VyOS Project May 2026 Update

daniil@sentrium.io (Daniil Baturin) — Fri, 29 May 2026 10:45:00 GMT

Hello, Community!

The May development update is here. Despite the fact that we had to deal with a downpour of vulnerabilities such as Copy Fail, Dirty Frag, and others (they are all fixed in rolling and in emergency LTS release updates available to subscription holders now!), the VyOS team and community members still added quite a lot of new features and bug fixes this month.

They include a fix for the long-standing, very annoying bug that led to needless OpenVPN server restarts on config changes that only affected user settings that go to the client config dir, multiple new options for DHCPv4 and DHCPv6 servers, initial support for traffic engineering in segment routing, and more.

On "run reset vrrp master"

daniil@sentrium.io (Daniil Baturin) — Sat, 28 Jul 2018 19:10:22 GMT

I've just exorcised a ghost of the old VRRP CLI implementation — the "reset vrrp master" command. I thought it would go away with the vyatta-vrrp package, but in fact it was in vyatta-op. It made me remember that I was going to write about it in the original blog post, but somehow I forgot about it.

Here is why that command was not reimplemented. First, it never worked with preempt to begin with, and with preempt being the default, its usefulness was already limited.

A more serious reason, however, is that it was a rather horrible (even if ingenious) kludge. This is how it worked: first it tried to locate the VRRP group in keepalived.conf, then it would remove it from the config, restart keepalived, insert it again, and restart keepalived again. It sort of worked, but you can see how fragile this approach is. If anything at any stage would go wrong, it would leave VRRP in an inconsistent state.

A much cleaner and general way to do it is to just disable the VRRP group in conf mode (set high-availability vrrp group Foo disable) and commit the change.

New VRRP CLI is here (with IPv6 support)

daniil@sentrium.io (Daniil Baturin) — Fri, 27 Jul 2018 22:10:19 GMT

Ever since I started with Vyatta, I've had a problem with commands for features unrelated to interfaces being defined inside interfaces. I'm sure the person who came up with that arrangement meant well and thought it would be familiar for Cisco and Juniper users, but the more I lived with it, the more I thought it creates more problems than it solves.

From the user perspective, it's hard to easily view the complete configuration of those features. It's also much harder to clone a feature config to another machine. And if you ever want to move some connection to a different NIC, things get even more fun.

For developers, however, it's even worse. First, it means commands for those features needs to be duplicated for every interface type, which makes adding new interfaces much harder. Second, configuration scripts end up more complex due to paths that can be nested quite deeply. Third, with the current config backend specifically, lack of nested end nodes can lead to very interesting tracking of the state to avoid repeated service restarts.

Until recently there was a token excuse for leaving unfortunate UI decisions alone — the difficulty of writing migration scripts. Luckily, it's no longer the case, so we can start cleaning it up. Ok, it is hard and you need to take care of many details, but at least you are not wrestling with a library that is simply inadequate for the task. Now we can go on a quest to remove excessive nesting and redesign the UI is an easier to use, more logical fashion.

VRRP looked a good feature to start the clean up with — we need to get IPv6 VRRP support to work in the end, its scripts have accumulated quite some cruft, and, well, it really has nothing to do with interface settings since it's a protocol of its own implemented by a userspace daemon.

Today I've rolled out the new implementation and it is already in the latest rolling release image, ready for your testing. Let's walk through the changes.

Keepalived

Keepalived was updated to version 2.0.5 with some patches of my own that are already in master but not in a release yet.

New VRRP syntax

Here is an example of a VRRP group with all available options set:

dmbaturin@vyos# show high-availability vrrp group WAN

 advertise-interval 5

 authentication {

     password qwerty

     type plaintext-password # could also be "ah"

 }

 description "My VRRP group"
 disable
 health-check {

     failure-count 5

     interval 60

     script /config/scripts/healthcheck.sh

 }

 hello-source-address 10.218.0.1

 interface eth1

 no-preempt

 peer-address 10.218.0.10

 preempt-delay 180

 priority 200

 rfc3768-compatibility

 transition-script {

     backup /config/scripts/backup.sh

     fault /config/scripts/fault.sh

     master /config/scripts/master.sh

 }

 virtual-address 10.218.0.100/24

 virtual-address 10.218.0.101/24

 vrid 42

As you can see, instead of being nested inside interfaces, VRRP has its own subtree now, "set high-availability vrrp". This makes it easy to move a VRRP group to a different interface, or change its VRID (Virtual Router ID) without resorting to node renaming or deleting and recreating it.

Originally, group number used to define the VRID, as in, "set interfaces ethernet eth0 vrrp vrrp-group 10" would create a group with VRID 10. Now group names are purely for identification and can be arbitrary. To set the VRID, use the "vrid" option.

Since groups are now outside of interfaces, the interface is also an option, that can be changed easily. The interfaces you can use are ethernet, bonding, bridge, and VLANs (including QinQ VLANs) on all of those.

Otherwise the options inside the groups changed little. The option that controls preempt mode is now a valueless node "no-preempt" rather than a boolean node "preempt (true|false)". The "run-transition-scripts" option is now simply "transition-script" — after all, what else one could do with them other than run them?

There is one behaviour change that I think no one will notice, but it should be mentioned. The old CLI used to allow setting a virtual-address without prefix length, as in "virtual-address 192.0.2.1". I think it was an oversight, because it could trick people into thinking it will have the same prefix length as the primary address of the interface, but it's not the case. Instead, the prefix length of such addresses would be set to /32, which, in broadcast networks, makes little sense. Now the CLI requires that you specify prefix length. If you relly want a virtual address with /32 or /128 mask, you should specify it explicitly.

Sync groups

You might have already noticed that sync-group option is missing, even though I said that group has all available options set. That's right — sync groups are now separate entities. This is how you can create one:

dmbaturin@vyos# show high-availability vrrp sync-group

 sync-group MySyncGroup {

     member WAN

     member LAN

 }

Unlike the old CLI, it's very easy to see which sync groups exist in the system, and shuffle VRRP groups between them if necessary.

IPv6 support

I'm pretty sure it's going to be everyone's first question, and rightfully so! The short answer is: yes, IPv6 VRRP is here for real. The long answer: with one caveat, you cannot mix IPv4 and IPv6 in one group.

This is a keepalived limitation. The VRRP protocol specification technically allows it, which is why I didn't make separate syntax for IPv6 groups. Maybe the restriction will be relaxed at some point, maybe not. Right now, if you try to mix IPv4 and IPv6 addresses in one group, you'll get a commit error.

dmbaturin@vyos# show interfaces ethernet eth1

 address 10.218.0.1/24

 address 2001:db8:ee::1/64

 duplex auto

 hw-id 00:50:56:9b:9d:9f

 smp-affinity auto

 speed auto

[edit]

dmbaturin@vyos# show high-availability

 vrrp {

     group IPv4 {

         interface eth1

         virtual-address 10.218.0.2/24

         vrid 44

     }

     group IPv6 {

         interface eth1

         virtual-address 2001:db8:ee::2/64

         vrid 43

     }

 }

[edit]

dmbaturin@vyos# run show interfaces ethernet eth1

eth1:  mtu 1500 qdisc pfifo_fast state UP group default qlen 1000

    link/ether 00:50:56:9b:9d:9f brd ff:ff:ff:ff:ff:ff

    inet 10.218.0.1/24 brd 10.218.0.255 scope global eth1

       valid_lft forever preferred_lft forever

    inet 10.218.0.2/24 scope global secondary eth1

       valid_lft forever preferred_lft forever

    inet6 2001:db8:ee::2/64 scope global nodad

       valid_lft forever preferred_lft forever

    inet6 2001:db8:ee::1/64 scope global

       valid_lft forever preferred_lft forever

Operational mode commands

The essentials are implemented, but it's subject to expansion and improvement.

These commands are already there:

show vrrp
show vrrp detail
show vrrp statistics

The output of "show vrrp" has changed a bit, some hardly informative fields such as "addr owner" (which has little practical implications) were removed.

dmbaturin@vyos# run show vrrp

Name    Interface      VRID  State    Last Transition

------  -----------  ------  -------  -----------------

Foo     eth1             30  MASTER   4s

Lack of information about sync group membership is a more significant omission and if there's demand for it, I'll try to get it back. The reason for it is that the new op mode uses keepalived's JSON output implemented in recent versions, but that output lacks some information that was included in the old (hard to parse) format, so I'll need to send them a patch for it.

Transition scripts

The order of transition script arguments remains compatible. One difference is that for RFC-compliant (i.e. using a macvlan for virtual MAC) VRRP, transition scripts now receive the macvlan interface where addresses are actually assigneg, e.g. eth1v43.

Compatibility with old configs

To ensure compatibility with old configs, I've written a migration script that should cover both configs from 1.1.8 and from earlier versions of the rolling release (including unicast peer and health-check options).

Your old configs should be automatically converted to the new syntax after image updgrade.

Your testing is needed!

The code is new, and there may be corner cases I've missed. If you find any bugs, please report them!

VyOS - Blog