Hands-On Lab: Configuring VRRP

This hands-on lab configures VRRP between two routers as the open-standard alternative to HSRP, using a real interface address as the virtual IP, and verifies Master/Backup roles and automatic failover behavior.

VRRP ConfigurationMaster and Backup RolesOpen Standard Redundancy

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

Lab Objective

Configure VRRP on two routers sharing a virtual IP address, verify Master and Backup roles form correctly, and confirm automatic failover occurs when the Master router fails.

Lab Purpose

VRRP serves the same purpose as HSRP, covered in an earlier lab, but as a vendor-neutral open standard, making it the correct choice whenever a redundancy group needs to include non-Cisco equipment. This lab highlights the terminology differences engineers must recognize when moving between the two protocols.

Lab Topology

R1 (intended Master) ---- Gi0/1 ---- Switch1
R2 (intended Backup) ---- Gi0/1 ---- Switch1

R1: 192.168.17.1/24 (this address will
    also serve as the virtual IP)
R2: 192.168.17.3/24

PC: 192.168.17.10/24, gateway 192.168.17.1

Task 1: Configure Basic Addressing

Configure both routers' interfaces on the shared segment.

Task 2: Configure VRRP on Both Routers

Configure VRRP group 1 on both routers, using R1's own real interface address (192.168.17.1) directly as the virtual IP.

Task 3: Set Priority on R1

Set R1's VRRP priority higher than the default so it becomes Master.

Task 4: Verify Master and Backup Roles

Confirm R1 shows as Master and R2 as Backup.

Task 5: Simulate a Failure and Verify Failover

Shut down R1's interface and confirm R2 automatically becomes Master.

Solution and Verification

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

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

R1(config)# interface gigabitethernet0/1
R1(config-if)# vrrp 1 ip 192.168.17.1
R1(config-if)# vrrp 1 priority 150

-- Notice the virtual IP matches R1's own
-- real interface address exactly -- a
-- capability unique to VRRP, distinct from
-- HSRP which always requires a separate
-- dedicated virtual address

R2(config)# interface gigabitethernet0/1
R2(config-if)# vrrp 1 ip 192.168.17.1

R1# show vrrp brief

Interface  Grp  Pri  Time  Own  Pre  State    Master addr   Group addr
Gi0/1      1    150  3609  Y    Y    Master   192.168.17.1  192.168.17.1

-- The "Own" column shows "Y", confirming R1
-- owns the actual IP address being used as
-- the virtual address

R2# show vrrp brief

Interface  Grp  Pri  Time  Own  Pre  State    Master addr   Group addr
Gi0/1      1    100  3609  N    Y    Backup   192.168.17.1  192.168.17.1

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

R2# show vrrp brief

Interface  Grp  Pri  Time  Own  Pre  State    Master addr   Group addr
Gi0/1      1    100  3609  N    Y    Master   192.168.17.3  192.168.17.1
-- R2 automatically became Master

Key Takeaway

VRRP uses "Master" and "Backup" instead of HSRP's "Active" and "Standby" terminology, and its preempt behavior is enabled by default (unlike HSRP, which requires the preempt keyword to be explicitly configured) — both are worth remembering when moving between protocols, since assuming identical default behavior between HSRP and VRRP is a common source of unexpected configuration results.

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

مقالات مرتبط

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.

ادامه