Common Address Redundancy Protocol
The Common Address Redundancy Protocol or CARP is a computer
Example
If there is a single computer running a
Principle of redundancy
A group of hosts using CARP is called a "group of redundancy". The group of redundancy allocates itself an IP address which is shared or divided among the members of the group. Within this group, a host is designated as "active/primary". The other members are "standby". The main host is that which "takes" the IP address. It answers any traffic or ARP request brought to the attention of this address. Each host can belong to several groups of redundancy. Each host must have a second unique IP address.
A common use of CARP is the creation of a group of redundant firewalls. The virtual IP address allotted to the group of redundancy is indicated as the address of the default router on the computers behind this group of firewalls. If the main firewall breaks down or is disconnected from the network, the virtual IP address will be taken by one of the firewall slaves and the service availability will not be interrupted.
History
In the late 1990s the
Cisco informed the OpenBSD developers that it would enforce its patent on HSRP. Cisco's position may have been due to their lawsuit with Alcatel. As Cisco's licensing terms prevented an open-source VRRP implementation, the OpenBSD developers begun developing CARP instead. OpenBSD focuses on security. They designed CARP to use cryptography. This made CARP fundamentally different from VRRP and ensured that CARP did not infringe on Cisco's patent. CARP became available in October 2003.[3] Later, it was integrated into FreeBSD (first released in May 2005 with FreeBSD 5.4),[4] NetBSD and Linux (ucarp).[1] While Cisco's US patent expired in 2014, the two incompatible protocols continue to coexist.
Incompatibility with IETF standards
OpenBSD uses VRRP's protocol number and MAC addresses. The OpenBSD project requested unique numbers from the Internet Assigned Numbers Authority (IANA) but was denied.
To allocate numbers, IANA has several requirements. At the time, these were specified in RFC 2780. Requirements include participating in a collaborative, lengthy discussion process within the
As a final note of course, when we petitioned IANA, the IETF body regulating[sic] "official" internet protocol numbers, to give us numbers for CARP and pfsync, our request was denied. Apparently we had failed to go through an official standards organization. Consequently we were forced to choose a protocol number which would not conflict with anything else of value, and decided to place CARP at IP protocol 112. We also placed pfsync at an open and unused number. We informed IANA of these decisions, but they declined to reply.
IANA had assigned protocol number 112 to
CARP also uses a range of
In spite of the overlap, it is still possible to use VRRP and CARP in the same broadcast domain, as long as the VRRP group ID and the CARP virtual host ID are different.
See also
- Gateway Load Balancing Protocol (GLBP)
- HSRP
- pfsync
- VRRP
- IP network multipathing(IPMP)
References
- ^ a b ucarp manpage
- ^ "VRRP-CISCO". IETF. Archived from the original on 2014-03-13. Retrieved 2011-11-26.
- ^ Ryan McBride (17 October 2003). "'CARP'". Mailing list ARChives.
- ^ FreeBSD 5.4 i386 release notes, retrieved 2010-01-06
- ^ "CARP License". OpenBSD Release Songs. 2004-05-01.
- ^ "Protocol Numbers". IANA. Retrieved 19 June 2014.
- ^ "Ethernet Numbers". Retrieved 19 June 2014.
External links
- OpenBSD Kernel Interfaces Manual –
- FreeBSD Kernel Interfaces Manual –
- UCARP: userland CARP implementation
- NetBSD port of CARP
- The OpenBSD song 3.5: "CARP License" and "Redundancy must be free"