[124370] in North American Network Operators' Group
Re: BGP Update Report
daemon@ATHENA.MIT.EDU (Danny McPherson)
Wed Mar 31 01:22:16 2010
From: Danny McPherson <danny@tcb.net>
In-Reply-To: <m2aatpupzq.wl%randy@psg.com>
Date: Tue, 30 Mar 2010 23:20:38 -0600
To: Randy Bush <randy@psg.com>
Cc: "nanog@nanog.org list" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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
