Virtual Router Redundancy Protocol provides a way, for a set of routers, to control a virtual address and MAC address, including automatic fail-over mechanism. Such an address may be used by hosts for some service access, e.g. as static default gateway. The gain from using VRRP is a higher availability of the service without requiring automatic reconfiguration of end hosts.
The VRRP protocol is defined in RFC 3768 (VRRP v2) and RFC 5798 (VRRP v3). The major difference between VRRP v2 and VRRP v3 is the support of IPv6 which is only available in the latter. 6WIND VRRP implementation is based on the Keepalived open source project.
There are two contexts involved in VRRP configuration:
vrrpglobal context, from which options common to all VRRP interfaces are set, and from which VRRP fail-over groups are defined.
vrrp, from which a particular VRRP instance is configured.
Here is a simple example of VRRP, similar to Sample Configuration 1 described in section 4.1 of RFC 3768:
The configuration of rtr1 is done with the following commands:
vrouter running vrf main# vrouter running vrf main# vrrp vrouter running vrrp# enabled true vrouter running vrrp# router-id vrrp_router1 vrouter running vrrp# .. vrouter running vrf main# interface vrrp vrrp51 vrouter running vrrp vrrp51#! link-interface eth1 vrouter running vrrp vrrp51#! vrid 51 vrouter running vrrp vrrp51# priority 200 vrouter running vrrp vrrp51# virtual-address 10.22.0.1/24 vrouter running vrrp vrrp51# virtual-route 10.22.0.0/24 interface eth1 vrouter running vrrp vrrp51# commit
The bound interface eth1 must be up and have an IP address configured.
Let’s fetch the state afer committing this configuration:
vrouter running vrf main# vrrp vrouter running vrrp# show state vrrp enabled true router-id vrrp_router1 traps-enabled false .. vrouter running vrf main# interface vrrp vrrp51 vrouter running vrrp vrrp51# show state vrrp vrrp51 vmac-xmit-base false preempt-delay 0 init-state backup state master garp-delay 5 link-interface eth1 enabled true use-vmac true advertisement-interval 1000 mtu 1500 vrid 51 oper-status UNKNOWN priority 200 preempt true version 2 counters in-errors 0 out-discards 0 out-octets 0 in-octets 0 out-unicast-pkts 9 out-errors 0 in-unicast-pkts 0 in-discards 0 .. ethernet mac-address 00:00:5e:00:01:33 .. virtual-address 10.22.0.1/24 virtual-route 10.22.0.0/24 interface eth1 ..
The same configuration can be made using this NETCONF XML configuration:
<config xmlns="urn:6wind:vrouter"> <vrf> <name>main</name> <vrrp xmlns="urn:6wind:vrouter/vrrp"> <enabled>true</enabled> <router-id>vrrp_router1</router-id> <traps-enabled>false</traps-enabled> </vrrp> <interface xmlns="urn:6wind:vrouter/interface"> <vrrp xmlns="urn:6wind:vrouter/vrrp"> <name>vrrp51</name> <enabled>true</enabled> <init-state>backup</init-state> <version>2</version> <garp-delay>5</garp-delay> <use-vmac>true</use-vmac> <vmac-xmit-base>false</vmac-xmit-base> <priority>200</priority> <preempt>true</preempt> <preempt-delay>0</preempt-delay> <advertisement-interval>1000</advertisement-interval> <authentication/> <link-interface>eth1</link-interface> <vrid>51</vrid> <virtual-address> <ip>10.22.0.1/24</ip> </virtual-address> <virtual-route> <ip>10.22.0.0/24</ip> <interface>eth1</interface> </virtual-route> </vrrp> </interface> </vrf> </config>
This configuration is obtained by merging the output of the following commands:
vrouter running config# show config xml absolute vrf main vrrp vrouter running config# show config xml absolute vrf main interface vrrp vrrp51
The configuration on the second router (backup) is similar, except the
priority which should be lower than 200, and the
router-id which is
The command reference for details.
Advertisement interval and preempt delay¶
advertisement-interval specifies the rate at which VRRP advertisements are
sent when the router is master.
When the router is backup, it is listening for advertisements. If no
advertisement is received, it switches to master after Master_Down_Interval.
preempt is enabled and advertisements with lower priority are received,
if switches to master after
Master_Down_Interval: Time interval for Backup to declare Master down. Calculated as
(3 * advertisement-interval) + Skew_time.
Skew_Time: Time to skew Master_Down_Interval in centiseconds. Calculated as
(((256 - priority) * Master_Adver_Interval) / 256)
When using slow value for
advertisement-interval, it is important
than the link interface is able to receive packets as soon as the
carrier is on, else the
preempt-delay could be ignored:
the switch port where the link interface is connected should have its spanning tree disabled.
if using unicast peering, it is advised to use static ARP entries to avoid latency induced by ARP requests.
Tracking IP addresses¶
A VRRP instance can track IP addresses. When a tracked address is unreachable, the instance cannot become master.
To enable IP tracking:
vrouter running config# / tracker vrouter running tracker# icmp my-tracker vrf main address 10.100.0.1 vrouter running tracker# / vrf main vrouter running vrf main# interface vrrp vrrp51 vrouter running vrrp vrrp51# track my-tracker
The Tracker guide.
Tracking fast path status¶
A VRRP instance can track the fast path status. If the fast path status does not match the configuration, the instance cannot become master. This occurs for instance when the fast path is starting or stopping, or if the fast path configuration cannot be applied.
To enable fast path tracking:
vrouter running vrf main# interface vrrp vrrp51 vrouter running vrrp vrrp51# track-fast-path true
Failover groups configuration¶
VRRP group is used to group VRRP interfaces from a given VRF that should failover together.
The following example shows how to group two VRRP instances:
vrouter running vrf main# vrouter running vrf main# vrrp vrouter running vrrp# group my-group vrouter running group my-group# instance vrrp51 vrouter running group my-group# instance vrrp52 vrouter running group my-group# commit
High-availability group notification¶
A VRRP group or VRRP instance can control the state of a high-availability group: when the VRRP state changes, all the subscribers of the high-availability group are notified and can act accordingly.
The following example configures a VRRP instance as a controller for the high-availability group my-ha-group.
High-availability Groups for details.
vrouter running config# ha group my-ha-group vrouter running group my-ha-group#! / vrf main interface vrrp vrrp51 vrouter running vrrp vrrp51#! link-interface eth1 vrid 51 runnint vrrp vrrp51#! notify-ha-group my-ha-group runnint vrrp vrrp51# commit
Other services support high-availability can declare themselves as subscribers for this group.