VyOS - Blog

VyOS 1.3.5 security release

daniil@sentrium.io (Daniil Baturin) — Fri, 15 Dec 2023 19:37:19 GMT

Hello, Сommunity!

VyOS 1.3.5/Equuleus LTS release is now officially available for download for customers and contributors. It includes fixes for two security vulnerabilities and a few bugs. One vulnerability is related to the HTTPS API, and the other is in the BGP daemon. Even though they require specific configurations and conditions to exploit, we encourage everyone to update. Images for on-premises deployment and for upgrade are already available, and cloud marketplace listing updates are in progress.

VyOS 1.2.9-S1 maintenance release

daniil@sentrium.io (Daniil Baturin) — Wed, 22 Mar 2023 20:54:08 GMT

Hello, community!

VyOS 1.2.9-S1 maintenance and security release is now available for download to everyone. We planned 1.2.9 to become the last 1.2.x release unless a remotely exploitable vulnerability was discovered. Thankfully, that hasn’t happened yet, but we found that Freexian extended LTS repositories had updates to the base packages that weren't in 1.2.9, including OpenSSL and sudo, so we decided to bring those updates to the community.

VyOS 1.2.9 maintenance release

daniil@sentrium.io (Daniil Baturin) — Fri, 02 Dec 2022 05:00:00 GMT

Hello, Community!

VyOS 1.2.9, the last planned maintenance release of the Crux branch, is now available for subscribers to download. This marks the end of the GA phase for 1.2.x: we will only make any new releases if remotely-exploitable vulnerabilities are found in its code.

We encourage everyone to migrate to VyOS 1.3.x, and we are happy to help with it if needed.

VyOS 1.3.0-epa3 release

daniil@sentrium.io (Daniil Baturin) — Fri, 05 Nov 2021 21:26:08 GMT

Hello!

VyOS 1.3.0-epa3 release is available now. The generic ISO image is available publicly, while subscribers can access additional flavors through the support portal. This release fixes a number of bugs found in earlier versions. If no serious bugs are found, it will also become the last "early production access" release and the next image will be the first official 1.3.0 LTS release.

VyOS Project July 2021 Update

e.altunbas@vyos.io (Erkin Batu Altunbas) — Sun, 08 Aug 2021 16:55:57 GMT

Hi again!

It's time for the progress update for the month of July. We are still on the road to the 1.3.0-epa1 release that will mark the transition of the 1.3/Equuleus branch from experimental to stable and will serve as a platform for ironing out the last bugs.

Past 1.3.0-epa1 there will not be any big CLI changes (only extensions), so we are making the last such changes now. The work on the future 1.4 branch hasn't stopped either. Interested in details?

Read on!

VyOS Project May/June 2021 Update

e.altunbas@vyos.io (Erkin Batu Altunbas) — Thu, 22 Jul 2021 15:48:10 GMT

Hello everyone,

it's time for the progress update for the months of May and June.

We've been a bit too busy with working on the code that we forgot to post a progress update in June—time to fix it! In short: the 1.3 release is on track to become the new LTS in the late summer or early autumn, 1.2.x maintenance continues, and the 1.4 release is gaining new cool features that we can later backport to 1.3.

VyOS 1.2.8 and VyOS 1.3.0-rc5 are available

daniil@sentrium.io (Daniil Baturin) — Tue, 06 Jul 2021 12:47:04 GMT

In this post, we announce not one, but two releases at once.

First, VyOS 1.2.8 LTS release is available to subscribers and everyone is welcome to build their own images.

Second, a VyOS 1.3.0-rc5 release candidate is also available for download for everyone, and we invite everyone to test it on lab VMs with your production configs.

The future of VyOS, part 1: release schedule

daniil@sentrium.io (Daniil Baturin) — Sun, 06 Jun 2021 21:27:55 GMT

Hello Community!

The future of VyOS is bright!

And in this post series, we will talk about our plans for the VyOS Project. This first post focuses on the most immediately important part: the release schedule and support timeline of VyOS 1.2.x and 1.3.x.

VyOS 1.2.7-epa1 and 1.3.0-rc1 images are available

daniil@sentrium.io (Daniil Baturin) — Fri, 26 Feb 2021 11:56:06 GMT

VyOS 1.2.7-epa1

First, VyOS 1.2.7-epa1 is now available to subscribers, and everyone can build an equivalent image from our repositories. It's a rather big release, with multiple bug fixes and some backports from the 1.3/equuleus branch. We don’t expect any major issues with it, but we encourage everyone to test it on non-critical routers first. If no issues are found within a week or so, we will call if a 1.2.7 release.

Anonymous stats collection from VyOS routers: we need your opinions!

daniil@sentrium.io (Daniil Baturin) — Fri, 29 May 2020 16:30:15 GMT

The T-word. Telemetry. Everyone hates it, not least because the most widely known implementations are unambiguously evil. We hate collection and sale of personal information as much as you do, so before we dive deeper into the subject, let’s set it straight: we will never collect any personally identifiable information from VyOS devices without explicit consent, ever.

However, not collecting anything at all does limit our ability to correctly prioritize issues. Now we are thinking of including anonymous stats collection into VyOS images (rolling and LTS alike) by default, and it needs a broad and serious discussion with the community. Our preliminary plan is to enable collection of basic usage stats by default, and provide CLI options to enable more detailed reporting. For that we need to know what people wouldn't hesitate to share by default, so we included a poll in this post.

VyOS Project March 2020 Update

daniil@sentrium.io (Daniil Baturin) — Mon, 23 Mar 2020 04:45:45 GMT

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.

VyOS Project 2020 February Update

yuriy@sentrium.io (Yuriy Andamasov) — Thu, 20 Feb 2020 20:37:36 GMT

We skipped January update as we were busy, but time flies fast so here it is.

February update, first in 2020 and with bunch updates!

VyOS 1.2.4 release

yuriy@sentrium.io (Yuriy Andamasov) — Wed, 01 Jan 2020 22:56:33 GMT

Happy new year! I hope you all had a good rest while we preparing this release. It´s been a while from last 1.2.4 EPA but testing went pretty good. Thanks to all who reported issues and worked with us to solve them!

VyOS project news in September

yuriy@sentrium.io (Yuriy Andamasov) — Mon, 23 Sep 2019 20:47:41 GMT

VyOS 1.2.3 release

yuriy@sentrium.io (Yuriy Andamasov) — Thu, 05 Sep 2019 09:00:18 GMT

VyOS 1.2.3-epa1 ("early production access") release images are available for download for customers and active contributors, and everyone is welcome to build it from the latest Crux branch and test it.

VyOS Project 2019 August update

daniil@sentrium.io (Daniil Baturin) — Mon, 05 Aug 2019 19:06:46 GMT

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:

VyOS 1.2.2 maintenance release

daniil@sentrium.io (Daniil Baturin) — Mon, 15 Jul 2019 16:04:25 GMT

VyOS 1.2.2 maintenance release is now available. Our customers and active contributors who have a subscription can download the images from the support portal, and everyone can also build it from the crux branch of the vyos-build repository.

Cloud images are taking a bit longer to complete, but they also will be available in a couple of days. Images for Amazon EC2 and Microsoft Azure are already available.

We are also introducing VyOS on the Packet Cloud with this release.

CVE-2019-11477 (TCP SACK panic) and an Intel i40e driver issue

daniil@sentrium.io (Daniil Baturin) — Tue, 18 Jun 2019 20:18:24 GMT

Recently discovered vulnerability in the Linux kernel's TCP selective acknowledgement processing code potentially allows a remote attacker to cause a kernel panic with a specially crafted packet sequence. You can read the details in the announcement

VyOS 1.2.1 release

yuriy@sentrium.io (Yuriy Andamasov) — Tue, 16 Apr 2019 04:03:23 GMT

We have just released VyOS 1.2.1. The images are available to subscribers and public clouds images submitted, and if you build an image from the Crux branch now, it will be equivalent to those images.

A number of issues have been resolved, and a small feature was added.

VyOS Project 2019 - March Update

yuriy@sentrium.io (Yuriy Andamasov) — Mon, 18 Mar 2019 08:00:00 GMT

Hello, Gents!

It’s been a while from the last update so I thought it’s a good time to share some news.

The team is busy as always, so much done already and much more to be done yet, sometimes it looks like the quantity of the tasks is infinite (and it is). That of course not stopping us, we like challenges and it brings lot of fun too. So here some more info below

VyOS 1.2 (Crux) released

yuriy@sentrium.io (Yuriy Andamasov) — Mon, 28 Jan 2019 17:10:14 GMT

VyOS 1.2.0 LTS is here. We are now merging the final bug fixes and preparing the images and cloud listings. Once the images are ready, we’ll send the download links to all subscribers, expect this during next days.

VyOS 1.2(Crux) EPA3 available to subscribers

yuriy@sentrium.io (Yuriy Andamasov) — Thu, 17 Jan 2019 07:00:00 GMT

The new VyOS 1.2.0-epa3 early is ready and available to subscribers

VyOS 1.2(Crux)-EPA2 is here

yuriy@sentrium.io (Yuriy Andamasov) — Wed, 02 Jan 2019 07:00:00 GMT

VyOS 1.2.0-epa2 release is now available to subscribers and can be built from the crux branch.

1.2 LTS Access Subscriptions pre-order launch & VyOS 1.1.x EOL

yuriy@sentrium.io (Yuriy Andamasov) — Wed, 26 Dec 2018 06:44:34 GMT

Early Production Access for 1.2.0 LTS binaries is here. We are upgrading our production routers as well as routers of our existing customers and partners, these images also will be used for cloud marketplaces.

We are now ready to announce pre-order for Access Subscriptions (find the discount code below) and EOL of VyOS 1.1.x

If you ever wanted support VyOS Project, now is a perfect time to do that.

VyOS 1.2.0-rc11 is available for download

daniil@sentrium.io (Daniil Baturin) — Mon, 17 Dec 2018 23:20:06 GMT

VyOS 1.2.0-rc11 is available for download from https://downloads.vyos.io/?dir=testing/1.2.0-rc11.

Last RC, Early Production Access, Educational and non-profit Access Subscriptions

yuriy@sentrium.io (Yuriy Andamasov) — Thu, 13 Dec 2018 13:05:24 GMT

Hello Community!

We were busy as always doing coding and some more useful stuff, but it’s time for an update.

VyOS development news in August and September

daniil@sentrium.io (Daniil Baturin) — Sun, 16 Sep 2018 18:39:00 GMT

Most importantly: all but one blockers for the 1.2.0 release candidate are now resolved. Quite obviously, for the release candidate, we want all features that worked in 1.1.8 to work fully.

New release naming scheme

While we are at it, I'd like to announce a small cosmetic change. Until now, our release branches were named after chemical elements. This naming scheme is getting a bit too common though (OpenDayLight is a well known example, but there are more), we decided to change it to something else to avoid confusion and be a bit more original.

The new branch theme is constellations sorted by area (in square degrees), from the smallest to the largest. The 1.2.0 release will be named Crux. Crux, also known as the Southern Cross, is a small but bright and iconic constellation that is depicted on flags of many countries of the southern hemisphere, such as Australia and New Zealand.

The 1.3.0 release will be named Equuleus, which is the latin for little horse (no relation to My Little Pony).

Migration to FRR from Quagga

We have resolved most of the migration problems and latest nightly builds already use FRR instead of our aged Quagga.

It will open a path to implementing many new protocols and features, such as BFD, PIM-SM, and more. What kept us from migrating was lack of support for multiple routing tables, which we need for PBR. FRR added it recently, and by now the last known issue that blocked migration (routes from the default table unintentionally leaking into non-default tables) has been resolved, so we finally can migrate without losing any features.

While I do feel somewhat uneasy about licensing of certain daemons, that are included in the source tree but use a permissive open source license even though they are linked against GPL libraries, we do not believe there's a GPL violation in it as long as the license of the binary package is GPL. Not sharing a modified source code of those daemons with users of the binary package would be a GPL violation, but we keep all source code of every VyOS component public.

New BGP address-family syntax

This is still in the works, but it will make it to the nightly builds soon.

Originally, VyOS used to have IPv6-specific BGP options under "address-family ipv6-unicast", but IPv4 options were directly under neighbor. The historical reason is that originally IPv6 BGP was not supported at all. This syntax was rather inconsistent, and made it hard to quickly see which options are address family specific. We used to stick with that inconsistent syntax just because it was always done that way.

One behaviour change in FRR made us reconsider that. As you may know, in BGP, routing information exchange is completely orthogonal to the session transport: IPv4 routes can be exchanged over a TCP connection established between IPv4 addresses and vice versa. The default behaviour of most, if not all, BGP implementation is to enable both address families regardless of the session transport.

That behaviour can be changed by an option, in VyOS, that's "set protocols bgp ... parameters default no-ipv4-unicast". The old behaviour of Quagga was to apply that only to sessions whose transport is IPv6, which is just as inconsistent. FRR takes that option literally and disabled IPv4 route advertisments for all peers if it's active, unless peers are explicitly activated for the IPv4 address family.

Making VyOS play well with that development requires an option to do that, and "address-family ipv4-unicast" is an obvious candidate, but introducing a special case doesn't feel write. I think moving original options to that subtree is a cleaner solution. Yes, it does require reprogramming your fingers, but when we start adding support for more address families, the original syntax will only start looking even more like an atavism.

This is what the new syntax will look like:

dmbaturin@vyos# show protocols bgp

 bgp 64444 {

     address-family {

         ipv4-unicast {

             network 192.168.2.0/24 {

             }

         }

     }

     neighbor 10.91.19.1 {

         address-family {

             ipv4-unicast {

                 allowas-in {

                     number 3

                 }

                 as-override

                 default-originate {

                     route-map Foo

                 }

                 maximum-prefix 50

                 route-map {

                     export Bar

                     import Baz

                 }

                 weight 10

             }

         }

         ebgp-multihop 255

         remote-as 64793

     }

}

Node renaming in migration scripts

Renaming nodes is a very common task in config syntax migration, but until now it could only be done very indirectly. The old XorpConfigParser simply could not separate names from values and renaming nodes was usually done by regex replace. In the new vyos.configtree you'd need to delete the old node and recreate it from scratch.

Until now. Lately we introduced a function that does it one step. If you, for whatever reason, wanted to rename "service ssh" subtree to "service secure-shell", you could do it like this:

with open("/config/config.boot") as f:

    config_text = f.read()

config = vyos.configtree.ConfigTree(config.text)
config.rename(["service", "ssh"], "secure-shell")
print(config.to_string())

One of the reason for introducing it is to make it easier to clean up the DHCP server syntax.

DHCP server rewrite

While we are waiting for the FRR fixes, we (Christian Poessinger and I mainly) decided to eliminate one more bit of the legacy code and give DHCP server scripts a rewrite. We also decided to clean up its syntax.

One of the things that always annoyed me was nested nodes for address ranges: "subnet 192.0.2.0/24 start 192.0.2.100 stop 192.0.2.100". Now start and stop will be different nodes, so that they are easy to change independently: "subnet 192.0.2.0/24 range Foo start 192.0.2.100; ... stop 192.0.2.200".

We will also rename the unwieldy "shared-network-name" to "pool". Operational mode commands always used the "pool" terminology, so it will also improve command consistency.

Wireguard support

Thanks to our contributor who goes by hagbard, VyOS now supports wireguard. The work on it is nearly complete, and will be covered in a separate post.

TFTP server support

Thanks to Christian Poessinger, VyOS now has TFTP server. It was a frequently requested feature, and I think it makes sense for people who keep DHCP on the router and do not want to setup another machine for provisioning phones, think clients and so on.

This is an example of TFTP server with all options set:

service {

 tftp-server {

     allow-upload

     directory /config/tftp

     listen-address 192.0.2.10

     port 69

 }

}

DMVPN works again

Thanks to our contributor Runar Borge, we have identified the cause and fixed the issues that broke DMVPN after upgrading to the latest upstream StrongSWAN. It should now work as expected.

L2TP/IPsec works again

One of the blockers introduced by upgrade to StrongSWAN 5.6 was broken L2TP/IPsec. We've adjusted the config to use the new syntax and now it works again.

More to come

We are actively working on getting the codebase ready for the release candidate. Stay tuned for new updates!

Making first boot scripts just got easier (but building vyos-1x got a bit harder)

daniil@sentrium.io (Daniil Baturin) — Wed, 18 Jul 2018 10:22:25 GMT

As you probably know already, we are working on integrating cloud-init into VyOS, which will allow us to support multiple cloud platforms, and get rid of the custom script for EC2. The hard part of this project is that just allowing cloud-init to do what it normally does in Debian would not produce desired results, we need to make it modify the config.

This raises a question when this should occur and how it should be done. Since modifying running config with scripts has its difficulties in the current backend, and even if it didn't, it still could potentially clash with user's commits, we thought we may want to modify the config.boot file before it's loaded instead.

One advantage is that once we have common functionality implemented, it can be reused not only in cloud-init, but also in the installer, and in custom first boot scripts if someone wants them.

To test this concept, I've added a library names vyos.initialsetup that includes a collection of functions for common settings such as user passwords and keys, host name, default route, name servers, and interface addresses.

Here's an example of a script you can run on your system for demonstration (adjust user name and do ssh-keygen if necessary):

#!/usr/bin/env python3
import vyos.configtree as vct

import vyos.initialsetup as vis
with open('/opt/vyatta/etc/config.boot.default') as f:

    config_string = f.read()
with open('/home/dmbaturin/.ssh/id_rsa.pub') as f:

    key_string = f.read()
config = vct.ConfigTree(config_string)
vis.set_user_password(config, 'vyos', 'qwerty')

vis.set_user_ssh_key(config, 'vyos', key_string)
# Default level is admin

vis.create_user(config, 'dmbaturin', password=None, key=key_string)
# Default type is ethernet

vis.set_interface_address(config, 'eth0', '192.0.2.10/24')
vis.set_default_gateway(config, '192.0.2.1')
vis.set_name_servers(config, ['203.0.113.10', '203.0.113.20'])
vis.set_host_name(config, 'vyos-test')
print(str(config))

The script will print a customized config based on the default config.

Building vyos-1x

This is the good thing. The bad, or rather somewhat inconvenient thing is that vyos-1x package build now depends on the libvyosconfig0 package that provides the library behind the vyos.configtree module, and it's essential for running unit tests for those modules.

You should add the "deb http://dev.packages.vyos.net/repositories/current/vyos/ current main" repository to the sources.list on your build machine and install libvyosconfig0 with APT, or simply take the file from the repo and install it by hand with dpkg.

I hope the increased reliability we gain from those unit test outweighs the inconvenience of additional setup.

Building VyOS images with custom packages just got simpler

daniil@sentrium.io (Daniil Baturin) — Wed, 27 Jun 2018 12:44:58 GMT

While the new build scripts first introduced when we migrated the development branch to jessie made things much simpler for developers and for people who just want to build the latest VyOS image from source, building an image even simply with a package available from Debian Jessie repos but not present in the VyOS package set by default was still quite an ordeal for a person not familiar with live-build and the structure of our build scripts.

Well, until now. Yesterday I've added ./configure script options that should allow everyone to build a custom image without ever touching the plumbing of the build scripts.

The simplest example, building an image with packages available in Debian Jessie:

./configure --custom-packages "bsdgames robotfindskitten"

sudo make iso

A more interesting example, adding a package from a third party repo signed with its own key. In this case, salt-minion:

wget https://repo.saltstack.com/apt/debian/8/amd64/2017.7/SALTSTACK-GPG-KEY.pub

./configure --custom-apt-entry "deb http://repo.saltstack.com/apt/debian/8/amd64/2017.7 jessie main" --custom-packages "salt-minion" --custom-apt-key ./SALTSTACK-GPG-KEY.pub

sudo make iso

Of course it doesn't guarantee that your image will build or work, but at least it will get you to the debugging phase faster,

Writing migration scripts (and manipulating VyOS config files outside VyOS) just got easier

daniil@sentrium.io (Daniil Baturin) — Mon, 28 May 2018 11:42:30 GMT

Long story short

VyOS 1.2.0-rolling (starting with the next nightly build) includes a library for parsing and manipulating config files without loading them into the system config. It can be used for automatically converting configs from old versions in case an incompatible change was made, and for standalone utilities. Motivation and history are discussed below.

Here is an example of interacting with the new library:

>>> from vyos import configtree
>>> c = configtree.ConfigTree("system { host-name vyos \n } interfaces { dummy dum0 { address 192.0.2.1/24 \n address 192.0.2.20/24 \n disable \n } }  /* version: 1.2.0 */")
>>> print(c.to_string())

system {

    host-name vyos

}

interfaces {

    dummy dum0 {

        address 192.0.2.1/24

        address 192.0.2.20/24

        disable { }

    }

}
 /* version: 1.2.0 */
>>> c.set(['interfaces', 'dummy', 'dum0', 'address'], value='293.0.113.3/32', replace=False)
>>> c.delete_value(['interfaces', 'dummy', 'dum0', 'address'], '192.0.2.1/24')
>>> c.delete(['interfaces', 'dummy', 'dum0', 'disable'])
>>> c.is_tag(['interfaces', 'dummy'])

True
>>> c.exists(['interfaces', 'dummy', 'dum0', 'disable'])

False
>>> c.list_nodes(['interfaces', 'dummy'])

['dum0']
>>> print(c.to_string())

system {

    host-name vyos

}

interfaces {

    dummy dum0 {

        address 192.0.2.20/24

        address 293.0.113.3/32

    }

}
 /* version: 1.2.0 */

As you can see, it largely mimics the API you get for the running
config. The only notable differences are that the "set" method requires
that you specify the path and the value separately, and to have nodes
formatted as tag nodes (i.e. "ethernet eth0 { ..." as opposed to
"ethernet { eth0 { ..." you need to mark them as such with "set_tag",
unless they were originally formatted that way in the config you parsed.

Incompatible syntax changes and migration scripts

Have you ever noticed the mysterious line at the end of saved VyOS configs?

/* Warning: Do not remove the following line. */

/* === vyatta-config-version: "cluster@1:config-management@1:conntrack-sync@1:conntrack@1:cron@1:dhcp-relay@1:dhcp-server@4:firewall@5:ipsec@4:nat@4:qos@1:quagga@2:system@6:vrrp@1:wanloadbalance@3:webgui@1:webproxy@1:zone-policy@1" === */

/* Release version: VyOS 1.1.8 */

What is it for? Think what happens if the old CLI syntax design is proven suboptimal, and the only way to seriously improve some feature requires an incompatible syntax change. One such change you may be aware of is the new vs. old NAT syntax, even if just because EdgeOS decided to keep it. The old syntax with a single "service nat" subtree where source NAT rules had to be over 5000, and yet you also had to specify rule type in addition to it, was unwieldy, and pretty much everyone agrees that the new one is better.

Despite the incompatible change, old configs from Vyatta Core 6.3 and older still load in modern VyOS versions just fine. There is a migration mechanism that looks at that version string at the end of the config, and runs appropriate scripts. For example, if you copy a config from some incredibly old version with "nat@1" in the version string, and do "load /config/config.boot.ancient", the system will look up scripts in /opt/vyatta/etc/config-migrate/migrate/nat/ and run scripts 1-to-2, 2-to-3, and 3-to-4, until the current version (though it's better to call it compatibility level) is reached.

So far so good. Why so much legacy syntax remains in VyOS then? Take "system gateway-address" for example, the source of confusion as to where that default route comes from and the leading cause of unintended equal cost multipath setups. Why that stuff is still there?

The mechanism for running the migration scripts is simple, but actually manipulating configs is not. While some scripts are nothing more than a single sed line (for example, the script that changes "smp_affinity" to "smp-affinity"), in most cases you need to go inside nodes. Basically, you need a set/delete/return_values/etc. API that you get for the running config, but without any validation and safeguards, since configs that need migration wouldn't validate by definition, otherwise no migration would be needed.

The parser used by the load command, which is also run non-interactively on boot, is tightly coupled with validation and is hard to decouple from it. It is likely going to stay this way until the entire config backend is replaced. To get around it, people back at Vyatta wrote a library for sort of parsing config files into sort of in-memory datastructures. The only problem is that it's badly broken, fragile, and very annoying to use. This is the reason people have avoided writing migration scripts at all costs, including keeping the worst kinds of legacy syntax until it's absolutely unbearable.

The old parser

The library in question is called XorpConfigParser. XORP was a routing protocol stack used by early versions of Vyatta, and they also used its shell and config format for their own features unrelated to routing protocols. That made adding new features hard and the routing protocol stack itself suffered from serious performance problems, so it was replaced by Quagga and the new CLI was made based on bash, but the name stuck. And not only the name. The library still makes assumptions about the old format, where names and values were separated by colons. When the config format was changed along with the CLI, it was not capable of manipulating values of nodes anymore and returns say "address 192.0.2.1/24" as single string, so the NAT script, for example, makes extensive use of regex match and replace to rename the options. Without normal set and delete operations, manipulating the config becomes an exercise in juggling eggs in variable gravity.

It has always been clear that it needs a replacement, but the problem of correctly parsing and manipulating configs is not a simple one. In addition to inherent complexity of a multi-way tree, the current VyOS syntax itself adds a whole bunch of problems. For example, leaf nodes (e.g. "address 192.0.2.1/24", or "reboot-on-panic true", or "disable") are terminated by newlines, while newlines are not significant anywhere else. Using the same /* */ syntax for node comments that are supposed to stay in the config, simply commented out nodes, and version metadata makes it even worse — the grammar is left-recursive and highly ambiguous. If you see a comment, you are not sure what follows — a node, and which kind of node, another comment, or end of file, and all cases need to be handled differently.

Putting Vyconf to use

A new config backend for VyOS, to be used in the future VyOS 2.0, has been in development for a while, but remained separate from any of the current VyOS code.

While replacing the config backend, and the old config format along with it, still needs a lot of work and cannot be completed until all config and op mode scripts are rewritten in the new style, there is a lot of work already done in the new backend, Vyconf. It was designed from the start to be layered, and rely on in memory datastructures, so the code that is aware of user sessions and commits is based upon code that is only aware of the datastructures and node name and value validation, which in turn builds upon code that is only aware of datastructures. The problem of set/delete interface to multiway trees is already solved there, so why not reuse it?

It needed support for the old config format input and output of course, and to make it accessible from Python scripts, the functionality needed to be made available through a shared library, but I managed to make a working version, which will make it to the next nightly build.

Technical details

The library is somewhat hacky now. The config formatter, for example, doesn't attempt to sort nodes, and likely cannot handle all possible cases of node nesting. The Python bindings are based on ctypes and dlopen(). The shared library it links with is unnecessarily large due to linking with all libraries that Vyconf needs. Building the library assumes per-user OPAM setup and has implicit dependency on Vyconf (and its build dependencies). To avoid the issue with ambiguity introduced by trailing comments, I opted for separating them with a simple finite state machine matcher before passing the actual config parts to the real parser.

You can find the source code of the shared library in libvyosconfig, and the Python bindings in vyos-1x.

Conclusion

Just like any new feature, it needs testing. I'll be testing for missing cases and preparing and API reference, as small as it is, but everyone is invited to play with it in the next 1.2.0 nightly build and send their feedback.

VyOS 1.2.0 status update

daniil@sentrium.io (Daniil Baturin) — Fri, 11 May 2018 08:33:05 GMT

While VyOS 1.2.0 nightly builds have been fairly usable for a while already, there are still some things to be done because we can make a named release candidate from it. These are the things that have been done lately:

EC2 AMI scripts retargeting and clean up

The original AMI build scripts had been virtually unchanged since their original implementation in 2014, and by this time they've had ansible warnings at every other step, which prompted us to question everything they do, and we did. This resulted in a big spring cleanup of those scripts, and now they are way shorter, faster, and robust.

Other than the fact that they now work with VyOS 1.2.0 properly, one of the biggest improvements from the user point of view is that it's now easy to build an AMI with a custom config file simply by editing the file at playbooks/templates/config.boot.default.ec2

The primary motivation for it was to replace cumbersome in-place editing of the config.boot.default from the image with a single template, but in the end it's a win-win solution for both developers and users.

The original scripts were also notorious for their long execution time and fragility. What's worse is that when they failed (and it's usually "when" rather than "if"), they would leave behind a lot of gargabe they couldn't automatically clean up, since they used to create a temporary VPC complete with an internet gateway, subnet, and route table, all just for a single build instance. They also used a t2.medium instance that was clearly oversized for the task and could be expensive to leave running if clean up failed.

Now they create the build instance in the first available subnet of the default VPC, so even if they fail, you only need to delete a t2.micro instance, a key pair, and a security group.

It is no longer possible to build VyOS 1.1.x images with those scripts from the baseline code, but I've created a tag named 1.1.x from the last commit where it was possible, so you can do it if you want to — without these recent improvements of course.

Package upgrades and new drivers

We've upgraded StrongSWAN to 5.6.2, which hopefully will fix a few longstanding issues. Some enthusiastic testers are already testing it, but everyone is invited to test it as well.

SR-IOV is now basically a requirement for high performance virtualized networking, and it needs appropriate drivers. Recent nightly builds include a newer version of Intel's ixgbe and Mellanox OFED drivers, so the support for recent 10gig cards and SR-IOV in particular has improved.

A step towards using the master branch again

The "current" git branch we use throughout the project where everyone else uses "master" was never intended to be a permanent setup: it always was a workaround for the master branch in packages inherited from Vyatta Core being messed up beyond any repair. It will take quite some time to get rid of the "current" branch completely and we'll only be able to do it when we finally consolidate all the code under vyos-1x, but we've made jenkins builds correctly put the packages built from the "master" branch in our development repository, so we'll be able to do it for packages that do not include any legacy code at least.

IPv6 VRRP status

This is the most interesting part. IPv6 VRRP is perhaps a single most awaited feature. Originally it was blocked by lack of support for it in keepalived. Now keepalived supports it, but integrating it will need some backwards-incompatible changes.

Originally, keepalived allowed mixing IPv4 and IPv6 in the same group, but it no longer allows it (curiously, the protocol standard does allow IPv4 advertisments over IPv6 transport, but I can see why they may want to keep these separate). This means to take advantage of the improvements it made, we also have to disallow it, thus breaking the configs of people who attempted to use it. We've been thinking about keeping the old syntax while generating different configs from it, or automated migration, but it's not clear if automated migration is really feasible.

An incompatible syntax change is definitely needed because, for example, if we want to support setting hello source address or unicast VRRP peer address for both IPv4 and IPv6, we obviously need separate options.

Soon IPv6 addresses in IPv4 VRRP groups will be disallowed and syntax for IPv6-only VRRP groups will be added alongside the old vrrp-group syntax. If you have ideas for the new syntax, the possible automated migration, or generally how to make the transition smooth, please comment on the relevant task.

PowerDNS recursor instead of dnsmasq

The old dnsmasq (which I, frankly, always viewed as something of a spork, with its limited DHCP server functionality built into what's mainly a caching DNS resolver), has been replaced with PowerDNS recursor, a much cleaner implementation.

VyOS 1.2.0 repository re-structuring

daniil@sentrium.io (Daniil Baturin) — Sun, 05 Feb 2017 18:10:58 GMT

In preparation for the new 1.2.0 (jessie-based) beta release, we are re-populating the package repositories. The old repositories are now archived, you still can find then in the /legacy/repos directory on dev.packages.vyos.net

The purpose of this is two-fold. First, the old repo got quite messy, and Debian people (rightfully!) keep reminding us about it, but it would be difficult to do a gradual cleanup. Second, since the CI server has moved, and so did the build hosts, we need to test how well the new procedures are working. And, additionally, it should tell us if we are prepared to restore VyOS from its source should anything happen to the packages.vyos.net server or its contents.

For perhaps a couple of days, there will be no new nightly builds, and you will not be able to build ISOs yourself, unless you change the repo path in ./configure options by hand. Stay tuned.

VyOS 2.0 development digest #7: Python coding guidelines for config scripts in 1.2.0, and config parser for VyConf

daniil@sentrium.io (Daniil Baturin) — Wed, 04 Jan 2017 19:27:32 GMT

Python coding guidelines for 1.2.0

In some previous post I was talking about the Python wrapper for the config reading library. However, simply switching to a language that is not Perl will not automatically make that code easy to move to 2.0 when the backend is ready, neither it will automatically improve the design and architecture. It will also improve the code in general, and help keeping it readable and maintainable.

You can find the document here: http://wiki.vyos.net/wiki/Python_config_script_policy

In short:

Logic for config validation, generating configs, and changing system settings/restarting services must be completely separated
For any configs that allow nesting (dhcpd.conf, ipsec.conf etc.) template processor must be used (as opposed to string concatenation)
Functions should not randomly output anything to stdout/stderr
Code must be unit-testable

Config parser for VyConf/VyOS 2.0

Today I pushed initial implementation of the new config lexer and parser. It already supports nodes and node comments, but doesn't support node metadata (that will be used to mark inactive and ephemeral nodes).

You can read the code (https://github.com/vyos/vyconf/blob/master/src/curly_lexer.mll and https://github.com/vyos/vyconf/blob/master/src/curly_parser.mly) and play with it by loading the .cma's into REPL. Next step is to add config renderer. Once the protobuf schema is ready we can wrap it all into a daemon and finally have something to really play with, rather than just run the unit tests.

Informally, here's what I changed in the config syntax.

Old config

interfaces {

  /* WAN interface */

  ethernet eth0 {

    address 192.0.2.1/24

    address 192.0.2.2/24

    duplex auto

  }

}

New config

interfaces {

  ethernet {

    /* WAN interface */

    eth0 {

      address [

        192.0.2.1/24;

        192.0.2.2/24;

      ];

      duplex auto;

      // This kind of comment is ignored by the parser

    }

  }

}

As you can see, the changes are:

Leaf nodes are now terminated by semicolons rather than newlines.
There is syntax for comments that are ignored by the parser
Multi nodes have the array of values in square brackets.
Tag nodes do not receive any special formatting.

I suppose the last change may be controversial, because it can lead to somewhat odd-looking constructs like:

interfaces {

  ethernet {

    eth0 {

      vif {

        21 {

          address 192.0.2.1/24

        }

      }

    }

  }

}

If you are really going to miss the old approach to tag nodes (that is "ethernet eth0 {" as opposed to "ethernet { eth0 { ...", let me know and I guess I can come up with something. The main difficulty is that, while this never occurs in configs VyOS config save produces, different tag nodes, e.g. "interfaces ethernet" and "interfaces tunnel" can be intermingled, so for parsing we have to track which ones were already created, and this will make the parser code a lot longer.

I'm pretty convinced that "address 192.0.2.1/24; address 192.0.2.2/24" is simply visual clutter and JunOS-like square bracket syntax will make it cleaner. It also solves the aforementioned problem with interleaved nodes tracking for leaf nodes.

Let me know what you think about the syntax.

VyOS 2.0 development digest #5: doing 1.2.x and 2.0 development in parallel

daniil@sentrium.io (Daniil Baturin) — Thu, 22 Dec 2016 01:33:41 GMT

There was a rather heated discussion about the 1.2.0 situation on the channel, and valid points were definitely expressed: while 2.0 is being written, 1.2.0 can't benefit from any of that work, and it's sad. We do need a working VyOS in any case, and we can't just stop doing anything about it and only work on 2.0. My original plan was to put 1.2.0 in maintenance mode once it's stabilized, but it would mean no updates at all for anyone, other than bugfixes. To make things worse, some things do need if not rewrite, but at least very deep refactoring bordering on rewrite just to make them work again, due to deep changes in the configs of e.g. StrongSWAN.

There are three main issues with reusing the old code, as I already said: it's written in Perl, it mixes config reading and checking with logic, and it can't be tested outside VyOS. The fourth issue is that the logic for generating, writing, and applying configs is not separated in most scripts either so they don't fit the 2.0 model of more transactional commits. The question is if we can do anything about those issues to enable rewriting bits of 1.2.0 in a way that will allow reusing that code in 2.0 when the config backend and base system are ready, and what exactly should we do.

My conclusion so far is that we probably can, with some dirty hacks and extra care. Read on.

The language

I guess by now everyone agrees that Perl is a bad idea. There are few people who know it these days, and there is no justification for knowing it. The language is a minefield that lacks proper error reporting mechanism or means to convey the semantics.

If you are new to it, look at this examples:

All "error reporting" enabled, let's try to divide a string by an integer.

$ perl -e 'use strict; use warnings; print "foobar" / 42'

Argument "foobar" isn't numeric in division (/) at -e line 1.

0

A warning indeed... Didn't prevent program from producing a value though: garbage in, garbage out. And, my long time favorite: analogous issues bit me in real code a number of times!

$ perl -e 'print reverse "dog"'

dog

Even if you know that it has to do with "list context", good luck finding information about default context of this or that function in the docs. In short, if the language of VyOS 1.x wasn't Perl, a lot of bugs would be outright impossible.

Python looks like a good candidate for config scripts: it's strongly typed, the type and object system is fairly expressive, there are nice unit test libraries and template processors and other things, and it's reasonably fast. What I don't like about it and dynamically typed languages in general is that it needs a damn good test coverage because the set of errors it can detect at compile time is limited and a lot of errors make it to runtime, but there are always compromises.

But, we need bindings. VyConf will use sockets and protobuf messages for its API which makes writing bindings for pretty much any language trivial, but in 1.x.x it's more complicated. The C++/Perl library from VyOS backend is not really easy to follow, and not trivial to produce bindings for. However, we have cli-shell-api, which is already used in config scripts written in shell, and behaves as it should. It also produces fairly machine-friendly output, even though its error reporting is rudimantary (then again, error reporting of the C++ and Perl library isn't all that nice either). So, for a proof of concept, I decided to make a thin wrapper around cli-shell-api: later it can be rewritten as a real C++ binding if this approach shows its limitations. It will need some C++ library logic extraction and cleanup to replicate the behaviour (why the C++ library itself links against Perl interpreter library? Did you know it also links to specific version of the apt-pkg library that was never meant for end users and made no promise of API stability, for its version comparison function that it uses for soring names of nodes like eth0? That's another story though).

Anyway, I need to add the Python library to the vyatta-cfg package which I'll do soon, for the time being you can put the file to your VyOS (it works in 1.1.7 with python2.6) and play with it.

Upd: since then, the Python library is a part of VyOS 1.2.0+ images and is in the default PYTHONPATH. Check out scripts in https://github.com/vyos/vyos-1x

Right now it exposes just a handful of functions: exists(), return_value(), return_values(), and list_nodes(). It also has is_leaf/is_tag/is_multi functions that it uses internally to produce somewhat better error reporting, though they are unnecessary in config scripts, since you already know that about nodes from templates. Those four functions are enough to write a config script for something like squid, dnsmasq, openvpn, or anything else that can reload its config on its own. It's programs that need fancy update logic that really need exists_orig or return_effective_value. Incidentally, a lot of components that need that rewrite to repair or could seriously benefit from serious overhaul are like that: for example. iptables is handled by manipulating individual rules right now even though iptables-restore is atomic, likewise openvpn is now managed by passing it the config in command line options while it's perfectly capable of reloading its config and this would make tunnel restarts a lot less disruptive, and strongswan, the holder of the least maintainable config script, is indeed capable of live reload too.

Which brings us to the next part...

The conventions

To avoid having to do two rewrites of the same code instead of just one, we need to make sure that at least substantial part of the code from VyOS 1.2.x can be reused in 2.0. For this we need to setup a set of conventions. I suggest the following, and let's discuss it.

Language version

Python 3 SHALL be used.

Rationale: well, how much longer can we all keep 2.x alive if 3.0 is just a cleaner and nicer implementation?

Coding standard

No single function shall SHOULD be longer than 100 lines.

Rationale: https://github.com/vyos/vyatta-cfg-vpn/blob/current/scripts/vpn-config.pl#L449-L1134 ;)

Logic separation and testability

This is the most important part. To be able to reuse anything, we need to separate assumptions about the environment from the core logic. To be able to test it in isolation and make sure most of the bugs are caught on developer workstations rather than test routers, we need to avoid dependendies on the global state whenever possible. Also, to fit the transactional commit model of VyOS 2.0 later, we need to keep consistency checking, generating configs, and restarting services separated.

For this, I suggest that we config scripts follow this blueprint:

def get_config():

    foo = vyos.config.return_value("foo bar")

    bar = vyos.config.return_value("baz quux")

    return {"foo": foo, "bar": bar} # Could be an object depending on size and complexity...
def verify(config):

    result do_some_checks(config)

    if checks_succees(result):

        return None

    else:

        raise ScaryException("Some error")
def generate(config):

    write_config_files(config)
def apply(config):

    restart_some_services(config)
if __name__ == '__main__':

    try:

       c = get_config()

       verify(c)

       generate(c)

       apply(c)

    except ScaryException:

        exit_gracefully()

This way the function that process the config can be tested outside of VyOS by creating the same stucture as get_config() would create by hand (or from file) and passing it as an argument. Likewise, in 2.0 we can call its verify(), update(), and apply() functions separately.

Let me know what you think.