Virtual Router Redundancy Protocol

Ron McCarty

The Virtual Router Redundancy Protocol (VRRP) has been around since 1997, and although it has been formalized by the Internet Engineering Task Force, it is a little-known protocol outside the realm of full-time network design engineers. VRRP (version 2) is defined in RFC 2338, “Virtual Router Redundancy Protocol”. This month's column will cover VRRP, VRRP design considerations, and an implementation using Linux and the vrrpd daemon.

Redundant Paths

Most networks implement redundant layer 3 paths using a routing protocol. Routing protocols allow routers to determine the best path through a network, as well as to determine new paths when links fail. There are various routing protocols with standards defined for better interoperability among various vendors' hardware. However, routing protocols do not lend themselves well to hosts, especially workstations, since it would require that the routing protocol be maintained on the hosts. This creates additional management issues that are not worth implementing in many network environments where networking and systems administration responsibilities are not shared by the same team.

Although routing protocols are not appropriate for many hosts, many organizations still need to provide a redundant path for hosts, in case their primary (default) gateway fails. VRRP fills this need to provide redundant gateways to other networks, without requiring hosts to have specific knowledge about the redundant gateways (paths). Restated, VRRP provides a transparent redundancy to hosts that cannot otherwise easily be implemented and managed. (For admins supporting Cisco networks, VRRP is similar to Hot Standby Router Protocol [HSRP]. Although Cisco eventually released the specs to HSRP as an RFC, other vendors have been slow to adapt it, since it originally had a proprietary slant.)

VRRP Architecture

VRRP implementations are made up of the following elements as defined by RFC 2338:

VRRP router -- The router actually participating in the virtual router created using VRRP. A VRRP router can support multiple virtual routers. (However, the Linux implementation currently only supports one virtual router made up of multiple VRRP routers.)

Virtual router -- The VRRP routers make up the virtual router. Although the virtual router is made up of multiple VRRP routers, the host using the virtual router is not aware of multiple routers participating and will not notice switch-overs to other VRRP routers within the virtual router.

Master -- The VRRP router that is currently answering requests to the virtual MAC and virtual IP addresses. The master is the only VRRP router that is communicating to the LAN with VRRP advertisements.

VRRP advertisement -- The protocol used to determine the master. Actually, when the protocol is not heard within the master_down_interval, which is:

3 * advertisement interval (normally 1 second) + skew time \
   ( (256 - VRRP router's priority) /256)

Figure 1 shows a logical view of VRRP overlapping the physical VRRP routers and Ethernet network.

Design Issues

Implementing VRRP also requires an understanding of other protocols and design issues in general. Here are several of the design issues to keep in mind:

Routing protocols -- Keep routing protocols pointed at real IP addresses. Pointing routing protocols at virtual IP addresses is asking for trouble by adding additional complexity to the routing protocol and stacking the functionality of the routing protocol on top of VRRP. Not only is additional complexity added, but a failure of VRRP would impact the routing protocol.

ICMP redirects -- Consider ICMP redirects carefully. ICMP redirects can be a useful tool for simple, relatively flat networks, where multiple paths out of a network are possible, and it provides a shorter path to hosts that are not aware of the network topology. (I covered ICMP in my Net Admin column in the April 2000 issue of Sys Admin.)

VRRP configuration -- Keep VRRP routers mirrored to each other. Avoid having paths that are dependent upon one of the routers, since its failure cannot overcome the VRRP protocol. This may not be possible for pre-existing networks where VRRP is being implemented. Should a dependency exist where a network relies on a particular VRRP router, ensure that routes to the network on other routers rely on the the real address of the VRRP router.

Layer 2 awareness -- Be aware of the layer 2 issues involved in implementing VRRP. During a fail-over from primary to backup, switch equipment is aware of two (redundant) paths to the same MAC address and will require the spanning tree protocol to recalculate paths. If the VRRP routers are on the same switch, then the switch will need to support MAC addresses on multiple interfaces.

Network failures -- Network failures can cause multiple VRRP routers to consider themselves primary, since they have not received the VRRP advertisements due to the network failure. This can act as a benefit by providing more connectivity than is possible if the multiple paths did not exist; however, they can inadvertently cause paths to be used that were not meant to be used. This could cause additional expenses in those cases where the paths do not cost the same and that cost is based on utilization, which is common in Europe.

Troubleshooting -- If tcpdump is used on one of the VRRP routers, be aware that tcpdump will report traffic for all interfaces, unless told otherwise. Additionally, sniffing on another host often makes sense to ensure you are seeing what is on the wire and not what a host replies to another interface.

vrrpd

vrrpd (http://w3.arobas.net/~jetienne/vrrpd/index.html), by Jerome Etienne, is a VRRP implementation for Linux. Its current version is 0.3, and the author considers it still in Beta. The program's biggest weakness is lack of support for multiple virtual routers. Additionally, the implementation uses the virtual MAC address for the primary MAC address as well, which can cause a longer fail-over period to the real IP, while caches of nodes must wait until the cache expires and the real MAC address is learned. In practice, this does not affect use since an outage affecting the path to the virtual IP will also affect traffic to the real IP address. However, you should be aware of the issue that can arise during implementation when you are starting and stopping the daemon.

Although VRRP is typically implemented on routers, a closer look at this Linux implementation will give a practical insight into the technology and, should you use hosts for routing, a new tool for network support. The documentation for vrrpd is terse, but the installation is straightforward, and all configuration is handled with parameters on the command line.

vrrpd is Linux-specific, and the examples here were installed on RedHat Linux 6.2. Each Linux host will need interface cards for routing, and IP routing should be activated. For this example, I will use the configuration as shown in Figure 1. To install the software, download the source from:

http://w3.arobas.net/~jetienne/vrrpd/vrrpd-0.3.tgz

cd /usr/local/src/
gunzip vrrpd-0.3.tgz
tar xvf vrrpd-0.3.tar
cd vrrpd
make
cp vrrpd /sbin/

Start vrrpd on “lefty” with:

/sbin/vrrpd -i eth1 -v 200 192.168.1.25 &

Start vrrpd on “righty” with:

/sbin/vrrpd -i eth1 -v 200 192.168.1.25 &

Notice that the priority has been set to 100 on both lefty and righty. Should one particular VRRP router always act as master when it's available, then use the RFC 2338 defined value of 255 to tell the VRRP router that it “owns” the IP address. Unless you define one of the routers as the “owner” and effective master, the VRRP router that comes on line first will become the master and remain backup until a failure. Once a failure occurs and another VRRP backup takes over, it will remain master until the next failure. With the “owner” defined, however, the master will assert itself again and become primary once it returns online.

As can bee seen, vrrpd is easily configured on Linux. Using vrrpd and its configuration is not much harder on most routers, and compared to routing protocols, is typically much easier to manage.

Summary

As I've described, VRRP is a protocol worth knowing and can help provide redundancy to hosts that would normally not have a redundant path to their default gateway. VRRP is a protocol worth having and supporting. Even if your organization will use routers to provide the redundancy, the Linux version gives you a good tool to show proof of concept and to get experience with the protocol.

About the Author

Ronald McCarty received his bachelor's degree in Computer and Information Systems at the University of Maryland's international campus at Schwaebisch Gmuend, Germany. After completing his degree, Ronald McCarty started his network career as network administrator at the Schwaebisch Gmuend campus. Ronald McCarty works for Lucent Technologies as a senior systems engineer on a customer team responsible for a major telecommunications carrier. He spends his free time with his two best friends in the world: his daughter, Janice, and his wife, Claudia. Ron can be reached at: ronald.mccarty@gte.net.