BGP Update Report

Danny McPherson danny at
Wed Mar 31 00:20:38 CDT 2010

On Mar 30, 2010, at 9:30 PM, Randy Bush wrote:

> might some of this be that the implementations use router-id to fill in
> an unconfigured rr cluster-id?

Yep!  So intermediate nodes in an iBGP topology with varying cluster 
IDs per RR with a common client set can certainly result in duplicate 
eBGP updates (not to mention lots of *useless* adj-RIB-In memory on 
those RRs for storing routes that are completely useless and would 
otherwise be discarded).

That said, even with common cluster IDs within a client set, and even
a single level (or completely flat) iBGP hierarchy, coupled with any 
jitter, variable propagation delay along a path, asymmetric or not, 
depending on transport connection dynamics, or variance in update arrival 
rates, and BGP speaker MRAI interactions with each, all can result in 
these duplicate updates at egress, and subsequent suppression via flap 
damping if employed.  And, of course, this is compounded by external 
interconnection denseness on ingress and even non-adjacent downstream 

I.e., there's room for protocol, implementation, and network architecture
variables here, and operators should expressly factor systemic effects of
each in their operating environment - they can have considerable impact.


More information about the NANOG mailing list