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
"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