Shut Down BGP Session Based on Tracked Object

In responses to my The Road to Complex Designs is Paved With Great Recipes post Daniel suggested shutting down EBGP session if your BGP router cannot reach the DMZ firewall and Cristoph guessed that it might be done without changing the router configuration with the neighbor fall-over route-map BGP configuration command. He was sort-of right, but the solution is slightly more convoluted than he imagined.

Cristoph’s original idea was simple enough: create a fake static route based on a track object (that can track anything you want) and match that route with the fall-over route-map. Unfortunately, that’s not how the fast fall-over functionality works – it takes the neighbor’s IP address, finds all routes that can be used to reach the neighbor, and tests them with the specified route-map (more details in my Designing Fast Converging BGP Networks article – search for it somewhere in this list).

I used a creative approach to create a static route that fits the requirements of the Fast Peering Deactivation: a host route toward the BGP next hop pointing at BGP next hop.

Let’s walk through a lab-tested example: The router is running BGP in AS#65100 and has an EBGP session with in AS#65000:

router bgp 65100
 bgp log-neighbor-changes
 network mask
 neighbor remote-as 65000

First we have to create the track object that will cause the BGP session termination. It can track anything – you can track interface state, use IP SLA and ping the firewall, or even use EEM to trigger time-based (or other event-based) session shutdown. I decided to track the state of the LAN interface.

There are simpler solutions if you want to originate a BGP route only when the LAN interface is operational. Read this blog post for more information.

track 10 interface FastEthernet0/0 ip routing

Next, create a host route for the BGP next hop pointing to the next hop itself.

If you use a PPP interface to connect to the BGP next hop, make sure you disable peer neighbor-route, otherwise the router creates a competing host route for the BGP next hop.

ip route Serial1/0 track 10
interface Serial1/0
 description Link to AS65000
 ip address
 encapsulation ppp
 no peer neighbor-route

We need a prefix-list and a route-map to match the host route toward the BGP next hop:

ip prefix-list BGP_OK seq 5 permit
route-map BGP_OK permit 10
 match ip address prefix-list BGP_OK

And finally, we can configure the fast BGP session deactivation on the EBGP session:

router bgp 65100
 neighbor fall-over route-map BGP_OK

Test#1 – shut down the LAN interface. BGP session is shut down almost immediately (you can fine-tune the delay with track object parameters).

A1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
A1(config)#int fa 0/0
15:27:55.719: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state to 
  administratively down
15:27:56.383: %TRACKING-5-STATE: 10 interface Fa0/0 ip routing Up->Down
15:27:56.415: %BGP-5-ADJCHANGE: neighbor Down Route to peer lost
15:27:56.415: %BGP_SESSION-5-ADJCHANGE: neighbor IPv4 Unicast 
  topology base removed from session  Route to peer lost
15:27:56.719: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
  FastEthernet0/0, changed state to down

Test#2 – re-enable the LAN interface. BGP session is reestablished in less than a second. Perfect ;)

A1(config-if)#no shut
15:29:22.211: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to up
15:29:22.395: %TRACKING-5-STATE: 10 interface Fa0/0 ip routing Down->Up
15:29:22.511: %BGP-5-ADJCHANGE: neighbor Up
15:29:23.211: %LINEPROTO-5-UPDOWN: Line protocol on Interface
  FastEthernet0/0, changed state to up

Need help?

BGP is one of those topics that never cease to intrigue me. If you need help getting it up and running, check out our ExpertExpress service.


  1. Is there a way to manage how BGP falls *back* over? Say if you want the primary session to stay down until you administratively inspect the event that caused the loss of the tracked object ?
  2. Just create an EEM applet that reacts to "track" object going down and sets another track object to "down".
  3. What I am currently doing is using EEM to watch my tracked objects and then issuing a neighbor shutdown command, then a a no neighbor shutdown command. (Along with email notifications)

    Is there a functional reason I would not want to do it that way, and use the method you prescribe?
  4. Great info; we have been literally working on this same problem area in our environment this week, but by trying to keep the BGP session up and instead stop advertising a network by removing that network's (static) route from the local routing table via tracking of an ip sla that pings the firewall interface.

    Unfortunately, I don't know what the delay is likely to be between when the route disappears from the routing table and BGP decides to stop advertising it, and so far I haven't been able to find that out. In our case, killing the whole BGP session is just as good, so we'll try this approach.
  5. Thanks for explanation!
  6. Hi Ivan,

    First, thanks for the great recipe!

    Is there are any limitation for this to work flawlessly? Or maybe I'm doing something wrong? When I've tried to implement it locally, I was tracking Loopback interface which shutdowns using EEM script based on HSRP event - everything worked fine (including few manual tests) for a few days before huge traffic flow brought my ISR2901 to the knees and HSRP event occurred, effectively shutting Loopback interface down. However, we haven't lost route to the BGP peer (somehow static route haven't been removed by Loopback tracking event). Am I missing something?
  7. Will the peer get re-established using the connected route or a less specific route?
  8. It works fine when I want to take down BGP session. But"delay" option on tracking object has no effect on BGP session re-establishment:
    *Mar 1 01:28:16.075: %BGP-5-ADJCHANGE: neighbor Up
    *Mar 1 01:30:38.979: %TRACKING-5-STATE: 1 rtr 1 state Down->Up
  9. Found this solution which works fine ( tracking line-protocol to make it easier, if in-direct failure needs to be fixed then IP SLA is required too):

    ip route Null0 track 1
    track 1 list boolean and
    object 10 not
    track 10 interface line-protocol
    delay up 180
  10. ip route (PER IP ADDRESS) Null0 track 1
    track 1 list boolean and
    object 10 not
    track 10 interface (WAN INTERFACE) line-protocol
    delay up 180
  11. Could you please explain for me the main purpose when you put this command in? and How can it effect to BGP neighbor forming process?
    ip route Serial1/0 track 10
    Thanks Ivan
    1. I would suggest you explore how "fast session failover" with a route map works.
  12. I made the configuration, and it works. But, the BGP session will be up by itself after about 30 secs.
Add comment