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 🙂
Hello!
We have 2 RB1200 Devices with VRRP configuration.
A simple sketch from the network is below. I hope it is understandable.
Each RB1200 Device has bridges, vlans and above them VRRP interfaces with public ip-s,
and there are VRRP ip-s in the local networks too, because the dhcp service.
There are NAT-ed servers with public services.
My probleme is that i could’nt setup appropriate firewall rules with these configuration,
because if a server (example) communicating from inside to the NET, the packet goes to
VRRP_LAN interface to VRRP_NET interface, which is ok.
In the reverse direction, when a computer communicating from outside to the server, the packet path is
very interesting: the input interface is VRRP_NET (it’s ok), and the output interface is always different.
One time is VRRP_LAN, other time is the BR_LAN under the VRRP_LAN interface.
I dont know if it is a config probleme, or it is just specificity of VRRP,
Please help me if you can. It is a very confusing probleme.
PUBLIC IP-s (VRRP’s)
| |
| |
RB1200 (1) RB1200 (2)
| | | |
| | | |
BR_1 BR_2 BR_1 BR_2
| | | | | | | |
| | | | | | | |
VL_1 VL_1 VL_2 VL_2 VL_1 VL_1 VL_2 VL_2
@Peti
It sounds like your issues are asymmetric routing while attempting to NAT. If you are running VRRP on the inside and outside you should be able to ensure that the incoming and outgoing router are the same.