the root cause of the heavy bgp traffic you are observing is PR32066; JUNOS does trigger a duplicate eBGP message if there is an internal path change; the workaround is to set out-delay on the eBGP peer group to a value between 1-5 seconds, which supresses most cases of duplicate updates; out-delay 30s is way too large - it may jeopardize our BGP performance [cause we need to check a queue that is 30s deep for duplicate updates] and is not recommended; /hannes On Tue, Mar 04, 2003 at 05:46:04PM +0100, Christian Panigl, ACOnet/VIX/UniVie wrote: | Dear all, | | remembering the thread on "Route update stats" in December ? | | Specifically: | | http://www.ripe.net/ripe/mail-archives/routing-wg/2002/msg00050.html | | Now Christophe Belmont, GEANT-NOC, together with Juniper found a | solution and we successfully tested it: | | They implemented "BGP Guard Time" (Cisco like 30 seconds) and the | result was impressive: | | The number of BGP update messages received from GEANT dropped by ~85% | and the number of "flaps" seen from GEANT by ~75% ! | | BGP guard time (30sec) means that updates are only sent to neighbors for | prefixes which have stayed in the routing table for 30 seconds. I'm | sure you know the specific problem, that when a prefix is withdrawn in a | meshed environment, lots of updates are sent from BGP entities which do | think that they still have a (longer) path. It may take quite some time | until all these false updates are dying down. Without this guard time a | BGP speaker immediately forwards all those false updates to all peers. | I guess that if you would globally disable BGP guard time (which | fortunately is default ON=30seconds for Ciscos but apparently not for | Junipers) quite some routers would collapse on these withdrawal | aftermaths. | | So my suggestion would be for all ISPs using Juniper routers: turn on | "BGP Guard Time" (Cisco like 30 seconds). | | Christophe, probably you can post the details to the list !?