File:  [NetBSD Developer Wiki] / wikisrc / guide / carp.mdwn
Revision 1.1: download - view: text, annotated - select for diffs
Mon Mar 4 23:00:44 2013 UTC (7 years, 6 months ago) by jdf
Branches: MAIN
CVS tags: HEAD
 * fix typo in index_bare
 * move CARP chapter from guide to wiki

    1: # Introduction to the Common Address Redundancy Protocol (CARP)
    2: 
    3: See [[below|guide/caro#license]] for the license of this chapter.
    4: 
    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).
   11: 
   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.
   19: 
   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.
   25: 
   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.
   32: 
   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.
   42: 
   43: CARP supports both IPv4 and IPv6.
   44: 
   45: ## CARP Operation
   46: 
   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.
   55: 
   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.
   59: 
   60: ## Configuring CARP
   61: 
   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 
   65: [ifconfig(8)](http://netbsd.gw.com/cgi-bin/man-cgi?ifconfig+8+NetBSD-5.0.1+i386) 
   66: The follow options are available:
   67: 
   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).
   70: 
   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.
   75: 
   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.
   79: 
   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 
   84:    interface.
   85: 
   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.
   89: 
   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 
   94:    254.
   95: 
   96:  * `state` -- Force a carp interface into a certain state. Valid bits are 
   97:    `init`, `backup` and `master`.
   98: 
   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.
  103: 
  104:  * `mask` -- The subnet mask of the shared IP.
  105: 
  106: Further CARP behaviour can be controlled via 
  107: [sysctl(8)](http://netbsd.gw.com/cgi-bin/man-cgi?sysctl+8+NetBSD-5.0.1+i386):
  108: 
  109:  * `net.inet.carp.allow` -- Accept incoming CARP packets or not. Default is 1 
  110:    (yes).
  111: 
  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.
  118: 
  119:  * `net.inet.carp.log` -- Log bad CARP packets. Default is 0 (disabled).
  120: 
  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.
  125: 
  126: ## Enabling CARP Support
  127: 
  128: CARP support is not enabled by default.
  129: 
  130: To use
  131: [carp(4)](http://netbsd.gw.com/cgi-bin/man-cgi?carp+4+NetBSD-5.0.1+i386),
  132: you need a kernel with support for the `carp` pseudo-device. Make sure the 
  133: following line is in your kernel configuration file:
  134: 
  135:     pseudo-device   carp        # CARP
  136: 
  137: After configuring the `carp` pseudo-device in your kernel configuration, you 
  138: must recompile your kernel and reboot to enable carp support.
  139: 
  140: ## CARP Example
  141: 
  142: An example CARP configuration:
  143: 
  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
  148: 
  149: This sets up the following:
  150: 
  151:  * Enables receipt of CARP packets (this is the default setting)
  152: 
  153:  * Creates an carp interface.
  154: 
  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 
  159:    10.0.0.1/255.255.255.0.
  160: 
  161: Running ifconfig on carp0 shows the status of the interface:
  162: 
  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
  167: 
  168: ## Advanced CARP configuration
  169: 
  170: The following example creates a cluster of two highly-available, redundant 
  171: firewalls. The following diagram presents what we're trying to achieve:
  172: 
  173:              +----| WAN/Internet |----+ 
  174:              |                        |
  175:           em1|                        |em1   
  176:           +-----+                  +-----+
  177:           | fw1 |                  | fw2 |
  178:           +-----+                  +-----+
  179:           em0|                        |em0
  180:              |                        | 
  181:           ---+-------Shared LAN-------+---
  182:         
  183: 
  184: Both firewalls are connected to the LAN on em0 and to a WAN/Internet connection 
  185: on em1. IP addresses are as follows:
  186: 
  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
  191: 
  192: The IP addresses we wish to share between the redundancy groups:
  193: 
  194:  * WAN/Internet Shared IP: 192.0.2.100
  195:  * LAN Shared IP: 172.16.0.100
  196: 
  197: The network policy is that Firewall 1 (fw1) will be the preferred master.
  198: 
  199: The following configuration is for Firewall 1 (fw1):
  200: 
  201:     #Enable preemption and group interface failover
  202:     # sysctl -w net.inet.carp.preempt=1
  203: 
  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
  208: 
  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
  213: 
  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.
  217: 
  218: The following configuration is for Firewall 2 (fw2):
  219: 
  220:     #Enable preemption and group interface failover
  221:     # sysctl -w net.inet.carp.preempt=1
  222: 
  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
  227: 
  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
  232: 
  233: ## Forcing Failover of the Master
  234: 
  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.
  239: 
  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.
  243: 
  244:     # ifconfig carp0 down
  245: 
  246: ## License
  247: 
  248: Copyright (c) 2005 Joel Knight <enabled@myrealbox.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