Skip to content

MikroTik VRRP and FastTrack: why one shared VRRP interface sent our router to 90% CPU

Our Lisbon edge runs a pair of MikroTik routers. VMs use VRRP gateways, so either router can take over if the other one dies. One day the busier router climbed from 60% to 90% CPU with no change in traffic, and FastTrack was barely working.

The symptom

FastTrack lets established connections skip the firewall and most of the routing work. On a busy gateway it is the difference between a calm router and a pegged one.

The FastTrack rule in the forward chain was matching ~180,000 packets per second. The global counter ipv4-fasttrack-packets was growing by only a few thousand. So connections were marked for FastTrack, but their packets still took the slow path.

The usual advice is wrong here

Search for this and you will read that "VRRP breaks FastTrack". It does not, at least not in our case. The second router also uses a VRRP interface, and it fast-pathed more than 99% of its traffic at the same time.

How to see it: rx vs fp-rx

RouterOS shows fast-path counters per interface:

/interface monitor-traffic [find where name~"VRRP"] once

Compare rx-packets-per-second with fp-rx-packets-per-second. On a healthy interface they are close. On ours, the VRRP interface that carried the VM gateways showed about 100,000 pps rx and 0 fp-rx. Every packet a VM sent to the internet arrived there and went the slow way.

One warning: fp-rx on an interface is not proof that forwarding is fast-pathed end to end. Check the per-connection counters too (orig-fasttrack-packets and repl-fasttrack-packets in /ip firewall connection). In one state we saw the VM-to-internet direction fixed while the reply direction stayed slow.

What was different

The broken interface was one VRRP interface holding the gateway addresses of many subnets at once. The healthy one carried a single subnet.

MikroTik's own MUM talk on underused and overused RouterOS features mentions a related case. A VRRP interface with the same subnet present twice creates a routing conflict, and the fast path stops working. We had leftovers like that on the shared interface, and we cleaned them up. That alone did not fix it.

The proof: move one subnet out

We moved one subnet's gateway to its own VRRP interface, for two minutes, with an automatic revert armed in advance. On its own interface, traffic for that subnet was fast-pathed 95% to 99% in both directions. On the shared interface it had been about 5%.

The fix

One VRRP interface per subnet (or per small group), with the matching backup on the second router. DHCP has to follow the gateway, so plan the DHCP server per interface before you move anything.

After the subnets were split across interfaces and routers, the router dropped from about 62% to 40-45% CPU on all cores, at the same traffic.

Things that bit us on the way

  • Re-binding the VRRP interface (/interface vrrp set X interface=... and back) can clear a stuck no-fast-path state for a while. It is not a fix: in our case the problem came back.
  • A new VRRP interface starts as BACKUP and waits for the master-down timer, so the first move costs several seconds of loss. Arm a dead-man revert before you test on a live router.
  • DHCP clients renew to the old server ID after a gateway moves. They fall back to broadcast at T2, so watch a full lease time before you decide it failed.

Checklist

  1. Run /interface monitor-traffic on every VRRP interface. A busy one with fp-rx near 0 is the problem.
  2. Compare the FastTrack rule counter with ipv4-fasttrack-packets over 10 seconds.
  3. Look for duplicate connected routes on the VRRP interface and remove stale addresses.
  4. If it is still slow, move one subnet to its own VRRP interface as a test, with an automatic revert.