Posts Tagged ‘IP SLA’

Using BFD to Track WAN Status and Change HSRP Priority

July 29, 2015 Leave a comment

It’s been five years since I started this blog! Time flies and a lot has happened since. Thanks for being along for the ride. What better way to celebrate than a blog post?

This post is going to be short and to the point.

Many of us run HSRP or VRRP. It is quite common to run it in a topology where you have dual routers and dual exits to the WAN and you don’t want to black hole your traffic.


One traditional way of achieving this is by tracking the interface that goes towards the WAN. There are a couple of drawbacks to this approach though:

  • You may not get link down on failure (connecting to switch)
  • You may experience an error that does not produce link down event

The next option is to use IP SLA that sends ICMP Echo towards the next-hop of the WAN or some destination further into the network. Ehanced Object Tracking (EOT) can then be used to create a track object that decrements the priority of the HSRP active router when the ICMP Echo probe fails. This works better but there are still some drawbacks to this approach:

  • Frequency can’t be set to lower than one second
  • There is no multiplier, one failed ping is enough which can lead to false positives
  • False positives will lead to the state changing more than necessary
  • The above can be solved by using a delay for the tracking object
  • Using IP SLA is likely more CPU intensive than using BFD

Unfortunately there is no way to directly configure HSRP to check the status of BFD running on your WAN interface. That does not mean we can’t solve the task at hand though. BFD is supported over static routes. What if we insert a dummy route into the RIB when BFD is running successfully over the WAN link and track that this route is installed into the RIB. If it is not installed it must mean that BFD has failed and that the HSRP priority of the active router should be decremented.

The configuration is quite simple. In my lab I have an ISP router with the following config:

interface GigabitEthernet1.100
encapsulation dot1Q 100
ip address
bfd interval 500 min_rx 500 multiplier 3


router bgp 1
bgp log-neighbor-changes
network mask
neighbor remote-as 2
neighbor fall-over bfd

I’m using BGP in this case to have BFD packets sent over the link. There needs to be a protocol registered with BFD for the packets to be sent. It would be more likely for the ISP to configure a static route using BFD as well. If you are already running BGP, this configuration may be overkill since you could track routes coming from BGP.

This is then the configuration of the active HSRP router:

track 1 ip route reachability
interface GigabitEthernet1
no ip address
negotiation auto
interface GigabitEthernet1.100
encapsulation dot1Q 100
ip address
bfd interval 500 min_rx 500 multiplier 3
interface GigabitEthernet1.200
encapsulation dot1Q 200
ip address
standby 1 ip
standby 1 priority 110
standby 1 preempt
standby 1 track 1 decrement 11
router bgp 2
bgp log-neighbor-changes
neighbor remote-as 1
neighbor fall-over bfd
ip route static bfd GigabitEthernet1.100
ip route GigabitEthernet1.100

To trigger the BFD packets being sent over the WAN link we first have a static route pointing out the egress interface and the next-hop.

ip route static bfd GigabitEthernet1.100

Then we put a standard IP route statement which will insert the dummy route. It is important to point out the egress interface though for single-hop BFD.

ip route GigabitEthernet1.100

EOT is used to track if the route is installed into the RIB or not.

track 1 ip route reachability

The HSRP priority is decremented if the route is not in the RIB which will make the standby router become active.

standby 1 track 1 decrement 11

We can then test if it works by shutting down the interface on the ISP router.

ISP1(config)#int gi1

The change in the RIB is detected by the HSRP active router:

*Jul 29 15:57:23.278: %TRACK-6-STATE: 1 ip route reachability Up -> Down
*Jul 29 15:57:24.872: %HSRP-5-STATECHANGE: GigabitEthernet1.200 Grp 1 state Active -> Speak
*Jul 29 15:57:36.582: %HSRP-5-STATECHANGE: GigabitEthernet1.200 Grp 1 state Speak -> Standby

The standby router takes over:

*Jul 29 15:57:24.872: %HSRP-5-STATECHANGE: GigabitEthernet1.200 Grp 1 state Standby -> Active

What are the advantages of this setup compared to IP SLA?

  • Lightweight protocol designed to test reachability
  • Can send packets faster than one second in between each
  • Can define what multiplier to use

The drawback may be that you have to get your ISP to run BFD and that they need to put a static route in on their side as well. This can be a real route or a dummy route though.

Hopefully this post was somewhat useful and you’ll stay with me for another five years. Thanks for reading!

Categories: FHRP Tags: , , ,

IP SLA trickery

February 4, 2011 1 comment

This tuesday our primary Internet provider had a major outage. We recently got a backup but it was not implemented yet but I had to implement it in a hurry to get us back online. I had prepared most of the config but not everything had been tested. To check if the primary connection is up I ping an IP-address which is only reachable through the primary provider. The config looks like this.

ip sla 1
icmp-echo source-interface vlan 200
timeout 500
frequency 3

This will send an ICMP echo packet every 3 seconds. If a reply is not received within 500 ms it will be considered to have timed out. If you want to force the traffic to originate from a specific interface use the source-interface option.

We need to schedule the IP SLA operation to run.

ip sla schedule 1 life forever start-time now

Then we need to track the SLA operation.

track 1 rtr 1 reachability

Then we need to configure our routes to be dependant on the SLA operation.

ip route track 1
ip route 254

Traffic will be sent to while the SLA operation is successful. If it fails the static route will be removed from the routing table and the floating static route will be installed instead.

What I noticed while implementing this is that when the primary came back up the routing would not switch back. I later realized why. When the echo was sent from the backup it was following the backup default route and could therefore not reach its destination. I had configure a static /32 route for which always exits out the primary interface so that the primary can come backup when the echo is successful. To do a succesful implementation of IP SLA you should have an address that is only reachable on way and that is reliable, maybe a loopback on a router or something like that. You also want to ping as far in to the net as possible, just pinging your next-hop won’t help if there is a problem further away from you. Anyone else running IP SLA for failover?

Please note that all IP-addresses have been switched out from the real ones.

Categories: CCIE, Routing Tags: ,