Hello, Сommunity!
This summer is anything but a slow news season, but if you need a break from world events, here's a VyOS development update for you — a purely technical read. Our development efforts in June brought a reorganized (and much faster) config syntax migration subsystem, improvements in QoS and reverse proxy; support for raw firewall tables, and more.
In older VyOS versions, the country code for wireless interfaces (which defines the regulatory domain) had to be set for every interface individually. That makes no sense because two wireless cards in the same box cannot be used in different countries or be subject to different regulations.
Now it's a system-wide option: set system wireless country-code.
Old per-interface settings are automatically migrated, and if you have different country codes in different interfaces, the value from the first interface will be used.
Now, it's possible to use QoS match groups to easily group match criteria and reuse them in multiple policy classes.
set qos traffic-match-group Mission-Critical match AF31 ip dscp 'AF31'
set qos traffic-match-group Mission-Critical match AF32 ip dscp 'AF42'
set qos traffic-match-group Mission-Critical match CS3 ip dscp 'CS3'
set qos policy shaper VyOS-HTB class 20 description 'MC'
set qos policy shaper VyOS-HTB class 20 match-group 'Mission-Critical'
set qos policy shaper VyOS-HTB class 20 priority '2'
set qos policy shaper VyOS-HTB class 20 queue-type 'fair-queue'
set qos policy shaper VyOS-HTB default bandwidth '20%'
set qos policy shaper VyOS-HTB default queue-type 'fq-codel'HAProxy supports multiple built-in health check methods, and now there's VyOS CLI for them all:
set load-balancing reverse-proxy backend bk-01 health-check ldap
set load-balancing reverse-proxy backend bk-01 health-check redis
set load-balancing reverse-proxy backend bk-01 health-check mysql
set load-balancing reverse-proxy backend bk-01 health-check pgsql
set load-balancing reverse-proxy backend bk-01 health-check smtpIf you need to apply firewall rules to packets before they are processed by conntrack, there’s support for configuring rules in raw tables now:
set firewall global-options timeout icmp '45'
set firewall global-options timeout tcp established '125'
set firewall ipv4 prerouting raw rule 10 action 'notrack'
set firewall ipv4 prerouting raw rule 10 destination address '198.51.100.0/24'
set firewall ipv4 prerouting raw rule 20 action 'drop'
set firewall ipv4 prerouting raw rule 20 destination port '22'
set firewall ipv4 prerouting raw rule 20 protocol 'tcp'
set firewall ipv6 output raw rule 10 action 'accept'
set firewall ipv6 output raw rule 10 protocol 'udp'
set firewall ipv6 output raw rule 20 action 'notrack'
set firewall ipv6 output raw rule 20 outbound-interface name 'eth2'set service ssh pubkey-accepted-algorithm ssh-ed25519 (T5878).generate nat rule-resequence start X step Y (T6313).run show kernel modules (T6501).set system option disable-usb-autosuspend (T5949).show lldp neighbors detail and show lldp neighbors interface <name> detail (T6045).set container name c1 sysctl parameter kernel.msgmax value 8192 (T6219).monitor log wireless ... and show log wireless ... (T6462).set service pppoe-server authentication any-login (T5710).show qos ... (T6452).run restart ssh command works correctly again (T6503).run generate ipsec profile ...) properly include CA common name now (T6424).monitor traceroute commands correctly work with VRF now (T6431).vlan-to-vni option in VXLAN interfaces (T6401).If you didn't know, whenever a VyOS system loads a config, it looks at the component versions line to see if the config is from an older version and runs a sequence of migration scripts to convert it to the current syntax. That allows us to make configuration command syntax changes with minimal user disruption.
You might have seen this line in /config/config.boot:
// Warning: Do not remove the following line.
// vyos-config-version: "bgp@5:broadcast-relay@1:cluster@2:config-management@1:conntrack@5:conntrack-sync@2:container@2:dhcp-relay@2:dhcp-server@11:dhcpv6-server@5:dns-dynamic@4:dns-forwarding@4:firewall@16:flow-accounting@1:https@6:ids@1:interfaces@33:ipoe-server@3:ipsec@13:isis@3:l2tp@9:lldp@2:mdns@1:monitoring@1:nat@8:nat66@3:ntp@3:openconnect@3:openvpn@2:ospf@2:pim@1:policy@8:pppoe-server@10:pptp@5:qos@2:quagga@11:reverse-proxy@1:rip@1:rpki@2:salt@1:snmp@3:ssh@2:sstp@6:system@27:vrf@3:vrrp@4:vyos-accel-ppp@2:wanloadbalance@3:webproxy@2"If the system sees bgp@1 there and the current BGP syntax version is 5, it runs five series of BGP migration scripts (0-to-1, 1-to-2...) to bring it to the current state. That way even very old configs from Vyatta Core days can still load without issues.
However, the way migration scripts were executed left quite some room for improvement. Originally, every script was an independent executable file, and there was no way around it since many scripts were written in different languages: some used Perl and the notoriously incomplete XorpConfigParser module that couldn't tell node values from tag nodes. Other scripts were shell scripts that used sed or awk to rename nodes.
However, now all those scripts are written in Python and use vyos.configtree module. That allowed us to make a migration script runner that parses the config once and then calls function from migration modules on it. That saves us a lot of subprocess spawns, and the fact that there's no repeated parsing and file writes also makes the process significantly faster.
That's all for now, but stay tuned for updates — more to come!