Multiple ACK Issue
Joey D.
jobewan at gmail.com
Tue Apr 15 17:46:39 UTC 2014
I'm still looking for any/all input regarding this issue. Is there a
different mailing list that would be more appropriate for this?
On Wed, Apr 9, 2014 at 12:05 PM, Joey D. <jobewan at gmail.com> wrote:
> bumping this into the dhcp-hackers list in hopes of a response.
>
> - Joey D.
>
>
> On Mon, Apr 7, 2014 at 11:49 AM, Joey D. <jobewan at gmail.com> wrote:
>
>> 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<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 listdhcp-users at lists.isc.orghttps://lists.isc.org/mailman/listinfo/dhcp-users
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-hackers/attachments/20140415/47f60fbc/attachment-0001.html>
More information about the dhcp-hackers
mailing list