Sat, May 11
Fri, May 10
Tue, May 7
Sat, May 4
Fri, May 3
Checked. Runs without errors
Thu, May 2
@natali-rs1985 Can you check and close it?
Fri, Apr 19
Apr 18 2024
Closed invalid - this is done with nftables now.
Probably related:
Apr 17 2024
thank you very much for your analysis. I am still wondering, why it breaks with adding the vrf and why it works before.
Also, why it starts to work again, after rebooting when removing the vrf again (but not before rebooting)
It is not related to VRF at all and is related to the policy routing logic:
Reproduced even on 1.3.2
set interfaces ethernet eth1 address '192.168.122.14/24'
Apr 12 2024
Apr 10 2024
The minimal configuration to reproduce:
set interfaces ethernet eth0 address '192.168.122.14/24'
Starting from the config above:
I am trying to narrow down how that happens, as my other experiments with vrf look fine.
I don't have any issues with your config, but my addresses (of course, I don't have all BGP VPN connections, etc.)
vyos@r4# set vrf name foo table 10101 [edit] vyos@r4# commit [edit] vyos@r4# [edit] vyos@r4# run show ver Version: VyOS 1.5-rolling-202404090019 Release train: current
Yup... it does not even come back after commit-confirm - so I assume something more severe crashes.
Unfortunately this also breaks after the commit (even tho the "commit" command finalizes). If I recall correctly, a commit-confirm won't reboot the box either - but I'll double check that.
Yes, let me try.
Could you try the latest rolling?
Ok. Just to clarify, as T6097 talks about ipv6: This seems to break both ipv6 and ipv4 connectivity for me
Probably the same task https://vyos.dev/T6097