When HSRP tracking an interface isn’t enough

I ran into an issue where I have HSRP going between two of my internet routers that are both using BGP to receive their default route and propagate out the routes for my network. I was tracking the WAN interface so that if it went down on either one side it would then move the HSRP addresses over to the other router. The issue I ran into was that my upstream BGP peer died and the interface stayed up for my primary connection.

So what issue did this cause? This made it so that HSRP addresses didn’t move since the interface didn’t go down.

I decided to dive into the cisco bag of tricks and figure out another way to monitor the BGP peer being up or down. Unfortunately this wasn’t something I could find in the 12.4 code, what I did find was the ability to monitor for a route being available. So since I only take a default route from the upstream BGP neighbors and my two connections are homed back to separate cities and BGP peers. I put in the following:

track 101 ip route 0.0.0.0 0.0.0.0 reachability

This allows the router to track for the default route being in the table, which if the BGP peer goes away so will this route. This can then shift the traffic over to the other internet connection and allow my access to the internet to live.

A simple sh track, shows that everything is working as it supposed to:

Track 101
IP route 0.0.0.0 0.0.0.0 reachability
Reachability is Up (BGP)
2 changes, last change 5d04h
First-hop interface is ATM4/0.148
Tracked by:
HSRP FastEthernet0/1 1
HSRP FastEthernet0/1 2
HSRP FastEthernet0/1 3
HSRP FastEthernet0/1 4
HSRP FastEthernet0/1 5
HSRP FastEthernet0/1 6

Simple clean and effective.