Thanks to all people testing release candidates, more bugs were uncovered and fixed. But this release also includes a new feature, that was made possible by migration away from our outdated Quagga, namely:
BGP large communities
Since we are using FRR rather than an outdated Quagga version now, we could finally add CLI support for a long requested feature: large communities. Now that RIRs are out of 32-bit AS numbers, it's more relevant than ever.
The syntax is very simple and similar to that of community-lists:
set policy large-community-list Foo rule 10 action permit
set policy large-community-list Foo rule 10 regex 4000000:33333:4444
set policy large-community-list Foo rule 20 action deny
set policy large-community-list Foo rule 20 regex '^$'
set policy route-map Bar rule 10 action permit
set policy route-map Bar rule 10 match large-community large-community-list Foo
set policy route-map Quux rule 10 action permit
set policy route-map Quux rule 10 set large-community 90000:555:111
Note that there are no well-known communities such as "no-export" here, unlike in the classic communities. I also decided not to implement support for "standard" (numbered) large-community-lists and only include "expanded" (named) lists.
Now to the bug fixes.
Directly connected interface-routes
Some hosting providers, for example, Online.net, use an unusual configuration with /32 host addresses, where you are supposed to create an interface-based route to the default gateway address and then create a default route via that address.
While this configuration is against the classic networking common sense, and I'm not a fan of it, it's technically perfectly valid and increasingly common. The Linux kernel network stack uses a "you asked for it, you get it" approach and allows you to do any crazy things, which sometimes turn out surprisingly useful. Our old Quagga, however, would treat such routes as unreachable because the next hop address is not from the same network as assigned on the interface — sound reasoning, but in this situation it was wrong.
The only way to make it work was to add an iproute2 command to the postconfig script, which is cumbesome. Migration to FRR seems to have resolved that issue though. This configuration appears to work fine in my lab:
set interfaces ethernet eth1 address 192.0.0.2.10/32
set protocols static interface-route 203.0.113.1/32 next-hop-interface eth1
set protocols static route 0.0.0.0/0 next-hop 203.0.113.1
This is what the route table looks like: the 203.0.113.1/32 route is treated as directly connected.
vyos@vyos# run show ip route
...
S> 0.0.0.0/0 [1/0] via 203.0.113.1 (recursive), 00:00:03
* via 203.0.113.1, eth1 onlink, 00:00:03
C>* 192.0.2.10/32 is directly connected, eth1, 00:00:03
S>* 203.0.113.1/32 [1/0] is directly connected, eth1, 00:00:03
And this is what it looks like in the kernel:
vyos@vyos# run show ip route forward
default via 203.0.113.1 dev eth1 proto static metric 20 onlink
192.168.56.0/24 dev eth0 proto kernel scope link src 192.168.56.13
203.0.113.1 dev eth1 proto static metric 20
If you are using online.net or another hosting provider that uses this scheme, please test it and tell us if it works for you without workarounds.
Fixes in bridging and tunnels
Thanks to Kroy from the forum, we tracked down and fixed a few bridging bugs that had been there for a long time but no one noticed.
The first bug was that the system allowed you to remove a bridge that still has active members (T898). Even with that bug fixed, you still could not remove a tunnel interface from a bridge because its own script was faulty (T900).
Both are now fixed, but there are still issues in that script: STP cost and priority options are not functional. We may fix it in the next release candidate.
Additionally, OpenVPN interfaces could not be added to bridges due to a brctl syntax change, as reported by afics in T884. This should also be fixed now.
Image signature check failure confirmation
Armin Fisslthaler (afics) noticed a particularly embarassing bug: when the installer fails to verify image GPG signature (due to missing key or otherwise), it asks if you want to proceed, and suggests that the default option is "No", but if you just hit Enter, it proceeds instead of exiting (
T885).
Ewald van Geffen took the time to fix that conditional and now it should no longer haunt us.
Missing release key in the image
Speaking of which, the VyOS release key is now included in the image and signature check should no longer fail.
More fixes
Corrected the syntax for deleting IPv6 next-hop (T800, fix suggested by Merjin).
IPv6 next-hop local value is now validated at set rather than commit time (T897).
Known issues