[6.49.18] DHCP relay don't fowrard NAK response from DHCP server

there is a network configured in Mikrotik and configured a DHCP relay for that network. The DHCP server is a openwrt dnsmasq.
The problem is very trivial and simple to reproduce:

  1. DHCP leased an IP address to a client in that network successfully. It is a static leased IP address which means that the MAC address is bounded to that specific address and each time the client always get the same IP address.
  2. I changed the IP address assignment of that client in the DHCP configuration.
  3. I force the client to renew its IP address before it is expired. In general, the client send a request to extend the leasing time to its original IP address.
  4. The DHCP server response with a NAK “address not available” (because the original address is not bounded to it anymore). Mikrotik also received this DHCP response (confirmed with package capture)
  5. The DHCP relay DOESN’T forward that NAK to the client. ( I can verify it with the counter of “request” and “response” at the DHCP relay webgui, the “request” keep increasing but no count on “response” )
  6. The client cannot get the new address and remains to the old address as it don’t have any response from the DHCP server.

I believe there is a bug in the DHCP relay in mikrotik that it doesn’t implement the forwarding of DHCP NAK to the client. This is a huge drawback in IP address management aspect as the change of the IP address need to be wait until the target IP address expires.

Which MT device is running DHCP relay? Which ROS version is running on said device?

You could verify that DHCP relay is indeed “eating” DHCP NACK responses by running /tool/sniffer (with filters appropriate set) on said MT device … if everything is fine, you should see DHCP packets at least twice (once on ingress interface and once on egress interface).

Yes, I also conducted the packer sniffing on router so I can verify the DHCP NAK is ate by the Mikrotik. I have the same config on RB4011iGS+, 750G r3 and RB960PGS version 6.49.18, and all of them exhibit the same behavior

If it’s indeed bug in DHCP relay, then it’s highly unlikely to get it fixed in ROS v6.

So what I’d do is to upgrade one of devices (the expendable one) to v7 (7.19.1 at this time) and see if DHCP relay in v7 behaves equally wrong (IIRC there were some entries related to DHCP in change logs … I didn’t pay close attention though). If it does, then open a support ticket about this problem. If it doesn’t, then … well, you’ll have your answer to the problem :wink: