Withdrawls and announcements attempt 2
I forgot to put my message in here... Here it was. I'll wake up one of these days. Ok, this is probably obvious, and may have been thought of by many of you before, but here are some thooughts. Comment if you'd like... Ok, the huge number of withdrawls with respect to announcements has to do with the fact that withdrawls of routes are made to a peer even if the announcement of that route was never made to the sepcified peer. (Or so conjectured Craig in his talk). At first I was wondering why they had such a thing written into the RFC (i.e. why am I withdrawing a route that I never announced to someone, it seems like a horrible waste), but in a blinding flash of the obvious while I was sitting outside having a cigarette it came to me.... Route map filters. Well, ok, how much more obvious can you get you ask? Its /a little/ more complex than that. The RFC does /not/ call for closing down a BGP session when you change your route filters. Cisco's have to do this, but its not part of the RFC. So, if I, for the sake of argument, added a new filter /after/ I made an announcement to someone I would have to somewhere keep track of the fact that I made the announcement. It seems to me that this could get to be a bit memory intensive (keeping track of the state of every announcement made to every peer). This leads me to wonder whether if we had infinite memory (just for the sake of argument), if it would be more processor intensive to keep track of all of your announcements or if the overhead invloved in dealing with withdrawls that don't affect me is less. Justin Newton Internet Architect Erol's Internet Services
"Justin W. Newton" <justin@erols.com> writes * Its /a little/ more complex than that. The RFC does /not/ call for closing * down a BGP session when you change your route filters. Cisco's have to do * this, but its not part of the RFC. So, if I, for the sake of argument, * added a new filter /after/ I made an announcement to someone I would have to * somewhere keep track of the fact that I made the announcement. It seems to * me that this could get to be a bit memory intensive (keeping track of the * state of every announcement made to every peer). * * This leads me to wonder whether if we had infinite memory (just for the sake * of argument), if it would be more processor intensive to keep track of all * of your announcements or if the overhead invloved in dealing with withdrawls * that don't affect me is less. There are however vendors out there that do exactly what you described above and can therefore change policies and have them take effect without having to take down a BGP session. And they only withdraw a prefix if they sent an update for it in the first place. -Marten
A quick clarification -- the liberal BGP widthraw policy implemented by Cisco (and a few other vendors) only accounts for a small fraction of the ~5 million plus daily withdraws in the default-free Internet. The real source of all these spurious withdraws remains a bit of a mystery. Our data shows some strange sort of 30 second looping/oscilation behavior is taking place. Possible causes of this behavior include configuration errors, unexpected IGP-EGP interactions, vendor implementation bugs, and problems inherent with the BGP protocol itself. The source of the millions of BGP withdraws is NOT Cisco's "liberal BGP withdraw" policy -- this generates a fairly minor number of extra withdraws (O(n) per router), and there are a quite a few valid and compelling reasons for wanting implementing BGP this way. - Craig at Fri, 21 Jun 1996 11:24:25 EDT, you wrote:
"Justin W. Newton" <justin@erols.com> writes
* Its /a little/ more complex than that. The RFC does /not/ call for closin
g
* down a BGP session when you change your route filters. Cisco's have to do * this, but its not part of the RFC. So, if I, for the sake of argument, * added a new filter /after/ I made an announcement to someone I would have to * somewhere keep track of the fact that I made the announcement. It seems t o * me that this could get to be a bit memory intensive (keeping track of the * state of every announcement made to every peer). * * This leads me to wonder whether if we had infinite memory (just for the sa ke * of argument), if it would be more processor intensive to keep track of all * of your announcements or if the overhead invloved in dealing with withdraw ls * that don't affect me is less.
There are however vendors out there that do exactly what you described above and can therefore change policies and have them take effect without having to take down a BGP session. And they only withdraw a prefix if they sent an update for it in the first place.
-Marten
-- Craig Labovitz labovit@merit.edu Merit Network, Inc. (313) 764-0252 (office) 4251 Plymouth Road, Suite C. (313) 747-3745 (fax) Ann Arbor, MI 48105-2785
A quick clarification -- the liberal BGP widthraw policy implemented by Cisco (and a few other vendors) only accounts for a small fraction of the ~5 million plus daily withdraws in the default-free Internet. The real source of all these spurious withdraws remains a bit of a mystery. Our data shows some strange sort of 30 second looping/oscilation behavior is taking place. Possible causes of this behavior include configuration errors, unexpected IGP-EGP interactions, vendor implementation bugs, and problems inherent with the BGP protocol itself.
The source of the millions of BGP withdraws is NOT Cisco's "liberal BGP withdraw" policy -- this generates a fairly minor number of extra withdraws (O(n) per router), and there are a quite a few valid and compelling reasons for wanting implementing BGP this way.
- Craig
What %age of the route assertions and withdrawls are substantially the same set of routes each day? Avi
Its /a little/ more complex than that. The RFC does /not/ call for closing down a BGP session when you change your route filters. Cisco's have to do this, but its not part of the RFC. So, if I, for the sake of argument, added a new filter /after/ I made an announcement to someone I would have to somewhere keep track of the fact that I made the announcement. It seems to me that this could get to be a bit memory intensive (keeping track of the state of every announcement made to every peer).
You need one bit per peer per path and code that is smart enough to use a bit map. For 40,000 paths and 128 BGP peers, thats an additional 640KB. In a 64 MB router thats 1% of memory. The reconfig code needs to be smart enough to deal with adding the 33rd peer if you want to do dynamic allocation. Gated and (unreleased) Bay code provide existance proof that can be done. When policy is changed such that something like a MED is changed, you need to go around clearing bits to indicate that the route needs to be readvertised. If the route needs to be withdrawn, leave the "I announced it" bits set. If it needs to be added, leave the bits clear. If it is changed, clear any bits to make it look like it wasn't advertised. Keep a list of routes that need attention and advertise out those that need to be advertised and withdraw those that need to be withdrawn, using the bit map to keep track of who still needs to get an update. Curtis
participants (5)
-
Avi Freedman -
Craig Labovitz -
Curtis Villamizar -
Justin W. Newton -
Marten Terpstra