- Test - lists.nanog.org

19108/suddenlink/cox contact?
by Jared Mauch 29 Aug '07

29 Aug '07

Can someone from suddenlink or cox contact me offlist? i've tried various other avenues to no avail.. - jared -- Jared Mauch | pgp key available via finger from jared(a)puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.

1 0

Seeking UUNET/Level3 help re packet loss between Comcast & Onvoy customers
by Rich Graves 29 Aug '07

29 Aug '07

On August 2, my Craig D. Rice from stolaf.edu posted Re: Seeking Comcast Contact: need to troubleshoot packet loss and/or asymmetric routing issue between Comcast & Onvoy. A good Comcast contact (thanks!) and some interesting (but, as it turns out, irrelevant) discussion of ICMP and PMTU ensued. Current situation: We now know that all packets from all Comcast ranges make it to Carleton (137.22/16) and St Olaf (130.71/16) just fine. But we are seeing 30-80% packet loss on the paths (multiple) from both Carleton and St Olaf to certain Comcast ranges only. The size of the packets does not seem to matter. We pursued the PMTU wild goose, and a few others, based on the observation that SYNs appeared to get through, but data packets did not. In reality, multiple SYNs are also being lost. Recently, we observed that packets sent from the interior IP address of our border router, 137.22.69.254, are able to get to Comcast fine. But traffic sent from any other source IP address in 137.22/16 fails. Outbound traceroutes (Carleton to Comcast) show that the "good" networks take an AT&T outbound hop, while the "bad" networks go through level3. Inbound traceroutes (Comcast to Carleton) always seem to go through AT&T. 137.22.69.254 137.22.69.253 71.63.168.1 good (level3) BAD (level3) 71.63.244.1 good (level3) BAD (level3) 74.19.4.1 good (AT&T) good (AT&T) Wild card: It might be relevant that Carleton was previously a UUNET customer, and that 137.22.69.254 was an IP address known to UUNET as a demarc point to be monitored. Maybe someone at UUNET failed to clear some filters some years ago, when we shut off our old T1. Complications: Onvoy has agreed to be sold to Zayo Bandwidth, http://www.startribune.com/154/story/1378026.html; the technician with whom we are working at Onvoy appears to be proud of his A+ certification; and we are in a semi-rural market with no short-term alternative for Internet service, and freshmen arriving in one week. Help! Here's how St Olaf sees the world. 71.63.168.1 is a "bad" address, > 50% packet loss. 73.112.232.1 is a "good" address, 0% loss. cisco7200#show ip bgp sum BGP router identifier 130.71.196.25, local AS number 21951 BGP table version is 31337554, main routing table version 31337554 224927 network entries using 26316459 bytes of memory 245363 path entries using 12758876 bytes of memory 44821/40648 BGP path/bestpath attribute entries using 5557804 bytes of memory 37918 BGP AS-PATH entries using 1026100 bytes of memory 516 BGP community entries using 18954 bytes of memory 1 BGP extended community entries using 24 bytes of memory 0 BGP route-map cache entries using 0 bytes of memory 0 BGP filter-list cache entries using 0 bytes of memory BGP using 45678217 total bytes of memory 11380 received paths for inbound soft reconfiguration BGP activity 1786406/1561479 prefixes, 3731508/3486145 paths, scan interval 60 secs Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 137.192.32.173 4 5006 9156558 2056473 31337549 0 0 23w6d 222602 192.42.152.218 4 57 3531028 478950 31337541 0 0 1d10h 11380 cisco7200#show ip bgp neighbors 137.192.32.173 routes | include 13367 * 24.31.0.0/19 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 24.118.0.0/18 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i * 24.118.0.0/16 137.192.32.173 0 5006 3549 3356 13367 13367 13367 13367 13367 13367 i *> 24.118.64.0/18 137.192.32.173 0 5006 3549 3356 13367 13367 13367 13367 i *> 24.118.128.0/19 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 24.118.160.0/19 137.192.32.173 0 5006 3549 3356 13367 13367 13367 13367 i *> 24.118.192.0/18 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 24.131.128.0/18 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 24.245.0.0/19 137.192.32.173 0 5006 3549 3356 13367 13367 13367 13367 i * 24.245.0.0/18 137.192.32.173 0 5006 7018 13367 13367 13367 13367 13367 i *> 24.245.32.0/19 137.192.32.173 0 5006 3549 3356 13367 13367 13367 13367 i * 24.245.64.0/20 137.192.32.173 0 5006 3549 3356 13367 13367 13367 13367 i *> 66.41.0.0/18 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i * 66.41.0.0/16 137.192.32.173 0 5006 3549 3356 13367 13367 13367 13367 13367 13367 i *> 66.41.64.0/18 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 66.41.128.0/18 137.192.32.173 0 5006 3549 3356 13367 13367 13367 13367 i *> 66.41.192.0/18 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 67.178.48.0/23 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i * 67.190.192.0/19 137.192.32.173 0 5006 7018 13367 13367 13367 13367 13367 i * 67.190.224.0/19 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 68.86.46.0/24 137.192.32.173 0 5006 3549 3356 13367 13367 13367 13367 i *> 68.86.200.0/23 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 68.86.232.0/22 137.192.32.173 0 5006 3549 3356 13367 13367 13367 13367 i *> 68.87.14.0/24 137.192.32.173 0 5006 3549 3356 13367 13367 13367 13367 i *> 68.87.174.0/23 137.192.32.173 0 5006 3549 3356 13367 13367 13367 13367 i *> 68.87.176.0/22 137.192.32.173 0 5006 3549 3356 13367 13367 13367 13367 i * 69.180.128.0/18 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 69.240.52.0/22 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 69.240.56.0/24 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 69.240.212.0/23 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 69.240.244.0/24 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 69.240.245.0/24 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 69.241.77.0/24 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 69.241.114.0/24 137.192.32.173 0 5006 3549 3356 13367 13367 13367 13367 i * 70.89.196.0/22 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i * 70.89.200.0/22 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 70.90.76.0/22 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 70.91.176.0/22 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 71.63.128.0/17 137.192.32.173 0 5006 3549 3356 13367 13367 13367 13367 i * 71.193.64.0/19 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 71.195.0.0/18 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 73.112.0.0/14 137.192.32.173 0 5006 3549 3356 13367 13367 13367 13367 i *> 73.127.0.0/16 137.192.32.173 0 5006 3549 3356 13367 13367 13367 13367 i *> 73.205.0.0/16 137.192.32.173 0 5006 3549 3356 13367 13367 13367 13367 i *> 73.236.0.0/15 137.192.32.173 0 5006 3549 3356 13367 13367 13367 13367 i *> 74.18.0.0/20 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 74.19.0.0/19 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 74.24.192.0/19 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 74.30.0.0/18 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 74.31.224.0/19 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 74.93.24.0/22 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 74.94.80.0/21 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 74.95.64.0/22 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 74.95.70.0/23 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 74.95.100.0/22 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 74.95.140.0/22 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 74.146.192.0/18 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 74.147.224.0/19 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 75.72.0.0/17 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 75.72.0.0/15 137.192.32.173 0 5006 3549 3356 13367 13367 13367 13367 13367 13367 i *> 75.72.128.0/17 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 75.73.0.0/17 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 75.73.128.0/17 137.192.32.173 0 5006 3549 3356 13367 13367 13367 13367 i *> 75.144.36.0/22 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 75.146.32.0/20 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 76.17.128.0/17 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 76.113.128.0/19 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 76.113.160.0/19 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 76.113.192.0/19 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 76.113.224.0/19 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 76.133.0.0/19 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 76.133.0.0/17 137.192.32.173 0 5006 3549 3356 13367 13367 13367 13367 13367 13367 i *> 76.133.32.0/19 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 76.133.64.0/19 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 76.133.96.0/19 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 76.154.0.0/19 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 76.154.0.0/17 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 76.154.32.0/19 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i *> 76.154.64.0/19 137.192.32.173 0 5006 7018 13367 13367 13367 13367 13367 i *> 76.154.96.0/19 137.192.32.173 0 5006 7018 13367 13367 13367 13367 13367 i *> 209.162.0.0/18 137.192.32.173 0 5006 7018 13367 13367 13367 13367 i cisco7200#show ip bgp neighbors 192.42.152.218 routes | include 13367 *> 24.31.0.0/19 192.42.152.218 110 0 57 13367 i *> 24.118.0.0/16 192.42.152.218 110 0 57 13367 i *> 24.245.0.0/18 192.42.152.218 110 0 57 13367 i *> 24.245.64.0/20 192.42.152.218 110 0 57 13367 i *> 66.41.0.0/16 192.42.152.218 110 0 57 13367 i *> 67.190.192.0/19 192.42.152.218 110 0 57 13367 i *> 67.190.224.0/19 192.42.152.218 110 0 57 13367 i *> 69.180.128.0/18 192.42.152.218 110 0 57 13367 i *> 70.89.196.0/22 192.42.152.218 110 0 57 13367 i *> 70.89.200.0/22 192.42.152.218 110 0 57 13367 i *> 71.193.64.0/19 192.42.152.218 110 0 57 13367 i cisco7200#sho ip bgp 71.63.168.1 BGP routing table entry for 71.63.128.0/17, version 31179174 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 5006 3549 3356 13367 13367 13367 13367 137.192.32.173 from 137.192.32.173 (172.30.0.5) Origin IGP, localpref 100, valid, external, best Community: 328073238 cisco7200#sho ip bgp 73.112.232.1 BGP routing table entry for 73.112.0.0/14, version 31179171 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer 5006 3549 3356 13367 13367 13367 13367 137.192.32.173 from 137.192.32.173 (172.30.0.5) Origin IGP, localpref 100, valid, external, best Community: 328073238 -- Rich Graves http://claimid.com/rcgraves Carleton.edu Sr UNIX and Security Admin CMC135: 507-646-7079 Cell: 952-292-6529

2 2

Comcast routing issues in Houston?
by Geoffrey Pan 29 Aug '07

29 Aug '07

Anyone seeing things like this when routing out from Comcast to Hostway? We're seeing total packet loss going out to 66.232.159.0/24 (i.e. www.powermedium.com) and others (8.6.221.0/24 also) If someone at Comcast can check on this would be appreciated.. |------------------------------------------------------------------------------------------| | WinMTR statistics | | Host - % | Sent | Recv | Best | Avrg | Wrst | Last | |------------------------------------------------|------|------|------|------|------|------| | 73.208.60.1 - 0 | 1 | 1 | 0 | 0 | 0 | 0 | | 68.85.249.189 - 0 | 1 | 1 | 16 | 16 | 16 | 16 | | 68.85.244.133 - 0 | 1 | 1 | 0 | 0 | 0 | 0 | | 68.85.244.130 - 0 | 1 | 1 | 16 | 16 | 16 | 16 | | 68.85.244.153 - 0 | 1 | 1 | 0 | 0 | 0 | 0 | | 4.79.90.93 - 0 | 1 | 1 | 0 | 0 | 0 | 0 | | - 100 | 1 | 0 | 0 | 0 | 0 | 0 | Routing seems to be dying at the level 3 handover Geoffrey Pan

1 0

Anyone from live.com or hotmail around here?
by Drew Weaver 29 Aug '07

29 Aug '07

I've been having a very hard time getting a simple question answered from your postmaster tech support, please hit me off-list. Thanks, -Drew

4 3

Congestion between NY and Ashburn on Teleglobe ?
by W. Kevin Hunt 28 Aug '07

28 Aug '07

Anyone else seeing congestion / high latency between New York and Ashburn on Teleglobe ? We've been seeing an extra 50-80ms of latency between the two on and off throughout the day... 7. 216.140.15.158 1.1% 34.1 40.0 33.9 143.4 19.3 G1-1.rp0.chcg.broadwing.net 216.140.14.110 G2-3.rp0.chcg.broadwing.net 8. s0-3-3.core1.chi.foc.broadwing.net 0.0% 34.7 34.2 33.9 35.0 0.3 9. if-0-1-0.core2.NTO-NewYork.teleglobe.net 0.0% 49.4 52.1 49.4 99.3 8.6 --- all fine to here, then we hit Ashburn --- 10. if-1-0-0.core3.AEQ-Ashburn.teleglobe.net 0.0% 163.5 170.7 137.7 197.2 11.8 11. ix-3-0-9.core3.AEQ-Ashburn.teleglobe.net 0.0% 156.6 163.1 129.5 242.4 15.2 12. ge-1-0-0-p407.msr2.ac2.yahoo.com 0.0% 155.7 161.3 124.3 187.5 12.6 ge-0-0-0-p205.msr1.ac2.yahoo.com

1 0

"2M today, 10M with no change in technology"? An informal survey.
by David Conrad 28 Aug '07

28 Aug '07

Hi, In another mailing list, someone has asserted that "noone believes router vendors who say [they can support 2M routes today and 10M with no change in technology]". Or perhaps more accurately, the router vendors claiming this are being a bit disingenuous in that while it is possible routers can handle this many static routes, they'll quickly fall down if they were subjected to real world dynamic conditions ISPs would see if you extrapolate routing flux in today's tables up to (say) 2M routes. My questions: Do you believe router vendors who state they today have "capacities on the order of 2 million ipv4 routes and they have no reason to expect that they couldn't deliver 10 million route FIB products in a few years given sufficient demand."? If you do not (or you believe the router vendors are being disingenuous) and routing system growth continues: - where do you believe existing routing technology will fall down? - what steps will you take/are you taking to limit your vulnerability? Feel free to respond privately if you don't feel comfortable discussing this in a public forum. I promise to hold any responses confidential, publishing only a summary of responses. Thanks, -drc

10 11

SNMP Trap Alarm?
by Deepak Jain 28 Aug '07

28 Aug '07

Ok, I could have picked a better title. I'm looking for a pointer to a box (pref. an embedded platform of some kind) that will receive/accept SNMP traps and sound a real world alarm/siren/klaxon. It can do fancy things like logging and such, but not strictly required. I could build one, but I'd rather have something OTS. Thanks in advance, Deepak

2 1

RE: IPv6 network boundaries vs. IPv4
by John van Oppen 27 Aug '07

27 Aug '07

We did the same thing... It seems easiest from a management perspective to copy the ipv4 logical layer with v6. The only change on our side was the fixed prefix length which if anything was a nice change. We did run into a few devices (old layer 3 switches) that don't support ipv6 and on those we either did not deploy IPv6 or moved the routing off for both v4 and v6 to the nearest "core" router that could handle v6 for any vlans that required the v6 capability. John van Oppen Spectrum Networks LLC 206.973.8302 (Direct) http://spectrumnetworks.us -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Valdis.Kletnieks(a)vt.edu Sent: Monday, August 27, 2007 10:25 AM To: John Osmon Cc: nanog(a)merit.edu Subject: Re: IPv6 network boundaries vs. IPv4 On Sat, 25 Aug 2007 23:56:29 MDT, John Osmon said: > > Is anyone out there setting up routing boundaries differently for > IPv4 and IPv6? I'm setting up a network where it seems to make > sense to route IPv4, while bridging IPv6 -- but I can be talked > out of it rather easily. We decided to map our IPv6 subnets one-to-one to our IPv4, so each of our routed /22 to /27 subnets gets a /64 IPv6 prefix. This however was just due to the fact that our topology permitted that - your mileage may vary.

3 2

Operational Feedback Requested on Pending Standard
by Ted Seely 27 Aug '07

27 Aug '07

All, Below is an email sent to the IETF OPS Area mailing list soliciting feedback from operators regarding firewalls. We would also appreciate feedback from the Operators Mailing Lists. Please respond to the OPS Area mailing list if you have a position on the item below. You can subscribe to the Operations and Management Area mailing list at the URL below if you are not already subscribed. https://www.ietf.org/mailman/listinfo/ops-area On behalf of the OPS Area Directors and myself, thank you. Ted - With OPS Area WG Hat On -------------------------------------------------------------- During the final review phases of the review of http://www.ietf.org/internet-drafts/draft-ietf-midcom-mib-09.txt the issue described below surfaced. It is actually not completely new, it was discussed in the past in a form or another, and it is not necessarily specific to this document and MIB module only, but also to other MIB modules. We believe that input from network operators can help, and we solicit this input. The MIDCOM-MIB defines tables containing firewall rules, indexed by ifIndex. ifIndex values can change when interfaces are swapped or devices reboot, and this could lead to rules being applied to the wrong interface. How do you, network operators, prefer interfaces be identified? - Is ifIndex the preferred choice even though the indices can change on reboot? - Is ifName a better choice for identifying interfaces in rules, since it is set by the device and remains fairly stable across reboots and is guaranteed to be unique? - is ifAlias a better choice, since it can be set by operators, although it is not guaranteed to be unique? We would appreciate inputs and thank you for your cooperation.

2 1

IPv6 network boundaries vs. IPv4
by John Osmon 27 Aug '07

27 Aug '07

Is anyone out there setting up routing boundaries differently for IPv4 and IPv6? I'm setting up a network where it seems to make sense to route IPv4, while bridging IPv6 -- but I can be talked out of it rather easily. Years ago, I worked on a academic network where we had a mix of IPX, DECnet, Appletalk, and IP(v4). Not all of the routers actually routed each protocol -- DECnet wasn't routable, and I recall some routers that routed IPX, while bridging IP... This all made sense at the time -- there were IPX networks that needed to be split, while IP didn't need to be. DECnet was... DECnet -- and Appletalk was chatty, but useful. I keep hearing the mantra in my head of: "I want my routers to route, and my switches to switch." I agree wholeheartedly if there is only one protocol -- but with the mix of IPv4 and IPv6, are there any folks doing things differently? With a new protocol in the mix are the lessons of the last 10 (or so) years not as clear-cut?

7 7