Closing, 1.3 has rewritten the perl code from scratch in python, but the functionality should be the same.

We could make compat-names a configurable option that defaults to disabled, e.g. "set interfaces openvpn vtunX tls compat-names {no-remapping}"

The implementation mostly works, but still behaves unexpectedly when keys don't have a BEGIN EC PRIVATE KEY or BEGIN RSA PRIVATE KEY, but have just a plain BEGIN PRIVATE KEY, which is valid for both EC and RSA (and is the default output format for openssl ec -out, for example when removing a passphrase from the key). We need to switch to checking the key type by actually trying to read it with openssl and checking its error status.

I'm not expecting a persisted-across-reboots FRR config — hence suggesting tmpfs — so when the system boots there is nothing there. Obviously something would need to create the (empty) FRR config files in tmpfs before running FRR, otherwise I expect all the FRR daemons will fail to start.

A router reboot last week reminded me to never to write mem in vtysh (but after looking it was automatic bij me :( )
The router booted with the configuration in FRR already loaded, and then Vyos tried to populate FRR based on the Vyos configuration and everything was broken :-)
It didn't help that the configuration i saved in FRR was a couple of months old.

We've seen this recently on bleeding-edge (yesterday's version) of 1.3. I'm currently investigating what tripped ospf6d, but I suspect it's going to be some Ubiquiti routers spewing their nasty OSPFv3 implementation.

ok, thanks! I can test on xen aswell, when the fix is in 1.3/rolling.

This fix is for 1.3 rolling only and should not be a problem on 1.2 as long as users do not explicitly set speed/duplex.

does this also affect vyos 1.2, or only 1.3/rolling?

also all calls to start-stop-daemon need to have a --oknodo option added

The code should be in the op-mode script rather than the class.But the PR was merged in, so I suppose it's ok.

https://github.com/vyos/vyos-1x/pull/263
https://github.com/vyos/vyatta-cfg-system/pull/121

PR262 should fix that last one @alien

I believe your default settings are not bad as, in our case, we are part of the ntp pool and our kit will use our own NTP servers :-)

Hello,
It's been a long time since the last comment.
Are there any real plans to add NETFLOW module to the next version (rolling release) ?
@mickvav Are you still using VyOS and this module? Would you be able to send me a version for 4.19.112-amd64-vyos ?

Deletion should be possible with tomorrows rolling release.

pushed https://github.com/vyos/vyos-1x/pull/261 which should fix the issue.
@lluu131 if you know how to use vi and only if you are sure you can run:

sudo vi /usr/lib/python3/dist-packages/vyos/ifconfig/ethernet.py +123

and you change CalledProcessError with RuntimeError

Please provide the VyOS version used

PR260 should fix this

PR259 fixes this

Another bug:

Same issue for me (1.3-rolling-202003221506). I needed to add this to the script "/usr/lib/python3/dist-packages/vyos/ifconfig/wireguard.py":

@wornet-mwo in 1.2.5 and rolling

Can confirm that this can be closed now.

@dmbaturin can you look 2 PR for implement option with ignore old transaction-script states?
https://github.com/vyos/vyos-1x/pull/255
https://github.com/vyos/vyos-replace/pull/7
Can we add this in 1.2.6?