Cutlery/gravity-sync
1
0
Fork 0
mirror of https://github.com/vmstan/gravity-sync.git synced 2025-07-09 02:34:06 -04:00
Code Issues Packages Projects Releases Wiki Activity

Updated DHCP Replication (markdown)

Michael Stanclift 2022-05-03 16:44:53 -05:00
parent 7d75f0dc3c
commit 76e703e218
1 changed files with 21 additions and 11 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
DHCP-Replication.md

@ -1,12 +1,18 @@
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. 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.
## Managing Scopes ## Managing Scopes
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. Once advantage of FTLDNS/DNSMASQ is that it allows static DHCP assignments 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.
### Example Network ### Example Network
For the sake of explanation, we'll use a standard class C subnet that can be found in most home or small business networks. 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` * Subnet: `192.168.1.0/24`
* Router: `192.168.1.1` * Router: `192.168.1.1`
@ -19,13 +25,15 @@ The network has around 50 devices on it that need IP addresses. We'll breakup th
* Split Scope 1: `192.168.1.100-192.168.1.149` * Split Scope 1: `192.168.1.100-192.168.1.149`
* Split Scope 2: `192.168.1.150-192.168.1.199` * 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.
## Shared Scope ## Shared Scope
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. 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. **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 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. 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. 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.
@ -33,15 +41,17 @@ There is no disruption to user services.
## Split Scopes ## Split Scopes
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. 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`. **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. 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.
Since other devices aren't connecting directly to Michael's iPhone anything, there is only a brief disruption to Michael. This time Pi-hole 1 responds, with an address of `192.168.1.100` from it's local scope, for the iPhone to use.
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**. 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**.
## Additional Considerations ## Additional Considerations