User Details
- User Since
- Apr 2 2019, 2:39 AM (301 w, 3 d)
Dec 2 2024
Aug 20 2024
Aug 19 2024
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?
Aug 18 2024
Merged PR: https://github.com/vyos/vyos-1x/pull/3992
Aug 16 2024
I took some time to re-test this on recent rolling releases and it seemed mostly positive.
Aug 13 2024
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).
Aug 12 2024
Aug 11 2024
Aug 10 2024
Aug 1 2024
Jul 31 2024
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.
Jul 30 2024
Jul 29 2024
Jul 22 2024
Jul 21 2024
Jul 16 2024
Jul 7 2024
There are two possible places where encrypted DNS support might be desired in a standard setup where VyOS is hosting a local resolver/recursor:
Apr 15 2024
I even commented on that issue…
It would seem my memory ages out after 3 years 🤣
Apr 14 2024
My system finally crashed again today. I found a workload that generates enough traffic over the VPN to reliably re-produce.
Apr 12 2024
Apr 7 2024
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.
Mar 28 2024
Mar 27 2024
Mar 12 2024
Mar 11 2024
Dec 30 2023
Dec 29 2023
Jan 23 2023
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.
Apr 5 2022
Dec 9 2021
Oct 12 2021
Oct 11 2021
Obviously in a perfect world we get "unique" and "stable". I do think giving stability priority makes sense.
Oct 10 2021
I surveyed all the hardware I have to see what kind of UUIDs they report:
Oct 5 2021
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.
Oct 3 2021
Sep 27 2021
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
Sep 20 2021
Sep 19 2021
Pull request: https://github.com/vyos/vyos-1x/pull/1010
Sep 17 2021
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.
Sep 15 2021
Sep 14 2021
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.
Sep 13 2021
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
Sep 11 2021
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").
Nov 14 2020
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.
Nov 12 2020
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.
Nov 10 2020
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.