Why leases are not renewed always via dhcp-relay ?
s.cramatte at wanadoo.fr
Fri Jul 6 18:26:41 UTC 2007
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:
> 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
More information about the dhcp-users