Define new VRRP syntax
Open, HighPublic

Description

So, my proposal:

high-availability
  vrrp
    group <number>
      virtual-address (multi)
      hello-source-address (ipv4)
      peer-address (ipv4) # For unicast
      disable <valueless>
      run-transition-scripts
        master (path)
        backup (path)
        fault (path)
      preempt <valueless>
      preempt-delay <int>
      priority <int>
      advertise-interval <int>
      sync-group <name>
      authentication
          type <ah|plaintext-password>
          password <text>
  group6
    <all same options but with IPv6 when applicable>

We need to research the issue of RFC compatibility, whether to try to include that at all or not.

Details

Difficulty level
Unknown (require assessment)
Version
-
Why the issue appeared?
Will be filled on close
This request is:
Service Request
dmbaturin triaged this task as High priority.
dmbaturin created this object with visibility "Public (No Login Required)".

For the VRRP group running IPv6 you need 'vrrp_version 3' at least in the keepalived config.

The RFC compatibility may be required by some. The behavior for a RFC compatible configuration is to use the MAC address specified in the RFC for the Virtual IP. The ARP entry in other systems on the network segment will be valid also after a failover. Without RFC compatibility the MAC of the interface is used, and the ARP must be changed in the devices on the network. Gratuitous ARP is used to notify the devices on the segment where a failover occurs.

If we want a solution with interop requirements to other systems than VyOS i think we should implement the RFC compatible part.

dmbaturin moved this task from Need Triage to In Progress on the VyOS 1.2.x board.Thu, May 31, 3:59 AM

@aopdal I agree it would be nice to have RFC compatibility, but when it was introduced, it relied upon a kernel hack that never made it into the mainline. If mainline keepalived and kernel do not support it, and we cannot add support for it that can be merged into the mainline, then it's more trouble than it's worth I think.
Cross-vendor VRRP is more of a hypothetical situation than a common setup.