I have had several discussions lately relating to the recycling of abandoned leases in Infoblox DHCP (which is based upon ISC dhcpd). There seems to be a common misunderstanding about how the process works.
To recap, an abandoned lease occurs when the DHCP server encounters one of the following situations:
- A client is attempting to obtain a new lease (via DHCPDISCOVER) and the DHCP server receives an ICMP echo reply (ping response) from the IP address that the DHCP server is attempting to offer
- The client sent a DHCPDECLINE message to the DHCP server indicating that it is rejecting the acknowledged address (usually because the client received an ARP reply for the address it has been leased)
Abandoned leases give the DHCP server some knowledge about addresses within its DHCP ranges that are potentially occupied by other devices. It could be that someone has mistakenly hard-coded an address that conflicts with an address within a DHCP range (e.g. a printer), or the DHCP server may not have any knowledge of previous leases that have been issued if a migration is taking place from one DHCP server to another.
In the migration scenario, abandoned leases can occur when a new client comes onto the network before all the existing clients have had a chance to renew their leases, e.g. a laptop user might move onto a particular subnet and when the DHCP server attempts to find a new IP address it receives an ICMP echo reply because there is already a client using that lease (and that client hasn’t reached the 50% renewal interval yet so does not appear in the new DHCP servers’ lease database). So it is quite normal to see some abandoned leases during a migration and these can be easily cleared using the Infoblox GUI if required (although this is strictly not necessary).
However, it is not normal to expect an administrator to check for abandoned leases during normal use, so what happens if abandoned leases occur in a stable environment where no migration is occurring? It generally happens due to misbehaving clients – there have been reports of Apple devices using a “rapid DHCP” mechanism that can cause abandoned leases to occur, similar problems have been reported with Android clients, and also PC’s that offload their ARPs to the network card while asleep.
It is really not acceptable to expect an administrator to keep clearing out abandoned leases to ensure there are enough free addresses in the DHCP ranges for legitimate clients to use, so what happens when all the available leases have been consumed by abandoned leases?
What should happen is that when the DHCP server has run out of free/available leases, it will start to reclaim and recycle abandoned leases. So long as nothing is responding to the ICMP echo request (ping), the DHCP server will offer these abandoned leases out to clients. However, the DHCP server will still issue a ping to check that the abandoned lease is indeed free, and if it receives a response, it still cannot offer it. So if every abandoned lease responds to a ping, then the DHCP server will not allocate them, and this is when you will find that clients cannot obtain a lease (people start complaining they can’t access the network). Your solution is either to expand the DHCP range or try and shut down the clients that are responding to the pings. If you find that the culprits are misbehaving clients, then you may have to investigate fixes for them, either by applying patches or simply by banning them from the network (you can use MAC address or vendor class filters on Infoblox to create a “deny” list to stop these clients accessing the network).
In the following screen shot you can see that the DHCP server successfully reclaims an abandoned lease (192.168.0.181) in response to a DHCPDISCOVER and offers it to a new client:
Something else to note, whilst doing a migration, is that if a legitimate clients’ lease does get abandoned because the lease database has not been populated yet, when that client renews at 50% of the lease time, the DHCP server will reclaim the abandoned IP and will reply with a DHCPACK – remember, because the client sends a DHCPREQUEST at lease renewal time and not a DHCPDISCOVER, there is no ping check involved, so the address won’t get abandoned again simply because the legitimate client is responding to pings.
You can see this behaviour in the following screen shot, the abandoned lease on 192.168.0.181 was reclaimed when a DHCPREQUEST was received:
There is a useful ISC DHCP PDF document available here that might be worth a read if you have an interest in DHCP.
About Paul Roberts
