How to Configure VRRP on Cisco for Gateway Redundancy (Step by Step)

Step 1 — Plan the topology and the virtual IP

Before touching the CLI, decide three things: the shared subnet, the virtual IP (VIP) that hosts will use as their default gateway, and which router you want to be master under normal conditions. In VRRP the elected router is the master and the others are backups (HSRP calls these active and standby — same idea, different words).

For this guide, two routers sit on 10.1.1.0/24. R1 uses 10.1.1.2, R2 uses 10.1.1.3, and the VIP is 10.1.1.1. Every host on the LAN sets its default gateway to 10.1.1.1 — never to a router's real interface address, or you lose the whole point of failover. A critical planning rule: pick a VIP that is NOT already assigned to any router's interface. If the VIP happens to equal a router's real IP, that router becomes the address owner and is forced to priority 255 (covered in Step 6), which overrides any priority you configure elsewhere.

VRRP routers in the same group elect a master by exchanging advertisements to multicast 224.0.0.18 using IP protocol number 112. That detail matters for troubleshooting: if an ACL or a switch filter blocks protocol 112 or that multicast on the segment, the routers can't hear each other and both declare themselves master.

Step 2 — Configure the physical interfaces

Give each router a unique real IP in the shared subnet and bring the interface up. VRRP rides on top of these addresses; it does not replace them. The virtual IP is added on top in the next step.

R1(config)# interface GigabitEthernet0/0
R1(config-if)# ip address 10.1.1.2 255.255.255.0
R1(config-if)# no shutdown
!
R2(config)# interface GigabitEthernet0/0
R2(config-if)# ip address 10.1.1.3 255.255.255.0
R2(config-if)# no shutdown

Step 3 — Enable VRRP and assign the virtual IP

Enable VRRP under the interface with a group number and the shared virtual IP. The group number (1 in this example) must be identical on every router that shares this VIP — the group number, not the interface name, is what binds the routers into one redundancy pair. VRRPv2 supports groups 1–255.

The instant both routers have this line, they elect a master and one of them starts answering ARP for 10.1.1.1 with the VRRP virtual MAC 0000.5e00.01XX, where XX is the group number in hex (group 1 = 0000.5e00.0101). Using a virtual MAC — not a router's burned-in address — is what lets failover happen without hosts having to re-ARP.

Note on IOS versions: the interface-level vrrp commands shown here are the long-standing syntax and are present on most IOS and IOS-XE images, where they run VRRPv2 by default. Some newer IOS-XE releases use a hierarchical VRRPv3 parser (fhrp version vrrp v3, then vrrp <grp> address-family ipv4). If the classic commands aren't accepted on your platform, check Cisco's current command reference for your specific IOS-XE release rather than assuming a fixed behavior.

R1(config)# interface GigabitEthernet0/0
R1(config-if)# vrrp 1 ip 10.1.1.1
!
R2(config)# interface GigabitEthernet0/0
R2(config-if)# vrrp 1 ip 10.1.1.1

Step 4 — Set priority to choose the master (and understand preempt)

By default every VRRP router runs priority 100, and ties are broken by the highest real interface IP. To deterministically make R1 the master, raise its priority above 100. The configurable range is 1–254; 255 is reserved for the address owner and 0 is used internally when a master is stepping down. Here R1 gets 110 and R2 keeps the default 100.

Now the part that catches HSRP veterans: in VRRP, preemption is enabled by default. That means as soon as a higher-priority router is available, it takes over the master role — you do NOT need to turn preempt on, and configuring vrrp 1 preempt changes nothing because it's already the default. This is the opposite of HSRP, where preempt is off until you explicitly configure standby <grp> preempt. The command you actually reach for in VRRP is the negative one: if you do NOT want a recovered router to snatch the master role back (for example, to avoid a second failover when the primary reboots), you must disable preemption with no vrrp 1 preempt.

With this config, R1 (110) is master. If R1 fails, R2 (100) becomes master. When R1 comes back, because preempt is on by default, R1 reclaims master automatically.

R1(config)# interface GigabitEthernet0/0
R1(config-if)# vrrp 1 priority 110
!
! Preempt is already ON by default in VRRP — nothing to enable.
! Only configure this if you want to STOP a returning router
! from reclaiming the master role:
R1(config-if)# no vrrp 1 preempt

Step 5 — (Optional) Track the uplink so failover is meaningful

A higher priority only helps if the master is actually a good path off the LAN. If R1 stays master but its WAN/uplink interface goes down, hosts still send traffic to R1 — into a black hole. Object tracking fixes this by lowering R1's VRRP priority when its uplink fails, letting R2 preempt.

Create a tracked object for the uplink's line protocol, then have VRRP decrement priority when that object goes down. Here R1 starts at 110; losing Gi0/1 subtracts 20, dropping R1 to 90 — below R2's 100 — so R2 (with preempt on) becomes master. When the uplink recovers, the decrement is removed, R1 returns to 110, and it preempts back. Choose the decrement so the result actually falls below the backup's priority; a decrement that leaves R1 above 100 wouldn't trigger failover.

R1(config)# track 1 interface GigabitEthernet0/1 line-protocol
R1(config)# interface GigabitEthernet0/0
R1(config-if)# vrrp 1 track 1 decrement 20

Step 6 — Know the address-owner special case (priority 255)

VRRP has a concept HSRP does not: the address owner. If the virtual IP you assign is the same as the router's own real interface address, that router becomes the owner of the address. The owner is automatically assigned priority 255 — the maximum — and is always the master whenever it is up. You cannot override this with the priority command (which only accepts 1–254), and any priority you set on the other routers is irrelevant while the owner is online.

This is occasionally used on purpose (the owner also gets slightly optimized behavior because it truly holds the address), but far more often it's an accident: someone types the VIP as a router's real IP and then can't understand why the 'lower priority' router keeps winning. If you want free control over which router is master via priority and tracking, choose a VIP that is not assigned to any interface, as in Steps 1–3. The example below shows what NOT to do unless you specifically want R1 to be a permanent, non-negotiable master.

! R1's real interface IP is 10.1.1.2. If you set the VIP to that same
! address, R1 becomes the ADDRESS OWNER, priority is forced to 255,
! and R1 is master whenever it is up — regardless of other routers.
R1(config-if)# vrrp 1 ip 10.1.1.2

Step 7 — Verify with show vrrp brief and show vrrp

Start with show vrrp brief for a one-line-per-group summary. Confirm exactly what you expect: your intended router shows State Master, the others show Backup, the Pre (preempt) column reads Y, and the Group addr column shows your VIP. The Own column reads Y only on an address owner — if you see Y where you didn't intend it, revisit Step 6. Column formatting varies slightly by IOS release, so read by heading, not by fixed position.

The most important sanity check across routers: there should be exactly ONE master for the group. Two masters means the routers aren't hearing each other's advertisements (see Common problems).

Use the detailed show vrrp to confirm the virtual MAC (0000.5e00.01XX), the advertisement interval (1 second by default), that preemption is enabled, the local priority, and the current master's address. You can also scope it to one interface with show vrrp interface GigabitEthernet0/0.

R1# show vrrp brief
Interface          Grp Pri Time    Own Pre State   Master addr     Group addr
Gi0/0               1  110 3570        Y   Master  10.1.1.2        10.1.1.1

R2# show vrrp brief
Interface          Grp Pri Time    Own Pre State   Master addr     Group addr
Gi0/0               1  100 3609        Y   Backup  10.1.1.2        10.1.1.1

! Detailed view (fields shown are representative):
R1# show vrrp
GigabitEthernet0/0 - Group 1
  State is Master
  Virtual IP address is 10.1.1.1
  Virtual MAC address is 0000.5e00.0101
  Advertisement interval is 1.000 sec
  Preemption enabled
  Priority is 110
  Master Router is 10.1.1.2 (local), priority is 110

R1# show vrrp interface GigabitEthernet0/0

VRRP vs HSRP at a glance

Both protocols deliver first-hop redundancy with a shared virtual IP and virtual MAC; the differences decide which one fits. VRRP is an open standard (RFC 5798), uses master/backup roles, defaults preemption ON, sends advertisements every 1 second to 224.0.0.18 over IP protocol 112, uses virtual MAC 0000.5e00.01XX, and has the address-owner (priority 255) concept. HSRP is Cisco-proprietary, uses active/standby roles, defaults preemption OFF (you must configure it), sends hellos every 3 seconds (10-second hold) to 224.0.0.2 (v1) or 224.0.0.102 (v2) over UDP 1985, and has no address owner. Both default to priority 100.

Choose VRRP for multi-vendor environments or when you want faster default timers and preemption without extra config. Choose HSRP in all-Cisco networks matching an existing standard, or when you specifically want preemption off by default. The single most common porting bug is the preempt default flipping between them — if you migrate a design command-for-command, you will get the wrong preemption behavior. For the Cisco-proprietary side, including its virtual MAC ranges, versioning, and the required standby <grp> preempt line, see our HSRP configuration guide.

The contrast below shows the same intent — 'this router should reclaim master when it recovers' — in each protocol. VRRP needs nothing (it's the default); HSRP requires an explicit line.

! VRRP: preempt is already the default — no command required.
R1(config-if)# vrrp 1 priority 110

! HSRP: identical intent, but preempt is OFF by default and
! must be enabled explicitly, or R1 will NOT reclaim active.
R1(config-if)# standby 1 priority 110
R1(config-if)# standby 1 preempt

Common problems (and the fix)

1) 'I can't enable preempt / preempt seems to do nothing.' You're applying HSRP habits. VRRP preemption is already ON by default, so vrrp 1 preempt is a no-op that confirms the default. The command that actually changes behavior is no vrrp 1 preempt, which you use only when you do NOT want a recovered higher-priority router to take the master role back. Verify with the Pre column in show vrrp brief (Y = enabled).

2) Two masters at once (split brain). Every router in show vrrp brief shows State Master. This means the routers aren't receiving each other's advertisements. Check for a mismatched group number or VIP (they must be identical on all routers in the group), a Layer 2 problem on the segment, or an ACL/switch filter dropping VRRP's multicast 224.0.0.18 / IP protocol 112. On older VRRPv2 IOS, a mismatched vrrp 1 authentication text string will also make routers ignore each other and both go master — either match the string on all routers or remove it (note that VRRPv3/RFC 5798 dropped VRRP authentication entirely).

3) 'The wrong router is master and priority won't fix it.' The stubborn winner is almost always the address owner. If the VIP equals that router's real interface IP, it's forced to priority 255 and is always master while up — your priority 110 elsewhere can't beat 255. Fix it by choosing a VIP that is not assigned to any interface (a free host address in the subnet), unless you genuinely intend that router to be a permanent master.

4) Master stays up but traffic is black-holed on uplink failure. VRRP tracks the LAN interface it's configured on, not your WAN/uplink, so losing the uplink doesn't drop priority by itself. Add object tracking (Step 5) with a decrement large enough to fall below the backup's priority, so the backup preempts when the real path off the network fails.

5) No failover happens at all. Confirm the hosts' default gateway is the virtual IP (10.1.1.1), not a router's real address (10.1.1.2 or 10.1.1.3). If clients point at a physical router IP, ARP still resolves to that box's real MAC and there's nothing for VRRP to fail over. Set every host to the VIP, and confirm with show vrrp brief that the Group addr column matches what the hosts use.