- NANOG - lists.nanog.org

The Cidr Report
by Tony Bates 07 Apr '01

07 Apr '01

This is an auto-generated mail on Fri Apr 6 23:00:00 PDT 2001 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 06Apr01 0) General Status Table History ------------- Date Prefixes 300301 98619 310301 98637 010401 98847 020401 98771 030401 98768 040401 98995 050401 99092 060401 99382 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 91.16.23.0/24 from AS11770 AS Summary ---------- Number of ASes in routing system: 10427 Number of ASes announcing only one prefix: 6119 (3475 cidr, 2644 classful) Largest number of cidr routes: 945 announced by AS705 Largest number of classful routes: 1594 announced by AS1221 1) Gains by aggregating at the origin AS level --- 06Apr01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1594 1193 401 25.2% Telstra Pty Ltd AS701 1469 1288 181 12.3% UUNET Technologies, Inc. AS8013 574 462 112 19.5% PSINet Ltd. Canada AS6429 215 103 112 52.1% RdC Internet AS6595 165 63 102 61.8% DoD Education Activity Network As AS705 343 245 98 28.6% UUNET Technologies, Inc. AS13999 104 8 96 92.3% Mega Cable S.A. de C.V. AS4151 242 148 94 38.8% USDA AS4293 373 280 93 24.9% Cable & Wireless USA AS7018 674 591 83 12.3% AT&T AS4755 207 126 81 39.1% Videsh Sanchar Nigam Ltd. Autonom AS577 241 172 69 28.6% Bell Advanced Communications Inc. AS5106 101 37 64 63.4% Ameritech Advanced Data Services, AS9498 80 17 63 78.8% BHARTI BT INTERNET LTD. AS3464 153 91 62 40.5% Alabama SuperComputer Network AS3749 121 60 61 50.4% Tennessee Board of Regents AS724 211 151 60 28.4% DLA Systems Automation Center AS11252 92 34 58 63.0% ISU Computer Center Bldg. 5 AS16758 63 6 57 90.5% IKON Office Solutions AS6413 67 11 56 83.6% Southern Online Systems, Inc. AS376 134 78 56 41.8% Reseau Interordinateurs Scientiqu AS226 148 92 56 37.8% Los Nettos AS7568 84 29 55 65.5% C.S. Communications Co., Ltd. AS1 608 553 55 9.0% BBN Planet AS4323 230 176 54 23.5% Time Warner Communications, Inc. AS6471 99 46 53 53.5% ENTEL CHILE S.A. AS17561 110 59 51 46.4% Internet service provision to Wes AS9269 113 64 49 43.4% City Telecom (H.K.) Ltd. AS174 417 368 49 11.8% PSINet Inc. AS1237 107 58 49 45.8% System Engineering Research Insti For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

1 0

Invite WHO?
by David Lesher 07 Apr '01

07 Apr '01

This is OT, perhaps way OT, but maybe not.... I'm back from ISPCON in B'more, and while it had the usual show swag, etc, there was one highly useful tract. The Regulatory track has participation from multiple FCC staffers from all across the agency; Regulatory, Common Carrier, Wireless, and others. Associates found it highly worthwhile. a) It was possible because it was local. Let me explain something that those of you with no USG experience may just not grok. It's REALLY hard to get travel money. All kinds of justifications for hotels are needed. Congress looks askew at anyone (err anyone ELSE, as their junkets are always work related...) going anywhere on Uncle Sam's nickel. But local mileage is easy. Overnight? Ferrget it. b) Like it or not, more & more of "the Internet business" is in the FCC's eyesight. That's NOT to say they now regulate this, that or the other - or that they can solve the Northpoint/TW/ whatever. But they are learning lots. And the HillCritters often call to ask them questions. It's to your benefit for them to know your side. Dave Farber just spent a year there as Chief Technologist. He was the first NetHead in that role, a traditional Bellboy slot. I think you'll find he thinks it time in his life well-spent. So my points: If organizing a symposium of any sort in the DC region; look into both having FCC (& other agency) panels, and inviting staffers. Participate in the process. There's more to our (abiet flawed) democracy than creating hanging chad on that Tuesday in Nov. You'd be surprised how much effect ONE person/ISP can have.... We now return to Sean's Favorite Fiber FUBAR's, already in progress. -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

1 0

Inflow?
by Timothy Brown 07 Apr '01

07 Apr '01

Can anyone who has used Inflow for collocation please contact me privately off-list? Thanks, Tim

1 0

Re: C&W routing instability
by James A. Farrar 06 Apr '01

06 Apr '01

A configuration error occurred which permitted improper route announcements from one of our downstream customers to be propagated. We immediately identified the issue and took immediate action to correct the situation. We apologize for the inconvenience this may have caused. Regards, Jim Farrar C&W Global Operations

1 0

AOL power problems yesterday
by Sean Donelan 06 Apr '01

06 Apr '01

What I've gathered so far is AOL was performing maintenance on part of its UPS system when a power surge/sag affected part of Loudoun County where AOL is located. Since AOL's peak usage is in the evening and late night, it is normal for them to perform maintenance during the "low-use" time period during the day. You are also more likely to get the "best" vendor support during the day. Parts of two computer rooms in one of AOL's data centers were knocked off-line for a minute or two. Several hundred individual servers needed to be rebooted. This affected parts of several AOL services such as Instant Messenger, e-mail, web searching. There were three different power anomolies in Northern Virginia yesterday. Normally an external event like a power failure, surge, or sag is handled by combinations of filters, upses, isolation transformers and generators. Its is relatively rare for an external event to cause problems in a top-level data center. I sent mail to AOL asking if I had the basic facts correct, but haven't heard back from them.

1 0

C&W routing instability
by Timothy Brown 06 Apr '01

06 Apr '01

Can anyone confirm routing instability and/or huge path leakage from C&W? I'm hearing reports of this and seeing general instability/loss, but the route servers aren't showing anything funny. Thanks, Tim

4 4

PG&E files for chapter 11
by Zaid Ali 06 Apr '01

06 Apr '01

Folks, PG&E files for chapter 11. http://www.sfgate.com/cgi-bin/article.cgi?file=/news/archive/2001/04/06/stat e1333EDT0194.DTL ------------------------------------------ Zaid Ali Network Architect WebEx Communications 110 Rose Orchard Way San Jose, CA 95134 Tel: 408-435-7251 fax: 408-435-7004 www.webex.com ----------------------------------------

2 1

RE: Possible IOS bug w/respect to incorrect nexthop advert
by Martin, Christian 06 Apr '01

06 Apr '01

I've seen this happen with Juniper peers, but not with Cisco. It is definitely a bug. chris > -----Original Message----- > From: John Fraizer [mailto:nanog@Overkill.EnterZone.Net] > Sent: Friday, April 06, 2001 2:47 PM > To: nanog(a)merit.edu > Subject: Possible IOS bug w/respect to incorrect nexthop advert > > > > > One of our peers recently upgraded to IOS to: > > Cisco Internetwork Operating System Software > IOS (tm) RSP Software (RSP-PV-M), Version 12.1(4)E, EARLY DEPLOYMENT > RELEASE SOFTWARE (fc1) > Copyright (c) 1986-2000 by cisco Systems, Inc. > Compiled Tue 07-Nov-00 14:23 by eaarmas > Image text-base: 0x60010958, data-base: 0x60F7C000 > > ROM: System Bootstrap, Version 11.1(8)CA1, EARLY DEPLOYMENT RELEASE > SOFTWARE (fc1) > BOOTFLASH: RSP Software (RSP-BOOT-M), Version 12.1(4)E, EARLY > DEPLOYMENT > RELEASE SOFTWARE (fc1) > > > > Ever since this upgrade, we've been seeing the following behavior: > > When they announce prefixes to us, sometimes they get it > right, as in, the > nexthop is set correctly and sometimes they get it wrong as > in, the cisco > picks a random address from it's configured addresses and sends the > nexthop as that address. > > Example getting it right: > > 2001/04/06 13:51:42 BGP: 209.115.127.21 rcvd UPDATE w/ attr: > nexthop 209.115.127.21, origin i, path 6259 6461 11042 8390 8431 > 2001/04/06 13:51:42 BGP: 209.115.127.21 rcvd 195.230.6.0/24 > 2001/04/06 13:51:42 BGP: 209.115.127.21 rcvd 195.230.7.0/24 > > > Examples getting it wrong: > > 2001/04/06 13:52:10 BGP: 209.115.127.21 rcvd UPDATE w/ attr: > nexthop 216.28.125.77, origin i, path 6259 3549 701 7871 > 2001/04/06 13:52:10 BGP: 209.115.127.21 rcvd UPDATE about > 206.162.212.0/22 -- DENIED due to: non-connected next-hop; > > 2001/04/06 13:57:57 BGP: 209.115.127.21 rcvd UPDATE w/ attr: > nexthop 216.28.126.221, origin i, path 6259 7018 14046 14046 > 2001/04/06 13:57:57 BGP: 209.115.127.21 rcvd UPDATE about > 216.241.140.0/23 -- DENIED due to: non-connected next-hop; > > > > This behavior began when the peer upgraded their IOS. > > Is this a documented issue or has anyone else seen this behavior? > > --- > John Fraizer > EnterZone, Inc > > >

1 0

CWI/ATT Peering in NYC
by Jeffrey Meltzer 06 Apr '01

06 Apr '01

FYI's, AT&T and Cable & Wireless are experiencing latency on their peering in NYC, ranging from 200ms to 1200ms. Both NOC's have acknowledged the issue and neither have an ETA. JEFF -- Jeffrey Meltzer VillageWorld.com, Inc. Voice 631-218-9090 620 Johnson Ave JFAX 516-977-3009 Bohemia, NY 11716

1 1

Sharing power quality data
by Sean Donelan 06 Apr '01

06 Apr '01

Last year, about this time, I asked if there was any interest in sharing power quality data. Whether it is Northern Virginia, or Silicon Valley, a lot of us drink from the same power pond. Its not so much a competitive matter, as bad power will make all of us sick. Internally we all have UPSes, generators, flywheels, etc. but we all get utility power from the same grid. Most of us collect a lot of data with power quality meters from our point of view of the utility grid. But since none of us share information, none of us really knows what the whole picture looks like. A few miles a way the major regional power outage may show up us just a blip in the data. And unless you were looking specifically for it, you might not have noticed. Nevertheless, the additional data might help with the analysis, if you knew who to ask to get it. AOL has one of the best designed, built and operated data centers in the world. Everyone I know who has ever seen it has been very impressed. It would take a remarkable event to affect AOL's operation. But we are always building based on the last earthquake, or the last hurricane or the last power problem. So we learn every time the extraordinary happens. Other data centers may use a very similar power design, so the extraordinary is very much of interest. Who knows, another data center might have already had the similar problem and found a fix.

2 1