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 T6097 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

PR https://github.com/vyos/vyos-1x/pull/3193
Extend config-sync for sections qos and system

vyos@r4# set service config-sync section system 
Possible completions:
   conntrack            Connection Tracking
   flow-accounting      Flow accounting
   option               System Options
   sflow                sFlow
   static-host-mapping  Map host names to addresses
   sysctl               Configure kernel parameters at runtime

Yes, as described in the issue, using dynamically added routes works fine. But I want to add the routes manually as I did before with the 1.3.x release.
Using both automatically added routes from PPPoE and setting them statically does not sound like a "sane" config to me.

I have also created a pull request that fixes this issue: https://github.com/vyos/vyos-build/pull/543

Delete set interfaces pppoe pppoe0 no-default-route will let it works. it is the same issue.

@tjh already backported

This is still an issue for 1.4.0-epa2.

Comparing to other vendors setting the password either in cleartext or as a salted hash (where when saved in config file its always saved as a salted hash - but it will accept a cleartext edition too if you wish that for whatever reason) through the CLI is the standard in NOS.

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

vyos@r4:~$ show conntrack table ipv4 
Id          Original src       Original dst         Reply src            Reply dst             Protocol    State        Timeout    Mark    Zone
----------  -----------------  -------------------  -------------------  --------------------  ----------  -----------  ---------  ------  ------
2589405901  192.0.2.14:37122   34.206.168.146:123   34.206.168.146:123   192.168.122.14:37122  udp                      99         0
931438034   192.168.122.14:22  192.168.122.1:56010  192.168.122.1:56010  192.168.122.14:22     tcp         ESTABLISHED  431999     0
4269448361  192.0.2.14:43882   34.117.118.44:80     34.117.118.44:80     192.168.122.14:43882  tcp         TIME_WAIT    116        0
821718377   192.0.2.14:36208   1.1.1.1:53           1.1.1.1:53           192.168.122.14:36208  udp                      n/a        0
vyos@r4:~$ 
vyos@r4:~$

@jestabro I have tested my usecase now and it seems the problem is fixed and the API no longer segfaults. Thank you so much for the fix and the fantastic turn around on this.

PR for 1.3: https://github.com/vyos/vyos-1x/pull/3130