Dnsmasq - DHCP failure fallback server


#1

I’ve seen several topics about using two pi-holes to serve up DHCP replies and the suggestions for getting them to work together without conflict. None of them seem really optimal to me but they are workable. Given that, look at this as more of a discussion starter than an actual request someone start writing code.

Looking at the ISC DHCP server, it offers a failover option that looks interesting, particularly the problem section. Getting something similar in Dnsmasq is not likely but possibly something to accomplish some of the functionality could be added to the pi-hole software, not modifying Dnsmasq code.

A simple first thought is to have a primary and fallback DHCP option/setting for pi-hole that picks the type of DHCP service that that pi-hole will provide.

The primary would work just as the current setup does.

The fallback would normally be disabled to avoid conflicts. A daemon or cron job could check the availability of the primary DHCP server and if it appears dead could enable the fallback DHCP server and disable it if the primary again appears to be working. The primary “server down” checks would not need to be frequent given the DHCP renewal process but primary “server up” checks should probably be much more frequent to keep from having the two servers running at the same time.

Both could offer the same pool of addresses, not trying to manage duplicates, instead depending on the client performing an ARP check to make sure the address is not being used by another client and reporting any conflicts back to the server.

Not forcing a client to change IP addresses to ones in a different IP pool avoids the issues mentioned at the ISC link.

If that proves workable then possibly the teleporter code could be leveraged to insure the settings between the two stayed in sync? Possibly even disabling user input on the fallback server and only populating from the primary.

If someone wants to experiment using just the cron start/stop options it appears that the webpage script offers a DHCP enable/disable command.


#2

ISC DHCP server offered failover capabilities, i use that and it works great

/etc/dhcpd.conf for primary DHCP server

authoritative;
ddns-update-style none;

failover peer “dhcp-failover” {
primary; # declare this to be the primary server
address 192.168.200.2;
port 647;
peer address 192.168.200.3;
peer port 647;
max-response-delay 30;
max-unacked-updates 10;
load balance max seconds 3;
mclt 1800;
split 128;
}

subnet 192.168.200.0 netmask 255.255.255.0 {
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.200.255;
option routers 192.168.200.1;
option domain-name-servers 192.168.200.1;
pool {
failover peer “dhcp-failover”;
max-lease-time 1800; # 30 minutes
range 192.168.200.100 192.168.200.254;
}
}

Backup

/etc/dhcpd.conf for secondary DHCP server

authoritative;
ddns-update-style none;

failover peer “dhcp-failover” {
secondary; # declare this to be the secondary server
address 192.168.200.3;
port 647;
peer address 192.168.200.2;
peer port 647;
max-response-delay 30;
max-unacked-updates 10;
load balance max seconds 3;
}

subnet 192.168.200.0 netmask 255.255.255.0 {
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.200.255;
option routers 192.168.200.1;
option domain-name-servers 192.168.200.1;
pool {
failover peer “dhcp-failover”;
max-lease-time 1800; # 30 minutes
range 192.168.200.100 192.168.200.254;
}
}


#3

The ISC DHCP server isn’t integrated into the pi-hole system as Dnsmasq is so while the failover option (linked in my first post) it offers works it may not be great for everyone. For folks it will work for it is a solution that is working now, not needing a new pi-hole feature.