Lab Objective
Configure MD5 authentication on an HSRP group between two routers, verify normal active/standby operation continues with matching authentication strings, then introduce a third router with a mismatched string and confirm it cannot join the group or influence the election.
Lab Purpose
The HSRP labs covered earlier in this series established basic active/standby redundancy and object tracking, but never addressed a genuine security concern: without authentication, any device on the shared segment claiming the correct HSRP group number and virtual IP could potentially insert itself into the election, or even become active and hijack the default gateway role entirely.
Lab Topology
R1 (intended active) ---- Gi0/1 ---- Switch1
R2 (intended standby) ---- Gi0/1 ---- Switch1
RogueRouter ---- Gi0/1 ---- Switch1 (added later,
attempting to join
the same HSRP group)
Virtual IP: 192.168.200.1/24Task 1: Configure Basic HSRP Between R1 and R2
Configure HSRP group 1 on both routers with the shared virtual IP, R1 as active.
Task 2: Configure Matching MD5 Authentication
Configure the identical authentication string on both R1 and R2.
Task 3: Verify Normal Operation Continues
Confirm the active/standby relationship is unaffected by adding authentication.
Task 4: Introduce RogueRouter with a Mismatched Authentication String
Configure RogueRouter with the same HSRP group and virtual IP but a different authentication string, and attempt to join.
Task 5: Verify RogueRouter Is Excluded from the Group
Confirm RogueRouter cannot participate in the HSRP election due to the authentication mismatch.
Solution and Verification
R1(config)# interface gigabitethernet0/1
R1(config-if)# ip address 192.168.200.2 255.255.255.0
R1(config-if)# standby 1 ip 192.168.200.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.200.3 255.255.255.0
R2(config-if)# standby 1 ip 192.168.200.1R1(config)# interface gigabitethernet0/1
R1(config-if)# standby 1 authentication md5 key-string HsrpSecure2026
R2(config)# interface gigabitethernet0/1
R2(config-if)# standby 1 authentication md5 key-string HsrpSecure2026R1# show standby brief
Interface Grp Pri P State Active Standby Virtual IP
Gi0/1 1 150 P Active local 192.168.200.3 192.168.200.1
-- Normal active/standby relationship
-- continues unaffected -- matching
-- authentication caused no disruptionRogueRouter(config)# interface gigabitethernet0/1
RogueRouter(config-if)# ip address 192.168.200.4 255.255.255.0
RogueRouter(config-if)# standby 1 ip 192.168.200.1
RogueRouter(config-if)# standby 1 priority 200
RogueRouter(config-if)# standby 1 authentication md5 key-string WrongKey999
-- RogueRouter uses a HIGHER priority (200)
-- than R1's 150 -- without authentication,
-- this would normally let it seize the
-- active role outrightR1# show standby brief
Interface Grp Pri P State Active Standby Virtual IP
Gi0/1 1 150 P Active local 192.168.200.3 192.168.200.1
-- R1 remains Active DESPITE RogueRouter's
-- higher configured priority -- the
-- authentication mismatch prevents
-- RogueRouter's hello packets from being
-- accepted as legitimate HSRP messages at
-- all, so its priority value is never even
-- considered in the electionR1# debug standby packets
HSRP: Gi0/1 Grp 1 Hello in 192.168.200.4
Authentication failure, message ignored
-- Confirms R1 explicitly detected and
-- rejected RogueRouter's hello messages
-- due to the authentication mismatch,
-- rather than merely losing an election
-- it could have otherwise wonKey Takeaway
HSRP authentication operates as an admission control mechanism at the protocol level itself — a router presenting a mismatched authentication string is not merely deprioritized in the election, its hello packets are rejected outright as invalid, meaning even a much higher configured priority provides no path to becoming active without the correct shared authentication string, closing the security gap left open in the basic HSRP configuration covered in earlier labs.