Common Address Redundancy Protocol
J. Chakradhar Rao B. Karthik Reddy
(05211A0509) (05211A0522)
(Padmasri B V Raju Institute of technology, Narsapur)
Abstract
CARP is the
Common Address Redundancy Protocol. Its primary purpose is to allow multiple
hosts on the same network segment to share an IP address. CARP is a secure, free
alternative to the Virtual Router Redundancy Protocol and Host
Standby Router protocol
CARP works by allowing a group of hosts on the
same network segment to share an IP address. This group of hosts is referred to
as a "redundancy group". The redundancy group is assigned an IP address that is
shared amongst the group members. Within the group, one host is designated the
"master" and the rest as "backups". The master host is the one that currently
"holds" the shared IP; it responds to any traffic or ARP requests directed
towards it. Each host may belong to more than one redundancy group at a time.
Keywords
Common address redundancy protocol, Virtual Router Redundancy Protocol , FreeBSD , Virtual Host , Advertisements , pfsync
Introduction
The Common Address Redundancy Protocol manages failover at the intersection of Layers 2 and 3 in the OSI Model (link layer and IP layer). Each CARP group has a virtual MAC (link layer) address, and one or more virtual host IP addresses (the common address). CARP hosts respond to ARP requests for the common address with the virtual MAC address, and the CARP advertisements themselves are sent out with this as the source address, which helps switches quickly determine which port the virtual MAC address is currently "at".
The master of the address sends out CARP advertisement messages via multicast using the CARP protocol (IP Protocol 112) on a regular basis, and the backup hosts listen for this advertisement. If the advertisements stop, the backup hosts will begin advertising. The advertisement frequency is configurable, and the host which advertises most frequently is the one most likely to become master in the event of a failure.
A reader who is familiar with VRRP will find this is somewhat familiar; however there are some significant differences:
The CARP protocol is address family independent. The OpenBSD implementation supports both IPv4 and IPv6, as a transport for the CARP packets as well as common addresses to be shared.
CARP has an "arpbalance" feature that allows multiple hosts to share a single IP address simultaneously; in this configuration, there is a virtual MAC address for each host, but only one IP address.
CARP uses a cryptographically strong SHA-1 HMAC to protect each advertisement.
Besides these technical differences, there is another significant difference (perhaps the most important one, in fact): CARP is not patent encumbered.
History
In the late 90s IETF began working on a solution to the problem. In 1997, CISCO informed them that this was already covered by Cisco patents. In 1998, Cisco told them it was covered by their patent of HSRP (Hot Standby Router Protocol). Nonetheless, IETF continued work on VRRP (Virtual Router Redundancy Protocol). After some debate, people decided it was alright to allow patented material in a standard, as long as it was licensed under RAND (Reasonable and Non-Discrimatory) terms. Because VRRP fixed problems with the HSRP protocol, Cisco began using VRRP instead, while still claiming it as its own.
Cisco informed the openBSD developers they would enforce their patent of HSRP. This may have been related to their lawsuit with Alcatel. Thus, a free implementation of VRRP could not be made. OpenBSD developers started CARP as an alternative to the patented VRRP, as the licensing terms did not seem reasonable or non-discriminatory. To avoid the HSRP patent, they ensured their idea for CARP was fundamentally different. Because of OpenBSD’s focus on security, CARP was designed with security in mind, and is designed to use cryptography. It became available completely for free, in October 2003. It has since been integrated into FreeBSD and NetBSD
* No official internet protocol number
As a final note of
course, when CARP developers petitioned IANA the IETF body regulating "official"
internet protocol numbers, to give us numbers for CARP and pfsync the request
was denied.
so CARP uses the same port 112 as that of VRRP to avoid
clashes.
*
Failover
* Load balancing
* CARP supports both IPv4 and IPv6.
* Very low overhead
* Cryptographically signed messages
* Interoperability between different operating systems
* its free.
One common use for CARP is to create a group of redundant firewalls. The virtual IP that is assigned to the redundancy group is configured on client machines as the default gateway. In the event that the master firewall suffers a failure or is taken offline, the IP will move to one of the backup firewalls and service will continue unaffected.
While highly redundant and fault-tolerant hardware minimizes the need for CARP, it doesn't erase it. There's no hardware fault tolerance that's capable of helping if someone knocks out a power cord, or if your system administrator types reboot in the wrong window. CARP also makes it easier to make the patch and reboot cycle transparent to users, and easier to test a software or hardware upgrade--if it doesn't work, you can fall back to your spare until fixed.
Drawbacks :
There are, however, situations in which CARP won't help. CARP's design does require that the members of a group be on the same physical subnet with a static IP address, although with the introduction of the carpdev directive, there is no more need for IP addresses on the physical interfaces. Similarly, services that require a constant connection to the server (such as SSH or IRC) will not be transparently transferred to the other system--though in this case, CARP can help with minimizing downtime. CARP by itself does not synchronize data between applications, for example, manually duplicating data between boxes with rsync, or whatever is appropriate for your application.
Configuring CARP:
Each redundancy group is represented by a carp(4) virtual network interface. As such, CARP is configured using ifconfig(8) The follow options are available:
carpN
vhid
password
carpdev
advbase
advskew
state
ipaddress
mask
Further CARP behaviour can be controlled via sysctl(8)
net.inet.carp.allow
net.inet.carp.preempt
net.inet.carp.log
net.inet.carp.arpbalance
CARP support is not enabled by default.
To use
carp(4) you need a kernel with support for the carp pseudo-device. Make sure the following line
is in your kernel configuration file:
pseudo-device carp # CARP
After
configuring the carp pseudo-device in
your kernel configuration, you must recompile your kernel and reboot to enable
carp(4) support.
There are three basic elements to setting up CARP failover interfaces to boot on FreeBSD:
First, in /etc/rc.conf, tell FreeBSD that you’re creating a “cloned interface.” Unless the interface is included in the list of virtual interfaces, it will never be created by FreeBSD.
cloned_interfaces="carpXX"
The cloned_interfaces directive can contain as
many virtual interfaces as you need separated by a space:
cloned_interfaces="carpXX carpYY carpZZ"
Then add the configuration directives for your cloned interfaces to /etc/rc.conf.
ifconfig_carpXX="vhid <carp-interface-id> advskew <priority>
pass <password> <carp-ip-address>"
and then in /etc/sysctl.conf, tell the kernel that you want to allow CARP interfaces to preempt each other:
net.inet.carp.preempt=1
This directive also means that once any single interface fails on a router, all virtual CARP interfaces will be shifted to the failover router at once.
The ifconfig_carpXX line is made up of four
elements.
vhid
<carp_interface_id> the virtual interface ID
advskew
<priority> the priority of the interface
pass
<password> the password used by hosts to
validate the CARP relationship
<carp_ip_address> the IP address of
the virtual interface.
ifconfig_carpXX="
1==>vhid
<carp_interface_id>
2==>advskew
<priority>
3==>pass <password>
4==><carp_ip_address>"
That’s all there is to it. You won’t need to worry about where or how the virtual interface attaches, FreeBSD is smart enough to know which parent interface it’s supposed to use by the IP address assigned to the CARP interface. The only real bookkeeping you’ve got to do is to make sure that:
the VHID on your primary and failover routers match, and
that the priority of the primary is lower than the failover.
How it Works ?
The master host in the group sends regular advertisements to the local network so that the backup hosts know it's still alive. If the backup hosts don't hear an advertisement from the master for a set period of time, then one of them will take over the duties of master (whichever backup host has the lowest configured advbase and advskew values). It's possible for multiple CARP groups to exist on the same network segment. CARP advertisements contain the Virtual Host ID which allows group members to identify which redundancy group the advertisement belongs to.
In order to prevent a malicious user on the network segment from spoofing CARP advertisements, each group can be configured with a password. Each CARP packet sent to the group is then protected by an SHA1 HMAC.
Implementation:
In the following example uses two FreeBSD routers called primo (our primary router) and secundo (our failover router) in a failover configuration:
/etc/rc.conf
ifconfig_em0="inet
99.88.77.70/29" # external interface for primo, our primary router
ifconfig_em1="inet 10.11.12.254/24" # internal interface for primo
defaultrouter="99.88.77.65"
gateway_enable="YES"
cloned_interfaces="carp1 carp2"
ifconfig_carp1="vhid 1 advskew 50 pass BigPassword 99.88.77.66" # external CARP interface for primo
ifconfig_carp2="vhid 2 advskew 50 pass BigPass2W 10.11.12.1" #internal CARP interface for primo
/etc/rc.conf
ifconfig_em0="inet 99.88.77.69/29" #external
interface for secundo, our failover router
ifconfig_em1="inet 10.11.12.253/24" # internal interface for secundo
defaultrouter="99.88.77.65"
gateway_enable="YES"
cloned_interfaces="carp1 carp2"
ifconfig_carp1="vhid 1 advskew 80 pass BigPassword 99.88.77.66" #our external CARP interface for secundo
ifconfig_carp2="vhid 2 advskew 80 pass BigPass2W 10.11.12.1" # internal CARP interface for secundo
Now I’m sure you’ve already noticed, but I want to reiterate it; the only difference in CARP interface definitions between the two hosts is the advskew assigned to each. This is how the priority of the router is assigned.
( Picture configuration not specific to the above implementation)
Example 2 : ( firewall failover )
Firewall Failover with pfsync and CARP
On most networks, the firewall is a single point of failure. When the firewall goes down, inside users are unable to surf the web, the website goes dead to the outside world, and email grinds to a halt. Since version 3.5, OpenBSD has included a number of components which can be used to solve this problem, by placing two firewalls in parallel. All traffic passes through the primary firewall; when it fails the backup firewall assumes the identity of the primary firewall, and continues where it left off. Existing connections are preserved, and network traffic continues as if nothing had happened.
Not only does such a configuration increase the reliability of the network, it can also increase the security in some subtle ways. It is now trivial to do upgrades without impacting the network, by taking the firewalls offline one at a time. The result? Hopefully the firewalls will be upgraded more frequently and there will be less resistance to applying patches "because the network will go down". Furthermore, in many corporate environments there is strong pressure to keep the network up "no matter what". Frequently then a firewall failure means running unprotected rather than waiting until a new one can be brought up - obviously increasing firewall reliability reduces the risk of this happening.
The two main components provided by OpenBSD are CARP (the Common Address Redundancy Protocol), which allows a backup host to assume the identity of the primary, and pfsync, which ensures that firewall states are synchronised so that the backup can take over exactly where the master left off and no connections will be lost.
Pfsync transfers state insertion, update, and deletion messages between firewalls. Each firewall sends these messages out via multicast on a specified interface, using the PFSYNC protocol (IP Protocol 240). It also listens on that interface for similar messages from other firewalls, and imports them into the local state table.
In order to ensure that pfsync meets the packet volume and latency requirements, the initial implementation has no built-in authentication. An attacker who has local (link layer) access to the subnet used for pfsync traffic can trivially add, change, or remove states from the firewalls. It's possible to run the pfsync protocol on one of the "real" networks, but because of the security risks, it is strongly recommended that a dedicated, trusted network be used for pfsync. This can be as simple as a crossover cable between interfaces on two firewalls
Following firewall cluster at home consists of two Soekris Engineering 4501s. Each device has three interfaces - one interface connects to a hub on the external, Internet side, one interface connects to the internal network, and the third interface connects the two firewalls to each other via a crossover cable: a dedicated link for the pfsync protocol.
The sample configuration given here is for the basic example above. Each box has three sis(4) interfaces; sis0 is the external interface, on the 10.0.0.0/24 subnet, sis1 is the internal interface, on the 192.168.0.0/24 subnet, and sis2 is the pfsync interface, using the 192.168.254.0/24 subnet. A crossover cable connects the two firewalls via their sis2 interfaces. On all three interfaces, firewall A uses the .254 address, while firewall B uses .253.
The interfaces are configured as follows:
/etc/hostname.sis0:
inet 10.0.0.254 255.255.255.0 NONE
/etc/hostname.sis1:
inet 192.168.0.254 255.255.255.0 NONE
/etc/hostname.sis2:
inet 192.168.254.254 255.255.255.0 NONE
/etc/hostname.carp0:
inet 10.0.0.1 255.255.255.0 10.0.0.255 vhid 1 pass foo
/etc/hostname.carp1:
inet 192.168.0.1 255.255.255.0 192.168.0.255 vhid 2 pass bar
/etc/hostname.pfsync0:
up sync if sis2
pf(4) must also be configured to allow pfsync and CARP traffic through. The following should be added to the top of /etc/pf.conf:
pass quick on { sis2 } proto pfsync keep state (no-sync)
pass on { sis0 sis1 } proto carp keep state
When writing the rest of the pf ruleset, it is important to keep in mind that from pf's perspective, all traffic comes from the physical interface, even if it is routed through the carp address. However, the address is of course associated with the carp interface. Therefore, in the interface context, such as "pass in on $extif ...", $extif would be the physical interface, but in the context of "from $foo" or "to $foo", the carp interface should be used, as it's being meant in the address context.
If preemption is desired, the server intended to be the backup needs to have a higher advskew than the primary. In this case, the carp configuration for the backup firewall would be as follows:
/etc/hostname.carp0:
inet 10.0.0.1 255.255.255.0 10.0.0.255 vhid 1 advskew 100 pass foo
/etc/hostname.carp1:
inet 192.168.0.1 255.255.255.0 192.168.0.255 vhid 2 advskew 100 pass bar
And of course, the following must be added to /etc/sysctl.conf on both firewalls:
net.inet.carp.preempt=1
Example 3 :
The following example creates a cluster of two highly-available, redundant firewalls. The following diagram presents what we're trying to achieve:
+----| WAN/Internet |----+
| |
em1| |em1
+-----+ +-----+
| fw1 | | fw2 |
+-----+ +-----+
em0| |em0
| |
---+-------Shared LAN-------+---
Both firewalls are connected to the LAN on em0 and to a WAN/Internet connection on em1. IP addresses are as follows:
Firewall 1 (fw1) em0: 172.16.0.1
Firewall 1 (fw1) em1: 192.0.2.1
Firewall 2 (fw2) em0: 172.16.0.2
Firewall 2 (fw2) em1: 192.0.2.2
The IP addresses we wish to share between the redundancy groups:
WAN/Internet Shared IP: 192.0.2.100
LAN Shared IP: 172.16.0.100
The network policy is that Firewall 1 (fw1) will be the preferred master.
The following configuration is for Firewall 1 (fw1):
#Enable preemption and group interface failover#sysctl -w net.inet.carp.preempt=1#Configure CARP on the LAN side#ifconfig carp0 create#ifconfig carp0 vhid 1 pass lanpasswd carpdev em0 \172.16.0.100 255.255.255.0#Configure CARP on the WAN side#ifconfig carp1 create#ifconfig carp1 vhid 2 pass wanpasswd carpdev em1 \192.0.2.100 255.255.255.0
As
mentioned before, our policy is for Firewall 1 to be the preferred master. When
configuring Firewall 2 we make the advskew a higher value since it's less
preferred to be the master.
The following configuration is for Firewall 2 (fw2):
#Enable preemption and group interface failover#sysctl -w net.inet.carp.preempt=1#Configure CARP on the LAN side#ifconfig carp0 create#ifconfig carp0 vhid 1 pass lanpasswd carpdev em0 \advskew 128 172.16.0.100 255.255.255.0#Configure CARP on the WAN side#ifconfig carp1 create#ifconfig carp1 vhid 2 pass wanpasswd carpdev em1 \advskew 128 192.0.2.100 255.255.255.0
Conclusion
Server Fail over is of high importance in the present situation as most
of the business needs 24X7 services without any
interruption.
A slight
interruption for the availability of services causes great Loss of
money.
CARP gives a best solution for the above problem.
Also it can be used for load balancing of servers which is the key
constraint for providing uninterrupted services.
Failure of server
cause severe security implications.
Thus CARP is the best and costs
saving solution for any company to provide 24X7
online services.
Links & References
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/carp.html
http://faqs.org/rfcs/rfc3768.html
Contacts
Karthikreddy.bvrit@gmail.com ( 9966956676 )
.
,
