[Kea-users] Kea not sending NAK
Marcin Siodelski
marcin at isc.org
Tue Mar 1 11:52:51 UTC 2016
So it sounds that Kea is doing a right thing, which is what makes me
happy. :-)
As for the relay agent behavior the relevant section of the RFC2131 says:
"If 'giaddr' is 0x0 in the DHCPREQUEST message, the client is on
the same subnet as the server. The server MUST
broadcast the DHCPNAK message to the 0xffffffff broadcast address
because the client may not have a correct network address or subnet
mask, and the client may not be answering ARP requests.
Otherwise, the server MUST send the DHCPNAK message to the IP
address of the BOOTP relay agent, as recorded in 'giaddr'. The
relay agent will, in turn, forward the message directly to the
client's hardware address, so that the DHCPNAK can be delivered even
if the client has moved to a new network."
So it seems that your relay agent may be doing a wrong thing, but maybe
it is configurable?
Marcin
On 01.03.2016 10:33, Thomas Andersen wrote:
> Hi Marcin,
>
> Sorry if I’m confusing you with the description. I’m getting confused myself. :)
> But I have verified that the relay (HP switch) is sending the NAK to ff:ff:ff:ff:ff:ff as a mc/bc.
>
> From wireshark on the client we are receiving:
> Destination: Broadcast (ff:ff:ff:ff:ff:ff)
> .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
>
> Kea is sending unicast to the relay.
>
> Funny thing is that OFFER packets are sent correctly as unicast to the client mac address from the relay.
>
> Br,
> Thomas
>
>
>
>
>
> On 01/03/16 10:24, "Marcin Siodelski" <marcin at isc.org> wrote:
>
>> On 29.02.2016 14:58, Thomas Andersen wrote:
>>> Hi Marcin,
>>>
>>> Thanks for the reply.
>>>
>>> I actually already did that just now, and now i see that the dhcp
>>> server IS sending a NAK, but is never received by the client.
>>> It is sending the response to the mac address (which it should since
>>> the requested ip is not valid).
>>>
>>> However, on our wireless equipment there is a broadcast/multicast
>>> filter which is stopping that packet. (Client can send mc/bc to the
>>> AP, but not the other way around).
>>>
>>> But why is the NAK sent as a mb/bc packet to ff:ff:ff:ff:ff:ff and not
>>> the client MAC (unicast) as in a dhcp OFFER? I currently use a HP
>>> procurve 5412 as dhcp relay. The mac dat mac address in the packet
>>> sent from the server is the procure mac address, which then broadcast.
>>>
>>
>> In the environment with relays the server should unicast the DHCPNAK to
>> the relay's IP/MAC address and the relay then forwards the packet to the
>> client's MAC address. What you're describing here is that the Kea server
>> is sending a DHCPNAK to the bc address and ff:ff:ff:ff:ff:ff? Or, is
>> this a relay agent that forwards the DHCPNAK to bc?
>>
>> Marcin
>>
>>> Br,
>>> Thomas
>>>
>>>
>>>
>>>
>>> On 29/02/16 14:38, "Marcin Siodelski" <marcin at isc.org> wrote:
>>>
>>>> Thomas,
>>>>
>>>> The server is expected to return a DHCPNAK to the renewing client which
>>>> "ciaddr" contains an address which is invalid for a subnet it is
>>>> connected to. By renewing client I understand a client which doesn't
>>>> include "server-ip" and doesn't include "requested-ip", per RFC2131
>>>> section 4.3.6.
>>>>
>>>> Since you said that your client sends "renew packet with a requested
>>>> address" it sounds that your case is rather an INIT-REBOOT case, when
>>>> the client remembers previously allocated address after a reboot. Such
>>>> client includes "requested IP address" to verify that the previously
>>>> allocated address is still valid. In the INIT-REBOOT case it is possible
>>>> for the server to ignore the client's message if the server has no
>>>> record of the client (RFC2131, Section 4.3.2):
>>>>
>>>> " If the network is correct, then the DHCP server should check if
>>>> the client's notion of its IP address is correct. If not, then the
>>>> server SHOULD send a DHCPNAK message to the client. If the DHCP
>>>> server has no record of this client, then it MUST remain silent,
>>>> and MAY output a warning to the network administrator. This
>>>> behavior is necessary for peaceful coexistence of non-
>>>> communicating DHCP servers on the same wire."
>>>>
>>>> I am wondering if this is the situation you hit in your testing?
>>>>
>>>> It would be useful if you enabled "NAKs logging" to see what the server
>>>> says when it discards the packet.
>>>>
>>>> This may be useful to see how to configure the NAK logger:
>>>>
>>>> http://kea.isc.org/docs/kea-guide.html#idp54421264
>>>>
>>>> Something like this should work....
>>>>
>>>> "Logging": {
>>>> "loggers": [
>>>> ....
>>>> {
>>>> "name": "kea-dhcp4.bad-packets",
>>>> "severity": "DEBUG",
>>>> "debuglevel": 99
>>>> }
>>>> ]
>>>> }
>>>>
>>>> Marcin Siodelski
>>>> ISC
>>>>
>>>> On 29.02.2016 11:12, Thomas Andersen wrote:
>>>>> Hi,
>>>>>
>>>>> In my kea testing, i find that if a client is sending a renew packet
>>>>> with a requested address that is not valid for the selected network, it
>>>>> just ignores the packet instead of sending a NAK. This means the client
>>>>> keep sending renew packets because the previous is timed out.
>>>>>
>>>>> Can this be configured to send NAK, or have i misconfigured something?
>>>>>
>>>>> --
>>>>> Med venlig hilsen / With best regards
>>>>> Thomas Andersen
>>>>>
>>>>> Systems and Network Administrator
>>>>>
>>>>> IT University of Copenhagen
>>>>> Rued Langgaards Vej 7
>>>>> 2300 København S
>>>>>
>>>>> Phone: +45 72185249
>>>>>
>>>>>
>>> ____________________________________________________________________________
>>>>>
>>>>> **NEVER DISCLOSE YOUR PASSWORD OR SHOE SIZE - NOT EVEN TO YOUR
>>> DENTIST**
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Kea-users mailing list
>>>>> Kea-users at lists.isc.org
>>>>> https://lists.isc.org/mailman/listinfo/kea-users
>>>>>
>>
More information about the Kea-users
mailing list