Insert delay in dhcp3-relay ?

[Simon Hobson]

José Queiroz wrote:

>Shouldn't the clients still be bound to the 
>secondary server when they reboot with a valid 
>lease? If I understood the documentation, in 
>this case, instead of broadcasting to find a new 
>lease (and server), they'll unicast to the last 
>server...

On reboot they will probably broadcast.

The idea is that if you are already connected to 
a network, and have a valid lease, then you 
already have a working IP setup - thus you can 
unicast to the server for a renewal.
At any time you are bringing up an interface 
(booting, waking from sleep, responding to a 
cable plugged in, etc) then you may not be on the 
same network as you were and so should assume you 
might not be. In that case you should broadcast 
your request so that if you are on the wrong 
network you can be taken care of (if the request 
isn't acceptable then the server should reply 
with a NAK so you know the address no longer 
valid).

Some OSs short-circuit the system a bit. Instead 
of just assuming the system may be on a different 
network they will check - typically by doing an 
ARP request for the previous default gateway. If 
you have the same gateway, on the same MAC, 
responding to the same IP address, then it's a 
fairly safe bet you are still on the same network 
- and so carry on using the existing lease.

It's for reasons like this that it's important to 
look at what is supposed to happen, not just 
observe what a limited set of clients/servers do. 
For example, the Microsoft DHCP server isn't RFC 
compliant, but in an all-Windows network you may 
not notice that since the clients sort of do some 
of the work.

-- 
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.