December 1999 - NANOG - lists.nanog.org

The Cidr Report
by Tony Bates 10 Dec '99

10 Dec '99

This is an auto-generated mail on Fri Dec 10 12:00:00 PST 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 10Dec99 0) General Status Table History ------------- Date Prefixes 031299 67454 041299 67626 051299 67585 061299 67819 071299 67663 081299 67694 091299 68242 101299 67903 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 64.4.64.0/19 from AS7398 *** Bogus 64.6.32.0/20 from AS13740 *** Bogus 64.6.64.0/20 from AS10726 *** Bogus 64.6.206.0/23 from AS14215 *** Bogus 64.7.0.0/24 from AS6461 *** Bogus 219.91.160.0/22 from AS7742 *** Bogus 219.91.164.0/23 from AS7742 AS Summary ---------- Number of ASes in routing system: 6207 Number of ASes announcing only one prefix: 3302 (1819 cidr, 1483 classful) Largest number of cidr routes: 659 announced by AS701 Largest number of classful routes: 981 announced by AS701 1) Gains by aggregating at the origin AS level --- 10Dec99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 383 141 242 63.2% BCnet Backbone AS7046 393 256 137 34.9% UUNET-CUSTOMER AS1221 640 524 116 18.1% TELSTRA-AS AS2609 126 11 115 91.3% EUnet-TN AS9706 112 11 101 90.2% Pusan Metropolitan City Office of AS3602 370 269 101 27.3% Sprint Canada Inc. AS9269 128 29 99 77.3% Hong Kong CTI AS7657 270 174 96 35.6% The Internet Group Limited AS1653 125 35 90 72.0% SUNET Swedish University Network AS7545 149 61 88 59.1% TPG Internet Pty Ltd AS174 562 476 86 15.3% Performance Systems International AS4293 229 144 85 37.1% Internal ASN for C&W AS577 259 181 78 30.1% Bell Canada Backbone AS7496 113 37 76 67.3% Power Up AS3749 137 62 75 54.7% TECNET AS4200 175 108 67 38.3% AGIS (Apex Global Information Ser AS705 160 98 62 38.8% ALTERNET-AS AS816 253 193 60 23.7% UUNET Canada (ASN-UUNETCA-AS4) AS4740 347 289 58 16.7% Ozemail Pty Ltd (ASN-OZEMAIL) AS701 981 934 47 4.8% Alternet AS684 92 46 46 50.0% Manitoba Regional Network Backbon AS209 294 253 41 13.9% Qwest Communications AS1 521 480 41 7.9% GTE Internetworking AS9304 60 22 38 63.3% Hutchcity AS6528 45 7 38 84.4% WORLD-LYNX AS8013 132 96 36 27.3% PSINET-CA AS549 198 162 36 18.2% ONet Backbone AS4755 104 68 36 34.6% Videsh Sanchar Nigam Ltd. India AS7568 51 16 35 68.6% C.S. Communications Co., Ltd. AS11127 110 76 34 30.9% UNKNOWN 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

RE: [announce-all] NAC Maintenance this weekend (fwd)
by Alex Rubenstein 10 Dec '99

10 Dec '99

Something interesting for all you operational folks... got this from a customer. ---------- Forwarded message ---------- Date: Fri, 10 Dec 1999 05:11:42 -0500 From: Protect_the_innocent <nobody@nowhere> To: 'Alex Rubenstein' <alex(a)nac.net> Subject: RE: [announce-all] NAC Maintenance this weekend We tested our Y2k power contingency plans just over two weeks ago... we didn't expect any downtime either. We moved up the date on our power systems and cut main power. Three generators failed to operate. Two threw their breakers due to the high load on them. The last was overwhelmed when the previous two cut out and threw an estimated 300 amp surge through the lines, blowing up hundreds of light bulbs, frying fax machines and pencil sharpeners along the way, jumping circuits in our industrial level surge protector and traveling through our "surge protected" lines to every desktop in the company and into the server room. After taking out over 100 monitors and almost 40 PCs, the surge proceeded to destroy our Server Room air conditioner, 4 huge APC UPS systems, 4 Compaq Proliant 6500s, 9 Compaq Proliant 3000s, a Compaq Proliant 1800 and both AS/400s. The surge then jumped the lines into the main power grid, blowing up two transformers, one of which fell on the IT manager's car (poetic justice) and cutting power on the entire block. The generator then proceeded to burst into flames, eventually blowing up all six generators and burning up seven cars. This all occurred within about 10 seconds and sent 38 people to the hospital, got the entire IT staff fired (and me hired as the new IT manager,) cost the company over $650,000 in equipment (not to mention the impending lawsuits), destroyed 8 cars and has cost the company two weeks (and running) of downtime. The resulting publicity got us on television in 5 states and caused our main competitor to announce that they will be closed for the week following New Years... Let's just say I'll make other plans for internet access for tonight and the weekend - just in case. -----Original Message----- From: Alex Rubenstein [mailto:alex@nac.net] Sent: Thursday, December 09, 1999 10:43 PM To: announce-all(a)nac.net; operations(a)nac.net Cc: network(a)nac.net; internal(a)nac.net Subject: [announce-all] NAC Maintenance this weekend ** This electronic communication is being originated from Net Access ** Corporation, your Internet Service Provider. In an ongoing effort to make our systems ready for the Year 2000 date rollover, we will be performing some tests and upgrades this weekend. On December 10th, 1999, at 5:00pm EST, we will be testing our Year 2000 power contingency plan. No downtime is expected during this test. On December 11th, 1999, as 2:00am EST, we will upgrading william.nac.net, a virtual web server. Expected downtime is four hours. Customers who have websites on this virtual web server will be out of service during this time period. If you have any questions, please call the Technical Assistance Centre at 973-590-5100.

3 2

Dead Line of APRICOT Fellow Application is Dec. 18 (fwd)
by Bill Manning 10 Dec '99

10 Dec '99

For you operational folk that have an interest, this might be useful. Sorry for duplicates and for pestering the rest of you. ----------------------------------------------------- % I'd like to let you know the dead line of APRICOT2000 Fellow Application % is Dec. 18. % % We are pleased to announce our Fellowship Program to support % participating in APRICOT2000 which will be held on 28 Feb. 2000 - % 2 Mar. 2000 in Seoul, Korea. The purpose of this program is to % encourage participation of network builders, top decision makers % in Government, Education, and Commercial Sectors who are not available % in fund. APRICOT2000 will cover registration of the conference and % tutorials in APRICOT2000 and US$250 equivalent Korean currency for % accomodation and food to the fellows. Clover hotel is the official hotel % for the fellows. % % Other related annoucement is in www.apricot2000.ne.kr. % % The Committee members select fellows according to following criteria % to % provide fairness, transparancy and necessity to come. % % 1) Network Builders. % 2) Top Decision Makers in Government, Education, and Commercial % Sectors. % 3) Developing Countries. % 4) No limit in geographical region. % % If you want to be a fellow in APRICOT2000, please fill in the attached % form and send to fellow-apply(a)nic.or.kr by 18 December 1999 . The % notification of accepltance will be on 21 December 21 1999. % % ================================================================= % Application Form % ================================================================= % % [Profile] % % (1) Name : % (2) Email : % (3) Address : % (4) Affliation and Position : % (5) Motivation to participate : % (6) One page A4 Biography (needed attached file - only text or word % file ) % % % ** The Motivation to participate is the most important to select % % % Best wishes, % % Sunyoung Han % syhan(a)cclab.konkuk.ac.kr % Fellowship Committee Chair of APRICOT2000 % -- --bill

1 0

Re: A call for the future. Was: Re: Verio Decides what parts ofthe internet to drop
by Dean Anderson 10 Dec '99

10 Dec '99

Around 07:22 AM 12/8/1999 -0800, rumor has it that Randy Bush said: > >> The phone system doesn't require anything close to millions of routes for >> LNP. Instead, at the time of call setup, there is a lookup that performs >> the translation between the portable number (which is the logical address) >> and the physical address (which to date is still mostly statically >> routed using a well-defined hierarchy based upon physical location). > >and here is where the anology breaks down. a second or two of call setup >may be acceptable for establishing a phone call. it would be a disaster >on a per-packet basis. > >ip is a connectionless protocol. before hitting the reply key, think about >that. I thought about it. It seems to me that a router is not presented with a stream of randomly addressed packets. In any time frame, there are going to be from 1 to many hundreds of packets between the same set of addresses. Cisco takes advantage of this to with a route cache. When I was a junior monkey, one of my first tickets involved the route cache ACL bug in IOS 8.0, where routes added to the route cache were no longer checked against the appropriate ACL's. Of course, I didn't know immediately that was the real problem. It just seemed to work after I pinged (permitted in the ACL), and would continue to work (for something denied in the acl) for a while afterward. So, while the first packet may result in a longer lookup, the successive packets hit the cached route. So now it becomes a problem to build an adequately sized route cache for the number of simultaneous 'connections' that one might expect to process in a given timeperiod. Which brings one back the terms and design rules that are not unlike those that apply to phone switches. The thing that is tough to grow is the access list size. The connectionless part of IP is just a matter of whether state is maintained in the protocol or at the endpoints. An ISDN connection has a state at the endpoints and all the processing points. All the switches along the path must maintain that state. An ISDN packet in the middle of stream does not carry enough information to recreate the state. If you miss the setup message, you can't figure out the state from the rest of the packets. By contrast, an IP packet traversing an IP network carries all the state it needs with it. However, that doesn't mean that you need to start from scratch each time you see the same src/dest pair. Methods which hold some additional state in the router for faster processing can be used to speed things up. The full route table could be very large. Much larger than 256Meg or even 4Gig. And even moving to disk backed storage (many gigs) most likely means that access would still be in tens or hundreds of milliseconds, not seconds. However, any given router doesn't really need to use very much of it at any given time. The problem, as I see it, is that Cisco sees everything as a router. And a typically low powered router, as compared to mid and high range unix servers. Consider the Cisco H323 (VOIP) product line. Clearly, the 5300 makes sense as a router. It processes 4 PRI or T1 CAS voice lines into h323 on IP, along with the consequent DSP chips. The 2600 & 3600 make sense for lower density DSP platforms. Clearly, tranlating G.711 to G.729 or others requires specialized hardware. However, the gatekeeper (call routing) software runs on a 3600. This is a grossly underpowered platform for gatekeeper functions, and underfeatured. Gatekeeper functions belong on a general purpose machine with modular (user replaceable) software and access to a database which can handle complex and quickly changing route policies (eg, time of day routing, followme routing). One desires a machine which can scale to handle hundreds or thousands of transactions per second (between a Sun ultra2 and an SGI Challenge w 64 processors). None of these functions are particularly suited to specialized routing hardware. Yet, Cisco insists that (nearly) everything must run on IOS. The best alternative right now runs on NT, with its lack of scalability and other PC problems. But the NT platform runs circles, triangles, squares, and other complex polyhedrons around the 3600. Policy based routing in either a voice or an IP network require flexibility which can't be found in a specialized hardware platform. The problem is the wrong software & hardware combination to do the job, not that the route table has grown too large, or that the job just can't be done. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

7 6

Re: Re[2]: Portable IP space, isolated networks, BGP, etc... (fwd)
by Randy Bush 10 Dec '99

10 Dec '99

>>>>> First, it's my understanding that I can use a single ASN for the BGP >>>>> peering at each of these networks. Am I mistaken? >> if you don't care to reach one from the other. > Well, you _can_, if you want to put the time and effort into performing > the evil routing voodoo. I can think of a few ways of doing it, without > even bridging over a tunnel. I wouldn't advise it, however. i disagree strongly. i think it is a really great idea for our competitors to deploy. randy

2 1

Re: BGP dampening parameters
by Vadim Antonov 10 Dec '99

10 Dec '99

The problem with overly aggressive flap damping is pretty much fixed by the adaptive rate-based algorithm. Now, did anyone actually try it in the real networks? --vadim "Other" Sean: | Have people adjusted their dampening parameters or are they still using the | Cisco defaults? Please see http://www.ripe.net/docs/ripe-178.html Sean.

1 0

Re: BGP dampening parameters
by smd＠clock.org 10 Dec '99

10 Dec '99

"Other" Sean: | Have people adjusted their dampening parameters or are they still using the | Cisco defaults? Please see http://www.ripe.net/docs/ripe-178.html Sean.

1 0

BGP dampening parameters
by Sean Donelan 10 Dec '99

10 Dec '99

In the past when a large provider would do a rolling reboot of their routers, usually in the early morning, some routes would get dampened for a while. It usually cleared up before the morning business traffic hit. Although there were some complaints from our friends in Europe about rebooting routers in the middle of their business day. I haven't heard of BGP dampening issues for a while. Do they still happen? Have people adjusted their dampening parameters or are they still using the Cisco defaults? My concern is false reports due to the increasing number of sites who plan to bounce their networks overnight on New Year's. http://dailynews.yahoo.com/h/nm/19991209/wr/yk_usa_3.html The original BGP dampening parameters were very agressive. I don't know if all these sites are aware if they bounce their network more than a couple times in a short time, they will get dampened. And will start reporting Internet problems because their network was dampened. Has anyone in their lab testing done any work to see how well modern Cisco's react to large scale world-wide network reboots if lots of sites follow suit?

1 0

Need help from UUNet's routing specialist!
by Dmitry S. Esakov 10 Dec '99

10 Dec '99

Hello! We (as8470) are Teleglobe customer. And we experience terrible delays on Teleglobe to UUNet interconnect points. Teleglobe's customer support engineers insist, that the problem caused by UUNet's routes prioritization. But I belive that this assymetric routing initiated by Teleglobe, not UUNet. Could you please send me 'sh ip bgp 195.128.65.33' performed at Serial3-1-1.GW1.DCA3.ALTER.NET (157.130.39.89). I am expecting to see communities or MEDs set at TG router that lowres route priority and makes traffic to go back via _Seattle_Denver_Chicago_NY_. Any help is _greatly_ appreciated! --------------------- Example of delays: --------------------- nyy-1#trace Protocol [ip]: Target IP address: www.uu.net Translating "www.uu.net"...domain server (195.128.64.3) [OK] Source address: 195.128.65.33 Loose, Strict, Record, Timestamp, Verbose[none]: Type escape sequence to abort. Tracing the route to www.uu.net (208.243.117.123) 1 if-0-1-0.bb6.NewYork.Teleglobe.net (207.45.205.13) [AS 6453] 0 msec 0 msec 0 msec 2 if-3-0.core2.nqt.Teleglobe.net (207.45.221.98) [AS 6453] 4 msec 0 msec 0 msec 3 if-1-0.core1.Washington.Teleglobe.net (207.45.223.170) [AS 6453] 8 msec 4 msec 8 msec 4 if-2-0-0.bb1.Washington.Teleglobe.net (207.45.221.228) [AS 6453] 8 msec 4 msec 8 msec 5 Serial3-1-1.GW1.DCA3.ALTER.NET (157.130.39.89) [AS 701] 1356 msec 1152 msec 1180 msec ^^^^^^^^^^^^^^^^^^ !!!!!!!!!!! 6 110.ATM3-0.XR1.DCA1.ALTER.NET (146.188.161.54) [AS 701] 1048 msec 1144 msec 1136 msec 7 195.ATM8-0-0.GW1.DCA1.ALTER.NET (146.188.161.17) [AS 701] 1172 msec 1036 msec 1244 msec 8 260.GW1.TCO3.customer.ALTER.NET (157.130.33.222) [AS 701] 876 msec 788 msec 812 msec 9 prod-334a.tco3.web.uu.net (208.243.113.236) [AS 11486] 1112 msec [cut] Serial3-1-1.GW1.DCA3.ALTER.NET (157.130.39.89) ---------------- Have a nice day! Esakov Dmitriy, Macomnet Internet Dpt.

3 2

OPERATIONAL: NSI.Registery died yesterday. Updates lost
by John M. Brown 09 Dec '99

09 Dec '99

According to several NSI.Registrar techs (first and second level) that I spoke with today The SRS died yesterday. Updates made yesterday may not have made it to the real world. Further comments stated that updates today may also be problematic. Just a heads up on the REGISTERY

1 0