@primoz What are the benefits?

If the FRR/vrrpd is good enough then the main benefit is that the FRR/vrrpd is already included so no need to also include and use keepalived (unnecessary files and binaries and dependencies).

Things to verify however before a switch is performed (and keepalived is thrown out) is support for vrf/namespaces, various interface and other tracking and multicast vs unicast (it seems that keepalived supports them all - dunno about FRR/vrrpd).

https://docs.frrouting.org/en/latest/vrrp.html

In T2444#158779, @Apachez wrote:

If the FRR/vrrpd is good enough then the main benefit is that the FRR/vrrpd is already included so no need to also include and use keepalived (unnecessary files and binaries and dependencies).

Things to verify however before a switch is performed (and keepalived is thrown out) is support for vrf/namespaces, various interface and other tracking and multicast vs unicast (it seems that keepalived supports them all - dunno about FRR/vrrpd).

https://docs.frrouting.org/en/latest/vrrp.html

@Apachez We can't delete the keeaplived package, as we use set high-availability virtual-server xxx which is part of keepalived.

Well in that case it boils down to if the FRR/vrrpd supports namespaces, various tracking (interface etc) aswell as multicast vs unicast which keepalived seems to support them all.

If keepalived will be kept for vrrp perhaps FRR/vrrpd could be deleted from the compile (unless the set high-availability vrrp will be expanded with a "flavour" setting to choose between keepalived and FRR/vrrpd)?

various tracking (interface etc)

I'm not able to find nothing regarding this feature in FRR repository, could you please send the source code related to this function?

Things to verify however before a switch is performed (and keepalived is thrown out) is support for vrf/namespaces

Yes, FRR supports VRF thought ZEBRA, you can specify a VRF by passing the -oto the FRR's deamon, please see: https://docs.frrouting.org/en/latest/zebra.html#virtual-routing-and-forwarding. In keepalived you can archive that with the configuration file, which should not require a service restart at all.

EDIT: Finally, from a VyOS point of view, I also think you should define the process to transit from keepalived to FRR regarding the MACVLAN interface creation into the kernel: keepalived create the MACVLAN interface himself, with FRR you need to create such interface manually and it is mentioned in the documentation.