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 |
'----' '----' '----'
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 as the destination for network services is not recommended. Examples of network services include, but are not limited to, NTP-Server and DHCP-Server.
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 synchronized 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.
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.
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 utilized 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.
Synchronization Groups
VRRP synchronization 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 synchronization group must contain exactly two VRRP instances.
Syntax
[no] member <VRRP_INSTANCE> [ <VRRP_INSTANCE>...]
-
Set the synchronization 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. All currently configured VRRP instances can be observed like this:
example:/config/router/#> show vrrp VRRP Instances ID Interface Router-ID Priority Address 1 vlan1 100 100 10.0.0.50 2 vlan2 80 100 10.0.0.100
[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 INSTANCE INTERFACE VRID PRIORITY STATE GROUPED GROUP
i2 vlan1 2 50 BACKUP N --------
i1 vlan1 1 100 MASTER N --------
In addition, the status of individual VRRP instances can be observed in the following manner:
example:/#> show vrrp i1
VRRP
Name : i1
Internal name : i1_vlan1_1
State : BACKUP
Virtual address : 10.0.0.100
Base interface : vlan1
Virtual router ID : 1
Master router : 10.0.0.1
Master priority : 100
Effective priority : 50
VRRP version : 2
Preempt : enabled, delay 0
Not part of a sync group.