Track OSPF Route Metric

Topology:

R1 and R2 run HSRP on their Fa1/0 interfaces sharing the virtual IP 192.168.0.254. R1 has a higher HSRP priority (100) than R2 (90) so R1 is active and R2 is in the standby state. R1 has an OPSF metric of 101 to R3s loopback 10.0.0.3/32.

R1#show ip route 10.0.0.3
Routing entry for 10.0.0.3/32
  Known via "ospf 1", distance 110, metric 101, type intra area
  Last update from 10.0.13.3 on FastEthernet0/0, 00:00:08 ago
  Routing Descriptor Blocks:
  * 10.0.13.3, from 10.0.0.3, 00:00:08 ago, via FastEthernet0/0
      Route metric is 101, traffic share count is 1

R1#show track
Track 1
  IP route 10.0.0.3 255.255.255.255 metric threshold
  Metric threshold is Up (OSPF/101/101)
    13 changes, last change 00:00:06
  Metric threshold down 102 up 101
  First-hop interface is FastEthernet0/0
  Tracked by:
    HSRP FastEthernet1/0 1

The following is configured on R1:

conf t
 track 1 ip route 10.0.0.3 255.255.255.255 metric threshold
  threshold metric up 101 down 102
  exit

 interface FastEthernet1/0
  description Link to SW1
  ip address 192.168.0.1 255.255.255.0
  standby 1 ip 192.168.0.254
  standby 1 timers 2 6
  standby 1 preempt
  standby 1 authentication 9eaPSi58
  standby 1 track 1 decrement 20

This has the effect that when R1's direct link to R3 goes down its OSPF metric to 10.0.0.3 increases to the point where the track object which is tracking the metric of 10.0.0.3/32 passes it's "down" threshold ("down 102" above) and the track object changes state to down. This decrements the R1 HSRP priority by 20 dropping it to be lower (100-20=80) than the HSRP priority of R2 (90):

R3#conf t
R3(config)#int fa0/0
R3(config-if)#shut
*Nov 16 15:18:05.218: %OSPF-5-ADJCHG: Process 1, Nbr 10.0.0.1 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Interface down or detached

R1#
*Nov 16 15:18:08.762: %OSPF-5-ADJCHG: Process 1, Nbr 10.0.0.3 on FastEthernet0/0 from FULL to DOWN, Neighbor Down: Dead timer expired
*Nov 16 15:18:25.118: %TRACKING-5-STATE: 1 ip route 10.0.0.3/32 metric threshold Up->Down
*Nov 16 15:18:26.058: %HSRP-5-STATECHANGE: FastEthernet1/0 Grp 1 state Active -> Speak
*Nov 16 15:18:33.126: %HSRP-5-STATECHANGE: FastEthernet1/0 Grp 1 state Speak -> Standby

R2#
*Nov 16 15:18:26.266: %HSRP-5-STATECHANGE: FastEthernet1/0 Grp 1 state Standby -> Active

R1#show ip route 10.0.0.3
Routing entry for 10.0.0.3/32
  Known via "ospf 1", distance 110, metric 11002, type intra area
  Last update from 10.0.12.2 on FastEthernet0/1, 00:00:14 ago
  Routing Descriptor Blocks:
  * 10.0.12.2, from 10.0.0.3, 00:00:14 ago, via FastEthernet0/1
      Route metric is 11002, traffic share count is 1

R1#show track
Track 1
  IP route 10.0.0.3 255.255.255.255 metric threshold
  Metric threshold is Down (OSPF/11002/255)
    12 changes, last change 00:00:31
  Metric threshold down 102 up 101
  First-hop interface is FastEthernet0/1
  Tracked by:
    HSRP FastEthernet1/0 1

R1#show standby
FastEthernet1/0 - Group 1
  State is Speak
    18 state changes, last state change 00:00:03
  Virtual IP address is 192.168.0.254
  Active virtual MAC address is 0000.0c07.ac01
    Local virtual MAC address is 0000.0c07.ac01 (v1 default)
  Hello time 2 sec, hold time 6 sec
    Next hello sent in 0.304 secs
  Authentication text, string "9eaPSi58"
  Preemption enabled
  Active router is 192.168.0.2, priority 90 (expires in 4.576 sec)
  Standby router is unknown
  Priority 80 (default 100)
    Track object 1 state Down decrement 20
  Group name is "hsrp-Fa1/0-1" (default)

Now the metric for R1 to 10.0.0.3/32 is "11002" and R2 is in HSRP state active. However, on R2 its link to R4 has a much higher cost, 10000, in the case that the R1 > R3 link is down and the R2 > R4 link is down maybe it is desirable to have R1 as HSRP master again. As per the below the R2 to 10.0.0.4 OSPF metric is very high when the R1 to R3 link is down:

R2#show ip route 10.0.0.4
Routing entry for 10.0.0.4/32
  Known via "ospf 1", distance 110, metric 10001, type intra area
  Last update from 10.0.24.4 on FastEthernet0/0, 00:01:45 ago
  Routing Descriptor Blocks:
  * 10.0.24.4, from 10.0.0.4, 00:01:45 ago, via FastEthernet0/0
      Route metric is 10001, traffic share count is 1

Track objects only support an up/down threshold value between 1-255 so a value is used to divide the OSPF metric to bring it down into the 1-255 range on R2:

conf t
 track resolution ip route OSPF 100
 track 1 ip route 10.0.0.4 255.255.255.255 metric threshold
  threshold metric up 100 down 101
  exit

"track resolution ip route OSPF 100" has the effect of dividing any tracked OSPF route metric by 100 so the R2 > R4 metric for 10.0.0.4 becomes 10001/100 == 100. The value in the "Metric threshold is Up (OSPF/10001/100)" statement means that the current OSPF metric to 10.0.0.4 is 10001 and with when divided by 100 the result is 100, so the track object is in state Up "Metric threshold down 101 up 100":

R2#show track
Track 1
  IP route 10.0.0.4 255.255.255.255 metric threshold
  Metric threshold is Up (OSPF/10001/100)
    6 changes, last change 00:35:21
  Metric threshold down 101 up 100
  First-hop interface is FastEthernet0/0
  Tracked by:
    HSRP FastEthernet1/0 1

When the R1 to R3 link is restored the best path for R2 to 10.0.0.4 is via R1 and now the track object shows the following:

R2#show ip route 10.0.0.4
Routing entry for 10.0.0.4/32
  Known via "ospf 1", distance 110, metric 1102, type intra area
  Last update from 10.0.12.1 on FastEthernet0/1, 00:01:30 ago
  Routing Descriptor Blocks:
  * 10.0.12.1, from 10.0.0.4, 00:01:30 ago, via FastEthernet0/1
      Route metric is 1102, traffic share count is 1

R2#show track
Track 1
  IP route 10.0.0.4 255.255.255.255 metric threshold
  Metric threshold is Up (OSPF/1102/11)
    6 changes, last change 00:48:58
  Metric threshold down 101 up 100
  First-hop interface is FastEthernet0/1
  Tracked by:
    HSRP FastEthernet1/0 1

The OSPF metric of 1102 divided by 100 produces the result of 11 so the track object state is up, but even so up the HSRP priority on R2 (90) is lower than that of R1 (100) so R1 is the HSRP master as long as the R1 > R3 link is up.

If at any point R3 should become completely isolated from the network or 10.0.0.3 is unreachable, and thus the route doesn't exist within OSPF, this will trigger the track object on R1 to change state to down. The route being unavailable has the same impact as if the threashold were exceeded.

---