Junos VRRP Configuration: VIP, Priority and Accept-Data

VRRP gives a subnet a virtual default gateway that survives the failure of any single router. On Junos OS the configuration lives inside the interface address: you add a vrrp-group statement under the IPv4 address of the interface, define the group ID and virtual IP, and each router's priority decides who is master. This lab-based guide walks through basic Junos VRRP, the accept-data option, and the verification commands that show master and backup state.

How VRRP Works on Junos

VRRP groups two or more routers into a single virtual router that owns a virtual IP address (VIP) and a virtual MAC address. One router is the master and answers ARP for the VIP; the others are backups, listening for the master's advertisement messages. If the advertisements stop, the highest-priority backup takes over the VIP and the virtual MAC, and hosts on the subnet do not need to change anything - their default gateway address never moved.

Junos arranges this differently from most other vendors. There is no global VRRP block where you list groups and interfaces; the vrrp-group statement hangs off the address inside the interface hierarchy:

[edit interfaces ge-0/0/2 unit 0 family inet address 172.16.50.2/24]
vrrp-group 50 {
    virtual-address 172.16.50.1;
    priority 120;
}

That nesting is the single biggest source of confusion for engineers coming from IOS or EOS, where the group is a sibling of the IP address. On Junos, if you cannot find the group in show vrrp, the first thing to check is whether you configured it under the right address statement.

Basic Junos VRRP Configuration

Two vMX routers share gateway 172.16.50.1 for the 172.16.50.0/24 segment. vMX-3 is preferred with priority 120; vMX-4 stays at the default priority 100:

lab@vMX-3> configure
[edit interfaces ge-0/0/2 unit 0 family inet]
set address 172.16.50.2/24 vrrp-group 50 virtual-address 172.16.50.1
set address 172.16.50.2/24 vrrp-group 50 priority 120
commit

lab@vMX-4> configure
[edit interfaces ge-0/0/2 unit 0 family inet]
set address 172.16.50.3/24 vrrp-group 50 virtual-address 172.16.50.1
commit

Both routers must be on the same Layer 2 segment, must use the same group ID, and must be configured with the same virtual address. Nothing else has to match: priorities, timers and tracking are local decisions. A router can be a member of multiple VRRP groups on the same interface, which is how you build per-VLAN or load-shared gateway redundancy on one physical link.

Verifying VRRP State

lab@vMX-3> show vrrp
lab@vMX-4> show vrrp
lab@vMX-4> show vrrp detail

vMX-3 reports State: master; vMX-4 reports backup and additionally lists the master address (172.16.50.2) and its priority. show vrrp detail exposes the VRRP version (2 by default), advertisement interval, preempt state, the virtual MAC (00:00:5e:00:01:32 for group 50) and whether tracking is enabled. The virtual MAC is derived from the group ID — group 50 maps to the last byte 0x32.

Three commands cover almost every verification question you will have:

lab@vMX-3> show vrrp summary
lab@vMX-3> show vrrp extensive
lab@vMX-3> show interfaces ge-0/0/2.0 | match vrrp

When a group will not come up, the state line is the diagnosis. A group stuck in init usually means the interface is down or the address is not yet usable; a group that oscillates between master and backup means the two routers disagree about the advertisement timer or one of them is losing packets on the segment. Compare show vrrp detail on both sides before you change anything.

Accept-Data and Preempt

By default the VRRP master does not answer traffic destined to the VIP itself — hosts can ping through the gateway but not the gateway address. Turning on accept-data makes the master respond to the VIP, useful for management and monitoring:

[edit interfaces ge-0/0/2 unit 0 family inet]
set address 172.16.50.2/24 vrrp-group 50 accept-data
set address 172.16.50.2/24 vrrp-group 50 preempt
commit

preempt (on by default) lets the higher-priority router reclaim the master role when it recovers; disable it if you want the incumbent to keep the VIP after a failover.

The explicit statements are preempt and no-preempt, and both sit at the same hierarchy level as priority. Preemption also takes an optional hold time, which delays the takeover long enough for the recovering router to finish converging its routing table - typically what you want after a Routing Engine reboot, so the VIP does not flap onto a router that is still installing routes:

[edit interfaces ge-0/0/2 unit 0 family inet address 172.16.50.2/24 vrrp-group 50]
preempt {
    hold-time 30;
}

Reach for no-preempt deliberately, not by accident. In an active/backup pair where the backup is intentionally the standby, preemption on the preferred node is the whole point of the design; disabling it means a router that reboots keeps the VIP only until it drops, and after that the roles never swap back on their own.

Priority, Ownership and the Virtual MAC

Priority is the election input and it is worth understanding the whole range, not just that higher wins:

• Priorities 1-254 are normal. The highest priority becomes master; ties are broken by the highest interface IP address.
• Priority 255 is reserved for the address owner - the router whose physical interface address is identical to the virtual address. If you configure the VIP as the interface's own address, you must set priority 255 and configure preempt, because that router must always be master.
• In a non-owner design - the common case, where each router has its own address and the VIP is a third address - every router is a peer and the priority you set is the only thing deciding the outcome.

Address ownership is a design choice worth making on purpose. Owning the VIP means the VIP is reachable even when VRRP is not running, which is convenient for management; it also means you cannot renumber the box without touching the gateway address, and you lose the clean separation between a router's identity and the service address it provides. The peer model is more flexible and is what the example above uses.

The virtual MAC is generated from the group ID in the standard range 00:00:5e:00:01:xx, where the last octet is the group ID in hexadecimal. Group 50 (0x32) therefore produces 00:00:5e:00:01:32. This matters for two operational reasons: hosts and switches cache the virtual MAC in their ARP and forwarding tables, so a well-behaved failover is invisible to them; and if you change the group ID during a change window, expect a brief disruption while the virtual MAC changes underneath everyone's ARP cache.

Timers, Authentication and Convergence

VRRP version 2 is the Junos default for IPv4, with a one-second advertisement interval and a three-second master-down timer derived from it. You can tune both ends of that:

[edit interfaces ge-0/0/2 unit 0 family inet address 172.16.50.2/24 vrrp-group 50]
advertise-interval 3;
fast-interval 200;
advertisements-threshold 10;

• advertise-interval is the rate at which the master sends advertisements, in seconds. Shortening it shortens failover, at the cost of more background traffic - the interval is a whole-number value, so for genuinely fast failover you want the timer below.
• fast-interval is the sub-second variant, in milliseconds, for deployments that need failover measured in hundreds of milliseconds.
• advertisements-threshold caps how many advertisements a router keeps waiting for when the interval is long.

Whatever you choose must be consistent within the group, otherwise the routers will not agree on when the master is down. Junos also notes that VRRP nonstop active routing (NSR) is enabled through the nonstop-routing statement under [edit routing-options] - relevant on dual-RE chassis, where VRRP state should survive a Routing Engine switchover rather than causing a gateway flap.

IPv4 VRRP supports simple and MD5 authentication, which is worth considering if your VRRP advertisements cross a segment you do not fully trust:

[edit interfaces ge-0/0/2 unit 0 family inet address 172.16.50.2/24 vrrp-group 50]
authentication-type md5;
authentication-key "$9$...";

Note the caveat that comes with the feature: authentication is an IPv4-only option, and it is weak protection by modern standards. It stops a stray router with a mismatched group ID from joining the group; it does not make VRRP secure. A better conversation to have is about port security and where your Layer 2 boundaries are.

Priority, Timers and Tracking

Priorities range 1–254; 255 is reserved for the address owner (the router whose physical interface IP equals the VIP). You can shorten failover with fast-interval and trigger failover when a tracked interface or route drops using track interface / route with a priority cost:

[edit interfaces ge-0/0/2 unit 0 family inet]
set address 172.16.50.2/24 vrrp-group 50 priority-cost 60
set address 172.16.50.2/24 vrrp-group 50 track interface ge-0/0/0
commit

Tracking is what turns VRRP from a liveness check on the router into a liveness check on the path. A router whose uplink has failed is still perfectly alive, and without tracking it will happily keep the VIP and black-hole the subnet. The mechanism is a priority penalty: each tracked object has a priority-cost, and when the tracked interface or route goes down, that cost is subtracted from the group priority. Lose enough tracked objects and your router's effective priority drops below the backup's, so the backup takes the VIP.

[edit interfaces ge-0/0/2 unit 0 family inet address 172.16.50.2/24 vrrp-group 50]
track {
    interface ge-0/0/0 {
        priority-cost 60;
    }
    route 0.0.0.0/0 {
        priority-cost 40;
    }
}

Design the arithmetic before you deploy it. With priority 120 and a cost of 60 on the uplink, the effective priority falls to 60 when the uplink fails - below a backup at the default 100, which is exactly the intended failover. If the same router tracks two objects with a combined cost greater than its priority margin, a single failure knocks it out of the election altogether, which may or may not be what you want. Related tracking designs on Junos use BFD for the same purpose; see Junos BFD liveness detection, timers and MC-LAG integration for the timer-driven version of the same idea.

IPv6 VRRP on Junos

The same model applies to IPv6 with a differently named group statement, vrrp-inet6-group, configured under the IPv6 address:

[edit interfaces ge-0/0/2 unit 0 family inet6]
set address 2001:db8:50::2/64 vrrp-inet6-group 50 virtual-address 2001:db8:50::1
set address 2001:db8:50::2/64 vrrp-inet6-group 50 priority 120
set address 2001:db8:50::2/64 vrrp-inet6-group 50 accept-data

IPv6 VRRP uses the same priority, preemption and tracking statements as the IPv4 group; what changes is the hierarchy name and the virtual link-local address handling. If your access layer is dual-stack, configure both groups on the same physical interface and keep the priorities aligned, so a failover moves IPv4 and IPv6 gateway service at the same time rather than splitting the two families across two routers.

Complete Example: Two-Router Gateway Pair

Putting the pieces together, this is a realistic pair for a 172.16.50.0/24 segment where vMX-3 is preferred, the uplink on ge-0/0/0 is tracked, and both routers accept traffic to the VIP for monitoring:

# vMX-3: preferred master with uplink tracking
set interfaces ge-0/0/2 unit 0 family inet address 172.16.50.2/24 vrrp-group 50 virtual-address 172.16.50.1
set interfaces ge-0/0/2 unit 0 family inet address 172.16.50.2/24 vrrp-group 50 priority 120
set interfaces ge-0/0/2 unit 0 family inet address 172.16.50.2/24 vrrp-group 50 preempt hold-time 30
set interfaces ge-0/0/2 unit 0 family inet address 172.16.50.2/24 vrrp-group 50 accept-data
set interfaces ge-0/0/2 unit 0 family inet address 172.16.50.2/24 vrrp-group 50 track interface ge-0/0/0 priority-cost 60
commit

# vMX-4: backup, ready to take over
set interfaces ge-0/0/2 unit 0 family inet address 172.16.50.3/24 vrrp-group 50 virtual-address 172.16.50.1
set interfaces ge-0/0/2 unit 0 family inet address 172.16.50.3/24 vrrp-group 50 preempt
set interfaces ge-0/0/2 unit 0 family inet address 172.16.50.3/24 vrrp-group 50 accept-data
commit

Before you push a change like this onto a live gateway, stage it with commit confirmed and rollback so that a mistake reverts itself instead of stranding the subnet.

Troubleshooting Junos VRRP

Both routers claim master. Almost always a Layer 2 problem rather than a VRRP problem: the advertisements are not getting through, or the interfaces are in different VLANs. Check the segment with show arp on both sides and confirm the virtual MAC appears in only one ARP table.

Neither router becomes master. Either the group IDs differ (a typo in one line is enough), the virtual addresses differ, or the interface is down. show vrrp detail on both routers settles it in one glance.

The VIP does not answer pings but transit traffic works. That is default VRRP behaviour, not a fault. Add accept-data if you want the master to answer for the VIP itself.

Failover happens on reboots but not on uplink failure. Tracking is missing or misconfigured. A router with a dead uplink still wins the priority election unless a tracked object takes its priority down.

Failover is slow. You are on the default one-second advertisement interval. Reduce it, or move to fast-interval for sub-second detection, and make sure the change is applied consistently to every member of the group.

Failover breaks existing sessions. VRRP moves the gateway, not the state. Long-lived TCP sessions tracked on the routers themselves - NAT, firewall sessions, IPsec - need their own redundancy mechanism. If your design depends on session state following the VIP, consider pairing VRRP with a stateful failover feature rather than treating the gateway as the whole problem.

Best Practices

• Set priorities so that the intended master wins and the intended backup can be master: a priority margin larger than the sum of your tracking costs, but not so large that nothing ever changes roles.
• Always configure tracking on the uplink of a gateway that has one. An unreachable VIP is worse than a failed-over VIP.
• Use preempt hold-time on routers that may reboot, so the VIP does not return before the routing table is ready.
• Keep group IDs consistent across the whole campus or data centre; a group ID is effectively a broadcast domain-scoped identifier and collisions create outages that look like magic.
• Document the expected master for every group, and verify it after every maintenance window with show vrrp summary.
• If you are comparing first-hop redundancy across vendors, the mechanics are close but the commands are not: see HSRP configuration with priority, preempt and track for the Cisco model and ArubaOS-CX VRRP active gateway for another VRRP-flavoured implementation.

On a Junos device VRRP competes with other first-hop options. Compare with the Cisco equivalent in HSRP configuration with priority, preempt and track, and see how Junos stages changes safely with commit confirmed and rollback before you touch a live gateway.

原文链接：https://www.networkcuriosity.com/junos-vrrp-example/

Additional reference: Configuring VRRP (Junos OS)