- Test - lists.nanog.org

Re: InternetWeek Article on UUnet: question
by Erik Muller 18 Nov '98

18 Nov '98

On Wed, 18 Nov 1998, Sean Donelan wrote: > http://www.internetwk.com/news1198/news111398-2.htm > > Was NETCOM identified as the source? Why was the NETCOM NOC difficult > for UUNET to reach on Sunday? Was it a 'customer configuration error' > or a router vendor(s) software bug? If UUNET had identified the correct > customer router to block, why did the route return? I'm more than a little curious about those comments as well. Noone from UUNet, to my knowledge, has informed us of any involvement from Netcom in this situation. If we were involved, I would greatly appreciate any information as to how... as we all know, we can't fix the problems that nobody tells us about. If there were problems contacting us, again, I'd like to know. Our contact information is readily available, and as far as I know, accurate - http://puck.nether.net/netops/nocs.html is up to date for us, anyway. Of course, I'm taking those comments with a pretty large grain of salt as well, considering that the same sentence implies that we're a UUNet customer. Uh, no, I think not. ---------------------------------------------------------------------------- Erik Muller, Network Engineer emuller(a)noc.netcom.net NETCOM Network Services Support NETCOM On-Line Communication Services

1 0

Cache-as-cache-can
by Michael Haba 18 Nov '98

18 Nov '98

To cut a long story short, I was just wondering if people could extrapolate their feelings regarding commerical Web Cache solutions. In terms of the good, the bad and the ugly. At the moment I'm left with 'two goods' Network Appliance's NetCache and Inktomi's Traffic Server and would appreciate some input to sort them out. -Michael -- Michael Haba <m.haba(a)magnet.at> Telenor Magnet - Internet at Work

9 11

RE: AS_PATH length and route selection (WAS: Strange BGP announcement)
by Martin, Christian 18 Nov '98

18 Nov '98

> So, would anyone care to discuss (from an operational POV) what removing > AS_PATH length from the BGP route selection algorithm will do to the > Internet? You determine your local policy based on the tools that you have. If AS_PATH length were not in the algorithm by default, you could force it in there (in Cisco IOS) using route maps and regexps. For example: ! route-map MATCH_LONGER_THAN_5_ASPATH_HOPS permit 10 match as path 5 set local-preference 50 ! route-map DISCARD_LONGER_THAN_5ASPATH_HOPS permit set local-preference 100 ! ip as-path access-list 5 permit ^[0-9]+\ [0-9]+\ [0-9]+\ [0-9]+\ [0-9]+_ ! This goes for any routing protocol, not just BGP. -Chris

1 0

RE: Strange BGP announcement
by Martin, Christian 18 Nov '98

18 Nov '98

> > Patently false. In particular, the spec allows an > implementation to invoke > local policy when computing the local preference of a route. An > implementation can reasonably incorporate the AS path length > in its local > preference calculations as part of its policy. > > Tony > In Cisco IOS, this falls under the BGP decision process in selecting a route. So in an indirect way, this is already implemented. To be more exact in terms of the RFC, I suppose a match clause could be implemented based on path length, but this can be done already with a regular expression. Either way, the capability is there. -Chris

1 0

Re: Cache-as-cache-can
by Tony Li 18 Nov '98

18 Nov '98

paul(a)vix.com (Paul Vixie) writes: > There's a fourth. I used to manufacture something called the Web Gateway > Interceptor which was topologically a router. It wasn't competitive as > a router, either in price, performance, or number/kind of interfaces. But > you could put it in parallel with another router and integrate it into > your OSPF mesh and use OSPF link costs to make it be the primary path only > while it was up. HSRP would have worked the same way, and I'll admit that > it's a lot simpler to do (though I'm not sure it's an open standard yet?) HSRP is published as an Informational RFC. However, there is a patent on the protocol, assigned to Cisco. To the best of my knowledge, Cisco has not granted any licenses to that patent (yet). The VRRP working group selected the VRRP protocol instead of HSRP to place on the standards track, so at this point, it is unlikely that HSRP will become a standard (open or otherwise) anytime soon. Tony

1 0

IDIG subscription message error
by Sean Donelan 18 Nov '98

18 Nov '98

When subscribing to the LISTSERV for the IDIG lists, the subscription message will include information about a WWW interface. Please ignore those paragraphs. The Web interface hasn't been set up, only the e-mail interface. Please e-mail the "ok" command as described in the subscription confirmation message. Sorry, but my LISTSERV guys have left for today and I haven't figured out how to change the subscription message file in LISTSERV. Actually, I haven't even found where it stores it yet. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

IPF.NET has currently problems at MAE-EAST / WEST
by Jan Czmok 18 Nov '98

18 Nov '98

Currently we have problems with our Ethernet Connections on our Switches at MAE-EAST and MAE-WEST. Currently no ETA. We keep you informed about changes and news. We will be still routed over our uplinks from germany. Greetings Jan Czmok IPF.NET Senior Network Engineer

1 0

Re: Cache-as-cache-can
by Paul Vixie 17 Nov '98

17 Nov '98

stevenh(a)inet.unisource.nl (steven hessing) writes: > There seem to be three solutions for transparent web-caching: > 1 a web-cache between two routers, all traffic is routed through it. > 2 a l4 switch between two routers, all traffic is routed through it. > The l4 switch redirects web-requests to a www-cache. > 3 a web-cache connected to a router which uses policy routing to > direct web-requests to it. There's a fourth. I used to manufacture something called the Web Gateway Interceptor which was topologically a router. It wasn't competitive as a router, either in price, performance, or number/kind of interfaces. But you could put it in parallel with another router and integrate it into your OSPF mesh and use OSPF link costs to make it be the primary path only while it was up. HSRP would have worked the same way, and I'll admit that it's a lot simpler to do (though I'm not sure it's an open standard yet?) -- Paul Vixie <paul(a)vix.com>

1 0

AS_PATH length and route selection (WAS: Strange BGP announcement)
by I Am Not An Isp 17 Nov '98

17 Nov '98

At 06:03 PM 11/17/98 -0500, Vijay Gill wrote: >You appear to have misunderstood the problem. The issue has nothing to do >with route selection, or are you talking about FastPath(TM, Pat Pending) >here? Cute, Vijay. Really cute. Of course, if everyone had only licenced it, we wouldn't have this problem now, would we? :p >The issue is that an invalid as-path attribute was injected from >somewhere. The cisco as-path sanity check code failed to pick it up. [SNIP] I have not misunderstood the problem, you have misunderstood my response. Someone posted that the routers should follow the RFC. I was commenting that you should be careful what you wish for. If we magically made all routers strictly conform to the RFC instantly, it would have solved this particular problem, but it would have caused *much* larger problems for the 'Net at large. I was also hoping to start a debate by those more knowledgeable than I about the ... wisdom of intentionally removing what is currently far and away the most used metric for route selection from the next version of BGP; namely: AS_PATH length. (At least I was under the impression that AS_PATH length was the used more than all other metrics combined for route selection in the backbone.) RFC1771 does not list AS_PATH length as a selection criteria - but at least RFC1771 does not specifically forbid use of AS_PATH length, as the draft for the next version does. Or perhaps I'm just misinformed. I have not actually read the draft for BGP 4+ (or whatever they're calling it now). This is second hand information, but I consider it to be from a very reliable source (even if he doesn't like ciscos ;). I am also not saying removal of this metric is a gigantic mistake, but my thought process to date leads me to tentatively believe it would be ... suboptimal. However, the people writing the spec obviously know more about it than I do, perhaps I've overlooked something. So, would anyone care to discuss (from an operational POV) what removing AS_PATH length from the BGP route selection algorithm will do to the Internet? >/vijay TTFN, patrick P.S. Before anyone goes off on me, I once again *agree* that the least cisco could do is deal with malformed announcements and the errors they generate properly. There are just other parts of the RFC with which I'm not so sure I agree. I Am Not An Isp www.ianai.net "Think of it as evolution in action." - Niven & Pournelle

2 1

IDIG-L Internet Distrubance Investigative Group mailing list
by Sean Donelan 17 Nov '98

17 Nov '98

I have set up a yet another mailing list (don't you just hate those words).... to discuss setting up an Internet Disturbance analysis forum. The most important thing is a catchy name. I came up with "IDIG", pronounced (eye-dig). For non-native english speakers it is a pun on "digging for answers" a slang term for some investigative methods, or it may refer to our mechanical backhoe friends which also "dig" either of which may be appropriate. I thought ITSB (a take off of the US NTSB, National Traffic Safety Board) would be asking for trouble. I believe I missed the IETF cut-off dates for a BOF, so if we did come up with something it would be at least the following meeting before it hit the IETF. It is actually two lists IDIG-L Internet Disturbance Analaysis Group Discussion An open (must subscribe to post) discussion list IDIG-ANNOUNCE Internet Disturbance Analaysis Group Announcements An moderated list LISTSERV instructions (yes, it is a real LISTSERV) send mail to "listserv(a)listserv.dra.com" containing the line SUBSCRIBE IDIG-L Your Name SUBSCRIBE IDIG-ANNOUNCE Your Name as always, replacing "Your Name" with your name. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0