Multiple ACK Issue

[jobewan]

     In our environment, multiple ACKs are causing an issue.  We have 
our servers setup in 2 different geographic regions, and there is a DHCP 
proxy in-line near the client site.  The issue is that the anti-spoofing 
mechanism in the dhcp-proxy always picks up on the 1st ack to make it 
back, which is always going to be 'Server A' (due to the latency b/t the 
regions); although 'Server B' is sending the offer.  This in turn causes 
issues for the client that is wanting an IP address from Server B.

Is the double ACK an expected behavior on a reboot?  The RFC on 3.1 says 
"If the client already knows its address, some steps may be omitted", 
which indicates that this should potentially follow the process noted in 
3.2 (showing both servers sending an ACK). Although, during a reboot, 
the client doesn't know it's ip address and follows a simple DORA which 
would indicate it would use the process in 3.1 (meaning only 1 server 
sends an ACK)

(also, sorry for the double post, It appeared that my initial mail was 
caught by a spamfilter).

- Joey D.


On 04/02/2014 11:16 AM, Leigh Porter wrote:
>
> I see a similar issue with a similar config, however the duplicate ACK 
> is not on the initial request but for lease renewals.
>
> I've not bothered investigating so far as it seemed to do no harm for 
> now..
>
> --
>
> 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:04
> *To:* dhcp-users at lists.isc.org
> *Subject:* Multiple ACK Issue
>
>  Below is a 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.
>
>
>               Server A        Client          Server B
>
>                 v               v              v
>
>                 |               |              |
>
>                 |     Begins initialization    |
>
>                 |               |              |
>
>                 | _____________/|\____________ |
>
>                 |/DHCPDISCOVER  | DHCPDISCOVER\|
>
>                 |               |              |
>
>                 |               |              |
>
>                 |               |  ___________/|
>
>                 |               | /DHCPOFFER   |
>
>                 |               |/             |
>
>                 |     Selects configuration    |
>
>                 |               |              |
>
>                 | _____________/|\____________ |
>
>                 |/ DHCPREQUEST  |  DHCPREQUEST\|
>
>                 |               |              |
>
>                 |               |              |
>
>                 |               |              |
>
>                 |\_____________ | ____________/|
>
>                 |      DHCPACK \|/ DHCPACK     |
>
>                 |               |              |
>
>                 |    Initialization complete   |
>
>
>
> SERVER A:
> stash-agent-options true;
>
> failover peer "iah-kcm" {
>       primary;
>       address x.x.1.248;
>       port 647;
>       peer address x.x.2.248;
>       peer port 647;
>       auto-partner-down 121;
>       max-response-delay 120;
>       max-unacked-updates 10;
>       load balance max seconds 5;
>       mclt 3600;
>       split 128;
>
> }
> server-identifier x.x.1.248;
> ping-check false;
>
>
> SERVER B:
> stash-agent-options true;
>
> failover peer "iah-kcm" {
>
>       secondary;
>       address x.x.2.248;
>       port 647;
>       peer address x.x.1.248;
>       peer port 647;
>       auto-partner-down 121;
>       max-response-delay 120;
>       max-unacked-updates 10;
>       load balance max seconds 5;
> }
> server-identifier x.x.2.248;
> ping-check false;
>
>
> - 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
> ______________________________________________________________________
>
>
> _______________________________________________
> 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/20140402/596d971f/attachment-0001.html>