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 ASNs. 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. -danny