VRRP

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.

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 fail-over 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:

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

Note

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 set to vrrp_router2.

See also

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. If preempt is enabled and advertisements with lower priority are received, if switches to master after preempt-delay.

• 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)

Note

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

See also

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.

See also

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.