Why leases are not renewed always via dhcp-relay ?

[Simon Hobson]

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.
>>
>>  
>Might be an Iptables rules ?  to block direct communication from client
>to server ?

No.

It is RFC compliant behaviour that a client with 
an existing lease will send a unicast packet 
directly to the server that gave it it's lease - 
there is no reason* to involve a relay agent for 
renewals because the client now has an address 
and so doesn't need this help. In any properly 
designed IP network this will be possible - but 
there are situations when it is not (for example 
a client which is behind a NAT gateway which 
would prevent the server from responding). 
David's comment was to make sure that the client 
and server can directly communicate - ie either 
can send packets directly to the other.

* Except for issues like this of course !

>  >> 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.
>>
>>  
>Do you mean to set  "server-identifier"  in dhcpd.conf to the  my
>dhcp-relay IP ?

Yes

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

>In these subnet I've got only 2 DNS redundant DHCP servers  to assign my
>public Ip's  and servers are connected to switch using Vlan's
>so no chance to join another DHCP server

It's a bit more complicated than that ! It's not 
just which servers the packets get to, but also 
how those servers perceive the packet got there.


I was under the impression that equipment that 
inserts option 82 also tends to have a dhcp 
sniffer function, so that even though the packet 
is unicast rather than using the relay agent, the 
equipment can intercept it and still insert 
option 82. It might be owrth checking if this is 
the case with your equipment as that would solve 
the problem for you.