The PR was rejected but the task was never closed, closing now.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Jan 10 2024
Looks more like a support request to me. If any specific bug report or feature request turns up about this, feel free to create it.
If the issue reappaers and you find the reproducing steps, feel free to reopen.
Yes, this can be marked as completed.
Since it's an FRR behavior detail, there's nothing we can do about that. But we probably should disallow trying to match both IPv4 and IPv6 options in the same rule.
This is probably resolved already in 1.4 and 1.5, but we need to confirm that.
I am not able to reproduce this, and conjecturally it was fixed in kernel version updates subsequent to the report. Compare the fix for Equuleus in:
https://vyos.dev/T5684
and the kernel commit mentioned therein:
https://github.com/torvalds/linux/commit/9dcc38e2813e0cd3b195940c98b181ce6ede8f20
If the issue is still reproducible, feel free to reopen.
We made successful ARM64 builds since then, but if the issue reappears, feel free to reopen.
Done
vyos@r4# set high-availability virtual-server serv1 forward-method Possible completions: direct Direct routing nat NAT (default) tunnel Tunneling
Closing this until we have reproducing steps.
Closing this as resolved, please re-open if any further issues found.
Since the original vyos-vm-images is deprecated, I suppose we should close this for now.
Well-known behavior when you use VTI interfaces you have to use set vpn ipsec options disable-route-autoinstall otherwise you can get any unexpected things.
Are we going to just let EVPN be the L2VPN technology of choice and not go down the VPWS/VPLS route for L2VPN? EVPN is the future anyway, so going and adding VPWS/VPLS is kind of doing legacy work.
No longer applicable now that XDP is phased out.
We use the netavark plugin for the containers, which fixes this.
set container name alp01 image 'alpine' set container name alp01 network NET01 set container network NET01 prefix '100.64.0.0/24'
The kernel is not supporting pseudowire/VPLS now
this patch was never merged into the kernel
OK, a little digging around in the grub configs led me to a "workaround" solution for the serial console problem after the machine is booted.