Hands-On Lab: Configuring Enhanced Object Tracking with HSRP

This hands-on lab configures IP SLA-based object tracking on an HSRP-enabled router, automatically lowering its priority when its WAN uplink fails, forcing failover to the standby router without requiring a full interface shutdown.

IP SLA Object TrackingHSRP Priority DecrementUplink Failure Detection

~4 min read · Updated Sep 23, 2026

Lab Objective

Configure an IP SLA tracking object monitoring reachability to an upstream address, link it to HSRP so the active router's priority automatically decrements if that upstream path fails, and verify failover occurs even though the router's LAN-facing interface itself never goes down.

Lab Purpose

The HSRP failover demonstrated earlier in this series relied on shutting down the LAN-facing interface directly — but a genuinely common real-world failure is the active router's WAN uplink going down while its LAN interface remains perfectly healthy. Without object tracking, HSRP would have no way to detect this and would keep forwarding LAN traffic toward a router that can no longer actually reach the internet.

Lab Topology

R1 (intended active) ---- Gi0/1 ---- Switch1 ---- LAN
R1 ---- Gi0/2 ---- WAN uplink toward ISP
R2 (intended standby) ---- Gi0/1 ---- Switch1

Virtual IP: 192.168.170.1/24
R1: 192.168.170.2, R2: 192.168.170.3

Task 1: Configure Basic HSRP

Configure HSRP on both routers as covered in an earlier lab, with R1 as active (higher priority, preempt enabled).

Task 2: Configure an IP SLA Tracking Object

Configure an IP SLA operation on R1 that pings a reliable upstream address, and a track object monitoring that operation's reachability.

Task 3: Link the Track Object to HSRP

Configure R1's HSRP group to decrement its priority when the tracked object goes down.

Task 4: Verify Normal Operation

Confirm R1 remains active while the tracked upstream address is reachable.

Task 5: Simulate a WAN Failure and Verify Failover

Shut down R1's WAN-facing interface (not the LAN interface) and confirm R2 becomes active despite R1's LAN interface remaining fully up.

Solution and Verification

R1(config)# interface gigabitethernet0/1
R1(config-if)# ip address 192.168.170.2 255.255.255.0
R1(config-if)# standby 1 ip 192.168.170.1
R1(config-if)# standby 1 priority 150
R1(config-if)# standby 1 preempt

R2(config)# interface gigabitethernet0/1
R2(config-if)# ip address 192.168.170.3 255.255.255.0
R2(config-if)# standby 1 ip 192.168.170.1

R1(config)# ip sla 1
R1(config-ip-sla)# icmp-echo 203.0.113.1
R1(config-ip-sla-echo)# frequency 5
R1(config)# ip sla schedule 1 life forever start-time now

R1(config)# track 1 ip sla 1 reachability

R1(config)# interface gigabitethernet0/1
R1(config-if)# standby 1 track 1 decrement 60

-- If the tracked object goes down, R1's
-- priority drops by 60 (from 150 to 90) --
-- enough to fall below R2's default
-- priority of 100, triggering failover

R1# show standby brief

Interface  Grp  Pri P State   Active    Standby   Virtual IP
Gi0/1      1    150 P Active  local     192.168.170.3  192.168.170.1

R1# show track 1

Track 1
  IP SLA 1 reachability
  Reachability is Up

R1(config)# interface gigabitethernet0/2
R1(config-if)# shutdown

-- This is the WAN interface, NOT the LAN
-- interface R1's HSRP group is configured on

R1# show track 1

Track 1
  IP SLA 1 reachability
  Reachability is Down

R1# show standby brief

Interface  Grp  Pri P State     Active        Standby  Virtual IP
Gi0/1      1    90    Standby   192.168.170.3  local    192.168.170.1
-- R1's priority dropped to 90, below R2's
-- 100, causing R2 to become active --
-- despite R1's own Gi0/1 (LAN) interface
-- still being fully up and connected

Key Takeaway

Object tracking decouples HSRP's failover decision from the state of the interface HSRP is actually configured on, allowing it to react to conditions elsewhere in the network entirely — this closes a real gap in the basic HSRP configuration covered earlier in this series, where a healthy LAN interface but a dead WAN uplink would otherwise go completely undetected.

Written & researched by Dr. Shahin Siami

Related Articles

Hands-On Lab: Configuring UDLD

This hands-on lab configures UDLD in aggressive mode on a fiber link between two switches, simulating a unidirectional fiber failure and verifying UDLD detects the mismatch and shuts down the affected port before a Layer 2 loop can form.

Continue

Hands-On Lab: Configuring Loop Guard

This hands-on lab configures Loop Guard on a switch's non-designated ports to prevent a unidirectional link failure from causing a Layer 2 loop, simulating a one-way BPDU loss and verifying the affected port enters a loop-inconsistent blocking state rather than incorrectly transitioning to forwarding.

Continue

Hands-On Lab: Configuring BPDU Guard and BPDU Filter

This hands-on lab configures BPDU Guard globally for PortFast-enabled ports and demonstrates the distinct, riskier behavior of BPDU Filter, comparing how each responds when a switch is connected to an access port that should only ever see end-user devices.

Continue

Hands-On Lab: Configuring Root Guard

This hands-on lab configures Root Guard on switch ports facing access-layer switches to prevent an unauthorized or misconfigured switch from becoming the Spanning Tree root, verifying the port enters a root-inconsistent state when a superior BPDU is received.

Continue

Hands-On Lab: Comprehensive Troubleshooting Challenge

This hands-on lab presents a multi-layer connectivity failure across VLANs, trunking, routing, and NAT simultaneously, requiring systematic bottom-up troubleshooting to identify and correct three independent faults before full connectivity is restored.

Continue

Hands-On Lab: Configuring Basic DMVPN (mGRE with NHRP)

This hands-on lab configures a basic single-hub DMVPN topology using a multipoint GRE tunnel and NHRP, demonstrating how a spoke dynamically registers its physical address with the hub without requiring a separate point-to-point tunnel per spoke.

Continue
Hands-On Lab: Configuring Enhanced Object Tracking with HSRP | Dr. Shahin Siami