Multiple ACK Issue

Joey D. jobewan at gmail.com
Mon Apr 7 16:49:07 UTC 2014


It looks like the last response/inquiry was not sent to the list. I'm 
sending it back through in hopes of getting additional feedback on my 
issue.  I'm still looking for info as to whether this is expected behaviour.

- Joey D.



On 04/04/2014 01:50 PM, Joey D. wrote:
>     I have tested this with numerous packet captures.  In every Packet 
> capture, there are 2 DISCOVERs, 1 OFFER (from 'Server B', indicating 
> the load-balancing algorithm is doing it's job), 2 REQUESTs (from the 
> client, with option 54 noting Server B), 2 ACKS with each server 
> sending their own option 54 address.
>
> This scenario does not occur if I wipe the lease data for that client 
> from both servers' lease tables;  this results in only 1 ACK from the 
> server listed in option 54 in the REQUEST (Server B).  Once that 
> works, if I reboot the client, we are back in the state of ACKS being 
> sent from both servers.  I can submit more data in a bug report if 
> necessary, but I'm not sure if this is a bug just yet...
>
> In the event of T2 timer, there is no option 54 info as mentioned.
>
> I included the email thread including additional data below (we use 
> split 128).
>
> Regards,
>
> - Joey D.
>
>
> On 04/04/2014 01:24 PM, Bruce Hudson wrote:
>>      My DHCP is a bit rusty these days but I would definitely not expect
>> multiple ACKs during a regular DORA. The request from the client should
>> include the server identifier of the offer it is accepting; and only
>> that server should process the request. That is part of the protocol.
>>
>>      If you are seeing multiple ACKs, either (1) the client is broken
>> and is not including a server identifier, (2) the servers are somehow
>> set to use the same identifier, or (3) the DHCP server is broken and
>> ignoring the identifier in the request. In the absence of packet traces,
>> I am inclined to assume one of the first two. Can you see a server
>> ACKing a client request that includes a different identifier?
>>
>>      A client can definitely broadcast a request without an identifier,
>> either during a reboot or at T2 as you suggest. In those cases I would
>> expect any server that sees the request to respond. You will see
>> multiple ACKs.
>>
>>      You did not say (or I missed) whether or not these two servers are
>> part of a redundancy pair or not. If they are, that might be the code
>> path that leads to ignoring the server identifier. On the other hand,
>> in that case I would expect the "split" statement to prevent both
>> servers from responding. Do you set the split to 255?
>> --
>> Bruce A. Hudson				|Bruce.Hudson at Dal.CA
>> ITS, Networks and Systems		|
>> Dalhousie University			|
>> Halifax, Nova Scotia, Canada		| (902) 494-3405
>
>
>
> On 04/04/2014 12:04 PM, Joey D. wrote:
>>     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-users/attachments/20140407/e5f97c20/attachment-0001.html>


More information about the dhcp-users mailing list