I am looking to migrate my PiHole to a new host. I have the new machine set-up (currently 192.168.0.4) with PiHole running in Docker, and am ready to switchover from the old host (192.168.0.2).
My PiHole is also my DHCP server (due to router limitations around DNS), and so to seamlessly switch without having to force each client to renew their DHCP leases, I ideally also need to port over ALL of the DHCP lease information from the old host. At that point the new host will be moved to 192.168.0.2 and takeover all of the DHCP and DNS responsibilities.
The issue I'm hitting is that teleporter only restores the static DHCP assignments, and not the also the active DHCP lease table. I understand why this could be desirable, but it's not what I want in this case.
I see that the current DHCP lease table is exported as dhcp.leases, but manually copying the contents of that file over the dhcp.leases of my new host and restarting PiHole didn't seem to populate the table. That may be because the DHCP server of the new host is currently disabled though?
Has anyone managed to achieve this, and if so, how did you do it?
Thanks!
What's your actual requirement here?
Why would you want to carry over active leases?
If you swap out your DHCP server, DHCP clients won't be affected immediately.
They will continue to use the IP address of their existing lease until it expires, attempting to renew their existing lease before it does (typically after half their leasetime).
Dynamically allocated DHCP leases are volatile by design, i.e. it is to be expected that -subject to availability- the same MAC may be assigned a different IP address from the pool when requesting or renewing a lease.
If you absolutely must have the same IP being assigned to a MAC, then you'd have to create a DHCP lease reservation/static DHCP lease for that MAC.
Yes, I understand that. My goal is to avoid the new DHCP server handing out an IP address that the old DHCP server already had (because it doesn't know it was in use), and ending up with two devices with the same IP address until the old lease expires. It's not that I want everything to have a fixed IP address forevermore.
I could meet that requirement by assigning a static address for each of my 25+ devices, but that is an annoying solution.
I suppose the safest way might be to reduce the DHCP pool on the old DHCP server (currently .10-.199) to something like .10-.99, wait 24 hours (my current lease time), and then set the new server to use .100-.199. That would avoid any conflict between the two, and devices would move to the new range naturally as their leases expired.
Then you could try to swap DHCP servers at a time where your DHCP clients have recently renewed or requested a lease, keeping the same pool range.
When a DHCP client attempts to renew its lease, it will start by sending a unicast DHCPREQUEST for its current IP address to the DHCP server's IP that it has acquired its lease from.
In your case, the DHCP server IP will stay the same, so your new Pi-hole DHCP server will receive the DHCPREQUEST for the IP the client actually holds, and likely acknowledge it - provided the requested IP lies within Pi-hole's pool range.
But if you'd configure your new Pi-hole DHCP server with a different pool range than your existing one, Pi-hole would have no choice but to reject that IP with a DHCPNAK.
You can verify that behaviour, e.g. by sending a DHCPREQUEST for an IP to your aspiring DHCP server currently at 192.168.0.4
with a tool like dhcping while monitoring your pihole.log
, with your Pi-hole's pool range configured to include or exclude the requested IP.
I guess my concern isn't so much about the clients already on the network (as they will likely request and be granted the same IP, as you say), but a new device joining the network during the period where the new DHCP server is still building its active leases table.
In that situation couldn't the new server assign an IP that another client could already be using?
In that case, carrying over and reusing dhcp.leases
may do what you want.
Just make sure that file is current, as pihole-FTL
/dnsmasq
would prune any leases that have expired.
You should verify that expiry times are all in the future (first field in each line from dhcp.leases
). date -d @<expiry-timestamp>
may come in handy.
Not if the host thats using an IP already responds to a ping:
$ man dnsmasq
[..]
-5, --no-ping
(IPv4 only) By default, the DHCP server will attempt to enβ
sure that an address is not in use before allocating it to
a host. It does this by sending an ICMP echo request (aka
"ping") to the address in question. If it gets a reply,
then the address must already be in use, and another is
tried. This flag disables this check. Use with caution.
1 Like
Ahhh, I think that's what I missing 
I had assumed that the DHCP server would treat its known allocations as the absolute authority over the IPs assigned from its DHCP pool range, and not perform any additional checks against them potentially being used.
If it also performs a ping before handing out the IP address, then I think that alleviates my concerns. Existing leases will persist until they need to renew, at which point they'll likely get back the same IP they were given by the old DHCP server, and any new leases will be sanity checked using a ping to verify the IP likely isn't being used right now.
Thanks!
1 Like
Just to follow-up and say that the migration went fine. The new server picked up the DHCP leases as they renewed (and most renewed immediately), and I had no issues with IP conflicts. The DNS resolution was a little slow initially, but that settled down after a 10+ minutes or so.
I've kept my old machine around as a backup just in case, but this has let me migrate PiHole and Wireguard onto a single server, and upgrade from a 5 year old Raspbian install 
2 Likes