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
On Mon, Jan 14, 2002 at 10:53:48AM -0800, Ratul Mahajan wrote:
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"?
It appears that routes are leaking out past a route-map based community based on a route that you e-mailed me about (as267 /30) that went to route-views.
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.
- jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
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: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Ratul Mahajan Sent: Monday, January 14, 2002 12:54 PM To: nanog@merit.edu 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
On Mon, 14 Jan 2002 13:28:42 -0600, 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.
If that's the problem, a fix might be to not advertise any routes to a BGP peer until you receive all the routes that peer has to send you. I think it's elegant that when two routers connect, neither sends any routes to the other until each has received all the routes the other has to send. Very Zen, don't you think? DS
to the best of my knowledge, here is what is happening. 1. router starts rebooting 2. there are routes in the routing table, some of which are not to be announce according to filters 3. bgp sessions comes up; the filters have not yet taken effect 4. start announcing routes 5. filters come up 6. the router realizes that it made a mistake and withdraws the routes not meant to be announced. i should also point out that all such incident are not 1000 router. most of them are 20-50, but i have seen non-trivial number of ~100 prefixes, and a couple more than that. -- ratul On Mon, 14 Jan 2002, Ratul Mahajan wrote:
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
:-> "Ratul" == Ratul Mahajan <ratul@cs.washington.edu> writes: > i should also point out that all such incident are not 1000 router. most > of them are 20-50, but i have seen non-trivial number of ~100 prefixes, > and a couple more than that. Do you have data about brand/model of the routers involved? I'd expect distributed equipment not to show such a behaviour, but who can tell... Pf -- ------------------------------------------------------------------------------- Pierfrancesco Caci | System Administrator @ seabone.net p.caci@seabone.net | Telecom Italia S.p.A. - International Wholesale Svcs Linux paperino 2.4.16 #1 Mon Nov 26 16:28:11 CET 2001 i686 unknown
participants (5)
-
David Schwartz
-
Jared Mauch
-
Pierfrancesco Caci
-
Ratul Mahajan
-
Steve Naslund