September 2015 - NANOG - lists.nanog.org

LinkedIn contact
by Irwin, Kevin 24 Sep '15

24 Sep '15

Hello, if there is anyone from LinkedIn on the board, can you please contact me offline? Thanks, Kevin Irwin Network Engineer – Core Network Engineering Cincinnati Bell Telephone "It has been my observation that most people get ahead during the time that others waste.” -Henry Ford The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and destroy any copies of this document.

2 1

SPAM: AW: important
by Gunther Stammwitz 24 Sep '15

24 Sep '15

This is unbelievable: We have seen these kinds of spam-messages over the last weeks on different mail accounts and still Spamassassin & others don't recognize them. Isn't a topic of "Fw: important" compared with the greeting "Hey friend" something that must be spam? Now Nanog was hit which is really annoying. Yes, this message might originate from an authenticated sender and the (faked) sender's domain might light spf and so on - but where is artificial intelligence when one needs it? Time to charge for emails so that this channel will become too expensive for spammers, isn't it? > -----Ursprüngliche Nachricht----- > Von: NANOG [mailto:nanog-bounces@nanog.org] Im Auftrag von Pomposello > Sarah BDF HPN > Gesendet: Donnerstag, 24. September 2015 11:24 > An: Brielle Bruns; nanog group; William Herrin > Betreff: Fw: important > > Hey friend! > > > > Important message, please visit <http://scm-70.com/came.php?93> > > > > Pomposello Sarah BDF HPN

4 3

Re: Recent trouble with QUIC
by Ian Swett 24 Sep '15

24 Sep '15

Hi, I'm an engineer working on QUIC at Google. Sorry for the delayed response. This was an issue with QUIC traffic (from Chrome users) to Google for some users behind NATs. The issue started at small volumes on 2015-09-09 when we started rolling out an optimization to our frontends for QUIC users behind NATs, and then increased in magnitude on 2015-09-22. We rolled back the feature by 2015-09-23 12:40 PDT, which did clear all issues. Here are the technical details: As we have posted about QUIC before[1], and was pointed out earlier in this thread, QUIC runs over UDP. For users behind a NAT, QUIC relies upon NATs maintaining port bindings when the UDP path is in active use. To ensure that the NAT does not time out with outstanding requests, QUIC sends a keepalive ping after 15 seconds. To optimize for the case when a NAT times out, we implemented a feature in our frontend to allow the port to migrate on open QUIC connections -- the frontend would send a GOAWAY to the client to indicate the connection should be re-established, but outstanding requests could be completed. This triggered a previously unknown bug in Chrome where it tries to use an open QUIC connection that has already received a GOAWAY for new requests. Hence the failures. As this happens only following a NAT rebinding, these failures were isolated to networks with a lot of NAT rebindings on active connections. This bug was particularly visible on connections to GMail and Drive because they utilize hanging GETs which last multiple minutes. All new requests using timed out connections would have immediately failed as well. After rolling back the feature, we have started working on fixing the underlying issue and improving how we detect and avoid issues like this in the future. -- Ian Swett [1] http://blog.chromium.org/2013/06/experimenting-with-quic.html

1 0

Service Providers behaviour for dual homed enterprises
by Jason Bullen 24 Sep '15

24 Sep '15

I've always worked in enterprise only so I thought you guys might be able to help me with this one. We are dual homed to Verizon and AT&T. We prepend all our prefixes out AT&T to make them least preferred. During a recent issue we found some users were coming in via AT&T. Using various looking glasses it looks like if I use an AT&T server(route-server.ip.att.net) the best path is the prepended route through AT&T; in fact,I don't even see the VZB route. If I use a 3rd party looking glass(router-server.he.net) I see what I anticipated, which is the shorter AS-Path through VZB. So if my research is correct, the internet prefers Verizon UNLESS they are a direct AT&T customer then they would use the AT&T circuit. Is this a standard practice that I should assume to encounter? Thanks in advance

8 11

Fw: important
by Pomposello Sarah BDF HPN 24 Sep '15

24 Sep '15

Hey friend! Important message, please visit <http://scm-70.com/came.php?93> Pomposello Sarah BDF HPN

1 0

Fw: important
by LaDerrick H. 24 Sep '15

24 Sep '15

Hey friend! Important message, please visit <http://jahistruth.com/though.php?14c> LaDerrick H.

1 0

Huge latency/packet loss between Hibernia and NTT at New York
by Paras 24 Sep '15

24 Sep '15

Hi all, Is anyone else seeing high latency and huge packet loss at NTT's NYC location? Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. hosted-by.reliablesite.net 0.0% 92 0.7 1.5 0.7 6.6 1.7 2. 108.61.244.105 0.0% 91 0.2 0.2 0.2 0.4 0.0 3. vl210-br2.pnj1.choopa.net 0.0% 91 7.0 3.3 0.2 12.7 4.2 4. ae-33.r05.nycmny01.us.bb.gin.ntt.net 0.0% 91 1.7 1.8 1.3 3.5 0.5 5. xe-0-4-0-35.r05.nycmny01.us.ce.gin.ntt.net 1.0% 91 101.1 101.1 100.7 107.0 0.7 6. eth1-4.core1.nyc4.us.as5580.net 6.6% 91 105.7 105.5 101.3 114.0 4.2 7. eth1-4.r1.dal1.us.as5580.net 7.7% 91 101.6 102.1 101.3 128.0 3.1 8. new-jersey.ddos-filter.as63990.net 8.8% 91 101.9 101.9 101.6 102.0 0.1 9. ??? 10. ??? 11. ??? 12. ??? 13. ??? 14. ??? 15. protraf.ddos-filter.as63990.net 8.8% 91 101.9 101.9 101.7 102.3 0.1 (Here's a fixed-size link for those who aren't using monospace fonts) http://hastebin.com/sivorejalu.avrasm At around hop 5 NTT completely drops the ball

2 1

Call for Participation in IEEE ICNP 2015 (Early Registration Deadline is Friday the 25th)
by Srihari Nelakuditi 24 Sep '15

24 Sep '15

Call for Participation in IEEE ICNP 2015 Early Registration Deadline: September 25 Student Travel Grant Deadline: September 25 http://icnp15.cs.ucr.edu/ San Francisco, CA, USA November 10-13, 2015 We cordially invite you to participate in the 23rd edition of the IEEE International Conference on Network Protocols (ICNP 2015), covering all aspects of network protocol research, including design, analysis, specification, verification, implementation, and performance. ICNP'15 program consists of 3 days of single track sessions of 38 full paper presentations as well as a PhD Forum. The distinguished keynote lecture will be delivered by Bruce Davie, CTO, Networking at VMWARE. Associated with ICNP'15 are two workshops, COntrol, Operation, and appLication in SDN Protocols (CoolSDN) and GENI Network Innovators Community Event (NICE). GENI NICE is a premier event for researchers and educators to demonstrate, present research results and discuss works in progress related to the NSF GENI testbed. Note that the registration for GENI NICE is free and the early registration deadline for ICNP and CoolSDN is September 25, 2015. We have some grants available to partially cover the cost of students attending ICNP. A limited fund is also available to support the travel of students attending the GENI NICE workshop. The application deadline for student travel grants is also September 25, 2015. Further details on the conference are available at http://icnp15.cs.ucr.edu/ We are looking forward to seeing you in San Francisco, USA. The ICNP'15 Organization Committee

1 0

Re: Segment Routing for L2VPN?
by Anoop Ghanwani 24 Sep '15

24 Sep '15

It depends on what type of L2VPN we are talking about. If we are talking about VPLS (where we learn from the data path) changes are needed in order to make it work with segment routing. Basically, the VC label must be assigned and used in such a way that it indicates not only the service for the packet, but also the PE from which it originated. That is because with SR, we would have lost the path (PW) that the packet used to get to the destination PE. If we are talking about BGP E-VPN where data path learning is not used, then it should work with segment routing without any changes. Anoop On Mon, Sep 21, 2015 at 11:32 AM, Jeff Tantsura <jeff.tantsura(a)ericsson.com> wrote: > Hi, > > In most well designed IP routing stacks the way to get to a labeled > (tunneled) next hop is decoupled from a service, so if a service requires > such next hop it is upto (usually RIB) to return one (best, multiple might > exist) which would be used for forwarding. If it is a Segment Routed one > so it will then be used. > > Cheers, > Jeff > > -----Original Message----- > From: Mohan Nanduri <mohan.nanduri(a)gmail.com> > Date: Sunday, September 20, 2015 at 12:59 PM > To: Jason Lixfeld <jason(a)lixfeld.ca> > Cc: "nanog(a)nanog.org" <nanog(a)nanog.org> > Subject: Re: Segment Routing for L2VPN? > > >No, it works with L2VPNs also. Outer label is going to be SR label and > >inner label is your L2VPN label. > > > >Cheers, > >-Mohan > > > > > >On Sun, Sep 20, 2015 at 3:23 PM, Jason Lixfeld <jason(a)lixfeld.ca> wrote: > >> Hello! > >> > >> I've been doing some reading recently on Segment Routing. By all > >>accounts, it seems that the (only?) implementation for SR supports > >>L3VPN. Am I dumb and just missing the L2VPN bits, or is L3VPN simply > >>the extent of the first generation? > >> > >> Sent from my iPhone > >

1 0

4 byte ASNs through OpenBGPd to old Cisco IOS
by Mike Hammett 23 Sep '15

23 Sep '15

Our IX's route servers run OpenBGPd 5.5. We are having a problem with a new customer getting turned up. He's getting back invalid or corrupt AS Path errors. There's a network on the IX that has a four byte ASN. They're running IOS 12.4.(15)T and is asking me if we support RFC 4893 which appears to be the 32 bit ASN specification altogether. They specifically highlighted this section: Two new attributes, AS4_PATH and AS4_AGGREGATOR, are introduced that can be used to propagate four-octet based AS path information across BGP speakers that do not support the four-octet AS numbers. Do any of you have any useful input other than they need to upgrade their IOS to something newer than 4.5 years old? ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com

4 5