Multiple ACK Issue
Joey D.
jobewan at gmail.com
Wed Apr 16 14:43:20 UTC 2014
Can you elaborate as to how you accomplished the dropping of the requests?
Is that an option or a script on the server?
On Wed, Apr 16, 2014 at 1:39 AM, Torppa Jarkko <jarkko.torppa at elisa.fi>wrote:
> I had similar problem on 3.x, at that time I tried to look at the code and
> did’nt see anything that would try to prevent sending duplicates. Some
> clients (juniper firewalls) don’t like it if they get response from a
> server that they did not specify.
>
>
>
> Fixed the issue by making path that drops the requests if our-id is not in
> the requests. As I red RFC at that time that would be the correct behavior.
>
>
>
> *From:* dhcp-hackers-bounces+jarkko.torppa=elisa.fi at lists.isc.org [mailto:
> dhcp-hackers-bounces+jarkko.torppa=elisa.fi at lists.isc.org] *On Behalf Of *Joey
> D.
> *Sent:* 15. huhtikuuta 2014 20:47
> *To:* dhcp-hackers at lists.isc.org
> *Subject:* Re: Multiple ACK Issue
>
>
>
> 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 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/20140416/6b788fff/attachment-0001.html>
More information about the dhcp-hackers
mailing list