VyOS Platform Blog

VyOS Project March 2020 Update

Written by Daniil Baturin | March 23, 2020 4:45:45 AM Z

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

1020 OSPF Stops distributing default route after a while
1228 pppoe default-route force option not working (Rel 1.2.0-rc11)
1301 bgp peer-groups don't work when "no-ipv4-unicast" is enabled.
1341 Adding rate-limiter for pppoe server users
1376 Incorrect DHCP lease counting
1392 Large firewall rulesets cause the system to lose configuration and crash at startup
1416 2 dhcp server run in failover mode can't sync hostname with each other
1452 accel-pppoe - add vendor option to shaper
1780 Adding ipsec ike closeaction
1803 Unbind NTP while it's not requested...
1821 VyOS - pppoe-server
1827 Increase default gc_thresh
1832 radvd adding feature DNSSL branch.example.com example.com to existing package
1837 PPPoE unrecognized option 'replacedefaultroute'
1851 wireguard - changing the pubkey on an existing peer seems to destroy the running config.
1858 l2tp: Delete depricated outside-nexthop and add gateway-address
1864 Lower IPSec DPD timeout lower limit from 10s -> 2s
1879 Extend Dynamic DNS XML definition value help strings and validators
1881 Execute permissions are removed from custom SNMP scripts at commit time
1891 Router announcements broken on boot
1900 Enable SNMP for VRRP.
1902 Add redistribute non main table in bgp
1909 Incorrect behaviour of static routes with overlapping networks
1913 "system ipv6 blacklist" command has no effect
1914 IPv6 multipath hash policy does not apply
1917 Update WireGuard to Debian release 0.0.20191219-1
1934 Change default hostname when deploy from OVA without params.
1935 NIC identification and usage problem in Hyper-V environments
1936 pppoe-server CLI control features
1964 SNMP Script-extensions allows names with spaces, but commit fails
1967 BGP parameter "enforce-first-as" does not work anymore
1970 Correct adding interfaces on boot
1971 Missing modules in initrd.img for PXE boot
1998 Update FRR to 7.3
2001 Error when router reboot
2066 PPPoE interface can be created multiple times - last wins
2077 ISO build from crux branch is failing
2079 Update Linux Kernel to v4.19.106
2087 Add maxfail 0 option to pppoe configuration.
2120 "reset vpn ipsec-peer" doesn't work with named peers

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.