Define new VRRP syntax
Closed, ResolvedPublic


So, my proposal:

    group <number>
      virtual-address (multi)
      hello-source-address (ipv4|ipv6)
      peer-address (ipv4|ipv6) # For unicast
      disable <valueless>
        master (path)
        backup (path)
        fault (path)
      preempt <valueless>
      preempt-delay <int>
      priority <int>
      advertise-interval <int>
      rfc3768-compatibility <valueless>
          type <ah|plaintext-password>
          password <text>

sync-group <tag>
  member <groupName>

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


Difficulty level
Unknown (require assessment)
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.May 31 2018, 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.

Merijn added a subscriber: Merijn.Jun 30 2018, 8:27 AM

RFC compatibility settings prevents VRRP from working on Hyper-V because of promiscuous on NICs
Without the RFC compatibility this is working fine. The new syntax draft.

I have not included the RFC compatibility option since it still needs research.

An interesting question: should we use VRIDs for group "names", or rather allow arbitrary, descriptive group names and make VRID a separate option?
As per the RFC, VRIDs must be unique within a LAN (i.e. datalink layer segment), but can be reused in different LANs. Assuming keepalived supports non-unique VRIDs (needs testing), what do you think?

Hey @aibanez @csalcedo your input here is welcome :)

for me vrid as option looks more logic, however, we can do description as an option too so no big difference

One note: I'm removing the "firewall" option. First, it's only relevant for RFC-compliant VRRP, and there's no checking for it. Second, it has no advantages over assigning the firewall directly to the parent interface in any case.
Third, it was implemented inconsistently: ethernet VIFs and non-ethernet interfaces (e.g. bond) lack it.

Fourth, it was only introduced in 1.2.0, so it's highly unlikely that anyone has it in production.

dmbaturin updated the task description. (Show Details)Thu, Jul 26, 1:51 PM
dmbaturin closed this task as Resolved.Sat, Aug 4, 8:08 PM
dmbaturin edited projects, added VyOS 1.2.x (VyOS 1.2.0-rc1); removed VyOS 1.2.x.