Inconsistent renews from F/O peers

[Mark Sandrock]

> On May 11, 2015, at 11:02 AM, Simon Hobson <dhcp1 at thehobsons.co.uk> wrote:
> 
> Mark Sandrock <sandrock at mac.com> wrote:
> 
>>     it sometimes happens that shortly
>> after obtaining an initial lease of MCLT,
>> (3600 seconds), some Windows clients
>> send a broadcast renew request that
>> is responded to differently by the two
>> failover peers.
> 
>> Although this seems incorrect behavior
>> on the switch'es part, the pathological
>> behavior of Windows renewing a lease
>> only 3 seconds into it, also seems wrong.
> 
> When this happens, do you have any indication how long it took to get the reply back to the client ?
> I'm wondering if a combination of factors (delay by the server, delay by the switch (I assume that the DHCP packets are being handled by the management CPU)) are leading to a delay at the client which is long enough for it to retry - hence the second renew after 3 seconds.
> 
> You may need to leave a packet capture running until you capture an event. IIRC there is a field (who's name escapes me at the moment) in the packet which indicates how long the client has been trying - if the first packet has 0 and the second has 3, then this would seem to support the hypothesis.

They got a packet capture today, which
is being sent to Cisco and Infoblox,
so I'll take a look at it.

But reportedly Cisco acknowledged
that the premature renew 3 seconds
after the initial lease is coming from
their own NAM client.

Thank you, Simon.

Mark