Correct Failover / DHCPOFFER functionality

[pat]

>You should see DHCPDISCOVER brosdcast to all dhcp servers. Each server
> should reply with DHCPOFFER.

If failover is enabled within a pair of DHCP servers why should both servers
respond to the DISCOVER with an OFFER.
only the server based on hashing should respond with an OFFER for a DISCOVER
isn't it ?

-Pat

On Thu, Jul 2, 2009 at 10:23 PM, David W. Hankins <dhankins at isc.org> wrote:

> On Thu, Jul 02, 2009 at 01:19:36PM +1000, Glenn Satchell wrote:
> > You should see DHCPDISCOVER brosdcast to all dhcp servers. Each server
> > should reply with DHCPOFFER. Client then chooses one of the offers and
> > does DHCPREQUEST to the chosen server. That server then replies with
> > DHCPACK.
>
> In "SELECTING" state the DHCPREQUEST message is transmitted to
> broadcast (because the client is not yet configured with an IP
> address nor a default route), and the packet is also broadcast during
> INIT-REBOOT although the client may or may not be configured (the idea
> is to ensure the reception of a NAK if the client has moved networks)
> depending on which restart-optimization was implemented (although
> usually the client is not configured as mobility is the safer
> assumption).
>
> It's after passing through BOUND that the RENEWING state DHCPREQUEST
> messages are unicast.  REBINDING state DHCPREQUEST messages are again
> broadcast so that other servers may be reached.
>
> In all of these, the only message where a client includes a server
> identifier option, to indicate which server it is selecting, is when
> it is in the SELECTING state.
>
> RFC 2131 is pretty mealy-mouthed on the subject of the server
> identifier option.  It reinforces that a server 'MUST be prepared to
> to accept any of its network addresses as identifying that server in a
> DHCP message', but never indicates a server is to drop messages if
> there is a server-identifier option that does /not/ match any of its
> network addresses.  So accepting all packets irrespective of server
> identifier fulfills this MUST, and doesn't go against any language
> normative or otherwise.
>
> So, many DHCP servers ignore the server-identifier field supplied by
> the client, including ISC's, and instead reply based upon whether or
> not the server is able to provide for the client's request; which
> depends greatly upon the current state of leases that may or may not
> be actively assigned to the client in question.
>
> --
> 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
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20090703/18c5a8b3/attachment.html>