Why the DHCP range sits behind every fixed place
A single device took a service down for minutes — not through a fault, but through an address. Here is how it happened, why the obvious fix is not enough, and which order removes the problem for good.
It was one of those faults you first take for coincidence: a service was no longer reachable, the interface would not load, and a few minutes later everything was fine again. No crash, no error message, no restart. The cause was an address handed out twice.
What happened
A device without a fixed address asks the network for one when it starts. The address server picks from its range and hands out the first one that looks free. The real problem: that range also contained addresses I had assigned by hand to devices that never ask for one.
To the server those addresses were free, because it never sees a request from a fixed device. So a device without a fixed address received exactly the address the service was already using. Two devices, one place. Whoever answers first wins — and that changes.
An example from practice
An example from my own setup: a media server had kept its address for months because it was configured manually. A new device joined the network and was handed the same address — it sat inside the DHCP range. For about twenty minutes the media server was unreachable, and nothing in the server's log pointed at the cause.
Cases like this are unpleasant because they happen rarely and look like coincidence. A device that worked yesterday is gone today, a restart sometimes helps — until next time. Once you know the cause, you stop searching the device and start looking at the address assignment.
Why this is possible at all
An address server only knows its own list. It has no idea that somewhere a device sits with an address typed into it by hand. As long as the two ranges are cleanly separated this is fine. The moment they overlap it is not — and it only shows up when a new device arrives and takes one of those addresses.
The obvious fix — and why it is not enough
The first reflex was to create reservations for the affected devices. That is better than nothing, but it only solves half the job:
- Reservations only apply to devices that ask for an address at all.
- Fixed addresses configured on the device itself remain unknown to the server.
- Every new device needs an entry, and a device that is switched off is hard to reserve.
- After a reset of the server the list is gone — the addresses on the devices are not.
Working that way means maintaining two lists describing the same thing. It holds as long as you are consistent, and breaks the moment a device shows up that you forgot about.
What I did instead
The answer is not extra technology but an order: fixed addresses come first, and the DHCP range begins after them. The two ranges now sit behind each other instead of on top of each other, and a device from the DHCP range cannot land on a fixed place at all.
What matters is not where exactly the boundary sits, but that it is written down — and that the fixed addresses really all lie below it. So the same step includes a check: after every change, reach each device individually and look at whether it holds the address the plan says it should.
Why the order alone is enough
Two separate ranges cannot overlap — that is not a matter of care but a property of the design. The DHCP range stays large enough for devices that need no fixed address, and the fixed places are where I expect them. A new device without a fixed address can no longer break anything, no matter how many are added.
What I take from it
- An address plan is only as good as its upkeep — the order removes the possibility of the fault instead of merely making it harder.
- After every change, check rather than trust: each device individually, not just the server.
- Ranges that exclude each other need no reservation lists to be maintained.
- Anyone who forgets a fault after a few minutes will not find the cause later — the cause goes on paper immediately.