BGP Update Report
danny at tcb.net
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