DHCP transactions per second

[Ian Anderson]

Thank you for the detailed reply.  Based off the information you
explained duplicated broadcasts from clients does cause additional load
on the dhcp server.  If I receive 4 DHCPDISCOVERS from 1 client, the
dhcp server will respond with DHCPOFFERS for all of those, reserving 4
ip addresses.   One of those OFFERS is followed by a DHCPREQUEST and
finally an ACK.  

In short, DHCP is reserving 4 ip's addresses three of which have 2 min
lease times, which will eventually expire.  The last IP address is
assigned to the client in a normal fashion.  Does this pretty much sum
it up?

-----Original Message-----
From: dhcp-users-bounce at isc.org [mailto:dhcp-users-bounce at isc.org] On
Behalf Of Simon Hobson
Sent: Monday, June 18, 2007 11:15 AM
To: dhcp-users at isc.org
Subject: Re: DHCP transactions per second

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 
about.


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 
version.

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.