June 2000 - Test - lists.nanog.org

Re: San Francisco power outages imminent
by Hal Murray 14 Jun '00

14 Jun '00

> Disinformation? Its not on the CAISO web site. Palo Alto runs their own utilities. I work in downtown Palo Alto. The text I quoted was distributed via email to our operations people and they forwarded it to us. I clipped off all the headers to save space and to be polite because I don't have permission to expose the initial sender's email address. Sorry for any confusion or doubts I contributed by not explaining that earlier. The last line of the message I quoted includes their URL: www.cpau.com (That's City of Palo Alto Utilities) Right now, that page says: What's New: STAGE III Alert called at 2:34 p.m. today.Portions of Rotating Outage Block #6 have been shut off for two hours to comply with an mandatory electricity curtailment request of 3 Megawatts of load in Palo Alto. The area affected is bounded by 1) Alma/Middlefield and E. Meadow/El Carmelo and 2) Alma/Middlefield and E. Meadow/Ferne. We will keep you notified of additional changes.

1 0

Re: San Francisco power outages imminent
by Hal Murray 14 Jun '00

14 Jun '00

The view from Palo Alto: ----- Date: Wed, 14 Jun 2000 12:32:44 -0700 STAGE TWO ELECTRIC ALERT! The Cal ISO has declared Stage One and Two Emergencies for today from Noon to 6:00 pm. Demand is exceeding transmission capability in the Bay Area by 250 megawatts. Please reduce electric consumption to the greatest extent possible. If required, Stage 3 (rolling blackouts) may not allow advance notice. You may wish to engage your emergency generators. We will update you as information becomes available. ----- Sent: Wednesday, June 14, 2000 3:26 PM At 2:34 p.m. Palo Alto initiated rolling blackouts to shed 3.3 megawatts of load. Similar action is occurring throughout the Bay Area. Affected outage areas are in residential portions of Block 6 and will be impacted for two hours. Thank you for your efforts. See www.cpau.com for more info.

2 1

Further power updates
by lucifer＠lightbearer.com 14 Jun '00

14 Jun '00

Direct contacts or NANOG readers have provided more information: Confirmation of outages in Cupertino (along De Anza to 85, at least), affecting Apple's main campus, from 13:30 to 15:30. This (or a related) outage are also reported in Sunnyvale. At least one report of outages in Fremont, affecting a service provider. Also, one report of an outage in the China Basin, affecting a circuit to another provider (whether it was a provider or circuit failure wasn't clear from the report). PG&E and the Santa Clara grid have both gone to Stage 3, according http://www.newschannel11.com/MoreNews/readstory.asp?s=0006_rotatingoutages and http://www.pge.com/whats_new/news/releases/2000/quarter02/000614r2.htm Local radio stations are reporting that the rolling blackouts have been extended to 2 hours (per area); I cannot confirm this, however. -- *************************************************************************** Joel Baker System Administrator - lightbearer.com lucifer(a)lightbearer.com http://www.lightbearer.com/~lucifer KF6WAY (Tech) - 146.475 MHz (FM/Phone)

2 1

RE: PMTU-D: remember, your load balancer is broken
by rdobbins＠netmore.net 14 Jun '00

14 Jun '00

Nobody expects anyone to change millions of dial-up MTUs; it was just a response to the original poster's query as to the origin of that figure. I've been DoSed via fragmentation, so it -can- happen. Agreed, it's not all that common. Thanks much for the info on Cisco 'Giant Frame' support; I know that'll come in handy! Server folks will often tell you that they need huge MTUs - and in some cases, they're correct. In other cases, it actually ends up hindering performance, depending upon the application and the entire end-to-end network topology. Playing with MTUs is very much like configuring filesystem block-size, or the application-specific buffering in a big RDBMS like Oracle. The main difference is that although one doesn't often see big RDBMS servers used for other things (allowing the server OS and the applications on it to be tweaked so as to squeeze out every erg of performance for a single purpose), networks in general, and carrier networks in particular, are generally used for all sorts of things. And besides the potential effect of an altered MTU size on application performance, one then runs into the question of whether it's an efficient use of bandwidth overall. So, I guess it makes sense to have a -thorough- understanding of one's topology and application characteristics prior to fiddling about with the MTU size. I can see that it may well offer the potential of a big win at the core, but moving towards the edges, I should think the benefits tend to taper off. There can't really be a rule of thumb for this sort of thing, of course; by nature, it's highly situationally dependent. -----Original Message----- From: Stephen Sprunk [mailto:ssprunk@cisco.com] Sent: Wednesday, June 14, 2000 3:48 PM To: rdobbins(a)netmore.net Cc: North American Noise and Off-topic Gripes Subject: Re: PMTU-D: remember, your load balancer is broken Sez <rdobbins(a)netmore.net> > The 576 value of the MS PPP MTU is merely a default - it can be > changed with a registry hack. Expecting the tens of millions of novice computer users to set their systems for a 1500 byte MTU is irrational. Those who are knowledgeable enough to do so are generally reducing it due to "speed up your modem" articles and programs which improve interactive performance at the expense of throughput. > Forcing excessive fragmentation/defragmentation is an effective DoS. Effective, but a fairly difficult problem to exploit. > I thought the frame-size limits for Gigabit Ethernet were 64-1518/1522 > bytes? And isn't that the limit on most host IP stacks for Ethernet media? > Or am I off in left field, here? IIRC, during development of the GigE spec, several vendors wished to increase the GigE MTU to ~9000 bytes. Due to the technical ramifications of bridging to low-MTU FastE segments, as well as inter-vendor politics, it didn't make it as part of the GigE spec but was later published as an optional extension. There are now several devices on the market that will do Jumbo frames on GigE. For instance, the Catalyst 6000 and GSR do: http://www.cisco.com/univercd/cc/td/doc/product/lan/cat6000/sw_5_5/cmd_r efr/set_po_r.htm#xtocid661812 I know there are several other vendors who support Jumbo frames as well. > Finally, I would say that on any medium, <100% utilization in and of itself > isn't grounds for fiddling with the MTU. There are lots of other things to > look at, first. I hear consistent requests from server folks for higher MTUs; they claim the per-frame CPU hit is significant enough to warrant using Jumbo frames to increase throughput. The results clearly show that it helps. S | | Stephen Sprunk, K5SSS, CCIE #3723 :|: :|: Network Design Consultant, HCOE :|||: :|||: 14875 Landmark Blvd #400; Dallas, TX .:|||||||:..:|||||||:. Email: ssprunk(a)cisco.com

1 0

AS6082
by Deepak Jain 14 Jun '00

14 Jun '00

Has anyone else noticed that AS6082 is leaking lots of AS701, AS2548, AS1239, and numerous other transit AS announcements? Or is everyone also in a great situation with respect to their filters? Deepak Jain AiNET

14 14

Re: Detroit Power Failure
by Sean Donelan 14 Jun '00

14 Jun '00

A followup on yesterday's power failure in Detroit. Detroit Public Lighting provides power for 4500 public and government buildings, as well as street lights and traffic signals in Detroit. Detroit Edison supplies power to commercial and residential customers. Detroit Edison was not affected. At last report, 90% of the DPL buildings had power restored. Spokespersons were no longer predicting how long it would take to completely restore all power to the remaining buildings.

1 0

RE: PMTU-D: remember, your load balancer is broken
by jhsu＠mur.com 14 Jun '00

14 Jun '00

: : Then again, at least some Cisco gear doesn't think that. : : perdition>sh in g0/1 : GigabitEthernet0/1 is up, line protocol is up : Hardware is Gigabit Ethernet, address is 00d0.7966.eeae (bia 00d0.7966.eeae) : MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, rely 255/255, load 24/255 the last i checked, 1500 was the default. given the right hw & sw, MTU can be adjusted upward. i seem to remember seeing it demonstrated on 12000 gear. there is a draft [draft-kaplan-isis-ext-eth-02.txt] that discusses some extensions useful to support large frames. these extensions- again, the last i checked- were supported by cisco, and other vendors. as always, contact your authorized support rep when in doubt. ymmv, _k

2 1

Re: San Francisco power outages imminent
by Sean Donelan 14 Jun '00

14 Jun '00

> I've seen a few messages forwarded from friends at various > SF companies, especially South of Market, saying that PG&E has > been calling them and asking that they reduce power utilization. The California Independent System Operator (runs the electrical grid) has issued a stage one alert. A stage one alert is to inform the public of the potential for power outages, and request consumers curtail their power consumption. Technically a stage one alert means the electrical grid reserve is less than 7%. Stage two is declared when the reserve drops below 5%, and large commercial customers with interruptible power contracts will be requested to curtail their load. Stage 3 is declared when the reserve drops below 1.5%, involuntary power interruptions (aka rolling brownouts and blackouts) are probable at stage three. CAISO is looking at the statewide load when issuing its alerts. Individual areas may be better or worse off. At 2pm San Francisco Office of Emergency Services has issued this statement: >The Pacific Gas and Electric Company has notified the City of San >Francisco that PG&E will begin involuntary curtailment of electrical >service to portions of San Francisco. These outages are necessary to >prevent collapse of the electrical power grid. Parts of San Francisco >are expected to be without power for at least an hour to an hour and >a half.

1 0

Re: UUnet blocking ICMP ECHO for select sources/destinations ?
by Kai Schlichting 14 Jun '00

14 Jun '00

The observations suggest something different. Remember that I mentioned that this blockage only occurs for a SINGLE IP in my network: the base IP belonging to the server doing the stats collection every 5 minutes. Other IP's (even on that server) are ok. Rate limiting would be visible as packet loss after the committed rate is exceeded: you can't rate-limit on production border routers down to single-host granularity, only a big interface-wide rate-limit will work. I am still trying to determine if the interface IP in question is the customer side of things, but things are a bit murky there, because there appear to be ACLs on both sides of the link. At Wednesday 04:15 PM 6/14/00 , Mufti Ahmed <Mufti.Ahmed(a)reuters.com> wrote: > Kai what if UUnet is running some type of QOS mechanism in their >core network that prevents massive amounts of icmp messages >traveling through? Maybe they are rate-limiting everyone with CAR. >Their infrastructure is interesting they use Cisco, Fore, and Juniper >at least in production. And they claim they run an MPLS network; >maybe this is where icmp traffic is killed..

1 0

central office facilities
by Bradley Dunn 14 Jun '00

14 Jun '00

I'm trying to collect information on central office facilities. Does anyone have any good resources for this information? In addition, are there any tricks for getting to the right people at the various ILECs? Some of the things I'm interested in are collocation at the CO, interoffice connectivity, and backhaul to regional POPs. I'd greatly appreciate any pointers. Thanks! Bradley

1 0