Intermittent DHCPv4-server regression with VRRP and RADIUS static IP assignment (RouterOS 7.20.x vs 7.16.2)

RouterOS General
1

Device: CCR2116-12G-4S+
Architecture: arm64
Use case: ISP NAS (DHCPv4-server + RADIUS + VRRP)

RouterOS versions tested:

  • 7.16.2 (stable) — works reliably
  • 7.20.2 / 7.20.6 (stable) — intermittent issue observed

Configuration overview:

  • DHCPv4-server running on VRRP interface
  • use-radius=yes
  • Static IP assignment via RADIUS (Framed-IP-Address)
  • address-pool=static-only
  • Only one active DHCP server in the broadcast domain (verified)

Problem description:
On RouterOS 7.20.x DHCPv4-server works in general, but intermittently fails to assign
RADIUS-provided static IP addresses.

The following log message appears occasionally:
"dhcp,critical,error failed to assign ip : already in use"

At the same time, ARP table may contain stale or failed entries for the same IP address.
The IP address belongs to the same client MAC and no actual duplicate client or IP conflict exists.

The issue is not constant and does not affect all clients.
It is observed sporadically, most often after client reconnects or VRRP role changes.

Expected behavior:
DHCPv4-server should successfully assign a RADIUS-provided static IP address when
the IP/MAC binding already exists and no real conflict is present.
This behavior is observed consistently on RouterOS 7.16.2 under the same configuration and load.

Result / workaround:
After downgrading RouterOS from 7.20.x back to 7.16.2, the issue disappears completely.
The system operates stably with identical configuration and traffic conditions.

Conclusion:
This appears to be a regression introduced after RouterOS 7.16.x,
possibly related to DHCPv4-server conflict detection or ARP handling logic
in environments using VRRP together with RADIUS-based static IP assignment.

2

This is a user forum. If you want MikroTik to be aware of the issue, you should create a support ticket here:

With the content you posted.

3

Thanks

4

Agree on ticket, make sure to include a supout.rif when you do.

Also, could enable a higher logging on topics=dhcp to file and see what's actually going on when this happens. The DHCP server has a decent amount of logging. Perhaps a 2nd for topics=vrrp too, as I have a sneaky suspicion that's involved here (as there have been a number of changes/bug-fixes between 7.16 and 7.20, so one could have broken something when using VRRP as listener for DHCP).

5

Thanks for the suggestions.

Unfortunately I cannot enable extended DHCP / VRRP logging on the production routers,
as these devices are handling live ISP traffic and any additional logging or testing
may impact active customers.

In addition, reproducing this issue requires changing RouterOS versions
(upgrading again to 7.20.x),
which is not possible on production systems for the same reason.

The issue was observed on a production NAS under real load and traffic patterns.
After downgrading from RouterOS 7.20.x back to 7.16.2, the problem disappeared completely
without any configuration changes.

I understand that additional logs (dhcp, vrrp) and support.rif would be helpful.
I will try to reproduce this behavior on a test system when possible and will
open an official support ticket with MikroTik including all requested data.

Thanks for taking a look and pointing out the possible VRRP interaction.