How a Broken Device Can Exhaust Your DHCP Server's IP Pool
An unusual way for your DHCP server to run out of dynamic IPs
I discovered a bizarre failure mode where a misconfigured device answered ICMP pings for every IP address on our network. Because the ISC DHCP server checks if an IP is free before assigning it, this 'screaming' machine tricked the server into thinking the entire dynamic pool was exhausted. Tracking down the culprit required tracing ARP tables, but luckily the device used its real MAC address, allowing us to identify and remove it quickly.
Today's new and exciting failure mode for a DHCP server handing out leases to dynamic clients: have something on your network that answers pings for absolutely every IP address.
- sargun
I accidentally took down our corporate network multiple times ~20 years ago, because I was setting up virtual networks with Linux machines acting as l2 bridges, and with proxy_arp to on. The DHCP server only checked for an arp reply, and I caused our server to run out of IPs. It had a cache and nobody knew how to clear it, so we just had to wait it out.
- no_carrier
I'm more interested to know about the endpoint that was responding to all IPs.
Also, minor nitpick:
> Without that we would have been reduced to tracing through switch ARP tables (for switches smart enough to report that)
You'd only need your switch to have a viewable mac address table rather than an ARP table.
- JasuM
Doesn't this mean that the broken device also answered to every ARP request? And wouldn't that break the network by itself, regardless of DHCP behavior?