Page MenuHomeVyOS Platform
Create Task
Maniphest T666

Define new VRRP syntax
Closed, ResolvedPublic
Actions

Description

So, my proposal:

high-availability
  vrrp
    group <number>
      virtual-address (multi)
      hello-source-address (ipv4|ipv6)
      peer-address (ipv4|ipv6) # For unicast
      disable <valueless>
      run-transition-scripts
        master (path)
        backup (path)
        fault (path)
      preempt <valueless>
      preempt-delay <int>
      priority <int>
      advertise-interval <int>
      rfc3768-compatibility <valueless>
      authentication
          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.

Details

Version
-

Related Objects
Search...

Event Timeline

dmbaturin created this task.May 29 2018, 7:00 PM
dmbaturin triaged this task as High priority.
dmbaturin created this object with visibility "Public (No Login Required)".
aopdal added a comment.May 30 2018, 7:54 AM

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 Crux 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 subscribed.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.

dmbaturin mentioned this in rVYOSONEX64e65d9cff44: T666: initial draft of the new VRRP syntax..Jul 10 2018, 6:52 PM
dmbaturin added a comment.Jul 10 2018, 6:55 PM

https://github.com/vyos/vyos-1x/blob/new-vrrp/interface-definitions/vrrp.xml 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?

syncer added a comment.Jul 10 2018, 8:47 PM

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

dmbaturin mentioned this in rVYOSONEX829e76035c4f: T666: add correct defaults from the RFC to the VRRP command definitions..Jul 14 2018, 11:12 PM
dmbaturin mentioned this in rVYOSONEX5841ac8f566d: [VRRP] T666, T616: rework the sync-group CLI and add support for it to the….Jul 18 2018, 11:41 PM
dmbaturin mentioned this in rVYOSONEX38c2a62384d7: T666, T616: add authentication and RFC compatibility options to the VRRP CLI..Jul 23 2018, 9:12 AM
dmbaturin mentioned this in rVYOSONEXb5ad22262d62: T616, T666: add new VRRP op mode and a wrapper for transition scripts..Jul 23 2018, 5:47 PM
dmbaturin added a comment.Jul 24 2018, 7:30 AM

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 mentioned this in rVYOSONEX12e7f0fafd8f: T666, T616: various fixes..Jul 24 2018, 10:45 AM
dmbaturin mentioned this in rVYOSONEX0a34c3b37fb4: T666: use the new script validator for health check and transition scripts..Jul 24 2018, 10:48 AM
dmbaturin mentioned this in rVYOSONEX80713a4135c8: T666, T616: add support for IPv6 and checks to prevent mixing IPv4 with IPv6 in….Jul 26 2018, 6:40 AM
dmbaturin updated the task description. (Show Details)Jul 26 2018, 1:51 PM
dmbaturin mentioned this in rVYOSONEX3dba2d13e6ba: T666, T616: new implementation of the VRRP CLI..Jul 27 2018, 11:59 AM
dmbaturin closed this task as Resolved.Aug 4 2018, 8:08 PM
dmbaturin edited projects, added VyOS 1.2 Crux (VyOS 1.2.0-rc1); removed VyOS 1.2 Crux.
dmbaturin mentioned this in rVYOSONEX671775491050: T666, T616: fix messed up variables in hello source/peer address checking..Aug 10 2018, 4:43 PM
dmbaturin mentioned this in rVYOSONEX5e58b540451f: T666, T616: exit from op mode script if VRRP information is not available..Aug 10 2018, 7:36 PM
syncer added a project: VyOS-1.2.0-GA.Oct 15 2018, 10:42 PM
syncer moved this task from Needs Triage to Finished on the VyOS 1.2 Crux (VyOS 1.2.0-rc1) board.Oct 15 2018, 10:42 PM