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" <[email protected]> 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" <[email protected]> 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" <[email protected]> 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 >>>>>> [email protected] >>>>>> https://lists.isc.org/mailman/listinfo/kea-users >>>>>> >>> _______________________________________________ Kea-users mailing list [email protected] https://lists.isc.org/mailman/listinfo/kea-users
