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

set service config-sync mode 'load'
set service config-sync secondary address '192.0.2.1'
set service config-sync secondary key 'xxx'
set service config-sync section firewall
set service config-sync section interfaces pseudo-ethernet
set service config-sync section interfaces virtual-ethernet
set service config-sync section nat
set service config-sync section nat66
set service config-sync section protocols static
set service config-sync section pki
set service config-sync section vrf

Change some section:

vyos@r4# set nat source rule 100 outbound-interface name 'eth0'
[edit]
vyos@r4# set nat source rule 100 source address '10.0.0.0/24'
[edit]
vyos@r4# set nat source rule 100 translation address 'masquerade'
[edit]
vyos@r4# commit
INFO:vyos_config_sync:Config synchronization: Mode=load, Secondary=192.0.2.1
[edit]
vyos@r4#

Is this related to the long commit and boot times when one have more than a handful routes or firewall rules as described in https://vyos.dev/T5388 ?

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

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

I have tested FRR NHRP with IPv6 as an overlay and I found some issues.

In T6116#179637, @sarthurdev wrote:

Interfaces aren't added on boot because mac address is locally administered: https://github.com/vyos/vyos-1x/blob/current/src/helpers/vyos-interface-rescan.py#L60

Raised this issue before with @jestabro as also seen with VyOS as VM.

Can we let local-route support group options both in destination and source ?

set policy local-route rule 10 destination
Possible completions:
+  address              IPv4 address or prefix
   port                 Port number used by connection

PR for 1.4 https://github.com/vyos/vyos-build/pull/528

Interfaces aren't added on boot because mac address is locally administered: https://github.com/vyos/vyos-1x/blob/current/src/helpers/vyos-interface-rescan.py#L60

Did this test again, and I got the same result.

Close the task due to the reporter not responding.
Reopen if you still have this bug.

Seems fixed, checked on VyOS 1.5-rolling-202403110024

vyos@r4# rollback 
Possible completions:
  <N>	Rollback to revision N (currently requires reboot)

The similar task T5956

There are no old-style CLI definitions anymore, and thus no default: tags either, so this shouldn't be an issue anymore.

VyOS 1.5 will use Kea, while ISC DHCP is completely abandoned now and there's no hope this will be fixed.

The most frequently-used validators are already in OCaml now, for the rest we'll need to create separate tasks.

For 1.3 you have to add a separate PR

Do we need it for 1.3?
If yes, a separate PR should exist, as a backport is impossible.