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.