Virtual Router Redundancy Protocol

Introduction

The Virtual Router Redundancy Protocol (VRRP), is a standard protocol that is used to provide automatic assignment of available routers to its participating hosts. The purpose of this is to provide redundancy between a host and its router. Further, VRRP can also be used for load balancing purposes.

The protocol allows multiple physical routers to act as a single router outwards towards its hosts. In the eyes of a host, only one router actually exists. This allows the routers to seamlessly failover to each other and take over routing duties, in case one or more goes down, without the hosts knowing.

All the participating routers together constitute a virtual router, and in normal cases exactly one of these will be selected as the currently active router, the master router. The non-selected routers are known as backup routers. The participating routers themselves are usually called physical routers, to differentiate the concept from the virtual router. An abstraction of this can be seen in Figure 1 below.

                      |
                  .--.-.
                 ( (    )__
                (_,  \ ) ,_)  Internet/Intranet
                  '-'--`--'
                   |
      -------+-----+-----+------- 10.0.0.0/24
             |           |
        .----|-----------|----.
        | .--+--.     .--+--. |
        | | R1  | VR1 | R2  | |
        | '--+--'     '--+--' |
        '----|-----------|----'
             |           |
      --+----+-----+-----+----+-- 192.168.1.0/24
        |          |          |
      .-+--.     .-+--.     .-+--.
      | H1 |     | H2 |     | H3 |
      '----'     '----'     '----'

Figure 1: Depicting how VRRP bundles several physical routers into seemingly one router to all connecting hosts. Here R1 and R2 will form the virtual router VR1. The connecting hosts only know about VR1, and do not need to know about the routers that constitute the virtual router.

The scope of this document is to provide some basic information on VRRP, in addition to all VRRP related configuration options that the system provides.

For example use-cases of VRRP and general setups, refer to the following:

Overview

A virtual router on a LAN is identified by a virtual router id (“vrid”). All participating hosts must use the same VRID to be part of the same virtual router - however, several different VRIDs (and thus several different virtual routers) may be in use on the same LAN simultaneously. Any physical device can also run several VRRP instances concurrently, for example if the device is connected to several LANs, and should participate in virtual routers for several of them.

When taking over routing duties, the master router assumes use of a virtual IP address. Because of this, other devices should use this virtual address as their gateway/router for the hop in question. There is also a set of virtual MAC addresses, one per possible VRID, that is reserved for exclusive use by the master router. The virtual IP address resolves to this MAC. It is highly recommended that the chosen virtual IP address be on the same subnet as the physical addresses the participating routers use on the corresponding interface. It is also not recommended to re-use an address that is already used by a physical device, either one of the participating routers or another device on the network.

Note

Using a VRRP virtual IP address (“VIP”) as the destination for network services is not recommended. Examples of network services include, but are not limited to, NTP-Server and DHCP-Server.

When a VRRP virtual address is used in this way, it can be advantageous to enable “accept mode”, as described below. It should however be noted that the multicast DNS discovery service is not intended to be used for the VIP, regardless of the “accept mode” setting.

In basic layer 3 routing scenarios, a failover (i.e. a change of ownership of the vaddr) will be transparent to applications on devices communicating via the virtual router. Exceptions to this include firewall state, which is not synchronised across hosts participating in the virtual router - in other words, TCP streams and other stateful connections will be broken by a failover.

Signalling between the participating hosts occurs over IP multicast group 224.0.0.18 using IP protocol number 112. The master router will periodically advertise that it is still the master. When 3 advertisement intervals have elapsed without a message being heard, the backup routers perform an election, and another router becomes the new master. Normally all the backup routers are silent, but during elections and startup of participating routers, the backup routers will exchange traffic.

Each participating router is configured with a priority value, higher values indicates a higher priority. This priority dictates which of the routers will be selected as the master router. Further, the routers also have a preempt option, which when enabled will allow a higher-priority backup router force an election. This will result in it taking over as master router, even when another physical router already is master.

In order to handle specific use cases - for instance, when running VRRP over link layer redundancy protocols, or link aggregates - there is an optional startup delay option available, which introduces a configurable delay to the startup of all VRRP instances on the device. Note that using this option together with the preempt option may lead to unexpected behaviour, and should be avoided if possible. Specifically, when using both options, if a device receives VRRP advertisements during its startup delay period, it may not become master after the delay expires, even if it has the highest priority and preempt is enabled.

There are two mutually incompatible versions of VRRP in common use, version 2 and version 3. Version 3 supports additional features such as sub-second precision for the advertisement interval (and thus failover time) and IPv6 support.

For additional details on VRRP and its workings see RFCs 3768 for VRRPv2 and 5798 for VRRPv3.

Using VRRP synchronisation groups, it is possible to synchronise the state of multiple VRRP instances across multiple devices. This can be used to achieves various goals, for instance to ensure that a backup instance on one device only becomes master if the backup instance on another device also becomes master, which can be useful in certain load balancing scenarios. For more information on synchronisation groups, see the VRRP Synchronisation groups document.

The virtual router IP address, commonly called the “VIP”, is sometimes used not only as a gateway address for hosts, but also as a host address for network services. In such cases, it can be useful to enable the “accept” mode of VRRP. This mode is described in RFC 5798.

Configuration

All VRRP configuration is carried out from the router configuration context in the CLI.

example:/#> configure
example:/config/#> router

This context has two additional sub-contexts that are related to VRRP:

instance: Used to configure individual VRRP instances.
group: Used to configure VRRP sync groups.

Additionally, this context also contains the following option, which applies to all instances:

[no] vrrp-startup-delay <TIME>

Optionally delay startup by TIME seconds.

This is useful in order to wait for slow interfaces or other services. The setting applies to all VRRP instances, and valid values for TIME are between 0 (exclusive) and 300 (inclusive). This value is in whole seconds.

no: Remove any delay and starts VRRP instances as soon as possible.

Instances

VRRP instances are configured from the router configuration context in the CLI. When creating a new VRRP instance an ID needs to be provided during the initial creation step:

example:/config/router/#> vrrp 1
example:/config/router/vrrp-1/#>

Syntax

[no] enable

Activate or deactivate VRRP instance.

no: Disable the instance.

[no] address <IP>

Virtual router IP address, must be in same subnet as interface.

Note

Currently there is only support for one virtual IP address per virtual router.

no: Remove the configured IP address.
IP: IP address in standard quad-dotted notation, e.g. 192.168.1.1.

[no] vrid <VRID>

Set router ID. It is used to identify and represent each virtual router.

no: Remove the configured VRID.
VRID: Number in the range of 1-255.

[no] iface <IFNAME>

Set interface to listen on.

no

Remove the configured interface .

IFNAME

Name of an interface. Current available interfaces on the system can be shown in the following manner:

example:/config/router/vrrp-1/#> do show iface
INTERFACE         OPER  ADDRESS/LENGTH      SOURCE      MAC/PTP ADDRESS
lo                UP    127.0.0.1/8         static      00:00:00:00:00:00
vlan1             UP    172.31.1.1/24       static      0c:f4:21:44:a6:00

[no] interval <INTERVAL> [msec]

Advertisement interval, in seconds or in 10 millisecond intervals.

Default: 1 second.

Note

If VRRPv2 is used the value must be a positive integer no larger than 255.
If VRRPv3 is used the value must be between 10 and 40000 milliseconds, inclusive.
An interval lower than 100 milliseconds may impact system performance negatively.

no

Reset to the default value.

INTERVAL

Time in seconds, unless msec is specified.

msec

If specified the INTERVAL value provided will be treated as milliseconds and not seconds.

Sub-second time values can only be utilised if VRRPv3 is used.

[no] priority <1-255>

Router priority, 255 only if IP owner.

Default: 100.

no: Reset to the default value.

[no] version <2 | 3>

Set VRRP version.

Default: 2.

no: Reset to the default value.

[no] preempt [delay <0-1000>]

Preempt existing router of lower priority, with optional delay.

no: Disable router preemption.
delay: Set the optional delay value, between 0-1000

[no] track trigger <ID> adjust <DELTA>

Track event trigger to adjust priority dynamically.

Create a ping trigger and connect to it here to adjust the priority of the VRRP instance depending on the upstream connectivity.

Example:

example:/config/router/vrrp-1/#> track trigger 1 adjust -10

no

Remove the configured tracker.

ID

Id number of the trigger to use. Triggers are created under the alarm context, the following is an example how to create a trigger:

example:/config/#> alarm
example:/config/alarm/#>
example:/config/alarm/#> trigger ping
example:/config/alarm/trigger-1/#> peer 192.168.0.1

For more information on trigger creation see the configuration page for alarms.

DELTA

Integer value to use when dynamically adjusting the VRRP priority. Must be in the range: -255 to 255.

[no] vmac

Create and/or use a virtual interface for VRRP. Uses the VRRP MAC address.

Default: Enabled

no: Disable the vmac.

[no] accept

Enable or disable Accept_Mode, as per RFC 5798. Enabled by default.

This setting is only standardised for VRRP version 3, but is also available for version 2. When enabled, the instance will accept packets destined to the virtual IP address, regardless of VRRP state.

This can be useful in certain scenarios, for instance if the virtual IP address is used as a destination for network services.

Synchronisation Groups

VRRP synchronisation groups are configured from the router configuration context in the CLI. When creating a new sync group a valid ID must be provided during the creation process:

example:/config/router/#> group test
example:/config/router/vrrp-grp-test/#>

Note: A synchronisation group must contain exactly two VRRP instances.

Syntax

[no] member <VRRP_INSTANCE> [ <VRRP_INSTANCE>...]

Set the synchronisation group VRRP member instances.

no: Remove configured member instance(s).
VRRP_INSTANCE: Id of a configured VRRP instance to be used as a group member.

[no] description

Add or edit free-text description.

no: Remove the configured description.

Status

The status for all active VRRP instances on a router can be observed from the admin context:

example:/#> show vrrp

VRRP Instances                                                                          
INSTANCE NAME    BASE INTERFACE   VRID ADDRESS         PRIORITY STATE   GROUP           
ecn1             vlan1            1    10.0.0.100      100(100) BACKUP  group2          
two              vlan1            2    10.0.0.101      100(100) BACKUP  group1          
three            vlan1            3    10.0.0.102      100(100) BACKUP  group1          
four             vlan1            5    10.0.0.200      100(100) BACKUP  group2          
five             vlan1            99   10.0.0.199      100(100) BACKUP  -               

VRRP Groups                                                                             
GROUP NAME       DESCRIPTION      INSTANCE 1       INSTANCE 2       SYNC STATE          
group1                            two              three            BACKUP 
group2           group2           ecn1             four             BACKUP

Note that for the VRRP instances, the “PRIORITY” column shows both the configured priority and the effective priority in parentheses. The effective priority is the one that is actually used in the VRRP protocol, and may differ from the configured priority if there are dynamic adjustments in place, for example due to tracking.

For the VRRP groups, the “SYNC STATE” column shows the current state of the synchronisation group. The state is determined based on the states of the member instances and their synchronisation status and all group members will transition to this state.

If a more detailed view of a specific VRRP instance is desired, the following command can be used. This includes statistics and other details about the instance:

example:/#> show vrrp ecn1
VRRP Instance: ecn1
  Internal name: ecn1_vlan1_1
  Interface: vrrp-ecn1
    Base interface: vlan1
    VMAC interface: vrrp-ecn1
  VRID: 1
  State: BACKUP
    Want state: BACKUP
    Last transition: 1432.39 seconds ago
  Priority: 100 (Effective: 100)
  Master priority: 120
  Version: 2
  Advert interval: 1.00 seconds
  Master advert interval: 1.00 seconds
  VIP set: No
    VIP: 10.0.0.100
  Last master address: 10.0.0.2
  Source address: 10.0.0.1
  Last received packet source address: 10.0.0.2
  Sync: Yes
    Sync group name: group2
    Internal Sync group name: VG_group2
    Sync state: BACKUP
  Preempt: Enabled
    Preempt Delay: 0 seconds
  Accept Mode: Disabled
  Statistics:
    Advertisements received: 1432
    Advertisements sent: 0
    Times became master: 0
    Times released master: 0
    Packet length errors: 0
    Advertisement interval errors: 0
    IP TTL errors: 0
    Invalid type received: 0
    Address list errors: 0
    Invalid auth type: 0
    Auth type mismatches: 0
    Authentication failures: 0
    Priority zero received: 0
    Priority zero sent: 0

Troubleshooting

The most commonly encountered issue with VRRP is that the instance stays in FAULT state. This is often caused by the underlying base interface being down, or the configured virtual IP address not being in the same subnet as the physical address of the base interface. In these cases, the instance will transition to FAULT state and remain there until the underlying issue is resolved.

Another common issue is that VRRP instances are grouped in a way prevents the synchronisation group from settling into a stable state. This can be caused by incompatible priorities on the member instances across different devices, or by using the preemption setting.

If an instance unexpectedly remains in the MASTER state, this can be caused by a loss of connectivity to the other participating routers, for example due to a network issue or a misconfiguration of the base interface. This can be verified by the “Advertisements received” and “Last received packet source address” fields in the detailed instance view, the latter of which should show the address of the master router. If these fields are empty, it indicates that no advertisements have been received from the master router, which can be a sign of a connectivity issue.

A rare but possible configuration is one where the virtual IP address is set to an address that is already used by the base interface. This is not recommended, but if it is done, then Accept Mode should always be enabled, to ensure connectivity. See the [no] accept configuration option for more information on this setting.

When the firewall is in use, it is important to ensure that the necessary rules are in place to allow VRRP traffic to pass between the participating routers. This can either be done by explicitly allowing traffic to the VRRP multicast group (224.0.0.18) and/or by allowing the VRRP protocol (IP protocol number 112).