BGP router-id removed by loopback shutdown at SDA border ?

holger.moersfelder@global.ntt · ‎03-10-2021

All,

why get the command "bgp router-id interface loopback0" removed from the running-config when loopback0 is shutdown during operation ? Losing the BGP router-id isn't nice for bgp protocol.

Nevertheless there are usecases e.g. SDA route convergence (BGP/IGP) where an EEM script will shutdown the Loopback0 for a short periode of time and bring it back up again.

Unfortunately EEM script execution will remove the command "bgp router-id interface loopback0" and the highst IP addr. is elected as bgp router-id. As workaround the BGP router-id could be set to a static IP addr representing Loopback0.

This behaviour is observed on Cat9K running SW 17.3 or 16.12. release.

Hopefully someone can share some insides or thoughts.

Jonathan Cuthbert · ‎03-11-2021

This is question specifically about the behavior of Cisco IOS / IOS-XE with regards to the BGP router-ID, and not specifically about SD-Access?

To summarize your question, and please correct me if I am wrong:

When the Interface used for the BGP router-ID is put in a shutdown state, the command "bgp router-id interface <interface>" is removed from the running configuration. Upon bringing the interface back up, the command "bgp router-id interface <interface>" is not placed back into the running configuration.

I believe this is expected behavior. This particular question may be a candidate for moving it to the routing space.

holger.moersfelder@global.ntt · ‎03-11-2021

Jonathan, your summarization is correct and as the focus is on bgp routing the routing space may be a better place.

Nevertheless my intent is to address this issue to the SDA community as they might facing this usecase/issue.

Jonathan Cuthbert · ‎03-11-2021

holger.moersfelder@global.ntt wrote:

All,

Nevertheless there are usecases e.g. SDA route convergence (BGP/IGP) where an EEM script will shutdown the Loopback0 for a short periode of time and bring it back up again.

.

Can you share this EEM script, please, and what it is looking to accomplish with with regards to convergence.

holger.moersfelder@global.ntt · ‎03-11-2021

Find attached the EEM script which was posted by Adriana Vascan and Bheem Negi during DNA Tac Time october 2020.

This EEM script will address this usecase:

Border Redundancy – Convergence

Most common workaround is to configure an EEM script to keep the RLOC loopback down on the reloading Border while BGP is converging. Below configuration will keep the loopback shutdown for 2 minutes:

willwetherman · ‎03-11-2021

Hi holger.moersfelder@global.ntt

I noted the same behaviour as I have used both your attached EEM script and a similar EEM script that tracks default fabric border uplinks to a pair of shared services/fusion switches and shutdowns loopback0 in the event that both uplinks are down (to prevent the default border from blackholing traffic). When the scripts are triggered, and loopback0 is shutdown, 'bgp router-id interface loopback0' is removed from the running config which I now understand is expected behavior.

When I tested this, although the bgp router-id statement was removed from the running config, the actual router-id did not change and did not impact BGP when loopback0 was re-enabled and BGP peers where restored. This wasnt an issue initially, however, following an occasion of EEM script testing, the config was saved and the border was rebooted which resulted in a new router-id to be selected due to the lack of 'bgp router-id' in the startup config.

Solution as you suggested was to set a static bgp router id 'bgp router-id 10.1.1.1' Just to note that this behaviour didnt impact fabric operations in any way, or BGP path selection, it was only cosmetic as we like to configure the BGP router ID to match loopback0 (as per best practise)

holger.moersfelder@global.ntt · ‎03-12-2021

WIll,

thanks for your reply as you are facing the same challenge.

Using the best practise we are still not confident if the workaround "bgp router-id 10.1.1.1" is getting removed by DNA Center during provisioning/Sync as DNA had provisioned "bgp router-id interface loopback0" before . This would lead again to a situation where bgp router-id isnt predicted / set to highst IP addr.

Therefore we are testing a modified EEM script which will not shutdown loopback0 instead "ip router isis" command will be temporarily removed from loopback0. This approach will disable the border-node IP in the fabric to avoid any routing blackhole in the same manner.

Additionaly loopback0 is still active and bgp process is not impacted.

track 1 ip route 0.0.0.0 0.0.0.0 reachability
!
event manager applet POST_RELOAD_SHUT_LO0 authorization bypass
event syslog pattern "SYS-5-RESTART"
action 1.0 cli command "en"
action 2.0 cli command "conf t"
action 3.0 cli command "inter lo0"
action 4.0 cli command "no ip router isis"
action 5.0 cli command "end"
action 6.0 syslog priority critical msg "POST_RELOAD_LISP_RLOC_SHUTDOWN_COMPLETE"
!
event manager applet POST_RELOAD_NO_SHUT_LO0 authorization bypass
event syslog pattern "TRACK-6-STATE: 1 ip route 0.0.0.0/0 reachability Down -> Up"
event timer countdown name DELAY_RLOC_BRINGUP time 60
action 1.0 cli command "en"
action 2.0 cli command "conf t"
action 3.0 cli command "inter lo0"
action 4.0 cli command "ip router isis"
action 5.0 cli command "end"
action 6.0 syslog priority critical msg "POST_RELOAD_LISP_RLOC_NO_SHUTDOWN_COMPLETE"

But we will test this approach in our next poc.

regards holger

willwetherman · ‎03-12-2021

Hi holger.moersfelder@global.ntt

Thats interesting as we have not observed the behaviour of DNA Center overwriting the BGP router-id during any provisioning tasks. I will have to check this.

Your updated EEM script makes sense and avoids having to shutdown the loopback0 interface, which is useful if you use loopback0 for border management. I will test this as well when I get a chance.