3: [[!toc levels=3]]
5: # Introduction to the Common Address Redundancy Protocol (CARP)
7: See [[below|guide/caro#license]] for the license of this chapter.
9: CARP is the *Common Address Redundancy Protocol*. Its primary purpose is to
10: allow multiple hosts on the same network segment to share an IP address. CARP is
11: a secure, free alternative to the
12: [Virtual Router Redundancy Protocol](http://www.ietf.org/rfc/rfc3768.txt)
13: and the
14: [Hot Standby Router Protocol](http://www.ietf.org/rfc/rfc2281.txt).
16: CARP works by allowing a group of hosts on the same network segment to share an
17: IP address. This group of hosts is referred to as a *redundancy group*. The
18: redundancy group is assigned an IP address that is shared amongst the group
19: members. Within the group, one host is designated the *master* and the rest as
20: *backups*. The master host is the one that currently *holds* the shared IP; it
21: responds to any traffic or ARP requests directed towards it. Each host may
22: belong to more than one redundancy group at a time.
24: One common use for CARP is to create a group of redundant firewalls. The virtual
25: IP that is assigned to the redundancy group is configured on client machines as
26: the default gateway. In the event that the master firewall suffers a failure or
27: is taken offline, the IP will move to one of the backup firewalls and service
28: will continue unaffected.
30: While highly redundant and fault-tolerant hardware minimizes the need for CARP,
31: it doesn't erase it. There is no hardware fault tolerance that is capable of
32: helping if someone knocks out a power cord, or if your system administrator
33: types reboot in the wrong window. CARP also makes it easier to make the patch
34: and reboot cycle transparent to users, and easier to test a software or hardware
35: upgrade -- if it doesn't work, you can fall back to your spare until fixed.
37: There are, however, situations in which CARP won't help. CARP's design does
38: require that the members of a group be on the same physical subnet with a static
39: IP address, although with the introduction of the carpdev directive, there is no
40: more need for IP addresses on the physical interfaces. Similarly, services that
41: require a constant connection to the server (such as SSH or IRC) will not be
42: transparently transferred to the other system -- though in this case, CARP can
43: help with minimizing downtime. CARP by itself does not synchronize data between
44: applications, for example, manually duplicating data between boxes with rsync,
45: or whatever is appropriate for your application.
47: CARP supports both IPv4 and IPv6.
49: ## CARP Operation
51: The master host in the group sends regular advertisements to the local network
52: so that the backup hosts know it's still alive. If the backup hosts don't hear
53: an advertisement from the master for a set period of time, then one of them will
54: take over the duties of master (whichever backup host has the lowest configured
55: advbase and advskew values). It is possible for multiple CARP groups to exist on
56: the same network segment. CARP advertisements contain the Virtual Host ID which
57: allows group members to identify which redundancy group the advertisement
58: belongs to.
60: In order to prevent a malicious user on the network segment from spoofing CARP
61: advertisements, each group can be configured with a password. Each CARP packet
62: sent to the group is then protected by an SHA1 HMAC.
64: ## Configuring CARP
66: Each redundancy group is represented by a
67: [carp(4)](http://netbsd.gw.com/cgi-bin/man-cgi?carp+4+NetBSD-5.0.1+i386) virtual
68: network interface. As such, CARP is configured using
70: The follow options are available:
72: * `carpN` -- The name of the carp virtual interface where N is an integer that
73: represents the interface's number (e.g., carp 0).
75: * `vhid` -- The Virtual Host ID. This is a unique number that is used to
76: identify the redundancy group to other nodes on the network. Acceptable
77: values are from 1 to 255. This allows for multiple redundancy groups to exist
78: on the same network.
80: * `password` -- The authentication password to use when talking to other
81: CARP-enabled hosts in this redundancy group. This must be the same on all
82: members of the redundancy group.
84: * `carpdev` -- This optional parameter specifies the physical network interface
85: that belongs to this redundancy group. By default, CARP will try to determine
86: which interface to use by looking for a physical interface that is in the
87: same subnet as the `ipaddress` and `mask` combination given to the carp
90: * `advbase` -- This optional parameter specifies how often, in seconds, to
91: advertise that we're a member of the redundancy group. The default is 1
92: second. Acceptable values are from 1 to 255.
94: * `advskew` -- This optional parameter specifies how much to skew the advbase
95: when sending CARP advertisements. By manipulating advbase, the master CARP
96: host can be chosen. The higher the number, the less preferred the host will
97: be when choosing a master. The default is 0. Acceptable values are from 1
98: to 254.
100: * `state` -- Force a carp interface into a certain state. Valid bits are
101: `init`, `backup` and `master`.
103: * `ipaddress` -- This is the shared IP address assigned to the redundancy
104: group. This address does not have to be in the same subnet as the IP address
105: on the physical interface (if present). This address needs to be the same on
106: all hosts in the group, however.
108: * `mask` -- The subnet mask of the shared IP.
110: Further CARP behaviour can be controlled via
113: * `net.inet.carp.allow` -- Accept incoming CARP packets or not. Default is 1
116: * `net.inet.carp.preempt` -- Allow hosts within a redundancy group that have a
117: better advbase and advskew to preempt the master. In addition, this option
118: also enables failing over all interfaces in the event that one interface goes
119: down. If one physical CARP-enabled interface goes down, CARP will change
120: advskew to 240 on all other CARP-enabled interfaces, in essence, failing
121: itself over. This option is 0 (disabled) by default.
123: * `net.inet.carp.log` -- Log bad CARP packets. Default is 0 (disabled).
125: * `net.inet.carp.arpbalance` -- Load balance traffic across multiple redundancy
126: group hosts. Default is 0 (disabled). See
127: [carp(4)](http://netbsd.gw.com/cgi-bin/man-cgi?carp+4+NetBSD-5.0.1+i386) for
128: more information.
130: ## Enabling CARP Support
132: CARP support is not enabled by default.
134: To use
136: you need a kernel with support for the `carp` pseudo-device. Make sure the
137: following line is in your kernel configuration file:
139: pseudo-device carp # CARP
141: After configuring the `carp` pseudo-device in your kernel configuration, you
142: must recompile your kernel and reboot to enable carp support.
144: ## CARP Example
146: An example CARP configuration:
148: # sysctl -w net.inet.carp.allow=1
149: # ifconfig carp0 create
150: # ifconfig carp0 vhid 1 pass lanpasswd \
151: carpdev em0 advskew 100 10.0.0.1 255.255.255.0
153: This sets up the following:
155: * Enables receipt of CARP packets (this is the default setting)
157: * Creates an carp interface.
159: * Configures carp0 for virtual host `#1`, enables a password (`lanpasswd`), sets
160: `em0` as the interface belonging to the group, and makes this host a backup due
161: to the advskew of 100 (assuming of course that the master is set up with an
162: advskew less than 100). The shared IP assigned to this group is
165: Running ifconfig on carp0 shows the status of the interface:
167: # ifconfig carp0
168: carp0: flags=8802<UP,BROADCAST,SIMPLEX,MULTICAST> mtu 1500
169: carp: BACKUP carpdev em0 vhid 1 advbase 1 advskew 100
170: inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255
172: ## Advanced CARP configuration
174: The following example creates a cluster of two highly-available, redundant
175: firewalls. The following diagram presents what we're trying to achieve:
177: +----| WAN/Internet |----+
178: | |
179: em1| |em1
180: +-----+ +-----+
181: | fw1 | | fw2 |
182: +-----+ +-----+
183: em0| |em0
184: | |
185: ---+-------Shared LAN-------+---
187: Both firewalls are connected to the LAN on em0 and to a WAN/Internet connection
188: on em1. IP addresses are as follows:
190: * Firewall 1 (fw1) em0: 172.16.0.1
191: * Firewall 1 (fw1) em1: 192.0.2.1
192: * Firewall 2 (fw2) em0: 172.16.0.2
193: * Firewall 2 (fw2) em1: 192.0.2.2
195: The IP addresses we wish to share between the redundancy groups:
197: * WAN/Internet Shared IP: 192.0.2.100
198: * LAN Shared IP: 172.16.0.100
200: The network policy is that Firewall 1 (fw1) will be the preferred master.
202: The following configuration is for Firewall 1 (fw1):
204: #Enable preemption and group interface failover
205: # sysctl -w net.inet.carp.preempt=1
207: #Configure CARP on the LAN side
208: # ifconfig carp0 create
209: # ifconfig carp0 vhid 1 pass lanpasswd carpdev em0 \
210: 172.16.0.100 255.255.255.0
212: #Configure CARP on the WAN side
213: # ifconfig carp1 create
214: # ifconfig carp1 vhid 2 pass wanpasswd carpdev em1 \
215: 192.0.2.100 255.255.255.0
217: As mentioned before, our policy is for Firewall 1 to be the preferred master.
218: When configuring Firewall 2 we make the `advskew` a higher value since it's less
219: preferred to be the master.
221: The following configuration is for Firewall 2 (fw2):
223: #Enable preemption and group interface failover
224: # sysctl -w net.inet.carp.preempt=1
226: #Configure CARP on the LAN side
227: # ifconfig carp0 create
228: # ifconfig carp0 vhid 1 pass lanpasswd carpdev em0 \
229: advskew 128 172.16.0.100 255.255.255.0
231: #Configure CARP on the WAN side
232: # ifconfig carp1 create
233: # ifconfig carp1 vhid 2 pass wanpasswd carpdev em1 \
234: advskew 128 192.0.2.100 255.255.255.0
236: ## Forcing Failover of the Master
238: There can be times when it is necessary to failover or demote the master node on
239: purpose. Examples include taking the master node down for maintenance or when
240: troubleshooting a problem. The objective here is to gracefully fail over traffic
241: to one of the backup hosts so that users do not notice any impact.
243: To failover, shut down the carp interface on the master node. This will cause
244: the master to advertise itself with an *infinite* advbase and advskew. The
245: backup host(s) will see this and immediately take over the role of master.
247: # ifconfig carp0 down
249: ## License
251: Copyright (c) 2005 Joel Knight <email@example.com>
252: Permission to use, copy, modify, and distribute this documentation for
253: any purpose with or without fee is hereby granted, provided that the
254: above copyright notice and this permission notice appear in all copies.
255: THE DOCUMENTATION IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL
256: WARRANTIES WITH REGARD TO THIS DOCUMENTATION INCLUDING ALL IMPLIED
257: WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE
258: AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL
259: DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR
260: PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
261: TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
262: PERFORMANCE OF THIS DOCUMENTATION
CVSweb for NetBSD wikisrc <wikimaster@NetBSD.org> software: FreeBSD-CVSweb