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:46:12 -05:00
parent 86a896093d
commit 2785dcf733
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
DHCP-Replication.md

@ -6,7 +6,7 @@ If you're not using your Pi-hole to act as a DHCP server, this file will not exi
## Managing Scopes
One advantage of Pi-hole's FTLDNS/DNSMASQ component 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.
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.