DHCP leases issue

[Simon Hobson]

Surya Teja <suryateja042 at gmail.com> wrote:
> Thanks for reply, Yes I can increase the scope range but i have clients like 100-120 per floor(per subnet) I don't think it would be good idea to increase its scope size to some /8 subnet  and over come this issues

You don't need to go to a /8, I was just illustrating that there is no shortage of private addressing available. it would be a bad idea anyway, very large pools increase the memory footprint and startup time for the DHCP server. You could either supernet 192.168.n.n addresses and use /23 or /22, or use the 172.16/12 space and subnet it to /23 or /22 to get plenty of space.

> Let me explain the scenario.

I understand fully the scenario - it's a common one.

> As suggested by Thomas I have added the statement one-lease-per-client true to config and till now I didn't see any issues but as it is not sure I am still observing the cases.

I would recommend against using that. Yes it "works", and will probably work without problem "most" of the time. But the fact that is mostly works OK is down to DHCP clients having been developed to cope with broken networks - with things like checking for duplicate addresses before re-using an existing lease on bringing up a network connection. Because "fixing" the problem by breaking the DHCP server will cause duplicate addressing given the level of churn your previous statements suggest.
Specifically: Client 1 moved from subnet A to subnet B, with one-lease-per-client set, the server will release the client's lease in subnet A. Client 2 joins subnet A, and depending on the level of churn may get the address previously leased to client 1. Client 1 now returns to subnet A, find that it has a valid lease for the network, but ... oops, that address is being used by someone else. There are clients around that will try to use the address and you'll get problems.
At the very least, by running with such a small DHCP pool size and roaming clients, you are forcing a lot of churn which isn't necessary.

If you were to switch to a /22 subnet, you could easily have a pool in the order of 1000 addresses per subnet - that would make the problem just go away unless many hundreds of clients all went on a roaming spree. In the long term, renumbering the network will be less hassle than dealing with the random failures you could see - I know it's a PITA, been there, more than once. Also dealt with supposedly knowledgeable network people who can't grasp anything other than a /24 !

BTW - are at least some of these clients using WiFi ? If so then be aware that having different subnets per floor may give you some "interesting" roaming issues. Clients could easily switch from an access point for "their" floor to another access point for the floor above or below. If they do this, then they'll switch subnet and all their connections will break.
How much of a problem this is depends on the application. Some will simply re-connect, others will break.