DHCP Failover Issue – Standby Server Responding When It Should Not

Hi wellyhartanto,

The only reason the standby host would be issuing new leases is because the failover state has changed, which only happens when connectivity over TCP 647 is broken - no matter how briefly.

Superficially, it sounds like you're dealing with the first state transition of "communication interrupted", which in turn is not lasting long enough to progress to the "partner down" state.

While you would expect to see events 20254 and/or 20255, the key event to look for is 20252.

If you're running packet traces, look for any reason that traffic from/to the standby host over TCP 647 would fail. Given you have a firewalls on both sides, this might manifest as resets (RST) being sent to either or both hosts, or, as you already mentioned, it could just be it's taking too long to receive a TCP reply (which encompasses planned activities such as host reboots, firewall reboots, etc.).

Timings aren't explicitly enumerated in the Microsoft documentation but it doesn't really matter since this only works where connectivity is entirely trustworthy. If it's not, then what you're seeing is an absolutely expected outcome.

Relevant documentation:

• DHCP Failover Examples | Microsoft Learn
• DHCP Failover Settings | Microsoft Learn
• DHCP Failover Events and Performance | Microsoft Learn
• draft-ietf-dhc-failover-12 (This RFC died, making this a bit harder to find).

Cheers,

Lain