Static ARP entries overwritten intermittently upon link-down when dhcp client enabled

Hello,

I've tracked down some unusual intermittent behavior. When a static ARP entry is configured on an interface and the static ARP entry is not a part of the same subnet as the returned DHCP lease, the static ARP entry will intermittently be removed from the configuration (blanked out/ shows as 00:00:00:00:00:00 in webfig.)

(Yes, static ARP is usually a terrible idea and all the reasons to avoid it are valid, however in this case we are working around other equipment behavior problems that we can't fix--and it works fine until we hit this bug)

Anyone familiar with any workarounds to this? I suspect it's a bug especially with the intermittent behavior.

Conditions:
DHCP Client must be enabled

  • Static ARP entry for different IP subnet but same MAC address as DHCP default gateway
  • A significant volume of traffic is required to replicate this issue reliably. The traffic must be destined to a route that utilizes this ARP entry although it does not have to be to the exact host of the ARP entry
  • RouterOS 7.19.4 or 7.15.3 on RB5009UG+S+ (other versions not tested yet)

Other factors:

  • Turning off DHCP client options does not help. Turning off peer DNS/NTP does not help. Turning off Add default route does not help.
  • Issue does not happen when the same IP handed out by DHCP is configured as static instead of being received from DHCP
  • The MAC address never restores and the configuration loses the MAC address of the entry

Steps to reproduce:

/ip dhcp-client
add add-default-route=no interface=ether4
/ip arp 
add address=48.0.49.49 interface=ether4 mac-address=F0:9F:C2:64:B4:68
/ip route
add disabled=no distance=1 dst-address=48.0.49.49/32 gateway=ether4 routing-table=main suppress-hw-offload=no
[user@mikrotik] /ip/route> /ip dhcp-client print 
Columns: INTERFACE, USE-PEER-DNS, ADD-DEFAULT-ROUTE, STATUS, ADDRESS
2 ether4     no            no                 bound   48.0.1.101/20   

After adding this configuration, then generate traffic from another device through another routerboard interface, but generate a decent volume.
#ping -s 1400 48.0.49.49 -c 50 -i 0.05 -f

Then, repeatedly bounce the ether4 interface link from the other end (I used a script to log into the adjacent device and enable/disable every minute)

After 2-10 minutes the /ip arp section will now read as below, missing the MAC address:

/ip arp
add address=48.0.49.49 interface=ether4

This bug is still present in RouterOS 7.21.1