VyOS Networks Blog

Hello, Community!

VyOS 1.3.0-epa1 images are now available for download. The “epa” suffix stands for “early production access”—the finish line of the new LTS release stabilization. The generic ISO is available publicly, while all other flavors are now reserved for subscribers—they will be available in the support portal within a couple of days. We recommend trying this release on lab VMs and upgrading non-critical production routers first since this release makes a log of big changes and some corner case issues may still exist.

First of all, we'd like to thank everyone who contributed to this release by sending us patches, testing images, writing documentation, supporting us through subscription purchases and donations, and otherwise helped us bring the release day closer. It wouldn't be possible without you!

Thanks to the efforts of everyone involved, VyOS 1.3 is quite stable already, and we are already running this release in production and it serves us well, but we recommend you try it with your production configurations on lab VMs first, then upgrade non-critical production routers, and only then schedule maintenance windows to upgrade your mission-critical installations. With so many big changes, there's always potential for unhandled corner cases. Please report any issues you find!

Also, remember that we are happy to issue free subscriptions to contributors: if you are already contributing to VyOS, please fill out the application form. And if not, hunting bugs in the upcoming release is a perfect way to start.

The branch name of the 1.3.0 release line is Equuleus. It’s named after a small and faint constellation of the northern sky whose name means “little horse” in Latin (no relation to My Little Pony!). In these almost three years of work, we have rewritten more than 50% of the legacy code from Perl to Python, and from the old unstructured approach to the new architecture that will eventually enable live rollbacks to previous config versions, commit dry-run functionality, and many other improvements. That’s not counting the more immediate benefit: those rewrites make the code much easier to maintain, extend, and contribute to. 

The base system was upgraded to Debian 10 (Buster). Long-term support for Buster from Debian developers is planned to continue until June 2024, so that will give us 2.5 years of official updates, not counting the Freexian extended LTS that will last even longer. That said, we do upgrade and patch a lot of packages ourselves, so we aren’t limited by the official support time frame, but it’s easier to focus on improvements to VyOS itself when the base system can be easily kept up to date. As usual, many packages are already newer than the base system provides: for example, Linux kernel 5.4.148 and FreeRangeRouting 7.5.

One thing of note is that VyOS 1.3 images are smaller than those of 1.2.x. We’ve always been unhappy about the bloated, over 400 megabytes large images of 1.2.x, but we considered the changes needed to improve that are too risky for an LTS release.

However, 1.3.0 images are only slightly larger than 300 megabytes. That took quite some effort because there wasn’t a single source of bloat. We removed unneeded packages, developed a procedure to automatically select files from the linux-firmware package that are actually used by modules enabled in the current kernel build configuration, and tweaked the SquashFS compression options to achieve that result.

New features

VyOS 1.3 includes many frequently requested and long-awaited features. Among them:

• VRF
• Initial support for MPLS and LDP
• IS-IS routing protocol
• SSTP VPN server
• IPoE server

That’s not counting numerous smaller improvements in many components—read the changelog for details.

Additionally, some components changed their underlying implementations, which opens up new possibilities for performance and functionality improvements. For example, L2TP and PPTP servers are now based on accel-ppp, a high-performance implementation used by many service providers. It scales much better than the old xl2tpd and pptpd implementations.

Known issues

Custom OpenVPN options need to be adjusted from the old approach (e.g. "--push ...") to the new one ("push ..."). Our OpenVPN scripts now generate config files for OpenVPN instances to allow them to be easily restarted if needed, instead of starting an openvpn process with a long string of inline options. Thus custom options also need to be written to be included in a config file rather than to be passed in the command line. We are investigating automatic migration options, but it may not be possible. We'd be happy to make it just work, but custom options are always end user's responsibility and not a part of the stable configuration API, so if you are using custom OpenVPN options, consider removing them before upgrade and re-creating them with the new approach.

We are also planning to add more options to the CLI to make custom options less necessary. If you are using custom options and want them to be first-class configuration entities, let us know!

Incompatible changes

No support for configurations from Vyatta Core older than 6.5

First of all, configuration files from Vyatta Core versions older than 6.5 are no longer supported. Since Vyatta Core 6.5 was released in 2012, almost a decade ago, we assume it’s not going to be an issue for anyone. Moreover, it’s always possible to upgrade such installations to VyOS 1.1.8 first and then to the latest version.

Incompatible configuration syntax changes

“service dns-forwarding listen-on” option removed

The “service dns forwarding listen-on” configuration option is no longer supported. When we changed the DNS forwarding implementation from DNSMasq to PowerDNS in VyOS 1.2.0, we kept that option for compatibility. PowerDNS cannot actually be configured to listen on an interface and requires listen-address settings instead, so in VyOS 1.2.0 we added a script to compensate for this and retrieve the addresses from listen-interfaces. However, that approach has reliability issues and isn’t suitable for a long-term solution. In the end, all users should reconfigure their routers and specify listen-addresses explicitly.

To partially alleviate the problem, we added a migration script that will automatically insert addresses of interfaces with statically configured addresses. However, if you had the DNS server listen on an interface that doesn’t have a fixed address, or one that doesn’t use “address” option (e.g. OpenVPN), that configuration will disappear from the config, and you will have to adjust your settings manually.

Removed features

The event handler (“set system event-handler”) is not present in the VyOS 1.3.0-epa1 image. It was removed due to the poor quality of its code. It’s not very robust, especially when using external processes as event sources, since it cannot restart those processes if they crash. It’s also not very reliable and can leak memory in some situations because it’s written in Perl and perl’s garbage collector cannot break reference cycles.

We plan to replace it with a better implementation later, but it’s going to involve non-migratable syntax changes, so for now, it’s removed. Since it’s always been an obscure and rarely-used feature, we hope it will not cause many inconveniences.

However, if you are using that feature, please let us know—we’d like to hear about your needs to make a better implementation!

Deprecated features

The clustering feature is deprecated. In all fairness, it’s been deprecated even before the fork—the implementation is based on the abandoned heartbeat project, and the configuration code has not changed in many years. It’s full of missed opportunities and design shortcomings, but one thing kept us from removing it: it still works, and there may be people who depend on it.

We also believe that many people can benefit from a better clustering implementation that would support more resource types than just IP addresses. However, it will have to be based on a different project (e.g. pacemaker) and it’s unlikely that configuration syntax will be possible to automatically migrate.

If you are currently using the clustering feature, please let us know here (We also would like to hear from you about your experience with the clustering feature, and your needs for a new, improved implementation); meanwhile, we advise migrating to VRRP, because it’s more robust and, thanks to transition scripts, in fact, covers more use cases than clustering and fully supports dual-stack configs. 

Changelog

Breaking changes

• T805: Drop config compatibility with Vyatta Core older than 6.5

Configuration syntax changes (automatically migrated)

• T679: SNMPv3 TSM is no longer supported by net-snmp

New features and improvements

• T31: Add VRF support
• T50: Better support for tcp-mss
• T149: IPv6 support in OpenVPN tunnel
• T169: Image install should put correct serial console device in created GRUB menu entry
• T175: Add source route option to VTI interfaces
• T208: Ability to ignore default-route from dhcpcd per interface
• T311: DHCP: set client-hostname via CLI
• T405: Add binaries for lcdproc
• T421: Add Pv6 prefix delegation support
• T533: Support for PPPoE MTU greater than 1492
• T548: BGP IPv6 multipath support
• T661: Show a warning if the router is going to reboot soon (due to "commit-confirm" command)
• T723: Add support for first boot or installation time saved config modification
• T752: Add an option to disable IPv4 forwarding on specific interface only
• T815: Add DHCPv6 server prefix-delegation support
• T853: Add SSTP server support
• T915: MPLS Support
• T928: Add support for PIM (Protocol-Independent Multicast)
• T989: Add support for IPoE server
• T1083: Implement "--persistent" option to NAT rules
• T1099: Openvpn: use config files instead of one long command.
• T1117: 'show ipv6 bgp route-map' missing
• T1154: use of local cache to build iso
• T1176: FRR - BGP replicating routes
• T1207: DMVPN behind NAT
• T1350: VRRP transition script will be executed once only

Bug fixes

• T320: OSPF does not redistribute connected routes associated with virtual tunnel interfaces
• T406: VPN configuration error: IPv6 over IPv4 IPsec is not supported when using IPv6 ONLY tunnel.
• T480: Error if no serial interface is present (/dev/ttyS0: not a tty)
• T505: Hostapd cannot log
• T508: ISC DHCP incorrect UDP checksum generation
• T521: Network services may fail if vyatta-router.service startup takes longer than a few seconds
• T586: Cannot add ethernet vif-s vif-c interface to bridge-group
• T592: lldpcli: unknown command from argument 1: `#`
• T625: Lack of IKEv1 lifetime negotiation
• T701: LTE interface dosen't come up
• T899: Tunnels cannot be moved from one bridge to another
• T945: Unable to change configuration after changing it from script (vbash + script-template)
• T951: command 'isolate-stations true/false' does not make any changes in the hostapd.conf
• T954: Using the 10.255.255.0/24 subnet on other interfaces breaks L2TP/IPSec
• T1040: rc.local is executed too early
• T1076: SSH: make configuration (sshd_config) volatile and store it to /run
• T1096: BGP process memory leak
• T1121: Can't search for prefixes by community: Community malformed: AA:NN
• T1123: Inconsistency in community-list naming validation
• T1130: Deleting BGP communities from prefix does not work
• T1137: 'sh ip bgp sum' being truncated
• T1145: shutdown event being ignored by latest rolling
• T1148: epa2 BGP peers initiate before config is fully loaded, routes leak.
• T1153: VyOS 1.2.0RC10, RAID-1, fresh install, unable to save config
• T1158: Route-Map configuration dropped updating rc11 to epa2
• T1169: LLDP potentially broken
• T1171: 1.2.0 epa2 - IPsec VPN initiation
• T1212: IPSec Tunnel to Cisco ASA drops reliably after 4.2GB transferred
• T1222: OSPF routing problem - route looping
• T1227: rip PW can't be set at interface config
• T1246: VyOS 1.2.0 "openvpn-options" configuration does not allow quotes in values
• T1249: multiple PBR rules can set to a single interface
• T1250: FRR not setting default gateway from DHCP
• T1770: webproxy breaks commit and http access on routed client
• T1894: FRR config not loaded after daemons segfault or restart
• T2019: LLDP wrong config generation for interface 'all'
• T2127: restart dhcp server reports a failure

Other resolved issues

• T239: Improve documentation for the firewall all-ping setting
• T393: Migrate vyatta-lldpd to vyos-1x
• T476: Update the base system to Debian 10 (Buster)
• T516: Make Python / XML code development more testable
• T517: Rewrite the wireless interface configuration in the new style (python + XML)
• T563: webproxy: migrate 'service webproxy' to get_config_dict()
• T597: Code testing on sonarcloud.com
• T611: Static route syntax should reflect `ip` command routing capabilities, if possible.
• T613: Missing linux-kbuild
• T640: Images no longer work when built without "recommended" packages
• T651: Split CI'ed, VyOS-specific packages and other packages into separate repos
• T679: SNMPv3 TSM is no longer supported by net-snmp
• T685: Python environment lacks definition of vyos_libexec_dir when calling os.system()
• T696: Rewrite conntrack sync to XML
• T742: Replace poptop and xl2tpd with accel-ppp
• T756: Implement rest api with vyos.base
• T786: new style xml and conf-mode scripts: posibillity to add tagNode value as parameter to conf-script
• T805: Drop config compatibility with Vyatta Core older than 6.5
• T808: replace lighthttpd with nginx
• T823: Rewrite DHCP op mode in the new style
• T833: New PPTP server implementation based on accel-ppp
• T834: New L2TP server implementation based on accel-ppp
• T1132: Build on Debian Buster
• T1184: wireguard - extend documentation with the show interface wireguard commands
• T1202: Add `hvinfo` to the packages directory
• T1214: Add `ipaddrcheck` to the packages directory
• T1236: Update Linux Kernel
• T1248: Add a function for copying nodes to the vyos.configtree library
• T2027: get_config_dict is failing when the configuration section is empty/missing