VyOS Project 2019 November Update
Welcome to the monthly round of VyOS project updates. What do we have in store for you?
The EPA (early production access) release is available for testing. We suggest that you try it in a lab first and see if your production configs work as expected—but that is true for every upgrade.
Our customers can download it from the support portal, and everyone can build it from the latest Crux branch. The full list of changes can be found in Phabricator.
In addition to bug fixes, the release features multiple improvements backported from the rolling release:
- BFD support
- HTTP API endpoints for saving and loading config files and upgrading/removing VyOS images
- Support for encryption acceleration with Intel QAT
- Miscellaneous improvements in operational mode commands like “show dhcpv6 server leases”.
We have also upgraded the Linux kernel to 4.19.84 and included driver updates, including a fix for the unfortunate e1000 card issue. FRR was updated to the latest stable 7.2 release.
If you are concerned about a possible hardware vendor lock-in, then we can assure you all vendor-specific acceleration options will always be opt-in and you’ll always be able to enable and disable them explicitly. For example, QAT is enabled by “set system acceleration qat”.
VyOS @ Google Cloud Marketplace
VyOS is officially available on the Google Cloud Marketplace! Now you can use VyOS on AWS, Azure, and GCP public clouds. This is a significant milestone for VyOS public cloud support, but we aren’t going to stop there of course. We’ll keep working to bring VyOS to as many platforms as we can, so stay tuned for updates.
VyOS Manager (Lite)
The HTTP API is still an experimental feature, but it’s now complete enough to replace sending configuration commands via SSH in automated management tools. We expect that eventually ansible modules and other third-party libraries will switch to it for better performance and reliability.
Another good thing is that it’s now complete enough to support a GUI. Since it’s now able to export a selected config path (like “interfaces ethernet”) to JSON, the GUI can retrieve any part of the config in an easily machine-readable format and present it to the user.
With an API and libraries that abstract away the low-level config operations, we can finally implement a GUI in a way that will not lock us out of making improvements to the system and eventually replacing the config backend. That was the main reason we haven’t done anything in that direction despite numerous requests to add it.
Our plan is to include a really basic GUI (VyOS Manager Lite) in the system image, mainly to simplify initial setup for newcomers and for emergency operations by “remote hands” who may not be familiar with VyOS along with real-time monitoring. It will be disabled by default but one can easily enable it either during installation time or after.
Built-in GUI for a single router is inferior to a good CLI most of the time, so there is little point in trying to expose every feature in it. Another part of the plan is to make a solution for managing and monitoring multiple VyOS installations at once, that’s what goes by a tentative name of “VyOS Manager”.
Its exact scope and feature set is still to be determined, so any feedback is welcome. Let us know what you’d like to see there!
1.2.4 will be the first release with initial support for next hardware systems that ship with Intel QAT:
- Dell EMC Virtual Edge Platform 4600
- Edge-Core SAF51003I
- Edge-Core SAF51015I
This will also be the start of VyOS HCL (Hardware Compatibility List). While we are not limiting customers in terms of how they deploy VyOS, we want to provide a list of hardware that is known to work well. We will work with existing customers to compile a list of commonly used hardware and virtual platforms.
You can expect a separate post on this matter.
New development in the rolling release
One of the most important goals for VyOS is to get rid of the legacy code that is holding us back from making improvements and eventually switching to a new config backend.
The code for configuring network interfaces is one of the largest and oldest parts that showed its limits long ago. Now, thanks to the efforts of Christian Poessinger et al., it’s being rewritten from scratch to make it more robust and easier to extend.
Among other things brought by this improvement, there’s now experimental support for GENEVE tunnels. It’s a promising protocol that offers improvements over VXLAN and other similar LAN extension methods. Of course, VXLAN support in VyOS is not going anywhere—if the kernel supports it and there's a demand for it among the community, and the customers, we are going to support it.
AT&T has released the source of DANOS, a system derived from the original Vyatta vRouter product, that Vyatta sold to Brocade and Brocade later sold to AT&T.
Since VyOS and vRouter have seriously diverged, it’s too early to say if any meaningful code exchange between these projects is possible. Most of the code is not reusable because the command definition format and programming languages are different. We will keep an eye on its progress though and we don’t rule out the possibility of future collaboration.
That’s it for November. Still, keep in mind that we continuously work on improving the project. Subscribe to our blog or follow VyOS on social media for all the latest news and updates.