VyOS Networks Blog

With cloud support, a simplified installation process, and a potentially much faster VPN, we can proudly say we’ve had a busy month.

What can you expect from the updates and the VyOS 1.2.3 release?

HTTP API configuration interface and future plans

For a while, the HTTP API server could only be configured and started by hand. Now everyone who wants to try it out can setup it easily:

set service https api debug
set service https api keys id myapp key mylongapi key
set service https listen-address '192.0.2.10'

The local API process listens on localhost:8080, and nginx exposes it on 192.0.2.10:443 in this example.

curl -k -X POST -F data='{"op": "set", "path": ["interfaces", "dummy", "dum1", "address"], "value": "203.0.113.76/32"}' -F key=qwerty https://192.0.2.10/configure

Future plans for that CLI include:

• An option to supply a custom certificate chain.
• Possibly: letsencrypt support.
• Support for simple user-defined proxy rules.

The last option is meant for people who want to run their own services on the router (monitoring etc.), and as a simple way to forward HTTP requests to inside the network without setting up a full-fledged reverse proxy.

The API itself will also contiue to evolve. Right now you can configure everything with it that you can configure through the CLI, but you need to hardcode exact command syntax, which can be problematic since it changes occasionally. For config files we handle it automatically, but there's no way to do command mapping for external scripts.

We are planning to introduce a high level API that abstracts away the command syntax and allows you to do thing like "add a firewall rule", "add an address" and so on. It will make it easier for people to write their own management scripts or orchestration system modules, and will also serve as a basis for the GUI.

Packet.com cloud support and PXE boot

Installing VyOS on a device that can't boot from USB or a CD drive was always challenging. PXE boot is quite tricky got get right for a system with a custom boot process, but we've got close to solving that problem.

Packet.com cloud uses PXE as its standard deployment methods, so we've been testing it there. Once it's verified and finalized, VyOS will be available to Packet customers.

The vyos-build makefile will also have PACKET and PXE targets. They both will build separate kernel + initrd + squashfs image sets, but the former will include cloud-init configs for Packet-specific environment, and the latter will be a generic PXE boot image that you can use with any hardware.

An unexpected problem is that Debian's busybox is built in a way that breaks domain name resolution and some other networking functions, so current PXE procedure only works with servers that can be contacted by their IP address—which is increasingly rare in the modern Internet where everything is a virtual host.

For this reason PXE build procedures are not yet in the mainline. When we get the Debian busybox package to build against musl or uClibc, or bite the bullet and include a correct build out of the busybox tree in the chroot, these procedures will be included.

The image is already available to our subscribers, and when Packet adds it to that list, it will be available to all packet users as well.

You can vote for it here

OpenStack support

We have resolved a bunch of problems with cloud-init on OpenStack, so it should be possible to deploy VyOS there now. Support is still experimental and needs your testing.

Intel QuickAssist

We've been investigating the Intel QuickAssist technology for VPN acceleration. The good thing is that it can be made entirely optional, and promises a good performance boost. There are quite a few things to figure out before we can make it a part of the image though, and we'd like to hear from people who use it about their experience.

When it's done, it will be a big improvement in bare metal platforms support.

VyOS 1.2.3 release

VyOS 1.2.3 is already in the works and we are planning to release it in August. The bug with OSPF process stopping to advertise the default route is fixed in FRR and the fix is now being tested.

Our changes in 1.2.2 fixed the problem with data races between the comit-time scripts and the DHCP client script but inadvertently created a deadlock when trying to disable an interface with "address dhcp". There's also one remaining data race that is not fixable in the current model at all (with static host mappings). We are changing that architecture to use a single process that will keep track of name servers and /etc/hosts entries that commit-time scripts and DHCP client scripts can communicate with through a message queue.

That solution will soon be in the nightly builds, and when it's tested, we'll backport it to Crux and include in 1.2.3.