Feature Request: VRRP L2 Keep-alive for Unmanaged Switch Environments

RouterOS General
1

Hello MikroTik Team,

I am using VRRP for WAN high availability with two RouterOS devices connected to an unmanaged switch, which is a common setup for many users.

I have observed that this configuration leads to significant unicast flooding of inbound WAN traffic to the backup router.

Root Cause:
The issue is caused by the switch's MAC address table entry for the VRRP virtual MAC timing out. This happens because outbound NAT'd traffic uses the router's physical MAC address, so there is no traffic being sourced from the virtual MAC to keep the switch's table entry refreshed.

Current Workaround:
I have successfully solved this by implementing a scheduled script on the master router that sends a simple ping to the ISP gateway every 2 minutes. This forces traffic to be sourced from the virtual MAC and keeps the switch's MAC table entry alive, completely stopping the unicast flooding.

Feature Suggestion:
While the script works, it would be a fantastic enhancement to build this functionality directly into the VRRP interface settings. I would like to request a new option, something like:

  • L2 Keep-alive: yes/no

  • Keep-alive Interval:

When enabled on an interface, this feature would automatically cause the master VRRP router to periodically send a small L2/L3 packet (like an ARP request for its gateway or a gratuitous ARP) sourced from the virtual MAC address.

Benefit:
This would make RouterOS's VRRP implementation more robust and user-friendly "out of the box," especially for users who may not have the expertise to diagnose unicast flooding or implement scripting workarounds. It would prevent performance and security issues on backup routers in these common hardware scenarios.

Thank you for considering this suggestion.

2

This is actually known as gratuitous ARP, and it's not actually the correct behavior to send it in on a keepalive basis (periodically), however the correct behavior would be to issue one (usually, several with a small delay) whenever an interface actually starts speaking with that MAC address.

If it's not so, document it and submit it as a bug. it should be done so.

3

I'm guessing GARPs are being sent out from the VRRP IF but because the virtual MAC isn't used as a source for normal outbound traffic, there is no activity to refresh the switch's MAC table. After the timeout (e.g., 5 minutes), the entry expires, which is what causes the L2 unicast flooding.

4

I also encountered a similar issue.
The problem persists even when using managed switches.
In my case, VRRP is used for the internal perimeter.
I solved the problem using a script that periodically sends a Gratuitous ARP packet to all VLANs using VRRP on a router with VRRP.

Policy: read test sniff

:foreach i in=[/interface vrrp find] do={
  :if (([/interface vrrp get value-name=running $i]) && ([/interface vrrp get value-name=master $i])) do={
    :local id [/interface vrrp get $i vrid]
    :local n [/interface vrrp get $i name]
    :local v [/interface vrrp get $i interface]
    :local ips [/ip address find where interface=$n]
    :if ([:len $ips] > 0) do={
      :local ip [/ip address get [:pick $ips 0] address]
      :local p1 [:find $ip "."]
      :local b1 [:pick $ip 0 $p1]
      :local p2 [:find $ip "." ($p1 + 1)]
      :local b2 [:pick $ip ($p1 + 1) $p2]
      :local p1 [:find $ip "." ($p2 + 1)]
      :local b3 [:pick $ip ($p2 + 1) $p1]
      :local p2 [:find $ip "/" ($p1 + 1)]
      :local b4 [:pick $ip ($p1 + 1) $p2]
      :local h "0123456789abcdef"
      :local a ([:pick $h ($b1 / 16)] . [:pick $h ($b1 % 16)] . [:pick $h ($b2 / 16)] . [:pick $h ($b2 % 16)] . [:pick $h ($b3 / 16)] . [:pick $h ($b3 % 16)] . [:pick $h ($b4 / 16)] . [:pick $h ($b4 % 16)])
      :local m ("00005e0001" . [:pick $h ($id / 16)] . [:pick $h ($id % 16)])
      :local c ("ffffffffffff" . $m . "08060001080006040001" . $m . $a . "ffffffffffff" . $a . "000000000000000000000000000000000000")
      /tool traffic-generator inject interface=$v data=$c
    }
  }
}