February 2014 - Test - lists.nanog.org

Cisco 7606 CPU Usage Problem
by Shahab Vahabzadeh 05 Feb '14

05 Feb '14

Hi there, I have a Cisco 7606 with this module on it: WS-SUP32-GE-3B and I am using its own 8 port like this: 2 Port Layer two ether-channel uplink to my 4900 Cisco Switch and 1 Layer two uplink to Internet, and near 10 tunnel to my customers for internet exchange with BGP peering + some policy map for shaping tunnel interfaces. My ether-channel traffic on 600Mbps (each port 300Mbps) I get 90% cpu load and ping time problem on my router, what is the problem?? And when I run: show processs cpu sorted I get a "Unknown" process eat the cpu process... I try lots of IOS version but it does not make difference. My IOS version is: c7600s3223-adventerprisek9-mz.150-1.S1.bin and some general configuration: no ip source-route > ! > ip cef load-sharing algorithm original > no ip domain lookup > ! > ! > ! > ! > mls ip cef load-sharing full > no mls flow ip > no mls flow ipv6 > mls qos > mls cef error action reset > multilink bundle-name authenticated > ! > spanning-tree mode pvst > spanning-tree extend system-id > system flowcontrol bus auto > diagnostic bootup level minimal > port-channel load-balance src-ip > username admin secret 5 $1$g6WX$LaQbPyD3qIaHsF5qTqt8g0 > ! > redundancy > main-cpu > auto-sync running-config > mode sso > ! > ! > ! > ! > vlan internal allocation policy ascending > vlan access-log ratelimit 2000 Thanks -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90

2 1

Re: BCP38.info
by Nick Olsen 05 Feb '14

05 Feb '14

Agreed. Our's listed for AS36295 are two customers, Which I know for a fact have their default route set out of a GRE tunnel interface. So while we hand them the request to their interface IP we've assigned them. The response is actually sent, And transported via the customers GRE Tunnel, And HQ's Dedicated internet access where their tunneling to. Making it appear that the reply has been spoofed. When in reality. it was just silent transported to another area before being sent to the src. Nick Olsen Network Operations (855) FLSPEED x106 ---------------------------------------- From: "David Miller" <dmiller(a)tiggee.com> Sent: Tuesday, January 28, 2014 2:47 PM To: "Jared Mauch" <jared(a)puck.nether.net>, Valdis.Kletnieks(a)vt.edu Cc: "NANOG" <nanog(a)nanog.org> Subject: Re: BCP38.info On 1/28/2014 2:16 PM, Jared Mauch wrote: > > On Jan 28, 2014, at 1:50 PM, Valdis.Kletnieks(a)vt.edu wrote: > >> On Tue, 28 Jan 2014 08:06:31 -0500, Jared Mauch said: >> >>> 52731 ASN7922 >> >>> It includes IP address where you send a DNS packet to it and another IP address responds to the query, e.g.: >> >>> The data only includes those where the "source-ASN" and "dest-asn" of these packets don't match. >> >> Hang on Jared, I'm trying to wrap my head around this. You're saying that >> AS7922 has over 50K IP addresses which, if you send a DNS query to that IP, >> you get an answer back from *an entirely different ASN*? How the heck does >> *that* happen? > > Yup. Jared, What you detected is a misconfiguration of devices on those networks, but that misconfiguration (in and of itself) is not necessarily what is commonly referred to as "IP spoofing" in the context of BCP38. You have *not* "shown" that these ASNs "allow IP spoofing". You have collected one data point that indicates the mere possibility that these ASNs allow IP spoofing. In the example that you provided, you sent a DNS query to a Pacenet (India) IP and received a response from a Vodafone (India) IP address. The IP from which you received the invalid response is an open resolver (bad thing). It is completely plausible that whatever device is being queried has interfaces on both networks. To have "shown" that this ASN "allows IP spoofing" you must have demonstrated that this response packet, sourced from a Vodafone IP, entered the "Internet" from a Pacenet router interface. Unless I am missing something here, you haven't come close to showing that. -DMM

7 9

RE: Route Server Filters at IXPs and 4-byte ASNs
by Jakob Heitz 05 Feb '14

05 Feb '14

I would support that. http://tools.ietf.org/search/draft-raszuk-wide-bgp-communities-03 How would you modify it? To me, that draft looks hugely complicated, like everything you could possibly think of was thrown in. I would support a simplified version (and be able to code it without bugs) if it contained just useful stuff. -- Jakob Heitz. ________________________________________ Date: Sat, 25 Jan 2014 18:37:42 +0000 From: Nick Hilliard <nick(a)foobar.org> To: Sebastian Spies <s+Mailinglisten.nanog(a)sloc.de>, nanog(a)nanog.org Subject: Re: Route Server Filters at IXPs and 4-byte ASNs Message-ID: <52E40476.20200(a)foobar.org> Content-Type: text/plain; charset=ISO-8859-1 On 25/01/2014 15:48, Sebastian Spies wrote: > To make things worse: even if the IXPs ASN is 2-byte, I would assume, > that RS implementors chose to interpret extended community strings as > always being in the format 4-byte:2-byte (see RFC5668). some ixp operators (e.g. me) are rather enthusiastic about the idea of a modified form of draft-raszuk-wide-bgp-communities getting more traction. This would solve this particular problem and many others. Nick

4 4

MMF optics for Juniper EX4550
by Davey Goode 05 Feb '14

05 Feb '14

Hi All, Can anyone recommend where to get some 10G SFP+ MMF optics what will work in a Juno. Im in San Jose right now and I'm flying back to NZ on friday.... replies off list would be appreciated. thanks in advanced. davey

1 0

Verizon Fios Issue in Massachusetts
by Brian Loveland 05 Feb '14

05 Feb '14

Is anyone from Verizon available to help me chase down an issue off-list? Since Sunday morning, we've been seeing what looks to be a bad link aggregation (10+% packet loss on one IP, 0% on an adjacent IP) to all of the networks we control (on various providers, various AS's, various locations) and to common things like 8.8.8.8 and 8.8.4.4 from my Fios connection at home. Colleagues are seeing the same from other towns in MA. A couple of them have opened tickets with Fios support but haven't gotten anywhere. Unfortunately not a AS701 IP customer for our work networks, so can't follow normal support channels on that side. Thanks.

1 0

Cogent <-> Verizon peering congestion
by John Zettlemoyer 05 Feb '14

05 Feb '14

I got that same response from Cogent in August and October when we complained (word for word). Sometimes it's bad, sometimes it's "ok". Happens with Comcast sometimes too, but the peer to Verizon is usually worse. I can show packet loss with an MTR anytime of day. Today is an "ok" day.... just 5% loss on average. |------------------------------------------------------------------------------------------| | MTR statistics | | Host - % | Sent | Recv | Best | Avrg | Wrst | Last | |------------------------------------------------|------|------|------|------|------|------| | gw2-j.phl1.wcit.net - 0 | 101 | 101 | 1 | 6 | 98 | 2 | | gi3-6.ccr01.phl05.atlas.cogentco.com - 0 | 101 | 101 | 1 | 17 | 179 | 16 | | te7-4.ccr01.phl01.atlas.cogentco.com - 0 | 101 | 101 | 1 | 31 | 205 | 1 | | te4-1.ccr01.bwi01.atlas.cogentco.com - 0 | 101 | 101 | 3 | 34 | 192 | 3 | |te0-1-0-7.mpd21.dca01.atlas.cogentco.com - 0 | 101 | 101 | 5 | 6 | 11 | 6 | | be2113.ccr41.iad02.atlas.cogentco.com - 0 | 101 | 101 | 6 | 6 | 12 | 7 | | verizon.iad01.atlas.cogentco.com - 5 | 85 | 81 | 0 | 48 | 95 | 47 | | No response from host - 100 | 21 | 0 | 0 | 0 | 0 | 0 | | l100.cmdnnj-vfttp-01.verizon-gni.net - 5 | 85 | 81 | 55 | 62 | 136 | 56 | |________________________________________________|______|______|______|______|______|______| John Zettlemoyer

1 0

NANOG 60 ATL Data Center Track Update
by Martin Hannigan 04 Feb '14

04 Feb '14

All, We are planning to experiment with a change in the way "personals", a long standing tradition in the Peering Track, are done and in the Data Center track at NANOG 60 in Atlanta. The track is being held Monday starting at 4:45 and running through 6:15. Instead of data center operators presenting, the hosts or a member of the data center community will present a brief summary of regional data center bullet points. If you operate a data center in Georgia, North Carolina, South Carolina and Alabama, respond with the following bullet point answers by Friday. If we can't fit everyone, apologies in advance. 1. mW committed from utility? 2. mW currently available? 3. Any Facility Certifications? 4. Gross Square Footage of Data Center? 5. Net Square Footage available in Data Center? 6. Design PUE? 7. Wholesale, Retail Colo or Both? 8. Date Active? 9. Number of dual routed providers operational? Along with this, we'll be presenting short summaries related to recent, interesting, developments in the industry related to space, power and people. See the track agenda at http://bit.ly/1jbZ9aY Best Regards, -M<

2 1

Re: TWC (AS11351) blocking all NTP?
by Scott Weeks 04 Feb '14

04 Feb '14

----------------------------- > We block all outbound UDP for our ~200,000 Users for this very reason > (with the exception of some whitelisted NTP and DNS servers). So far > we have had 0 complaints ----------------------------- Because those that might complain switched providers when their internet broke instead of complaining and hoping something might change? scott

1 0

Visual tools for RSVP-TE
by Rampley Jr, Jim F 04 Feb '14

04 Feb '14

I'm curious what tools different organizations are using to provision, manage, and visually see how constraint based LSP's are routed over your network. Jim

1 0

Re: TWC (AS11351) blocking all NTP?
by Larry Sheldon 04 Feb '14

04 Feb '14

On 2/2/2014 9:17 PM, ryangard(a)gmail.com wrote: > I'd hate to think that NetOps would be so heavy handed in blocking > all of UDP, as this would essentially halt quite a bit of audio/video > traffic. That being said, there's still quite the need for protocol > improvement when making use of UDP, but blocking UDP as a whole is > definitely not a resolution, and simply creating a wall that not only > keeps the abusive traffic out, but keeps legitimate traffic from > flowing freely as it should. "We had to burn down the village to save it." -- Requiescas in pace o email Two identifying characteristics of System Administrators: Ex turpi causa non oritur actio Infallibility, and the ability to learn from their mistakes. (Adapted from Stephen Pinker)

12 24