How Virtual Router Redundancy Protocol works
Virtual Router Redundancy Protocol (VRRP) is a simple, yet robust practice that can provide additional availability in your network. VRRP can be implemented using Red Hat Enterprise Linux and/or the VRRPd open source implementations.
VRRP provides gateway redundancy by allowing each router within the redundant router topology to share a virtual Ethernet MAC address and a virtual IP address. When the virtual addresses are active on a particular router, the router is said to be the master. Routers without control of the virtual addresses are referred to as backups.
VRRP runs on top of the Internet as its own protocol (i.e., it does not use TCP or UDP) and sends its announcements to a multicast address for outer VRRP routers to listen. If a backup does not hear from the master, then the backup will take over through an election process whereby the router with the highest priority within the VRRP routers.
Generally, VRRP is a protocol used in enterprise environments where routing redundancy is necessary for host stations, especially end user workstations. In this tip, I offer an overview of VRRP's uses and how to get started with it.
Availability and single points of failure
Workstation failures are accepted as part of the computing environment with very little spent on providing additional resiliency in workstations, like redundant hard drives, processors and other components. Network redundancy is also not needed for the workstation. The network connectivity is usually provided through a single Ethernet port to a switch, which connects to a core switch or router. Redundancy for link failures between switches is supplied through additional connections and the use of the Virtual Trunking protocol so that a switch that uplinks other switches does not become a single point of failure for many users. This does not address the resiliency needed for the default gateway (router) use by the workstations.
Prior to widespread Internet usage, redundancy for the routers (default gateways and other gateways) was provided using routing protocols such as RIP and then RIP2. Most environments chose not to implement routing protocols at the workstation level because of increased Internet Protocol use and disruptions caused by the failure of users to understand how changes on their workstations affected the entire network.
By not running a routing protocol, a workstation will not have knowledge of a redundant gateway to route traffic to during a failure of the primary router. This means that a router failure will cause the workstation to fail to communicate with stations outside its local area network. From an availability standpoint, this is acceptable for a single workstation. Yet, the single router failure becomes a point of failure for a complete network, which, in large networks, can impact hundreds of users.
Transparent redundancy
Without running a routing protocol on the workstation, a transparent method is needed to provide gateway redundancy without requiring changes on the workstation. Ideally, this wouldn't impact the workstation at all.
Various vendors looked at addressing this issue by enabling some type of IP-sharing via the routers providing redundant gateway functionality. The most successful vendor technology was Cisco's Hot-Standby Router Protocol (HSRP), developed in the early 1990's. Due to the popularity of Cisco's routers, the protocol is still commonly in use today. Initially, Cisco did not provide the specifications to the protocol. Although the algorithms of the protocol was easy enough to determine using network sniffers, it was unclear to other vendors how Cisco would react to reverse-engineering on other platforms to create interoperability with HSRP.
Because of the intellectual rights associated with having a vendor control a protocol the Internet Engineering Task Force (IETF) created a working group and, ultimately, requests for comments (RFCs) to define the protocol. (Most of the foundation of the working group started in 1997. Cisco decided to release HSRP as RFC 2281 in 1998 before the IETF could release its initial RFC.)
VRRP on Linux
VRRP is often implemented on Linux using the VRRPd. Red Hat also provides VRRPd as part of its Cluster Suite, but the example here will use the VRRPd to keep the example configuration straightforward.
Once the VRRPd is installed on the system, the master VRRP router can be started with
vrrpd –i eth0 –p 25 –v 1 192.168.1.1
- The –i parameter tells VRRPd which interface to use for binding of the virtual IP 192.168.1.1 and which interface to use for vrrp announcements.
- The –p parameter tells vrrpd which priority to assign this instance of the virtual router. The virtual router instance with the highest priority will become the master.
- The last parameter, –v, tells the virtual router which instance (virtual router) it is a part of. This is what identifies and associates this particular instance with other virtual routers on the local area network.
The backup VRRP router can be started with:
vrrp –i eth0 –p 24 –v 1 192.168.1.1
Notice the only difference is the –p with a value of 24. By being less than the master's 25, this instance will come up as a backup router.
Watching VRRP
VRRP has been assigned the protocol number 112 by the Internet Engineering Task Force. This protocol number can be used to take a peek at VRRP with tcpdump to determine what the protocol is doing. For example, the following tcpdump shows only one router advertising its virtual router ID to other routers running vrrpd:
[root@red ~]# tcpdump -vv proto 112
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
00:07:02.643224 IP (tos 0x0, ttl 255, id 58441, offset 0, flags [none], proto 112, length: 40) 192.168.1.5 > VRRP.MCAST.NET: VRRPv2, Advertisement, vrid 1, prio 25, authtype none, intvl 1s, length 20, addrs: 192.168.1.1
00:07:03.649142 IP (tos 0x0, ttl 255, id 58697, offset 0, flags [none], proto 112, length: 40) 192.168.1.5 > VRRP.MCAST.NET: VRRPv2, Advertisement, vrid 1, prio 25, authtype none, intvl 1s, length 20, addrs: 192.168.1.1
This tcpdump was run on the system running VRRPd, so the lack VRRP protocol messages from the other VRRP router suggests that there is a network down. Ifconfig, unfortunately, cannot be used to monitor the VRRP virtual interface. Therefore, the ps command should be used to determine any virtual IP addresses:
[root@red ~]# ps aux | grep vrrp
root 11403 0.0 0.1 1708 464 pts/1 S 00:22 0:00 vrrpd -n -i eth0 -p 25 -v 1 192.168.1.1
Routing through VRPP
To route traffic through the VRRP routers, the DHCP scopes for workstations must be configured to hand out the virtual IP address as the default gateway.
For workstations that are configured with static IP addresses, the gateway will need to be manually changed. For RHEL 5, the /etc/sysconfig/network file needs to be edited so that the GATEWAY parameter points to the virtual IP as the following example shows for this article's scenario:
[root@blue ~]# cat /etc/sysconfig/network
NETWORKING=yes
HOSTNAME=blue.mcwrite.net
GATEWAY=192.168.1.1
