HSRP Object Tracking IP SLA

Lesson Contents

HSRP Object Tracking IP SLA monitors end-to-end reachability by actively probing an upstream host and automatically adjusting HSRP router priority when those probes fail. Unlike interface tracking, which only monitors whether a local interface’s line protocol is up, IP SLA can detect failures anywhere along the path to the probe destination, including a remote router going down while the local cable stays connected.

In this lesson, you’ll learn how to configure an IP SLA probe, link it to a track object, and associate that track object with an HSRP group. We’ll configure the probe, associate it with HSRP, simulate a failure with an inbound ACL on the upstream router, and verify the automatic failover to another HSRP router. Every command and every output in this lesson was captured directly from the lab devices, in the order it was executed, so you can follow the same sequence yourself.

Key Takeaways

HSRP IP SLA object tracking actively probes a remote host and automatically adjusts router priority when the probe fails, triggering failover even when the local interface remains physically up.
Create an IP SLA probe with ip sla <number>, configure it with icmp-echo <target> source-interface <interface>, and set a polling interval with frequency <seconds>.
Start the SLA probe with ip sla schedule <number> life forever start-time now to activate it immediately and keep it running indefinitely.
Create a track object with track <number> ip sla <number> reachability to monitor whether the SLA probe is succeeding or failing.
Associate a track object to an HSRP group using standby <group> track <number> decrement <value>, which reduces the router’s priority by the specified amount when the tracked object fails.
Both the active and standby routers should have the same IP SLA and track object configured so they monitor the same conditions and respond correctly to network changes. This isn’t a requirement, but it’s best practice.
Verify the probe with show ip sla statistics to see the latest return code and success/failure counters. Use show track to confirm the object state and which HSRP groups are tracking it.
Use show standby to display detailed HSRP state, including the current track object status and whether a priority decrement is active.

Prerequisites

You should understand HSRP Basic Configuration, including how to configure standby groups and virtual IP addresses. It can be useful to understand HSRP preemption because we use it in this lesson. IP SLA and object tracking are not too difficult, so you’ll learn them as we go through this lesson.

Configuration

Here’s the topology we’ll use for this lab:

#todo: Add topology image showing R1 and R2 with HSRP on the 192.168.12.0/24 segment (via SW1), R1 connected to R3 on 192.168.13.0/24, R2 connected to R3 on 192.168.23.0/24, and R3’s Loopback0 (3.3.3.3/32) as the IP SLA probe target.

Here’s what we have:

R1 and R2 are routers that will run HSRP:
- R1 is the primary router with priority 110.
- R2 is the standby router with priority 105.
We’ll run HSRP on the 192.168.12.0/24 subnet. SW1 is a Layer 2 switch that bridges R1’s and R2’s Ethernet0/1 interfaces onto this segment.
R1 has a separate point-to-point link to R3 on 192.168.13.0/24 (Ethernet0/2 on R1, Ethernet0/1 on R3).
R2 has a separate point-to-point link to R3 on 192.168.23.0/24 (Ethernet0/2 on both routers).
R3 has a Loopback0 interface with address 3.3.3.3/32. Both R1 and R2 will use IP SLA to probe this loopback to verify end-to-end reachability through their respective uplinks.

We use static routes on R1, R2, and R3 for full reachability.

Configurations

Want to take a look for yourself? Here you will find the startup configuration of each device.

hostname R1
!
ip cef
!
interface Ethernet0/1
 ip address 192.168.12.1 255.255.255.0
!
interface Ethernet0/2
 ip address 192.168.13.1 255.255.255.0
!
ip route 3.3.3.3 255.255.255.255 192.168.13.3
!
end

hostname R2
!
ip cef
!
interface Ethernet0/1
 ip address 192.168.12.2 255.255.255.0
!
interface Ethernet0/2
 ip address 192.168.23.2 255.255.255.0
!
ip route 3.3.3.3 255.255.255.255 192.168.23.3
!
end

hostname R3
!
ip cef
!
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
!
interface Ethernet0/1
 ip address 192.168.13.3 255.255.255.0
!
interface Ethernet0/2
 ip address 192.168.23.3 255.255.255.0
!
ip route 192.168.12.0 255.255.255.0 192.168.13.1
ip route 192.168.12.0 255.255.255.0 192.168.23.2
!
end

IP SLA Operation

IP SLA (Internet Protocol Service Level Agreement) is a Cisco IOS feature that sends active test packets to measure network performance and reachability. For HSRP object tracking, we use an ICMP echo probe. When the probe succeeds, the track object is up. When the probe fails, the track object goes down, and HSRP adjusts the router’s priority.

On R1, configure IP SLA operation 1 to send an ICMP echo to R3’s loopback (3.3.3.3), sourcing the probe from Ethernet0/2:

R1(config)#ip sla 1
R1(config-ip-sla)#icmp-echo 3.3.3.3 source-interface Ethernet0/2
R1(config-ip-sla-echo)#frequency 5
R1(config-ip-sla-echo)#exit
R1(config)#ip sla schedule 1 life forever start-time now
R1(config)#end

Here’s what each command does:

ip sla 1 creates IP SLA operation 1. This is the identifier you’ll reference when creating the track object.
icmp-echo 3.3.3.3 source-interface Ethernet0/2 sends ICMP echo requests to R3’s loopback at 3.3.3.3, using Ethernet0/2’s IP address (192.168.13.1) as the source. Keep in mind that source-interface only sets the source address; the outgoing interface is still chosen by the routing table. In this lab, it’s the static host route to 3.3.3.3 via 192.168.13.3 that sends the probe out of R1’s own uplink, so the probe tests that specific path.
frequency 5 sends a probe every 5 seconds. The default timeout is also 5 seconds, so a failed probe is detected within 5 to 10 seconds.
ip sla schedule 1 life forever start-time now starts the probe immediately and keeps it running forever. Without this command, the SLA operation is defined but not running.

Verify the SLA configuration with show ip sla configuration 1:

R1#show ip sla configuration 1
IP SLAs Infrastructure Engine-III
Entry number: 1
Owner: 
Tag: 
Operation timeout (milliseconds): 5000
Type of operation to perform: icmp-echo
Target address/Source interface: 3.3.3.3/Ethernet0/2
Type Of Service parameter: 0x0
Request size (ARR data portion): 28
Data pattern: 0xABCDABCD
Verify data: No
Vrf Name: 
Do not fragment: No
Schedule:
   Operation frequency (seconds): 5  (not considered if randomly scheduled)
   Next Scheduled Start Time: Start Time already passed
   Group Scheduled : FALSE
   Randomly Scheduled : FALSE
   Life (seconds): Forever
   Entry Ageout (seconds): never
   Recurring (Starting Everyday): FALSE
   Status of entry (SNMP RowStatus): Active
Threshold (milliseconds): 5000
Distribution Statistics:
   Number of statistic hours kept: 2
   Number of statistic distribution buckets kept: 1
   Statistic distribution interval (milliseconds): 20
Enhanced History:
History Statistics:
   Number of history Lives kept: 0
   Number of history Buckets kept: 15
   History Filter Type: None

This tells us everything we need to know: ICMP echo to 3.3.3.3 sourced from Ethernet0/2, running every 5 seconds with a 5-second timeout, running forever. The status shows Active, meaning the probe is running.

Track Object for IP SLA Reachability

Now create a track object that monitors the reachability result of the IP SLA operation:

R1(config)#track 100 ip sla 1 reachability
R1(config-track)#end

This combines track object 100 with IP SLA 1.

This is different from interface tracking. Here’s a comparison: IP SLA tracking catches failures that interface tracking misses. If the probe traffic to R3’s loopback stops getting through, whether because R3 is down, a route disappeared, or a filter along the path starts dropping it, but the Ethernet0/2 cable is still plugged in and the line protocol stays up, an interface track object would remain Up and leave R1 as the active HSRP router with no working upstream path.

An IP SLA track object detects that probes to 3.3.3.3 are failing and triggers the failover, regardless of the underlying cause. We’ll prove this later in the verification section by keeping R1’s interface completely untouched and checking its line protocol state during the outage.

HSRP Group with Priority Decrement

Now configure HSRP Group 1 on Ethernet0/1 and associate it with track object 100. When track object 100 goes down, R1’s priority will be decremented by 10 points, allowing R2 to become the active router:

R1(config)#interface Ethernet0/1
R1(config-if)#standby 1 priority 110
R1(config-if)#standby 1 preempt
R1(config-if)#standby 1 track 100 decrement 10
R1(config-if)#standby 1 ip 192.168.12.254
R1(config-if)#end

This is a basic HSRP configuration. We use HSRP Preemption so that the router with the highest priority becomes the active router. The standby 1 track command tells the router that when track 100 object 100 is down, it should reduce the priority by 10.

The decrement value must be chosen so that the active router’s priority drops below the standby router’s priority when the tracked object fails. In this lab, R1’s priority is 110, and R2’s is 105, so a decrement of 10 is sufficient.

IP SLA, Track Object, and HSRP Group on R2

It is a good idea to configure object tracking on both routers. It’s not a hard requirement, but it’s wise to make R2 monitor the same condition. Without it, R2 keeps its priority of 105 no matter what happens to its own uplink.

If R2’s Ethernet0/2 or its path to R3 fails, R2 stays at 105 while R1 sits at 110, so R1 remains active. That sounds fine until R1’s path also fails: R1 drops to 100, R2 is still at 105, and R2 takes over as the active router even though it has no working upstream path either. By configuring object tracking on both routers, they’ll respond similarly to network changes related to their path to R3. The router with the highest priority will become the active router.

Configure IP SLA operation 1 on R2:

R2(config)#ip sla 1
R2(config-ip-sla)#icmp-echo 3.3.3.3 source-interface Ethernet0/2
R2(config-ip-sla-echo)#frequency 5
R2(config-ip-sla-echo)#exit
R2(config)#ip sla schedule 1 life forever start-time now
R2(config)#end

Create the track object:

R2(config)#track 100 ip sla 1 reachability
R2(config-track)#end

Now configure HSRP Group 1 on R2 with a lower priority so it becomes the standby router. R2’s priority is 105, which is lower than R1’s 110:

R2(config)#interface Ethernet0/1
R2(config-if)#standby 1 priority 105
R2(config-if)#standby 1 preempt
R2(config-if)#standby 1 track 100 decrement 10
R2(config-if)#standby 1 ip 192.168.12.254
R2(config-if)#end

R2’s priority of 105 is lower than R1’s 110, so R2 will be the standby router. However, if track object 100 fails on R1, R1’s priority will be decremented to 100, which is lower than R2’s 105. At that point, R2 will become active because it still has the higher priority.

This completes the configuration.

Verification

Let’s verify our work.

HSRP Group Status and Baseline IP SLA/Track State

Let’s start with R1. First, IP SLA:

R1#show ip sla statistics
IPSLAs Latest Operation Statistics

IPSLA operation id: 1
	Latest RTT: 1 milliseconds
Latest operation start time: 13:20:02 UTC Wed Sep 23 2026
Latest operation return code: OK
Number of successes: 13
Number of failures: 0
Operation time to live: Forever

IP SLA is working and has successful probes. Object tracking works as well:

R1#show track 100
Track 100
  IP SLA 1 reachability
  Reachability is Up
    1 change, last change 00:01:08
  Latest operation return code: OK
  Latest RTT (millisecs) 1
  Tracked by:
    HSRP Ethernet0/1 1

Let’s check HSRP:

R1#show standby brief
                     P indicates configured to preempt.
                     |
Interface   Grp  Pri P State   Active          Standby         Virtual IP
Et0/1       1    110 P Active  local           192.168.12.2    192.168.12.254

R1 is the active router for Group 1 with priority 110. On R2:

R2#show standby brief
                     P indicates configured to preempt.
                     |
Interface   Grp  Pri P State   Active          Standby         Virtual IP
Et0/1       1    105 P Standby 192.168.12.1    local           192.168.12.254

R2 is in standby state, confirming that R1 is active. wo probes went out since the previous output (13:20:07 and 13:20:12), exactly what you’d expect from a 5-second frequency.
This is our baseline before we break anything.

Failure Simulation

One way to simulate a failure is to shut down R1’s uplink interface. That’s not the most convincing demonstration of what IP SLA object tracking actually buys you, because a shutdown interface also brings the line protocol down, which means an interface track object would have caught the same failure just as well.

To prove that IP SLA is really testing end-to-end reachability and not just local link state, we’ll instead leave R1’s interfaces alone and block the probe traffic itself with an inbound ACL on R3, the probe target. The physical link and the line protocol on R1’s Ethernet0/2 stay up the entire time; only R1’s ICMP echo gets dropped.

On R3, create an ACL that denies ICMP echo from R1’s probe source address (192.168.13.1) to R3’s loopback (3.3.3.3), but permits everything else:

R3(config)#ip access-list extended BLOCK_SLA_PROBE
R3(config-ext-nacl)#deny icmp host 192.168.13.1 host 3.3.3.3 echo
R3(config-ext-nacl)#permit ip any any
R3(config-ext-nacl)#exit

Apply it inbound on Ethernet0/1, the interface facing R1:

R3(config)#interface Ethernet0/1
R3(config-if)#ip access-group BLOCK_SLA_PROBE in
R3(config-if)#end

About 20 seconds after applying the ACL, we check the track object on R1:

R1#show track 100
Track 100
  IP SLA 1 reachability
  Reachability is Down
    2 changes, last change 00:00:21
  Latest operation return code: Timeout
  Tracked by:
    HSRP Ethernet0/1 1

The track object has already transitioned to Down. Check the SLA counters:

R1#show ip sla statistics
IPSLAs Latest Operation Statistics

IPSLA operation id: 1
	Latest RTT: NoConnection/Busy/Timeout
Latest operation start time: 13:20:47 UTC Wed Sep 23 2026
Latest operation return code: Timeout
Number of successes: 17
Number of failures: 5
Operation time to live: Forever

Now we see the number of failures increase. While the track object is down, take a look at the Ethernet0/2 interface of R1:

R1#show ip interface brief
Interface              IP-Address      OK? Method Status                Protocol
Ethernet0/0            10.65.97.11     YES TFTP   up                    up
Ethernet0/1            192.168.12.1    YES manual up                    up
Ethernet0/2            192.168.13.1    YES manual up                    up
Ethernet0/3            unassigned      YES unset  administratively down down

R1#show interfaces Ethernet0/2 | include line protocol
Ethernet0/2 is up, line protocol is up

Ethernet0/2 is still up, line protocol up, exactly as it was in the baseline. This is proof that an interface line-protocol track object would never have caught this failure: the interface never changed state at all. Only the IP SLA probe traffic was affected, because R3’s ACL is silently discarding it. Now check the HSRP state on both routers:

R1#show standby brief
                     P indicates configured to preempt.
                     |
Interface   Grp  Pri P State   Active          Standby         Virtual IP
Et0/1       1    100 P Standby 192.168.12.2    local           192.168.12.254

R2#show standby brief
                     P indicates configured to preempt.
                     |
Interface   Grp  Pri P State   Active          Standby         Virtual IP
Et0/1       1    105 P Active  local           192.168.12.1    192.168.12.254

Here’s what happened:

R1’s priority has been decremented from 110 to 100 because track object 100 went down, even though R1’s Ethernet0/2 line protocol never went down.
R2 preempted and took the active role; R1 has moved to standby.
The active router is now R2 at 192.168.12.2.

Let’s look at the HSRP state on both routers to see the track object reflected in the group state:

R1#show standby
Ethernet0/1 - Group 1
  State is Standby
    4 state changes, last state change 00:00:18
  Virtual IP address is 192.168.12.254
  Active virtual MAC address is 0000.0c07.ac01 (MAC Not In Use)
    Local virtual MAC address is 0000.0c07.ac01 (v1 default)
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 2.736 secs
  Preemption enabled
  Active router is 192.168.12.2, priority 105 (expires in 9.840 sec)
  Standby router is local
  Priority 100 (configured 110)
    Track object 100 state Down decrement 10
  Group name is "hsrp-Et0/1-1" (default)
  FLAGS: 0/1

R2#show standby
Ethernet0/1 - Group 1
  State is Active
    2 state changes, last state change 00:00:29
  Virtual IP address is 192.168.12.254
  Active virtual MAC address is 0000.0c07.ac01 (MAC In Use)
    Local virtual MAC address is 0000.0c07.ac01 (v1 default)
  Hello time 3 sec, hold time 10 sec
    Next hello sent in 2.352 secs
  Preemption enabled
  Active router is local
  Standby router is 192.168.12.1, priority 100 (expires in 10.016 sec)
  Priority 105 (configured 105)
    Track object 100 state Up decrement 10
  Group name is "hsrp-Et0/1-1" (default)
  FLAGS: 1/1

R2#show track 100
Track 100
  IP SLA 1 reachability
  Reachability is Up
    1 change, last change 00:01:43
  Latest operation return code: OK
  Latest RTT (millisecs) 1
  Tracked by:
    HSRP Ethernet0/1 1

Here’s what we see:

Track object 100 state Down decrement 10 on R1 confirms the priority decrement of 10 is active. The configured priority is 110, but the effective priority is now 100 (110 – 10 = 100).
R2’s track object 100 still shows Up, unchanged at 1 change since it came up, because R2’s own probe to 3.3.3.3, sourced from 192.168.23.2 and arriving on R3’s Ethernet0/2, is not touched by the ACL applied only to Ethernet0/1. Only R1’s probe is being blocked.
R2 is now Active at priority 105, which is higher than R1’s decremented 100.

Confirm on R3 that the ACL is actually matching R1’s probe traffic:

R3#show access-lists BLOCK_SLA_PROBE
Extended IP access list BLOCK_SLA_PROBE
    10 deny icmp host 192.168.13.1 host 3.3.3.3 echo (8 matches)
    20 permit ip any any

8 matches on the deny line so far. We let the outage continue and check R1’s IP SLA a bit later:

R1#show ip sla statistics
IPSLAs Latest Operation Statistics

IPSLA operation id: 1
	Latest RTT: NoConnection/Busy/Timeout
Latest operation start time: 13:24:27 UTC Wed Sep 23 2026
Latest operation return code: Timeout
Number of successes: 17
Number of failures: 49
Operation time to live: Forever

Successes are still at 17, exactly where they were before, since no probe has succeeded since the ACL started dropping the traffic. On R3, the deny counter grew right along with it:

R3#show access-lists BLOCK_SLA_PROBE
Extended IP access list BLOCK_SLA_PROBE
    10 deny icmp host 192.168.13.1 host 3.3.3.3 echo (49 matches)
    20 permit ip any any

49 matches on the deny line, matching the 49 failures on R1’s IP SLA counters.

Restore the Probe Path

Now let’s remove the ACL from R3’s Ethernet0/1:

R3(config)#interface Ethernet0/1
R3(config-if)#no ip access-group BLOCK_SLA_PROBE in
R3(config-if)#end

Once the ACL is gone, R3 starts replying to R1’s ICMP echo again. When the track object returns to Up, R1’s priority is restored to 110, and because preemption is enabled, R1 reclaims the active role. A little later, we check the track object:

R1#show track 100
Track 100
  IP SLA 1 reachability
  Reachability is Up
    3 changes, last change 00:00:46
  Latest operation return code: OK
  Latest RTT (millisecs) 1
  Tracked by:
    HSRP Ethernet0/1 1

Track object 100 has returned to the Up state, confirming that the probe is reaching R3 again. The track object flips back to Up on the first successful reply, and as the SLA counters below show, the first successful probe after the outage.

Now check the HSRP state on both routers:

R1#show standby brief
                     P indicates configured to preempt.
                     |
Interface   Grp  Pri P State   Active          Standby         Virtual IP
Et0/1       1    110 P Active  local           192.168.12.2    192.168.12.254

R2#show standby brief
                     P indicates configured to preempt.
                     |
Interface   Grp  Pri P State   Active          Standby         Virtual IP
Et0/1       1    105 P Standby 192.168.12.1    local           192.168.12.254

R1 has returned to the Active state because:

R3’s ACL no longer blocks R1’s probe, so the IP SLA probe to 3.3.3.3 succeeds again.
Track object 100 is Up, so the priority decrement is no longer applied.
R1’s priority is back to 110, and with preemption enabled, R1 reclaims the active role.

R2 has correctly returned to standby state. Let’s check IP SLA on R1 again:

R1#show ip sla statistics
IPSLAs Latest Operation Statistics

IPSLA operation id: 1
	Latest RTT: 1 milliseconds
Latest operation start time: 13:25:27 UTC Wed Sep 23 2026
Latest operation return code: OK
Number of successes: 28
Number of failures: 50
Operation time to live: Forever

Successes have started climbing again (17 to 28), and failures finished at 50.

For completeness, we remove the temporary ACL entirely from R3 afterward so the router returns to its original startup configuration:

R3(config)#no ip access-list extended BLOCK_SLA_PROBE
R3(config)#end

That’s all there is to it!

Configurations

Want to take a look for yourself? Here you will find the final configuration of each device.

hostname R1
!
ip cef
!
track 100 ip sla 1 reachability
!
interface Ethernet0/1
 ip address 192.168.12.1 255.255.255.0
 standby 1 ip 192.168.12.254
 standby 1 priority 110
 standby 1 preempt
 standby 1 track 100 decrement 10
!
interface Ethernet0/2
 ip address 192.168.13.1 255.255.255.0
!
ip route 3.3.3.3 255.255.255.255 192.168.13.3
!
ip sla 1
 icmp-echo 3.3.3.3 source-interface Ethernet0/2
  frequency 5
ip sla schedule 1 life forever start-time now
!
end

hostname R2
!
ip cef
!
track 100 ip sla 1 reachability
!
interface Ethernet0/1
 ip address 192.168.12.2 255.255.255.0
 standby 1 ip 192.168.12.254
 standby 1 priority 105
 standby 1 preempt
 standby 1 track 100 decrement 10
!
interface Ethernet0/2
 ip address 192.168.23.2 255.255.255.0
!
ip route 3.3.3.3 255.255.255.255 192.168.23.3
!
ip sla 1
 icmp-echo 3.3.3.3 source-interface Ethernet0/2
  frequency 5
ip sla schedule 1 life forever start-time now
!
end

hostname R3
!
ip cef
!
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
!
interface Ethernet0/1
 ip address 192.168.13.3 255.255.255.0
!
interface Ethernet0/2
 ip address 192.168.23.3 255.255.255.0
!
ip route 192.168.12.0 255.255.255.0 192.168.13.1
ip route 192.168.12.0 255.255.255.0 192.168.23.2
!
end

Conclusion

You now understand how HSRP IP SLA object tracking monitors end-to-end reachability and automatically adjusts router priority to trigger failover when probes to an upstream host fail. The key concept is that IP SLA probes actively test the path to a destination, detecting failures that interface tracking would miss entirely, including failures that have nothing to do with the local interface’s line protocol.

We configured IP SLA operation 1 on both R1 and R2 to probe R3’s loopback at 3.3.3.3, each over its own separate uplink, created track object 100 to monitor the SLA reachability, and associated it with HSRP Group 1 using standby 1 track 100 decrement 10. We then proved the mechanism with a more realistic failure than an interface shutdown: an inbound ACL on R3 that selectively dropped only R1’s ICMP echo probes. We explicitly checked show interfaces Ethernet0/2 | include line protocol and show ip interface brief on R1 throughout the outage and confirmed the interface stayed up, line protocol up, the entire time, proving that an interface-based track object would never have detected this failure. Meanwhile, the IP SLA track object correctly went down, R1’s priority decreased from 110 to 100, and R2 became active.

When the ACL was removed and probes resumed, R1 reclaimed the active role. We confirmed with show ip sla statistics and R3’s show access-lists that R1’s failure counter tracked R3’s deny counter for the whole outage window (50 denies, 50 failures), and because the probe runs on a fixed 5-second cadence, those counters let us reconstruct the start and end of the outage to within a single probe interval.

Remember that preemption must be enabled for the standby router to take over when the active router’s priority decrements. Also remember that IP SLA tracking introduces a small detection delay, up to one probe interval plus the probe timeout, before the track object transitions to Down. If a probe destination flaps repeatedly, use the delay command on the track object to dampen the response:

R1(config)#track 100 ip sla 1 reachability
R1(config-track)#delay up 20 down 10

The track object now has to observe a failed condition for 10 seconds before reporting Down, and a successful condition for 20 seconds before reporting Up again. This prevents a flapping path from causing repeated HSRP failovers.

I hope you enjoyed this lesson. If you have any questions, feel free to leave a comment!