- Test - lists.nanog.org

Re: MAE-East still no generator
by Hank Nussbacher 09 Sep '96

09 Sep '96

On Sat, 7 Sep 1996 23:24:14 -0400 (EDT) Andrew Partan wrote: >> I am moving to ... a Cascade 9000 ... > >My condolences. Care to explain that last comment? > --asp > Hank

2 1

"installing UPSes isn't hard"
by mo＠uu.net 09 Sep '96

09 Sep '96

Clearly you've never owned a UPS the size of a large DC Plant. One of the ongoing problems with UPS boxes is they have batteries in them, too, and they have to be managed and maintained. one of the BIGGEST wins in going with House DC as a source is that there is just one battery plant to be managed, and it is always rated for at least 8 hours continuous full load. sizing a UPS for that much is very, very expensive. If you wanna run AC, use inverters from House DC. That's just a UPS with the crap made redunant by a huge DC plant left off. If you insist on buying AC-powered things, then you will have inverters somewhere, either inside the UPS box or outside connected right from the DC plant. EIther way, there are many more parts involved to break. the MTBF WILL be lower. there is no way around that. The Telco folks have 100 years of hard-won experience and some of it is worth borrowing to prevent learning it the hard way. But if you insist on relearning them, be my guest. Just don't offer bad advice to other impressionable young minds. cheers, -Mike O'Dell VP, Chief Scientist UUNET Technologies, Inc.

2 1

Re: The SWAMP
by Havard.Eidnes＠runit.sintef.no 09 Sep '96

09 Sep '96

> Isn't the argument of the non-default routing tables growing by an > additional 13 entries or not is specious noise? The routing bucket is > leaking through bloody great open chasms and we are wondering about > the incremental damage throuigh a pinhole! The 13 additional entries are not the issue. The issue is one of setting a bad high-profile example. Any suggestions for closing the open chasms in the routing bucket? - Havard

4 3

Re: MAE-East still no generator
by Peter Lothberg 09 Sep '96

09 Sep '96

> is dead you are ok, I just don't think that is the point. MAE-East needs > to have some money dumped in to fix some of the power and other problems > before it is a big disaster. Well, the NY-NAP (in south NY...), has like a day of -48V and generators for weeks, and excellent physical security. --Peter

2 1

Re: The SWAMP
by Bradley Dunn 09 Sep '96

09 Sep '96

> If there has to be a separate route for each one anyway, why not just > blow 253*10 addresses and announce a /24 for each root name server, even > if only one IP out of each /24 is used? > > Less CPU to blow holes in filters that normally deny > /24. > > Avi How far does this get extended, then? What if, to encourage aggregation, /24s start to be filtered? Do you then blow a /23? A /22? I guess the real question is how do you balance between two scarce resources, router CPU and IPv4 address space. -BD

2 1

The SWAMP
by Bradley Dunn 09 Sep '96

09 Sep '96

I was doing my daily traceroutes to see who was down today, and i noticed some interesting things. One thing I noticed was that: c.root-servers.net e.root-servers.net g.root-servers.net i.root-servers.net all appear to be in the "twd", as well as being in the swamp. A well-known router vendor's web site also appeared to be in this category. Now I don't run anything nearing a real router, so I checked route-server.cerf.net, and sure enough they are being advertised as /24s. I realize renumbering the root servers is not really a good place to start.:-) Yet I think it shows what a massive task we have ahead of us, if we are to make progress in aggregating 192/8. I also think it would be hard to convince someone to renumber out of a /24 in 192, when they can say, "well almost half of the root servers haven't renumbered, why should I?". Just my observations. I'll crawl back into my little stub of the 'net and resume being a spectator. :) -BD

6 11

Re: The SWAMP
by Havard.Eidnes＠runit.sintef.no 09 Sep '96

09 Sep '96

Now, to create another sub-thread on this subject... Bradley Dunn wrote: > Now I don't run anything nearing a real router, so I checked > route-server.cerf.net, and sure enough they are being > advertised as /24s. I realize renumbering the root servers is > not really a good place to start.:-) Yet I think it shows what > a massive task we have ahead of us, if we are to make progress > in aggregating 192/8. The massive task of aggregation is not only in 192/8. Earlier today I took a dump of the BGP routing table on the above mentioned router (thanks to CERFnet!) and threw it at one of my Perl scripts which produces a report showing the distribution of prefix lengths for announced routes in each individual /8 block within the "class C" address space. The result is attached below. Note that the two "100% announced" entries are due to a well known jester announcing a couple of /8s... I will however here repeat the summary for all of the "class C" routes which shows the total number and the distribution over prefix lengths: All >=24 /23 /22 /21 /20 /19 /18 /17 /16 </16 #Rts 33220 24504 2388 1785 1170 933 918 486 226 642 168 Anyone for "War on /24"? (Oh, well, probably a lost cause before it got started...) - Havard Block #Rts >=/24 /23 /22 /21 /20 /19 /18 /17 /16 </16 As/rt % of spc 192 6446 5466 451 239 118 74 39 13 7 39 0 826 31.76 193 1911 1200 223 143 95 72 78 14 5 51 30 5299 60.36 194 2439 1609 226 146 88 56 146 35 20 99 14 4691 68.20 195 138 45 4 2 2 6 35 5 6 32 1 20288 16.69 196 375 266 33 30 15 10 4 3 1 11 2 44739 100.00 197 2 1 0 0 0 0 0 0 0 0 1 8388K 100.00 198 3965 3327 206 128 101 50 52 24 4 58 15 2113 49.94 199 3885 3285 174 111 95 66 39 38 18 46 13 2324 53.83 200 920 763 43 33 22 21 16 6 3 9 4 5252 28.80 201 0 0 0 0 0 0 0 0 0 0 0 0 0.00 202 1556 718 228 204 125 110 56 66 19 25 5 3787 35.12 203 1444 902 146 127 47 57 56 40 34 33 2 5852 50.38 204 3690 2817 216 138 131 124 86 58 22 78 20 2996 65.90 205 2151 1628 132 108 86 67 38 26 7 38 21 4550 58.34 206 2454 1392 183 230 137 132 177 68 31 78 26 5384 78.76 207 1164 665 61 69 60 57 81 87 34 40 10 6791 47.12 208 671 420 62 76 48 29 14 1 14 3 4 2972 11.89 209 0 0 0 0 0 0 0 0 0 0 0 0 0.00 210 9 0 0 1 0 2 1 2 1 2 0 23779 1.28 #Rts 33220 24504 2388 1785 1170 933 918 486 226 642 168 All >=24 /23 /22 /21 /20 /19 /18 /17 /16 </16

1 0

Re: The SWAMP
by Havard.Eidnes＠runit.sintef.no 09 Sep '96

09 Sep '96

> 'Deserve'? Is this like China 'deserves' a /8? Do root > servers have egos that need coddling? > > Why do they NEED special address space? What's the matter with > the address space of the normal networks in which they reside? > If there is someing bad about those networks, then they need > fixing, and access to the root (or other) servers will be fixed > with that change. I will echo Randy's sentiment here: is there a technical reason why the root name servers need special "provider-independent" addresses, or is this a solution looking for a problem? As far as I know, as long as one of the IP addresses in a local name server's root hints file is correct and that root name server is reachable, the local name server will operate correctly. Changes to the root hints file are currently not terribly frequent, and updating it once per half year (or maybe even less frequent) does not seem like an inordinately heavy burden. Without a technically well-founded reason for doing "weird" things with the routes for the root name servers, you can expect so see similarly ill-founded justifications from other folks wanting to do the same or similar things. As the recent events should make evident, the last thing we need right now is creating a precedent for spreading /32 routes or needlessly propagating other "special-purpose" and non-aggregateable routes. Regards, - Havard

3 2

RE: power hit stories...
by Ry Jones (ECA) 08 Sep '96

08 Sep '96

At a company I used to work for, we had the badge reader/controller for the building in the security officer's office instead of the ops room. We had a failure (the Inauguration Day storm in the Pacific Northwest) that lasted longer than the UPS the security officer had put on his desktop. You guessed it... the building went into failsafe mode; only keys worked for access. None of the ops had keys and we were effectively locked out of the building. Somehow we got a hold of the security guy's home number and he came in and we put in an extension cord. Pretty stupid, but not as cool as your story. Related, but not to power, one Monday (holiday) the building went into Day Mode, which was quite a bit less secure than Night Mode. Someone had forgotten to enter the impending Holiday as a Night/Weekend mode day. The main doors, loading dock, and all internal doors were wide open all day until someone noticed none of them were locked. -- a-ryj(a)microsoft.com, rjones(a)wicker.com MSN WAN tools group http://www.wicker.com/ >---------- >From: Bill Sommerfeld[SMTP:sommerfeld@apollo.hp.com] >Sent: Sunday, September 08, 1996 5:21 PM >To: nanog(a)merit.edu >Subject: power hit stories... > >Reminds me of the power hit at MIT one summer Saturday in 1988. Ask >Jeff Schiller about it some time... > >Short version: > >MIT had just installed a 5ESS as its new PBX; they put in the usual >batteries for backup, and opted to not include a generator just for >the switch, because MIT had its own generator. > >All the multi-line phone sets were ISDN sets, powered from the phone >closets. The phone closets supposedly had emergency power (from the >generator) and (small) backup batteries. > >Anyhow, something bad happened somewhere in Cambridge (transformer >explosion or some such), with the result that most of town lost power. >For a long time. > >One might expect the generators to come on. > >Nope. They were off-line for maintainance. > >Phys plant had brought in portable generators on trailers. > >They didn't work either. > >oops. > >So, there were now three grades of power at MIT, and two of them >weren't working. > > - normal power (from the local power grid, now dead) > - emergency power (from the generator, now dead) > - switch power (from the switch's batteries, still working) > >Unfortunately, the main phys plant emergency number was on one of the >ISDN phones. As one might expect, that phone got a lot of calls after >the lights went out, and the phone went dead when its phone closet's >batteries went out.. > >Jeff was summoned to fix the switch so that the emergency number would >work again.. I happened to be nearby at the time and wound up getting >an impromptu tour of the switch. > >We noticed, on arrival, that the lights in the nearby room housing the >modem pool were evidently on switch power.. which was clearly a wiring >mistake. > >Jeff tried to get into the switch room with his key card, but some >part of the card reader/electronic lock setup which controlled access >to the door to the switch room was not on switch power, and it >wouldn't let us in. > >Our ears soon verified that the switch's burglar alarm, on the other >hand, *was* on switch power. > >Once we shut up the alarm, we discovered that switch console terminal >was *not* on switch power... > >Things went on like this for a while.. > >Moral: > >If there are multiple grades of power available, make *darn* sure that >nothing plugged into the highest grade depends on anything plugged >into a lower grade.. > > - Bill >

1 0

Re: The SWAMP
by Bradley Dunn 08 Sep '96

08 Sep '96

Interesting. Well, in that case the rest of the /24 they are in now would have no excuse not to renumber, now would they? :) How would the routes for these /32s get propagated? I assume you'd want them to be announced via BGP, so everyone would have to rewrite their filters to let those routes in. Right? -BD ---------- > From: Paul A Vixie <vixie(a)wisdom.home.vix.com> > To: nanog(a)merit.edu > Subject: Re: The SWAMP > Date: Sunday, September 08, 1996 7:12 PM > > We have considered assigning a /32 to each root name server and asking > everybody in the universe to carry these 10 or so routes in the interest > of complete and permanent provider independence. So rather than worry > about the /24's ... :-)

2 1