- NANOG - lists.nanog.org

Re: Major fiber cut in Tyson's Corner area
by Sean Donelan 13 Apr '99

13 Apr '99

ferguson(a)cisco.COM (Paul Ferguson) writes: >I just heard on the local news that 3 fiber optic cables, as well as >one large copper bundle was cut in the Tyson's Corner area (Northern >Virginia). No idea what impact it may have on net traffic, although one >fiber strand was reported as belonging to MCI. > >For those who may not know, MAE-East is in the Tysons Corner vicinity. Things that make you go Hmmm! Yesterday I received a very strange phone call from a person claiming to be with MCI/Worldcom wanting to talk to me about verifying Y2K readiness of our equipment at MAE-East. He wanted to verify the address, and wanted to send a tech over to check serial numbers of equipment. Our MCI/Worldcom sales rep says he knows nothing about MCI/Worldcom doing this, nor why MCI/Worldcom wouldn't already know the address of their own building. I wonder if he just was fishing, to find out where to send the backhoe :-) -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1

Re: Major fiber cut in Tyson's Corner area
by Avi Freedman 13 Apr '99

13 Apr '99

Paul Ferguson (ferguson(a)cisco.com) wrote: : For what it's worth: : I just heard on the local news that 3 fiber optic cables, as well as : one large copper bundle was cut in the Tyson's Corner area (Northern : Virginia). No idea what impact it may have on net traffic, although one : fiber strand was reported as belonging to MCI. : For those who may not know, MAE-East is in the Tysons Corner vicinity. : - paul In one area, in particular (which affects CAIS, Servint, and one of netaxs's POPs) - >From MFS - "The YF system between 81b and q37 is still down; their techs are still working on it." The last update was at 4pm, which said that due to fact that Bell Atlantic owns the duct in which the accident occurred, this could be an extended outage. The outage was caused by a company called Fishell. They were boring next to the BA duct and hit the fiber line multiple times and in multiple locations. There are currently 41 DS3's and 1 OC3 down. He didn't know who the OC3 belonged to. Earlier today, an OC12 belonging to L3 was down, but it has now been restored. Then from MFS - The cut is much more involved than was thought previously. MFS fiber guys went to the site to find the cables covered in concrete, and mixed in with the whole BA damaged duct. It looks like right now MFS is going to have to wait until BA fixes the duct before they can even attempt to fix the fiber. At 12:30 this afternoon, there was an estimated ETA of 2 to 3 hours downtime. That's now been changed to read an "extended downtime". The master ticket number is 412 573. So they managed to bore into the duct then fill it with concrete. Now, Bell is fine (and has dual-entrance around the problem), so as you can imagine, they do NOT want to let MFS un-conrete the duct and repair. Fun fun. Still, apparently 6861 Elm St, Vienna, VA, with at least TWO full-up OC48s of capacity, appears not to have dual-entrance... If anyone is willing to home a customer onto their SMDS circuit for a day, in exchange for various tricks and favors, the noc(a)netaxs.com folks would like to know. SMDS is primarily a backup for them, and 6861 is a backup/2ndary POP for netaxs, but there is one customer so far-out that they had to use SMDS as a primary point of connection. Avi

1 0

2q99 in-addr audit complete
by bmanning＠ISI.EDU 13 Apr '99

13 Apr '99

Hi, The 2q99 in-addr audit is complete. The results are posted at: http://www.isi.edu/div7/people/bmanning.home/in-addr-audit.html Your comments and observations are encouraged. -- bill "When in doubt, Twirl..." -anon

1 0

Re: FYI ONLY >> Non-Operational (at least directly)
by Sean Donelan 13 Apr '99

13 Apr '99

randy(a)psg.COM (Randy Bush) writes: >> University of Hawaii' external data services were effected (Primary and >> Secondary DNS were not functional). > >hmmmmm. wonder how that could hapen. I don't track Hawaii that closely anymore since Hawaii Public dropped DRA for another vendor. But Hawaii was always the most unusual circuit in our network. I never did figure out why, but the 'landing point' for the Hawaii state government circuit was Chicago, Illinois. It appears Hawaii.EDU at least has arranged for an off-island backup of its DNS. There may have been some other configuration problem, but at first glance Hawaii.EDU and Hawaii.NET had a chance of keeping its DNS functioning. Hawaii.GOV's NS records have a slight problem, which may have killed it when connectivity was lost. And things like HI.US would have been completely dead. The US-domain sucks in many states, so that's not too unusual. DRA made a standing offer to the US-domain administrator to act as one of the primary or secondary servers for any LIB.xx.US. AT&T may handle the physical circuits, but the Internet service for the University of Hawaii is handled by UUNET. So there are lots of different people you can ask why the redundancy failed, or if it was ever present. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1

Re: FYI ONLY >> Non-Operational (at least directly)
by Robert Mathews-ICICX 13 Apr '99

13 Apr '99

On Tue, 13 Apr 1999, Chris Yarnell wrote: > Hmm. We secondary hawaii.edu and hawaii.net. Shouldn't have been a total > outage. Chris: Hello... I do realize that you provide us with Secondary Service.. if you cannot GET OFF the island, that doesn't matter much does it? :) Such was also the case INTER-ISLAND and even INTRA-ISLAND.. Best.

2 1

OPS: BGP spew from ASN 7374
by Sean Donelan 13 Apr '99

13 Apr '99

ASN 7374 appears to be announcing most of the Internet through the CIX. Could whoever their upstream provider is supposed to be, please contact them. Cisco: could we please have more config memory, so we can load access-lists for even huge BGP peers? -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

6 5

FYI ONLY >> Non-Operational (at least directly)
by Robert Mathews-ICICX 13 Apr '99

13 Apr '99

Gentlepeople: For those who are interested, there was a significant outage begining at approximately 9:30 Am or so,and ending approximately 2:00 Pm (+/- few mins..), past Saturday, here in Hawaii. The outage was caused by a contractor operating a 'backhoe' which severed an AT&T Cable. AT&T is at a loss, in explaining why redundant systems did not take up the slack. They are investigating.. All sorts of functions from Paging to Retail Service Systems to Transit and Inter-Connect Services were effected. University of Hawaii' external data services were effected (Primary and Secondary DNS were not functional). Furthermore, 2nd and 3rd tier services (communities whose data service needs are supported by the University.. State Gov.) were also among the communities that were effected. AT&T is outwardly being responsible about this -- suggesting that effected AT&T consumers immediatey contact their account reps at AT&T to begin processes relating to settlement.. All I wish to know is: WHO was it that let that WILD BACKHOE get on a barge for Hawaii? Hmmmm? All the best.

2 1

How good is the CIX's connect?
by Matt Hempel 12 Apr '99

12 Apr '99

I'm debating whether to buy a crossconnect to CIX's 7513 and use it for UUNet traffic. I tried pushing 701 through the shared FDDI and it crawled, but that could have been the FDDI. Does anybody have any good experience with routing through CIX? I noticed one of my transit providers is using it for UUNet. Does anybody know UUNet's connection to the router and how saturated it already is? --matt hempel

2 1

Testing backup communication systems between operators
by Sean Donelan 09 Apr '99

09 Apr '99

The North American Electric Reliability Council conducted its first Y2K telecommunications capability exercise. As usual, they report the test was successful; and at no time was any electric customer affected. Twenty- two regional security coordinators (the electric industry's term for "NOC") and 2,000 electric utility personnel participated. Lessons Learned: - There were some incorrect phone numbers among the emergency contacts - Geographic coverage of some radios require relocation of antennas - Personnel require training on the use of backup systems. Some had only recently been installed, and little training occurred prior to the drill - Congestion on the backup systems indicated a need to establish and practice traffic priorities - Some backup transmissions were noisy - A "small number" of backup systems did not work - Severe weather in the Midwest hampered some activities NetOps: When was the last time you tested your backup systems? Or a better question, do you have a backup system for contacting other providers? -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1

NANOG16 -- Call for Presentations
by Craig Labovitz 09 Apr '99

09 Apr '99

* * * * * * * * * * * * * * * * * CALL FOR PRESENTATIONS * * NANOG 16 * * Eugene, Oregon * * May 23 - 25, 1999 * * * * * * * * * * * * * * * * * NANOG, the North American Network Operators Group, will hold its 16th meeting in Eugene, Oregon on May 23 - 25, 1999. NANOG conferences provide a forum for the coordination and dissemination of technical information related to large-scale (i.e. national/international) Internet backbone networking technologies and operational practices. NANOG meetings, held three times each year, include two days of short presentations, plus afternoon/evening tutorial sessions. Meetings are informal, with an emphasis on relevance to current backbone engineering practices. The conference draws around 500 participants, mainly consisting of engineering staff from large national service provides, and members of the research and education community. Now in its fifth year, NANOG evolved from the NSFNET "regional-techs" meetings, where technical staff from the regional networks met to discuss operational issues of common concern. With the emergence of the commercial Internet, NANOG meetings evolved to include a broader base of providers, network operators, and researchers. NANOG 16 will be hosted by the University of Oregon and Verio. For more information about NANOG, conference hotels, schedules, and logistics, see: http://www.nanog.org ------------------------------------------------------------------------------ CALL FOR PRESENTATIONS NANOG invites presentations on backbone engineering, coordination, and research topics. Presentations should highlight issues relating to technology already deployed or soon to be deployed in core Internet backbones and exchange points. Previous meetings have included presentations on: - Backbone traffic engineering - Coordination of inter-provider QoS - Deployment experience with queueing disciplines (CAR, RED) - Inter-provider security and routing protocol authentication - Routing scalability in backbone infrastructures - Security issues for the Internet core - Routing policy specification and backbone router configuration - Building large-scale measurement infrastructure - Cooperative inter-provider caching - Alternatives to hot-potato routing - Recommendations on queue management and congestion avoidance - Experience with differentiated services - Reports from next-generation networks (Internet2, CA*net, etc) - Inter-domain multicast deployment - Backbone network failure analysis - Inter-exchange point updates Tutorials have covered topics such as: - BGP case studies - Address allocation and renumbering - External route selection - IP multicast technologies ------------------------------------------------------------------------------ HOW TO PRESENT Submit an informal one- or two-paragraph abstract describing the presentation in email to nanog-support(a)nanog.org. The proposal should be submitted well in advance of the conference. Notification of acceptance is rolling and is usually provided one or two days after receipt of the abstract. NANOG also welcomes suggestions/recommendations for tutorials, panels and other presentation topics. -- Craig Labovitz labovit(a)merit.edu Merit Network, Inc. http://www.merit.edu/~labovit 4251 Plymouth Road, Suite C. (734) 764-0252 (office) Ann Arbor, MI 48105-2785 (734) 647-3185 (fax)

1 0