North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: router startup behavior
Sorry, didn't get your first message clear in my head. The next question I would have is what do the routes look like. To get that many routes for a couple of class Cs, the router's BGP must be really broke. I would try to look at router type and software version and see if there is a correlation there. I would then try Cisco's web site to see what the known BGP issues are for that IOS version. The bug toolkit has a lot of resolved BGP bugs but you need to know the version and platform in order to get a better search. You usually need a support contract to get to this area but you might be able to talk them into helping you or having one of the service providers submit the problem as a trouble case. Can you provide a sample of the routing table during the bad advertisements ? Steve > -----Original Message----- > From: Stephen J. Wilcox [mailto:[email protected]] > Sent: Monday, January 14, 2002 1:53 PM > To: Ratul Mahajan; Steve Naslund > Subject: RE: router startup behavior > > > > that doesnt fit with the sequence of events outlined below > > ie > reboot > 1000+ routes appear > 1000+ routes removed > > you are saying > > line failure > 1000+ routes removed > line recovery > 1000+ routes appear > > and the numbers ie 1-1000 seems very high for this small provider with one > or two class Cs at a maximum > > On Mon, 14 Jan 2002, Steve Naslund wrote: > > > > > Here is my best guess as to what you are seeing. Most likely a > large CIDR > > block is announced > > by a service provider A. A small CIDR block is given to a > customer who is > > connected to multiple > > service providers and thus running BGP. Now the more specific route is > > announced by service provider B, > > he does not own the block but is announcing it on behalf of > service provider > > As customer. What is happening is that the customer has a line > or router > > failure and that withdraws their more specific announcement from service > > provider B. Since the service provider A is announcing a > supernet route he > > now becomes the only route > > for that block. > > > > +++++++++++++++++++++++++++++++ > > Steven Naslund > > Network Engineering Manager > > Hosting.com - Chicago > > +++++++++++++++++++++++++++++++ > > > > > -----Original Message----- > > > From: [email protected] [mailto:[email protected]]On Behalf Of > > > Ratul Mahajan > > > Sent: Monday, January 14, 2002 12:54 PM > > > To: [email protected] > > > Subject: router startup behavior > > > > > > > > > > > > > > > at university of washington, we are doing a measurement study of bgp > > > misconfiguration > > > (http://www.cs.washington.edu/homes/ratul/bgp/index.html). > > > > > > one of the things we found is that there are a lot of announcements of > > > more-specifics that come and go within a matter of 2-5 minutes. > > > > > > by talking to the operators involved in these incidents, we found that > > > most of these are caused when the router is rebooted (intentionally or > > > not). while some operators were aware of this side effect, > most were not, > > > and were taken by surprise that they just injected anywhere > from 1-1000 > > > routes into BGP only to withdraw them a couple of minutes later. > > > > > > i would like to understand this behavior better. is this behavior > > > vendor-specific (cisco?) or pervasive? is there a > configuration style that > > > causes or avoids this "spill-over"? > > > > > > my understanding is limited to this happens when the bgp > session comes up > > > too soon, before the filters have taken effect. could someone familiar > > > with router internals shed some light on it? > > > > > > the problem is limited to route origination only, or also propagation? > > > in other words, can a router propagate a route it should not while > > > starting up because export filters are not yet in place? > > > > > > never ever gotten my hands dirty into router configuration; your input > > > would be invaluable. > > > > > > thanks, > > > -- ratul > > > > > > > > > > > > -- > Stephen J. Wilcox > IP Services Manager, Opal Telecom > http://www.opaltelecom.co.uk/ > Tel: 0161 222 2000 > Fax: 0161 222 2008 > >
|