Failover and duplicate DHCPACKs

[Kimmo Liikonen]

Hi,

Thanks for replies.

On Thu, Feb 25, 2010 at 12:55 AM, David W. Hankins <dhankins at isc.org> wrote:
> On Sat, Feb 20, 2010 at 09:32:27AM +1100, Glenn Satchell wrote:
>> Looking at the log files in the first case with failover, the client
>> goes through the discover/offer/request/ack cycle. 30 minutes later
>> (half the lease time) it renesw using a request/ack. Then at the 60
>> minute mark it goes through a discover/.. cycle again. The odd thing
>> is that the renewals are going via the dhcp relay - renewals are
>> unicast so they should go directly from the client to the dhcp
>> server.
>
> Just an idea - if the servers are getting the renewals via the
> relay (or rebinding for that matter) it could be that one of the
> servers on the relay agent's forward list doesn't have a consistent
> idea of the network(s) that are appropriate for that relay agent's
> giaddr...

that relay is a Cisco router, and it "captures" also unicast dhcp
traffic. That's feature
and cannot be turned off. And router doesn't have state information
about "active"
DHCP server for that lease.

> So the client could be getting a DHCPNAK from some server (maybe an
> old one you migrated away from ages ago?), and that will also cause it
> to go back to DHCPDISCOVER more or less right away.

No, i know that client isn't getting DHCPNAK (DHCP servers logs). Client just
gets two DHCPACKs.

Maybe RFC says that duplicate ACKs from servers are okay, but that doesn't
mean that every client really can handle duplicate ACKs (stateful
firewall could
drop the wrong ACK?).

I  am wondering that why ISC DHCP server works differently with some other
clients?

It doesn't send duplicate ACKs to some clients, because it says that lease is
owned by peer:

"Feb 17 13:57:14 dhcp2 dhcpd: DHCPREQUEST for 111.111.111.111 (2.2.2.3)
from ff:ee:dd:cc:bb:aa via 1.1.1.1: lease owned by peer"

Unfortunately I don't have packet captures..

BR,

Kimmo Liikonen