VyOS Networks Blog

As usual, we’ve been busy working on the 1.2.x LTS release and on the future 1.3.0 version. One important update is that VyOS 1.2.5-epa2 (early production access) image is now available to subscribers, and everyone can build it from the Crux branch. It includes latest stable release of the FreeRangeRouting protocol stack and multiple bug fixes. We are running that image on our own routers, and if no more serious issues are discovered, we’ll make the final 1.2.5 release and keep working on 1.2.6.

VyOS 1.2.5-epa2

Resolved issues

This release took longer than expected, but finally it’s close to completion.

Many people were concerned by a remotely exploitable vulnerability in PPPd related EAP authentication mechanism (CVE-2020-8597). However, for VyOS systems, it was never a threat because  we don’t have EAP enabled anywhere, and with EAP disabled, pppd doesn’t attempt to process those packets. Still, 1.2.5-epa2 includes the patch for it just in case.

Another issue related to both FRR and PPP is that Framed-Routes received via RADIUS for PPP subscribers were not deleted when the client disconnected. With latest FRR, that works as expected.

We have also backported the "mode-force" option for VRRP transition scripts from 1.3. You can set it with "set high-availability vrrp group MyGroup transition-scripts mode-force". What does it do exactly? You may not have noticed since it's a bit of an edge case, but VyOS doesn't normally run VRRP transition scripts on "transitions" caused by keepalived restarts. Historically, keepalived would try to execute transition scripts even on soft reloads used for re-reading the config, so any commit that involves VRRP settings could cause transition scripts to fire. Newer versions behave sensibly, but we've kept the original behaviour by default for compatibility, and to make it possible to give VRRP a hard reset without running slow and/or disruptive  scripts when no "real" state change happened. However, that behaviour is not always desirable, so now you can choose whether  to always run scripts on daemon restarts (mode-force) or not.

VyOS 1.3 development

Cloud-init rework

There was lot of development lately around cloud-init and with these new changes you will be able to:

• supply a complete configuration file (like "/config/config.boot") to VyOS during deployment;
• add any custom configuration commands (like "set xxx yyy") to the configuration during deployment;
• install VyOS via PXE (with interactive installer or automatically);
• boot VyOS with a custom config via PXE. This is completely zero-touch provisioning— you can use VyOS on a hardware router booted via PXE without installing or configuring after the boot.

Most of the noted changes are already included in the current branch, some still undergoing testing and waiting for integration. We hope that at least partially they will be included in the next  LTS release.

Network interface discovery

Network interface discovery and naming are now more robust and predictable. For a test, we’ve set up KVM VMs with 20 NICs, and this configuration now loads without any issues. VMWare guests will have the correct order of interfaces in configurations with 4+ nics

Containers on VyOS

Running docker containers on VyOS (including VyOS itself running as a container, with a right kernel). This will open up a path to persistent third-party applications integrated with VyOS — a possibility that is currently inhibited by the fact that installed applications need to be migrated between VyOS images on updates.

Massive rewrites from perl to xml\python infrastructure 

Extensive rewrite of the code that configures network interfaces, in Python and in a more flexible and extensible way. Special thanks to our new contributor Thomas Mangin and Christian Poessinger! 

VRF

More kudos to Thomas Mangin and Christian Poessinger for bringing VRF to reality! You now can test it in rolling releases

Reproducible builds

Reproducible builds for 1.2.x are taking a bit longer than expected. The idea is simple, but some implementation details are a bit harder. We are not giving up on that, and we expect the reproducible build system to become operational for the final 1.2.5 or at worst 1.2.6 release.

Rolling release monthly snapshots

In addition, we are planning to start making monthly snapshots of the rolling release in different formats (ISO, OVA, VHDX and RAW and Cloud-init ready RAW). So far we've been making snapshots only in exceptional cases like migration from Jessie to Buster.  However, there's clearly a gap between the fully stable LTS branch and "move fast and break things" rolling release. We hope monthly snapshots that are tested and verified to be functional will help people run rolling release on non-critical production routers, and help us discover issues in new code faster.