Hello, Сommunity!
We hope you enjoy your summer!
In June, there was a lot of work done on VyOS. Why is this update so short, then?
One reason is that VyOS 1.4 is now on the way to becoming the new LTS release, and there's a lot of work on smoke tests and refactoring that is required to stabilize it.
However, a few long-awaited features also landed in the rolling release in June, including TACACS+, config sync, and initial support for accelerated networking with VPP. Let's review the user-visible changes in the 1.3 LTS branch and the rolling release.
set high-availability vrrp group <name> version [2|3]VyOS has had usable RADIUS login support for a while now, but TACACS+ remained a frequently-requested feature. There has been work done on it, on and off, and currently, it's finally working (thanks to the efforts of Christian Breunig!). Here's how to enable it:
set system login tacacs server <address> key <key>
# Optionally
set system login tacacs server <address> timeout <n>
set system login tacacs server <address> port <port>
set system login tacacs server <address> source-address <address>Command accounting through TACACS+ is not supported yet, but it's on the list of planned features.
Config synchronization is another long-awaited feature. In the VyOS 1.1 and early 1.2 eras, our excuse for not implementing it was that there wasn't a proper remote API for working with configuration. Sending commands over SSH is an anti-pattern and a potential cause of multiple problems. However, with the proper HTTP API, there were no excuses anymore — only design questions.
Viacheslav Hletenko stepped forward and made an initial implementation. Some things to note about it:
set service config-sync secondary address <address>
set service config-sync secondary key <key>
set service config-sync section [nat|nat66|firewall]
set service config-sync mode [load|set]We'll be glad to hear from everyone who tests that feature and reports on their experience or any issues they may find!
The question of how to do 40 and 100-gigabit networking with VyOS becomes increasingly frequent as network speeds increase. Currently, kernel bypass networking is the answer to that question. General-purpose hardware and Linux kernel networking stack certainly caught up with 10 gigabits already, but everything beyond that still requires a fast path.
The most promising project for that role, as of now, is VPP.
Now, thanks to the efforts of Taras Pudiak, we have a prototype. The current implementation is experimental and has to be manually enabled in the CLI in the rolling release.
# Enable the VPP CLI
sudo mv /opt/vyatta/share/vyatta-cfg/vpp /opt/vyatta/share/vyatta-cfg/templates/vpp
# Configure
set vpp cpu main-core '1'
set vpp cpu corelist-workers '2'
set vpp physmem max-size '2048m'
set vpp interface eth1 num-rx-desc '256'
set vpp interface eth1 num-rx-queues '512'
set vpp interface eth1 num-tx-desc '256'
set vpp interface eth1 num-tx-queues '512'
set vpp interface eth1 pci '0000:02:00.0'
set vpp interface eth1 rx-mode 'polling'
set vpp interface eth2 pci '0000:08:00.0'As you can see from the CLI, Ethernet devices need to be switched into the VPP mode explicitly. That is intentional. Many network OSes that use a kernel bypass data plane make it mandatory. That's not an option because we are committed to keeping VyOS available on small devices with a single CPU, hardware with network cards without VPP drivers, and on all virtual platforms. We believe the user should be free to choose whether they use only kernel networking or the VPP-based data plane, so we will keep it optional in all future releases.
If you require high-speed networking and are in a position to test it, please get in touch! Many things still can't be used with VPP right now, but we intend to keep expanding feature support for it.
set container name <name> volume <name> propagation [shared|slave|private|rshared|rslave|rprivate]set policy route-map <name> rule <n> set extcommunity rt '<address> <address> ...'That's all for now, but we continue!