North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: Withdrawls and announcements attempt 2

  • From: Craig Labovitz
  • Date: Fri Jun 21 12:10:56 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" <[email protected]> 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				[email protected]
Merit Network, Inc.			(313) 764-0252 (office) 
4251 Plymouth  Road, Suite C.		(313) 747-3745 (fax)
Ann Arbor, MI 48105-2785



- - - - - - - - - - - - - - - - -