Dell OS10 VRRP Configuration: v2, v3 and Preempt Guide

Virtual Router Redundancy Protocol is the first-hop redundancy option most Dell PowerSwitch OS10 networks reach for when VLT peer routing alone is not enough. On OS10, VRRP has its own version-specific behaviour: v2 and v3 differ in how the virtual MAC is formed, how advertisements are authenticated and how preempt timing works, and getting those details wrong produces a secondary that never takes over. This guide walks through the working configuration, the version differences that actually matter in production, and the show commands that prove failover works before you need it.

When to use VRRP on OS10 instead of VLT peer routing alone

VLT peer routing lets both VLT peers route traffic for the same subnet, which is usually the fastest path for an MC-LAG-style campus edge. VRRP adds a virtual IP and virtual MAC that hosts can use as a stable default gateway, which matters when:

• you have a mix of VLT and non-VLT uplinks, or the upstream pair is not VLT-capable;
• you need a single gateway IP independent of which chassis is forwarding;
• you want sub-second takeover without host ARP changes.

Both can coexist. VRRP group state is per-VLAN, so you can run VLT peer routing for one subnet and a VRRP group for another on the same chassis pair.

Base configuration

OS10# configure terminal
OS10(config)# interface vlan 100
OS10(conf-if-vl-100)# ip address 10.10.100.2/24

OS10(conf-if-vl-100)# vrrp-group 10
OS10(conf-vrrp-group-10)# virtual-address 10.10.100.1
OS10(conf-vrrp-group-10)# priority 150
OS10(conf-vrrp-group-10)# preempt
OS10(conf-vrrp-group-10)# advertisement-interval 1
OS10(conf-vrrp-group-10)# version 2
OS10(conf-vrrp-group-10)# no shutdown

Repeat on the peer with a lower priority (default 100) and the same group number and virtual address. The higher priority becomes master; the virtual MAC is derived from the group number, so both members must agree on the group ID and version.

Version 2 vs version 3: the differences that break deployments

The virtual MAC change is the classic silent failure: if one peer is configured for v2 and the other for v3, both see the other's advertisements as foreign and both can end up in master state, producing duplicate gateway ARP replies. Always verify the version on both sides.

Preempt behaviour and failover timing

With preempt enabled, a higher-priority member takes the master role back as soon as it is healthy. Without it, a recovered device stays backup until the current master fails. In campus designs, preempt plus a small delay is usually what you want, so that a flapping chassis does not repeatedly steal the gateway and force gratuitous ARP storms.

OS10(conf-vrrp-group-10)# preempt
OS10(conf-vrrp-group-10)# preempt delay minimum 60
OS10(conf-vrrp-group-10)# track 1 interface ethernet 1/1/1 priority-cost 30
OS10(conf-vrrp-group-10)# track 1 interface port-channel 10

Tracking an uplink with priority-cost is the difference between a failover that works and one that only works when a whole switch dies. If the uplink toward the core drops while the chassis stays up, priority drops below the peer's value and VRRP fails over even though the box never rebooted.

Verification and failover testing

OS10# show vrrp brief
OS10# show vrrp
OS10# show vrrp interface vlan 100
OS10# show vrrp statistics
OS10# show running-configuration interface vlan 100

Use show vrrp brief first: it prints the group, state, priority and virtual address per interface. Then test for real — shut the tracked uplink on the master and confirm the secondary moves to master within a few advertisement intervals, and that the hosts' ARP cache points at the virtual MAC.

Common OS10 VRRP problems

• Both members master: version mismatch, mismatched group ID, or the virtual address missing on one side.
• No takeover on uplink loss: no track object, or the priority-cost is too small to cross the peer's priority.
• Slow reconvergence after reboot: preempt delay too long; measure the actual time before tuning.
• IPv6 group never comes up: version 2 selected on an IPv6 group.

VRRP alongside VLT: avoiding a double-active gateway

On Dell PowerSwitch OS10, VLT and VRRP are frequently deployed on the same pair, and the interaction is where designs break. VLT peer routing lets both chassis forward traffic for the same subnet, while a VRRP group nominates a single master to own the virtual IP and MAC. Run both without thinking and you can end up with a device's default gateway being answered by both chassis.

Two workable patterns:

1. VRRP for the gateway, VLT for the fabric. Run a VRRP group on the VLAN with the master pinned to the chassis that owns the primary uplink. Hosts point at the virtual IP. This is the most predictable option when the upstream pair is not VLT-capable.
2. VLT peer routing with anycast-style addressing. Both peers hold the same gateway IP on the SVI and hosts use a single address. No VRRP state machine is involved, but every upstream path must be symmetric enough to tolerate either chassis forwarding.

Mixing them by accident is easy: if a VRRP group exists on a VLAN that is also part of a VLT with peer routing enabled, examine which MAC the hosts actually learn. Verify with the ARP/neighbour table on a host:

# On a Linux host behind the pair
ip neigh show 10.10.100.1
ip route get 10.10.100.1

# On the switch
OS10# show vrrp interface vlan 100
OS10# show vlt brief

If the neighbour MAC is the VRRP virtual MAC (00:00:5e:00:01:0a for group 10 on v2), the group is doing the work. If it is one of the chassis MACs, peer routing is answering. Pick one behaviour deliberately and document it, because troubleshooting a gateway problem later depends entirely on knowing which mechanism owns it.

VRRP troubleshooting table

Capacity and licensing notes

• VRRP groups are per-VLAN; a campus with 40 VLANs and two gateway pairs can reach hundreds of group instances. Check the platform scale guide before designing one group per VLAN everywhere.
• Advertisement interval affects takeover speed: at the default 1 second, detection of a dead master takes roughly three intervals. Lower values increase protocol chatter across every access switch.
• IPv6 first-hop requirements differ; if you have IPv6 hosts, run the v3 group for the IPv6 address and confirm the router advertisement behaviour separately.
• Document virtual IP, group ID, version and priority per VLAN in the network design, not only in the switch configuration — the design is what survives a re-cabling exercise.

Related reading

If you also run VLT for the same VLAN, read Dell OS10 VLT peer routing configuration to avoid double-active gatewaying, and Dell OS10 basic switch management CLI for the management-plane steps before you touch first-hop redundancy. Cross-vendor comparison of first-hop gateways is in ArubaOS-CX VRRP active gateway and first-hop redundancy.

原文链接：https://www.dell.com/support/kbdoc/en-us/000223071/configuring-vrrp-on-dell-networking-smartfabric-os10