VRRP

Virtual Router Redundancy Protocol (VRRP) is an election protocol that dynamically assigns responsibility for a virtual router to one of the VRRP routers on a LAN. The elected router is called the Master and takes responsibility of a virtual IP address and MAC address, while other nodes are called Backup. These addresses may be used by other devices to access some service, e.g. a static default gateway or a security gateway endpoint. The election process provides dynamic failover, should the Master become unavailable. VRRP enables service high availability without requiring slow reconfiguration of end hosts (through dynamic routing or standard IPv6 ND mechanisms). The Master node processes the traffic while the Backup nodes remain passive.

The VRRP protocol is defined in RFC 3768 (VRRPv2) and RFC 5798 (VRRPv3). The major differences between VRRPv2 and VRRPv3 are the support of IPv6 and the support of low failover timer values which are only available in the latter.

Overview

There are two contexts involved in VRRP configuration:

  • the vrrp global context, from which options common to all VRRP interfaces are set, and from which VRRP failover groups are defined.

  • the interface type 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:

../../../_images/aafig-8328353f10823f476c5a8eb161e2613b41892c66.svg

The configuration of rtr1 is done with the following commands:

vsr running vrf main#
vsr running vrf main# vrrp
vsr running vrrp# enabled true
vsr running vrrp# router-id vrrp_router1
vsr running vrrp# vrrp-startup-delay 30
vsr running vrrp# ..
vsr running vrf main# interface vrrp vrrp51
vsr running vrrp vrrp51#! link-interface eth1
vsr running vrrp vrrp51#! vrid 5
vsr running vrrp vrrp51# priority 200
vsr running vrrp vrrp51# virtual-address 10.22.0.1/24
vsr running vrrp vrrp51# commit

Note

The link interface eth1 must be up and have an IP address configured.

Let’s fetch the state after committing this configuration:

vsr running vrf main# vrrp
vsr running vrrp# show state
vrrp
    enabled true
    router-id vrrp_router1
    traps-enabled false
    ..
vsr running vrf main# interface vrrp vrrp51
vsr 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 5
    oper-status UP
    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:05
        ..
    virtual-address 10.22.0.1/24
    ..

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>5</vrid>
        <virtual-address>
          <ip>10.22.0.1/24</ip>
        </virtual-address>
      </vrrp>
    </interface>
  </vrf>
</config>

This configuration is obtained by merging the output of the following commands:

vsr running config# show config xml absolute vrf main vrrp
vsr 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 set to vrrp_router2.

See also

The command reference for details.

VRRP states

Here are the existing VRRP states and their meanings:

  • fault - this state is caused by a fault on a tracked element (link interface, route…). When the state switches to fault, the router sends a VRRP announcement with a priority of 0.

  • backup - the router is starting or it is ready to take the virtual address in case of failure of the master.

  • master - the only state where the router owns the virtual addresses.

VRRP interface settings

Version

version defines whether version 2 or 3 is used. Using version 3 allows faster failovers thanks to low timer values and is recommended. See information about timers.

vsr running vrf main# interface vrrp vrrp51
vsr running vrrp vrrp51# version 3

Caution

Setting IPv6 VRRP does not imply version 3. Virtual Service Router allows using IPv6 on VRRPv2 although its support is deprecated.

Priority

The router with the highest priority will be elected master. The other one will remain backup.

vsr running vrf main# interface vrrp vrrp51
vsr running vrrp vrrp51# priority 150

If no priority is set, the default value of 100 is used. To ensure a predictable Master, we recommend setting a different priority for each router.

If priorities of routers are equal:

  • in VRRPv2, the router with the highest IP is elected as master.

  • in VRRPv3, the first router appearing on the network is elected as master.

Note

The priority value of 255 is a special value that can only be set when the virtual-address IP and the link-interface IP address are identical. It means that the router on which the priority 255 is set switches to the master state when the router comes up.

The value of 255 is only supported with the vMAC VRRP mode and when no HA services are configured.

Init state

init-state is a deprecated option that defines in which state the VRRP instance is initialized before the election occurs, at startup and after a link goes to up state.

We recommend letting it at the default value of backup. If you want the router election to converge quickly, use lower timers values.

vsr running vrf main# interface vrrp vrrp51
vsr running vrrp vrrp51# init-state backup

Virtual router identifier

The virtual router identifier vrid identifies a set of VRRP routers on a LAN. Several groups of VRRP routers can coexist on the same broadcast domain as long as they all have a different vrid. For a given VRRP instance, the vrid value must be identical on both routers. We recommend setting the same vrid on all instances within a HA group of routers.

vsr running vrf main# interface vrrp vrrp51
vsr running vrrp vrrp51# vrid 30

Caution

A vMAC is built from the vrid value. Setting the same vrid value on several groups of routers within the same broadcast domain would mean that the same vMAC is re-used at different places. See Virtual MAC address.

Preemption

“To preempt” in the context of VRRP means to take over as master when the other router is master. The condition for a router to preempt is basically to receive three times a lower priority announcement than its own.

The preemption feature is enabled by default and should remain enabled. For some special cases, it can be configured using the preempt option:

vsr running vrf main# interface vrrp vrrp51
vsr running vrrp vrrp51# preempt (true|false)

See also

The timers section gives information about the preemption convergence time.

Gratuitous ARP delay

A gratuitous ARP is an unsolicited notification used to update other hosts’ mapping of an IP address to a MAC address.

It involves broadcasting an ARP request whose Sender Protocol Address (SPA) and Target Protocol Address (TPA) are both set to the sender’s IP address, and the Source Hardware Address (SHA) is set to the MAC address. This ARP packet is a request type but serves only an informational purpose, as it does not expect a reply.

After transitioning to master state, the router immediately sends multiple gratuitous ARP requests for each virtual address it owns. It then waits for the garp-delay before sending a second set of gratuitous ARP packets.

This mechanism updates the switch’s MAC forwarding tables and informs other hosts about the virtual IP to MAC address mapping:

  • if the use-vmac option is enabled, it updates the switch’s forwarding table with the port where the host owning the vMAC address is connected, while the MAC/IP address mapping for hosts remains unchanged.

  • if the use-vmac option is disabled, it updates both the switch’s forwarding table with the new MAC address location and informs other hosts about the updated MAC/IP mapping.

Note

Since it is a delay, reducing garp-delay will not speed up the failover. Its default value of 5 seconds should not be changed.

vsr running vrf main# interface vrrp vrrp51
vsr running vrrp vrrp51# garp-delay 5

Trackers

A tracker is used to set a VRRP instance into fault state when a tracking condition fails.

Caution

The up state and the presence of an IP address on the link interface are tracked by the VRRP instance by default. When configuring a new VRRP instance in a failover group, make sure the link interface matches these conditions. Otherwise, the HA group would go to fault state.

IP address tracker

A VRRP instance can monitor the reachability of IP addresses. If a tracked address becomes unreachable, the instance transitions to the fault state.

To enable IP tracking via periodic ICMP requests:

vsr running config# / tracker
vsr running tracker# icmp my-tracker vrf main address 10.100.0.1
vsr running tracker# / vrf main
vsr running vrf main# interface vrrp vrrp51
vsr running vrrp vrrp51# track my-tracker

See also

The Tracker guide.

Fast path status tracker

A VRRP instance can track the fast path status. If the fast path status does not match the configuration, the instance goes to fault state. 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:

vsr running vrf main# interface vrrp vrrp51
vsr running vrrp vrrp51# track-fast-path true

ARP settings

Having arp-ignore set to its default value of any results in the VRRP instance and the link interface both responding to ARP requests addressed to either, meaning that each ARP request receives two conflicting responses. To avoid this, we recommend explicitly setting arp-ignore to check-interface on both the VRRP instance and the link interface.

To configure arp-ignore:

vsr running vrf main# interface vrrp vrrp51
vsr running vrrp vrrp51# network-stack ipv4
vsr running ipv4# arp-ignore check-interface
vsr running ipv4# / vrf main
vsr running vrf main# interface physical eth1
vsr running physical eth1# network-stack ipv4
vsr running ipv4# arp-ignore check-interface

To prevent the link interface from responding to ARP requests addressed to itself, set arp-filter to false.

To configure arp-filter:

vsr running vrf main# interface physical eth1
vsr running physical eth1# network-stack ipv4
vsr running ipv4# arp-filter false

Synchronization of instance states

This section explains how to configure VRRP on Virtual Service Router to synchronize the instance states within a VRF and to work with the HA features such as HA conntrack and HA IKE .

Failover groups configuration

A VRRP group is used to group VRRP interfaces from a given VRF that should share the same VRRP state.

The VRRP instances of a group run VRRP independently but share their state with the group. This way, all group instances are in a consistent state and follow the following rules:

  • If an instance goes to fault state, all the instances of its group will go to fault state as well.

  • If any backup instance stops receiving announcements from the master router, the group will not go to the master state unless all instances stop receiving announcements as well.

Caution

All the instances of a group must have the same priority. If they don’t, it will lead to constant re-elections.

The following example shows how to group two VRRP instances:

vsr running vrf main#
vsr running vrf main# vrrp
vsr running vrrp# group my-group
vsr running group my-group# instance vrrp51
vsr running group my-group# instance vrrp52
vsr running group my-group# commit

Track a group in a different vrf

A VRRP group can track a group in another VRF, and apply a penalty to its own priority when the tracked group goes to fault state.

This feature is used to ensure that, when two VRRP groups are configured in two different vrfs, both groups will share the same fate.

If we define as Primary the device with the highest VRRP priority (in other words, the preferred master node) and as Secondary the preferred backup node, the priority penalty should be chosen so that (Primary priority - penalty) < Secondary priority. The penalty value ranges from 1 to 253 and defaults to 253. We recommend keeping the default value.

Caution

A configuration where one side has a priority of 254 and the other has a priority of 1 is not compatible with this feature.

Here is an example of configuration:

../../../_images/aafig-1bffe8ed6d530d63f9316c4142739e941ecebcb6.svg 
rtr1 running config# vrf main
rtr1 running vrf main# vrrp
rtr1 running vrrp# group my-group
rtr1 running group my-group# instance vrrp51
rtr1 running group my-group# track-group group my-group vrf wan
rtr1 running group my-group# ..
rtr1 running vrrp# ..
rtr1 running vrf main# ..
rtr1 running config# vrf wan
rtr1 running vrf wan# vrrp
rtr1 running vrrp# group my-group
rtr1 running group my-group# instance vrrp52
rtr1 running group my-group# track-group group my-group vrf main

rtr2 running config#
rtr2 running config# vrf main
rtr2 running vrf main# vrrp
rtr2 running vrrp# group my-group
rtr2 running group my-group# instance vrrp51
rtr2 running group my-group# track-group group my-group vrf wan
rtr2 running group my-group# ..
rtr2 running vrrp# ..
rtr2 running vrf main# ..
rtr2 running config# vrf wan
rtr2 running vrf wan# vrrp
rtr2 running vrrp# group my-group
rtr2 running group my-group# instance vrrp52
rtr2 running group my-group# track-group group my-group vrf main
rtr2 running config#

When the vrrp51 instance goes to fault on rtr1, the main vrf VRRP group my-group will go fault as well. The VRRP instance in the main vrf on rtr2 will take over.

Thanks to the specified track-group group my-group vrf main command, the wan vrf VRRP group my-group will have its priority of 200 reduced by 253, to the minimum value of 1. This value is lower than the priority of the corresponding group on rtr2 (100). The VRRP instance in the wan vrf on rtr2 will take over.

Warning

This mechanism relies on the preemption feature which is enabled by default. In the case described above, disabling preemption would prevent the VRRP instance in the wan VRF on rtr2 from taking over.

Note

The vrf option accepts a all keyword. When vrf all is set, all the groups with the specified name in all the vrfs (except the current one) will be tracked. The priority will be reduced by (number of faulty instance) * (priority-penalty value). The minimum reduced priority is 1.

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.

See also

High-availability Groups for details.

vsr running config# ha group my-ha-group
vsr running group my-ha-group# / vrf main interface vrrp vrrp51
vsr running vrrp vrrp51#! link-interface eth1 vrid 5
vsr running vrrp vrrp51# notify-ha-group my-ha-group
vsr running vrrp vrrp51# commit

Other services support high-availability can declare themselves as subscribers for this group.

Note

If a HA group notification is configured, the following rules apply:

  • all the VRRP instances of a VRF must be in a unique VRRP group. Otherwise, the configuration would not be accepted at commit time.

  • only the master router can forward traffic. It synchronizes protocol information such as neighbor and IPsec packet sequence numbers to the backup. The backup router cannot synchronize information to the master. If it receives some data plane traffic by mistake, the traffic will be dropped.

Protection against undesired traffic on the backup node

When VRRP controls the state of an HA group (as described in High-availability group notification), it may set the HA group state to backup. The HA services then no longer expect to process traffic.

Undesired traffic may however temporarily be received, forwarded or sent by the device, which may cause adverse effect. For example, if the backup node encrypts traffic and sends IPsec packets to a remote host, the replay window of the remote host will slide forward and the remote peer will drop IPsec traffic sent by the master node due to the anti-replay mechanism, causing a potentially long-lasting traffic loss.

To protect the device from such issues, the VRRP service automatically installs filtering rules in the VRF of the VRRP instance or VRRP group that notifies a switch to the HA backup state. These rules drop undesired traffic potentially received, forwarded or sent by the device.

This feature is enabled by default, but may be disabled per VRF in the VRRP context, via the following command:

vsr running config# / vrf main vrrp
vsr running vrrp# drop-traffic-on-backup false
vsr running vrrp# commit

High-availability split-brain situation

A HA split-brain situation is a situation where both VRRP routers are in master state because a network outage stops them from exchanging VRRP announcements between them.

Note

If you are not using HA conntrack or HA IKE , HA split-brain situation will not affect Virtual Service Router packet processing. You can skip reading until the Startup delay section. Configuring vrrp-startup-delay has some other benefits.

Possible causes

The cause of a broken communication between instances that causes a double master HA topology are the following:

  • An interface may only receive traffic several seconds after the link comes up. The common causes are:

    • a switch with STP configured in non-edge (or portfast) mode,

    • a LACP bonding coming up before its slaves interface are in LACP collecting state.

    Since all instance interfaces are likely to face this issue at the same time at system startup, we recommend using a vrrp-startup-delay of 30 seconds. To avoid an issue where all the instance interfaces would flap at the same time, it is advised as well to avoid the VRRP instance to rely on a unique logical interface or on several interfaces linked to the same switch. Consider adding a HA link if all the instances relies on one switch.

  • There is a defect on the network on a single point of failure between all the instances. See topology solutions.

Consequences

The consequences of a HA split-brain depend on the services the Virtual Service Router is running:

  • If the nodes are using HA conntrack or HA IKE , the sequence numbers of packets are synchronized from the master to the backup or fault router. The data plane traffic is only accepted and forwarded on the master router. If the routers are all in master state, they will both forward a part of the traffic and increment their sequence numbers independently. They will not synchronize their sequence numbers one with another because a master router cannot accept synchronized information by design. As soon as the unlegitimate master router returns to the backup state, the master router will receive its traffic. However the master’s sequence number table is outdated, so this traffic will be dropped.

  • Without HA conntrack and HA IKE , having several master routers in the HA topology does not affect their packet processing because the routers forward packets without checking any sequence number. The split-brain situation is the result of a fault on the network that might lead to a traffic outage but that is not caused by the routers.

Solutions

Change the topology

We recommend using different physical links and switches for the instances of a group to avoid this the split-brain situation.

Here is a network topology with two routers running Virtual Service Router. Each router has a HA group containing instances on link interfaces bond0.2 and bond0.3 that are respectively vlan 2 and 3 sub-interfaces of bond0.

../../../_images/aafig-7ab14904c4ec3fc5785346ed48dfa3596aa48f4a.svg

The link between switch1 and switch2 is now broken. The communication is totally broken between routers. As a result, both routers are master.

../../../_images/aafig-8e5c1cc61105c1beda7519dc0b7a4ff42db8e3b0.svg

A solution to avoid the problem is to dispatch the VRRP instances on several switching domains to ensure that VRRP announcements for different VRRP instances take a different path. It requires adding some switches.

../../../_images/aafig-df618cf930bafdbb45ce503f40e8893f22557ebf.svg

If adding some switches is not possible, consider adding a HA link.

Configure a startup delay

vrrp-startup-delay is a delay that is applied at system startup before starting to listen for VRRP advertisement. This way, no VRRP election happens before the router is ready.

We recommend setting a 30s vrrp-startup-delay value.

vsr running vrf main#
vsr running vrf main# vrrp
vsr running vrrp# vrrp-startup-delay 30

Note

vrrp-startup-delay only applies at system startup but not after a link state is flapping.

Note

Before the vrrp-startup-delay timer expires, the initial state set by the init-state leaf in the VRRP interface configuration applies. Make sure to let it at the default backup value.

VRRP settings for virtual environments

Using Virtual Service Router on VMs with VRRP may require to adjust the following settings:

Note

We recommend keeping default value of these settings if Virtual Service Router is running on bare-metal servers.

Virtual MAC address

By default, a vMAC is associated to the virtual IP address in the host ARP and NDP neighbor table. It is also used as a source MAC address for VRRP announcements.

Some virtual network switches (eg. VMware vSwitch) are unable to deal with vMAC because they only know MAC addresses that the hypervisor has assigned to the VMs. In this case, use-vmac must be set to false so that the MAC address of the link interface is used instead.

vsr running vrf main# interface vrrp vrrp51
vsr running vrrp vrrp51# use-vmac false

Caution

When disabling use-vmac, make sure the ARP or NDP protocols are correctly propagated. Otherwise, some hosts might not be informed of the new master MAC address after a failover. We recommend testing some manual failovers.

  • The storm control feature, if it is enabled on switches, may affect the flooding of ARP broadcasts.

  • The reception of gratuitous ARP may be disabled on hosts for security reasons.

Note

Since IPv4 and IPv6 vMAC formats are different, it is not possible to define IPv4 and IPv6 virtual adresses on the same VRRP instance.

Note

vmac-xmit-based setting is only effective if use-vmac is true. Its default value is false. If true, the MAC address of the link interface is used for sending VRRP announcements. It should be left configured to its default value.

Unicast peering

By default, the VRRP announcements are sent on multicast.

Some virtual network switches (eg. VMware vSwitch) are unable to deal with multicast MAC addresses. In this case, a unicast-peer must be configured to send VRRP using unicast packets instead of multicast packets. The destination IP address (192.168.222.2 in the following example) is the actual address of the same instance on the other router.

vsr running vrf main# interface vrrp vrrp51
vsr running vrrp vrrp51# unicast-peer 192.168.222.2

Note

When using values for advertisement-interval lower than 1s and unicast peering, we recommend using static ARP / NDP entries to avoid latency induced by ARP / NDP requests.

VRRP settings for Layer 3 high availability

Principle

The VRRP protocol was designed for Layer 2 HA, i.e. for assigning the responsibility for a virtual router address between neighbor devices located on the same LAN segment.

The Virtual Service Router extends the VRRP standard to allow advertisement propagation between neighbors outside the same Layer 2 domain. This is accomplished by routing VRRP packets between Layer 2 segments, enabling Layer 3 high availability.

In a Layer 3 use case, the behavior differs from Layer 2 in the following ways:

  • unicast peering is used instead of broadcasting (unicast-peer command),

  • vMACs are not used (use-vmac false),

  • the virtual IP address is advertised through a routing protocol instead of via gratuitous ARP.

../../../_images/aafig-943caa67432ae2741773f21863e6e52147925ea3.svg 
rt1 running config# / vrf main interface
rt1 running interface# vrrp vrrp51
rt1 running vrrp vrrp51#! link-interface eth1
rt1 running vrrp vrrp51#! vrid 5
rt2 running vrrp vrrp51# priority 200
rt1 running vrrp vrrp51# use-vmac false
rt1 running vrrp vrrp51# unicast-peer 192.168.222.2
rt1 running vrrp vrrp51# virtual-address 10.22.0.1/24
rt1 running vrrp vrrp51# / vrf main vrrp
rt1 running vrrp# enabled true
rt1 running vrrp# commit

rt2 running config# / vrf main interface
rt2 running interface# vrrp vrrp51
rt2 running vrrp vrrp51#! link-interface eth1
rt2 running vrrp vrrp51#! vrid 5
rt2 running vrrp vrrp51# priority 100
rt2 running vrrp vrrp51# use-vmac false
rt2 running vrrp vrrp51# unicast-peer 192.168.111.1
rt2 running vrrp vrrp51# virtual-address 10.22.0.1/24
rt2 running vrrp vrrp51# / vrf main vrrp
rt2 running vrrp# enabled true
rt2 running vrrp# commit

A routing protocol (typically BGP) should be enabled on each device and configured to advertise the virtual IP address (when the device is master) and the device unicast addresses.

In addition to the link-interface, other states should be tracked, in particular the reachability of the router that provides connectivity to the routed network. To add a tracker that checks the router reachability via BFD, create a BFD tracker, then reference it from the vrrp instance:

rt1 running config# / tracker
rt1 running tracker# bfd PE-ROUTER
rt1 running bfd PE-ROUTER#! type single-hop
rt1 running bfd PE-ROUTER#! source 192.168.111.1
rt1 running bfd PE-ROUTER#! address 192.168.111.254
rt1 running bfd PE-ROUTER#! vrf main
rt1 running bfd PE-ROUTER# / vrf main interface
rt1 running interface# vrrp vrrp51
rt1 running vrrp vrrp51# track PE-ROUTER
rt1 running vrrp vrrp51# commit

rt2 running config# / tracker
rt2 running tracker# bfd PE-ROUTER
rt2 running bfd PE-ROUTER#! type single-hop
rt2 running bfd PE-ROUTER#! source 192.168.222.2
rt2 running bfd PE-ROUTER#! address 192.168.222.254
rt2 running bfd PE-ROUTER#! vrf main
rt2 running bfd PE-ROUTER# / vrf main interface
rt2 running interface# vrrp vrrp51
rt2 running vrrp vrrp51# track PE-ROUTER
rt2 running vrrp vrrp51# commit

Handling route convergence delays

When a VRRP instance is newly created or leaves the fault state, the device may have been previously isolated from the routed network. Restoring connectivity between the HA cluster members (e.g., rt1 and rt2) requires time due to routing protocol convergence.

During this convergence delay, rt1 and rt2 are unable to exchange VRRP advertisements. As a result, each device assumes it is the only active node in the cluster and transitions to the Master state, which leads to a split-brain scenario.

To prevent this situation, we recommend configuring a delay before the election process begins when a VRRP instance exits the init or fault state. This delay (in seconds) should exceed the time required for routes convergence across the network.

rt1 running config# / vrf main interface
rt1 running interface# vrrp vrrp51
rt1 running vrrp vrrp51# fault-init-linger-delay 30
rt2 running vrrp vrrp51# commit