DHCP Static Mappings



  • We are having a problem with some of our static mappings.  The network design is not ideal as a previous administrator did not have the knowledge to manage our layer 2 switches. Now we are in a precarious position of having a /23 network, distributing addresses from one half of the scope using dhcp and setting reservations for the other half. 172.24.44.0/23 is the network on the interface. DHCP distributes 172.24.44.50-254.  Static reservations are made to place certain PCs that require a particular policy in the 172.24.45.0/23 half of the scope.  This works for some clients but not all.  The static mapping will be placed but the client will still pull the old 172.24.44.x address.  I did just trying listing all the DHCP leases and finding the "expired, offline" lease and deleting it manually.  The client was then able to pull the proper 172.24.45.x address assigned via a static mapping. Why are all of the expired, offline leases staying in the table? I've read some other threads on this issue but I did not get a clear answer.  I have some PCs that are having this issue but the mapping shows as expired, online. Even though the PC is no longer on the network.  Please advise on this strange behavior.


  • LAYER 8 Global Moderator

    Well if what you want is 2 vlans of /24 each - why don't you just do that??



  • @rmessina:

    Why are all of the expired, offline leases staying in the table? I've read some other threads on this issue but I did not get a clear answer.

    That is the behavior of dhcpd. 
    You could also try forcing the client to relinquish its IP before requesting a new one.
    On windows clients:
    ipconfig /release
    followed by
    ipconfig /renew

    –A.



  • Actually, this is a change in behavior. On 2.0 when you selected a DHCP client and reserved it an address, "cleanup" was done (I don't know the details of "how" it was done, but it observably worked) so that the client got the reserved address without further intervention.

    On 2.2.4 you have to manually track and kill the prior in-pool reservation.

    The 2.0 behavior was considerably more intuitive to work with when reserving addresses.


Log in to reply