-
-
Notifications
You must be signed in to change notification settings - Fork 130
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 additional 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 and Gravity Sync will see it and act accordingly. If you're not using your Pi-hole to manage DHCP, this file will not exist and then Gravity Sync will skip over this step.
You will need to think about how to lay out your DHCP assignments before using redundant DHCP servers. DHCP replication has been tested with Gravity Sync using a shared/split scope architecture. FTLDNS/DNSMASQ allows both Pi-hole systems to assign addresses that are listed in their static DHCP assignments, but also to have a range of IP addresses that are unique to their side.
For the sake of explanation, 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
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. These are 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 to 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.
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 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 interact with other devices via DNS or static IP assignments, can obtain leases from either Pi-hole.
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.
Later, Pi-hole 2 goes down for maintenance. When Michael's iPhone attempts to renew it's current IP address, it cannot reach the DHCP server. After a while the lease expires and since it still cannot reach Pi-hole 2 so it sends another broadcast looking for a new address. This time Pi-hole 1 responds, with an address of 192.168.1.100 for the iPhone.
Since other devices aren't connecting directly to Michael's iPhone anything, there is only a brief disruption to Michael.
- 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.