ISC DHCP Failover and Load Balancing Declarations

Several declarations are configurable to govern the behavior of the primary and secondary servers working as failover peers. The failover peer statement block declares the failover partner server and the parameters that define the interoperation with the failover peer. The name declared for this failover pairing definition is then referenced in individual pool statement blocks for pools for which failover is configured. Thus individual pools can be configured for failover or not. The statements within the failover peer declaration include the following. When referring to this server we mean the server on which the configuration file example is configured.

  • failover peer 'name' { }

where name is the name you define for the pairing (and include the quotes). The curly brackets enclose the statements below providing a full definition of the failover configuration for the server.

  • primary; - if this is a primary server; or secondary; if this is the failover server
  • address IPaddress; where IPaddress is the IP address on which this server should listen for failover messages; alternatively a DNS name can be defined corresponding to the IP address and port on which the server should listen.
  • port portnum; where portnum is the TCP port number on which the server should listen for failover messages from its peer.
  • peer address IPaddress; where IPaddress is the IP address or DNS name of its failover partner.
  • peer port portnum; where portnum is the TCP port number to which this server should connect on the peer server.
  • max-response-delay seconds; This declaration defines the number of seconds the server should wait before it concludes that the connection to its peer has failed.
  • max-unacked-updates number; This declaration defines the window of binding update messages that can be outstanding (unacknowledged) from its peer. Once the number is reached the server must await an acknowledgement of outstanding packets prior to transmitting additional messages.
  • mclt seconds; The maximum client lead time (mclt) declaration indicates the number of seconds a recovering primary must wait after it has received its peer'™s lease database before it can assume the primary role and begin processing DHCP packets. This is because the mclt value is the maximum time a lease may be extended by a server when its partner is down. Thus by waiting mclt seconds the leases provided by this server prior to failure and extended by its peer should be expired.
  • split index; This declaration defines a load balancing split between two peers. If a hash of the client'™s MAC address within a DHCP packet is less than index this server processes the DHCP packet; otherwise it drops it assuming its partner will handle it. The hash value is between 0 and 256 so a value of 256 means no load balancing while 128 means a 50-50 load balance split.
  • hba bitmap; This declaration can be used in lieu of the split statement to provide more granular delineationof the split from a 50/50 vs. 100/0 choice to a bitwise delineation. The bitmap is formatted as a 32-byte hexadecimal string with each byte separated by a colon. For example the following statement is equivalent to split 128;<

    hba ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:

    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00;

    • load balance max seconds sec; This declaration defines a threshold to compare with the secs field of the client'™s DHCP packet in order to override load balancing. If the secs value is greater than sec the server will assume that this client packet normally to be processed by its peer in a load balancing configuration is in need of processing and will handle it thereby overriding the load balancing configuration.
    • auto-partner-down sec; This statement specifies a sec seconds time delay upon entering the communications-interrupted state when the server is unable to communicate with its failover peer. The default is 0. This option should be used with care.

    All of the above statements except split and mclt are defined on both the primary and secondary; split and mclt are only defined on the primary server. These split and mclt values absolutely must match on both servers so they are set on the primary server and communicated to the failover server during the failover protocol initialization between the servers.

    Below is an example of the primary server's failover configuration with its dhcpd.conf file. Note that the "failover peer" statement must be added to each pool for which failover is to be configured.

    StatementMeaning
    failover peer "failover" {
    primary;This is the primary server.
    address p-dhcp.ipamworldwide.com;IP address or name on which to listen for communications from peer.
    port 519;TCP port number to listen on for communications from peer.
    peer address f-dhcp.ipamworldwide.com;IP address or DNS name of peer.
    peer port 520;Connect to peer on TCP port 520.
    max-response-delay 60;Wait 60 seconds before considering peer connection down.
    max-unacked-updates 10;Allow up to 10 unacknowledged binding updates.
    mclt 3600;Maximum lease time in seconds allowed while out of contact with peer.
    split 128;One form of load balancing where 128 is 50%/50% and 256 is 100%/0%.
    load-balance-max-seconds 5;Serve other server's client requests if DHCP header "SECS" value is greater than 5.
    };

    You can also manually place a server in a partner-down state in order to perform maintenance on the partner. This state suspends lease binding updates and heartbeats. Setting a server in the partner-down state may be performed using the DHCP API or by updating the DHCP configuration file using the failover peer 'name' state { } expression then restarting the server. The syntax of this statement is as follows:

    failover peer 'name' state {

    my state partner-down;

    peer state state at date;

    }

    Here we have placed this server (my state) to partner-down omitting the date and placed the peer into another state (valid states are described in the DHCP API section) as of an optional date specification.