January 2001 - Test - lists.nanog.org

Re: What is going on in the PAC NW (Microsoft Outage)
by Hank Nussbacher 25 Jan '01

25 Jan '01

At 11:35 24/01/01 -0800, Tony Rall wrote: > >Is there any information available about Microsoft and MS related >companies > >being unavailable > >I'm seeing about 50% packet loss to all 4 microsoft.com nameservers. I >can't get any dns responses from them. The following is all hypothesis: Reading the MS announcement that says "At 6:30 last night, a configuration change was made by a Microsoft technician to the routers on the edge of Microsoft's DNS network", and adding in the 50% packet loss you list above, it looks like the MS technician installed some sort of Cisco TCP/UDP rate-limit on some interface along the data path. -Hank

1 0

Labeling and naming
by Kurt Erik Lindqvist 25 Jan '01

25 Jan '01

For a project I am currently working on I stumbled upon the following. What is the best way to lable and name equipment? Although this applies to all equipment such as SDH ADMs, IP, ATM etc I realised that it seems to be hardest to find a sensible convention for IP equipment. Preferably I would like to find a convention that fits all, but I guess that is utopia. So, since list contains, PTTs, Telcos, ISPs and wannabees is there any good common scheme or pointers to something useful? - kurtis -

5 6

History: lengthy outages
by Sean Donelan 25 Jan '01

25 Jan '01

On Wed, 24 January 2001, jlewis(a)lewis.org wrote: > Somebody bitched a router config, and it took 22.5 hours to figure it out? > That's the sort of goof you might expect from a mom and pop ISP with a > hundred customers and virtually no IP clue. I'll be shocked if multiple > people (at multiple levels) aren't fired over this. Screwing up happens. > Taking this long to figure out what you (or even for others to figure out > what someone else) screwed up is just absolutely unbelievable. That's a bit unfair. There have been a number of lengthy outages. AS7007 router configuration problem: April 25 1997 lasted 2 hours AOL (ANS router configuration problem): Aug 7 1996 lasted 19 hours ATT frame-relay switch errors: April 13, 14 1998 lasted 26 hours BBN standard power failure: October 11, 1996 lasted about 12 hours(off and on) NETCOM router configuration error: June 20 1996 lasted 13 hours Sprint database problems: September 3 1996 lasted 5 hours NSI root server corruption (operational error): July 16 1997 lasted 4 hours PacBell configuration problems: January 30-31 1997 lasted 48 hours UUNET frame-relay problems: July 1 1997 lasted over 24 hours UUNET cisco/bay router problems: November 7 1997 lasted 5 hours Worldcom frame-relay switch errors: August 1999 lasted 9-10 days If I skipped your favorite provider, have no fear. More than likely they've also had (or will have) a lengthy outage at one time or another. One interesting thing I found was providers seem to have substantial outages shortly after announcing "100% Uptime." But somehow the net continues to stumble forward.

4 3

peer "sanity" filters - best practices?
by David P. Maynard 25 Jan '01

25 Jan '01

Several times over the past few years, the NANOG list has discussed the topic of if or how non-transit peer BGP announcements should be filtered. I searched through the archives, but couldn't find where anyone had published a summary of best practices for filtering announcements from peers that aren't one of the "top N" (for some debatable value of N) NSPs. What I am looking for is a set of filters that implement a sanity check to catch some of the recurring BGP config problems. For example, if SmallTime Internet suddenly starts announcing that they provide transit for UUNET, I don't want there to be any chance that I will start sending my UUNET-bound traffic to SmallTime. Some of the "rules" I can think of would be: - peers should not be announcing transit routes from the top N transit providers (implemented via AS filter-list blocking the top transit ASNs) - peers should not be announcing RFC1918 networks (implemented by prefix-list) - peers should not be announcing the same networks that "I" originate - peers should not be announcing a default route - peers should not announce more than n-thousand routes (implemented using the Cisco 'maximum-prefix' option) These rules would theoretically be applied to any peers who weren't part of the "top N." In practice, I'm thinking of peers that announce 1 to a few thousand prefixes. Is the idea even feasible? If so, what other rules make sense? One other option would be to limit announcements to /24 and shorter. Is there any agreement on the "top N" ASNs that "normal" peers shouldn't be announcing? Thanks. -dpm P.S. My interest is not just academic. These filters will get installed on one of my customers' networks. They have had a fair number of problems with peers announcing routes that they shouldn't and I am looking for ways to help reduce the problem. -- David P. Maynard, Flametree Corporation Network Infrastructure and Monitoring Solutions EMail: dpm(a)flametree.com, Tel: +1 512 670 4090, Fax: +1 512 670 4091 --

3 2

Re: What is going on in the PAC NW (Microsoft Outage)
by Steven M. Bellovin 25 Jan '01

25 Jan '01

In message <OFF5C3FF78.0778E224-ON882569DE.006B3A50@LocalDomain>, "Tony Rall" w rites: > > >>Is there any information available about Microsoft and MS related >companies >>being unavailable > >I'm seeing about 50% packet loss to all 4 microsoft.com nameservers. I >can't get any dns responses from them. > >As, I think, Greg Woods mentioned, it's a pretting weak setup putting all >of your nameservers on what appears to be the same network. > >I am amazed that this has taken so long to fix. Any chance their nameservers are being DDoSed? --Steve Bellovin, http://www.research.att.com/~smb

5 4

Re: Labeling and naming
by Michael Shields 25 Jan '01

25 Jan '01

In article <NEBBLMDAGLPOAGJMOFHAMEKCDBAA.karwas(a)ifxcorp.com>, "Przemyslaw Karwasiecki" <karwas(a)ifxcorp.com> wrote: > <2 letters of ISO country code> > http://www.bcpl.net/~jspath/isocodes.html > <3 letters of airport city code> > http://www.ufreight.com/faq/airport_code/airport_code_by_ac.html You don't need to rely on secondary compilations for these: http://www.din.de/gremien/nas/nabd/iso3166ma/ http://www.iata.org/codes/ -- Shields.

2 1

More intelligent MS/DNS article.
by BillT＠Mahagonny.com 25 Jan '01

25 Jan '01

A much more informed article about the MS/DNS problem is on the wired site at: http://www.wired.com/news/business/0,1367,41387,00.html I have already pointed one manager who wanted me to fix the problem there... -- BillT(a)Mahagonny.com | PGP KeyID#: 0xFB966670 -By the year 2019, one third of the worlds population will be Elvis impersonators.

3 3

Re: Microsoft spokesperson blames ICANN
by Richard A. Steenbergen 25 Jan '01

25 Jan '01

On Wed, Jan 24, 2001 at 09:16:14PM -0800, Christian Nielsen wrote: > > ultradns does this and has a great product. I particularly like this comparison on their webpage: Security Managed DNS Service: Built from the ground up to deliver secure and safe DNS service UltraDNS does not allow access to server source code BIND: The SANS Institute reports that BIND is the #1 security vulnerability for Internet servers Hackers have access to source code -- 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)

2 1

Network diversity Software diversity
by Sean Donelan 25 Jan '01

25 Jan '01

Although several people have leaped on the apparent lack of network diversity in Microsoft name servers, there is a more general problem which also affects networks using BIND. Using FreeBSD and BIND on *ALL* your name servers may be just as bad a practice as using Windows 2000 and Microsoft DNS on *ALL* your name servers. I still think NSI is taking a tremendous risk using identical servers for all their GTLD-servers, even though they are geographically distributed. You might try using UltraDNS on half your critical nameservers and BIND on the other half. And even using Solaris on some of the boxes and AIX or Linux, or NetBSD on the others. This is not because I think one or the other has a fatal flaw, but because software is a hard beast to manage. The idea behind diversity isn't you will never have an error. But the errors are unlikely to strike both servers at the same time. If you use identical servers and identical software, no matter how geopgrahically dispersed, a software flaw will affect all your servers at the same time. Software is what crashed the ATT long distance network, the Worldcom frame-relay network, and even the one incident which took out the entire ARPANET.

3 2

RE: SSH on other Cisco models
by Roger Choate 25 Jan '01

25 Jan '01

The SSH client has been integrated into Release 12.1(3)T on the C17x0, C25xx, C26xx, C36xx, C4x00, C7x00, and C12000 Roger...

1 0