BGP Community Propagation on Cisco IOS/XE: The 90's Called
Just when I thought no vendor stupidity peculiarity could surprise me, Cisco IOS/XE proved me wrong.
I was improving a completely unrelated BGP functionality. I ran BGP integration tests on Cisco IOL (because it’s the fastest one to boot), and the BGP community propagation test failed. After verifying that I did not change the template and that the data structures had not changed, I checked the IOL release I was using.
Surprise 🎉🎉: the neighbor send-community configurations that worked since (at least) the IOS Classic release 15.x stopped working in Cisco IOS/XE release 17.16.01a.
Background Story
This is the help message offered by a Cisco IOS router for the neighbor send-community configuration command:
dut(config-router-af)#nei 10.1.0.1 send-community ?
both Send Standard and Extended Community attributes
extended Send Extended Community attribute
standard Send Standard Community attribute
<cr> <cr>
<cr> <cr> bit is trying to tell you that it’s OK to press ENTER without specifying the community type, but fails to mention it means standard community propagation. Oh well, we’ve seen worse.
Purely by accident (one has to suppose), using two configuration commands gets the desired results:
dut(config-router-af)#neighbor 10.1.0.2 send-community standard
dut(config-router-af)#neighbor 10.1.0.2 send-community extended
dut(config-router-af)#do show run | include neighbor 10.1.0.2 send
neighbor 10.1.0.2 send-community both
The neighbor send-community standard command followed by the neighbor send-community extended command magically results in neighbor send-community both. Mission Accomplished!
However, that no longer works in Cisco IOS/XE release 17.16.01a (even though it worked until at least IOS/XE release 17.15.01).
dut(config-router-af)#neighbor 10.1.0.2 send-community standard
dut(config-router-af)#neighbor 10.1.0.2 send-community extended
dut(config-router-af)#do show run | include neighbor 10.1.0.2 send
neighbor 10.1.0.2 send-community extended
WTA*? The propagation of standard BGP communities is gone.
Considering all the fairy tales I’ve been hearing about how it’s impossible to change any ridiculous old setting in a major network operating system, I’d love to know what triggered this sudden “back to the 90s” stunt.
I've always used "send-community both" and, if I'm not mistaken, this gets add to the config as that way. I cannot remember that I've ever seen "send-community standard" and "send-community extended" in any config. To me, it was always XOR "both" for both or "standard" / "extended" for one or the other only.
> I've always used "send-community both" and, if I'm not mistaken, this gets add to the config as that way.
Correct, it always appears as "both" in the configuration (see the blog post). However, if you're configuring stuff through a template, it helps if you can configure one after another, and then have whatever in the config.
I verified this on actual hardware on 17.18.01. Previous versions consolidate the two lines into one with the "both" keyword at the end. Now the commands override each other. If you enter standard first and then extended, extended is all you get. If you go the other way, standard will override extended. (Interestingly enough, even if you enter the "standard" keyword, it shows up in the config simply as "neighbor x.x.x.x send-community". I'm not a huge fan of re-working the user-input syntax, but these commands are as old as time.) You can still enter "neighbor x.x.x.x send-community both".
I don't know why we changed this. I'm pretty sure it's worked this way for as long as I've been configuring BGP, and that's a long time. I'll see if I can find anything out.
> I verified this on actual hardware on 17.18.01.
Thanks for the confirmation.
> I don't know why we changed this [...] I'll see if I can find anything out.
Thank you!
That reminds me of the old "show queueing" command misspelled for all of the 2000's on ciscos, then finally someone there decided to "fix" it later to "queuing" and broke some stat collection scripts I had used for a decade, not to mention retraining muscle memory when doing qos work later.
Then again, Cisco stopped being consistent about, well seems like anything by the late 2000's anyways (ahem, nxos), if not particularly qos.