July 1997 - Test - lists.nanog.org

Re: Mae-WEST
by Barry A. Dykes 11 Jul '97

11 Jul '97

If I remember right, the 7000 series routers have the env sensors on the arbiter. I don't remember it being on a particular card, so it's not a simple swap :( Barry > At 03:40 PM 7/11/97 -0400, Golan Ben-Oni wrote: > >On Fri, 11 Jul 1997, Eric Kozowski wrote: > >Ironically, our temperature device is now broken in our Cisco. Has anyone > >else had similar problems with them? We now have a number of 7000 series > >routers which report off-the-wall readings. > > > >-Golan > > > > > > > > MFS is in the proccess of installing new cooling units on the roof. They > take up aprox. 1000sqft. So they are at least working on it. > > You should have seen the air lift :) > > > James McKenzie > mcs(a)innetix.com > Innetix, Inc. > (408) 993-9477 > http://www.innetix.com

1 0

Re: Mae-WEST
by Philip Steffora 11 Jul '97

11 Jul '97

Obviously, as a MFS customer that doesn't make me feel a whole bunch better about the situation in San Jose. -phil ================================== Philip Steffora steffora(a)pa.dec.com Operations Mgr. AltaVista - Digital Equip Corp ================================== At 11:25 AM 7/11/97 -0700, Steve Feldman wrote: >Yes, there's a generator. Unfortunately, it doesn't kick in when someone >trips or turns off the main breaker. (This is hearsay; I'm actually out >of the office and am getting my info second-hand.) > Steve

1 0

Re: Mae-WEST
by Sanjay Dani 11 Jul '97

11 Jul '97

>> This gets me thinking about the backup generator that is supposed to be >> online. >> >> Why didn't the generator kick-in before the UPS went down? >Or, lets say, an automatic network monitor (ALA SNMP) that tells them >when UPS power is about to run down (before the lights go out) so they >can roll their generator into place. It is amazing how many connectivity failures are power related. For an APC UPS, all it takes is a dedicated $500 sparcstation, the $99 powerchute UPS monitoring software, and a $99 modem attached to the sparc for sending out a text page every time the UPS coughs. Sorry for stating the obvious.

1 0

RE: Mae-WEST
by Steve Carter 11 Jul '97

11 Jul '97

The message I got was that a contractor tripped a breaker, the UPS was run down and out of juice and the generator took a while to kick in. The power outage took out Gigaswitch #1, effectivly dropping the whole MAE. When power was restored the switch had a memory problem that wouldn't allow the config to load. Memory fixed, config loaded, but now there is still a problem with a switch port (#4, MFS said) that has kept six of our peers down. A couple of suggestions/observations: o Monitor the UPS so it doesn't run out of juice. o Reconfigure the Gigaswitch topology so that one loss doesn't take out all peers. o MFS call handling at the customer service center was good, considering the number of calls they must have got. Shirley even took the time to call me directly with an update. Cool. Maybe MFS should consider a mail server that would send out periodic status updates to subscribers? ---------------------------------- > I have a cage in the MFS Co-Lo and insisted on having a separate UPS > from > the main. > While I never lost power today, my FDDI did go down. > > This gets me thinking about the backup generator that is supposed to > be > online. > > Why didn't the generator kick-in before the UPS went down? > > Perhaps the better question is if they have a functioning generator > ... > Anyone from MFS listening? > > -ps > > At 09:15 AM 7/11/97 -0700, you wrote: > > > > I would guess that power to the colo cages is down. > > > >Mike. >

1 0

RE: ATM vs. DS3
by Murray, Steve 11 Jul '97

11 Jul '97

Peter Kline wrote >Another way of looking at this is that we know an ATM PVC over a DS3 using >PLCP is configurable for a maximum of 96000 cells per second. 96000 cells >per second * 48 payload octets per cell * 8 bits per octet = 36864000 bps, >or 36.864 Mbps, not too far from what I observed above. With PLCP turned >off, the maximum PVC config was ~105000 cells per second, yielding ~40.3 Mpbs. The SAR function will add eight bytes to the payload. The eight bytes contain the CPCS-UU(1 bytes), CPI (1 byte), length of payload (two bytes) and a CRC (4 bytes). This additional overhead needs to be taken into account if you are segmenting small frames. The last cell after segmentation will have these eight bytes at the end of the cell plus any padding needed to fill out the cell. If you are segmenting a 96 byte payload for example you would think this would actually fit into two cells (using the 48 byte payload), but it really take three cells. The last cell would only contain padding and this overhead. Steve Murray Worldcom

1 0

MAE West is up again (fwd)
by Taner Halicioglu 11 Jul '97

11 Jul '97

Interesting that GS-1 isn't on the "main DC plant"... I thought this GS was an important one, considering all the OC-3's go to it :-) -Taner -- D. Taner Halicioglu taner(a)isi.net Programmer/Engineer/Sysadmin ISI / GlobalCenter Voice: +1 408 543 0313 Fax: +1 408 541 9878 PGP Fingerprint: 65 0D 03 A8 26 21 6D B8 23 3A D6 67 23 6E C0 36 ---------- Forwarded message ---------- Date: Fri, 11 Jul 1997 10:06:44 -0700 (PDT) From: Steve Feldman <feldman(a)mfst.com> To: mae-west(a)nsipo.arc.nasa.gov Subject: MAE West is up again MAE West should be alive now. If you're still seeing problems, please contact our NOC and let them know! Here's what happened, as near as I can make out: Sometime during the night there was a power failure affecting at least the part of the building where the MAE is located. This went undetected long enough for the UPS powering one of the Gigaswitches to drain, so the Gigaswitch lost power. When power was restored, the Gigaswitch refused to come back up, claiming that it's management memory was corrupted. We were finally able to clear the management memory and rebuild the Gigaswitch configuration from scratch, and it finally came back to life. For the short term, we're going to put that switch on the main DC power plant (as all the others are) which has a much longer lifetime and is watched better. We'll also try to find out what happened with the Gigaswitch management memory. Steve

1 0

Re: Unacceptable Delay
by Bill Woodcock 11 Jul '97

11 Jul '97

I would point out that the delay inherent in the NANOG list which keeps it from being useful to ops folks in real-time is exactly what spurred creation of the IPNmoo and the Inter-Provider Notification Project in general. Nobody who was logged into IPNmoo appears to have lost their connections to it. -Bill ______________________________________________________________________________ bill woodcock woody(a)zocalo.net woody(a)nowhere.loopback.edu user(a)host.domain.com

1 0

Network Monitoring Tools
by David Hares - ADP Autonet 11 Jul '97

11 Jul '97

I would like to solicit recommendations for network monitoring utilities. We are attempting to monitor around a thousand nodes (and growing). We're using SunNet Manager since we're primarily a Sun shop. The problem is it's taking a full time programmer (me) to keep up with the changes in our net. It doesn't seem like it ought to take that much effort. The operations staff is competent and ought to be able to configure a monitoring utility. Also, SunNet seems to be a cpu hog. At the rate it uses up cpu, I'll need a giga-SPARC by next year. So, the question of the day is what's in use and really works ? I'm not enamored of cute GUI interfaces, particularly ones that try to draw my network out before giveing any useful information. Among other problems, running these over a less than wonderful connection to my hotel room is painful. Something that scales well into multipe thousands of nodes would be nice. Thanks in advance. -- David L. Hares, Senior Staff Programmer AutoNet Phone: (313) 995-6539 175 Jackson Plaza FAX : (313) 995-6458 Ann Arbor, MI 48106 (USA) Email: dhares(a)autonet.net

3 2

Unacceptable Delay
by Rodney Joffe 11 Jul '97

11 Jul '97

It's interesting to note the delay in the NANOG mailer. I don't know if there's any manual operation involved, but according to the headers, Rob posted this at 7:43, it was received at 7:43 pdt by MERIT, and shipped out at 8:15 pdt. I guess we're lucky this isn't an operational list, where time might be important ;-) Can we improve this? Rodney Joffe Chief Technology Officer Genuity Inc., a Bechtel company http://www.genuity.net Received: from postal1.genuity.net by x-files.genuity.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1458.49) id 3T51M8BZ; Fri, 11 Jul 1997 08:15:13 -0700 Received: from merit.edu (merit.edu [198.108.1.42]) by postal1.genuity.net (Sendmail G2.3/8.8.5) with ESMTP id PAA19251; Fri, 11 Jul 1997 15:15:28 GMT Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id KAA15550; Fri, 11 Jul 1997 10:49:59 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Fri, 11 Jul 1997 10:43:51 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id KAA15338 for nanog-outgoing; Fri, 11 Jul 1997 10:43:49 -0400 (EDT) Received: from elite.exodus.net (rob(a)elite.exodus.net [209.1.115.69]) by merit.edu (8.8.5/8.8.5) with ESMTP id KAA15331 for <nanog(a)merit.edu>; Fri, 11 Jul 1997 10:43:41 -0400 (EDT) Received: (from rob@localhost) by elite.exodus.net (8.7.5/8.7.3) id HAA04422 for nanog(a)merit.edu; Fri, 11 Jul 1997 07:43:52 -0700 From: Robert Bowman <rob(a)elite.exodus.net> Message-Id: <199707111443.HAA04422(a)elite.exodus.net> Subject: It's always fun To: nanog(a)merit.edu Date: Fri, 11 Jul 1997 07:43:52 -0700 (PDT) X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-nanog(a)merit.edu

3 2

RE: Mae-WEST
by Lance Tatman 11 Jul '97

11 Jul '97

I was told that a contractor tripped the main breaker and the UPS's ran down so that Gigaswitch-01 on the MFS side no longer had power. Since the 4 OC-3c's that link MFS and Ames are on that switch, connectivity has been lost until MFS can restore power. Folks on the Ames side can still talk to each other-but that's about it. -Lance-

2 1