Icon
Icon		Icon
Icon		Icon
Icon
2:09 AM
0 comments


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

    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
 

OpenBSD CARP

Because of patent issues with VRRP and the Internet Engineering Task Force's (IETF) point of view about patented technology in standards (that is, RAND [reasonable and nondiscriminatory]), the OpenBSD community developed their own redundancy protocol, Common Address Redundancy Protocol (CARP), which was introduced in the OpenBSD 3.5 release. One positive aspect of that architecture is the tight integration with the pf firewall and pf's clustering capabilities via pfsync.
For more information about OpenBSD CARP, look at the CARP man page at http://www.openbsd.org/cgi-bin/man.cgi?query=carp&sektion=4. Notable features are ARP-based Layer 2 load-balancing capabilities, support for both IPv4 and IPv6, and hash protection for enhanced protocol security. Example setups are provided at http://www.countersiege.com/docpfsync-carp/.
 

If You Enjoyed This Post Please Take a Second To Share It.

You Might Also Like

Stay Connected With Free Updates

Subscribe via Email

teaser