VRRP (Virtual Router Redundancy Protocol) is a system that enables more than one device on a network to act as a gateway for routing traffic, where one is a master and others are backup. The idea is that if one of the devices fails for any reason then the backup can step in automatically and continue routing traffic.
Virtual Address
VRRP works by having a virtual IP address that can move between devices automatically.
You would normally make this an extra address on the network, but it can be the normal address for the master router if you prefer (e.g. if short of IP addresses).
You could have more than one virtual address. You can have more than on VRRP in operation at once on the same or different machines as well.
One device is master and handles all traffic for the virtual address. If the master fails, the backup takes over. Other devices do not need to be aware of the change.
For IPv6 VRRP3 is used by default whereas for IPv4 VRRP2 is used by default. Devices have to be using the same version. IPv4 and IPv6 can co-exist with one using VRRP2 and the other VRRP3. Setting the same config (apart from priority) on all devices ensures they have the same version.
VRID
You can have multiple VRRPs on the same LAN at the same time, so there is an ID that is used to tell them apart. The default is 42.
Set all devices that are working together to the same ID and different to the ID of other VRRPs on the same LAN.
Typically you would only have the one so the default of 42 is fine.
As a general rule, it is a good idea to set a separate VRRP ID for different VRRP instances even when they are on separate VLANs. This is because the MAC address used is based on the VRRP ID.
If you have any non VLAN aware switches, switches that do not have separate VLAN MAC caches, some Linux installations taking part in the VRRP, or are using an FB2900 in some configurations then the MAC address may be misdirected by a switch and cause problems.
The *FB6000 series can happily handle the same VRRP ID on any number of VLANs but the other issues (switches) are worth considering even in this case.
*The FB6000 series is due to be replaced in Q1 or Q2 of 2021, by the FB9000 series. A few improvements include a more powerful CPU, more RAM & Ten SFP ports (Two at 10Gbit/s & eight at 1Gbit/s). Please contact us or periodically check our News page for updates on features & availability of the new FB9000 series.
Priority
The priority defines which is master and which is backup. Higher is master. If using the normal IP of the master, then the master should have priority 255. Otherwise, pick priorities from 1 to 254. It is usually sensible to space these out, e.g. using 100 and 200. We suggest not setting priority 1 (see profiles and test, below).
Interval
The interval is specified in multiples of 10ms, so 100 is one second. The default is one second. If you set lower than one second then VRRP3 is used by default (see below). VRRP2 only does whole seconds and must have the same interval for all devices. VRRP3 can have different intervals on different devices, but typically you would set them all the same.
Special MAC address
By default, a special MAC address is used. This means devices on the LAN are not even aware that the master/backup switch has happened. When there is a switch the VRRP packets that are broadcast are sent from the MAC so your network switch will move traffic to the right device automatically. Each VRID has its own MAC, and IPv4 and IPv6 use a different MAC.
You can disable the use of the special MAC if you wish, and use a normal FireBrick MAC. This can lead to problems in some cases.
Interaction with DHCP
If you are running DHCP server on the FireBrick and do not set the gateway to be advised to clients, the FireBrick picks one of its own IP addresses. Where the FireBrick has VRRP configured on the same interface it will advise this as the gateway to use.
This means devices will use the virtual address as the gateway and so switch to the backup as gateway automatically when needed. You can still specify an explicit gateway on the DHCP server settings if you prefer.
Where no DNS server is specified in the DHCP server settings then the FireBrick sends its own IP as DNS server. Again, if VRRP is configured the virtual address is sent.
The FireBrick handles DNS resolution and relay for traffic sent to the virtual address. You can set DNS servers explicitly in the config instead, including setting an empty list of servers.
Interaction with IPv6 Router Announcements
IPv6 router announcements will send the MAC address of the FireBrick as the gateway for devices on the LAN. If you have VRRP configured with the special MAC address, then the special MAC address is what is sent. This allows devices on the LAN to switch gateway automatically.
Where no DNS server is specified in the RA settings then the FireBrick sends its own IP as DNS server. Again, if VRRP is configured the virtual address is sent.
The FireBrick handles DNS resolution and relay for traffic sent to the virtual address. You can set DNS servers explicitly in the config instead, including setting an empty list of servers.
Interaction with BGP
When deciding the local IP to use as a next-hop in BGP announcements the FireBrick will use the VRRP IP address if there is one on the interface. This can be disabled on specific configuration settings on BGP if required.
Profiles and test
One of the classic problems with VRRP is that if a master router fails, and is then restored to service, then it can become master for VRRP before it knows where to route the traffic it receives.
To address this issue, a VRRP config can have a profile and also has the (deprecated) option to directly test the routability of an IP address. If the test fails or the profile is inactive then the VRRP continues to operate as normal but with a low priority setting (normally priority 1 but this can be configured).
This has the effect that the virtual gateway will switch to the backup router as it will have a priority higher than 1. If however the backup router is broken or also has a failed test or inactive profile then both will have the low priority so one will still act as a router on the LAN.
Once the low priority state ends there is then a delay (default 10 seconds) before the priority returns to normal – this also applies on power on. This allows time for external routing to fully establish before becoming master again.
Controlled shutdown
In much the same way as a profile failing, if a controlled shutdown is done (such as loading new software into the FireBrick), then the VRRP switches to a low priority allowing the backup to become master. This can allow a software re-load without losing a packet where a pair of routers is deployed.
Session tracking and firewalls
Session tracking is per FireBrick. This means a firewalled session may fail if routing switches to backup. This is not always the case, as a packet in the right direction to re-establish the session on the new router will allow the reply traffic if there is no NAT or mapping involved.
Where NAT or mapping is being used the switch to a backup router will cause all current sessions to fail. VRRP is best deployed where there is no such mapping in place.
VRRP version
VRRP version 2 works with IPv4 addresses and whole second polling intervals only. Normal polling is one second, and the timeout is three times that which means the fastest a backup can take over is just over 3 seconds.
You should configure all devices on the VRRP with the same settings (apart from their priority).
VRRP version 3 works in much the same way, but allows polling to be any multiple of 10ms (1/100th of a second). The default polling is still 1 second, but it can be set faster or slower. The timeout is still 3 times the poll rate, but this means the backup could take over in as little as 30ms.
VRRP3 also works with IPv6. Whilst IPv4 and IPv6 VRRP are completely independent, you can configure both at once in a single config by listing one or more IPv4 addresses and one or more IPv6 addresses.
VRRP3 is used by default for any IPv6 addresses or where an interval of below one second is selected. It can also be specifically set in the config by setting version3=”true”.
If you have devices that are meant to work together as VRRP but one is version 2 and one is version 3 then they will typically not see each other and both become master.
The status page shows if VRRP2 or VRRP3 is in use, and whether the FireBrick is master or not.
Compatibility
VRRP2 and VRRP3 are standard protocols and so the FireBrick can work alongside other devices that support VRRP2 or VRRP3.
Note that the FireBrick has non-standard support for some specific packets sent to the VRRP virtual addresses. This includes answering pings (configurable) and handling DNS traffic. Other VRRP devices may not operate in the same way and so may not work in the same way if they take over from the FireBrick.
Example
If you have one router on a LAN that is 192.168.0.2/24 and another that is 192.168.0.3/24, you might decide to allocate 192.168.0.1 as a virtual gateway.
| Attribute | Master | Backup |
|---|---|---|
| ip | 192.168.0.1 | 192.168.0.1 |
| vrid | 42 | 42 |
| priority | 200 | 100 |
| interval | 100 (1s) | 100 (1s) |
| preempt | true | true |
| use-vmac | true | true |
| version3 | false | false |