Hi,
I need to build a VRRP configuration with a pair of MT equipped with 4 interfaces each.
The MT configuration of a single vr group doesn't allow to move several addresses on different interfaces (although that's obviously needed to correctly handle a router with 4 interfaces: external, internal, DMZ1 and DMZ2).
So the only solution seems to create 4 vr groups, one for each interface.
This approach, tough, should create many independent vr engines, each with its heartbeat traffic and so on...
Does anybody know if there is another (possibly clean and efficient) way to do that job?
In another post I read about using scripting to manually enable/disable addresses on master-backup events, but it seems to be quite unreliable...
I don't think this is uncommon situation, so any suggestion will be greatly appreciated.
Many thanks in advance.
Regards,
Riccardo
Re: VRRP configuration question
So the only solution seems to create 4 vr groups, one for each interface.
This approach, tough, should create many independent vr engines, each with its heartbeat traffic and so on...
Does anybody know if there is another (possibly clean and efficient) way to do that job?
In another post I read about using scripting to manually enable/disable addresses on master-backup events, but it seems to be quite unreliable...
I don't think this is uncommon situation, so any suggestion will be greatly appreciated.
bumping the topic back up.. anyone?
the way it stands now, the only way that VRRP will really help those of us using the box as a firewall is in a total box failure.. if i just lost an interface, this does nothing for me as the interface on the otehr side of the FW doesn't know to fail.
is there a non-scipt-hack way to do this.. or can we possibly get the MT guys to add a VR association into a future release? that would pretty much do it.
anyone, anyone? i really don't wanna have to go buy a pix just for decent failover.
thanks
jerm
I totally agree! (of course.... 
About this thread I started, I could highlight 2 main "improving areas" about MT VRRP:
1) "VR associations" between interfaces
We could reserve an ethernet port on each box to connect via cross cable: when the heartbeat is missing we can suppose the other box is dead (usually cross cables don't die). In this situation ALL the addresses should migrate to the surviving backup box, so the only "not virtual" address should be the pair on the ethernet port reserved for the heartbeat.
The heartbeat could be also shared with traffic, though (like trusted LAN network, using additional dedicated addresses).
2) Configuration update between VRRP box
With step above the consistency of configuration between VRRP nodes becomes extremely important. In a complex environnment it's often very difficult to track every change on the master and replicate it immediately on the slave(s), so IMHO a simple and reliable mechanism of configuration replication would be a key differentiator between MT and both free (Linux) and commercial solution.
Unfortunately as far as I know the tools available out of the box are not suitable for this purpose:
- Files Backup/Restore create a slave "too much identical" to the master, because it also clones configuration items that should be keep unique: all the MAC addresses, heartbeat IPs, VRRP configuration, Identity names and so on...
I tried with a combination of restore+script, where the script personalizes the backup just after the restore.... but this approach is not supported by Mikrotik.
- Export/Import is too far from an automated script to apply it to a "factory reset" box to change it to a VRRP backup node. Basically the main problem is the Export command doesn't write the configuration items using a sequence usable "as is" by the Import command. So the manual task to reorder the commands and remove the ones to be keep unique makes this way quite inefficient.
Any contribution is highly appreciated.
Riccardo
About this thread I started, I could highlight 2 main "improving areas" about MT VRRP:
1) "VR associations" between interfaces
We could reserve an ethernet port on each box to connect via cross cable: when the heartbeat is missing we can suppose the other box is dead (usually cross cables don't die). In this situation ALL the addresses should migrate to the surviving backup box, so the only "not virtual" address should be the pair on the ethernet port reserved for the heartbeat.
The heartbeat could be also shared with traffic, though (like trusted LAN network, using additional dedicated addresses).
2) Configuration update between VRRP box
With step above the consistency of configuration between VRRP nodes becomes extremely important. In a complex environnment it's often very difficult to track every change on the master and replicate it immediately on the slave(s), so IMHO a simple and reliable mechanism of configuration replication would be a key differentiator between MT and both free (Linux) and commercial solution.
Unfortunately as far as I know the tools available out of the box are not suitable for this purpose:
- Files Backup/Restore create a slave "too much identical" to the master, because it also clones configuration items that should be keep unique: all the MAC addresses, heartbeat IPs, VRRP configuration, Identity names and so on...
I tried with a combination of restore+script, where the script personalizes the backup just after the restore.... but this approach is not supported by Mikrotik.
- Export/Import is too far from an automated script to apply it to a "factory reset" box to change it to a VRRP backup node. Basically the main problem is the Export command doesn't write the configuration items using a sequence usable "as is" by the Import command. So the manual task to reorder the commands and remove the ones to be keep unique makes this way quite inefficient.
Any contribution is highly appreciated.
Riccardo