Hi,

I have an interface called vlan_test with no IP address configured. I would like to add an IP address to this interface on VRRP becoming master and remove it when it becomes backup. I have the following script:

:log info "Master";
:if ([/interface vrrp get vrrp_master master] = true) do={
:log info "VRRP is master";
[/ip address add address=x.x.x.x/32 interface=vlan_test]
} else={
:log info "VRRP is backup";
[/ip address remove address=x.x.x.x/32 interface=vlan_test]
}

The script is configured on the "on-master" and "on-backup" of the VRRP interface and the run count increases when VRRP fails over, however, nothing is logged nor is the IP address added. The ultimate goal would also be to change the MAC address but that is another issue for another day

I have tried the /ip command without the [] as well, same result.

Thanks !

BTW - I solved this using the following script:

:log info "VRRP Event detected, checking IPs";
:if ([/interface vrrp get vrrp_master master] = true) do={
:log info "VRRP is master";
[/ip address add address="1.1.1.1/32" interface="vlan_XX"]
} else={
:log info "VRRP is backup";
[/ip address remove [find address="1.1.1.1/32"]]
}

Need to figure out a GARP from that address - tomorrow's worries

Need to figure out a GARP from that address - tomorrow's worries

But you normally just add the SAME VRRP address on both routers to the VRRP interface itself, use /32 as you do now, done. Maybe you have a more complex setup, but you shouldn't need a script for VRRP address assignment.

Maybe you need a script for some other reason. But any irregularity in VRRP could leave you with either two IP, or no IPs. While in theory, this shouldn't happen... if you're using VRRP for high reliability that script worry me in practice (VRRP timing isn't instant, future config changes might temporary break VRRP, etc.)

Need to figure out a GARP from that address - tomorrow's worries

But you normally just add the SAME VRRP address on both routers to the VRRP interface itself, use /32 as you do now, done. Maybe you have a more complex setup, but you shouldn't need a script for VRRP address assignment.

Maybe you need a script for some other reason. But any irregularity in VRRP could leave you with either two IP, or no IPs. While in theory, this shouldn't happen... if you're using VRRP for high reliability that script worry me in practice (VRRP timing isn't instant, future config changes might temporary break VRRP, etc.)

Hi,

Yeah, the reason for adding the IP address to another interface is that one of our providers only allow a single MAC. So the idea is that I will have a bridge interface (so I can change the MAC) and I will assign the IP to the interface, along with disabling it etc.

So far in our testing it's worked well. This provider is a secondary for us so it doesn't matter if it takes time.

Cheers !

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.

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 !