Page MenuHomeVyOS Platform

Remove keepalived in favor of FRR for VRRP
Open, WishlistPublicFEATURE REQUEST

Description

Hi,

looking at FRR ( http://docs.frrouting.org/en/latest/vrrp.html ) it would seem to be nice to throw out keepalived and replace it with FRR ...

Regards,

Primoz

Details

Difficulty level
Unknown (require assessment)
Version
-
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Unspecified (possibly destroys the router)
Issue type
Improvement (missing useful functionality)

Event Timeline

erkin renamed this task from VRRP @ FRR to Remove keepalived in favor of FRR for VRRP.Aug 30 2021, 6:16 AM
erkin set Issue type to Improvement (missing useful functionality).
erkin removed a subscriber: Active contributors.

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

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.

dmbaturin triaged this task as Wishlist priority.Jan 9 2024, 5:18 PM