- Test - lists.nanog.org

MAE-East snafu redux
by Jeremiah Kristal 22 Apr '98

22 Apr '98

Has everyone just become so used to terrible performace at MAE-East, or am I the only one seeing problems? I'm seeing perfect performance to networks connected to Gigaswitch 1 (excluding overloaded ports), but 15-20% packet loss to anyone connected to any other Gigaswitch. In the past MFS would jump on these tickets, find a frozen card on Gigaswitch 6, reset it, and clear the trouble. It has been over 24 hours since I opened a ticket, I've spoken with MFS Datanet Engineering, and I still don't think I've spoken to anyone at MFS who is aware that all traffic between Gigaswitches goes through Giga6. If anyone has time tonight, could they check performance to other providers on the same Gigaswitch and on other Gigas. If you need to know which provider is on which switch, go to http://www.mfsdatanet.com:80/MAE/east.map.html Thanks, and hopefully this is on topic, even if it doesn't contain actual router commands. :) Jeremiah Kristal Senior Network Engineer ICon CMT Corporation jeremiah(a)iconnet.net 201-319-5764 x284 internal

3 2

IEGRP v OSPF
by Geoff Hill 22 Apr '98

22 Apr '98

Subject: Case Study : EIGRP / OSPF Date: Sat, 11 Apr 1998 12:09:10 -0700 From: Geoff Hill <hillgm(a)corplink.com.au> To: nanog(a)merit.edu Gidday, I am interested in the comparison of these two protocols. Could you poin t me to a copy of the above paper please. Geoff Hill

1 0

Re: MAE-East snafu redux
by Sean Donelan 21 Apr '98

21 Apr '98

>Has everyone just become so used to terrible performace at MAE-East, or am >I the only one seeing problems? I'm seeing perfect performance to >networks connected to Gigaswitch 1 (excluding overloaded ports), but >15-20% packet loss to anyone connected to any other Gigaswitch. In the No. But the rest of us are too afraid to ask MFS to touch the switches least they start falling over every 15 minutes again, as has happened the last few times MFS jiggled something. I do wish providers and MFS could arrange trunking a bit better. For example, we on the same gigaswitch as one provider, but we end up sending traffic across the inter-switch trunks to a different gigaswitch because of the way the BGP sessions are setup with a second router the provider uses. Yes, the other provider is aware of it, and yes the other provider's senior backbone engineering staff is aware of it, and yes they have no plans to change it. I almost get the impression, they want it to have poor connectivity. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: Filtering ICMP (Was Re: SMURF amplifier block list)
by Eric Germann 21 Apr '98

21 Apr '98

At 08:45 PM 4/21/98 +0400, Alex P. Rudnev wrote: >1) Traceroute is not affected by this filter; Just a note that if you are using Winders, tracert does use ICMP Echo Requests, no high port numbers. FYI. >2) ICMP is really blocked at many different places of Internet; we answer >every day _no matter you can't ping www.XXX.com, it's becuase they refuse >PING's to their network_. Still don't make it right. ============================================================================ ==== Eric Germann Computer and Communications Technologies ekgermann(a)cctec.com Van Wert, OH 45891 Phone: 419 968 2640 http://www.cctec.com Fax: 419 968 2641 Network Design, Connectivity & System Integration Services A Microsoft Solution Provider

1 0

Post-mortem, One company's response to a network outage
by Sean Donelan 21 Apr '98

21 Apr '98

Its been a week since the latest provider-wide network failure, so here's a bit of post-mortem. As reported everywhere, the AT&T frame-relay network failed last Monday, April 13, 1998. Since then, AT&T has been catching up in the keeping the customer informed department. Even recognizing the substantial penalty because of the slow initial response, I have to admit that AT&T eventually surpassed most of their competitors in this area. Full disclosure, AT&T did offer me some baseball tickets. The next question is how well will Cisco/StrataCom handle their part in this incident. Was it something unique about the AT&T network, or are other providers who also use cisco/StrataCom frame-relay switches at risk of experiencing the same problem. Or had they already experienced the problem, and updated their switches prior to this event. This isn't the first frame-relay network that has collapsed. And finally, does anyone know why the cloak of secrecy over where the two initial frame-relay switches that failed? Even though the New York Times reported (which doesn't make it true, just highly probable) the switches were in Albany and Cambridge, the AT&T people seem striken by apoplexy when you mention the general location. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Hate bother anyone...
by Richard Irving 21 Apr '98

21 Apr '98

But, I couldn't find a reference to a MAC address on a piece of ethernet... The vendor code is : 00:C0:43:00...... Anyone know who's vendor code this is ? Thanks, Richard

3 2

Re: Filtering ICMP (Was Re: SMURF amplifier block list)
by Steve Uurtamo 21 Apr '98

21 Apr '98

Okay, so it's clear that we need to come up with some sort of sol'n to these kinds of problems. Here's my two cents: Don't block all of ICMP. Block pings and traceroutes if you think that it's going to make your life better, but please don't break anything else. We need a low-pain protocol to allow provider NOCs to check out a few salient things on their upstream provider's/peers routers -- e.g. which interface a particular spoofed packet is coming from, the IP address of the remote-side interface, etc., etc., all the way back to the source. This would allow provider NOCs to track this stuff down themselves. No more 6 hour phone calls to people with various degrees of clue/time/energy for a problem that may only occur for 15 minutes at a time, every 4 hours. It wouldn't be hard to jimmy this protocol (in case people care) such that you would ONLY be able to track back to a particular NOC's router if all of the inbetween-routers had "signed off" on the fact that what you're looking for (specific dst/src or packet type) had actually SHOWN UP on them as well. It wouldn't have to continuously check this -- just check once and PK-encrypt the timestamp into the signature on the authentication packet. Various timeouts could be configured by individual NOCs. (Yes, each NOC could have its own PK value -- but there would only have to be one per AS). Before everyone gets all hot and bothered about the suggestion that I'm making -- I'm not talking about arbitrary packet sniffing -- I'm talking about sniffing HEADERS on packets whose dst address (or packet type or whatever everyone agrees is significant) is inside the domain of the dst provider. Not a big deal. I really don't think that it's that much to give up -- hell, digex already allows me to dump their entire BGP table anytime I want -- i'm just talking about some very minimal tracking ability. Some companies, such as sprint, who may have hundreds of customers plugged into a single router, may not want to do this. But frankly, without this, we're all dependent upon the clue/time/energy of some guy who's busy doing his own thing, and we aren't guaranteed timely and accurate information. Actually, now that I think of it, you could almost jimmy this out of a few hours of PGP-wrapped SNMP-calling perl scripts listening to some fixed socket at some fixed (and published) IP address of each network provider. No reason to dick with the router code if no need to. What say ye? steve

1 0

Re: Digital Internet Exchange - Palo Alto
by mfw＠datamain.com 21 Apr '98

21 Apr '98

> contact at the Digital Internet Exchange David Ross Global Networking and Computing (GNAC) 999 Main Street Redwood City, CA 94063 (650) 569-4602 (425) 810-8665 ross(a)gnac.com does not work at the PIX; he has racks co-located there; David has arranged two (very worthwhile) tours for my customers. > I am looking into setting up a connection there. good choice. i hear they're full but you should still try. > Any perceived wisdom from the list as this exchange point would also be > appreciated. best I've seen.

1 0

new NANOG agenda items
by Susan Rebecca Harris 21 Apr '98

21 Apr '98

Greetings - we've added several new agenda items for the Dearborn NANOG: http://www.nanog.org/mtg-9806/topics.html Stay tuned - we'll be adding new topics often. ------------------------------------------------------------------------- Susan Rebecca Harris, Ph.D. Merit Network, Inc. Phone: 734.936.2100 srh(a)merit.edu Senior Science Writer Fax: 734.647.3185 -------------------------------------------------------------------------

1 0

RE: Digital Internet Exchange - Palo Alto
by Kamau Wanguhu 21 Apr '98

21 Apr '98

Rose This is a good place to start: http://www.ix.digital.com/contact.html If you have any trouble send me your phone number and I will track someone internally to help you. Kamau Wanguhu Digital Equipment Corp Cambridge Research Lab kamau(a)crl.dec.com +1.617.692.7613 => -----Original Message----- => From: Rose, Julian [mailto:Rose.Julian@att-unisource.com] => Sent: Tuesday, April 21, 1998 09:41 => To: 'nanog(a)merit.edu' => Subject: Digital Internet Exchange - Palo Alto => => => Can anyone give me a name of a contact at the Digital => Internet Exchange => Point in Palo Alto, I am looking into setting up a connection there. => => Any perceived wisdom from the list as this exchange point => would also be => appreciated. => => Regards => => Julian Rose =>

1 0