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.
| 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.
There was lot of development lately around cloud-init and with these new changes you will be able to:
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 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
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.
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!
More kudos to Thomas Mangin and Christian Poessinger for bringing VRF to reality! You now can test it in rolling releases
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.
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.