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