Secondary DHCP server won't start on Centos 6.2

Question

I'm trying to create a backup DHCP server. Server times are in sync. Primary server starts fine. Secondary server won't start. Error from /var/log/messages is:

Sep 15 14:47:45 stream dhcpd: Copyright 2004-2010 Internet Systems Consortium.
Sep 15 14:47:45 stream dhcpd: All rights reserved.
Sep 15 14:47:45 stream dhcpd: For info, please visit https://www.isc.org/software/dhcp/
Sep 15 14:47:45 stream dhcpd: /etc/dhcp/dhcpd.conf line 25: invalid statement in peer declaration
Sep 15 14:47:45 stream dhcpd: #011max-response-default
Sep 15 14:47:45 stream dhcpd:          ^
Sep 15 14:47:45 stream dhcpd: /etc/dhcp/dhcpd.conf line 41: failover peer dhcp-failover: not found
Sep 15 14:47:45 stream dhcpd:     failover peer "dhcp-failover"
Sep 15 14:47:45 stream dhcpd:                    ^
Sep 15 14:47:45 stream dhcpd: /etc/dhcp/dhcpd.conf line 49: failover peer dhcp-failover: not found
Sep 15 14:47:45 stream dhcpd:     failover peer "dhcp-failover"
Sep 15 14:47:45 stream dhcpd:                    ^
Sep 15 14:47:45 stream dhcpd: WARNING: Host declarations are global.  They are not limited to the scope you declared them in.
Sep 15 14:47:45 stream dhcpd: /etc/dhcp/dhcpd.conf line 70: failover peer dhcp-failover: not found
Sep 15 14:47:45 stream dhcpd:     failover peer "dhcp-failover"
Sep 15 14:47:45 stream dhcpd:                    ^
Sep 15 14:47:45 stream dhcpd: /etc/dhcp/dhcpd.conf line 78: failover peer dhcp-failover: not found
Sep 15 14:47:45 stream dhcpd:     failover peer "dhcp-failover"
Sep 15 14:47:45 stream dhcpd:                    ^
Sep 15 14:47:45 stream dhcpd: Configuration file errors encountered -- exiting
Sep 15 14:47:45 stream dhcpd:
Sep 15 14:47:45 stream dhcpd: This version of ISC DHCP is based on the release available
Sep 15 14:47:45 stream dhcpd: on ftp.isc.org.  Features have been added and other changes
Sep 15 14:47:45 stream dhcpd: have been made to the base software release in order to make
Sep 15 14:47:45 stream dhcpd: it work better with this distribution.
Sep 15 14:47:45 stream dhcpd:
Sep 15 14:47:45 stream dhcpd: Please report for this software via the CentOS Bugs Database:
Sep 15 14:47:45 stream dhcpd:     http://bugs.centos.org/
Sep 15 14:47:45 stream dhcpd:
Sep 15 14:47:45 stream dhcpd: exiting.

Config file contents:

# DHCP Server Configuration file.
#   see /usr/share/doc/dhcp*/dhcpd.conf.sample
#   see 'man 5 dhcpd.conf'
#

option domain-name "eng.foo.com";
option domain-name-servers ns0.eng.foo.com, ns1.eng.foo.com;
option ntp-servers ntp.eng.foo.com;
#option time-servers ntp.eng.foo.com;

default-lease-time 3600;
max-lease-time 7200;

authoritative;

log-facility local7;

failover peer "dhcp-failover" {
        secondary;
        address 10.0.1.70;
        port 647;
        peer address 10.0.1.11;
        peer port 647;
        max-response-default 30;
        max-unacked-updates 10;
        load balance max seconds 3;
}

#
# Management subnet
#
subnet 10.0.0.0 netmask 255.255.255.0 {
  option subnet-mask 255.255.255.0;
  option broadcast-address 10.0.0.255;
  option routers 10.0.0.1;
  option domain-search "eng.foo.com", "foo.com";

  # Unknown clients get this pool
  pool {
    failover peer "dhcp-failover";
    max-lease-time 300;
    range 10.0.0.240 10.0.0.249;
    allow unknown-clients;
  }

  # Known clients get this pool
  pool {
    failover peer "dhcp-failover";
    max-lease-time 28800;
    range 10.0.0.150 10.0.0.199;
    deny unknown-clients;
  }

  include "/etc/dhcp/dhcpd.conf-engmgmt";

}

#
# Data subnet
#
subnet 10.0.1.0 netmask 255.255.255.0 {
  option subnet-mask 255.255.255.0;
  option broadcast-address 10.0.1.255;
  option routers 10.0.1.1;
  option domain-search "eng.foo.com", "foo.com";

  # Unknown clients get this pool
  pool {
    failover peer "dhcp-failover";
    max-lease-time 300;
    range 10.0.1.240 10.0.1.249;
    allow unknown-clients;
  }

  # Known clients get this pool
  pool {
    failover peer "dhcp-failover";
    max-lease-time 28800;
    range 10.0.1.150 10.0.1.199;
    deny unknown-clients;
  }

  # For centos network installs
  if substring (option vendor-class-identifier, 0, 8) = "anaconda" {
    filename "/autohome/distro/ks/";
    next-server eng-data.eng.foo.com;
  }

  # For PXE network installs
  if substring (option vendor-class-identifier, 0, 9) = "PXEClient" {
    filename "pxelinux.0";
    next-server eng-data.eng.foo.com;
  }

  # For KVM PXE network installs
  if substring (option vendor-class-identifier, 0, 9) = "Etherboot" {
    filename "pxelinux.0";
    next-server eng-data.eng.foo.com;
  }

  include "/etc/dhcp/dhcpd.conf-engdata";

}

Answer 1

This answer is specific to those who are experiencing this same type of error after copying this example configuration from ISC's website. There is a subtle error caused by the encoding of the dashes on that page.

In vim, if you place your cursor over the first dash of max-response-default and press ga while in command mode, you will see a unicode value of 8208. Now if you delete the dash, replace it with your own, and check again, it will have an ASCII/unicode value of 45.

Replace all the Unicode-dashes inside your failover configuration with ASCII-dashes and the configuration should successfully load.

Answer 2

There sems to be a configuration problem around line 25, quite possibly max-response-default. Shouldn't that be max-response-delay?

Answer 3

Most obvious culprit seems to be the secondaries inability to communicate with the primary over the specified port.

• Can you ping the primary from the secondary?
• Is iptables configured to allow communication on port 647?

Beyond that, according to ISC the DHCP service doesn't do a lot of checking to ensure the config is correct, and will fail in odd ways if something isn't set right. So if its not a network issue then it must be the config. For example, one omission in your config file seems to be disabling bootp on segments that have failover enabled. You'd be better off making a master dhcp config used on both servers and then primary/secondary peer declarations that includes the master config, it would preclude the possibility of the configs not matching up.

For quick overview of the main requirements for setting up a dhcp failover scenario see: http://webcache.googleusercontent.com/search?q=cache:tbaPhUwlbdsJ:consultancy.edvoncken.net/index.php/HOWTO_Configure_DHCP_failover+&cd=1&hl=en&ct=clnk&gl=us

Edit: Ah woops, missed the line gertvdijk points out below. It seems it should be max-response-delay, not max-response-default.