HSRP Track Metric

HSRP can use object tracking to track if a route is present in the routing table and then alter the HSRP priority accordingly. This is more reliable than just tracking the status of an interface because an interface can remain in the up/up state even if the routing protocol is not working (i.e. if your BGP peering session went down).
The configuration would look something like this:



interface FastEthernet0/1
 ip address 192.168.10.1 255.255.255.0
 standby ip 192.168.10.254
 standby priority 105
 standby preempt
 standby track 1
!
track 1 ip route 3.3.3.3 255.255.255.255 reachability


This states that the router will check for the presence of 3.3.3.3/32 in the routing table and if it not there then decrement the HSRP priority by 10 (interestingly, the value of 10 is not explicitly configured anywhere and is a Cisco default value). The loss of this route from the routing table would change the priority to 95 which, assuming that the standby router is at the default value of 100, would cause it to assume the role of HSRP master if it has the preempt statement configured.


But what about a situation where we just want to check a metric change in the route that we are learning? I came across this where a router was configured to track a remote route but if the WAN link went down it would re-learn the remote route via the backup router and would therefore not release the HSRP active role.


The command to do this is:


track 1 ip route 3.3.3.3 255.255.255.255 metric threshold
  threshold metric up 2 down 20


Here we are tracking the presence of the 3.3.3.3 route and we are changing the HSRP priority value based on the metric of the route. This means that if the route has a value between 2 and 20 then the tracking object is considered up. If the metric is greater than 20 then the tracking object is considered down.


To check the metric:



R1#sh ip route 3.3.3.3 | i metric
  Known via "ospf 1", distance 110, metric 2, type intra area
      Route metric is 2, traffic share count is 1

 We then initiate a failure so that the route metric changes:



*Mar  1 01:45:46.963: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Dead timer expired
*Mar  1 01:46:06.595: %TRACKING-5-STATE: 1 ip route 3.3.3.3/32 metric threshold Up->Down
*Mar  1 01:46:08.727: %HSRP-5-STATECHANGE: FastEthernet0/1 Grp 0 state Active -> Speak
*Mar  1 01:46:18.727: %HSRP-5-STATECHANGE: FastEthernet0/1 Grp 0 state Speak -> Standby

We now repeat the metric check:



R1#sh ip route 3.3.3.3 | i metric
  Known via "ospf 1", distance 110, metric 20, type extern 2, forward metric 1
      Route metric is 20, traffic share count is 1


After restoring the link things revert back to normal:


*Mar  1 01:55:43.835: %OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on FastEthernet0/0 from LOADING to FULL, Loading Done
*Mar  1 01:55:58.091: %TRACKING-5-STATE: 1 ip route 3.3.3.3/32 metric threshold Down->Up
*Mar  1 01:55:59.735: %HSRP-5-STATECHANGE: FastEthernet0/1 Grp 0 state Standby -> Active

You can use the "ip ospf cost" interface command to change the metric if you need to fine tune this.