Withdrawls and announcements attempt 2
Craig Labovitz
labovit at merit.edu
Fri Jun 21 16:04:59 UTC 1996
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 at 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 at merit.edu
Merit Network, Inc. (313) 764-0252 (office)
4251 Plymouth Road, Suite C. (313) 747-3745 (fax)
Ann Arbor, MI 48105-2785
More information about the NANOG
mailing list