-
-
Notifications
You must be signed in to change notification settings - Fork 118
DHCP Replication
Starting in Gravity Sync 4, replication of static DHCP assignments is now supported.
This is handled by management of the 04-pihole-static-dhcp.conf file. There is no specific configuration work required for Gravity Sync to sync these static DHCP assignments, if you're using your Pi-hole as a DHCP server this file will exist, Gravity Sync will see it, and act accordingly.
If you're not using your Pi-hole to act as a DHCP server, this file will not exist and then Gravity Sync will skip over this step.
One advantage of Pi-hole's FTLDNS/DNSMASQ component is that it allows static DHCP assignments to use address ranges that are not part of their own dynamic pool. However before implementing redundant DHCP servers, you will need to think about how to lay out your DHCP assignments. DHCP replication with Gravity Sync should use what is outlined here as a shared/split scope architecture.
In this architecture, both Pi-hole systems are allowed to assign addresses that are replicated as part of the static assignments (the shared scope) but also to have a range of IP addresses that are unique to their side, AKA the split scope.
For examples here, we'll use a standard class C subnet that can be found in most home or small business networks.
- Subnet:
192.168.1.0/24 - Router:
192.168.1.1 - DNS 1:
192.168.1.10 - DNS 2:
192.168.1.20
The network has around 50 devices on it that need IP addresses. We'll breakup the network into a shared scope that both Pi-hole can assign static DHCP addresses from, and then each Pi-hole will have their own scopes.
- Shared Scope:
192.168.1.50-192.168.1.99 - Split Scope 1:
192.168.1.100-192.168.1.149 - Split Scope 2:
192.168.1.150-192.168.1.199
The split scopes are defined within the Pi-hole interface under Settings > DHCP > Range of IP addresses to hand out for each side. The shared scope are never explicitly listed in a range within the interface, but are individually assigned in the Static DHCP leases configuration part of the same page.
Devices that we want to have consistent IP addresses will need to be part of the Shared Scope, which will then be managed by Gravity Sync. You should put any devices on your network that you want to be able to lookup via name resolution within your local network, or that you want to always have the same IP. Streaming media devices, cameras, home servers, or other such hosts that provide services to other devices on the network.
Example: plex-server.home.net will be assigned 192.168.1.50. Anytime devices on the network want to stream from this Plex server they'll need to come back to this address so it should be consistent.
When a device comes online looking for an IP address, if it's part of this Shared Scope it will be assigned a consistent address by either Pi-hole acting as a DHCP server. When the client's DHCP lease comes up for renewal or expires, the client will reach out to the Pi-hole to attempt to renew it. Since it's part of the static lease pool, it will be told to continue using the same address.
If plex-server.home.net attempts to renew it's lease but the Pi-hole that it previously obtained it from is offline, it will send a broadcast to the network looking for the other Pi-hole. Since that Pi-hole has the same static lease data in it's configuration from the shared scope, it will continue to assign 192.168.1.50 to that device.
There is no disruption to user services.
Devices that exist on the network but do not generally serve data to other devices, need DNS lookups or static IP assignments, can obtain leases from either Pi-hole. An IOT sensor, smart watch/phone, guest devices, are some possible examples.
Example: Michael's iPhone joins the network, and sends a broadcast looking for an IP address from a DHCP server. Pi-hole 2 isn't busy, so it returns an address in it's scope of 192.168.1.150.
After a while, Michael's iPhone attempts to renew it's current IP address. It will first look for the original Pi-hole/DHCP server that assigned it. In this example Pi-hole 2 went offline after an SD card failure. Michael's iPhone will continue to use the DHCP address it was given but when the lease expires, if it still cannot reach Pi-hole 2, it will send another broadcast to the networking looking for another DHCP server to assign a new address.
This time Pi-hole 1 responds, with an address of 192.168.1.100 from it's local scope, for the iPhone to use.
Since other devices aren't connecting directly to Michael's iPhone, there is only a brief (if any) disruption to Michael.
**Note: **The individual Pi-hole scope leases are not part of the 04-pihole-static-dhcp.conf file, they are located in /etc/pihole/dhcp.leases and are not managed by Gravity Sync.
- Only devices that are part of the shared scope and have a static assignment will respond to local DNS requests by both Pi-hole. Otherwise only the Pi-hole that assigned the lease will know what the device's DNS address is.
- Make sure you disable DHCP on your router if you intend to use DHCP assignments via Pi-hole.
- Make sure you disable conditional forwarding on your Pi-hole if you're assigning addresses via the Pi-hole.
- The total number of devices that need IP addresses on your network should always be less than your shared scope + a split scope. In this example there are 99 IPs available for the 50 or so devices.
- Be mindful of devices that have static IPs defined on the clients themselves (they never request an address from DHCP) as you don't want to include the IP addresses for these devices in either your shared or split scopes.
You will want to make sure that the DHCP server on each Pi-hole is handing out both Pi-hole for DNS resolution. This can be accomplished by adding a .conf file to your DNSMASQ directory of each Pi-hole, with the line dhcp-option=option:dns-server,192.168.1.10,192.168.1.20