May 1999 - Test - lists.nanog.org

Is there a PSI.NET person in the house?
by Roeland M.J. Meyer 11 Apr '00

11 Apr '00

I just got half a hundred of these (and 123 of these last Friday) and all e-mail, to the usual locations, bounces or gets ignored. I am livid, I am pissed, I am *really* wanting to SMURF PSI.NET because they have been a spam-harbor for *years*! PSI.NET should have made it into the RBL a long time ago. >Return-Path: <admin1(a)fnmail.com> >Received: from beta.pragmatix.com (epsilon.pragmatix.com [205.166.32.6] (may >be forged)) > by condor.lvrmr.mhsc.com (8.9.1/8.9.1) with ESMTP id FAA18857 > for <rmeyer(a)mhsc.com>; Mon, 1 Mar 1999 05:04:57 -0800 >Date: Mon, 1 Mar 1999 05:04:57 -0800 >From: admin1(a)fnmail.com >Message-Id: <199903011304.FAA18857(a)condor.lvrmr.mhsc.com> >Received: from jgroves (ip33.phoenix8.az.pub-ip.psi.net [38.29.61.33]) by >beta.pragmatix.com with SMTP (Microsoft Exchange Internet Mail Service >Version 5.5.1960.3) > id FS46B0Z3; Sun, 28 Feb 1999 18:33:11 -0500 >To: travelers(a)ibm.net >Subject: Make $$, Travel and Have Fun! >X-UIDL: 2ddab26e92763572b29a9545c30b592f ___________________________________________________ Roeland M.J. Meyer - e-mail: mailto:rmeyer@mhsc.com Internet phone: hawk.lvrmr.mhsc.com Personal web pages: http://staff.mhsc.com/~rmeyer Company web-site: http://www.mhsc.com ___________________________________________________ KISS ... gotta love it!

3 3

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

08 Jun '99

Tony Li <tony1(a)home.net> wrote: >I suspect that the main driver is not the amount of routing information >in the gross sense, but the scalability of the protocol as the number of >nodes increases. There's a better solution: decrease the number of nodes by replacing clusters with bigger boxes. This has an additional advantage of reducing number of hops (and, consequently, latency variance). K.I.S.S. rulez :) --vadim PS. Using DUAL or DASM instead of SPF helps, too -- these algorithms tend to eliminate updates which "do not matter" unlike SPF-based algorithms which have to inform everyone about local topology changes.

5 4

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