Implementation; this may be slightly revised before PR, to provide extra data ...
https://github.com/vyos/vyos-1x/compare/current...jestabro:commit-schedule

Furher to this, manually setting "mru 1500" gives me my 1500 MTU back again.

The new MRU config in 1.3.4 seems to have caused my MTU to be lower.

Out of the blue it looks like some compile thats gone wrong?

What is the exact path within the chroot directory?

This will be fixed by merge of PR:
https://github.com/vyos/vyos-1x/pull/2371

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

Good point @Viacheslav apologies I was distracted at the time.
I can make it work by starting manually ( # ip vrf exec RCS3 zabbix_agent2 -c /run/zabbix/zabbix-agent2.conf )so I guess updating the systemd units file (/lib/systemd/system/zabbix-agent2.service) should make this work.

In T5657#162236, @bbabich wrote:

Yep looks fine @Viacheslav
I've been using it like this for a while now but figure it may be useful as part of making 'VRFs' complete...

$ sudo ip vrf exec RCS3 mtr 192.168.222.11

Yep looks fine @Viacheslav
I've been using it like this for a while now but figure it may be useful as part of making 'VRFs' complete...

@fsbof This change was accepted so it should end up in the 1.5 rolling soon. I suspect backporting to 1.4 wouldn't be an issue but that is a question for a more senior dev. But as for 1.3, I am unsure as I have never ran that version and don't know if there are any changes between those releases that would make it a pain to backport.

I was also affected by this issue. I could only update to 1.5-rolling-202309280022. Updates to more recent versions had the effect that after login I coudn't manage VyOS as I only had a standard linux bash.

Did you test it in vrf? Is it really works as expected?

@JeffWDH I am happy to download, build and test when you're ready if you point me to the right version(s)/location(s). I'm also very new to this but I managed to Build Equuleus in a docker container which has been working ok. Appreciate your efforts.

I've updated this to default to no ASCII art as I think it's cleaner, but added an option to show it if you want to see it:

Wow - you guys work quickly! 👍

I think it should be included, its often used during generation in Debian among other distros.

Fixed in https://github.com/vyos/vyos-1x/pull/2342

I wonder if we need the ASCII art though or not the plain fingerprints only (first line of the command)

I had a similar issue going from 1.5-rolling-202309250022 to 1.5-rolling-202310090023.

Then this task can be set to closed and invalid :-)

If you don't use the firewall (statefully at least) then it will go through the FW_CONNTRACK chain and the NAT_CONNTRACK and/or WLB_CONNTRACK chains will be reached, or fall through to the notrack.

But the NAT_CONNTRACK and WLB_CONNTRACK chains are never evaluted because FW_CONNTRACK always set action to accept?

That is how the conntrack enabling system works. FW_CONNTRACK verdict is set to accept when it is determined the firewall needs conntracking (state rules, flowtable etc.), same for NAT_/WLB_ chains. If none require conntrack - all chains will be return and it falls down the chain to the final notrack and conntrack is not enabled.

An additional "nice to have" would be a hook that runs on route state change.
Examples:

set protocols failover route 0.0.0.0/0 next-hop 100.100.100.1 hook '/config/scripts/failover-hook-100.100.100.1'

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

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

Once PR https://github.com/vyos/vyos-1x/pull/2344 is merged, counters and logs for default action should be available once again.

Problem remains with "N/D" is being used in show firewall groups instead of "None".

Verified in VyOS 1.5-rolling-202310090023: