• I noticed that the IPs given out by the DHCP server is "sticky", that they are not static, but tends to stay the same whenever the client reconnects. Is there a way to force the DHCP server to recycle the IP's not in use? Otherwise the DHCP server just keeps giving out higher numbers.

    I frequently fiddle with the network and would love to keep all the hosts within a close group of IP's within the DHCP ip range.


  • Not that I'm aware of. It's ISC dhcpd, might want to search to see what's possible with it.

  • LAYER 8 Global Moderator

    what is your lease time?  Lease if not released correctly on the client side would continue to be there until the actual lease expires.

    So for example if you have lease time of 1 day..  And client gets lease at say 9am, and then disconnects from network without actual release of the lease.  Then that lease would be held until 9am the next day..  If the client comes back before 9am he should get his old IP back.  Keeping in mind that the lease time would refesh to 24 hours if client is on for say 50% of lease time – so if client was on for 12 hours from when he first got the lease, he would then renew it and clock would be reset to 24 from that renewal time.

    Lower the lease time to say 1 hour or something.  This should free up the leases earlier - now not sure if isc dhcpd will recycle that or just continue to walk through the unused leases before getting back to the other IPs that are no longer in use and don't have lease on them.


  • Depending on use - for a site with mostly the same users, just reserve them addresses (in the pool or out of it) and they will stay put. I use a pool, but assign non-pool addresses to known users, which helps to make unknown users more visible, and known users easier to account…

    For a site with a small number of variable users, use a smaller pool. But that does not sound like what you are doing.

    But, for a site with a small number of pretty much the same users, a smaller pool also works.

    IME the usual behavior (quasi-static in the pool) is more useful than not. But the benefits of setting them up DHCP-Reserved-static (easily done right from Status/DHCP Leases in 2.0.2) is huge if you are not running something like an airport hotspot with mostly transient customers. Even if you haven't sorted out which computer is which, you can assign them to invariant addresses, which makes checking the opposite direction and rearranging easier.

    My networks (on NAT) recently went from /24 to /18 and /24 to /22 to deal with the explosion of accessories that want an IP address - I used to have a pool the size of my userbase and room to spare in a /24. The /18 is probably overkill, but I didn't want to go back and re-do it.  If you make sufficient space in the NAT, it's easy to have a pool that's large enough for whatever you haven't reserved an address for, and room for all your users/devices reserved, and (if you don't have the sort of policy that forbids devices you don't know the address of from any use of the network - in which case you don't need much of a pool either) space to reserve the ones you have yet to determine which or who's they are that isn't your more logically arranged space.