- Test - lists.nanog.org

Comcast NOC contact
by Joe Marr 05 Feb '14

05 Feb '14

I'm seeing an odd routing issue with Comcast and would like their help. Does any have any contact information for them?

2 1

Re: BCP38
by Jay Ashworth 05 Feb '14

05 Feb '14

----- Original Message ----- > From: "Frank Bulk" <frnkblk(a)iname.com> > Here's such a report: > > http://spoofer.cmand.org/summary.php And those results aren't bad; they amount to between 2/3 and 3/4 of real source address space already having something implemented, if I'm reading them correctly. Cheers, -- jra -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://www.bcp38.info 2000 Land Rover DII St Petersburg FL USA BCP38: Ask For It By Name! +1 727 647 1274

1 0

[iab-chair@iab.org: Call for Review of draft-iab-filtering-considerations-06.txt, "Technical Considerations for Internet Service Blocking and Filtering"]
by Jeffrey Haas 05 Feb '14

05 Feb '14

It's IETF stuff. Operator sanity check would probably be appreciated. :-) -- Jeff ----- Forwarded message from IAB Chair <iab-chair(a)iab.org> ----- Date: Wed, 29 Jan 2014 11:16:56 -0500 From: IAB Chair <iab-chair(a)iab.org> To: IETF Announce <ietf-announce(a)ietf.org> Cc: IAB <iab(a)iab.org>, IETF <ietf(a)ietf.org> Subject: Call for Review of draft-iab-filtering-considerations-06.txt, "Technical Considerations for Internet Service Blocking and Filtering" This is a call for review of "Technical Considerations for Internet Service Blocking and Filtering" prior to potential approval as an IAB stream RFC. The document is available for inspection here: https://datatracker.ietf.org/doc/draft-iab-filtering-considerations/ The Call for Review will last until 26 February 2014. Please send comments to iab(a)iab.org. On behalf of the IAB, Russ Housley IAB Chair ----- End forwarded message -----

4 3

Verizon Wireless NOC contact
by Staudinger, Malcolm 05 Feb '14

05 Feb '14

Can someone from Verizon contact me off-list? We're seeing DNS resolution issues to Earthlink domains from Verizon Wireless customers, and have only gotten the run around from our "usual" Verizon NOC contacts Malcolm Staudinger Information Security Analyst | EIS EarthLink www.earthlink.net E: mstaudinger(a)corp.earthlink.com<mailto:mstaudinger@corp.earthlink.com>

1 0

Done a physical security audit lately?
by Jay Ashworth 05 Feb '14

05 Feb '14

http://www.npr.org/blogs/thetwo-way/2014/02/05/272015606/sniper-attack-on-c… -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.

3 4

Looking for Time Warner NOC contact
by Eric Sieg 05 Feb '14

05 Feb '14

Need some assistance isolating a connectivity issue between their customer and mine. Any assistance/direction would be greatly appreciated as normal paths have been exhausted.

1 0

Cogent <-> Verizon peering congestion
by Robert Glover 05 Feb '14

05 Feb '14

Hello, For the last several months, we have been tracking a congestion issue between Cogent <-> Verizon Host Loss% Snt Last Avg Best Wrst StDev 1. router.garlic.com 0.0% 29 0.3 6.1 0.2 160.6 29.7 2. vl203.mag03.sfo01.atlas.cogentco.com 0.0% 29 2.2 8.1 2.1 161.1 29.5 3. te0-0-0-14.ccr22.sfo01.atlas.cogentco.com 0.0% 29 2.9 2.7 2.4 3.6 0.2 4. be2165.ccr22.sjc01.atlas.cogentco.com 0.0% 29 4.1 4.0 3.7 4.8 0.2 5. be2047.ccr21.sjc03.atlas.cogentco.com 0.0% 29 4.5 4.7 4.3 5.5 0.3 6. verizon.sjc03.atlas.cogentco.com 22.2% 28 169.3 171.5 168.1 193.5 6.9 7. so-1-0-0-0.SJC01-CORE-RTR2.verizon-gni.net 37.0% 28 205.8 180.6 171.6 271.6 24.8 8. A12-0-135.SNFCCA-DSL-01.verizon-gni.net 33.3% 28 172.3 177.5 171.7 250.8 18.3 9. pool-71-116-122-235.snfcca.btas.verizon.net 25.0% 28 197.9 197.6 195.5 199.2 0.8 We have smokeping's from our side showing 30%+ packet loss from us (AS4307) to Verizon. All I have gotten from Cogent is a canned response: --- The latency and/or packet loss that you are experiencing to this destination is due to occasional high traffic with Verizon. We have repeatedly requested augments to these congestion points and hope Verizon will comply soon. While this has been escalated internally to the CEO level, we encourage you to also contact Verizon customer support with your concerns and complaints. Their delay is a major impediment to internet traffic overall and contrary to net neutrality requirements. Our peering engineers will continue to address this on a daily basis until resolved. --- It seems to have gotten a lot worse in recent days, to the point where we have customers who are trying to access us from Verizon's network (i.e. they have Verizon DSL, or via Verizon 3G/4GLTE) complaining they are having a very hard to checking their email, etc. Has anyone else been experiencing these issues? Or does anyone have more information that what Cogent provided me in their canned statement? -Bobby

6 8

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