Why leases are not renewed always via dhcp-relay ?

[Sébastien CRAMATTE]

David W. Hankins escribió:
> 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.
>
>   
Might be an Iptables rules ?  to block direct communication from client
to server ?
>> 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 ?

> 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