Happy to take this on if someone can assign this to me.

It’s completely doesn’t work even with PBRD https://github.com/FRRouting/frr/issues/3160 (I didn’t check)

Use flowtable on all interfaces including tun.

I have not tested this in the latest version (1.5), so please excuse me if the issue has already been fixed there.

Version: VyOS 1.4.2 LTS
Release train: sagitta
Release flavor: generic

We are moving from legacy OpenNHRP (which is unmaintained) to an FRR solution.
Could you check the rolling release? It uses FRR nhrpd.

Could you send the minimum "set of commands" to reproduce?
Do you use a flowtable on tun or ethernet only?

An easy mitigation is to just update the command that is run to:

journalctl --no-hostname --boot -k | grep "ipv4-NAM-${6:0:15}"

The only issue with this as the only solution, is you could lose granularity in logging if you were to have names like:

test-test-test-1
test-test-test-2

Running show log firewall ipv4 name test-test-test-1 would return log entries for both names since the string would be ipv4-NAM-test-test-test-. That's where a warning could come into play, stating it is recommended to keep names to no more than 15 characters.

Need to check with the latest rolling release, as we have more flexibility in the bridge firewall. But command set interfaces bridge br0 ip adjust-mss '1377', with no extra config, most probably won't have desired effect.

Probably another task, but nice to have reset all connections soft in and soft out

vyos@r14:~$ reset ip bgp all 
Possible completions:
  <Enter>               Execute the current command

https://github.com/vyos/vyos-1x/pull/4538

Sorry to respond to such an old ticket but we stumbled over it now with a migration from VyOS 1.3.8 to VyOS 1.4.2.
After rebooting the system seems to have lost the configuration completely because it was not possible to logon to the system on the console anymore.
In the boot screen just a System error was shown.

It's not reproducible in rolling and @Viacheslav and @Andrii say they couldn't identify a commit that fixed it, so the root cause in older FRR is not known yet. We may get back to it in 1.4.4 or later.

@fernando Could you please re-test in the latest rolling release image?

The immediate cause of the errors above is a missing check, to be corrected in the first commit here:
https://github.com/vyos/vyos-1x/pull/4493
This exposes a second possible migration error from migration script vrf/2-to-3, corrected in the second commit of the PR.

I have tested the lab without IPSec for 3.5 hours - PIMD is alive

Same stuff see screenshoot:

Deploy a new VM with 1.4.2 copy configuration to the /config/config.boot (remove HW-id's), and reboot the router or execute load

Adding a simple condition seems to do the work:

@c-po is switching to 6.12 on the schedule at all?

Fun fact: removal of the DHCP assigned IP address in VyOS 1.3.8 only works if dhcp client runs on the native interface. If dhcp is run on a vif - this also does not work

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

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