DHCP Relay agent not forwarding messages to the client

[Cuttler, Brian (HEALTH)]

I'd thought that the hash was used to determine which MAC addresses each of the DHCP servers would reply to in normal mode, with the 'other' server picking up the full load of the peer became unavailable.


-----Original Message-----
From: dhcp-users-bounces at lists.isc.org [mailto:dhcp-users-bounces at lists.isc.org] On Behalf Of dave c
Sent: Tuesday, June 16, 2015 3:42 PM
To: Users of ISC DHCP
Subject: Re: DHCP Relay agent not forwarding messages to the client

Referencing the RFCs that were posted earlier... what we are seeing here is how it's supposed to work. When the dhcp relay system doesn't opt to choose which server to relay requests to.

Absent some form of dhcp monitoring built into the router, the dhcp relay doesn't know which of the various relay systems will have available IPs or even which of them will be not too busy to handle the dhcpdiscover message it is relaying. As a result, it sends it to all dhcp relay hosts. The dhcp relay hosts, seeing a dhcpdiscover send an answer back, as they are supposed to. 
The client, accepts the first response it gets and completes the dhcp handshake and continues to talk to that dhcp server for future lease renewals.

The hash is to split the IP Pool space between the two servers, not to determine who the dhcp servers are allowed to talk to.

What I find odd is that the failover pair actually seeming to discuss between them who will respond to a local broadcast request in the direct connection mode. That actually seems odd to me. Normally all dhcp servers on the wire will answer unless one server is defined as authoritative.

Caused me no end of grief when someone would host a rogue dhcp server in a campus environment I ran back in the day.

Dave

On 6/16/15 14:16, Sean McMurray wrote:
> I have zero experience with dhcp failover, but I agree with Gero. They should not both make offers.
>
> If they are both making offers, what is the point of configuring them 
> in failover? You might as well set them up independent of each other and have them serve different pools.
>
> What am I missing?
>
> On 06/16/2015 08:18 AM, Gero Palacio wrote:
>> Hi There.
>>
>> What I find odd is that according to section 5.3 of this document 
>> IETF Internet Draft - DHCP Failover Protocol 
>> <https://tools.ietf.org/pdf/draft-ietf-dhc-failover-12.pdf> *only one* of the servers should respond to the DHCP offer. The other should discard it.
>>
>> I have tested this behavior with 2 computers connected on the same 
>> subnet as the DHCP servers (so no relay agent involved) and it works 
>> as described. Both servers receives the offer but only one of them 
>> responds with an offer. This is also back up by RFC 3074 DHC Load Balancing Algorithm <https://tools.ietf.org/html/rfc3074>:
>>
>>     _Section 4: _
>>     The proposal maps the STID into a hash value using the function in section 6.  The
>>     resulting hash value can then be used to decide who
>>     should respond to the request, or who the forwarding target should be.
>>
>>
>> So I don't why it's behaving the way it does when there's a relay agent involved.
>>
>> Thanks all for your help!
>> - Gerónimo.
>
>
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
>

--
Dave Calafrancesco
_______________________________________________
dhcp-users mailing list
dhcp-users at lists.isc.org
https://lists.isc.org/mailman/listinfo/dhcp-users