<div>>You should see DHCPDISCOVER brosdcast to all dhcp servers. Each server<br>> should reply with DHCPOFFER. </div>
<div> </div>
<div>If failover is enabled within a pair of DHCP servers why should both servers respond to the DISCOVER with an OFFER.</div>
<div>only the server based on hashing should respond with an OFFER for a DISCOVER isn't it ?</div>
<div> </div>
<div>-Pat<br><br></div>
<div class="gmail_quote">On Thu, Jul 2, 2009 at 10:23 PM, David W. Hankins <span dir="ltr"><<a href="mailto:dhankins@isc.org">dhankins@isc.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="im">On Thu, Jul 02, 2009 at 01:19:36PM +1000, Glenn Satchell wrote:<br>> You should see DHCPDISCOVER brosdcast to all dhcp servers. Each server<br>> should reply with DHCPOFFER. Client then chooses one of the offers and<br>
> does DHCPREQUEST to the chosen server. That server then replies with<br>> DHCPACK.<br><br></div>In "SELECTING" state the DHCPREQUEST message is transmitted to<br>broadcast (because the client is not yet configured with an IP<br>
address nor a default route), and the packet is also broadcast during<br>INIT-REBOOT although the client may or may not be configured (the idea<br>is to ensure the reception of a NAK if the client has moved networks)<br>depending on which restart-optimization was implemented (although<br>
usually the client is not configured as mobility is the safer<br>assumption).<br><br>It's after passing through BOUND that the RENEWING state DHCPREQUEST<br>messages are unicast. REBINDING state DHCPREQUEST messages are again<br>
broadcast so that other servers may be reached.<br><br>In all of these, the only message where a client includes a server<br>identifier option, to indicate which server it is selecting, is when<br>it is in the SELECTING state.<br>
<br>RFC 2131 is pretty mealy-mouthed on the subject of the server<br>identifier option. It reinforces that a server 'MUST be prepared to<br>to accept any of its network addresses as identifying that server in a<br>DHCP message', but never indicates a server is to drop messages if<br>
there is a server-identifier option that does /not/ match any of its<br>network addresses. So accepting all packets irrespective of server<br>identifier fulfills this MUST, and doesn't go against any language<br>normative or otherwise.<br>
<br>So, many DHCP servers ignore the server-identifier field supplied by<br>the client, including ISC's, and instead reply based upon whether or<br>not the server is able to provide for the client's request; which<br>
depends greatly upon the current state of leases that may or may not<br>be actively assigned to the client in question.<br>
<div>
<div></div>
<div class="h5"><br>--<br>David W. Hankins "If you don't do it right the first time,<br>Software Engineer you'll just have to do it again."<br>Internet Systems Consortium, Inc. -- Jack T. Hankins<br>
</div></div><br>_______________________________________________<br>dhcp-users mailing list<br><a href="mailto:dhcp-users@lists.isc.org">dhcp-users@lists.isc.org</a><br><a href="https://lists.isc.org/mailman/listinfo/dhcp-users" target="_blank">https://lists.isc.org/mailman/listinfo/dhcp-users</a><br>
</blockquote></div><br>