Hey guys,

I have been doing VRRP testing whole last week and I have a couple questions.

Thats my test setup. RB01 is VRRP master. Failover and everything works fine when RB01 is unplugged.

My questions:
1) When RB01 is unplugged, since masquerade is used and the NAT session table is not present on RB02, all connections are dropped and have to be re-established. Any way to get around that?

2) When a link between RB01 and wan switch fails, eth10-vrrp is correctly picked up by RB02. But on LAN side, RB01 is still eth1-vrrp master, and any connections coming to it will not pass, since it doesnt have a connection to wan anymore. How to deal with this?
The only thing I can think of is to write a script that checks if ether10 is running and if not then disable ether1 as well. Any idea how performance expensive would it be to run a script like this every 1second (default VRRP check interval)

Thanks!

tom

a) no, can't get around that on RouterOS
b) VRRP interfaces can have up/down scripts associated with them that fire when a router changes state between backup and master. You can use those to change the priority on the other VRRP interface, and enable pre-emption - that will cause the other interface to change state as well. No need for a scheduler, it's all event driven as the script is called automatically when a change event takes place.

Side note: in my opinion it's best to only fail once and not automatically recover. Then it takes human intervention to restore the original state. That prevents flapping the master status around, leading to customers getting bad services. Of course that will require a decent monitoring infrastructure that alerts you to failures as they happen and assumes that someone will be available to fix things. Example: Something fails on router 1. Fail everything to router 2, and that's the last that'll happen automatically (unless router 2 dies completely) until a network admin has verified all is well and restored the failover procedure. You can do this by smartly setting your priorities and change them appropriately in the scripts so that pre-emption keeps things stable.

a) no, can't get around that on RouterOS
b) VRRP interfaces can have up/down scripts associated with them that fire when a router changes state between backup and master. You can use those to change the priority on the other VRRP interface, and enable pre-emption - that will cause the other interface to change state as well. No need for a scheduler, it's all event driven as the script is called automatically when a change event takes place.

Side note: in my opinion it's best to only fail once and not automatically recover. Then it takes human intervention to restore the original state. That prevents flapping the master status around, leading to customers getting bad services. Of course that will require a decent monitoring infrastructure that alerts you to failures as they happen and assumes that someone will be available to fix things. Example: Something fails on router 1. Fail everything to router 2, and that's the last that'll happen automatically (unless router 2 dies completely) until a network admin has verified all is well and restored the failover procedure. You can do this by smartly setting your priorities and change them appropriately in the scripts so that pre-emption keeps things stable.

a) makes me sad, but nothing that can be done about it

b) I checked, but when I unplug the cable that connects RB01 to WAN switch none of the scripts take place. The VRRP scrips are only ran when a VRRP interface switches to master or to slave. When I unplug a cable the only thing that changes is that its no longr running, but it still retains master status.

Thanks for the suggestion, its really a great idea. I will script it like that, and make each RB check the other one like every 5 minutes, and send an email if one is down.

Urgh, that sucks. Maybe write an email to support and request that VRRP interfaces transition to a down state when the physical interface goes down. It makes no sense to consider it a master if it's impossible for the interface to be up, and this tiny change would make failover scenarios much more elegant.

Urgh, that sucks. Maybe write an email to support and request that VRRP interfaces transition to a down state when the physical interface goes down. It makes no sense to consider it a master if it's impossible for the interface to be up, and this tiny change would make failover scenarios much more elegant.

When the interface on top of which the VRRP interface is running goes down, the VRRP interface itself goes down as well. It no longer has the R (running) flag, which is correct. But since the scripts are "On Master" and "On Backup" only, and none of these 2 take place when the interface goes down ... well, it sucks yeah.

There should probably be a 3rd option for a script when the VRRP interface itself goes up or down.

Will write an email to support and hope I guess. Do I have any other options of how to make failover happen when case b) happends?

Sorry, I had a type before. That's what I meant: it would be nice if a VRRP transitioned to the 'backup' state when its running state changed to 'down'. That way you still only need two scripts, and it's logically consistent (can't be master if you're down).

You could make a NetWatch probe (http://wiki.mikrotik.com/wiki/Manual:Tools/Netwatch) that watches the non-virtual IP address on the VRRP interface. That would work fairly well, I think - but it's scheduled and not event driven, so there's delay (at worst the full interval between runs) and there's the possibility of false positives or negatives where the router might be too busy to deal with ICMP probes and could potentially drop them.

Say you have ether1 with 1.1.1.2/24 and vrrp1 tied to ether1 with 1.1.1.1/32. Make a NetWatch probe that watches 1.1.1.2 (which will die with the interface) and for the down-script executes the VRRP priority changes on the other VRRP interface.

Support says

We will see what we can do to improve VRRP in future versions.

In the meantime, I approached it from the other end. If any of the VRRP interfaces transition to Master on the backup VRRP router (RB02 in this case) the "On-Master" script will increase the VRRP priority of all interfaces on the backup router so they become master.

That will give me basicly the same result, just from the other side.

I will also create script on each device that check the other device once every 24h and email me if one of them is down.