- Test - lists.nanog.org

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

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

14 Jun '00

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.. Mufti Nayeem Ahmed Network Systems Engineer Market Data Networks Reuters America Inc. (212)-603-3595 ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.

1 0

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

14 Jun '00

Greetings. How many people here are running their own ping/traceroute/wget tools and feed the resulting responses into some form of database (MRTG, if you will) to get an idea how ping times to certain points in the network are changing over time? It appears that UUnet is selectively blocking such probes (upon major customer request?), in this case: pings from a single host (and only that single host) in my network to 157.130.178.1 , a Seattle border router to Amazon.com . As it appears, the goal is not to prevent denial of service attacks (5 ping packets every 5 minutes is less than the traffic load of an average daily customer of Amazon), but to hinder legitimate QoS analysis of connectivity to Amazon (and as such through UUnet's network itself). I, and certainly others, deem it very necessary to know that major web sites are or have been unreachable or hardly reachable during certain times for customer service and quality-of-service control purposes (yes, this is driving buying decisions for connectivity). Outages/bad performance in multiple directions are a sure indication of larger problems. Are some UUnet border routers so busy that they can't afford even a miniscule amount of ICMP traffic? Blocking it for single source/ destination pairs just doesn't make sense, other than that there is something (QoS-related) to hide. What pisses me off the most is that while Amazon (along with Ebay and a couple of other high-profile sites) may have corporate brain damage bad enough to filter all ICMP, not just rate-limit it or limit it to certain parts of their infrastructure, but a major backbone provider doing the same? Input please. Comments like "well, use another machine, or use http GET instead of ping to measure performance" are not helpful: I am fully capable of doing an end-run around these blocks any day. Thanks, bye,Kai

1 0

PMTU-D: remember, your load balancer is broken
by Marc Slemko 14 Jun '00

14 Jun '00

This is your monthly PMTU-D horkage rant. Chances are that if you are using a load balancer for TCP connections, then it does not properly handle Path MTU Discovery. Examples of devices like the ones I am talking about that do not, last I knew, handle this properly are localdirectors and arrowpoints. F5 claimed that they fixed their big/ip product to do this properly some time ago (remember when they broke NSI's whois service this way?), but I haven't seen it in action yet or know what version is required, and their support channels don't seem to know much about it when asked and give nonsensical answers like "it is built into the BSD/OS system that our product is built on". I would love to know about any such load balanceres that actually do handle this right. For an explanation of PMTU-D, see http://users.worldgate.ca/~marcs/mtu/ What happens with most load balancers is that when the server behind them tries to use PMTU-D, the ICMP "can't fragment" that may come back from a router between the server and the client will not make it to the load-balanced server because the load balancer will throw it away. The result is that most users with a path MTU that is less than min(client MTU, server MTU) will be unable to receive data from the server. The fix is to bitch at your vendor to fix their broken system and to tell them to hire someone that knows something about how TCP works. If you are a vendor, then make sure your load balancing software works right. What it needs to do is either send the "can't fragment" on to just the backend servers that have connections from the remote IP, or to flood it to all of them. The workaround for the person using such load balancers is to disable PMTU-D on your backend servers. This is your only option if the vendor of your load balancer doesn't care or takes a while to release a fix. If you have complaints that small subset of clients that can open a TCP connection to your load balanced IP but can't receive any reponse to their request, this could be what is up. (yes, www.slashdot.org seems to be broken in this way as I type. Oh well, slashdot isn't always a good thing...) This has been your monthly PMTU-D horkage rant.

6 7

Cisco vs. Juniper
by Hank Nussbacher 14 Jun '00

14 Jun '00

FYI. Cisco, Juniper face-off on software Companies debate merits of each other's routing code. By JIM DUFFY Network World, 06/12/00 http://www.nwfusion.com/news/2000/0612infra.html

2 1