From 86a896093d3be517e80d6caa218da66bf3d641a9 Mon Sep 17 00:00:00 2001 From: Michael Stanclift Date: Tue, 3 May 2022 16:45:49 -0500 Subject: [PATCH] Updated DHCP Replication (markdown) --- DHCP-Replication.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/DHCP-Replication.md b/DHCP-Replication.md index 8d39495..f79b3df 100644 --- a/DHCP-Replication.md +++ b/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 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 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. 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.