- NANOG - lists.nanog.org

Risks and reality
by Sean Donelan 02 Apr '00

02 Apr '00

On Thu, 30 March 2000, Nathan Stratton wrote: > Sometimes there are not a lot of options. I work as a fire fighter and > built one of my datacenters on the 5th floor because I had no options. I > did make sure that it was marked out correctly because I know what it is > like going through a building on fire. So far I have never worked a CO > fire, but I am sure it is a mess. Bellcore had some good videotape of CO fires. But I wonder, do people talk to their insurance companies about the actual level of risk? If you look worldwide, it turns out the risk from fire in a datacenter is about the same as the risk of a terrorist attack. It sounds awful, until you look a little further and find out the occurance of either risk is very small. Factory Mutual labels risks less than 1 incident per 1,000,000 sq/ft of insured space as "low-risk." Fires in telecommunication and data centers are even rarer than 1 incident per 1,000,000 sq/ft. For the bored, the fires in telecommunications centers were extinguished by the following, in order: 1) extinguished by employees (49%) 2) extinguished by firefighters (45%) 3) extinguished by automatic fire suppression systems (6%) There are other risks which are more likely in telecommunications and data centers.

1 0

cflowd and netflow settings
by Dana Hudes 02 Apr '00

02 Apr '00

Hi folks, this is actual operational question so excuse the interruption in the fiber cut du jour thread. I have a cisco 7500 series router with v11.1(CC) code. I have cflowd running on a Dell PIII system with an IDE hard drive (thankfully fairly large) under RedHat Linux 6.1 . cflowd and friends are compiled with -mcpu=i686 . I have configured a generous cache size of 65535 on the router but it only uses 1024 entries anyway. show ip cache flow says that: IP Flow Switching Cache, 69632 bytes 1002 active, 22 inactive, 3045004972 added 2253347804 ager polls, 0 flow alloc failures Exporting flows to x.x.x.x (2055) Exporting using source interface Loopback0 Version 6 flow records, origin-as Active flows timeout in 60 minutes 3045003952 flows exported in 112978700 udp datagrams, 0 failed last clearing of statistics 5d05h The collector machine is getting hammered on the data collection. >From the log: Apr 1 20:20:19 plan9 cfdcollect[28872]: [I] wrote data for router 172.16.1.2 Apr 1 20:20:19 plan9 cfdcollect[28872]: [I] connected to localhost:2056 Apr 1 20:20:19 plan9 cflowd[16312]: [I] sent data to 216.70.64.120:1877 Apr 1 20:20:22 plan9 cflowd[29964]: [I] missed 195585 of 220926 flows from 172. 16.1.2 engine 0 agg_method 0 (88.5296% loss) Apr 1 20:20:57 plan9 cfdcollect[28872]: [I] localhost has data for 1 router. Apr 1 20:20:59 plan9 cfdcollect[28872]: [I] got data for router 172.16.1.2 from localhost Apr 1 20:20:59 plan9 cfdcollect[28872]: [I] wrote data for router 172.16.1.2 Apr 1 20:20:59 plan9 cfdcollect[28872]: [I] connected to localhost:2056 Apr 1 20:20:59 plan9 cflowd[16315]: [I] sent data to 216.70.64.120:1878 Apr 1 20:21:02 plan9 cflowd[29964]: [I] missed 168234 of 248568 flows from 172. 16.1.2 engine 0 agg_method 0 (67.6813% loss) At this point, cfdcollect is set to minPollInterval of 15 but I still lose data at peak (sure, at 10am on a weekday its no problem to keep up...) cflowd is configured for FLOWFILELEN: 2097152 and to keep 70 raw flow files. I had pretty much the same % loss with 1Mb flow files and only keeping 10 . I'm thinking that perhaps disk I/O is a problem with cfdcollect and cflowd on 1 machine with 1 disk. Two physical disks (Ultra Wide Fast SCSI) might help keep up. Thanks Dana Hudes

1 0

Re: WCOM DS3 outage in PHI
by Sean Donelan 01 Apr '00

01 Apr '00

True, there have been cases when the worldcom circuits in a city have been cut, but the UUNET network stayed up. Which undercuts any salespeople who tell people "trust us with your entire network." Nevertheless, it is amusing when an official Worldcom spokesperson specifically identifies a fiber cut in Worldcom's facilities, yet one of Worldcom's subsidiaries refers to its parent company as a nameless telco provider. It almost sounds like finger-pointing instead of synergy. But anyone who has ever dealt with the Worldcom family of companies is probably used to it. When there is a problem, its not a Worldcom circuit, its a MFS circuit. It seems very different at some other companies. I suspect some folks want to disown parts of TCG's network, but AT&T puts their brand name on the line when AT&T Local Services has a problem instead of refering to a nameless telco provider. On Fri, 31 March 2000, Vijay Gill wrote: > > UUnet allegedly wrote > > > Senior network engineers are > > > working closely with one of our Telco providers > > > to quickly resolve > > > > Amazing how quickly in the event of a fault one's much vaunted > > parent company becomes 'one of our Telco providers' :-) > > (no UUnet is not the only offender). > > There is not necessarily a one to one mapping between circuits purchased > by UUNET and circuits sold to UUNET by WCOM.

1 0

DSUA
by Joshua Goodall 01 Apr '00

01 Apr '00

Does anyone have a copy handy of Bill Manning's IPv4 Special Uses document (draft-manning-dsua-*.txt) that appears to have dropped off the I-D's list? tia ... - J

8 9

Computers are tougher than people think
by Sean Donelan 31 Mar '00

31 Mar '00

If you've seen the news, you've seen the Cash America Inc building in Fort Worth. Its the one with no windows. Although the building suffered extensive damage, and Cash America may have to abandon it, their computer center providing service to 400+ pawn shops around the country worked without interruption. Even though I don't work with libraries anymore, they still draw my attention. The Fort Worth Public Library, which is mostly underground, had significant damage to its aboveground expansion. For those who say, I told you underground is better, I'd remind you about the extensive damage to Boston Public Library's lower levels when a water main broke. Pick your risk. Sprint showed that fiber rings can work, if you do them right. Sprint suffered a fiber cut in downtown Fort Worth during the tornado. I don't think anyone outside of Sprint's operation center noticed. I didn't. Southwestern Bell now says one of their facilities in Arlington had a power failure, and is now backup on generator power.

6 6

Re: WCOM DS3 outage in PHI
by Sean Donelan 31 Mar '00

31 Mar '00

On Mon, 27 March 2000, Tatsuya Kawasaki wrote: > I uderstand there is 672 DS3 is cut at Philly. > Does anyone have update on this outage? The report is a MCI/Worldcom fiber cut near Philly, PA, the current ETR is 5pm EST. Depending on fiber and circuit swaps/leases UUNET, Exodus, PSI, and others have indicated they are affected. People are reporting problems as far north as Boston and as far south as Atlanta. No reported cause.

5 5

The Cidr Report
by Tony Bates 31 Mar '00

31 Mar '00

This is an auto-generated mail on Fri Mar 31 12:00:00 PST 2000 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 31Mar00 0) General Status Table History ------------- Date Prefixes 240300 74204 250300 74230 260300 74283 270300 74264 280300 74374 290300 74495 300300 74917 310300 74847 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 65.45.0.0/19 from AS10585 *** Bogus 219.91.160.0/22 from AS7742 *** Bogus 219.91.164.0/23 from AS7742 AS Summary ---------- Number of ASes in routing system: 7078 Number of ASes announcing only one prefix: 3919 (2134 cidr, 1785 classful) Largest number of cidr routes: 972 announced by AS701 Largest number of classful routes: 1040 announced by AS701 1) Gains by aggregating at the origin AS level --- 31Mar00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 437 153 284 65.0% BCnet Backbone AS1221 699 535 164 23.5% TELSTRA-AS AS7046 460 315 145 31.5% COQUI-NET PRTC Internet AS9269 159 27 132 83.0% Hong Kong CTI AS9706 151 25 126 83.4% Pusan Metropolitan City Office of AS2609 123 22 101 82.1% EUnet-TN AS7657 266 170 96 36.1% The Internet Group Limited AS7545 155 62 93 60.0% TPG Internet Pty Ltd AS705 307 217 90 29.3% ALTERNET-AS AS174 566 477 89 15.7% Performance Systems International AS7496 123 38 85 69.1% Power Up AS4293 290 205 85 29.3% Internal ASN for C&W AS7029 160 78 82 51.2% ALLTELNET AS6429 202 121 81 40.1% RDC-INTERNET AS9304 107 27 80 74.8% Hutchcity AS577 248 172 76 30.6% Bell Backbone AS209 437 369 68 15.6% Qwest Communications AS9557 80 15 65 81.2% Pakistan Telecommunication Compan AS3602 299 237 62 20.7% Sprint Canada Inc. AS701 1040 981 59 5.7% Alternet AS3749 120 61 59 49.2% TECNET AS7260 108 50 58 53.7% NORLIGHT AS4740 339 281 58 17.1% Ozemail Pty Ltd (ASN-OZEMAIL) AS1727 139 81 58 41.7% MRMS-WEST AS724 196 140 56 28.6% DLA-ASNBLOCK-AS AS816 329 275 54 16.4% UUNET Canada (ASN-UUNETCA-AS4) AS7568 66 19 47 71.2% C.S. Communications Co., Ltd. AS6595 88 42 46 52.3% DODDSEUR AS684 85 40 45 52.9% Manitoba Regional Network Backbon AS5106 73 29 44 60.3% AADS-COLUMBUS 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: Arlington and Fort Worth, Texas
by Sean Donelan 31 Mar '00

31 Mar '00

On Thu, 30 March 2000, "Stephen Sprunk" wrote: > Maybe this is a facet of natural disasters rarely afflicting downtown areas > around here... Maybe an occasional cattle stampede through downtown Dallas ... > I've noticed that every telco colo facility I've been in around downtown > Dallas has the same design... All are in high-rise facilities, on the > 10th-30th floors. All have the battery and A/C rooms around the elevator > shafts at the center of the floor plan, surrounded by all the equipment > racks/cages around the outside facing the windows. Gravity is a tough law to break. Batteries and mechanical equipment are heavy, and must go where the floor is strongest. Which tends to be the core of the building. As always consult a licensed structural engineer. Protecting against an airplane crashing into the side of the building is hard (although the Empire State building survived). Pick your risks and mitigate those within commercial reason. Lloyds of London exists for the rest. Sometimes the best commercial solution is putting your equipment around the outside. You loose one rack of routers to wayward tree, a few customers are down. Loose your electrical plant, and everyone is S.O.L. Triage is never a pleasant experience. Another note about battery rooms in high-rise buildings. There is/was a proposal before the NFPA to prohibit battery rooms above the third floor in high-rise structures after the L.A. CO fire. I haven't been keeping close watch on it, but Bellcore/Telcordia was fighting it tooth&nail.

7 7

RE: independent publication (was Re: DSUA) (fwd)
by Daniel L. Golding 31 Mar '00

31 Mar '00

A paper publication brings an important element - the market. Folks have to pay large $$$ for paper journals. This allows a process known in capitalistic societies as "voting with your feet". If you feel a particular journal or it's peer review policies have become corrupt, you don't pay for the journal anymore. The journal then ceases to be. Other than a governmental approach (as if ICANN could remove the IESG's "mandate from heaven"...), an approach anchored firmly in the value of currency is pretty sound. The other side of this coin is that there is typically a professional society backing the journal. Is it time for NANOG to become that type of organization? (i.e. AMA, ASME, ABA, to name just a few). As most employers will pay for professional society dues and journal subscriptions, the economic impact on the actual participants would be minimal. Flicking a virtual match at the gasoline can, Daniel Golding Senior Network Engineer NetRail, Inc. On Thu, 30 Mar 2000, Roeland M. J. Meyer wrote: > > > William Allen Simpson > > Sent: Thursday, March 30, 2000 7:48 AM > > > > The IESG has become severely politicized these days, and has some > > serious internal problems. > > If this keeps up, these tracks will be re-routed. > > > They've even rejected Bradner and my DES retirement BCP, although > > virtually every IETF working group from PPP to SAAG recommended it. > > We're planning on asking the RFC Editor for publication as > > Informational, instead. Presumably Manning can go that route, too. > > > > My "IKE/ISAKMP Considered Harmful" was the only draft ever summarily > > removed from the internet-drafts FTP site, because it is critical > > of the IESG. It was published by Usenix ;login: in December. > > Given this sort of behavior, I wonder how much longer the IESG will retain > their credibility? > > > There are some pretty good starts on operational web sites, linked to > > by the NANOG page. It would be helpful to be more active in > > maintaining > > (actively organizing) the links. What formalities do we need to have > > such a thing come to fruition? > > > > Do we really need a formal paper (hardcopy) publication? > > Given recent output of IAB, IESG, and IETF, it is becoming clear that these > orgs are no longer purely technical. Rather, they are becoming highly > politicized. As such, they will lose credibility for their > value-proposition, as being apolitical technical bodies. Once their > neutrality is gone, they will soon follow. They sad part is that those geeks > don't see that. > >

1 0

Re: Arlington and Fort Worth, Texas
by Henry R. Linneweh 30 Mar '00

30 Mar '00

one of the problems with higher is that people trapped below would be subject to immersion in liquid acid from the run down and people above from the burning fumes, not a good choice. Option 3 for large network carriers, large data centers that are in non flood plains or high storm zones. "Rowland, Alan D" wrote: > Umm... > > Just my 2¢, but I would think the higher, the better for the very reasons > you state. The higher up the battery room, the less staff have to funnel > through this "danger zone" to evacuate the building. Also, in most fires, > fumes tend to rise. So again, the higher the battery room, the less floors > are above this danger zone. > > Of course the best solution (but not practical in most real worlds) would be > to have the battery room isolated in a halon equipped bunker. "Pick your > risks and mitigate those within commercial reason." > > YMMV > > End of non-operational content. > > Al Rowland > > > -----Original Message----- > From: Henry R. Linneweh [mailto:linneweh@concentric.net] > Sent: Thursday, March 30, 2000 2:02 PM > To: Sean Donelan > Cc: nanog(a)merit.edu; ssprunk(a)cisco.com > Subject: Re: Arlington and Fort Worth, Texas > > This is disturbing, I think that people, environment and property are > the crux of importance in the order stated. > > Above the 3rd floor is a risk to human life and therefore > unacceptable, being A First Responder Operational (FRO) > I can clearly see this as a serious risk, technical details of > burning acid fumes omitted. > > Sean Donelan wrote: > > > On Thu, 30 March 2000, "Stephen Sprunk" wrote: > > > Maybe this is a facet of natural disasters rarely afflicting downtown > areas > > > around here... > > > > Maybe an occasional cattle stampede through downtown Dallas ... > > > > > I've noticed that every telco colo facility I've been in around downtown > > > Dallas has the same design... All are in high-rise facilities, on the > > > 10th-30th floors. All have the battery and A/C rooms around the > elevator > > > shafts at the center of the floor plan, surrounded by all the equipment > > > racks/cages around the outside facing the windows. > > > > Gravity is a tough law to break. Batteries and mechanical equipment are > > heavy, and must go where the floor is strongest. Which tends to be the > > core of the building. As always consult a licensed structural engineer. > > > > Protecting against an airplane crashing into the side of the building is > > hard (although the Empire State building survived). Pick your risks and > > mitigate those within commercial reason. Lloyds of London exists for the > > rest. Sometimes the best commercial solution is putting your equipment > > around the outside. You loose one rack of routers to wayward tree, a few > > customers are down. Loose your electrical plant, and everyone is S.O.L. > > Triage is never a pleasant experience. > > > > Another note about battery rooms in high-rise buildings. There is/was a > > proposal before the NFPA to prohibit battery rooms above the third floor > > in high-rise structures after the L.A. CO fire. I haven't been keeping > > close watch on it, but Bellcore/Telcordia was fighting it tooth&nail. > > -- > Thank you; > |--------------------------------------------| > | Thinking is a learned process so is UNIX | > |--------------------------------------------| > Henry R. Linneweh -- Thank you; |--------------------------------------------| | Thinking is a learned process so is UNIX | |--------------------------------------------| Henry R. Linneweh

1 0