- Feed Queries
- All Stories
- Search
- Feed Search
- Transactions
- Transaction Logs
May 4 2024
May 3 2024
What you're trying to achieve seems to be a derivate of https://www.wireguard.com/netns/
How was this configuration achieved? Or is it manually crafted?
Upstream bug https://github.com/FRRouting/frr/issues/15912 fixed in https://github.com/FRRouting/frr/pull/15913
May 2 2024
Upstream bug https://github.com/FRRouting/frr/issues/15912
something native would be more powerful
May 1 2024
Well looks like you hit a WireGuard limitation here (route-leaking the default nexthop to another VRF)
You probably should get the wireguard interface running in your default VRF first and see if traffic properly passes - once that's working for oyu you can move it into a VRF. Please not only the decrypted side of the WireGuard interface will reside in the VRF. The side passing encrypted packets ALWAYS is in the default VRF (Linux Kernel)
Apr 29 2024
Please note that the Wireguard tunnel itself is sourced from the default VRF. Only the "inner side" of the tunnel runs in VRF wan.
Apr 26 2024
Apr 24 2024
Apr 22 2024
So the root cause here is that vrf.py runs prior to vrf_vni.py where the first one eliminates all vni configuration within FRR.
The main reason for this weird logic is T5492.
Apr 21 2024
Apr 20 2024
Apr 19 2024
Apr 13 2024
There is also an inactivity timer in systemd-logind, but this will log you out even while running e.g. htop and just watching - I wonder if that's the preferred way :/
Apr 12 2024
Offending driver is intel_qat - try disabling QAT first.