Duplicate T2539

Add a smoketest to check if the required config options are present in the kernel configuration to prevent this in the future.

Yeah - its a bug when used in EVE-ng - closing

While i appreciate that you have an opinion of what's "best," i'm not re-summarizing 10+y of Linux out-of-tree history to spoon feed someone data they can, and should (like good engineers do), acquire on their own. Several of those patches are simply in-tree integrations for things currently built and packaged as kmods by VyOS on an LTS tree, the rest are well documented long running projects of their own which one must research and review the source code for anyway to properly understand their function and benefit.

It’s best to provide links to related descriptions instead of asking everyone to search for the related details and patch implementations you describe

@querubin thanks for the info; that requirement should not persist, as current work should lessen the overhead. I'll link the task back here when defined.

I think it was a bug with virtio drivers and bonding.

I can't reproduce it

Tried the latest rolling. It boots/runs if you give it 768MB of memory.
At 512MB it hangs as before. I guess minimum requirements will be
changing.

@querubin Thank you for the detailed results --- firstly, these issues may be overdetermined due to several updates earlier this month; one notable issue is that we had moved to a 5.x series kernel, which showed several problems re QAT support, and an identified kernel bug. We have reverted to 4.19 as of yesterday until the next LTS kernel is available. I would suggest trying the most recent rolling, and then we will diagnose any persistent issues.

In failover mode only one active channel with "best parameters" can be used for connections

@banditos13 Can you describe more details?
What is the bug and how to reproduce it?

Was fixed with https://phabricator.vyos.net/R6:0ecfe5a6d11065388714b0ef21de532f88774357 and T1241

Still present in the latest rolling

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

Fixed together with T2863 in commit https://github.com/vyos/vyos-1x/commit/d49845421dbd8d0f470b7122022543eb45d10b7a

Details can be found in T2843

Isn't it upgraded to 5.x? Why 4.x?

Due to the fact that transparent proxy, which was the default, is being removed for now, there will be in the first version 2 authentication modes, one is by IP address or network (nothing else would be required as long as you have the correct src IP) and LDAP (either anonym or with bind-dn to browse LDAP. I have both mechanisms already working via cli and about to clean up and test right now. If anyone need a special authentication mechanism, please let me know. I also disabled local file caches, since these days most traffic is https anyway, we can take some pressure off of the filesystem (ssd).

Tested in the latest rolling release and observed that after deleting the member interface, the assigned interface is remained in the admin down state.

Not quite sure if this is the right thing to do but, if a "delete protocols ospf" command is given the equivalent in FRR should be "no router ospf".

I attempted clean installations of VMs using both
vyos-1.3-rolling-202008301444-amd64.iso and
vyos-1.3-rolling-202009011736-amd64.iso. The first image boots up and
allows configuration. However, the latter hangs and never reaches a vyos
command line prompt. The last lines on the boot console are:

With VyOS 1.2 the default WireGuard behavior is used. This means that when a
WireGuard interface is added to the system, there is no "MAC" address - also
there is no IPv6 link-local address assigned by the Kernel to this particular
interface.

Unfortunately we must revert the Kernel upgrade as there are two problematic issues:

Which CLI commands did you use to trigger this error?

Fix will be in one of the next rolling releases, stay tuned!

Try a show ipv6 route ospfand look at the routes; they're probably being rejected:

trae@cr01b-vyos# run show ipv ro ospf
Codes: K - kernel route, C - connected, S - static, R - RIPng,
       O - OSPFv3, I - IS-IS, B - BGP, N - NHRP, T - Table,
       v - VNC, V - VNC-Direct, A - Babel, D - SHARP, F - PBR,
       f - OpenFabric,
       > - selected route, * - FIB route, q - queued route, r - rejected route

https://phabricator.vyos.net/T1483

@zsdc Any chance on this in 1.2.6?

@c-po , the same behavior even with kernel 5.8.8

vyos@R1:~$ uname -a
Linux R1 5.8.8-amd64-vyos #1 SMP Thu Sep 10 08:58:42 UTC 2020 x86_64 GNU/Linux