[Kea-users] Kea not sending NAK

Thomas Andersen than at itu.dk
Tue Mar 1 12:00:18 UTC 2016


Hi Marcin,

Yes, we just confirmed that KEA is doing the right thing.
Kea is sending a NAK with boots unicast flag to relay (HP) and the relay is sending the NAK to the client also with boots flash unicast, but to the ff:ff:ff:ff:ff:ff instead of the client mac, as it does with al the other packets/cases we have.

So now I’ll start “fighting” HP on this one :)


Br,
Thomas



On 01/03/16 12:52, "Marcin Siodelski" <marcin at isc.org> wrote:

>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