Failover/load-balancing with dhcp client bug on “seconds elapsed” field
dan.r.duarte at gmail.com
Wed Apr 14 22:11:05 UTC 2010
We’re having a strange behavior on our network preventing several clients
from being served by a pair of servers working in failover. It seems that
the problem is related to a bug on the client that fails to increment the
“seconds elapsed” field on “request” messages. It only increments on the
“discovers”. I was hoping that you could suggest some workaround or
configuration change for this issue, because the update of all clients’
firmware might not be an immediate option.
This is our scenario:
- We need to give a static IP to our clients based on the option 82
location info received by the server;
- to do so we created matching classes, and pools with only one IP
available. On each on those pools we accept only one mach class;
- when the client sends the first Discover, dhcp0 ignores (I
believe he thinks it will be handled by its peer), but dhcp1 writes on the
log “peer holds all free leases” (I believe dhcp1 isn’t controlling this
- The client keeps trying and incrementing the “seconds elapsed”
field on the “discovers”. When it becomes greater than our configured “load
balance max seconds”, dhcp0 answers the request with the usual “offer”;
- The problem is when the client sends the “request”, because it
sends it with “seconds elapsed” = 0! The transaction id is the same, and all
the other parameters seem to be correct except this one.
- Dhcp0 ignores the request even that on the options the client
specifically states that he’s answering his offer.
To me it seems clear that the problem is the bug on the dhcp client, however
it looks like that the failover / loadbalancing is a lot dependent on the
good implementation of all the clients. Without failover this would work
perfectly, ignoring this bug.
Do you think there could be any workaround to solve this problem in the
Is dhcp0 working correctly when it ignores the “request” with
seconds-elapsed = 0?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the dhcp-users