August 2007 - Test - lists.nanog.org

Re: "2M today, 10M with no change in technology"? An informal survey.
by Brandon Butterworth 30 Aug '07

30 Aug '07

> 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]". Haven't we gone over the CPU speed argument recently enough? > 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."? Pointless argument, wait and see as it doesn't matter. If they do then we're fine. If they don't then we won't have that many routes so it won't be a problem. > - where do you believe existing routing technology will fall down? If people sit watching the train crash rather than take avoiding action > - what steps will you take/are you taking to limit your vulnerability? As long as I can afford as big a RP as the next ISP we're fine. brandon

21 43

How to get help from your ISP for security problems
by Sean Donelan 30 Aug '07

30 Aug '07

I'm used to the fingerpointing, but I was amazed when I met a lot of security researchers which didn't seem to know about all the different things ISPs are doing to help customers avoid having their computers compromised by intrusions and repairing their computers afterwards. So I started putting together a web page of paid and free ISP security support links. If you are a national or large regional ISP in the US, send me your link and I'll add it. <http://www.donelan.com/ispsupport.html> Note: I haven't said how to get help from some other ISP.

3 3

Re: An informal survey... round II
by William Herrin 30 Aug '07

30 Aug '07

On 8/30/07, John Curran <jcurran(a)mail.com> wrote: > I.E. If at some time unknown around 2010, ISP's stop receiving > new allocations from their RIR, and instead use of many smaller > "recycled" IPv4 address blocks, we could be looking at a 10x to > 20x increase in routes per month for the same customer growth. John, Why should we announce tiny recycled blocks? If there is a /16 in the swamp in which half the space is free but its all /24's, why wouldn't wouldn't we allocate all the free /24's to a single entity and instruct the entity to announce it as a "holey" /16? The existing /24 holders will override (punch holes in) the /16 for their /24's. Regards, Bill Herrin -- William D. Herrin herrin(a)dirtside.com bill(a)herrin.us 3005 Crane Dr. Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004

10 11

RE: An informal survey... round II
by michael.dillon＠bt.com 30 Aug '07

30 Aug '07

> > Considering > > Verizon's highly-connected position at the core of the IPv4 > Internet, > > I would think that all it takes to cause a snowball effect, is for > > Verizon to start offering IPv6 transit and peering on the > same terms > > as IPv4. If there is any company whose IPv6 plans we should be > > interested in, it is Verizon. > I believe that your sales peoples should know how to make > this happen for you, if not please ping the Customer Service > folk who would also be able to make some progress on this > issue for you. Issue? It was more of an observation than an issue. Based on the CAIDA Internet connectdness maps which show AS701 as the most connected AS in the core of the Internet, combined with other Verizon networks, it seems to me that Verizon's progress is the most interesting to watch. When Verizon has full availability of IPv6 access (all ASes, all PoPs) then I see that as a tipping point. --Michael Dillon

1 0

Anyone from global crossing on list?
by Drew Weaver 30 Aug '07

30 Aug '07

Had an incident last night and need some "clarification" support has been less than.. supportive. Thanks, -Drew

1 0

Re: An informal survey... round II
by Brandon Butterworth 30 Aug '07

30 Aug '07

> Is there a possible revenue stream here for larger ISP's to begin > charging their customers for not aggregating or to pay a clearing house to reaggregate them, mutual trades so you can accumulate enough of a block, approach current (non)users of space and buy out to build blocks they can sell If we hit the limits a possible outcome is larger blocks will sell for more per address than smaller as there'll be lots of people filtering on arbitrary rules. Time to standardise how the pain will be applied now? brandon

1 0

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 28 Aug '07

28 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