DHCP transactions per second
Ian.Anderson at clearwire.com
Mon Jun 18 19:54:19 UTC 2007
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
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
>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
>to the other 3?
Essentially, nothing happens to them.
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
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