- NANOG - lists.nanog.org

Re: Palo Alto Power Hit
by Sean Donelan 09 Feb '99

09 Feb '99

Apparently my normal sources inside the carriers got stomped on by senior management, and aren't allowed to talk to me anymore. So here is a summary of unofficial reports from various unofficial sources. The West Coast is experience severe weather, including storms and flash flooding. There are multiple weather advisories up and down most of the coast. Approximately 55,000 people are without power. At the moment, no reported deaths due to the storms. Internet related incidents There were power problems through the early morning hours. A major power surge hit the Palo Alto grid at 7:16am PST. I haven't seen any SCADA information on just how large the surge was. This appears to be the instigating factor for several carrier outages. Several significant Internet trunks pass through the Palo Alto area. Customers of several carriers reported problems including MCI/Worldcom/UUNET/MFS, GTE/BBN, and Sprint. One person reported loss of residential phone service, which may indicate Pacific Bell was also affected. A lot of dead routes, and partially routed CIDR blocks seem to indicate those backbones may have been partitioned for some time. UUNET and MFS customers reported loss of a Palo Alto node. I don't know if this referred to their equipment in the PAIX building, or at another Palo Alto location. MFS had a power problem at PAIX a few years ago, but elected to use utility power instead of PAIX power. PAIX reported their power equipment absorbed the surge, and continues to operate normally. BBN at Stanford appeared to have some communication problems, no word if any rats were implicated. MAE-West-San Jose, Mae-West-Ames, and PacBell AADS appear unaffected. Sprint didn't appear to have any circuits down, but had enough problems with the few people they peer with externally, that Internet routing wasn't working well. A common report was the power surge either blew the fuses, or the entire power supply on a MFS OC192 piece of equipment. This may be the source for some reports of a fiber cut in the area. Most problems cleared up around 9:15PST after the fuse/equipment was repaired. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

ICANN forces the issue
by Henry Linneweh 09 Feb '99

09 Feb '99

ICANN Releases Guidelines For Domain Registrars http://www.internetnews.com/bus-news/article/0,1087,3_65921,00.html Hopefully this will bring some form of sanity to the process. Henry R. Linneweh

1 0

Palo Alto Power Hit
by Sean Donelan 09 Feb '99

09 Feb '99

The City of Palo Alto had a power problem early this morning, estimated at 7:30PST 9-Feb-1999. Portions of the city were without power, and there are some reports of some telelcommunications carriers in the area being affected. So far none of the carriers I've contacted would confirm or deny any problems, although some customers of carriers did report problems. P.S. The Digital/Compaq PAIX sent a note saying they were NOT affected. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

3 2

Fiber Outage
by Tim Wolfe 09 Feb '99

09 Feb '99

FYI: I have heard that there is a fiber cut in Palo Alto that has directly affected 1.2 Gbps of capacity into PA... Tim ---------------------------------------------------- Timothy M. Wolfe | Why surf when you can Sail? tim(a)clipper.net | Join Oregon's Premier Sr. Network Engineer | Wireless Internet Provider! ClipperNet Corporation | http://www.clipper.net/ ----------------------------------------------------

2 1

SNMP Hub management tools
by Matt Braun 09 Feb '99

09 Feb '99

Since the System monitoring query had such good results, I am going to try a variation. I am looking for SNMP management tools (windows or Unix) that can use multiple MIBS for an environment with hubs from several different vendors. The tools need not be GUI, and I am espically interested in 'free' tools. The functionality I am looking for includes (but is not limitted to): gathering port / board pps and bps information port link status the ability to determine what port an IP addresses / MAC addreses is connected to enable / disable ports reset hub / hub management Don't bother reporting on Openview and Optivity...I know about those :-) Please send responses to me personally (with URLS or other appropriate pointers) and I will digest / sumarize them and send them to the list. Matt

2 2

anti-smurf info
by Charles Sprickman 09 Feb '99

09 Feb '99

Hi, Just to let anyone using 3Com/USR gear with "HiPer ARC" term servers know that the latest release supports a new feature that will validate outgoing packets for the proper IP address. Release 4.1.59-1 includes a feature called "SAA" or "Source Address Assurance". It's basically an auto filter that will only let users source packets from the address they are assigned when they dial in. It can be globally applied or triggered per-user via Radius. This is a free download, no service contract required... Thanks, Charles -- =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork(a)inch.com access(a)inch.com | = =----------------=

1 0

Re: NIC database/whois
by Robert Szarka 09 Feb '99

09 Feb '99

At 08:11 PM 2/7/99 , Becki Kain wrote: >anyone else noticed the NIC "losing" a set of domain registrations, around >the time of January 11 (during their "speculator" issues), where the NIC >took the modify, modified the domain, then reset it to it's previous >settings (from January 9)? Something similar may have happened to one of the domains hosted here, but I think it was at an earlier date. Submissions--even ones that were acknowledged--were lost over the past month, that's for sure, despite their plea for us not to resubmit! >also, is there a way to do the old "whois server <server NIC name>" to >show everything a server is registered for? I can't seem to get that to >work, no matter what whois I try. There is a form somewhere on their site for requesting that roughly equivalent info be sent via email. It took them a couple of days to get it to me, as I recall, but it did work when I tried it last month. Ah, here it is: http://rs.internic.net/reports/ -- Robert Szarka Managing Partner, Operations DownCity, LLC +1 860 823 3000

6 5

Re: NIC database/whois
by Forrest W. Christian 09 Feb '99

09 Feb '99

On Tue, 9 Feb 1999, Jon Ribbens wrote: > This seems not to work anymore these days. Hmmm.... whois lewis.mt.net # whois ns01.backupdns.com [No name] (NS31832-HST) Hostname: NS01.BACKUPDNS.COM Address: 206.127.77.91 System: ? running ? Record last updated on 30-Sep-97. Database last updated on 8-Feb-99 05:16:01 EST. # whois "server ns31832-HST" Complete Computing Services (TAMECT-DOM) TAMECT.ORG Complete Computing Services (ICS-CO-DOM) ICS-CO.COM Cybervisors, Inc. (CYBERVISORS-DOM) CYBERVISORS.COM Works for me. The only gotcha is that if you have over 50 responses, you need to use the online whois via telnetting to internic.net. - Forrest W. Christian (forrestc(a)imach.com) ---------------------------------------------------------------------- iMach, Ltd., P.O. Box 5749, Helena, MT 59604 http://www.imach.com Solutions for your high-tech problems. (406)-442-6648 ----------------------------------------------------------------------

1 0

URGENT: Missing AIRONET Wireless Card from NANOG 15
by John M. Brown 09 Feb '99

09 Feb '99

Would the person who's driver's lic is B057253 please return the AiroNet wireless card you borrowed at NANOG 15. Thank you jmbrown(a)ihighway.net

2 1

Re: Why the temptation for dial users to crank back rwin/mtu?
by Aron Sedlack 08 Feb '99

08 Feb '99

> It's always been my belief that the 576 values were generated by hosts > that didn't support Path MTU discovery and wanted to be conservative > and avoid fragmentation. Fair enough.. .... > apparently there's some performance value in this (at least to the .... > > MTU - at least this makes a little bit of sense.. If they're doing > HTTP/1.0 stuff with parallel connections then a smaller MTU is going > to make that parallelization latency much more effective and perceived > performance will go up some.. it doesn't impact full document > retrieval time though (at least not positively!).. are dial links > really lossy enough that chopping the segment size to 1/3 is a big win > in retransmit time or are the win95/98 stacks really braindead enough > that they don't do pmtud so are just trying to dodge fragmentation? I > found it really odd that [7] which I use all the time to track > features in a myriad of shipped OS's actually has a blank entry for > pmtud on both of those (neither yes nor no..) This is discussed in depth in RFC1191 and W. Richard Stevens' book "TCP/IP Illustrated Volume 1" (see page 29-31). Aron

1 0