Re: nested prefixes in Internet

2016-10-19 Thread Matt Buford 
On Mon, Oct 10, 2016 at 2:44 PM, Baldur Norddahl 
wrote:


> Is that a real problem? In my experience a /24 is honoured almost
> universially.
>

Here's a real-world issue I ran into with this.  In this case, it isn't
that someone filtered /24s, but that they didn't have a full table (peering
routes only plus a default).  This resulted in them following the less
specific route for traffic destined for the /24.

A customer of mine was advertising only a /20 to me and then only a more
specific /24 was advertised from a remote site of theirs to a different
ISP.  The customer did have a connection between their two sites, so in
theory it was OK if the traffic arrived on their "wrong" link, except that
the customer strongly didn't want this to happen, thus the inconsistent
routes.

This customer found that the remote /24 was unable to access a large CDN
provider.  This CDN told them that a traceroute to the /24 went to my
network (we peered at an exchange) and was then dropped.

This seemed odd at first, as I confirmed I was not advertising the /24 to
them so why were they routing it to me?  It turned out that the CDN
provider was running a peer-routes-only network with a default to their
transit.  This meant that they saw the /20 from their peer (me) but never
saw the /24, since they carried no transit routes.  This resulted in them
routing the entire /20 to me.

My peering router was not willing to route traffic from a peering exchange
towards transit I had to pay for, so it was dropped.

The customer's split advertisements didn't seem particularly unreasonable
or invalid, though perhaps they were not the preferred setup.  It wasn't
unreasonable for me to not route from a peering exchange to transit.  It
wasn't unreasonable of the CDN to have a peering-and-default routing
table.  But, those three things together were not compatible.

I called the customer and presented them with my findings and some
potential options to consider, and consistent advertisements was one of
those options.  The customer strongly wanted incoming traffic to arrive
directly to the correct location so he didn't want to do that.  I suggested
a possible compromise was for him to advertise both the /24 and /20 to me,
but use communities so that I never advertised his /24 to any upstreams or
peering exchanges.  That way, if traffic for the /24 accidentally hit my
network like we were running into, I would route it to him and he could
pass it to the correct site.  It meant that a little traffic would arrive
at the wrong site in his network and have to pass over his back-end link,
but at least it would be fairly limited.  He didn't like this either.  He
didn't want to split the /20 advertisement up to no longer cover the /24
either, I think just because "I shouldn't have to do that!"

The option the customer chose in the end was to use a community on his
advertisement to instruct my routers to no longer advertise his /20 to any
peering exchanges at all.  That ensured the CDN didn't directly send me
anything for him (not the /24 or the /20), and the transit networks
in-between took care of making sure traffic to the /24 didn't accidentally
end up on my network.  While I didn't find it very elegant to be shifting
traffic from peering exchanges to transit, it wasn't a significant amount
of traffic and it got him off my back.

Re: Coherent CWDM 40G QSFP

2016-10-19 Thread Rod Beck 
True 40 gigs is rare period. Most of the time it is bandwidth limiting on a 100 
gig wave.



From: NANOG  on behalf of Mike Hammett 

Sent: Wednesday, October 19, 2016 11:46 PM
To: Tim Durack
Cc: nanog list
Subject: Re: Coherent CWDM 40G QSFP

Apparently I just remembered the big transport platforms using coherent 40G and 
100G and assumed there was a cheap variant, but there isn't.




-
Mike Hammett
Intelligent Computing Solutions

Midwest Internet Exchange

The Brothers WISP

- Original Message -

From: "Tim Durack" 
To: "Mike Hammett" , "nanog list" 
Sent: Tuesday, October 18, 2016 9:28:02 PM
Subject: Re: Coherent CWDM 40G QSFP

Not aware of ACO/DCO in QSFP form factor. Inphi is doing 100G QSFP28 PAM4 DWDM 
for MS. Probably the best you will see for a while.


On Tue, Oct 18, 2016 at 4:50 PM Mike Hammett < na...@ics-il.net > wrote:


Does anyone make a coherent CWDM 40G QSFP? I thought so, but the first couple 
places I checked, I struck out at. This would be for a passive mux\MROADM.




-
Mike Hammett
Intelligent Computing Solutions

Midwest Internet Exchange

The Brothers WISP

Re: Coherent CWDM 40G QSFP

2016-10-19 Thread Mike Hammett 
Apparently I just remembered the big transport platforms using coherent 40G and 
100G and assumed there was a cheap variant, but there isn't. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Tim Durack"  
To: "Mike Hammett" , "nanog list"  
Sent: Tuesday, October 18, 2016 9:28:02 PM 
Subject: Re: Coherent CWDM 40G QSFP 

Not aware of ACO/DCO in QSFP form factor. Inphi is doing 100G QSFP28 PAM4 DWDM 
for MS. Probably the best you will see for a while. 


On Tue, Oct 18, 2016 at 4:50 PM Mike Hammett < na...@ics-il.net > wrote: 


Does anyone make a coherent CWDM 40G QSFP? I thought so, but the first couple 
places I checked, I struck out at. This would be for a passive mux\MROADM. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP

Re: nested prefixes in Internet

2016-10-19 Thread Baldur Norddahl 

Hi

Solution B is what happens by default and requires no changes by any 
party. A, B and C just do what they would do in any transit relation. 
The default BGP shortest AS path length first algorithm will make sure 
that traffic is delivered correctly.


Solution A requires that ISP A actively filter the /24 announcement and 
that would have severe negative impact. It would mean that you would not 
receive any traffic at all through that link unless the link to ISP B is 
down. Not even traffic from A to B (that would go A -> C -> B because of 
the more specific). Maybe you meant that they would only filter the /24 
announcement on the peering link between A and C, but that would have no 
effect and therefore makes no sense.


Remember that ISP A is only originating their own /19. The /24 route 
announcement is received from ISP B and merely propagated (not 
originated) to ISP As uplink and peers. The moment that the link between 
A and B is down, the /24 route announcement will gone as well - instead 
A will be receiving the /24 route announcement via C.


Regards,

Baldur



Den 19/10/2016 kl. 18.27 skrev Martin T:

Hi,

I made a drawing of those two best solutions: http://i.imgur.com/7NQVgUH.png

As much as I understand, both solutions require no special changes
from "ISP C". Only advantage of solution B over solution A, that I can
see, is that at the time when link between "ISP C" and "ISP B" is up,
the traffic from Internet towards "ISP B" prefers the "ISP C"
connection.


In case the link between "ISP A" and "ISP B" goes down, then traffic
from "ISP A" addressed to this /24 will use a private peering link
between "ISP A" and "ISP C" so the transit costs are not an issue.


thanks,
Martin

On Wed, Oct 12, 2016 at 1:58 AM, Owen DeLong  wrote:

On Oct 10, 2016, at 14:59 , Baldur Norddahl  wrote:



Den 10/10/2016 kl. 22.27 skrev Owen DeLong:

Not true… There are myriad reasons that the /24 might not reach a network 
peered with ISP-A, including the possibility of being a downstream customer of 
a network peered with or buying transit from ISP-A. In the latter case, not an 
issue, since it’s paid transit, but in the former (peered, not transit), again, 
ISP-A is probably not super excited to carry traffic that someone isn’t paying 
them to carry.


But ISP-A is in fact being paid to carry the traffic. Supposedly ISP-B has a 
paid transit relation to ISP-A. In the case the transit link is down ISP-A 
might have to transport the traffic through a less profitable link however.

Which isn’t really in the agreement between ISP-B and ISP-A unless it was 
specifically (and unusually) negotiated.

Also, you’re assuming that the leased space came with a transit agreement. In 
many cases, address leases don’t, so consider the additional scenario where 
ISP-B leases addresses from ISP-A, but has transit contracts with ISP-C and 
ISP-D but no connection at all to ISP-A.


I know that if ISP-A was my network I would be making money even with the 
transit link down. Yes I might have to transport something out of my network 
through one of my transits, but outbound traffic is in fact free for us because 
we are heavy inbound loaded.

Yes, but it doesn’t help if it also came in on a transit link. Any traffic you 
both receive and transmit on transit costs you money pretty much no matter who 
you are.


Owen

Re: Excessive Netflix DNS Traffic?

2016-10-19 Thread Velocity Lists 
Did (Netflix) find an issue?

Velocity Online
850-205-4638

On Mon, Oct 17, 2016 at 12:05 PM, Dave Temkin  wrote:

> We (Netflix) are investigating this now.
>
> -Dave
>
>
>
>
>
> On Sat, Oct 15, 2016 at 12:44 PM -0500, "Velocity Lists" <
> voli...@staff.velocityonline.net> wrote:
>
> We have seen it as well.
>> In our cases it is all TCP DNS traffic as well.
>>
>> Velocity Online850-205-4638
>>
>> On Fri, Oct 14, 2016 at 11:43 AM, Eamon Bauman
>> wrote:
>>
>> > We're rate limiting it now, but it's definitely bad behavior. When I open
>> > the flood gates, over a 5-min sample from a single host I received well
>> > over 61,000 queries.
>> > The size of the records being requested cause this to be an (unintended)
>> > amplification attack, as a 30Mbps inbound sum is getting amplified to
>> > 150-200Mbps outbound.
>> >
>> > On Thu, Oct 13, 2016 at 7:52 PM, Josh Reynolds
>> > wrote:
>> >
>> > > Same here :)
>> > >
>> > > On Oct 13, 2016 1:09 PM, "Ryan, Spencer"  wrote:
>> > >
>> > >> I was going to point you to the reddit thread about it, but it looks to
>> > >> be your thread :)
>> > >>
>> > >>
>> > >> Spencer Ryan | Senior Systems Administrator | sr...@arbor.net >> 
>> > >> sr...@arbor.net>
>> > >> Arbor Networks
>> > >> +1.734.794.5033 (d) | +1.734.846.2053 (m)
>> > >> www.arbornetworks.com
>> > >>
>> > >>
>> > >> 
>> > >> From: NANOG  on behalf of Eamon Bauman <
>> > >> ea...@eamonbauman.com>
>> > >> Sent: Thursday, October 13, 2016 10:26:57 AM
>> > >> To: nanog@nanog.org
>> > >> Subject: Excessive Netflix DNS Traffic?
>> > >>
>> > >> Hi all,
>> > >>
>> > >> Is anyone seeing excessive DNS traffic from game consoles (Xbox One,
>> > PS4)
>> > >> running Netflix? Starting 9/29 we have been seeing significant volume of
>> > >> DNS traffic from game consoles on our campus to our caching recursive
>> > >> boxes. Logs show repeated requests for api-global.netflix.com and
>> > >> nrdp.nccp.netflix.com.
>> > >>
>> > >> Anyone else experiencing this?
>> > >>
>> > >> Eamon
>> > >>
>> > >
>> >
>>
>>

Re: nested prefixes in Internet

2016-10-19 Thread Owen DeLong 
Assuming that there is a PNI A<->C assumes facts not in evidence.

Owen

> On Oct 19, 2016, at 11:27 AM, Martin T  wrote:
> 
> Hi,
> 
> I made a drawing of those two best solutions: http://i.imgur.com/7NQVgUH.png
> 
> As much as I understand, both solutions require no special changes
> from "ISP C". Only advantage of solution B over solution A, that I can
> see, is that at the time when link between "ISP C" and "ISP B" is up,
> the traffic from Internet towards "ISP B" prefers the "ISP C"
> connection.
> 
> 
> In case the link between "ISP A" and "ISP B" goes down, then traffic
> from "ISP A" addressed to this /24 will use a private peering link
> between "ISP A" and "ISP C" so the transit costs are not an issue.
> 
> 
> thanks,
> Martin
> 
> On Wed, Oct 12, 2016 at 1:58 AM, Owen DeLong  wrote:
>> 
>>> On Oct 10, 2016, at 14:59 , Baldur Norddahl  
>>> wrote:
>>> 
>>> 
>>> 
>>> Den 10/10/2016 kl. 22.27 skrev Owen DeLong:
 Not true… There are myriad reasons that the /24 might not reach a network 
 peered with ISP-A, including the possibility of being a downstream 
 customer of a network peered with or buying transit from ISP-A. In the 
 latter case, not an issue, since it’s paid transit, but in the former 
 (peered, not transit), again, ISP-A is probably not super excited to carry 
 traffic that someone isn’t paying them to carry.
 
>>> 
>>> But ISP-A is in fact being paid to carry the traffic. Supposedly ISP-B has 
>>> a paid transit relation to ISP-A. In the case the transit link is down 
>>> ISP-A might have to transport the traffic through a less profitable link 
>>> however.
>> 
>> Which isn’t really in the agreement between ISP-B and ISP-A unless it was 
>> specifically (and unusually) negotiated.
>> 
>> Also, you’re assuming that the leased space came with a transit agreement. 
>> In many cases, address leases don’t, so consider the additional scenario 
>> where ISP-B leases addresses from ISP-A, but has transit contracts with 
>> ISP-C and ISP-D but no connection at all to ISP-A.
>> 
>>> I know that if ISP-A was my network I would be making money even with the 
>>> transit link down. Yes I might have to transport something out of my 
>>> network through one of my transits, but outbound traffic is in fact free 
>>> for us because we are heavy inbound loaded.
>> 
>> Yes, but it doesn’t help if it also came in on a transit link. Any traffic 
>> you both receive and transmit on transit costs you money pretty much no 
>> matter who you are.
>> 
>> 
>> Owen
>>

Re: nested prefixes in Internet

2016-10-19 Thread Martin T 
Hi,

I made a drawing of those two best solutions: http://i.imgur.com/7NQVgUH.png

As much as I understand, both solutions require no special changes
from "ISP C". Only advantage of solution B over solution A, that I can
see, is that at the time when link between "ISP C" and "ISP B" is up,
the traffic from Internet towards "ISP B" prefers the "ISP C"
connection.


In case the link between "ISP A" and "ISP B" goes down, then traffic
from "ISP A" addressed to this /24 will use a private peering link
between "ISP A" and "ISP C" so the transit costs are not an issue.


thanks,
Martin

On Wed, Oct 12, 2016 at 1:58 AM, Owen DeLong  wrote:
>
>> On Oct 10, 2016, at 14:59 , Baldur Norddahl  
>> wrote:
>>
>>
>>
>> Den 10/10/2016 kl. 22.27 skrev Owen DeLong:
>>> Not true… There are myriad reasons that the /24 might not reach a network 
>>> peered with ISP-A, including the possibility of being a downstream customer 
>>> of a network peered with or buying transit from ISP-A. In the latter case, 
>>> not an issue, since it’s paid transit, but in the former (peered, not 
>>> transit), again, ISP-A is probably not super excited to carry traffic that 
>>> someone isn’t paying them to carry.
>>>
>>
>> But ISP-A is in fact being paid to carry the traffic. Supposedly ISP-B has a 
>> paid transit relation to ISP-A. In the case the transit link is down ISP-A 
>> might have to transport the traffic through a less profitable link however.
>
> Which isn’t really in the agreement between ISP-B and ISP-A unless it was 
> specifically (and unusually) negotiated.
>
> Also, you’re assuming that the leased space came with a transit agreement. In 
> many cases, address leases don’t, so consider the additional scenario where 
> ISP-B leases addresses from ISP-A, but has transit contracts with ISP-C and 
> ISP-D but no connection at all to ISP-A.
>
>> I know that if ISP-A was my network I would be making money even with the 
>> transit link down. Yes I might have to transport something out of my network 
>> through one of my transits, but outbound traffic is in fact free for us 
>> because we are heavy inbound loaded.
>
> Yes, but it doesn’t help if it also came in on a transit link. Any traffic 
> you both receive and transmit on transit costs you money pretty much no 
> matter who you are.
>
>
> Owen
>

Re: Linux router guru sought for hairpulling issue

2016-10-19 Thread Eric Germann 
Thanks to Robert McKay for the answer that fixed it.

His explanation was

> Did you forget to add ttl 255 (or similar) to the tunnel setup? By default 
> the gre packets will end up with the ttl set to the same as the inside 
> payload ttl so when you traceroute they won't reach the other gateway.. that 
> sounds like what you might be talking about?
> 
> http://lartc.org/howto/lartc.tunnel.gre.html 
> 

Added TTL=255 to the ifcfg-tun* config files and all is well.

Thanks to the others for their ideas (too many to name).

Great community

EKG



> On Oct 19, 2016, at 8:27 AM, Eric Germann  wrote:
> 
> Colleagues,
> 
> I know we’re all usually running big gear, but I’ve been tasked with building 
> some appliances to run in the cloud as VM’s.
> 
> Looking for someone who has built on Centos 7 using IPSec and GRE tunnels.  
> Having an issue with GRE tunnels and trace route. That’s pulling my hair out.
> 
> If you’d like to discuss, reply off list.
> 
> Thanks
> 
> EKG
> 



smime.p7s
Description: S/MIME cryptographic signature

Linux router guru sought for hairpulling issue

2016-10-19 Thread Eric Germann 
Colleagues,

I know we’re all usually running big gear, but I’ve been tasked with building 
some appliances to run in the cloud as VM’s.

Looking for someone who has built on Centos 7 using IPSec and GRE tunnels.  
Having an issue with GRE tunnels and trace route. That’s pulling my hair out.

If you’d like to discuss, reply off list.

Thanks

EKG



smime.p7s
Description: S/MIME cryptographic signature

Re: 18 years ago today - rfc 2468

2016-10-19 Thread Mike Hammett 
"or you haven't read enough RFCs" so for those of us that aren't masochists 

;-) 


I did get my summary last year at NANOG, though. 



- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Wayne Bouchard"  
To: "Patrick W. Gilmore"  
Cc: "NANOG list"  
Sent: Wednesday, October 19, 2016 2:44:31 AM 
Subject: Re: 18 years ago today - rfc 2468 

And for those of you who you don't recognize his name, either you 
aren't old enough or you haven't read enough RFCs, though his 
contributions go wayyy beyond that. It is fair to say he is very 
much one of the cadre of personell who quite literally built the 
internet that so many of the rest now take for granted. 

On Sat, Oct 15, 2016 at 09:21:01AM -0400, Patrick W. Gilmore wrote: 
> We do. 
> 
> Thank you for reminding us. And thanks to Dr. Postel for making what we do 
> possible. 
> 
> -- 
> TTFN, 
> patrick 
> 
> > On Oct 15, 2016, at 9:19 AM, Rodney Joffe  wrote: 
> > 
> > To be clear - Oct 16. Which has just tolled in the APAC region. For most of 
> > you it will be tomorrow. But no matter. You get the point. 
> > 
> >> On Oct 15, 2016, at 9:08 AM, Rodney Joffe  wrote: 
> >> 
> >> How time flies 
> 

--- 
Wayne Bouchard 
w...@typo.org 
Network Dude 
http://www.typo.org/~web/

Re: 18 years ago today - rfc 2468

2016-10-19 Thread Wayne Bouchard 
And for those of you who you don't recognize his name, either you
aren't old enough or you haven't read enough RFCs, though his
contributions go wayyy beyond that. It is fair to say he is very
much one of the cadre of personell who quite literally built the
internet that so many of the rest now take for granted.

On Sat, Oct 15, 2016 at 09:21:01AM -0400, Patrick W. Gilmore wrote:
> We do.
> 
> Thank you for reminding us. And thanks to Dr. Postel for making what we do 
> possible.
> 
> -- 
> TTFN,
> patrick
> 
> > On Oct 15, 2016, at 9:19 AM, Rodney Joffe  wrote:
> > 
> > To be clear - Oct 16. Which has just tolled in the APAC region. For most of 
> > you it will be tomorrow. But no matter. You get the point. 
> > 
> >> On Oct 15, 2016, at 9:08 AM, Rodney Joffe  wrote:
> >> 
> >> How time flies
> 

---
Wayne Bouchard
w...@typo.org
Network Dude
http://www.typo.org/~web/

NetRouting NOC

2016-10-19 Thread Chris Knipe 
Hi,

Anyone from NetRouting NOC (AS47869) that can contact me off list please.
Not getting anywhere resolving a routing issue with your support personnel.

-- 

Regards,
Chris Knipe