October 2001 - Test - lists.nanog.org

Slightly OT: Third anniversary of Dr. Jon Postel's death
by Patrick W. Gilmore 16 Oct '01

16 Oct '01

Just thought it would be nice to take a moment and remember someone who was so instrumental in creating what we (usually) discuss here. -- TTFN, patrick

1 0

Any good suggestions for a TCP based
by Arman Khalili 16 Oct '01

16 Oct '01

packet loss tool. thanks, ak

2 1

Extreme Networks mailing list?
by Rich Sena 15 Oct '01

15 Oct '01

Does anyone know of an Extreme Networks list - I looked around and couldn't find one... Jared, if there isn't one are you intereseted in hosting one on puck? -- Rich Sena - ras(a)thick.net ThickNET Consulting "On the way to understanding; you understand, and forget."

2 1

RE: Attacks Expose Telephone's Soft Underbelly
by Sean Donelan 15 Oct '01

15 Oct '01

On Mon, 15 Oct 2001, Kevin Gannon wrote: > I guess this is really a question for Sean given your background. > Over on this side of the pond the 999 (112) service needs to be > 100% reliable/redundant, having seen a major CO melt down in > the capital I can atest that it works. > > My question is how is this achieved for both 999 services and > critical government services ? Surely buisnesses can learn > something from it ? Never watch sausage being made. The basic principles (aka best practices) are well understood. However, money is the driving factor in all decisions whether those decisions are made by the public or private sector. 9-1-1 (the US version of emergency number) service is very reliable, but has been disrupted the same things which disrupts telephone service in general. Not all public service answering points have redundant circuits. Not all end-offices have diverse paths. Even when redundant circuits exist, they've been groomed on to a common physical facility. Operator and software errors corrupt translation tables in switches. Much of the reliability comes not from preventing things from breaking, but by priority repair service when it breaks. Because 9-1-1 is usually repaired before most other services, it has the best MTBF/MTTR even if it breaks due to the same cause as other services. Of course, there is always the definition of working. If your phone doesn't work, you can't call 9-1-1, even if the PSAP is "working." Another problem in New York City was NYC's emergency operation center "bunker" was destroyed in the collapse of the world trade center tower. In addition to all the other problems, Verizon needed to install/re-route emergency circuits for almost everything connected to the EOC.

2 2

NYT: Attacks Expose Telephone's Soft Underbelly
by Sean Donelan 15 Oct '01

15 Oct '01

The New York Times is reporting about some of the issues Verizon is facing with its New York recovery. http://www.nytimes.com/2001/10/15/technology/15PHON.html Although most people are focusing on Verizon, things are much more interesting when you look at the interaction of all the different carriers in lower Manhattan. And what I think is more important, what happened outside of Manhattan. Carriers restored service be re-routing circuits through Cleveland and London (Yes, England). One issue that did come up was government planning was limited to Verizon. So alternate capacity which could have been used during the first few days went unused, and some services were disrupted because employees of non-Verizon carriers weren't allowed into the area.

4 3

RE: Attacks Expose Telephone's Soft Underbelly
by Kevin Gannon 15 Oct '01

15 Oct '01

On Mon, Oct 15, 2001 at 02:15:38AM -0400, Kath wrote: > I don't see how this situation could have helped them, but only hurt them. > I mean, if you have a physical facilities issue (severed copper/fiber optic, > damaged CO), then you are gonna have problems with telephone or data service > no matter who you use. Plus, some of us know how long opening and > resolution of a trouble ticket with an ILEC can take when coming from a > CLEC, but now you could only imagine when Verizon has a serious issue, like > this. My employer is one example of an alternative, and I know of several other companies that could fit the bill as well. MFN (www.mmfn.com) can sell a private fiber optic ring to a customer. In many cases (and Manhattan is a good one) that can be a truly physically diverse ring. We have a number of customers who insist on truly diverse rings, and things like two building entrances at least 100 yards apart. For the most part (because nothing is 100% sure) it is possible to protect against any single cable cut. The largest problem with our service right now is that the barrier to entry for the customer is higher than it should be -- if you need a single T1 we can't compete. For what it's worth, I believe it to be the case (*) that we had fiber rings with a node in one of the trade center towers that were fully operational (minus that node) after the disaster. In the end, it's often a matter of what you're willing to pay for, or if you leave it up to your carrier what risk they are willing to assume. We've all fought to drive the price of T1's into the ground, and at $200-$300 for a local circuit they aren't going to build redundant fiber rings. You're going to get a single run collapsed ring every time, simple economics. Copper services which are still used in so many places are virtually impossible to make path redundant due to the technologies and distance limitations involved. Verizon offers products that connect you to two CO's. I've ordered them before. Companies like MFN can bypass CO's completely with redundant fiber rings. Companies like Yipes and Cogent often build their IP services in redundant metro configurations. Companies like Level 3 and MFS have upscale redundant access products. There are alternatives that could have protected the vast majority of the service that went down. The problem with all of them is that they cost more $$$'s than the non-redundant service. I think this event is making a lot of companies look hard at their cost control strategies and reconsider their disaster recovery plans. Can you be 100% sure you'll always be up? No. Can you add several 9's to the services currently available, absolutely. * I don't work for the fiber side of the business and only know a little bit about the impact of this specific disaster to our network. Issues still arise (I am assuming that the ring is running SDH rather than Dark fibre) due to configuration problems SW problems ect. These issues do not go away no matter what the entry level in terms of price is. Regards, Kevin

1 0

Re: RE: Attacks Expose Telephone's Soft Underbelly
by Frank Coluccio 15 Oct '01

15 Oct '01

Something I've heard zero about during the recent restoration procedures in NY was the "mutual assistance program," or MAP, which is comprised of about a dozen carriers in NY. MAP was conceived about ten years ago when the "Trillion Dollar Gamble" document was issued to/by the financial community in NY under the aegis of the Chamber of Commerce, and it allegedly played heavily into the restoration of the '93 bombing. But it has been relatively quiet since then. Perhaps the disruption of the bunker in 7 WTC caused those contingency preparations to be aborted. Anyone with knowledge about this please email or post here. Good use of the 911 response mechanisms to demonstrate your point, btw. Both outwardly (the service provider, i.e., Telco, NSP) and inwardly (the user organization, itself). To advance your point another step and to support mine, I should point out that it is incumbent on enterprise IT organizations to ensure that 911 capabilities are supported by PBXs, and now VoIP LAN platforms [call managers and gateways], as well, in order to ensure employee safety on a 24/7 basis. The same holds true for other, highly-visible services when given sufficient priority, especially when mandated by law. Such would be the case with D/R contingency preparedness when other aspects of public safety and welfare are at risk. These factors all play directly into one of your main points, which is the effect of throwing more cash at targeted applications. -FAC > > On Mon, 15 Oct 2001, Kevin Gannon wrote: > > I guess this is really a question for Sean given your background. > > Over on this side of the pond the 999 (112) service needs to be > > 100% reliable/redundant, having seen a major CO melt down in > > the capital I can atest that it works. > > > > My question is how is this achieved for both 999 services and > > critical government services ? Surely buisnesses can learn > > something from it ? > > Never watch sausage being made. > > The basic principles (aka best practices) are well understood. > However, money is the driving factor in all decisions whether > those decisions are made by the public or private sector. > > 9-1-1 (the US version of emergency number) service is very > reliable, but has been disrupted the same things which disrupts > telephone service in general. Not all public service answering > points have redundant circuits. Not all end-offices have diverse > paths. Even when redundant circuits exist, they've been groomed > on to a common physical facility. Operator and software errors > corrupt translation tables in switches. Much of the reliability > comes not from preventing things from breaking, but by priority > repair service when it breaks. Because 9-1-1 is usually repaired > before most other services, it has the best MTBF/MTTR even if it > breaks due to the same cause as other services. > > Of course, there is always the definition of working. If your phone > doesn't work, you can't call 9-1-1, even if the PSAP is "working." > > Another problem in New York City was NYC's emergency operation center > "bunker" was destroyed in the collapse of the world trade center > tower. In addition to all the other problems, Verizon needed to > install/re-route emergency circuits for almost everything connected > to the EOC. > > >

1 0

Toll-free and teleconference services on 9/11
by Sean Donelan 13 Oct '01

13 Oct '01

How well did toll-free and teleconference services work in 9/11? Four ISPs told me they couldn't get through to their upstream's toll-free customer service numbers for most of the day on 9/11. And one ISP told me their teleconference service couldn't set up a call for unspecified reasons. There have also been several reports in the newspapers, and from customers that customer service call centers were evacuated, so there was no one to answer the call if it did get through. All the carriers I asked replied their systems worked. I'm trying to figure out if these were isolated problems or widespread. How well did your NOC-to-NOC communications work?

1 0

Re: Register.com contact
by Jim Popovitch 13 Oct '01

13 Oct '01

--- kysi ferul <redwingblakburdz(a)yahoo.com> wrote: > > Son! What the hellkind of a name is POO POO BITCH? Don't lie! It's Intelligent Russian, yours? Nevermind, it's already been revealed. -Jim P. > Jim Popovitch <jimpop(a)yahoo.com> wrote: > Yes, Matt quickly responded to my issue and my concerns were > fully addressed. Thank you for following up on this as well. > > -Jim P. > > --- "Jordyn A. Buchanan" wrote: > > At 6:00 AM -0700 10/12/01, Jim Popovitch wrote: > > >If there is a Register.com engineer listening, please contact me off-list. > > > If > > >not, does anyone here have any indepth knowledge of Register.com's DNS > > layout? > > > > Although Matt's already responded, we also have an e-mail address: > > > > isphelp(a)register.com > > > > for assistance to ISPs (and, why not, other network operators) who > > are not direct customers of ours, and consequently do not have access > > to the support resources of our Global Partner Network. > > > > The address is answered by smart, technical people (all of whom used > > to work for ISPs). > > > > Jordyn > > > __________________________________________________ > Do You Yahoo!? > Make a great connection at Yahoo! Personals. > http://personals.yahoo.com > > > > > Kysi Ferul redwingblakburdz(a)yahoo.com > > > > > > --------------------------------- > Do You Yahoo!? > Make a great connection at Yahoo! Personals. __________________________________________________ Do You Yahoo!? Make a great connection at Yahoo! Personals. http://personals.yahoo.com

1 0

The Cidr Report
by CIDR Report 13 Oct '01

13 Oct '01

This is an auto-generated mail on Fri Oct 12 23:00:02 PDT 2001 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. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. NEW: Check http://www.employees.org/~tbates/cidr-report-region.html for the regional version of this report. NEW: Check http://www.employees.org/~tbates/autnums.html for a complete list of autonomous system number to name mappings as used by the CIDR-Report. 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 GX Networks for giving me access to their routing tables once a day. Please send any comments about this report directly to CIDR Report <cidr-report(a)cisco.com>. ------------------------------------------------------------------------------ CIDR REPORT for 12Oct01 0) General Status Table History ------------- Date Prefixes 051001 104449 061001 104665 071001 104597 081001 104752 091001 104769 101001 104817 111001 105289 121001 104773 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- *** Bogus 1.0.0.0 from AS7623 AS Summary ---------- Number of ASes in routing system: 11764 Number of ASes announcing only one prefix: 7013 (3982 cidr, 3031 classful) Largest number of cidr routes: 872 announced by AS701 Largest number of classful routes: 1406 announced by AS701 1) Gains by aggregating at the origin AS level --- 12Oct01 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS1221 1232 947 285 23.1% Telstra Pty Ltd AS701 1406 1185 221 15.7% UUNET Technologies, Inc. AS4151 304 172 132 43.4% USDA AS16473 201 76 125 62.2% Bell South AS577 304 185 119 39.1% Bell Advanced Communications Inc. AS13999 132 16 116 87.9% Mega Cable S.A. de C.V. AS4293 380 271 109 28.7% Cable & Wireless USA AS6595 167 60 107 64.1% DoD Education Activity Network As AS7018 777 672 105 13.5% AT&T AS721 366 266 100 27.3% DLA Systems Automation Center AS705 262 162 100 38.2% UUNET Technologies, Inc. AS2048 216 116 100 46.3% State of Louisiana AS4755 199 122 77 38.7% Videsh Sanchar Nigam Ltd. Autonom AS11686 215 138 77 35.8% Education Networks of America AS1239 481 407 74 15.4% Sprint AS7046 331 261 70 21.1% UUNET Technologies, Inc. AS4200 142 74 68 47.9% Apex Global Information Services, AS3464 162 95 67 41.4% Alabama SuperComputer Network AS12302 100 34 66 66.0% MobiFon S.A. AS724 216 151 65 30.1% DLA Systems Automation Center AS6471 129 64 65 50.4% ENTEL CHILE S.A. AS17557 128 66 62 48.4% Pakistan Telecom AS19632 70 11 59 84.3% Metropolis Intercom S.A. AS16758 63 6 57 90.5% IKON Office Solutions AS209 309 254 55 17.8% Qwest AS306 60 6 54 90.0% National Guard Bureau AS226 145 93 52 35.9% Los Nettos AS400 135 84 51 37.8% Headquarters Standard Systems Cen AS17561 111 60 51 45.9% Internet service provision to Wes AS1 529 478 51 9.6% BBN Planet 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