Re: RFD and Duplicates in BGP
Danny McPherson <danny@...
2010-11-07 07:28:03 GMT
> where the network in question was said not have cluster id set on the
> rrs, thus producing dupes in a different distribution than one would see
There were certainly cluster IDs on the iBGP RRs, and even if there
weren't, they'd default to
the BGP RRs router ID, but that's not relevant anyway.
The point is that this could occur with any non-transitive non-mandatory
attribute, it's just much more obvious in places where more influencers
(e.g., RR or confederation path attributes that reflect internal
topologies but aren't propagated externally) surface.
There are two options here, the cleaner is for BGP implementations to keep
state of exactly what they've propagated to a given eBGP peer and avoid
readvertisement of duplicates that result from non-transitive attributes
being stripped. We chatted with Keyur about this when we saw the behavior
and he said there were some optimizations in some code, but not all.
Additionally, RFD implementations need to keep per path state for just
this reason else intermediate ASNs can have iBGP issues that result in
duplicates which penalize the entire prefix, even if it's reasonably
IIRC, RFC2439 describes something to this effect.
> but indeed, there are a lot of dupes out there.