Well we finally have our MPLS network in place and I am gearing up to centralize all of our provisioning and add as much redundancy as I can. My goal is to have one main DHCP server with a secondary one synced up and ready to load balance if need be. I have a test version of this running (a site dhcp server as the master and my main server at the headend as the slave), but I am having issues with the BootP part of the equation. It appears that the ICS DHCP server doesn't like to failover pools with bootp enabled.
At the moment I can't find a way around this except to only to run failover on the CPE pools, which is not an ideal situation. Has anyone tackled this problem in the past?
FWIW, here are my DHCP server config files. Remember I have the headend as the slave and remote site as the master right now.
headend [slave]:
[code]
omapi-port 9991;
key omapi_key {
algorithm HMAC-MD5;
secret "************************";
};
omapi-key omapi_key;
class "cm" {
match if substring(option vendor-class-identifier,0,6) = "docsis";
spawn with option agent.remote-id;
}
authoritative;
ddns-update-style none;
#################################################
### Generic Network to appease DHCPD
###
###
subnet 172.16.0.0 netmask 255.255.248.0 {
authoritative;
deny client-updates;
deny unknown-clients;
range 172.16.0.200 172.16.0.201;
}
##################################################
### Site 1
###
###
failover peer "failover" {
secondary; # declare this to be the secondary server
address 172.16.0.7;
port 647;
peer address 172.16.16.7;
peer port 647;
max-response-delay 30;
max-unacked-updates 10;
load balance max seconds 3;
}
##### CM Pool ######################################
subnet 172.16.16.0 netmask 255.255.248.0 {
pool{
range 172.16.16.11 172.16.20.0;
option domain-name-servers 12.127.16.68,12.127.16.67;
option routers 172.16.16.10;
option tftp-server-name "172.16.16.7";
next-server 172.16.16.7;
server-name "172.16.16.7";
option broadcast-address 172.16.23.255;
default-lease-time 86400;
max-lease-time 86400;
option time-offset -25200;
option time-servers 172.16.16.7;
allow members of "cm";
deny unknown-clients;
# filename "gold.bin";
# option bootfile-name "gold.bin";
}
}
##### CPE Pool ######################################
subnet 172.20.16.0 netmask 255.255.248.0 {
pool{
failover peer "failover";
range 172.20.16.11 172.20.20.0;
option domain-name-servers 12.127.16.68,12.127.16.67;
option routers 172.20.16.10;
option broadcast-address 172.20.23.255;
default-lease-time 86400;
max-lease-time 86400;
deny members of "cm";
deny dynamic bootp clients;
}
}
########################################
### QOS groups
###
###
group "gold" {
filename "gold.bin";
option bootfile-name "gold.bin";
}
[/code]
Secondary [master]:
[code]
omapi-port 9991;
key omapi_key {
algorithm HMAC-MD5;
secret "**************";
};
omapi-key omapi_key;
class "cm" {
match if substring(option vendor-class-identifier,0,6) = "docsis";
spawn with option agent.remote-id;
}
failover peer "failover" {
primary;
address 172.16.16.7;
port 647;
peer address 172.16.0.7;
peer port 647;
max-response-delay 30;
max-unacked-updates 10;
load balance max seconds 3;
mclt 1800;
split 128;
}
##### CM Pool ######################################
subnet 172.16.16.0 netmask 255.255.248.0 {
pool{
range 172.16.16.11 172.16.20.0;
option domain-name-servers 12.127.16.68,12.127.17.71;
option routers 172.16.16.8;
option tftp-server-name "172.16.16.7";
next-server 172.16.16.7;
server-name "172.16.16.7";
option broadcast-address 172.16.23.255;
default-lease-time 86400;
max-lease-time 86400;
option time-offset -25200;
option time-servers 172.16.16.7;
allow members of "cm";
deny unknown-clients;
# filename "gold.bin";
# option bootfile-name "gold.bin";
}
}
##### CPE Pool ######################################
subnet 172.20.16.0 netmask 255.255.248.0 {
pool{
failover peer "failover";
deny dynamic bootp clients;
range 172.20.16.11 172.20.20.0;
option domain-name-servers 12.127.16.68,12.127.17.71;
option routers 172.20.16.1;
option broadcast-address 172.20.23.255;
default-lease-time 86400;
max-lease-time 86400;
deny members of "cm";
}
}
group "gold" {
filename "gold.bin";
option bootfile-name "gold.bin";
}
[/code]
sadly I do not have the answer to your question, your best bet would be to create a ticket with the maintainers and wait for it to be addressed.
We have not found either DHCPD's or Cisco CNR's failover to our liking they all seem to be missing something.
What we are testing right now is using heartbeat/drbd and a virtual ip to do our failover.
i.e. have /etc/dhcpd.conf and /var/lib/dhcp/dhcpd.leases on a drbd partition , then have heartbeat monitor the dhcp service, if it fails on the primary it mounts the drbd partition on the backup server takes over the virtual IP and starts dhcpd. On your cmts you point your Cable helper address at the virtual IP.
This way in the event of a dhcp failure your backup picks up where your primary left off using the same conf and leases files. when your main server is back alive it can pick up where the backup left off since they are using the same files.
i think that might be the best solution the more I think about it. It also solves the problem of mirroring over dynamic host decs (made through omapi), and cleans up some issues with tftp, ect.
Do you have heartbeat enabling/disabling the virtual interface as well?
yes it enables and disables the virtual interface as well.
We use that setup for all of our mail services currently and it works very well.