Using Cisco EEM To Flap Interfaces For BGP Convergence

I like many people often balance price with need. It’s often difficult to look into my crystal ball and determine what piece of gear I need at a site…do I need an expensive router(both in cost and power) or can I get away with a switch…?

In some scenarios I will use a layer 2 point-to-point(transport) to connect to a remote location. At that site I might connect to one more more BGP peers. If I can just use a switch at that site it can save me a lot of money since I don’t have to put a big beefy router out at the site.

This puts me in a delicate position sometimes. When connecting to BGP peers they will default to sending hello messages every 60 seconds. If they miss three hellos, the peer is considered down and all routes from them are flushed. If these peers are directly connected this usually isn’t an issue since an interface flap will immediately flush all peer learned routes. What if, for example, you are using a switch to connect the peers together. If the transport link goes down, the peer connected to that switch has no idea…so that peer will continue to announce your routes for up to 3 minutes by default, blackholing all of that traffic! While it’s true that you should be able to lower these hello times, some of my peers won’t allow that…what to do…?

If only I could flap the peer interfaces when my transport drops…well, with Cisco Embedded Event Manager, you can.

First, configure tracking of an interface. This will allow the switch to watch the interface, and when it goes up or down, log it:

1
2
3
4

!Here I'm tracking Gigabit 1/17 on the switch
track 1 interface Gi1/17 line-protocol
!I configure it here to wait 5 seconds before alerting that the interface has returned.  This can easily be extended.
 delay up 5

The delay command can also have a down delay set so that it has to be down X seconds before being declared down. It would be configured as “delay up X down Y”.

Next I create an EEM script that reacts to the syslog messages that are created when the interface goes down:
Catalyst

1
2
3
4
5
6
7
8
9

event manager applet transit-flap-down
 event syslog pattern "TRACKING-5-STATE: 1 interface Gi1/17 line-protocol Up->Down"
 action 1.0 cli command "enable"
 action 1.5 syslog msg "transport flap down"
 action 2.0 cli command "conf t"
 action 3.0 cli command "interface gi1/2"
 action 4.0 cli command "shutdown"
 action 5.0 syslog msg "shutdown BGP Peer1 gi1/2"
 action 5.1 cli command "end"

Nexus

1
2
3
4
5
6
7
8
9

event manager applet transit-flap-down
 event tra 1 st down
 action 1.5 syslog priority notifications msg transport flap down
 action 2.0 cli conf t
 action 3.0 cli interface g1/2
 action 4.0 cli shutdown
 action 5.0 syslog priority notifications msg shutdown BGP Peer1 gi1/2
 action 5.1 cli end
 action 10.0 event-default

Here’s the opposite script that watches for the transport interface to return, then bring the peer interface back up:
Catalyst

1
2
3
4
5
6
7
8
9

event manager applet transit-flap-up
 event syslog pattern "TRACKING-5-STATE: 1 interface Gi1/17 line-protocol Down->Up"
 action 1.0 cli command "enable"
 action 1.5 syslog msg "transport flap up"
 action 2.0 cli command "conf t"
 action 3.0 cli command "interface gi1/2"
 action 4.0 cli command "no shutdown"
 action 5.0 syslog msg "enabled BGP Peer1 gi1/2"
 action 5.1 cli command "end"

Nexus

1
2
3
4
5
6
7
8
9

event manager applet transit-flap-up
 event tra 1 st up
 action 1.5 syslog priority notifications msg transport flap up
 action 2.0 cli conf t
 action 3.0 cli interface g1/2
 action 4.0 cli no shutdown
 action 5.0 syslog priority notifications msg enabled BGP Peer1 gi1/2
 action 5.1 cli end
 action 10.0 event-default

So in action, the transport interface goes down, and Gi1/2 is shutdown until it returns. This could shutdown multiple peer interfaces if you had multiple peerings off of this switch. EEM is pretty versatile and can be extremely useful.

Well, happy routing folks!