Mikrotik VRRP – Hardware Redundancy
So working for a datacenter, I hear plenty of buzz words…what good sales guy doesn’t work one in every other sentence? One of those phrases you hear is “concurrently maintainable”. What does this mean? It means you can sustain loss in your infrastructure and still be up. We are talking about hardware redundancy.
In our DC if you aren’t doing BGP with us, you would do well to use VRRP…what is VRRP? Here’s wikipedia’s definition. In essence it works like such. You have two of your routers connected to the same layer 2 segment. You have a subnet configured that is /29 or larger. You configure a physical IP on the interfaces, then you create a VRRP interface on each router associated with those connected interfaces. You then assign the same VRRP IP address on both routers to the VRRP interface.
The VRRP router that has the higher priority(default is 100) is the master. The master responds to ARP requests for the VRRP IP. If the master router fails, then the backup router takes over and owns the VRRP IP. Soooo, your default gateway points towards the VRRP IP so that if the master fails and the backup takes over your default route is still valid! There is also a concept of premption. By default preemption will migrate the VRRP IP over to the router with the highest priority.
Here are some examples:
So here’s our demo config:
So what happens when one of our providers fail?
Provider fails on one link. The backup guy takes over the VRRP IP. Our default route points to 10.0.0.1 so we still route out!
We drop half of our network gear, but have no fear. The ISP was pointing towards 10.0.0.6 to route to me, so all is good in the hood.
Router 10.0.0.4
Create the VRRP interface *assign it higher priority – default is 100*:
1 2 3 4 | /interface vrrp
add arp=enabled authentication=none comment="" disabled=no interface=ether1 \
interval=1 mtu=1500 name=vrrp1 on-backup="" on-master="" password="" \
preemption-mode=yes priority=150 vrid=1 |
Configure our IPs:
1 2 3 4 5 | /ip address
add address=10.0.0.4/29 broadcast=10.0.0.7 comment="" disabled=no interface=\
ether1 network=10.0.0.0
add address=10.0.0.6/32 broadcast=10.0.0.6 comment="" disabled=no interface=\
vrrp1 network=10.0.0.6 |
Our default route:
1 2 3 | /ip route
add comment="" disabled=no distance=1 dst-address=0.0.0.0/0 gateway=10.0.0.1 \
scope=30 target-scope=10 |
Router 10.0.0.5
Create the VRRP interface:
1 2 3 4 | /interface vrrp
add arp=enabled authentication=none comment="" disabled=no interface=ether1 \
interval=1 mtu=1500 name=vrrp1 on-backup="" on-master="" password="" \
preemption-mode=yes priority=100 vrid=1 |
Configure our IPs:
1 2 3 4 5 | /ip address
add address=10.0.0.5/29 broadcast=10.0.0.7 comment="" disabled=no interface=\
ether1 network=10.0.0.0
add address=10.0.0.6/32 broadcast=10.0.0.6 comment="" disabled=no interface=\
vrrp1 network=10.0.0.6 |
Our default route:
1 2 3 | /ip route
add comment="" disabled=no distance=1 dst-address=0.0.0.0/0 gateway=10.0.0.1 \
scope=30 target-scope=10 |
This is great for the WAN side, but is quite often used for the LAN also!
You can also run two separate VRRP groups on a single interface which will allow you to load balance with redundancy.
Go forth and route my peoples!
Hi, great feature and great tutorial BUT – have you tried to build it/use it in real-world envy? Thanks to implementation in MT (v. 3.x) I have successfully blocked whole server housing three times
. (Master VRRP server generated packet storm after coming back on-line and discovering that it should not be active)
I communicated with Hejtmi and he says that it was a known bug. I’ve searched the change logs and haven’t seen anything about it being repaired.
On a side note I thought of some additional scenarios where this could play out poorly. If you are doing VRRP on the outside and inside, if you lost a link on either group, you would want traffic to shift to the other router. Currently there is no mechanism built in for this.
Cisco has a tracking system for HSPR and VRRP. If you lose a tracked interface you deduct a specified amount of points from that group’s priority. If you are running preemption this will allow the backup to take over.
A similar system could be fashioned for the Mikrotiks using scripts. If any of you are interested, let me know and I’ll see if I can’t whip something up.
Hi Greg
Yes, I am highly interested in such a script. I have two VRRP groups running on the inside and one group on the outside. Traffic just gets stuck if I unplug the patchcable on the outside, even tough the slave becomes master. But as you said yourself, it would be nice to have a mechanism, that automatically adjusts the inside group priority when I loose my outside master.
Complicated, I know
Give me a little time