- NANOG - lists.nanog.org

Re: Carrier reliability and diversity
by Richard A. Steenbergen 06 Apr '01

06 Apr '01

On Thu, Apr 05, 2001 at 03:39:10PM -0700, Sean Donelan wrote: > > The air line reservation system Galileo had significant problems > earlier. > > Excerpt from Reuters: > "The outage began about 8:30 p.m. Mountain Daylight Time on Wednesday > and lasted until 10:55 a.m. MDT on Thursday, said Beth Tennis, vice > present of enterprise networks for Quantitude, Galileo's Denver-based > networking subsidiary. It affected three of the four T-1 high-speed > data transmission lines supplied to Galileo by AT&T Corp., said > Beth Tennis" 4 T1's were down in Denver? Stop the world, I want off. :P You missed the bigger story about the AOL Instant Messanger outtage for a large portion of the day (which I heard lots about from all my AIM loving friends). Doubtless many thousands of network engineers were cut off from their vital lines of communication. > Although I've found AT&T has the highest reliability of all the carriers > I've used. Redundant links from the same carrier frequently have a Personally I've found AT&T to be a packet motel, packets go in but they don't come out... To each their own... -- Richard A Steenbergen <ras(a)e-gerbil.net> http://www.e-gerbil.net/ras PGP Key ID: 0x138EA177 (67 29 D7 BC E8 18 3E DA B2 46 B3 D8 14 36 FE B6)

4 4

Presentation topics
by Susan Harris 06 Apr '01

06 Apr '01

Greetings, and thanks to everyone who made suggestions for future NANOG presentations on the Atlanta attendee survey. Here are some of the topics you said you'd like to hear about: - Use of new BGP attributes (best current practices overview) - Use of the Internet Routing Registry in day-to-day network operations - MPLS traffic engineering in the core - Operational experience with large-scale enterprise VPNs - Experiences with provisioning redundant fiber paths - Operational experience with IPv6 migration - Wide-area deployment experience with VOIP - Experiences with providing large-scale XDSL service It'd be great if we could hear talks on some of these topics -- or other subjects you'd like to suggest -- in Scottsdale. If you'd be interested in presenting, please send a one- or two-paragraph abstract describing the talk to nanog-support(a)nanog.org by April 16. Thanks -- Susan Harris

1 0

Northern Viriginia Power
by Sean Donelan 06 Apr '01

06 Apr '01

On Thu, 05 April 2001, John Starta wrote: > The service interruption was apparently a result of a major regional power > failure in Northern Virginia. I'm curious whether it was AOL or their > providers who suffered from the power failure. I would expect AOL would > have back-up power. > > http://www.techtv.com/news/internet/story/0,24195,3320700,00.html Was anyone else effected in Northern Virginia? Other than a couple of stories about AOL IM being down, I couldn't find any news coverage of a major regional power outage in Northern Viriginia. The only story I found was an electrical fire at Dullas Town Center near the Gap store. VEPCO customer service didn't know of any power outages.

6 5

Sorry, ping
by Roeland Meyer 06 Apr '01

06 Apr '01

Sorry guys, this one got loose. > -----Original Message----- > From: Roeland Meyer [mailto:rmeyer@mhsc.com] > Sent: Wednesday, March 07, 2001 2:58 PM > To: 'idno-discuss(a)idno.org'; LIST Domain Policy (E-mail); LIST ORSC > (E-mail); DNSO. ORG Discuss (E-mail); 'wg-review(a)dnso.org'; NANOG > (E-mail) > Cc: Morfin, Jefsey; Teernstra, Joop > Subject: [wg-review] ping > > > Two things; > Does this list work? > Is my email working? > > MHSC is currently recovering from a one month outage caused > by our access > provider and our upstream ISP failing to play well together. > > We were forced to switch to another ISP and we have lost our > /24 net-block > in the process. I am now trying to shoe-horn 62 servers, > formerly using over > 130 IP addresses, into 32 addresses. SpeakEasy.Net does not seem to be > competent to manage delegation of /24s. > > I still have a lot of work to do ... > > The outage was unannounced and it wasn't technically-based. > MHSC got caught > in the cross-fire between two other companies (our vendors) > having a feud. > The two companies were Covad and DSLnetworks. Our new ISP > (SpeakEasy.Net) > doesn't have the level of competent service that we need so > we are still > looking for another provider. Hopefully, one that will let us > divorce Covad > (MHSC no longer trusts Covad to provide reliable access). > Until then, we are > forced to stay with SpeakEasy, by Covad, or we will suffer yet another > outage, which Covad guarantees to be at least 45 days. Over 60% of our > services will remain off-line until we can recover enough > revenue to pay for > co-lo space. > > Multiple T1's are looking real attractive right now, but > lead-times are > horrible. > > Covad claims non-payment, DSLnetworks claims otherwise. All I > know is that > MHSC got stomped as collateral damage. As far as we're > concerned, anyone > that lets a customer get 18 months, in arrearage, is > mis-managing their > market. IOW, the fault is on both sides. > -- > This message was passed to you via the wg-review(a)dnso.org list. > Send mail to majordomo(a)dnso.org to unsubscribe > ("unsubscribe wg-review" in the body of the message). > Archives at http://www.dnso.org/archives.html >

1 0

What IPv4 Multicast Groups Do You Black-Hole?
by Bill Nickless 06 Apr '01

06 Apr '01

-----BEGIN PGP SIGNED MESSAGE----- I'm working on an Internet Draft that describes current practice for IPv4 Multicast routing. This Internet Draft includes a table of IPv4 multicast groups that I've sort of picked up over time that are generally black-holed. Following is the table that I have; do you use the same table of known-bad groups? Are there any other groups that you believe should be included in this table? 224.0.1.2/32: SGI "Dogfight" game 224.0.1.3/32: RWHOD 224.0.1.22/32: SVRLOC 224.0.1.24/32: MICROSOFT-DS 224.0.1.35/32: SVRLOC-DA 224.0.1.39/32: Cisco's Rendezvous Point Announcement Protocol 224.0.1.40/32: Cisco's Rendezvous Point Discovery Protocol 224.0.1.60/32: HP's Device Discovery Protocol 224.0.2.2/32: Sun's Remote Procedure Call Protocol 229.55.150.208/32: Norton "Ghost" disk duplication software Please send me direct email and I'll summarize the results back to these lists (wg-multicast, nanog, and mboned). Thank you, === Bill Nickless http://www.mcs.anl.gov/people/nickless +1 630 252 7390 PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7 nickless(a)mcs.anl.gov -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com> iQCVAwUBOs0RVKwgm7ipJDXBAQHUUQP9EJOcCFZIsZTv4UH+S3/Hf9pYiWd7XSf9 QXFTwfUL7y31Xke0gp+PNq/Cyc0Xo+vkw6zmLgHQpGrkOW9MMXDSe1O2jsuJut/8 a2RYlnysl7U13QZSu3CZoElJAaAjtLEDAR3auj5cM0jsY3CRgtQ7POhzNMv/nw9R qpXBaCWFlaM= =LyCp -----END PGP SIGNATURE-----

1 0

Re: Carrier reliability and diversity
by Sean Donelan 06 Apr '01

06 Apr '01

On Thu, 05 April 2001, "Richard A. Steenbergen" wrote: > 4 T1's were down in Denver? Stop the world, I want off. :P > > You missed the bigger story about the AOL Instant Messanger outtage for a > large portion of the day (which I heard lots about from all my AIM loving > friends). Doubtless many thousands of network engineers were cut off from > their vital lines of communication. I don't use AIM, no one I know uses AIM. Other than spending 15 minutes removing it from my PC after I install Netscape, AIM has little effect on my life. I went to the AOL IM web site http://www.aol.com/aim/ and AOL has no mention of any outages on its web page. Perhaps someone from AOL would like to explain why IM keeps failing? On the other hand, I was trying to check reservations on a European airline for a trip, and Galileo being out of commission did affect my life a bit. It was nice that Galileo's spokesperson explained what was happening, so I didn't assume that the crappy service I experienced wasn't typical of Galileo, but was due to a network outage. As I mentioned before, the interesting thing about outages isn't if you are up or down. But if you are down while your competitors are up.

1 0

Carrier reliability and diversity
by Sean Donelan 05 Apr '01

05 Apr '01

The air line reservation system Galileo had significant problems earlier. Excerpt from Reuters: "The outage began about 8:30 p.m. Mountain Daylight Time on Wednesday and lasted until 10:55 a.m. MDT on Thursday, said Beth Tennis, vice present of enterprise networks for Quantitude, Galileo's Denver-based networking subsidiary. It affected three of the four T-1 high-speed data transmission lines supplied to Galileo by AT&T Corp., said Beth Tennis" Although I've found AT&T has the highest reliability of all the carriers I've used. Redundant links from the same carrier frequently have a common vulnerability, the carrier. For things which absolutely can't go down, I assume even AT&T will have occasional problems. Personally I used AT&T Worldnet and Earthlink, alternating depending on who had a problem. That's high praise for me.

1 0

Re: Major Qwest ATM outage.
by Sean Donelan 05 Apr '01

05 Apr '01

On Thu, 05 April 2001, "Kevin Oberman" wrote: > As was reported when Qwest did the software upgrade to all of their > Lucent (Ascend) 550s, the Qwest IP net does not use ATM. It is > entirely POS. As a result, the Qwest IP side was not impacted. > > This does look like the sort of like the cascading PNNI routing > problems that the big upgrade last week was supposed to have fixed. I > think the Lucent folk still have problems to deal with. Folks have reported that qwest said the cause for the failure was an OC48 going down, which led to instabilities within their network.

1 0

Re: Major Qwest ATM outage.
by Sean Donelan 05 Apr '01

05 Apr '01

On Wed, 04 April 2001, Scott Call wrote: > For any of us unlucky enough to have Qwest ATM service, they are > having a major outage. Started exactly at midnight eastern, and the MAST > person I spoke with made a reference to lucent conference calls, so I'm > betting on a bungled software upgrade or something similar. > > Qwest Master ticket # 219247. It doesn't seem to be affecting Qwest's IP network. Qwest's IP network status page reports 100% availability. http://stat.qwest.net/flash/current.cfm I don't have an account to see Qwest's ATM status page.

2 1

RE: Faster 'Net growth rate raises fears about routers
by Roeland Meyer 05 Apr '01

05 Apr '01

> From: Sean Donelan [mailto:sean@donelan.com] > Sent: Tuesday, April 03, 2001 5:26 AM > > On Mon, 02 April 2001, Roeland Meyer wrote: > > From the article: > > <quote> > > "Half of the companies that are multihomed should have > gotten better service > > from their providers," says Patrik Faltstrom, a Cisco > engineer and co-chair > > of the IETF's Applications Area. "ISPs haven't done a good > enough job > > explaining to their customers that they don't need to multihome." > > </quote> > > Why would a rational customer pay for a second connection > (usually more than doubling their cost) if a single connection was > satisfactory? Although providers try to vertically integrate > their operations, time and time again, > vertical integration tends to increase the risk for the customer. Because, if the ISP goes out of business the lead-times for getting a new connection exceed 40-days. This was my point on invoking the DSLnetworks/Covad spectre (it's the one I know the most details of). Also reference FlashPoint, NorthPoint, et al. We are now suffering over 100,000 businesses being disconnected from the Intenet because their upstream went tits-up. So, don't tell me it doesn't happen. This is the original reason for having multi-homing with two different upstreams. In most cases, the connection itself was rock-solid up until the time the lights went out. In many cases, there was no warning. In ALL cases, the outage exceeded 4-weeks unless the site was multi-homed somehow. My latest quote for a new DSL connection is 42 days. T1s are 6-8 weeks. Bigger pipes are 2-6 months for the fastest response, many cases are longer. Back to business failures, the DSL world is looking rocky at best. Rythms isn't looking very solid and neither is Covad. Some of the NorthPoint customers are not going with either, electing to go with the local RBOC instead (despite the hassles and long lead-times). What many businesses really need is true multi-homing. > Mid-level providers serve an important function in the > Internet hierarchy. > Multi-homing works well with mid-level providers aggregating > local routes, > and managing redudancy between long-haul providers. If you > don't use a > mid-level provider, to achieve the same reliability you end > up needing to > be your own mid-level provider. Exactly. You also save some monthly recurring cost. > Why can't a large provider operate their network as a set of mid-level > networks, and connections to multiple long-haul networks. They could. But, they dont.

7 7