DHCP transactions per second

Simon Hobson dhcp1 at thehobsons.co.uk
Mon Jun 18 18:15:06 UTC 2007

Ian Anderson wrote:

>  >>> Or in other words, does dhcp know the difference between a normal
>  >>> broadcast and one that is a duplicate?

>  >> How can it ? They are simply relayed packets and will be identical
>  >> other than the GIAddr - there is nothing to say "this is a duplicate".

>If this is the case, and DHCP responds to every request it receives,
>what happens to the DHCPOFFER that are never ACK'd by the client. If
>DHCP transmits 4 DHCPOFFERS and a client ACK's one of them, what happens
>to the other 3?

Essentially, nothing happens to them.

short version
After the server sends an offer, it doesn't track it waiting for a 
request. IFF the client decides to accept an offer then it will make 
a request and the server treats that as a new transaction, if the 
client doesn't make a request that the offer is simply forgotten 

longer version
When a client sends a discover, the server will create a 'temporary 
lease' of 2 mins duration to track the resulting offer (you can see 
these in teh leases file). When it receives a request from the 
client, it will find an existing lease so it will send an ack and 
record the 'proper' lease. If the client doesn't make a request then 
the 2 minute lease will simply expire. If the server gets several 
discovers (such as in this case via different relay agents) then the 
second and subsequent ones will result in further temporary leases 
being created - but all the same and each one replaces the previous 

It is quite reasonable for more than one offer to be made by the same 
server (the client might be at the other end of a slow network and so 
send a new discover before it gets the first offer). It's also quite 
OK for a client to get offers from more than one server. If a client 
does get multiple offers, it is defined that the client is free to 
choose an offer based on whatever criteria it thinks fit and in 
theory this could include taking account of which offer gives the 
client the most/best set of options to use. In practice I think just 
about all clients simply take the first offer received.

I think the 2 minute temporary lease was just a simple way of 
tracking the offers made without having a separate mechanism - after 
all, the lease mechanism is already there so why not just use it.

I vaguely recall that the bug I mentioned was related to multiple 
discovers and failover - something like a second discover coming in 
before the first temporary lease had been propagated to the partner 
server. I think this might have resulted in several different offers 
being made, but as I say I can't recall any details.

More information about the dhcp-users mailing list