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

This contains another error, see more

Kernel 5.10.12

We need to change this and for CRUX

vyos@RTR1# run show version | match Version
Version:          VyOS 1.2.6-S1
[edit]
# Log
Feb  9 15:12:16 RTR1 ipsec_starter[2036]: # unknown keyword 'disableuniqreqids'

The root cause of this problem is that VYOS does not use CPU0 and therefore cannot enable RPS on a single-core processor

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

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

Looks like upgrading to 1.4-rolling-202102060218 finally fixed the issue for me. Now netstat shows 0 dropped TX, and my SSH connections are much more responsive.

@ajgnet which exactly version used in this case?

Also FRR seems to not like RIPng

Emergency recovery procedure:

grub> ls (hd0,msdos1)/boot/
#Figure out directory name, in this case, this is 1.4-rolling-202102040221

@c-po Why does the RPS setup function call fail, but the mirror error message is displayed?

This PR does the switch over.

This PR adds the notification script.

The pull request is created to fix this issue:

In T915#85657, @Cheeze_It wrote:

@daniil, I am not seeing this to be a problem on VyOS 1.4-rolling-202101151916. What specific version are you seeing this on?

@jestabro this is due to the key_mangling call for get_config_dict() - I wonder if we can exclude the mangling on the tagNode value itself and how JInja2 behaves with it.

PR https://github.com/vyos/vyos-1x/pull/722
Added sort command which provides some clarification on what the XML definition file will first in the list. It sorts by name.
So, in this case, the first XML file will be bcast-relay.xml

PR
https://github.com/vyos/vyatta-conntrack/pull/2

Fixed in T2997

As I see in VyOS 1.4-rolling-202102040221 the OSPF interface configuration is already under protocol section. Looks good.
So next up are ospfv3 and rip.

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.