- Test - lists.nanog.org

Interesting for all Ascend CORE Users ...
by Jan Ahrent Czmok 20 Jul '99

20 Jul '99

Hi! To get further attention of other Ascend/Cascade/Lucent Core Users (e.g. BSTDX-8000/9000 - CBX 550 - and similar) and to get further "tips & tools" everybody is using, i created a mailing-list: ascend-core-users(a)onelist.com Everybody is free to subscribe and to contribute. Jan -- Jan Czmok Gigabell AG Senior Network Engineer Mainzer Landstr. 46 Member of IPv6-Forum 60325 Frankfurt Phone: +49 69 17084-716 Fax: +49 69 17084-701

1 0

OC-12 outage at Mclean,VA
by Tatsuya Kawasaki 20 Jul '99

20 Jul '99

Apparently there is an outage at MClean, VA to Philly and MCLean, VA to Atlanta. It happened round 12:00pm EST. Tatsuya /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ Tatsuya Kawasaki KIVEX.com Unlock the Power of the Internet URL:www.KIVEX.com Phone 301.215.6777 Fax 301.215.5991 /_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

1 0

Re: billing for "friendly" name transfer
by Dan Bustillos - Datalink Computer Services 20 Jul '99

20 Jul '99

Well, Internic does not do credits. As for a name Change you should be able to do an Registrant Name Change Agreement (RNCA). I have done several RNCA's and have never had to pay the 70.00 again. The only problem with a RNCA is that Internic takes forever to process them. Be sure to keep copies as you may need to fax/send it to them many many times. My.02! Thank you, Dan Bustillos Datalink Computer Services (530) 897-6400 (888) 328-4638 ******************* "Error, No Keyboard - Press F1 to continue" Only on a PC would you see this error. Never on my mac.

1 0

double billing for domain names
by Carl Malamud 20 Jul '99

20 Jul '99

It is with some caution that I post this query to nanog, but I consulted with a colleague who runs a root server and he indicated that this note might be of interest to the readership as it is an operations issue that may affect your users. This note concerns what appears to be systematic double-billing for domain names by NSI. Here's how it works: 1) You work for corporation A and have registered a domain name for several years which has an anniversary date of April 1. Each April 1, you receive a bill for $35. 2) On December 31, you transfer that domain name to corporation B, which pays $70, good for two years. 3) On April 1, corporation B will receive a bill for $35 from NSI, despite the fact that the domain name is paid for a two year period. On December 31, I executed such a transfer for a couple dozen domain names. In early February, I received my first duplicate bill from NSI. I raised a considerable stink and eventually got them to cancel the invoice. Since then, I receive a consistent string of bills, each on the previous anniversary date of the domain names. Each time I've raised a considerable stink, but it is very hard to get the double bills cancelled. The manager of the billing department finally reported it to the NSI engineering team in June, and NSI confirmed that this is a systematic problem in their billing machinery. So, here is my query: Do other people also have these double bills or do your customers have this issue? I suspect that NSI does this on a regular basis and there are a lot of NSI customers that are paying money for domain names they already paid for. If each domain name transfer yields $70 in revenue for NSI (paying for two years) and then yields another $35-$70 in double revenue, this seems like it might be a lot of money. I'd appreciate notes from anybody else who has a similar issue or is aware of people with a similar issue so that I can document it as a systematic practice. Regards, Carl Malamud Invisible Worlds http://invisible.net/

3 2

Re: Toronto bell canada central office fire
by Robert M. Enger 19 Jul '99

19 Jul '99

At 02:37 PM 7/18/99 -0400, you wrote: >This report mentions: > However, no automatic power shutdown systems > are currently available.. >which drags us straight into the comp.risks area. > >Telco systems qualify as ultra-high-reliability and the battery >plant of same is the most basic of those. They spend bigbux$ on >having that -48v there, no matter what. If you now do install a >system that will shut same off, I will bet dollars to donuts it >will false at least once, bringing down an office. > >Where do you draw the line? You draw multiple lines: compartmentalize the facility. Run independently fused/interrupted circuits from the battery stack to each region of the building, at least on a per-floor granularity, if not finer. You install water seals between the floors, and install floor-drains. Then, if a floor needs to be hosed down, the water doesn't leak to the floors below. Using HVAC that is not shared between the compartments is also a good idea. Independent smoke evacuation is needed too. Short of structure damaging explosions, you do your best to minimize the fate sharing between the floors, or between separate compartments on each floor. Cost is the hardest issue to contend with in order to improve the reliability of our centralized communications facilities. Every company wants to reduce costs in order to offer lower prices to attract customers. The large communications facility buildings have become central focus points with enormous fate-sharing (voice, Internet, cell phones, ATM-machines and more all go out at once). However rare the occasion that government intervention is desirable, this may be one of those rare occasions. Perhaps we should encourage our regulators to FORCE improved compartmentalization and survivability in our shared tenant communications facilities. How can you motivate a city/politician? What's in it for them? In much the same way some communities currently crow about their enhanced, modern infrastructures in order to attract new businesses, cities could also crow about having building codes that ensure that the modern infrastructures they have worked so hard to attract can actually be relied upon to function. The politician looks like a hero; and no company is free from the cost burden, so equity is maintained. Bob Enger

1 0

3q99 in-addr audit status
by bmanning＠ISI.EDU 19 Jul '99

19 Jul '99

> Hi, > > Past data is at: www.isi.edu/div7/people/bmanning.home/in-addr-audit.html > The run is scheduled to start 01 July 1999. > > -- bill The 3q99 audit is complete. The runtime this quarter was 260.5 hours. Th inital size of the zone has grown while the total number of visable delegations has shrunk. date inital size total zone count 2q1999 120334 708172 3q1999 126856 649331 /8 specifics and other detail will be posted shortly at the above URL. The fourth quarter audit is scheduled to start 01 October 1999. --bill

1 0

Re: Toronto bell canada central office fire
by Sean Donelan 19 Jul '99

19 Jul '99

nathan(a)robotics.NET (Nathan Stratton) writes: >As a volunteer fire fighter I will agree with you on that one. I often >wonder why more people don't sue for damage, I guess there is >little they can do. Some people in fire fighters actually have fun >cutting holes where they don't need cut or flooding places with water >they know don't need it. Our department is very good, but many of them are >not concerned with the property at all. One of the lessons from the Los Angeles CO fire was the danger to firefighters with fires in telecommunication facilities. Fortunately such fires are rare. But that rarity means few departments have any experience with such fires. Hinsdale was a wake up call for the telecommunications industry, L.A. was a wake up call for the fire service. Five years later, NFPA, AT&T and Telcordia (bellcore) are still debating what should be done. For the most part, the experience has not yet reached down to either the local fire departments or the people building data and telecommunication facilities. http://www.nfpa.org/Research/summaries/los_angeles.html -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

6 5

Toronto bell canada central office fire
by Sean Donelan 18 Jul '99

18 Jul '99

I don't know if things are worse when I stay in the country, or when I leave. And, no, my airplane had not entered Canadian airspace at the time of the Bell Canada fire. I believe I was still over Iceland when it started. Here's how the Toronto newspapers covered the story: http://www.globalandmail.ca/gam/National/19990717/UMAINN1.html http://www.thestar.com/editorial/news/990717NEW04_CI-MAIN17.html And here is what a the phone company had to say: http://forums.sympatico.ca/WebX/WebX.cgi?13@190.0iYha9hEaX5^0@.ef9843d http://www.bell.ca/en/corp/aboutbell/newsroom/archives/nr99/nr99e0716.asp While Bell Canada is doing its best at PR damage control, it does point out the importance of not assuming the telephone company is infallible. Even if you believe the phone company claim of 99.999% reliability, stuff will still happen. This is not the first, nor I suspect the last, time a single central office failure had an out-of-proportion impact on the national network. All phone companies seem especially surprised by the affect of office failures on data circuits. They just don't seem to put as high a priority on data as they do on voice. Although Bell (and indeed any carrier) hates giving out information about their network, and how your circuits are actually routed. You need that information to make sure Bell (or some other carrier) doesn't route all your circuits through the same facility. Just because you paid for diversity, doesn't mean you got it or six months later it is still diverse. Even virtual circuits on ATM or Frame-relay pass through a physical switch somewhere. Sometimes I think the carriers don't want to give you the information, because they don't know themselves. After one carrier had a 2-day outage, including several delays due to mistakes in the carrier's records, one of my government customers made the carrier physically walk them through the entire physical circuit route, including every patch board and mux, to prove the carrier now knew where the circuit went. It was interesting :-) But the goal isn't just to point out what was wrong. But also to add any lessons to the knowledge base so we can avoid the same mistakes. The major C.O. fires in New York city, Chicago(Hinsdale), Los Angeles all have reports looking at the causes and effects. And I'm sure the Toronto fire will also have a report. In most C.O. fires, even Hinsdale, the fire itself does very little damage. It is all the byproducts of a fire and fire-fighting which cause the disruption and damage. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

3 2

Corrected urls (Re: Toronto bell canada central office fire)
by Sean Donelan 17 Jul '99

17 Jul '99

>http://www.globeandmail.ca/gam/National/19990717/UMAINN1.html >http://www.thestar.ca/editorial/news/990717NEW01_CI-MAIN17.html -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

TCP tools.
by Forrest W. Christian 17 Jul '99

17 Jul '99

I really can't think of a better place to ask this, so If anyone has any ideas of a place better suited please let me know (no flames please). I'm looking for a (free or quite inexpensive) tool to help diagnose some bizzare TCP problems we're having with some TCP flows stalling exactly 32k into the transfer. This isn't the same file and it's almost exacly 32k each time... but I digress. Is there a tool out there that can sniff a TCP flow and do some basic analysis such as missed acks, duplicate packets, Window Sizes, etc. etc. Mainly, I'm looking at something which can compare what it sees with some semblance of a normal flow and pick out "errors". Other tools to track down stalls would be helpful also. No, I'm not looking for ping tools or flood tools, etc., but instead something which can help me determine why this particular TCP implementation is stalling consistently in serveral different environments so I can go yell at the vendor. I realize that most if not all packet sniffers will provide the information neccessary to do this analysis by hand, but picking apart multiple flows bit by bit can be tedious and error prone, and not something I particularly want to do if there is an easier way. Thanks for all pointers. - Forrest W. Christian (forrestc(a)imach.com) KD7EHZ ---------------------------------------------------------------------- iMach, Ltd., P.O. Box 5749, Helena, MT 59604 http://www.imach.com Solutions for your high-tech problems. (406)-442-6648 ----------------------------------------------------------------------

2 1