This brings up an interesting issue: validate_value.ml could easily be modified to print warnings, while maintaining T2759 (namely, only print fatal errors if _all_ validators fail for a given setting), however, is this reasonable behaviour ? One would think that a 'validator' is either pass or fail, and if it is just giving a warning, it is no longer a validator.

I will take a look; thanks for the report !

Note, the host was upgraded from 1.2.8

PRs 1069 and 1070 will be merged

Adding set zone-policy zone SERVER interface SERVER to the presented test case should solve the issue. This is because the traffic needs to pass both eth1 and its associated VRF "master" interface, in this case TEST.

PR https://github.com/vyos/vyos-1x/pull/1071

From what I understand this looks to be due to https://github.com/vyos/vyos-utils/blob/master/src/validate_value.ml catching both stdout and stderr output from the validators and only printing the captured output if the validator exit status is 0 so there isn't a way to print warnings unless it always prints the output or handling for a special 'warning' exit code was added.

This issue should be fixed after these changes https://phabricator.vyos.net/T1970 (udevadm settle)
Tested on EdgeCore SAF51015I with generic ISOs.

Does not possible to reproduce this behavior on 1.3-epa3.

Certificates can be wound there:

loaded certificate from '/etc/swanctl/x509/R1.pem'
loaded certificate from '/etc/swanctl/x509ca/CA.pem'
loaded RSA key from '/etc/swanctl/private/x509_R1.pem'

This doesn't seem to help, whatever is calling the validator script seems to hide the output unless the exit status is non-zero.

https://github.com/pmacct/pmacct/blob/master/QUICKSTART#L603-L621

Try to restart vyos-configd after changing script file

A simple re-prdoucer is

Indeed, this looks like the commit

@anastrophe Describe please how to reproduce it?
Can be related to this commit d9b1c3df T2683

Hardcoded version of the fix for 1.4:
https://github.com/vyos/vyos-1x/pull/1068
https://github.com/vyos/vyos-build/pull/201

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997981

I did a quick test with 1.3.0-epa3 and this config loads in about 6 minutes in my VM (2 GB memory, 1 core at 1,6 GHz) at boot, some WireGuard config errors notwithstanding. After all the performance improvements, I think we can consider this resolved at this point.

FRR doesn't support it.

Just want to know, did you try rfc3768-compatibility?

It probably works that way.
Unfortunately that breaks other parts of our setup.

Duplicate T3655

Tested against 1.3.0-EPA3, same problem.