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

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

It's better to let this problem be solved by the migration to pftables (per T3286) instead of try and a band-aid over this isolated issue.

I opened T3285 to it. Once the switch to shutdownd is done, I'll incorporate a service that warns the user of an impending shutdown.

We don't find any solution right now. We test with different kernels/offloads/sysctl params but without result.
Additional topic
https://xcp-ng.org/forum/topic/2956/tx-dropped-in-pv-vm

Own build crux version from 13 Jan 2021 19:08 UTC - works properly
1.2.6-S1 - works properly
1.2.6 - affected (does not works)
1.4-rolling-202102040221 - works properly
1.3-beta-202102040443 - works properly

Yes, but since it won't solve the notification problem, these are separate concerns. Let's make a new task for migrating that script from atd to systems for scheduling reboots.

Hi,
I've been experiencing issues similar to what is being mentioned here. From my experience, I cant find any indication that the packet loss is related to packet size, it seems random.
Im running 1.4-rolling-202101270854 on XCP-NG 8.1.0. Confirmed on both Intel(R) Atom(TM) CPU C2758 and Intel(R) Xeon(R) CPU E5-2630 v3 machines. HW-checksumming turned off in XCP-NG makes no difference.

So it turn's out, while looking at the current status more closely, there is a lot of redundancy available which should be migrated away.

@Viacheslav , I tested in the 1.4 version, it seems that the neighborship is stuck in ExStart state with basic config. This behavior is not seen in 1.2.5 and 1.3
And also no frr.log is created.

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

To round out the effort, i've added an optional patch to the series which provides granular AAA/RBAC from ring0 and can also deliver the W^X functionality for userspace along with those functions.

Since 5.10 appears to be holding solid, and grsecurity is using 5.10 for their beta branch, i've completed the forward port of these core functions to the same kernel revision being used in the current branch (at the time of commit).
Whats the intent with Intel drivers there? If we want to pull in from Intel, i think we ought to do the same in-tree patch process to build and sign the modules at build-time (and enforce module signing validation to load at runtime).

It is also allowed in VyOS 1.2 but the Kernel errors out:

If you create a VIF and VIF-S interface with the same ID, the resulting device names collide:

This is caused by the omission of a call to conntrack --orig-dst in the new Python script.

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

I have successfully replicated this on 1.3-rolling-202101052023 and 1.4-rolling-202101240218. It's absent in 1.2.6. I'm going to investigate this regression.