Pi-hole redundancy setup sanity check

Help
1

I somewhat recently set up a second pi-hole to update the first pi-hole that I had been running for a while (it's still on stretch). Both have DHCP server enabled.

The 1st pi-hole has a static IP of 192.168.1.246.
The 2nd pi-hole has a static IP of 192.168.1.210.

From what I have found when searching a 2 pi-hole setup is that the range of IP addresses to hand out should not overlap.

So for the 1st pi-hole, the range of IP addresses to hand out is from 192.168.1.201 to 192.168.1.235. The 2nd is from 192.168.1.236 to 192.168.1.251.

Now here's where I'm a little confused. Since the first pi-hole has a static IP address of 192.168.1.246, would there be any sort of conflict, since that IP is in the range of the second pi-hole of IPs to hand out? And vice-versa with the 2nd pi-hole?

Things seem to be working and both pi-holes are resolving clients DNS requests, but I can't help but feel like I'm missing something here.

Thank you in advance.

Debug Token:

1st pi-hole debug token is: https://tricorder.pi-hole.net/CUveVASB/
2nd pi-hole debug token is: https://tricorder.pi-hole.net/VxiCbqGT/

2

Manually configured static IPs should always be outside of any DHCP pool range, regardless how many DHCP servers you run.

While DHCP itself would attempt to avoid address conflicts via DAD, so a client would reject an IP address that is already taken, you'd still lose an IP address from the pool, which may be a scarce resource.

If they aren't in your case, you may simply reserve your Pi-hole machine's IP in the respective other's DHCP server, just to be safe (IP assignments can be outside of the DHCP pool range, as long as they stay in your network's address range).

3

Ah, I see! Makes sense. Thank you for the explanation.

Is there a way to edit the "Range of IP addresses to hand out" section via CLI? I tried updating the DHCP pool range for each pi-hole to not include the other but editing and clicking save doesn't seem to update the ranges via the admin console for the 1st pi-hole.

4

According to your debug logs, you already have succeeded doing so:

*** [ DIAGNOSING ]: contents of /etc/dnsmasq.d

-rw-r--r-- 1 root root 495 May  3  2022 /etc/dnsmasq.d/02-pihole-dhcp.conf
   dhcp-range=192.168.1.201,192.168.1.235,24h

*** [ DIAGNOSING ]: contents of /etc/dnsmasq.d

-rw-r--r-- 1 root root 495 Jul 26 15:38 /etc/dnsmasq.d/02-pihole-dhcp.conf
   dhcp-range=192.168.1.236,192.168.1.251,24h
5

If still looking for a safe way via the shell:

$ sudo nano /etc/pihole/setupVars.conf
[..]
DHCP_START=10.0.0.20
DHCP_END=10.0.0.254

Save/exit, run below and select "Repair":

pihole -r

EDIT: The quick and dirty way :wink:

$ sudo nano /etc/pihole/setupVars.conf
[..]
DHCP_START=10.0.0.20
DHCP_END=10.0.0.254

$ sudo nano /etc/dnsmasq.d/02-pihole-dhcp.conf
[..]
dhcp-range=10.0.0.20,10.0.0.254,24h

$ pihole-FTL --test
dnsmasq: syntax check OK.

$ pihole restartdns
  [✓] Restarting DNS server
1 Like
6

Yup, this is what I had initially. Maybe I misunderstood your response:

I was going to update 1st pi-hole DHCP pool range to 192.168.1.211 to 192.168.1.227 (since 2nd pi-hole IP address is 192.168.1.210) and the 2nd pi-hole to 192.168.1.228 to 192.168.1.245 (since 1st pi-hole IP address is 192.168.1.246).

But upon saving the new pool range for the 1st pi-hole, nothing changed, hence my second question.

7

This did the trick!

Thank you deHakkelaar, much appreciated.

1 Like
8

Since you are sacrificing more IPs from the pool range than necessary, my previous recommendation would apply:

1 Like
9

Got it. I updated.

I see errors in the [ DIAGNOSING ]: contents of /var/log/lighttpd step where the 2nd pi-hole is mentioned. Maybe this is related to the 1st pi-hole being out of date, maybe this is a nothingburger, I'm not sure. I posted new debug logs.

2nd pi-hole, I don't see anything alarming, but added those logs just in case.

1st pi-hole: https://tricorder.pi-hole.net/VGzwA0pK/
2nd pi-hole: https://tricorder.pi-hole.net/WuT3DSGt/

10

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.