Checked. Runs without errors

@natali-rs1985 Can you check and close it?

Closed invalid - this is done with nftables now.

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

Probably related:

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'

In T6221#182954, @fetzerms wrote:

I only created a vrf (but did not assign it to anything else). Is that intend to break connectivity?

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 T6096 talks about ipv6: This seems to break both ipv6 and ipv4 connectivity for me

Probably the same task https://vyos.dev/T6097

I only created a vrf (but did not assign it to anything else). Is that intend to break connectivity?

Thats common with other vendors aswell.

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

https://github.com/vyos/vyos-build/pull/553