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

Another note—our current RPS implementation intentionally excludes core 0 from packet processing. If we want the default RSS behavior to mimic, this might mean we should be using N-1 queues where N is the number of cores. Whether this makes sense to carry over to RSS I'll leave open for debate.

Should RSS/ntuple be the default or should it be an opt-in "offload" setting?

Ack, I'm inclined to close this as a duplicate. What's the best way to mark the ticket?

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

I took some time to re-test this on recent rolling releases and it seemed mostly positive.

I've seen this a few times on the most recent 1.5x rolling releases. So far every stack trace has included the xfrm_input kernel function, so this tells me it is likely specific to when QAT is combined with the VTI feature (which switched from the vti interface type to xfrm type in 1.4).

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

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

I was hoping some combination of the newer QAT driver 4.24 and newer kernel in the latest rolling releases might fix this... but seemingly not.

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

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

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

There are two possible places where encrypted DNS support might be desired in a standard setup where VyOS is hosting a local resolver/recursor:

I even commented on that issue…
It would seem my memory ages out after 3 years 🤣

My system finally crashed again today. I found a workload that generates enough traffic over the VPN to reliably re-produce.

Hi -- this works. The VTI interface is just another interface so you can add it to a firewall zone just as you would an Ethernet interface. This can be done with existing site-to-site ipsec VTIs today. I also do it with OpenVPN interfaces for remote access on some of my installations.

For completeness let me link this back to discussion here: https://github.com/vyos/vyos-1x/pull/1024#issuecomment-1399908479
TL;DR I do not believe this bug needs to be re-opened, what was likely identified is a different, unrelated, limitation of pdns-recursor that affects the newer authoritative DNS functionality.

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

Obviously in a perfect world we get "unique" and "stable". I do think giving stability priority makes sense.

I surveyed all the hardware I have to see what kind of UUIDs they report:

Yeah, that seems reasonable to me. I would prefer not add clutter to the system node if it can be avoided.

That seems fair, basically make the DUID generation deterministic. There is some defined structure to the DUID format, I think this would be a "type 3 DUID" per this document: https://www.juniper.net/documentation/en_US/junose15.1/topics/concept/dhcp-unique-id-servers-clients-overview.html.

Adding a few notes here:

• The ideal behavior probably depends on which PKI elements are changed and what services depend on them.
• E.g. OpenVPN does not require a server restart for a CRL change (see https://openvpn.net/community-resources/controlling-a-running-openvpn-process/), but changing the CA or server cert/key would require a restart.
• It seems like there are some swanctrl commands that can conditionally reload parts of the config too without taking all tunnels down
• The former might be useful if you need to renew server certs or something like that and want to do so with the minimal impact

Pull request: https://github.com/vyos/vyos-1x/pull/1010

Tested on latest build VyOS 1.4-rolling-202109160217 and confirmed it is adding the remote id attribute by default as expected. Connections establish without issue.

Booted my host with 1.4-rolling-202109140217 and confirmed pfs enabled is now generating the expected swanctl.conf file to match the old behavior. If I don't report back in exactly an hour from now that my tunnels died, we can assume the fix works.

Note: config versions were added to the default configs here https://github.com/vyos/vyos-build/commit/23639568a945f19471af88547dab45b87bbd642d, but the current vyos-build-ami replaces the default file with its own that hasn't been modified to add the versioning comment yet. That can probably be fixed whenever that repo is updated for equuleus (I have my own patched local branch that I could publish if desired).

cc: @c-po maybe this was a side effect of unifying the two parsers

FYI, if your OpenVPN config relies on cert files or anything you uploaded into the config directory, you may need to change the owner to the openvpn user or widen file permissions. Oddly this only seems to affect equuleus, not sagitta (OpenVPN seems fine reading files owned by "root" out of "/config/auth").

Your revert appears to do the trick. Image booted fine with QAT enabled, and "show system acceleration qat status" shows the QAT device came up fine and is running happily.

Sure—if you want to drop me an image I can try it out. I do have a working vyos-build as well, I can also try and produce my own with that change backed out when I get some time towards the end of the week.

I will perform a few additional tests tomorrow with the oldest available rolling releases (looks like October 13th as of writing). Will see if I can binary search my way to when things broke.

A few updates... the failure still occurs on latest rolling. Similar outcome—the kernel panics and dumps a stacktrace during the initial boot-up configure process. However, this issue goes back further than I expected (and initially expressed in the ticket). I goofed up in my testing of 1.3-rolling-202010260327 by booting with a default config file without the QAT option.