DHCP server, duplicate forwards from VRRP'd relays

[Bob Harold]

On Tue, Oct 31, 2017 at 1:07 PM, Tim DeNike <tim at denike.us> wrote:

> Normally you want both to actively forward requests and receive
> responses.  In the case that you might have ARP inspection or something of
> the sort enabled on the routers.  Both routers need to know the servers
> response.
>
>
>
> On Tue, Oct 31, 2017 at 1:00 PM, Brennan,Andrew <andrew.brennan at drexel.edu
> > wrote:
>
>> Ok, so I've looked for what I think I'm looking for in the dhcpd.conf man
>> page and can't find it.  But, I might have something in mind that doesn't
>> exist - not sure.
>>
>> I have two NAT appliances forwarding my client DHCP discover/requests to
>> the server and the server - having no configuration otherwise - replies to
>> both with corresponding offer packets, etc.  Seems like overkill to me and
>> I've opened a case with the vendor to see if I can't configure only the
>> active router do the relaying -- but I had a thought that my server *could*
>> be configured to know that both relays are doing the same job and that it
>> only needs to respond to one of those requests (or prefer one over the
>> other, etc.).
>>
>> Is there a corresponding configuration that I haven't figured out yet?
>> Or is this something that doesn't exist (yet) in the realm of the ISC
>> DHCPD?  And, lastly ... if it doesn't exist as an option, would this be a
>> useful option/feature for the server?
>>
>> Thanks!
>>
>> andrew.
>>
>>
I think that is the way it is expected to work.  That has the least
complications for servers or routers "remembering" and "detecting" when
other things respond or fail to respond.  We have two routers on each
subnet (HSRP) and two DHCP servers in failover, so the clients get four
responses to a discover, and the client chooses which one it wants (usually
just takes the first).  Its a lot of traffic and logs (hitting Splunk) but
that's the way it is.
You might look at KEA to see if it will act differently.

-- 
Bob Harold
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20171031/dda2a844/attachment.html>