Re: 1GE L3 aggregation

[Baldur Norddahl]

On 22 June 2016 at 22:04, David Charlebois  wrote:

> In our case, we advertise a single /24 from our head office to 2 upstream
> providers. The routing is %100 for redundancy.
>


The full table is in many cases overrated. If both your transits are good
service providers, you do not gain much by trying to get even better
routing compared to what the single homed customers of each provider is
getting. And that is basically what you are trying by taking in full tables.

The only thing to be beware of is some so called Tier 1 providers that have
bad interconnectivity to other Tier 1 providers. For example, neither
Cogent nor HE will give you a full view of the IPv6 network because these
two guys are in a peering war, so they miss the routes from the other
network. Taking in full tables allows you to select the correct provider
for the (relatively few) trouble routes, but note that you will still have
a problem if one link is down. The fix is to use smaller regional transit
providers, with each provider having multiple transits of his own.

For a feed with default route you can use the most basic BGP speaking
switch. Those are available for 1k USD or less. The ZTE switches we use are
in that range with copper ports and no 10G. Or you can get a Mikrotik
RB2011 for $99.

Or you can keep the full feed and use a Linux/BSD server for routing with
BIRD og Quagga. At 1G speed a server is going to do the job trivially. If
you want to be advanced, get two servers, one for each transit. Redundancy
on the LAN side can be provided by VRRP.

Regards,

Baldur

Re: IPv4 Legacy assignment frustration

[Ray Soucy]

Regardless of whether or not people "should" do this, I think the horse has
already left the barn on this one.  I don't see any way of getting people
who decided to filter all of APNIC to make changes.  Most of them are
static configurations that they'll never look to update.

On Wed, Jun 22, 2016 at 12:06 PM, Kraig Beahn  wrote:

> The following might add some clarity, depending upon how you look at it:
>
> We, as "core" engineers know better than to use some of the sources listed
> below, tho, my suspicion is that when an engineer or local IT person, on an
> edge network starts to see various types of attacks, they play wack-a-mole,
> based upon outdated or incomplete data, and never think twice about
> revisiting such, as, from their perspective, everything is working just
> fine.
>
> In a networking psychology test, earlier this morning, I wrote to ten
> well-known colleagues that I was fairly confident didn't regularly follow
> the nanog lists. Such individuals comprised of IP and IT engineers for
> which manage various network sizes and enterprises, ultimately posing the
> question of "Where in the world is 150.201.15.7, as we were researching
> some unique traffic patterns".
>
> *Seven out of ten came back with overseas*. Two came back with more
> questions "as the address space appeared to be assigned to APNIC", but was
> routed domestically.
>
> *One came back with the correct response.* (MORENET)
>
> Two of the queried parties were representative of major networks, one for
> an entire state governmental network with hundreds of thousands of actual
> users and tens of thousands of routers, the other from another major
> university. (Names left out, in the event they see this message later in
> the day or week)
>
> After probing the origin of their responses, I found the following methods
> or data-sources were used:
>
> -Search Engines - by far, the worst offender. Not necessarily "the engines"
> at fault, but a result of indexed sites containing inaccurate or outdated
> CIDR lists.
> -User generated forums, such as  "Block non-North American Traffic for
> Dummies Like Me
> "
> (Yes - that's the actual thread name on WebMasterWorld.com, from a Sr.
> Member)
> -Static (or aged) CIDR web-page based lists, usually placed for advertorial
> generation purposes and rarely up to date or accurate. (usually via SE's or
> forum referrals)
> -APNIC themselves - A basic SE search resulted in an APNIC page
> <
> https://www.apnic.net/manage-ip/manage-historical-resources/erx-project/erx-ranges
> >
> that,
> on it's face, appears to indicate 150.0.0.0/8 is in fact, part of the
> current APNIC range.
> -GitHub BGP Ranking tools: CIRCL / bgp-ranging example
> 
> (last
> updated on May 16th, 2011, tho an RT lookup
>  via the CIRCL tool
> does shows the appropriate redirect/org)
> -Several routing oriented books and Cisco examples
> <
> http://www.cisco.com/c/en/us/support/docs/ip/integrated-intermediate-system-to-intermediate-system-is-is/13796-route-leak.pdf
> >
> list
> such range, for example, FR/ISBN 2-212-09238-5.
> -And even established ISPs, that are publically announcing their "block
> list
> ", such as Albury's
> Local
> ISP in Australia
>
> The simple answer is to point IT directors, IP engineers or "the
> receptionists that manages the network" to the appropriate registry
> data-source, which should convince them that corrective action is
> necessary, i.e. fix your routing table or firewall. The complexity begins
> in trying to locate all of these people and directing them to the
> appropriate data-source, which I think is an unrealistic task, even for the
> largest of operators. Maybe a nanog-edge group is in order.
>
> If the issue was beyond just a nuisance and If I were in your shoes, i'd
> renumber or use an alternate range for the types of traffic affected by
> such blocks, i.e. administrative web traffic trying to reach major
> insurance portals. (Looks like AS2572 is announcing just over 700k IPv4
> address, over about 43 ranges with only some potentially affected)
>
> Realizing that renumbering is also extremely unrealistic, if you haven't
> already reached the IPv6 bandwagon, that's an option or, if none of the
> above seem reasonable, you could always put together a one-page PDF that
> points these administrators to the appropriate resource to validate that
> you, are in fact, part of the domestic United States.
>
> I agree that a more accurate tool probably needs to be created for the
> "general population to consume," but then again, even that solution, is
> "just another tool" for the search-engines to index, and you're back at
> square one.
>
> As much as I think most of us would like to help fix this issue, I don't
> know that a decent, non-in

60 hudson - insurance?

[Chris McDonald]

are others being told that their remote hands / installers , etc now need
to show proof of insurance?

thanks

Re: IPv4 Legacy assignment frustration

[Tom Smyth]

Hi Ray, Kraig
I think people affected just have to try to put pressure on their isps in
the path between the afffected ips and hope for the best... public pressure
is probably the only way to get around what I think most of us would agree
is a terrible practice... I really hope that we can get rid of this
practice as the last crumbs of IPv4 are carved up and re-distributed
amongst new and growing isps.

perhaps a name and shame project to highlight those isps that block ip
ranges constantly and indiscriminately,
needless to say the impact such practice has on peoples freedom to
communicate,

Thanks

Tom Smyth



On Thu, Jun 23, 2016 at 4:09 PM, Ray Soucy  wrote:

> Regardless of whether or not people "should" do this, I think the horse has
> already left the barn on this one.  I don't see any way of getting people
> who decided to filter all of APNIC to make changes.  Most of them are
> static configurations that they'll never look to update.
>
> On Wed, Jun 22, 2016 at 12:06 PM, Kraig Beahn  wrote:
>
> > The following might add some clarity, depending upon how you look at it:
> >
> > We, as "core" engineers know better than to use some of the sources
> listed
> > below, tho, my suspicion is that when an engineer or local IT person, on
> an
> > edge network starts to see various types of attacks, they play
> wack-a-mole,
> > based upon outdated or incomplete data, and never think twice about
> > revisiting such, as, from their perspective, everything is working just
> > fine.
> >
> > In a networking psychology test, earlier this morning, I wrote to ten
> > well-known colleagues that I was fairly confident didn't regularly follow
> > the nanog lists. Such individuals comprised of IP and IT engineers for
> > which manage various network sizes and enterprises, ultimately posing the
> > question of "Where in the world is 150.201.15.7, as we were researching
> > some unique traffic patterns".
> >
> > *Seven out of ten came back with overseas*. Two came back with more
> > questions "as the address space appeared to be assigned to APNIC", but
> was
> > routed domestically.
> >
> > *One came back with the correct response.* (MORENET)
> >
> > Two of the queried parties were representative of major networks, one for
> > an entire state governmental network with hundreds of thousands of actual
> > users and tens of thousands of routers, the other from another major
> > university. (Names left out, in the event they see this message later in
> > the day or week)
> >
> > After probing the origin of their responses, I found the following
> methods
> > or data-sources were used:
> >
> > -Search Engines - by far, the worst offender. Not necessarily "the
> engines"
> > at fault, but a result of indexed sites containing inaccurate or outdated
> > CIDR lists.
> > -User generated forums, such as  "Block non-North American Traffic for
> > Dummies Like Me
> > "
> > (Yes - that's the actual thread name on WebMasterWorld.com, from a Sr.
> > Member)
> > -Static (or aged) CIDR web-page based lists, usually placed for
> advertorial
> > generation purposes and rarely up to date or accurate. (usually via SE's
> or
> > forum referrals)
> > -APNIC themselves - A basic SE search resulted in an APNIC page
> > <
> >
> https://www.apnic.net/manage-ip/manage-historical-resources/erx-project/erx-ranges
> > >
> > that,
> > on it's face, appears to indicate 150.0.0.0/8 is in fact, part of the
> > current APNIC range.
> > -GitHub BGP Ranking tools: CIRCL / bgp-ranging example
> > <
> https://github.com/CIRCL/bgp-ranking/blob/master/lib/db_init/ip_del_list>
> > (last
> > updated on May 16th, 2011, tho an RT lookup
> >  via the CIRCL
> tool
> > does shows the appropriate redirect/org)
> > -Several routing oriented books and Cisco examples
> > <
> >
> http://www.cisco.com/c/en/us/support/docs/ip/integrated-intermediate-system-to-intermediate-system-is-is/13796-route-leak.pdf
> > >
> > list
> > such range, for example, FR/ISBN 2-212-09238-5.
> > -And even established ISPs, that are publically announcing their "block
> > list
> > ", such as Albury's
> > Local
> > ISP in Australia
> >
> > The simple answer is to point IT directors, IP engineers or "the
> > receptionists that manages the network" to the appropriate registry
> > data-source, which should convince them that corrective action is
> > necessary, i.e. fix your routing table or firewall. The complexity begins
> > in trying to locate all of these people and directing them to the
> > appropriate data-source, which I think is an unrealistic task, even for
> the
> > largest of operators. Maybe a nanog-edge group is in order.
> >
> > If the issue was beyond just a nuisance and If I were in your shoes, i'd
> > renumber or use an alternate range for the types of traffic affected by
> > such blocks, i.e. administrative web traff

Re: 60 hudson - insurance?

[Dovid Bender]

Chris,

We were told this a long time ago. You can always just say they work for you ;)


Regards,

Dovid

-Original Message-
From: Chris McDonald 
Sender: "NANOG" Date: Thu, 23 Jun 2016 16:22:30 
To: nanog list
Subject: 60 hudson - insurance?

are others being told that their remote hands / installers , etc now need
to show proof of insurance?

thanks

Re: 60 hudson - insurance?

[James Milko]

We got this from them a few years ago.  Same story to pull up the dock as
well.


On Thu, Jun 23, 2016 at 11:52 AM, Dovid Bender  wrote:

> Chris,
>
> We were told this a long time ago. You can always just say they work for
> you ;)
>
>
> Regards,
>
> Dovid
>
> -Original Message-
> From: Chris McDonald 
> Sender: "NANOG" Date: Thu, 23 Jun 2016 16:22:30
> To: nanog list
> Subject: 60 hudson - insurance?
>
> are others being told that their remote hands / installers , etc now need
> to show proof of insurance?
>
> thanks
>

Re: Looking for a Level 3 Routing Registry contact

[Theodore Baschak]

Curious if you had any luck with this task, I've tried via several avenues
and had very little luck getting old cruft removed. :-(

Theodore


On Fri, Jun 17, 2016 at 4:16 PM, Delacruz, Anthony B <
anthony.delac...@centurylink.com> wrote:

> Please contact me off list if you can help me get in touch with an actual
> person that can clear out old entries in the Level 3 routing registry. I
> can't do jack with the automated and the contacts that put them in are non
> responsive for clearing out their years old mess. Thanks.
>
> This communication is the property of CenturyLink and may contain
> confidential or privileged information. Unauthorized use of this
> communication is strictly prohibited and may be unlawful. If you have
> received this communication in error, please immediately notify the sender
> by reply e-mail and destroy all copies of the communication and any
> attachments.
>

Re: Looking for a Level 3 Routing Registry contact

[Fred Hollis]

same...

On 23.06.2016 at 18:42 Theodore Baschak wrote:

Curious if you had any luck with this task, I've tried via several avenues
and had very little luck getting old cruft removed. :-(

Theodore


On Fri, Jun 17, 2016 at 4:16 PM, Delacruz, Anthony B <
anthony.delac...@centurylink.com> wrote:


Please contact me off list if you can help me get in touch with an actual
person that can clear out old entries in the Level 3 routing registry. I
can't do jack with the automated and the contacts that put them in are non
responsive for clearing out their years old mess. Thanks.

This communication is the property of CenturyLink and may contain
confidential or privileged information. Unauthorized use of this
communication is strictly prohibited and may be unlawful. If you have
received this communication in error, please immediately notify the sender
by reply e-mail and destroy all copies of the communication and any
attachments.

Re: Cisco 2 factor authentication

[Chris Lawrence]

Any radius based auth works well I've used a solution by secure envoy I the 
past which seems to work well they also have soft token apps, hard tokens plus 
SMS based.

Sent from my iPhone

> On 23 Jun 2016, at 01:51, Ray Ludendorff  wrote:
>
> Has anyone setup two factor VPN using a Cisco ASA VPN solution?
> What sort of soft client based dual factor authentication options were used 
> for the Cisco VPNs (e.g. Symantec VIP, Google authenticator, Azure 
> authenticator, RSA, etc.)
> I am trying to find what infrastructure is needed to come up with the 
> solution.
>
> Please contact me of list
>
> Regards
> Ray Ludendorff
>
>
>



DISCLAIMER: The information contained in this communication from 
clawre...@dovefire.co.uk is confidential and may be legally privileged. It is 
intended solely for use by the recipient and others authorised to receive it. 
If you are not the intended recipient you are hereby notified that any 
disclosure, copying, distribution or taking action in reliance of the contents 
of this information is strictly prohibited and may be unlawful.

WARNING: Although the company has taken reasonable precautions to insure no 
viruses are present in this email, the company cannot accept responsibility for 
any loss or damage arising from the use of this email or attachments.

Registered in England and Wales No 09745479 as Dovefire Technology Solutions 
Limited
Registered Address Clifton Mill, Pickup Street, Accrington, Lancashire, BB5 0EY

Please consider the environment before printing this e-mail.

www.dovefire.co.uk 

Re: Cisco 2 factor authentication

[Peter Loron]

We are in the process of rolling out Okta, including using a second factor for 
AnyConnect VPN. Works well.

-Pete

On 6/22/16, 01:27, "NANOG on behalf of Ray Ludendorff"  wrote:

Has anyone setup two factor VPN using a Cisco ASA VPN solution?
What sort of soft client based dual factor authentication options were used for 
the Cisco VPNs (e.g. Symantec VIP, Google authenticator, Azure authenticator, 
RSA, etc.)
I am trying to find what infrastructure is needed to come up with the solution.

Please contact me of list

Regards
Ray Ludendorff

RE: 60 hudson - insurance?

[Keith Medcalf]

How do you show proof of self-insurance?

Or is this an extortion racket?

> -Original Message-
> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Chris McDonald
> Sent: Thursday, 23 June, 2016 09:23
> To: nanog list
> Subject: 60 hudson - insurance?
>
> are others being told that their remote hands / installers , etc now need
> to show proof of insurance?
>
> thanks