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 دقیقه مطالعه · آخرین به‌روزرسانی ۱ مهر ۱۴۰۵

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.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

ادامه

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

ادامه

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

ادامه

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

ادامه

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

ادامه

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

ادامه