VyOS Networks Blog

The summer is often a slow news season, but we’ve got quite a few things to share. We’ve been slacking off on posting development news and keeping the community updated, so it’s time to fix it.

Past and current events

Google Season of docs

As you remember, we had applied for Google Season of Docs, a programme similar to Google Summer of Code that is meant to help open source projects with documentation. It’s the first time it’s ever held and still a pilot project, so the number of projects they selected isn’t very large, and our application got rejected.

However, even without external help, the contributor activity in that area is higher than ever and the new documentation project got more contributions in the last few months than the wiki got in the last couple of years.

Everyone is welcome to join that project and I’m sure together we can make VyOS well-documented and easy to learn for newcomers.

The new documentation can be found at https://vyos.readthedocs.io/en/latest/ and you can contribute to it by forking https://github.com/vyos/vyos-documentation and making a pull request.

The future of wiki.vyos.net

Due to increased activity in the Read the Docs project we decided to retire the wiki completely. If most people prefer the git workflow to that of MediaWiki, we can’t force people in the community to change their mind.

We will no longer accept new account requests, but we’ll keep the wiki online until all its content is migrated to Read the Docs and the support portal. After that we will redirect wiki.vyos.net to the new documentation site.

HTTP API

The nightly builds now include an HTTP API. Yes, one of the most requested features is finally here. We’ve found a not completely insane way to make it work with the old configuration backend, and there it is.

What’s better, the config write API for Python is not baked into the HTTP service, but is available as a module, so everyone can write their own configuration-modifying apps that run on VyOS as well, even though it’s still not too easy.

So far it’s a technology preview and there is no CLI for setting it up, so you’ll have to start the service by hand if you want to test it. We’ll make a separate blog post for everyone interested in technical details.

The “service https” config subtree was removed from the nightly builds along with the remains of the old GUI, but we’ll replace it with a redesigned CLI that gives people more control over the HTTP services they run, certificates they use, and may support custom proxy rules too.

Writing pre-boot scripts just got easier

It’s been possible to run pre-boot scripts for a while (they can be called from /config/scripts/vyos-preconfig-bootup.script), but there was no easy way to retrieve values from a config. The vyos.configtree library that powers new migration scripts made it much easier, but you can only use it from Python or OCaml, shell scripts were out of luck.

Now we have a command for querying values from config files that are not loaded that is easy to use from shell scripts:

For example, if you want to get the host name from a file on a nightly build, do this:

/usr/bin/vyos-config-file-query -f /config/config.boot --return-values --path "system host-name"

The migration script runner and the “merge” command are also being rewritten to use the new config libraries.

Fixes and features in the rolling release

A number of issues have been fixed in nightly builds/rolling release. Here are some of them:

• VRRP health check scripts can now support arguments, so you can reuse one script in multiple groups (as in set high-availability vrrp group Test health-check script "/config/scripts/myscript.sh 192.0.2.1")
• Multiple fixes in DHCP static mapping for IPv6
• PPPoE server now supports CIDR prefixes for IPv4 and IPv6 rather than only address ranges.
• PPPoE server now supports per-user rate limiting (... username myuser rate-limit download/upload).
• DHCPv6 relay can now listen on multiple interfaces.
• Once broken wpad-url option in DHCP server works again.

PacketPushers Podcast

VyOS has been featured in the issue of the Packet Pushers podcast. It was the first time we’ve ever participated in a podcast, and due to our limited experience, the sound is anything but great. We hope it will be better next time.

Future plans

MPLS is coming

Long requested MPLS support now a bit closer (but still somewhat away).

We have FRR and MPLS-enabled kernel now. This means we can start working on experimental support. You can track progress here or better if you have a particular interest in MPLS, join our effort, testing and feedback are greatly appreciated.

We also would like to hear about specific use cases for MPLS switching done in software. While it’s one of the most requested features, we still have little idea how people are actually going to use it, since we only ever used it on hardware L3 switches, so we need to hear from you.

Firewall rewrite

Firewall and NAT were selected as the next target for a big rewrite™. It’s one of the oldest parts of the system, and has long standing CLI design and implementation issues.

Executing iptables commands one by one limits its performance, while the interface-bound CLI makes it impossible to easily insert global rules.

The redesign done in Vyatta Core 6.5 didn’t do it any good either, since it removed the “modify” firewalls (that’s iptables mangle) and moved its remnants to “policy route”, so many things that were once possible cannot be done, while the “policy route” config subtree is full of commands that have nothing to do with policy-based routing).

It’s also one of the biggest components in the system though, so the rewrite will be gradual, and will still need coordinated CLI design and implementation effort. If you have any ideas, and especially if there are parts of the current firewall CLI you hate most and find most limiting, let us know.

Express Data Path

XDP (Express Data Path) is the “killer app” for the rewrite. Once rule generation is abstracted away, we can generate rules for targets other than iptables. Making use of the superior performance that XDP provides for specific cases such as simple drop is one of the goals.

People have requested DPDK support for a long time, but apart from technical difficulties with getting it to work, its vendor lock-in was always our biggest objections, and in light of Intel-specific CPU vulnerabilities, growing support for ARM64, and a comeback of the IBM POWER, that concern is only growing bigger.

XDP is vendor neutral and doesn’t use its own TCP/IP stack separate the kernel, so we think it’s a better way to bring VyOS to post-10G networking in the long run.

VyOS 1.2.2

VyOS 1.2.2 maintenance release will be ready by the end of June. If you are ready to build from source, you can already build an image from the crux branch and benefit from a number of fixes (see changelog), but some more fixes are on the way, and we need to complete them before we make an official image available to customers.