Very creative. I love VRRP, one of the most useful features. Normally we use it on the LAN side. And I'd thought you'd be limited on WAN with a /29 or better public IPs. You got me thinking if your approach work to use for VRRP more typically case of a single IP/single MAC from an ISP.
But does the backup take over? – since the VRRP interface needs an IP... But I guess it doesn't care if the IP assign while "backup" is a begon or something, until it changed by the script to the real IP. Curious if you can post what you came up with. Pretty novel use for VRRP.
Yip - so far, it's perfect. The only down side is that there is no easy way of sending a GARP so comms die for about 30 seconds while the switch figures out that the MAC has moved. I have tried various work arounds for this without any luck. I know I can generate the packet using HEX but this is not a production worthy solution. A small change will cause this to break.
It's worth noting that we do the following:
On activate -
Enable the interface
Assign IP
On deactivate -
Remove the IP
Disable the interface
Both devices have the same MAC so enable/disable of the interface is critical IMHO.
Another note is that VRRP on Linux "does this out of the box":
vrrp_instance VI_NAT {
state MASTER
virtual_router_id 123
priority 200
advert_int 1
interface eth0
unicast_peer { x.x.x.x }
unicast_src_ip x.x.x.y
vrrp_garp_master_delay 1
vrrp_garp_master_repeat 5
nopreempt
virtual_ipaddress {
x.x.x.x/24 dev eth1
y.y.y.y/29 dev eth2
}
virtual_routes {
0.0.0.0/0 via z.z.z.z dev eth2
}
}
This way the VRRP heartbeat/comms is kept off the public interfaces (eth1,eth2) and is restricted to the management interface (eth0) - I do know that some people might not see this as a solution since they want interfaces to fail independently of each other. For us, we want a fail one, fail all solution. I forgot the setting, but it will force the mac to be the same on both devices (00:00:50:xxxx)
Cheers !