Hands-On Lab: Implementing HSRP

This hands-on lab configures HSRP between two routers sharing a virtual gateway address, sets priority and preempt to control which router is active, and verifies automatic failover when the active router fails.

HSRP ConfigurationActive Standby FailoverHSRP Preempt

~3 دقیقه مطالعه · آخرین به‌روزرسانی ۳۱ شهریور ۱۴۰۵

Lab Objective

Configure HSRP on two routers sharing a virtual IP address, set priority and preempt so a specific router becomes active, and verify traffic automatically fails over to the standby router when the active router goes down.

Lab Purpose

HSRP eliminates a single default gateway from being a single point of failure, discussed earlier in this series, by letting two routers share a virtual IP address that hosts use as their gateway, with one router actively forwarding while the other stands ready.

Lab Topology

R1 (intended active) ---- Gi0/1 ---- Switch1
R2 (intended standby) ---- Gi0/1 ---- Switch1

R1: 192.168.15.2/24
R2: 192.168.15.3/24
Virtual IP: 192.168.15.1/24

PC: 192.168.15.10/24, gateway 192.168.15.1

Task 1: Configure Basic Addressing

Configure both routers' interfaces on the shared segment.

Task 2: Configure HSRP on Both Routers

Configure the virtual IP address on both routers using HSRP group 1.

Task 3: Configure Priority and Preempt on R1

Set R1's priority higher than the default and enable preempt so R1 becomes and remains active.

Task 4: Verify Active and Standby Roles

Confirm R1 shows as active and R2 as standby.

Task 5: Simulate a Failure and Verify Failover

Shut down R1's interface and confirm R2 automatically becomes active, then restore R1 and confirm it reclaims the active role.

Solution and Verification

R1(config)# interface gigabitethernet0/1
R1(config-if)# ip address 192.168.15.2 255.255.255.0
R1(config-if)# no shutdown

R2(config)# interface gigabitethernet0/1
R2(config-if)# ip address 192.168.15.3 255.255.255.0
R2(config-if)# no shutdown

R1(config)# interface gigabitethernet0/1
R1(config-if)# standby 1 ip 192.168.15.1
R1(config-if)# standby 1 priority 150
R1(config-if)# standby 1 preempt

R2(config)# interface gigabitethernet0/1
R2(config-if)# standby 1 ip 192.168.15.1

R1# show standby brief

Interface  Grp  Pri P State   Active    Standby   Virtual IP
Gi0/1      1    150 P Active  local     192.168.15.3  192.168.15.1

R2# show standby brief

Interface  Grp  Pri P State   Active        Standby   Virtual IP
Gi0/1      1    100   Standby 192.168.15.2  local     192.168.15.1

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

R2# show standby brief

Interface  Grp  Pri P State   Active   Standby   Virtual IP
Gi0/1      1    100   Active  local    unknown   192.168.15.1
-- R2 automatically became active within
-- a few seconds of R1 going down

R1(config-if)# no shutdown

R1# show standby brief
Gi0/1      1    150 P Active  local    192.168.15.3  192.168.15.1
-- R1 reclaimed the active role because
-- preempt was configured and its priority
-- (150) is higher than R2's (100)

Key Takeaway

Without preempt, R1 would remain standby indefinitely after recovering from its outage, even with a higher priority, since HSRP does not automatically reclaim the active role unless explicitly told to — this is the same behavior noted for Spanning Tree's root bridge election earlier in this series, and it is a detail worth double-checking whenever a "primary" device unexpectedly stays in a backup role after coming back online.

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

مقالات مرتبط

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.

ادامه