VyOS Networks Blog

Hello, Community! February was a busy month for us: we merged the initial implementation of an accelerated dataplane into the rolling release branch, added a rewritten implementation of WAN load balancing, revamped the syslog configuration, and fixed a whole bunch of bugs. Read on for details!

New features

VPP-based accelerated dataplane

An accelerated dataplane has been one of the most frequently requested and long-awaited features.

Now an initial implementation has landed in the rolling release this month. It is based on FD.io VPP.

First, accelerated dataplane is and will always be optional, and needs to be configured explicitly.

It's important for us that VyOS must continue to run on small devices, older hardware, and arbitrary virtual machines that VPP may not support or that may not have enough resources to run it. And let's be honest about it: there are feature disparities between the kernel and VPP, and there may be VPP-specific bugs.

Some systems lock the user into an accelerated dataplane, which means the system can only ran on rather large servers and VMs with plenty of memory and multiple NICs. We do not want to do that because for a lot of use cases, Linux kernel's forwarding and filtering are fast enough, smaller (including embedded) devices are our target platforms, and we want to enable reuse of older hardware. If you need accelerated forwarding and have resources for it — go for it, if you want features that are only available in the Linux kernel — that option will always be there.

Second, we will try to ensure that accelerated dataplane plays nicely with the normal system configuration, whenever that's possible.

For example, network addressed and routes are already synced between the kernel and VPP when an interface is configured for VPP. Our upcoming prototype of IPsec also works directly with StrongSWAN's data. However, other features, like NAT, will require separate configuration — simply because they will necessarily work different from their conceptual counterparts in the kernel.

Third — last but no least — the configuration subsystem and our modifications to VPP are open-source.

The details of our accelerated dataplane projects certainly deserve its own post. For now, a sneak peak: this is how to enable it for a physical interface.

set vpp settings interface eth1 driver <dpdk|xdp>

Rewritten WAN load balancing daemon (T4470)

The WAN load balancing subsystem was one of the few things we inherited from Vyatta Core and still hadn't rewritten. The daemon was notoriously fickle and had a bunch of long-standing bugs that were difficult to track down and fix.

Now rolling release images feature a new implementation, rewritten from scratch in Python instead of dated C++. The only difference in the config is that if you want a rule to apply to all interfaces of a type, you should write eth* rather than eth+, as per nftables conventions (T7196).

If you were using WAN load balancing in older VyOS versions or plan to start using it, please give it a try and let me knows if it works well for you!

New syslog configuration (T6989)

The ubiquitous rsyslog daemon has different configuration format options. The legacy format is still more common, but the new "advanced" format is, arguably, nicer, and supports options that the old format doesn't, such as an option to send mark (keepalive) messages only if there haven't been real messages in a while.

Rolling release images now include a revamped implementation that used the new, "advanced" format. The rewrite also includes a few command changes — all automatically migrated where necessary.

• Drop the file option to log to dedicated files.
• Drop the user option to always log to user terminal — it will be an op-mode command instead.
• Rename host <ipv4|ipv6|fqdn> to remote <ipv4|ipv6|fqdn>.
• Add new source-address option for outgoing connections under remote source-address <ipv4|ipv6|fqdn>.
• VRF can be defined per remote now: remote vrf <name>.
• Move global preserve-fqdn to preserve-fqdn.
• Move global marker interval to marker interval.
• Rename global to local, as every facility configured under global is actually logged locally to /var/log/messages

Other features

• RPKI now allows setting the source address, e.g.: set protocols rpki cache 10.0.0.2 source-address 192.0.2.1 (T5810).
• tmpfs mountpoint support for containers, e.g., set container name test01 tmpfs work destination /opt/work (T7185).
• Timeout options for HAProxy: set load-balancing haproxy timeout <server|client> seconds (T7190).
• GENEVE tunnels support port option now (T7171).
• set service lldp interface <intf> disable is now replaced with (and automatically migrated to) a more flexible set service lldp interface <name> mode <disable|rx-tx|rx|tx> (T7165).

Bug fixes

• add system image now downloads images to a directory on disk rather than to a RAM-backed tmpfs, so it no longer creates memory usage spikes and upgrade failures due to insufficient space on small machines (T7102).
• Commit archive can correctly use HTTP proxy now (T6058).
• Moving a DHCP-configured network interface between VRFs no longer causes a duplicate default route (T5103).
• set protocols bgp address-family ipv4-unicast redistribute table <num> command works as expected now (T7161).
• sFlow agent-address now correctly works with addressed in non-default VRFs (T7136).
• set firewall global-options resolver-interval and resolver-cache commands work correctly now (T7176).
• set firewall global-options state-policy <state> action reject works as expected now (T7148).
• show haproxy command works again, after it was missing for a while after the subtree renaming (T7187).
• Correct error message on attempts to use the same physical interfaces in multiple bonding interfaces (T7191).
• Trying to add the same physical interface to more than one bridge correctly causes a commit error now (T7192).
• Fixed an unhandled exception when trying to configure SNMPv3 without engine ID (T7180).

That's all for not, but stay tuned for updates. And if you plan to attend MWC Barcelona this year on March 3-6, we will be there, so you are welcome to visit our booth and have a chat!