Danger! BGP command "no neighbor activate" removes neighbor config

[tlfergus111]

Hello all,

During a scheduled maintenance, my company recently had an issue where the BGP command "no neighbor activate" was used to disable a peer under an address-family instead of the command "neighbor shutdown". The result is that the BGP config for the neighbor was removed. The config included the command "neighbor route-map out" to set the next hop on outgoing advertisements so that the return traffic will be redirected to firewalls.

Normal:

"no neighbor activate"

When the neighbor was enabled again using "neighbor activate", the config was not restored completely. The result of the missing "neighbor route-map" was that the next hop was not set on the outgoing advertisements which caused asymmetric routing through the firewall and packets were dropped for being out-of-state.

"neighbor activate"

Post-mortem:

I have seen this behavior years ago because I learned the hard way just like my coworker. Lab tests have shown this on different hardware platforms and different IOS versions. (2800, 3600, 3800, 7200, 7600 ... 12.2, 12.4, etc)  This is not a bug but rather a programmed behavior. The problem is that this behavior is NOT DOCUMENTED ANYWHERE. The documentation for the command does say the 'no' form is used to disable a peer, but nothing about removing the config to accomplish that.

We opened a TAC case and also contacted our FES engineer. They both responded with the correct command that should have been used, "neighbor shutdown". At this point, it doesn't matter what the correct command is. There is no documentation showing (1) the neighbor commands will be removed; and (2) not all commands will be restored.

My tests so far show the commands "neighbor route-map" and "neighbor prefix-list" will not get restored.

Question for the Cisco community:

My question to all is whether anyone has seen this behavior before?  I can't believe I am the only person to know this, or rather, part of a select few that learned this the hard way. Cisco wrote the code in the IOS without documentation and they cannot explain the behavior other than reproducing it themselves.

Thanks,

Tom

[Peter Paluch]

Hello Tom,

As surprising as it may seem, I find this behavior logical. The neighbor activate command within an address-family stanza activates the BGP neighbor for a particular address family, i.e. it adds this neighbor as a new neighbor among other routers that are capable of exchanging prefixes of a particular format. It defines that this neighbor is expected to send and receive prefixes for the appropriate address family including all the prefix and attribute manipulation. Each configuration created for this neighbor in an address-family stanza would not be relevant if the neighbor itself was not added into the address family. Therefore, if you delete the neighbor using the no neighbor activate command, you are essentially saying to the router that this neighbor should no longer be spoken to with the prefix information for the particular address family, and all configuration for this neighbor is therefore deleted because this neighbor effectively ceased to exist for the particular address family.

Best regards,

Peter

[tlfergus111]

Hello Peter,

Many thanks for your update. I understand your point but I am undecided whether to agree just yet. You can add configuration for a neighbor but it won't become active until you enter 'neighbor activate'. The reverse should be true. Entering 'no neighbor activate' should disable the neighbor without removing the config. Documentation for this command says, "... you disable address exchange for address family IPv4 with a specific neighbor by using the no form of the neighbor activate command." My issue with Cisco is that the behavior of removing the config is not documented. Following the documentation without seeing the behavior firsthand could result in unexpected results. Our Cisco account engineering has contacted the business unit responsible for IP Routing with BGP to question the command's behavior and also documentation.

Thanks,

Tom

[elizer man-on]

This is a very dangerous command we need to avoid in BGP .

[tsarles]

Thank you for posting this. It has prevented me from making the same mistake.