<div dir="ltr"><div class="gmail_extra">Hi Alp,</div><div class="gmail_extra"><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">We have setup a DHCP failover configuration, with Wireless LAN Controllers having multiple ip-helper-address statements. The controllers are Cisco and Aruba branded. As I understand it, Controllers relay DHCP discover messages to both DHCP servers, however sometimes we see different IP addresses are OFFERED for the same request by both DHCP servers. Is it the normal behavior?</blockquote></div><br>It is the expected behavior when the "sec" field in the DHCP client's message is grater than the "mclt" defined in the primary DHCP server. Or if the DHCP server are *not* in normal state. If that's not the case (both servers in normal state and "sec" < "mclt") both servers will receive the DHCP DISCOVERY message but only one of them will reply back with an offer. There's a thread describing a similar problem I had in this mail list, subject "DHCP Relay agent not forwarding messages to the client" first message from June 15.</div><div class="gmail_extra"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8000001907349px">Could you also point some documentation that I can read to understand how exactly failover works in ISC DHCP version 4.2.8? Especially how multiple discovery and request packets are handled from multiple ip-helper address statements.</span></blockquote><div><br></div><div>You can check out this link <a href="https://tools.ietf.org/html/draft-ietf-dhc-failover-12 and  ">DHCP Failover Protocol Draft IEFT</a> and this <a href="https://tools.ietf.org/html/rfc3074">DHC Load Balancing Algorithm RFC 3074</a>. Always keep in mind this tip which I got from another thread in this mail list:</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">The split *does not* determine the share of the pool. The pool is<br> *always* balanced 50/50. The split value determines which peer will<br> respond to the client based on the hashed value of the client<br> identifier (MAC address).</blockquote><div><br></div><div><br></div><div>Hope this helps!<br>Gero. </div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"></blockquote><blockquote style="margin:0 0 0 40px;border:none;padding:0px"></blockquote></div>