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