Why leases are not renewed always via dhcp-relay ?

[David W. Hankins]

On Fri, Jul 06, 2007 at 04:27:41PM +0200, Sébastien CRAMATTE wrote:
> It's very strange ?

No, this is RFC2131 documented behaviour.  The easiest and best
thing to do is to make sure the server and client can unicast to
each other.

> I want to force to use  dhcp relay  in every case ... I need option 82
> datas so when a lease is renewed directly I loose these datas
> Any ideas or configuration tips ?

If the option 82 contents do not change from packet to packet, then
you can use the values that are 'cached' upon the lease state when
the client last operated through a relay.

This draft:

http://www.ietf.org/internet-drafts/draft-ietf-dhc-server-override-04.txt

which I think is working on becoming an RFC, was written for the case
where the server and client can under no circumstances directly speak
with one another (such as when the client is on a VPN the server can
not access).

The simple way to "do the same thing" is to configure a
dhcp-server-identifier equal to the relay agent's address.  Clients
will unicast their renews to this address.

However, this makes every client RENEW look, to the server(s), like a
REBIND.  So multiple servers may well answer, and they may well answer
with DHCPNAKs if they sense that the client is on the wrong subnet
(which may be incorrect depending on how the packet reaches the relay
and how the relay senses the interface the packet is received upon).

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins