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).

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 10.0.7.10 in AS#65000:

router bgp 65100
 bgp log-neighbor-changes
 network 10.0.1.1 mask 255.255.255.255
 neighbor 10.0.7.10 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
 carrier-delay

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 10.0.7.10 255.255.255.255 Serial1/0 10.0.7.10 track 10
!
interface Serial1/0
 description Link to AS65000
 ip address 10.0.7.9 255.255.255.252
 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 10.0.7.10/32
!
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 10.0.7.10 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
A1(config-if)#shut
A1(config-if)#
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 10.0.7.10 Down Route to peer lost
15:27:56.415: %BGP_SESSION-5-ADJCHANGE: neighbor 10.0.7.10 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
A1(config-if)#
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 10.0.7.10 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 me (or one of our experts) for a few day on-site network design/review workshop, get in touch ... and there’s always the ExpertExpress option if you’re looking for a quick design review, second opinion or troubleshooting help.

6 comments:

  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 ?

    ReplyDelete
  2. Just create an EEM applet that reacts to "track" object going down and sets another track object to "down".

    ReplyDelete
  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?

    ReplyDelete
  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.

    ReplyDelete
  5. Thanks for explanation!

    ReplyDelete
  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?

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.