VyOS development news in August and September
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
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
L2TP/IPsec works again
More to come
We are actively working on getting the codebase ready for the release candidate. Stay tuned for new updates!
Comments