xref: /freebsd/share/man/man4/carp.4 (revision 22cf89c938886d14f5796fc49f9f020c23ea8eaf)
1.\"	$OpenBSD: carp.4,v 1.16 2004/12/07 23:41:35 jmc Exp $
2.\"
3.\" Copyright (c) 2003, Ryan McBride.  All rights reserved.
4.\" Copyright (c) 2011, Gleb Smirnoff <glebius@FreeBSD.org>
5.\"
6.\" Redistribution and use in source and binary forms, with or without
7.\" modification, are permitted provided that the following conditions
8.\" are met:
9.\" 1. Redistributions of source code must retain the above copyright
10.\"    notice, this list of conditions and the following disclaimer.
11.\" 2. Redistributions in binary form must reproduce the above copyright
12.\"    notice, this list of conditions and the following disclaimer in the
13.\"    documentation and/or other materials provided with the distribution.
14.\"
15.\" THIS SOFTWARE IS PROVIDED BY THE PROJECT AND CONTRIBUTORS ``AS IS'' AND
16.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
17.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
18.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE PROJECT OR CONTRIBUTORS BE LIABLE
19.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
20.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
21.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
22.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
23.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
24.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
25.\" SUCH DAMAGE.
26.\"
27.Dd March 6, 2023
28.Dt CARP 4
29.Os
30.Sh NAME
31.Nm carp
32.Nd Common Address Redundancy Protocol
33.Sh SYNOPSIS
34.Cd "device carp"
35.Sh DESCRIPTION
36The CARP allows multiple hosts on the same local network to share a set of
37IPv4 and/or IPv6 addresses.
38Its primary purpose is to ensure that these
39addresses are always available.
40.Pp
41To use
42.Nm ,
43the administrator needs to configure at a minimum a common virtual host ID
44(vhid), and attach at least one IP address to this vhid on each machine which
45is to take part in the virtual group.
46Additional parameters can also be set on a per-vhid basis:
47.Cm advbase
48and
49.Cm advskew ,
50which are used to control how frequently the host sends advertisements when it
51is the master for a virtual host, and
52.Cm pass
53which is used to authenticate
54.Nm
55advertisements.
56The
57.Cm advbase
58parameter stands for
59.Dq "advertisement base" .
60It is measured in seconds and specifies the base of the advertisement interval.
61The
62.Cm advskew
63parameter stands for
64.Dq "advertisement skew" .
65It is measured in 1/256 of seconds.
66It is added to the base advertisement interval to make one host advertise
67a bit slower that the other does.
68Both
69.Cm advbase
70and
71.Cm advskew
72are put inside CARP advertisements.
73These values can be configured using
74.Xr ifconfig 8 ,
75or through the
76.Dv SIOCSVH
77.Xr ioctl 2 .
78.Pp
79CARP defaults to using multicast messages, but can be configured to unicast
80announcements to peers using the
81.Cm peer
82and
83.Cm peer6
84parameters. Default addresses can be restored using
85.Cm mcast
86and
87.Cm mcast6 .
88Note that TTL verification is disabled if the peer address is not a multicast
89address.
90These values can be configured using
91.Xr ifconfig 8 ,
92or through the
93.Dv SIOCSPEER
94.Xr ioctl 2 .
95.Pp
96CARP virtual hosts can be configured on multicast-capable interfaces: Ethernet,
97layer 2 VLAN, FDDI and Token Ring.
98An arbitrary number of virtual host IDs can be configured on an interface.
99An arbitrary number of IPv4 or IPv6 addresses can be attached to a particular
100vhid.
101It is important that all hosts participating in a vhid have the same list
102of prefixes configured on the vhid, since all the prefixes are included in the
103cryptographic checksum supplied in each advertisement.
104Multiple vhids running on one interface participate in master/backup
105elections independently.
106.Pp
107Additionally, there are a number of global parameters which can be set using
108.Xr sysctl 8 :
109.Bl -tag -width ".Va net.inet.carp.ifdown_demotion_factor"
110.It Va net.inet.carp.allow
111Allow
112.Nm
113operation.
114When disabled, virtual hosts remain in initial state, neither sending nor
115receiving announcements or traffic.
116Enabled by default.
117.It Va net.inet.carp.preempt
118Allow virtual hosts to preempt each other.
119When enabled, a vhid in a backup state would preempt a master that
120is announcing itself with a lower advskew.
121Disabled by default.
122.It Va net.inet.carp.dscp
123DSCP value in carp packet.
124Valid Values are 0 to 63.
125A value of 4 is equivalent to the old standard of TOS LOW_DELAY.
126TOS values were deprecated and replaced by DSCP in 1998.
127The default value is 56 (CS7/Network Control).
128.It Va net.inet.carp.log
129Determines what events relating to
130.Nm
131vhids are logged.
132A value of 0 disables any logging.
133A value of 1 enables logging state changes of
134.Nm
135vhids.
136Values above 1 enable logging of bad
137.Nm
138packets.
139The default value is 1.
140.It Va net.inet.carp.demotion
141This value shows the current level of CARP demotion.
142The value is added to the actual advskew sent in announcements for
143all vhids.
144During normal system operation the demotion factor is zero.
145However, problematic conditions raise its level: when
146.Nm
147experiences problem with sending announcements, when an interface
148running a vhid goes down, or while the
149.Xr pfsync 4
150interface is not synchronized.
151The demotion factor can be adjusted writing to the sysctl oid.
152The signed value supplied to the
153.Xr sysctl 8
154command is added to current demotion factor.
155This allows to control
156.Nm
157behaviour depending on some external conditions, for example on the status
158of some daemon utility.
159.It Va net.inet.carp.ifdown_demotion_factor
160This value is added to
161.Va net.inet.carp.demotion
162when an interface running a vhid goes down.
163The default value is 240 (the maximum advskew value).
164.It Va net.inet.carp.senderr_demotion_factor
165This value is added to
166.Va net.inet.carp.demotion
167when
168.Nm
169experiences errors sending its announcements.
170The default value is 240 (the maximum advskew value).
171.El
172.\".Sh ARP level load balancing
173.\"A
174.\".Nm
175.\"interface has limited abilities for load balancing incoming connections
176.\"between hosts in an Ethernet network.
177.\"For load-balancing operation, one needs several CARP interfaces that
178.\"are configured to the same IP address, but to a different vhids.
179.\"Once an ARP request is received, the CARP protocol will use a hashing
180.\"function against the source IP address in the ARP request to determine
181.\"which vhid the request will be assigned to.
182.\"If the corresponding CARP interface is the current
183.\"master interface, a reply will
184.\"be sent to the ARP request;
185.\"otherwise it will be ignored.
186.\"See the
187.\".Sx EXAMPLES
188.\"section for a practical example of load balancing.
189.\".Pp
190.\"The ARP load balancing implemented in
191.\".Nm
192.\"has some limitations.
193.\"First, ARP balancing only works on the local network segment.
194.\"It cannot balance traffic that crosses a router, because the
195.\"router itself will always be balanced to the same virtual host.
196.\"Second, ARP load balancing can lead to asymmetric routing
197.\"of incoming and outgoing traffic, and thus combining it with
198.\".Xr pfsync 4
199.\"is dangerous, because this creates a race condition between
200.\"balanced routers and a host they are serving.
201.\"Imagine an incoming packet creating state on the first router, being
202.\"forwarded to its destination, and the destination replying faster
203.\"than the state information is packed and synced with the second router.
204.\"If the reply would be load balanced to second router, it will be
205.\"dropped since the second router has not yet received information about
206.\"the connection state.
207.Sh STATE CHANGE NOTIFICATIONS
208Sometimes it is useful to get notified about
209.Nm
210status change events.
211This can be accomplished by using
212.Xr devd 8
213hooks.
214Master/slave events are signalled under system
215.Dv CARP .
216The subsystem specifies the vhid and name of the interface where
217the master/slave event occurred.
218The type of the message displays the new state of the vhid.
219Please see
220.Xr devd.conf 5
221and the
222.Sx EXAMPLES
223section for more information.
224.Sh EXAMPLES
225For firewalls and routers with multiple interfaces, it is desirable to
226failover all of the addresses running
227.Nm
228together, when one of the physical interfaces goes down.
229This is achieved by the use of the preempt option.
230Enable it on both hosts A and B:
231.Pp
232.Dl sysctl net.inet.carp.preempt=1
233.Pp
234Assume that host A is the preferred master and we are running the
235192.168.1.0/24 prefix on em0 and 192.168.2.0/24 on em1.
236This is the setup for host A (advskew is above 0 so it could be overwritten
237in the emergency situation from the other host):
238.Bd -literal -offset indent
239ifconfig em0 vhid 1 advskew 100 pass mekmitasdigoat 192.168.1.1/24
240ifconfig em1 vhid 2 advskew 100 pass mekmitasdigoat 192.168.2.1/24
241.Ed
242.Pp
243The setup for host B is identical, but it has a higher
244.Cm advskew :
245.Bd -literal -offset indent
246ifconfig em0 vhid 1 advskew 200 pass mekmitasdigoat 192.168.1.1/24
247ifconfig em1 vhid 2 advskew 200 pass mekmitasdigoat 192.168.2.1/24
248.Ed
249.Pp
250When one of the physical interfaces of host A fails,
251.Cm advskew
252is demoted to a configured value on all its
253.Nm
254vhids.
255Due to the preempt option, host B would start announcing itself, and thus
256preempt host A on both interfaces instead of just the failed one.
257.\".Pp
258.\"In order to set up an ARP balanced virtual host, it is necessary to configure
259.\"one virtual host for each physical host which would respond to ARP requests
260.\"and thus handle the traffic.
261.\"In the following example, two virtual hosts are configured on two hosts to
262.\"provide balancing and failover for the IP address 192.168.1.10.
263.\".Pp
264.\"First the
265.\".Nm
266.\"interfaces on host A are configured.
267.\"The
268.\".Cm advskew
269.\"of 100 on the second virtual host means that its advertisements will be sent
270.\"out slightly less frequently.
271.\".Bd -literal -offset indent
272.\"ifconfig carp0 create
273.\"ifconfig carp0 vhid 1 advskew 100 pass mekmitasdigoat 192.168.1.10/24
274.\"ifconfig carp1 create
275.\"ifconfig carp1 vhid 2 advskew 200 pass mekmitasdigoat 192.168.1.10/24
276.\".Ed
277.\".Pp
278.\"The configuration for host B is identical, except the
279.\".Cm advskew
280.\"is on virtual host 1 rather than virtual host 2.
281.\".Bd -literal -offset indent
282.\"ifconfig carp0 create
283.\"ifconfig carp0 vhid 1 advskew 200 pass mekmitasdigoat 192.168.1.10/24
284.\"ifconfig carp1 create
285.\"ifconfig carp1 vhid 2 advskew 100 pass mekmitasdigoat 192.168.1.10/24
286.\".Ed
287.\".Pp
288.\"Finally, the ARP balancing feature must be enabled on both hosts:
289.\".Pp
290.\".Dl sysctl net.inet.carp.arpbalance=1
291.\".Pp
292.\"When the hosts receive an ARP request for 192.168.1.10, the source IP address
293.\"of the request is used to compute which virtual host should answer the request.
294.\"The host which is master of the selected virtual host will reply to the
295.\"request, the other(s) will ignore it.
296.\".Pp
297.\"This way, locally connected systems will receive different ARP replies and
298.\"subsequent IP traffic will be balanced among the hosts.
299.\"If one of the hosts fails, the other will take over the virtual MAC address,
300.\"and begin answering ARP requests on its behalf.
301.Pp
302Processing of
303.Nm
304status change events can be set up by using the following devd.conf rule:
305.Bd -literal -offset indent
306notify 0 {
307	match "system"          "CARP";
308	match "subsystem"       "[0-9]+@[0-9a-z\.]+";
309	match "type"            "(MASTER|BACKUP)";
310	action "/root/carpcontrol.sh $subsystem $type";
311};
312.Ed
313.Pp
314To see
315.Nm
316packets decoded in
317.Xr tcpdump 1
318output, one needs to specify the
319.Fl T Ar carp
320option, otherwise
321.Xr tcpdump 1
322will interpret them as VRRP packets:
323.Bd -literal -offset indent
324tcpdump -npi vlan0 -T carp
325.Ed
326.Sh SEE ALSO
327.Xr tcpdump 1 ,
328.Xr inet 4 ,
329.Xr pfsync 4 ,
330.Xr devd.conf 5 ,
331.Xr rc.conf 5 ,
332.Xr ifconfig 8 ,
333.Xr sysctl 8
334.Sh HISTORY
335The
336.Nm
337device first appeared in
338.Ox 3.5 .
339The
340.Nm
341device was imported into
342.Fx 5.4 .
343In
344.Fx 10.0 ,
345.Nm
346was significantly rewritten, and is no longer a pseudo-interface.
347