Multiple ACK Issue
Leigh Porter
leigh.porter at ukbroadband.com
Wed Apr 2 17:02:50 UTC 2014
So similar issue. I think that with failover, both servers are allowed to respond to a request for an existing lease. However, I though the backup would only respond if it has lost comms with the primary (i.e. the failover link had died and so the backup peer thought the primary was dead). However, this is not what we both seem to observe.
--
Leigh
From: dhcp-users-bounces+leigh.porter=ukbroadband.com at lists.isc.org [mailto:dhcp-users-bounces+leigh.porter=ukbroadband.com at lists.isc.org] On Behalf Of Joey D.
Sent: 02 April 2014 17:36
To: dhcp-users at lists.isc.org
Subject: Multiple ACK Issue
Below is my pastebin link to a text diagram of what we witness is happening in the event of a device reboot of a previously connected device (meaning the device is already established in the leases db on both servers), as well as our failover config. Is there a configuration directive that can be used which mandates that only the server sending the offer can send the ACK? (much like what is done when allocating a fresh lease like in sec 3.2 in the rfc). I can detail a bit more as to the environment layout if necessary, but I'm hoping there is an option I'm simply overlooking.
http://pastebin.com/xvBXxz6P
Regards,
Joey D.
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
______________________________________________________________________
This email has been scanned by the Symantec Email Security.cloud service.
For more information please visit http://www.symanteccloud.com
______________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20140402/4ea588d8/attachment.html>
More information about the dhcp-users
mailing list