Todo (migrate to systemd or migrate generated configs to /run, to not leave behind corpses after a system reboot)

It would be interesting to hear the reason the FRR chose this behavior as default for one of their profiles. It causes major reconvergence issues for BGP networks and I don't see an obvious benefit.

Shouldn't it be fixed at some point though? I mean is there a reason this should stay something that has to be worked around?

@dmbaturin to enable it by default we need rewrite BGP to new python/XML format and use template, where this feature will be by default because FRR by default doesn't check routes in the RIB.

As far as I remember, originally in our Quagga days, it was the case: nothing was advertised if it wasn't present in the RIB. So if you wanted to advertise e.g. 192.0.2.0/24 but had it split into /25's, you'd need both set protocols bgp ... network 192.0.2.0/24 and set protocols static route 192.0.2.0/24 blackhole.

Sorry for the noise, it was disabled. I forgot to save the config before upgrading, doh.

vyos@rt-home# show openvpn 
 openvpn vtun0 {
     encryption {
         ncp-ciphers aes256gcm
     }
     hash sha512
     keep-alive {
         failure-count 60
         interval 59
     }
     mode server
     persistent-tunnel
     server {
         client jernej-note3 {
             ip x.x..7.10
         }
         client-ip-pool {
             start x.x.7.127
         }
         domain-name home
         max-connections 10
         push-route x.x.0.0/24
         subnet x.x.7.0/24
         topology subnet
     }
     tls {
         ca-cert-file /config/auth/openvpn/ca.crt
         cert-file /config/auth/openvpn/rt-home.crt
         crypt-file /config/auth/openvpn/tls.key
         key-file /config/auth/openvpn/rt-home.key
     }
 }
 openvpn vtun1 {
     description b
     device-type tun
     disable
     encryption {
         ncp-ciphers aes256gcm
     }
     hash sha512
     keep-alive {
         failure-count 60
         interval 59
     }
     local-port 1195
     mode server
     persistent-tunnel
     server {
         client jernej-note3 {
             ip x.x.8.10
         }
         client-ip-pool {
             start x.x.8.6
             stop x.x.0.3
         }
         domain-name home
         max-connections 10
         push-route x.x.0.0/24
         subnet x.x.8.0/24
         topology subnet
     }
     tls {
         ca-cert-file /config/auth/openvpn/ca.crt
         cert-file /config/auth/openvpn/rt-home.crt
         crypt-file /config/auth/openvpn/tls.key
         key-file /config/auth/openvpn/rt-home.key
     }
 }
[edit interfaces]

I tried removing client-ip-pool if it was a issue with it, no difference.

vyos@rt-home# delete openvpn vtun1 server client-ip-pool 
[edit interfaces]
vyos@rt-home# commit
[ interfaces openvpn vtun1 ]
Warning: Client "jernej-note3" IP x.x.8.10 is in server IP pool, it is not reserved for this client.
Diffie-Hellman prime file is unspecified, assuming ECDH

Using the following configuration on 1.3-rolling-202004131043 I see two tunnels running:

Can you share me a configuration?

Fixed in VyOS 1.3-rolling-20200413104

This is a old quirk that's long known (probably was already reported) and
can be worked around by adding a pseudo-ethernet interface with the DHCP
client on it.

https://github.com/vyos/ddclient/commit/6704998de025c7195eb5f30f64859cb0bb7d4596

https://github.com/vyos/vyos-1x/pull/339

Test results on the VyOS 1.3-rolling-202004020117:
Basically, the DHCP option 121 is handled as expected but two issues were observed i.e.:

1. Static routes advertised by the DHCP server in option 121 are not automatically removed from the FIB when the "address dhcp" setting is removed from the interface. Disable/enable the interface doesn't change anything. The only option to get rid of them is to restart the router.

A similar behavior is observed when the "address dhcp" config is replaced with static IP address in one go. In that case disable/enable the interface at least makes them removed from the FIB but they are still present in the FRR as "inactive" . The only option to get rid of them is to restart the router.

Trying to find more information with debugging settings of zebra process.
Apr 12 23:52:18 router zebra[1472]: 0:2404:5780:3::/48: Route install failed
Apr 12 23:52:18 router zebra[1472]: 0:2404:5780:3::/48 Stale dplane result for old_re 0x555f6166b300
Apr 12 23:52:18 router zebra[1472]: 0:2404:5780:3::/48 Processing dplane ctx 0x555f765ff7a0, op ROUTE_UPDATE result FAILURE

https://github.com/vyos/vyos-1x/pull/338

https://github.com/vyos/vyos-1x/pull/335

could you please try this patch. if it still fails, can you remove the 'mtu' from the 'options' line and try again ?

diff --git a/python/vyos/ifconfig/tunnel.py b/python/vyos/ifconfig/tunnel.py
index 0506066..46900ce 100644
--- a/python/vyos/ifconfig/tunnel.py
+++ b/python/vyos/ifconfig/tunnel.py
@@ -141,8 +141,8 @@ class GREIf(_Tunnel):
     default = {'type': 'gre'}
     required = ['local', ]  # mGRE is a GRE without remote endpoint

Retested today using VyOS 1.3-rolling-202004120117

Also fixed in 1.3 https://github.com/vyos/vyos-build-kernel/commit/006550a30afa3c595a07782ec3ce239dc6f65443

Any comments @dmbaturin ?

with T2238 interface can be listed using their feature definition (broadcast, bonding, bridge ...).

@zsdc asked if we could find out a better API for the command and there is an issue where it seems that the environment dict passed to Popen() is not working as expected.

on any equipment with many interfaces, you would expect "port 0" to be "eth0", etc. As vendors are likely to give incremental mac addresses to their interfaces, could the hardware mac address be used at boot to order the interfaces? adding new interfaces may cause a re-numbering but it would give stability on if the hardware does not change.

Naming convention seems fine.

Uh, that's nice easter eggs folks :-) Thank you both for your valuable hints! They'll be very handy!

It is a useful feature .. please do not kill, This patch will fix things until it can be looked into 🤕

+1 on that, already migrated l2tp and sstp VPN to systemd today

I use http://jinja.quantprogramming.com/ to test templates. With it you
can test all possible combinations of input variables. (You need to test
all combinations if you're stripping whitespace, as some combination can
have a good format, another can have too much whitespace stripped)

Looks good, you can actually emulate a wifi card: modprobe mac80211_hwsim

https://github.com/vyos/vyos-1x/pull/331

Pull request: https://github.com/vyos/vyos-1x/pull/330

True, it doesn't currently work; that patch has various problems.

fingerprint = cmd(fingerprint_cmd, shell=True, stderr=DEVNULL)

I have converted this to

fingerprint = cmd(fingerprint_cmd,  stderr=DEVNULL, input=input=host_key)

ok will add the feature once the current set of patch waiting approval are in to not have to deal with rebasing etc :-)

The works also include the migration of template to separate files as per T2230

Yes, that would be useful, for example conf_mode scripts could print warnings that would go to the syslog when the config is applied on boot. Other scripts output is seen by the user anyway so I don't see a use elsewhere.

It will not intercept what is printed by executed programs. I could add an option for the functions to have stderr intercepted and printed by VyOS (causing program errors to go to logs)