- NANOG - lists.nanog.org

RE: Battery lifetimes RE: East Coast outage?
by McBurnett, Jim 15 Aug '03

15 Aug '03

>ut all those SONET hubs in basements, SLC's in the burbs and such >-- they don't have generators. They have X hours of batteries. In >the fine print, it says the LEC will have a portable generator >on site before they die. >That's doable if the failure is local; say a semi taking out >a power pole. But given anything bigger, a citywide or bigger >blackout, a regional ice storm, or whatever.... they do not have >the quantity of gensets they'd need, much less the manpower to >deploy AND maintain [refuel] same. Here in the SE we had a little Experience with this EXACT issue back in december. We had a power outage that lasted 4 days. Bellsouth's plan, and it seemed to work, was to hook gensets to a truck run to a battery pack run the generator long enough to recharge the pack and then drop and run to the next one. They started this within an hour or two of the power outage. None of my circuits went down during those days. (We had generator power at our office) This may be a larger, but we had about 2 Million out of power in little ole SC.. IMHO, J

1 0

Anti-spam scripts
by just me 15 Aug '03

15 Aug '03

Pardon the posting from (for once) a non-blackout area, but I have a small request. I just lost a large chunk of my work to a disk failure. A couple of months ago, I mailed out a bunch of my anti-spam scripts and database schemas to someone on this list. I'd know who, but my mail was hosed, too. If that was you, would you mind mailing the info back to me? I'd be forever indebited. Sorry for the WOB. Matt Ghali --mghali(a)snark.net------------------------------------------<darwin>< Flowers on the razor wire/I know you're here/We are few/And far between/I was thinking about her skin/Love is a many splintered thing/Don't be afraid now/Just walk on in. #include <disclaim.h>

1 0

NERC summer 2003 power predictions
by Sean Donelan 15 Aug '03

15 Aug '03

>From North American Electric Reliability Council May 2003 Reliability Summer Assessment Assessment Summary Generating resources are expected to be adequate to meet projected demand for electricity in North America this summer. However, there are some areas of concern in NPCC: southwestern Connecticut, New York City and Long Island. Locally tight resources compounded by transmission limitations into and within those areas make them particularly susceptible to reliability problems that can be caused if there is lower than expected generating unit availability, or high demand caused by extreme weather. Even in areas where resources are expected to be adequate, unanticipated equipment problems and extreme weather can combine to produce situations in which demands temporarily exceed available generation and transmission capacity.

3 2

cat6k msfc2 boot procedure details?
by Jochen Kaiser 15 Aug '03

15 Aug '03

Good morning, I try to understand the boot process of a msfc2 in cat6500 in hybrid mode. After reading the appropriate docs at CCO and some practise, I understand how to boot it and mostly (*sigh*) it works. Asking these detailed questions to ppl also administrating cat6k revealed a deep lack of knowledge ;-( Can anyone enlighten me/us? --- I understand, that there are 4 mechanisms on the msfc2: --------------------------------------------------------- 1. config register 2. BOOT variable (???) 3. BOOTLDR for helper image 4. 'boot system' statement in nvram config I assume, that there are 3 image types: 1. ROM image -> loaded when all fails 2. a c6msfc2-boot image -> loaded when other image fails (that's what I've read, but I watched, that it is booted each time, also when a loadable normal image is reachable on bootflash) 3. a c6msfc2 -> regular image Now we have different situations: ---------------------------------- a) an image is defined in nvram config 'boot system' and the image is on the bootflash -> image loads b) an image is defined but not on bootflash and there is an 'boot' image on bootflash -> boot-image boots my q: - is the position of the boot image of any relevance? I heard, that it is important, that it is the 1st file on the bootflash. Is this right? - does this just happen, when the config register has the appropriate value of 0x2000 ? - what is the exact role of the 'BOOTLDR'-variable? c) no image defined, config register 0x102 and boot image is on bootflash -> ???? my q: - What happens? d) an image is defined in the 'BOOT'-variable -> ???? my q: - what is the sense of the boot-variable? - how is it set? e) image is on ata-flash-disk and a boot image is on bootflash. image is defined via nvram 'boot system' -> since the appropriate image is not found, it boots the 'boot' image from bootflash, reads the nvram config and sees the sup-disk0 and loads the real image as a replacement my q: - is this correct? ------------ Especially I've a problem with setting the boot-variable (during normal operation of a regular booted image). router#sh boot BOOT variable = sup-disk0:c6msfc2-jo3sv-mz.121-19.E.bin,1 CONFIG_FILE variable does not exist BOOTLDR variable does not exist Configuration register is 0x2102 tia & greetings, Jochen Kaiser -- Dipl. Inf. Jochen Kaiser, GPG 0x3C93A870, phone +49 9131 85-28681 Network Administration mailto:jochen.kaiser@rrze.uni-erlangen.de Regionales Rechenzentrum Universitaet Erlangen-Nuernberg, Germany Homepage and PublicKey: http://ipv6.rrze.uni-erlangen.de/~unrz111

1 0

151 Front St Toronto (Torix)
by Mike Tancsa 15 Aug '03

15 Aug '03

Does anyone know whats up with them ? All my peers are down now and the host for the mailing list is still off the air. ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike(a)sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike

3 7

power failure causes and effects
by Fred Heutte 15 Aug '03

15 Aug '03

Most of the early rumors about causes of the power failure have proven incorrect -- fire at a New York City power plant, etc. Most likely is a congestion failure in the Niagara-Mohawk grid, which covers a large part of New York state and has feeders across into Canada. Congestion failures happen when power flows through a particular switching station are high, and a component fails either directly or because of a power surge caused by a failure elsewhere. The imbalance caused by an open or short circuit will then immediately spread through the rest of the grid unless action is taken to disconnect, or point failures occur (resulting in fires and explosions from degradation of power transmission equipment, transformers, etc., not a pretty outcome at all) -- or both. In general, transmission grids are designed from a failsafe perspective, meaning that it is much safer to cause rolling brownouts or blackouts than to let key components such as transmission substations or power plants have a catastrophic failure. Since the entire grid has to be in sync and supply and demand must be in relative parity at all times, the usual strategy in these cases is to isolate the affected area, "island it" by shutting down power ingress and egress (tripping safety breakers at major crossing points), and shutting down power plants in the vicinity that will have stress failures if they don't have sufficient load to balance their output. The problem is that power travels faster than even the highest-speed switching equipment can operate, so the surges causing a cascading failure like this afternoon's can spread very quickly, like ripples in a pond. The weather was hot and humid but completely within range for the time of year, so this has to be counted as a "normal accident." It's likely that whatever component initially failed and triggered the shutdown was within its usual tolerances and simply had an ordinary breakdown. Of course, to spread, a massive outage like this also exposes other weaknesses and hidden dependencies in the system, which might be other physical components, software, operator error, etc. The system is remarkably resilient in most circumstances, which is what five-nines or more is all about. But rust never sleeps, and underinvestment in key transmission corridors in New England, New York north of Manhattan and in parts of the Midwest is no doubt an underlying cause. As to the root cause of that engineering problem -- the answer is politics, some of it congressional, and I will say no more in this forum. Fred Heutte Portland, Oregon energy policy analyst and net geek

4 3

Weird attack or traffic (Was Re: The impending DDoS storm)
by Haesu 15 Aug '03

15 Aug '03

Is anyone else seeing backscatters on your network about windowsupdate.com's IP? Someone who transits through 65.123.21.137 router is sending out lots of packets to 204.79.188.11 (windowsupdate.com) in which its not currently advertised to internet as we speak. Not to mention, packets seem to be source-spoofed to 65.124.16.0/21 (our block), causing backscatter from 65.123.21.137 to our network... Any ideas/or anyone seeing similar effect? Is someone who is administrative to Qwest Communications WASH01-WAN-65-123-21 (NET-65-123-21-0-1) aware of this may be? It looks like a Qwest customer CPE router to me but I dunno.. See below for traffic snapshot.. -hc -- Sincerely, Haesu C. TowardEX Technologies, Inc. WWW: http://www.towardex.com E-mail: haesu(a)towardex.com Cell: (978) 394-2867 k00:50:22.807370 65.123.21.137 > 65.124.23.125: icmp: net 204.79.188.11 unreachable 00:50:22.891672 65.123.21.137 > 65.124.22.48: icmp: net 204.79.188.11 unreachable 00:50:22.979997 65.123.21.137 > 65.124.22.98: icmp: net 204.79.188.11 unreachable 00:50:23.047340 65.123.21.137 > 65.124.22.21: icmp: net 204.79.188.11 unreachable 00:50:23.133616 65.123.21.137 > 65.124.22.72: icmp: net 204.79.188.11 unreachable 00:50:23.520405 65.123.21.137 > 65.124.23.107: icmp: net 204.79.188.11 unreachable 00:50:23.745844 65.123.21.137 > 65.124.22.3: icmp: net 204.79.188.11 unreachable 00:50:23.829309 65.123.21.137 > 65.124.22.54: icmp: net 204.79.188.11 unreachable 00:50:24.493650 65.123.21.137 > 65.124.23.113: icmp: net 204.79.188.11 unreachable 00:50:24.530074 65.123.21.137 > 65.124.23.35: icmp: net 204.79.188.11 unreachable 00:50:24.618082 65.123.21.137 > 65.124.23.86: icmp: net 204.79.188.11 unreachable 00:47:50.611529 65.123.21.137 > 65.124.18.100: icmp: net 204.79.188.11 unreachable 00:47:50.649962 65.123.21.137 > 65.124.17.151: icmp: net 204.79.188.11 unreachable 00:47:50.711865 65.123.21.137 > 65.124.17.124: icmp: net 204.79.188.11 unreachable 00:47:50.756960 65.123.21.137 > 65.124.17.47: icmp: net 204.79.188.11 unreachable 00:47:50.826367 65.123.21.137 > 65.124.20.8: icmp: net 204.79.188.11 unreachable 00:47:52.355967 65.123.21.137 > 65.124.22.126: icmp: net 204.79.188.11 unreachable 00:47:52.587141 65.123.21.137 > 65.124.20.46: icmp: net 204.79.188.11 unreachable 00:47:53.865460 65.123.21.137 > 65.124.22.87: icmp: net 204.79.188.11 unreachable 00:48:05.250757 65.123.21.137 > 65.124.16.1: icmp: net 204.79.188.11 unreachable 00:48:05.713640 65.123.21.137 > 65.124.17.86: icmp: net 204.79.188.11 unreachable 00:48:05.841169 65.123.21.137 > 65.124.17.60: icmp: net 204.79.188.11 unreachable 00:48:06.013042 65.123.21.137 > 65.124.16.33: icmp: net 204.79.188.11 unreachable 00:48:06.549540 65.123.21.137 > 65.124.17.41: icmp: net 204.79.188.11 unreachable 00:48:06.803847 65.123.21.137 > 65.124.17.92: icmp: net 204.79.188.11 unreachable 00:48:06.981930 65.123.21.137 > 65.124.17.15: icmp: net 204.79.188.11 unreachable 00:48:07.277776 65.123.21.137 > 65.124.18.100: icmp: net 204.79.188.11 unreachable 00:48:07.343120 65.123.21.137 > 65.124.18.74: icmp: net 204.79.188.11 unreachable 00:48:07.486285 65.123.21.137 > 65.124.17.47: icmp: net 204.79.188.11 unreachable 00:48:07.569901 65.123.21.137 > 65.124.20.8: icmp: net 204.79.188.11 unreachable 00:48:08.117407 65.123.21.137 > 65.124.18.106: icmp: net 204.79.188.11 unreachable 00:48:08.356732 65.123.21.137 > 65.124.20.41: icmp: net 204.79.188.11 unreachable 00:48:08.637485 65.123.21.137 > 65.124.20.14: icmp: net 204.79.188.11 unreachable 00:48:08.944750 65.123.21.137 > 65.124.22.126: icmp: net 204.79.188.11 unreachable 00:48:08.946623 65.123.21.137 > 65.124.22.49: icmp: net 204.79.188.11 unreachable

2 2

RE: power failure causes and effects
by Mark Segal 15 Aug '03

15 Aug '03

We have power in some pops and our co.. Genie just shut off.. Wow its quiet now.. (fyi our co is in vaughan). mark -- Mark Segal Director, Network Planning FCI Broadband Tel: 905-284-4070 Fax: 416-987-4701 http://www.fcibroadband.com Futureway Communications Inc. is now FCI Broadband -----Original Message----- From: Mehmet Akcin [mailto:mehmet@akcin.net] Sent: August 15, 2003 1:10 AM To: nanog(a)merit.edu Subject: Re: power failure causes and effects I have been hearing on the TV that some places that had power failure have started getting their power back, reporters say hopefully by the morning all of the places where had power failure will back online. Mehmet Akcin ----- Original Message ----- From: "Marshall Eubanks" <tme(a)multicasttech.com> To: "Fred Heutte" <aoxomoxoa(a)sunlightdata.com>; <nanog(a)merit.edu> Sent: Friday, August 15, 2003 12:51 AM Subject: Re: power failure causes and effects > > On Thu, 14 Aug 2003 19:12:04 -0700 > Fred Heutte <aoxomoxoa(a)sunlightdata.com> wrote: > > It looks like DC may have had a close call - the University of > Maryland was > dark for about 1 hour, and I have heard several news reports here > stating that the local (DC regional) power grid just managed to > decouple from wider East Coast grid in time to avoid a collapse here. > > Regards > Marshall Eubanks > > > > > Most of the early rumors about causes of the power failure have > > proven incorrect -- fire at a New York City power plant, etc. > > > > Most likely is a congestion failure in the Niagara-Mohawk grid, > > which covers a large part of New York state and has feeders across > > into Canada. > > > > Congestion failures happen when power flows through a particular > > switching station are high, and a component fails either directly or > > because of a power surge caused by a failure elsewhere. > > > > The imbalance caused by an open or short circuit will then > > immediately spread through the rest of the grid unless action is > > taken to disconnect, or point failures occur (resulting in fires and > > explosions from degradation of power transmission equipment, > > transformers, etc., not a pretty outcome at all) -- or both. In > > general, transmission grids are designed from a failsafe > > perspective, meaning that it is much safer to cause rolling > > brownouts or blackouts than to let key components such as > > transmission substations or power plants have a catastrophic > > failure. > > > > Since the entire grid has to be in sync and supply and demand must > > be in relative parity at all times, the usual strategy in these > > cases is to isolate the affected area, "island it" by shutting down > > power ingress and egress (tripping safety breakers at major crossing > > points), and shutting down power plants in the vicinity that will > > have stress failures if they don't have sufficient load to balance > > their output. > > > > The problem is that power travels faster than even the highest-speed > > switching equipment can operate, so the surges causing a cascading > > failure like this afternoon's can spread very quickly, like ripples > > in a pond. > > > > The weather was hot and humid but completely within > > range for the time of year, so this has to be counted as a "normal > > accident." It's likely that whatever component initially failed and > > triggered the shutdown was within its usual tolerances and simply > > had an ordinary breakdown. Of course, to spread, a massive outage > > like this also exposes other weaknesses and hidden dependencies in > > the system, which might be other physical components, software, > > operator error, etc. > > > > The system is remarkably resilient in most circumstances, which is > > what five-nines or more is all about. But rust never sleeps, and > > underinvestment in key transmission corridors in New England, New > > York north of Manhattan and in parts of the Midwest is no doubt an > > underlying cause. > > > > As to the root cause of that engineering problem -- the answer is > > politics, some of it congressional, and I will say no more in this > > forum. > > > > Fred Heutte > > > > Portland, Oregon > > energy policy analyst and net geek > > >

1 0

Re: 151 Front St Toronto (Torix)
by Mike Tancsa 15 Aug '03

15 Aug '03

Just spoke with the GT/360 help desk. Apparently there were issues with the generators at 151 Front St and the A/C was either broken or just partially functioning. As a result at one point they had shut down their long haul gear as the temperature was approaching dangerous levels. Anyone have any more details ? The intake on my 7204s are at 37C vs the normal 28C. ---Mike At 11:04 PM 14/08/2003 -0400, Mike Tancsa wrote: >Does anyone know whats up with them ? All my peers are down now and the >host for the mailing list is still off the air. > > ---Mike >-------------------------------------------------------------------- >Mike Tancsa, tel +1 519 651 3400 >Sentex Communications, mike(a)sentex.net >Providing Internet since 1994 www.sentex.net >Cambridge, Ontario Canada www.sentex.net/mike

1 0

Thoughts....
by Allen McRay 15 Aug '03

15 Aug '03

Wonder what is going to happen as those millions of machines in the northeast are restarted after a little rest this afternoon and evening. Bet more than a few of them have got a bug just waiting to wake up. Be interesting to see if there is any increase in activity....... Allen

1 0