Back to blog

MikroTik / RouterOS  ·  Tutorial  ·  July 2026

MikroTik
VRRP First-Hop Redundancy

Every device on the LAN points its default gateway at one router. Reboot that router and the whole network goes dark — even with a second router sitting right next to it, because the clients don't know it exists. VRRP gives the two routers one shared virtual gateway so the LAN never notices which is actually forwarding. This is the Cisco HSRP/VRRP post in RouterOS.

MikroTik RouterOS VRRP Redundancy Gateway

First-hop redundancy solves a specific fragility: the default gateway is a single IP, so it's a single point of failure no matter how many routers you own. VRRP (the open standard Cisco also implements, alongside its proprietary HSRP) fixes it by having two or more routers share a virtual IP and virtual MAC. One is master and forwards; the others are backup and stay silent until the master stops sending VRRP advertisements, at which point the highest-priority backup takes over the virtual IP in about a second. Clients keep the same gateway address throughout and never re-ARP.

On RouterOS a VRRP instance is a virtual interface you attach the shared address to. The mechanics mirror Cisco IOS: First-Hop Redundancy — priority elects the master, preemption decides whether a recovered router takes back over, and the interesting engineering is making failover trigger on a dead uplink, not just a dead router.

Prerequisites

01

The Two Routers

Same VRID, same virtual IP, different priorities. The higher priority is master. The virtual IP goes on the VRRP interface, not the physical one.

Router A (MASTER · real .2) — VRRP instance + virtual gateway
# The VRRP instance rides the LAN bridge; higher priority = master.
> /interface vrrp add name=vrrp-lan interface=bridge vrid=10 priority=200 version=3
# The SHARED gateway address lives on the vrrp interface.
> /ip address add address=10.10.0.1/24 interface=vrrp-lan
# Router A's own management address stays on the bridge itself:
> /ip address add address=10.10.0.2/24 interface=bridge
Router B (BACKUP · real .3) — identical, lower priority
> /interface vrrp add name=vrrp-lan interface=bridge vrid=10 priority=100 version=3
> /ip address add address=10.10.0.1/24 interface=vrrp-lan   # SAME VIP
> /ip address add address=10.10.0.3/24 interface=bridge
# Clients set their gateway to 10.10.0.1 and never care which router owns it.
⚠ Gotcha — Same VRID on the Segment, and Only One VIP Owner

Both routers must share the same vrid — it's how they recognise each other's advertisements and derive the identical virtual MAC (00:00:5E:00:01:0A for VRID 10). Mismatched VRIDs means two routers both think they're master, both answering for .1 — a duplicate-IP nightmare. Also put the shared address only on the vrrp-lan interface; if you accidentally add .1 to the physical bridge too, you've defeated the whole mechanism.

02

Preemption & Verifying Mastership Safe to Run

Should a recovered master take back the crown, or let the backup keep it? That's preemption. Then confirm who's actually master and test a real failover.

Terminal — monitor state, control preemption
> /interface vrrp monitor vrrp-lan
     state: master
  master-adv...: 00:00:00

# Preemption is on by default: a returning higher-priority router
# reclaims master. Turn it off to avoid a second blip on recovery:
> /interface vrrp set vrrp-lan preemption-mode=no
# Test: disable vrrp on A and watch B flip to master within ~1s.

03

Fail Over on a Dead WAN, Not Just a Dead Router

Plain VRRP only reacts when the master stops advertising — i.e. the router itself dies. But if the master is alive with a dead uplink, it happily keeps mastership and blackholes the LAN. You have to teach it to demote itself.

Terminal — netwatch drops VRRP priority when the WAN gateway goes unreachable
# Probe an off-net target through the WAN; on failure, lower our VRRP
# priority below the backup so B takes over. Restore it on recovery.
> /tool netwatch add host=1.1.1.1 interval=5s \
    down-script="/interface vrrp set vrrp-lan priority=50" \
    up-script="/interface vrrp set vrrp-lan priority=200"
# Now a live-router/dead-WAN failure demotes the master and the LAN
# follows the working uplink. Pairs with dual-WAN routing failover.
💡 Pro Tip — Keep the Two Routers' Configs in Lockstep

VRRP protects the gateway, but the backup is only useful if it can actually route what the master did — same NAT, same firewall, same static routes, same DHCP options. The classic outage is a failover onto a backup that was never kept current. Treat the pair as one unit: change both together, and consider driving both from the same template in fleet management. This is exactly the discipline the hotel field build leaned on.

Takeaways

  1. The default gateway is a single point of failure until two routers share it. VRRP gives the LAN one virtual IP/MAC that survives a router dying.
  2. Same VRID, same VIP, different priority — highest priority is master. Put the shared address only on the VRRP interface.
  3. Failover is sub-second and invisible to clients — they keep the same gateway and never re-ARP.
  4. Preemption is a choice: reclaim mastership for predictability, or leave it for one fewer blip on recovery.
  5. Plain VRRP ignores a dead uplink. Use netwatch to drop priority when the WAN fails so a live-router/dead-WAN box demotes itself.
  6. Keep both routers' configs identical. A backup that can't route what the master did is a false sense of security.

One router between your business and a lost booking day?

NOCTIS builds redundant gateways on MikroTik and Cisco across Crete — VRRP pairs with uplink tracking and matched configs, so a dead router or a dead line is a non-event, not a callout.

Book a Discovery Call →