VRRP
Gateway redundancy protocols solve the problem of eliminating single points of failure in a LAN environment for clients that require a reliable HA default path and next hop. Provisioning of a default route/multiple routes can, in general, be achieved in various ways:
Dynamic Host Configuration Protocol (DHCP) with default gateway provisioning
Manual default route entry/entries plus load balancing (optional Linux feature)
Dynamic routing protocols on the client workstation
Internet Router Discovery Protocol (IRDP) clients
Virtual Router Redundancy Protocol/Hot Standby Router/Protocol/Gateway Load Balancing Protocol (VRRP/HSRP/GLBP)
The concept of a secondary default route (floating static route) does not work on multi-access networks. The affected workstation has no standardized and reliable way of telling that a particular gateway just went down, and an incomplete ARP entry does not trigger a route removal from the forwarding table. This is implementation-specific and different on point-to-point links with line protocols.
VRRP (RFC 2338) is essentially an election protocol that elects a master from a pool of candidate routers and takes care of associated Layer 3 and Layer 2 virtual and real addresses for resilient LAN forwarding responsibility. The virtual router that is associated with each alternate path under VRRP uses the same IP address and MAC address as the routers for other paths. As a result, the host's gateway information does not change, no matter which path is used. This applies to both the IP and MAC address used for the actual frame delivery.
VRRP is related to the Cisco proprietary and highly successful HSRP and supplemented by GLBP. Look at the Cisco.com document "Virtual Router Redundancy Protocol" for more information. The Cisco implementation requires Cisco IOS Release 12.2(T)or 12.0ST.
CAUTION
HSRP is not compatible with VRRP.
The following sections discuss two implementations of VRRP for UNIX.
VRRPd
VRRPd is a Linux implementation of the Virtual Router Redundancy Protocol originally developed by ImageStream and released to the public as a GNU project.
VRRP's primary design goal is eliminating a single point of failure represented by a next-hop gateway for static LAN routes, often routes of last resort. Figure 12-5 presents the lab layout used for the following configurations. The specification of VRRP was influenced considerably by the Cisco HSRP protocol. In addition to this primary function (next-hop redundancy), RFC 2338 also states that the protocol should
Minimize the duration of black holes.
Minimize the steady-state bandwidth overhead and processing complexity.
Function over a variety of multiaccess LAN technologies that support IP traffic.
Provide for election of multiple virtual routers on a network for load balancing.
Support multiple logical IP subnets on a single LAN segment.
Figure 12-5. VRRP Lab Architecture
Freevrrpd
Freevrrpd is part of the HUT Project. A feature overview according to the HUT Project includes the following:
Provides an RFC 2338-compliant daemon
Implements virtual addresses
Supports multiple virtual router IDs (VRIDs)
Enables master state announcement (by sending multicast packets via BPF)
Changes routes and IP in 3 seconds
Performs gratuitous ARP requests to clean the cache of all hosts
Elects from among different slave servers
Allows the same host to be slave and master simultaneously
Automatically downgrades to slave if a master is up again
Provides anti-address-conflict system
Provides multithreaded vrrp daemon
Supports plain-text passwords
Supports netmask for virtual IP address(es)
Simple version of "monitored circuits"
Supports executing master/backup scripts during transition state
Comparison of the VRRP Implementations
Example 12-9 provides a comparison of different VRRP implementations.
Example 12-9. VRRP Lab (Linux VRRPd, CISCO IOS Architecture, and FreeBSD freevrrpd)
scar# show running-config ... interface ethernet 1/0 ip address 192.168.14.254 255.255.255.0 vrrp 1 priority 50 vrrp 1 ip 192.168.14.10 ... [root@castor:~#] cat /usr/local/etc/freevrrpd.conf # Each VRID section must begin with [VRID] keyword [VRID] # serverid is needed to specify the number of the VRID, here VRID = 1 serverid = 1 # you must set the interface with a real interface name of your system interface = ed0 # priority = 255 is a MASTER of the VRID # priority < 255 is a BACKUP with a priority 0 to 254 # 254 is a higher BACKUP priority priority = 100 # addr option is needed to specify ip address(es) associated with the VRID # you can specify multiple addresses separated by ',' # netmask is specified with CIDR notation, so numbers after '/' represent the # number of bits set to 1 for the netmask. # eg: /24 is 11111111 11111111 11111111 00000000 = 255.255.255.0 addr = 192.168.14.10/24 [root@castor:~#] freevrrpd ?f /usr/local/etc/freevrrpd.conf [root@callisto~#] vrrpd i eth0 ?p 255 ?v 1 192.168.14.10
