- Test - lists.nanog.org

The Cidr Report
by Tony Bates 01 Oct '99

01 Oct '99

This is an auto-generated mail on Fri Oct 1 12:00:00 PDT 1999 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 01Oct99 0) General Status Table History ------------- Date Prefixes 060999 63135 070999 63155 080999 62994 270999 64154 280999 63958 290999 64074 300999 64030 011099 64019 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 5723 Number of ASes announcing only one prefix: 2996 (1637 cidr, 1359 classful) Largest number of cidr routes: 556 announced by AS701 Largest number of classful routes: 910 announced by AS701 1) Gains by aggregating at the origin AS level --- 01Oct99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 383 146 237 61.9% BCnet Backbone AS2609 127 13 114 89.8% EUnet-TN AS1221 585 478 107 18.3% TELSTRA-AS AS9269 128 28 100 78.1% Hong Kong CTI AS174 589 494 95 16.1% Performance Systems International AS7046 337 250 87 25.8% UUNET-CUSTOMER AS4293 228 142 86 37.7% Internal ASN for C&W AS577 263 178 85 32.3% Bell Canada Backbone AS7545 141 61 80 56.7% TPG Internet Pty Ltd AS7657 244 167 77 31.6% The Internet Group Limited AS7496 109 33 76 69.7% Power Up AS6944 92 16 76 82.6% RapidSite, Inc. AS3749 139 64 75 54.0% TECNET AS4200 181 109 72 39.8% AGIS (Apex Global Information Ser AS719 464 408 56 12.1% LANLINK autonomous system AS4740 342 288 54 15.8% Ozemail Pty Ltd (ASN-OZEMAIL) AS2493 138 91 47 34.1% iSTAR Internet, Inc. AS684 92 46 46 50.0% Manitoba Regional Network Backbon AS209 296 250 46 15.5% Qwest Communications AS6528 45 7 38 84.4% WORLD-LYNX AS549 200 162 38 19.0% ONet Backbone AS4755 112 76 36 32.1% Videsh Sanchar Nigam Ltd. India AS3737 99 66 33 33.3% PenTeleData Inc. (ASN-PTD) AS701 910 878 32 3.5% Alternet AS9453 33 2 31 93.9% Soongsil University AS7745 40 9 31 77.5% BIGSKY-AS AS4307 32 1 31 96.9% SVINET-1 AS1785 234 203 31 13.2% NYSERNet Backbone AS10479 40 9 31 77.5% ITESM-Rectoria Zona Norte AS1 489 458 31 6.3% GTE Internetworking 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

fiber cut in slc
by Christian Nielsen 01 Oct '99

01 Oct '99

Looks like another fiber cut. This one in SLC. Since this is a MFS cut, I bet this is the reason UU is seeing issues on their network. Christian (who will be in SLC in a few hours :)

1 0

C&W
by Morris Allen 01 Oct '99

01 Oct '99

Anyone else having Noc's problems with Cable & Wireless? They are killing us. thanks Morris Allen VidcomNet, Inc.

1 0

Interesting multiple OSPF area dilemma
by Dustin Clampitt 01 Oct '99

01 Oct '99

Greetings: I seek input on a decision I must make regarding using multiple areas in a network using OSPF as the IGP. I have reviewed the NANOG archive messages regarding OSPF hierarchy, KISS principle, OSPF design, etc., but I'd still enjoy some feedback. * We have an existing nationwide network all carried by a single ATM carrier. (Carrier "A") * The network is flat. Everything is area 0.0.0.0. Currently less than 1000 OSPF route table entries. * We are expanding the network via a second carrier. (Carrier "B") * As we do more business with the new carrier "B" we expect to swing cities currently on the "A" network over to the "B" network. * I have a fresh /18 from ARIN to apply to the build out with new Carrier "B" * Both networks will tie into the same hubs on the east and west coasts. The questions are: 1. Do I even consider creating a second area "1" for the new network? I don't have a huge number of routers, or routes, yet. Our existing address space is highly fragmented for various reasons, but that doesn't mean we shouldn't attempt to inject some order to the network as we move forward. 2. If we are successful in moving all business away from existing carrier "A" then we have to create a new area 0. That puts us in the position of having to put interfaces linking cities into the new area 0, while each city then has to have a unique new area for the "local" interfaces. I don't even want to think about virtual link games as I'm a big believer in the KISS principle. (I'm lazy, and I don't expect to be the one supporting this forever.) How do I move area 0? I suppose I could start by putting all inter-city links in the new network in area 0, but then right off the bat I have 2 OSPF areas in every new city. That seems to be counter to much that I've read. I expect the vast majority of "local" interfaces to be stub areas anyway. 3. Are any gains in route aggregation and fault tolerance offset by: * the additional "cost" of complexity * additional CPU load necessary to process multiple areas? More Gory details: Existing network "A": * East Coast hub with transit via UUNET * West Coast hub with transit via SAVVIS * 16 Satellite cities. Each city is dual homed to East/West Coast Hubs via ATM * 2 dozen routers in network. * Currently less than 1000 OSPF routes all in area 0. * BGP4 as the I/EBGP New network "B" * connects to same east/west coast hubs as network "A" * we have a fresh /18 to apply to this buildout --- I apologize for turning the list into OSPF design 101. It seems to me to be apropos and an interesting dilemma that may be faced by others who inherit a network that grew without benefit of a master plan. Actually, in deference to those list readers who I know at one time were formerly involved with this network, I'm sure there was a plan, but it was lost before I got here. And 2.5 years ago I probably wouldn't have recognized it if it came up and bit me on the butt. I could just punt, and put it all in area 0, but I just had to ask. Sincerely, Dustin Clampitt

3 2

Martian list of IP's to block???
by John M. Brown 01 Oct '99

01 Oct '99

working on a document and was wondering if people could provide the various versions of the Martian list that is used... thanks

1 0

Massive fiber cut ??
by Jesper Skriver 30 Sep '99

30 Sep '99

Hi, Is there a massive fiber cut, or what ? >From what I can see both above and bbnplanet has problems between the east and west cost ... traceroute to www.above.net (207.126.96.163), 30 hops max, 40 byte packets 1 eth9-0-0.sltnxt2.ip.tele.dk (193.162.159.76) 0.852 ms 0.579 ms 0.521 ms 2 feth5-0-0.sltnxt1.ip.tele.dk (195.249.2.26) 0.775 ms 0.789 ms 0.664 ms 3 atm1-0-3.kd4nxi1.ip.tele.dk (195.249.2.21) 4.470 ms 3.098 ms 4.514 ms 4 ser4-0.45M.linxnxi1.ip.tele.dk (195.41.41.246) 23.299 ms 23.213 ms 25.149 ms 5 linx.london.above.net (195.66.224.76) 38.534 ms 71.093 ms 26.651 ms 6 nyc-lhr-stm-1.nyc.above.net (209.249.0.106) 92.307 ms 91.116 ms 91.575 ms 7 iad-nyc-oc12-1.iad.above.net (209.249.203.49) 94.735 ms 94.857 ms 96.739 ms 8 pao-iad-oc3.pao.above.net (207.126.96.145) 1072.156 ms 1054.131 ms * 9 * sjc-pao-oc12-2.sjc2.above.net (207.126.96.66) 1069.846 ms * 10 main1-core5.sjc.above.net (209.133.31.134) 669.436 ms 687.632 ms 680.923 ms 11 www.above.net (207.126.96.163) 663 ms 676.565 ms 682.928 ms traceroute to cio-sys.cisco.com (192.31.7.130), 30 hops max, 40 byte packets 1 eth9-0-0.sltnxt2.ip.tele.dk (193.162.159.76) 1.101 ms 0.544 ms 0.505 ms 2 atm1-0-72.kd4nxi2.ip.tele.dk (195.249.7.89) 5.675 ms 5.629 ms 5.967 ms 3 atm1-0-76.boanxt1.ip.tele.dk (195.249.7.106) 11.058 ms 9.940 ms 9.957 ms 4 feth4-0-0.boanxi2.ip.tele.dk (195.249.5.202) 11.139 ms 10.210 ms 10.337 ms 5 pos1-0-0.155M.NewYorknxi2.ip.tele.dk (195.249.5.190) 88.229 ms 86.665 ms 86.373 ms 6 s4-0-1.nyc4-cr5.bbnplanet.net (4.1.78.5) 94.553 ms 92.325 ms 87.544 ms 7 p3-3.nyc4-nbr3.bbnplanet.net (4.0.3.162) 87.342 ms 86.945 ms 86.760 ms 8 p2-1.chicago1-nbr1.bbnplanet.net (4.0.3.121) 1213.229 ms 1243.234 ms 1244.851 ms 9 p2-1.paloalto-nbr2.bbnplanet.net (4.24.7.18) 1560.060 ms 1594.888 ms 1578.081 ms 10 p0-0-0.paloalto-cr18.bbnplanet.net (4.0.3.86) 1557.100 ms 1586.801 ms 1576.663 ms 11 h1-0.cisco.bbnplanet.net (4.1.142.238) 1590.069 ms 1657.856 ms 1591.913 ms 12 sty.cisco.com (192.31.7.1) 1572.650 ms 1573.448 ms 1570.231 ms 13 cio-sys.cisco.com (192.31.7.130) 1570.323 ms 1642.216 ms 1608.919 ms /Jesper -- Jesper Skriver (JS4261-RIPE), Network manager Tele Danmark DataNet, IP section (AS3292) One Unix to rule them all, One Resolver to find them, One IP to bring them all and in the zone to bind them.

11 10

backhoe kiddies
by Dan Hollis 30 Sep '99

30 Sep '99

It's awesome the damage an individual with a backhoe can do to the net. With one flip of a lever, kill an entire continent. http://www.internettrafficreport.com/cgi-bin/tr_chartpage.pl?NorthAmerica -Dan

1 0

Re: Massive fiber cut??
by Sean Donelan 30 Sep '99

30 Sep '99

<spork(a)inch.com> writes: > (Sean, where are you??) Not in Ohio. One of the things I couldn't take with me when I changed jobs was my network contacts database. I need to start collecting phone numbers and contacts all over again.

1 0

issues with DoC, ICANN, and NSI resolved
by Ravi Pina 28 Sep '99

28 Sep '99

"The resolution of issues among the Department of Commerce, the Internet Corporation for Assigned Names and Numbers (ICANN), and Netowrk Solutions, Inc. (NSI) is embodied in five agreements (and the appendices to those agreements): . . ." http://www.ntia.doc.gov/ntiahome/domainname/agreements/summary-factsheet.htm -r -- echo "send pgp key" | mail ravi(a)cow.org "Begin to eat the dust.. the... to eat the... to eat the... the... to eat the dust... the dust of... Baja California."

2 1

Re: FW: your mail
by rs＠seastrom.com 27 Sep '99

27 Sep '99

> > > I have listened to their seminar about this... As the simple L5 firewall > > > it's not bad, through it realise the fixed set of ruls and defends your > > > from the simple SMTP attacks only. But anyway, IOS FW is just what 90% of > > > the customers need... > > > > How would IOS FW perform on Cisco 7x00-class equipment with 100M-to-Gigabit > > traffic ? > > Umm... Very poorly. At the low end it's acceptable. Gigabit traffic sucks on 7500 series routers even without any kind of filtering. The 7000-series routers, if they have an SSE, will do standard and extended access lists in the switch engine. Now, given the limitations of CX-FEIP-2TX boards (the only faste boards that will work in a non-RSP 7000), you are lucky to get 70 mbit/sec through that. If you have fddi, you can get most of the way to 100 mbit/sec one way (the CX-FIP cards, which are the only FDDIs that work in a 7000, won't do full-duplex). The 7500-series routers, you really want to get a VIP2-50 rather than a 2-40 or lower if you're going to be doing filtering on the linecard. You can load the fast ethernets up just fine there. 400 mbit/sec seems to be the upper limit of the currently shipping generation of gigE cards for the 7500 series. Hope this helps (and standing by for corrections from the #cisco IRC mafia...) ---Rob

5 5