DHCPNAK query
Friesen, Don SSBC:EX
Don.Friesen at gov.bc.ca
Tue Mar 23 13:47:38 UTC 2010
>Thank you for the vital information.
>I was debugging this issue and i found
>that nak_lease do not unicast. Also i was
>not receiving any request packets from the
>remote subnet client. Which makes sense
>because REBIND is not happened.
>Do u see that this is the expected behaviour.
From times prior to our implementing ISC
DHCP, when we used Sun's old NIS+ based
service, we port mirrored our DHCP servers
to a sniffer to log the DHCP traffic. This
helped us see things like when customers
installed their own DHCP servers that were
responding on the remote subnets (and then
complain that our DHCP servers weren't
working). I mention that because it held
clues to debugging what was happening to
the NAKs.
Prior to 4.1.1 we would see a unicast
REQUEST come in at t1 (RENEW) from the remote
client, and have it logged both on the sniffer
and the DHCP server that received it. The
DHCP server would log a NAK and then hang.
The NAK would not appear on the sniffer.
This was due to the bug in 4.1.0 that was
fixed in 4.1.1.
Unfortunately I can't tell you exactly what
the behaviour of 4.1.1 is, but I expect that
the sniffer would log a local broadcast NAK
in response to the unicast REQUEST. The
unicast REQUESTs and broadcast NAKs would
continue throughout the renewal interval
until t2 (REBIND) when the client would switch
to a broadcast REQUEST, and the relay agent
would step in to relay the request.
Nak_lease would then reply to the relay agent
with a NAK that would reach the client.
The reason I can't tell you what happens
with 4.1.1 is that my copy includes a unicast
NAK patch (which ISC does not recommend using).
Don.
More information about the dhcp-users
mailing list