Multiple ACK Issue

[Joey D.]

     I apologize if it's not proper etiquette to post the same issue to 
both mailing lists, but I'm looking for a bit of feedback as to whether 
what I'm experiencing is 'expected' behaviour from the isc dhcp 
software.  It looks as though myself and Leigh are both observing the 
same 'multiple ack' scenario, but it's a bit of a "muddy" explanation in 
the RFC as to whether both ACKs should present themself during a 
reboot/DORA (although I'd expect it to happen at a T2 timer).

- Joey D.


On 04/02/2014 12:48 PM, jobewan wrote:
>     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-hackers/attachments/20140404/ded5c30a/attachment.html>