GEANT implementing "BGP Guard Time" on their Junipers (was: Route update stats)
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 !? Kind regards CP --- ---------------------------------------------------------------------- --- --- Christian Panigl : Vienna University Computer Center - ACOnet --- --- VUCC - ACOnet - VIX : -------------------------------------------- --- --- Universitaetsstrasse 7 : Mail: Panigl@CC.UniVie.ac.at (CP8-RIPE) --- --- A-1010 Vienna / Austria : Tel: +43 1 4277-14032 (Fax: -9140) --- --- ---------------------------------------------------------------------- ---
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 !?
Hannes Gredler writes:
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;
There is actually another workaround for PR32066 that may be useful to some people: seting nexthop-self on the export policy facing ebgp. This should be a NOP in terms of what the advertisements look like for most people (i don't believe 3rd party nexthops are widely used). <blush> This bug is that, inadverly, a set of attributes that are relevant to iBGP only (iBGP nexthop, cluster-list and confed segments) are taking into account when comparing attributes for eBGP advertisements. Thus, duplicate eBGP advertisements are not being suppressed correctly. </blush> Expanding on the issue of out-delay... What out-delay does in JunOS, is to delay the advertisement of a route for <interval> seconds since the actual route change... This is very different from the cisco behaviour of advertisement interval which specifies an <interval> between 2 distinct sets of updates (by this it is ment 2 passes through the conceptual RIB-OUT). Assuming that there is always some noise in the network cisco's version of min-advertisement interval will in average delay an update by <interval>/2. So while both implementations take an <interval> in seconds, these values actually mean something quite different. Using the same absolute value on both implementations might not be what you want... Also, you want to size up ebgp out-delay according to your iBGP propagation times... a good heuristic for a single iBGP mesh is probably 2 x <worse case>. The factor 2 is so that a iBGP withdrawl can be propagated to the asbr w/ an alternate less prefered route and that it has time to readvertise that route. <worse-case> is typically verry dependent on your networking equipment... if you have ciscos using their default configs, the iBGP min-advertisement time is often used. These guesstimates are provided without any warranty ;-) Pedro.
participants (3)
-
Christian Panigl, ACOnet/VIX/UniVie -
Hannes Gredler -
Pedro Roque Marques