dhcpd ddns request 1 sec timeout
Simon Hobson
dhcp1 at thehobsons.co.uk
Sat Jan 6 10:03:31 UTC 2007
Seiji T wrote:
> > The dhcp server is single threaded, so it blocks while the dns update
>> is done. If it waits too long it may miss other incoming dhcp requests.
>
>I understand that but then, why is 1 sec okay and not 2 sec? Why not 500 msec?
Design decision taken when the system was written ? I believe the
internal timer only works in whole seconds, so the minimum timeout is
1s.
> > If your incoming dhcp rate is pretty low then there should be little
>> harm in bumping the timeout up to two seconds. But really you should
>> look at your DNS infrastructure and see if there is a way to improve
>> it's response.
>
>Maximum possible rate will be like 7000 DHCP requests at once to 2
>dhcp servers.
I think you need to qualify that. What does 'at once' really mean,
because if they all come in one second then they aren't going to get
serviced ! I assume you are thinking in terms of "we have 7000
clients and if there's a wide area power cut then they'll all come up
at once". Firstly, how likely (or how often) is such an event, and
secondly, unless all the equipment is identical AND powers up
automatically, then there will be a spread of time. I would imagine
that the rate will follow something resembling a bell curve.
If you had the worst case where every client caused a dns update, and
they all failed or went close to the timeout, then a 1s timeout would
limit you to 3600 clients/hour - or about 2 hours to service all your
7000 clients. In practice, only a small percentage of client updates
should result in a dns update - if say 10% did, then the dns timeout
itself would impose a limit of more like 36,000/hour or about 12
minutes to service your 7000 clients.
This is one area you do have control over. If you set (say) 2 week
leases then you would need a wide area outage of at least a week
before you have a significant number of leases timing out - by that
time, taking a couple of hours to get all the clients back up is not
likely to be top of everyones list of issues !
>As you have suggested, we are planning to change our DNS
>infrastructure. Currently the DDNS server transfers full zone data to
>approx 20 secondary servers everytime DNS database changes.
That sounds like a bad dns design ! Why do you need so many servers ?
Even ISPs with several hundreds of thousands of clients tend to only
have 2-4 dns servers.
>We are thinking of relaying via a hub server which will then
>transfer the full zone data to the 20-something secondary servers.
>We thought of incremental zone transfer but we never done it before
>and decided that relaying to one server is safer.
What software are you using ?
Incremental transfers will reduce the amount of traffic and probably
reduce the time taken, it's low risk and common packages (like bind)
'just do it' automatically. Also, you could consider NOT notifying
the secondary servers and let them poll the master every few minutes.
I was under the impression that bind will rate-limit the number of
zone updates it does when there's a lot of updates, though I don't
recall any details.
>We are looking at other options and the purpose of this thread is to
>understand the rationale behind the 1 sec fix.
My guess would be that when this bit was written, the developers were
using bind for the dns and didn't have any problems with a 1s
timeout. Given that the dhcp server blocks while it's waiting, the
minumum is 1s, and there didn't seem to be any need to make it longer
- it just got set at 1s.
Beyond that, there's no magic in the 1s value !
It might help if you describe your setup and what you think your
problems are - ie the bigger picture. Chances are it's not too
different to what others have already done in the past and can give
helpful advice.
More information about the dhcp-users
mailing list