nanog mailing list archives
Re: BGP Update Report
From: Danny McPherson <danny () tcb net>
Date: Tue, 30 Mar 2010 23:20:38 -0600
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
Current thread:
- BGP Update Report cidr-report (Mar 05)
- <Possible follow-ups>
- BGP Update Report cidr-report (Mar 12)
- BGP Update Report cidr-report (Mar 19)
- Re: BGP Update Report Anton Kapela (Mar 27)
- Re: BGP Update Report Joe Provo (Mar 28)
- Re: BGP Update Report Anton Kapela (Mar 28)
- Re: BGP Update Report Danny McPherson (Mar 28)
- Re: BGP Update Report Randy Bush (Mar 30)
- Re: BGP Update Report Danny McPherson (Mar 30)
- Re: BGP Update Report Anton Kapela (Mar 27)