- Test - lists.nanog.org

memorial network reconfiguration day?
by William Allen Simpson 31 May '99

31 May '99

Hey, did everybody decide: "it's a holiday, and the end of the month, nobody will notice when all the routes flap as we change router configuration"? When the backhoes had a day off? I haven't seen this much since the bad ol' days of '91 or so. Aside from the perpetual congestion problems in C&W North Royalton, I saw GoodNet Chicago flipflop between MAE East and West, and ACSI cum eSpire problems on their cross-country links into Arkansas / Mississippi / Tennessee / Texas, and sometimes even alternate tracing through AGIS. Was upwards of 70% packet loss for awhile there.... Or is this always happening, and I just got to watch because I had some time on my hands and it affected me for several hours? WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

1 0

Re: OSPF multi-level hierarchy: Necessary at all?
by Alex Zinin 31 May '99

31 May '99

At 11:35 27.05.99 -0700, Vadim Antonov wrote: >... >>but the main question is whether there is a demand >>for it or not. > >I guess the answer is pretty much not. The amount of interior >routing information in a properly designed backbone is quite >small even if there is no two-layer abstraction. If you do not use route-summarization on the area borders, your're gonna have flat network from the routing info's point of view, even though the topology info is abstracted. Flat networks are very well known to be not scalable. >(Now, the >_exterior_ information is aplenty, but OSPF is useless for it >anyway). The new approach could incorporate aggregating externals on level borders in addition to aggregating internal routing info. > >If someone proposed simplifying and cleaning up OSPF i'd be >quite for it. Building a protocol allowing to get rid of >iBGP hack would also help :) In OSPFv6 an ASE-LSA can point to another LSA, which per D. Ferguson can contain BGP path attributes. The new approach (which could be intergrated in OSPF for IPv6 btw) could use a technique analogous to this one. Rgds ------------------------------------------------------------------ Alex D. Zinin, Consultant CCSI #98966 CCIE #4015 AMT Group / ISL Cisco Systems Gold Certified Partner http://www.amt.ru irc: //EFNET/#cisco, //irc.msn.com/#NetCisco [Ustas]

3 5

Sprint outage??
by Brad S. Dreisbach 30 May '99

30 May '99

Does anyone have any information on an outage at sprint. I just got off the phone with the NOC and there is supposedly some sort of fiber outage in the dc area affecting only sprint customers. ________________________________________________ Brad Dreisbach ~ Unix Systems Engineer digitalNATION ~ www.dedicatedserver.com Phone: 703-642-2800 ~ Fax: 703-642-3747 Work: www.dn.net ~ Personal: home.dn.net/~bradd

1 0

Re: Oddities in a bad route announcement
by Sean Donelan 30 May '99

30 May '99

mdl(a)equinox.shaysnet.COM (M. David Leonard) writes: > It looks OK from here right now: It seems pretty much hosed everywhere outside of UUNET. Now there seems to be no route being announced outside to anyone. paix1>show ip bgp 192.104.54.3 % Network not in table paix1>exit -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

3 2

Oddities in a bad route announcement
by Sean Donelan 29 May '99

29 May '99

At first I thought this was just another Bay router causing Warwick Online (ASN11606) to leak routes between UUNET and Sprint. But when I looked into it, I found a few oddities. Unlike most bad route incidents, this seems to hijack a route for very specific site. Usually bad routes blackhole in the provider, so suffer so much congestion it is quickly noticed. In addition, usually a more specific announcement caused the problem. You could still find the "correct" route somewhere. In this case, I can't find the real 192.104.54.0/24 announcement on route-server.cerf.net, digex looking glass, or my own bgp sessions. Yes, I've already reported this to the providers involved. But in the more general sense, anyone have a hypothesis why this would happened? The blockage of the real announcement from the direct upstream provider seems very strange. traceroute to infoserver.FCC.gov (192.104.54.3), 30 hops max, 38 byte packets 1 StLouis22-fe6-0-0.dra.net (192.65.218.2) 10 ms 0 ms 10 ms 2 sl-gw2-kc-3-7.sprintlink.net (144.232.129.97) 10 ms 10 ms 10 ms 3 sl-bb2-kc-12-0.sprintlink.net (144.224.20.2) 10 ms 10 ms 10 ms 4 sl-bb10-kc-1-1.sprintlink.net (144.232.2.21) 10 ms 10 ms 10 ms 5 sl-bb11-chi-4-0.sprintlink.net (144.232.9.118) 20 ms 20 ms 20 ms 6 sl-bb5-chi-0-0-0.sprintlink.net (144.232.0.170) 20 ms 20 ms 20 ms 7 sl-bb7-pen-5-0-0.sprintlink.net (144.228.10.37) 40 ms 40 ms 30 ms 8 sl-bb11-pen-1-3.sprintlink.net (144.232.5.57) 30 ms 40 ms 40 ms 9 sl-gw24-pen-4-0-0.sprintlink.net (144.232.5.182) 40 ms 50 ms 40 ms 10 sl-warwick-3-0-0.sprintlink.net (144.232.188.214) 40 ms 70 ms 60 ms 11 208.228.101.2 (208.228.101.2) 50 ms 50 ms 50 ms 12 905.Hssi2-0.GW3.NYC1.ALTER.NET (157.130.6.237) 50 ms 50 ms 50 ms 13 104.ATM3-0.XR1.NYC1.ALTER.NET (146.188.177.138) 60 ms 50 ms 60 ms 14 195.ATM3-0.TR1.NYC1.ALTER.NET (146.188.178.182) 60 ms 50 ms 50 ms 15 104.ATM5-0.TR1.DCA1.ALTER.NET (146.188.136.213) 60 ms 50 ms 50 ms 16 199.ATM6-0.XR1.DCA1.ALTER.NET (146.188.161.129) 50 ms 50 ms 50 ms 17 195.ATM9-0-0.GW2.DCA3.ALTER.NET (146.188.163.185) 50 ms 50 ms 50 ms 18 fcc.gov-gw.customer.alter.net (157.130.39.150) 60 ms 50 ms 60 ms 19 infoserver.fcc.gov (192.104.54.3) 50 ms * 50 ms -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1

Re: updated IP Address Utilization Chart
by Alan Hannan 29 May '99

29 May '99

Thanks, it looks sharp. I recommend you post it to nanog(a)merit.edu to publicize the change... -a Thus spake Hans-Werner Braun (hwb(a)nlanr.net) on or about Thu, May 27, 1999 at 04:08:49PM -0700: > > Ok, I did a little sequel. Check out: > > http://moat.nlanr.net/IPaddrocc/18monthSequel/ > > > Hi Hans, > > > > I've just now downloaded nnpack.pl, I'll take a look, thanks alot. > > > > -alan > > > > Thus spake Hans-Werner Braun (hwb(a)nlanr.net) > > on or about Thu, May 27, 1999 at 10:29:53AM -0700: > > > > > > > > > > > Hi Hans, > > > > > > > > Would it be possible to get an updated Global Internet Address > > > > Occupancy chart from you, or perhaps the code to make one > > > > ourselves? > > > > > > > > Thanks. > > > > > > > > -alan > > > > > > I can probably create one, but all the software and data files are > > > online and publicly available. > > > > > > Hans-Werner

3 4

RE: OSPF multi-level hierarch: side question
by Vadim Antonov 28 May '99

28 May '99

Steve Meuse <smeuse(a)bbnplanet.com> wrote: > On the other hand, you can choose to build a box that can handle thousands > of customers, and decrease the traffic load, but also increase the > liklihood of a failure that can directly affect a larger percentage of > customers. Dan Rabb <danr(a)dbn.net> wrote: > Routers will inevitably fail. The question becomes how much exposure do you > want when it does? First, you have to stop thinking of routers as "black boxes" and expose internal structure of large boxes so you can compare it with clusters. In this respect, big router designs i know of are eminently more reliable than clusters of traditional routers for a number of reasons: 1) the connectivity between components ("elementary routers") is significantly richer, with many diverse paths between components. 2) the design is inherently simpler than that of a multi-vendor and multi-standard cluster; with significantly fewer number of different components and a lot more regular topology. Simplicity directly translates into reliability. 3) there is a built-in support for extensive fault-tolerance and self-diagnostics at a level simply unachievable with standard routing protocols (which by their nature do not have a foggiest idea of the internal structure and diagnostic possiblilities of the routers; and do not provide any support for state mirroring). 4) the individual failure blocks are much smaller (i.e. one "line card" vs entire router, at least in Pluris design -- the line card interface is not a bus, but a serial line with protocol which cannot be screwed up by misbehaving line card, unlike any known bus protocols). 5) power supplies are distributed (Pluris box simply has a separate DC-DC converter on every card) 6) at least one vendor (Pluris) has all card cages complteley isolated electrically 7) the last (but not least) aspect of terabit routing is its inherent reliance on inverse-multiplexing over multiple parallel channels allowing to degrade service gracefully in case of individual channel or path failures - without any need to make the problem visible at IP level; and therefore not limited by performance of distributed routing algorithms. Alex Zinin <zinin(a)amt.ru> wrote: > "Have more bigger boxes rather than less smaller ones"-approach is not > for everybody and not for every case. If you have clusters sitting in one room, > powered from the same source, sharing the same ceiling that can fall, running > the same version of soft, using the same config., etc., than yes it's ok, > because they will more likely crash at the same moment. A big router does not have to be all in one place physically. Pluris design allows hundreds feet of component separation with optical cabling. > Also, even if you do use a large box, you probably don't wanna know > all the details about it's connections at some level of your network. The whole premise of big box design is that its internal capacity is so much bigger than interface capacity that from outside it looks like a single point w/o any need to optimize routing inside. From the perspective of network management, of course, big boxes have to provide detailed internal status info. A sane design for a big router has an out-of-band diagnostic network within the box. >> to eliminate updates which "do not matter" unlike SPF-based algorithms >> which have to inform everyone about local topology changes. > > In SPF-based protocols we have areas for this purpose---we do not propogate > topology information across the area boundaries. Across boundaries which have to be configured _manually_. DV and diffuse algorithms tend to squelch topology updates automatically _within_ an area if a same-metric alternative path is found. SPF has to have a coherent picture of network topology at all times; so flap can easily kill it off. Diffuse algorithms are by design work well in a network with rapidly changing topology. --vadim

1 0

Re: OSPF multi-level hierarchy: Necessary at all?
by Vadim Antonov 28 May '99

28 May '99

Tony Li <tony1(a)home.net> wrote: >And this is also ignoring the fact that we have zero routers that are of the >scale that you describe today. I'll agree that we will get there... >eventually. If the IGPs fail in the meantime, we're still dead. One can run separate IGPs on inside and outside POP clusters. I toyed with configurations like that back then... nearly got killed by Peter :) --vadim

1 0

The Cidr Report
by Tony Bates 28 May '99

28 May '99

This is an auto-generated mail on Fri May 28 12:00:02 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 28May99 0) General Status Table History ------------- Date Prefixes 210599 59570 220599 59339 230599 59259 240599 59294 250599 59763 260599 60611 270599 60580 280599 60794 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 221.43.160.0/19 from AS12323 AS Summary ---------- Number of ASes in routing system: 5031 Number of ASes announcing only one prefix: 2576 (1405 cidr, 1171 classful) Largest number of cidr routes: 406 announced by AS701 Largest number of classful routes: 1226 announced by AS209 1) Gains by aggregating at the origin AS level --- 28May99 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS209 1226 567 659 53.8% Qwest Communications AS271 358 147 211 58.9% BCnet Backbone AS4293 273 168 105 38.5% IMCI AS174 582 488 94 16.2% Performance Systems International AS4755 172 86 86 50.0% Videsh Sanchar Nigam Ltd. India AS577 255 176 79 31.0% Bell Canada Backbone AS4200 169 93 76 45.0% AGIS (Apex Global Information Ser AS3749 136 62 74 54.4% TECNET AS1267 94 24 70 74.5% IUNET-AS AS7496 99 33 66 66.7% Power Up AS7545 112 48 64 57.1% TPG Internet Pty Ltd AS7122 139 78 61 43.9% MTS ADVANCED Network Policy AS1221 457 396 61 13.3% TELSTRA-AS AS7657 179 122 57 31.8% The Internet Group Limited AS10928 111 54 57 51.4% UNKNOWN AS9269 65 10 55 84.6% Hong Kong CTI AS72 94 39 55 58.5% Schlumberger Information Network AS4740 325 270 55 16.9% Ozemail Pty Ltd (ASN-OZEMAIL) AS719 474 420 54 11.4% LANLINK autonomous system AS1239 526 472 54 10.3% SprintLink Backbone AS2493 175 122 53 30.3% iSTAR Internet, Inc. AS7046 265 213 52 19.6% UUNET-CUSTOMER AS3737 161 111 50 31.1% PenTeleData Inc. (ASN-PTD) AS803 73 37 36 49.3% SaskNet Backbone AS1 495 460 35 7.1% BBNPLANET AS6172 153 120 33 21.6% HOME-NET-1 AS1785 246 214 32 13.0% NYSERNet Backbone AS549 163 132 31 19.0% ONet Backbone AS4307 32 1 31 96.9% SVINET-1 AS3549 133 102 31 23.3% Frontier GlobalCenter 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

One Big Box Design
by Sean Donelan 28 May '99

28 May '99

Of course with the "one big box" design, even if you design it to so-called "telco-quality" standards you still have the problem of loosing a lot when the "big box" goes down. Someone pointed out to me that last night seven Missouri counties lost 9-1-1 service and long-distance service for over four hours (and a plane crashed, but that was unrelated). Southwestern Bell reports an 'unknown party' cut a fiber optic cable in Lake St. Louis (just west of St. Louis) around 2pm CDT yesterday. Cell phones, pagers, 800 numbers were out of service from about Jefferson City to Lake St. Louis. If you had a direct T1 to an IXC you could call long-distance, but Equal Access dialing was down. The 'unknown party' just happened to sever the fiber optic link for the main access tandem for the central(westphalia) LATA in Missouri. When you lose an access tandem in the telephone network, things don't work so good. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0