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:45:31 -05:00
parent 76e703e218
commit 8c258064c1
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 ## Managing Scopes
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. One 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. 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.