On 01-03-18 13:50, Job Snijders wrote: > On Wed, Feb 28, 2018 at 09:52:50PM -0500, Jay Borkenhagen wrote: >> For what it's worth, I first noticed the special treatment of some >> well-known communities after Job announced his GRACEFUL_SHUTDOWN >> beacon prefix. I expected that it would not have passed intact >> through a "set community foo" policy, but it did. >> >> Clearly "set community foo" is not appropriate for use on many classes >> of connections -- e.g. on connections to one's customers -- but where >> it is used it should not cause surprises. > I agree that surprises are bad. What I struggle with is defining what > the sensible non-surprising behaviour is. > > IOS XR: "set community X" removes _all_ except WKC, and sets X > Junos: "set community X" removes _all_, and sets X > OpenBGPD: "set community X" is the equivalent of "set community X additive" > BIRD: "set community X" doesn't exist > ExaBGP: "set community X" doesn't exist > etc... > > Kind regards, > > Job Brocade NetIron also behaves like: "set community X" removes _all_, and sets X
To be honest, I am also surprised there is so much variance. Perhaps this explains why real-world incidents such as last November's Level3<>Comcast leak happen. That seemed to be the result of a stripped no-export community.. Link: https://dyn.com/blog/widespread-impact-caused-by-level-3-bgp-route-leak/ _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
