This command doing not what you are expecting. It shows virtual VRRP interfaces running in RFC3768 compatibility mode. Add the rfc3768-compatibility option to a VRRP group and a new virtual interface should be listed in the output.
If you want to change this behavior, please describe how exactly.

Possible by backporting https://github.com/vyos/vyos-1x/pull/452 and https://github.com/vyos/vyatta-cfg-system/pull/125 though I think some code using Config would need to be modified - add .exists calls before each .return_value(s) - 1.3's vyos.config doesn't require them, 1.2's I think does.

Ok, nice. And how about 1.2? Is it possible to fix this with the 1.2.6 release?

This is already fixed in 1.3

The user-data dir actually is preserved on upgrade, it's just the check that is faulty. Need to look into it.

It looks like this bug is in the kernel.
1.2.5 - 4.19.106-amd64

No, seems to be fixed! I was pretty sure it was upstream, must be resolved now.

Could anyone test if it's still reproducible?

When googling on the error given, T109 shows up where I had posted about this in 2018. I'm not sure it's related to this. Im not sure any configuration has been lost on reboot.

https://phabricator.vyos.net/T1564

Also in 1.2.5

vyos@vyos:~$ show protocols bfd peer 10.203.42.1 
% Unknown command: show bfd     peer 10.203.42.1 local-address 10.203.42.254 vrf default
vyos@vyos:~$ 
vyos@vyos:~$ show protocols bfd peer 10.203.42.1 counters 
% Unknown command: show bfd     peer 10.203.42.1 local-address 10.203.42.254 vrf default counters
vyos@vyos:~$ 
vyos@vyos:~$ 
vyos@vyos:~$ show version 
Version:          VyOS 1.2.5

I did some tests and the only problem appears when adding a route-map to ipv6.

@lawrencepan your configuration not committed because,

1. "route-reflector-client" can be used only when remote-as and local-as are equal

Try to check your commit.
You wiil see

PR for 1.2: https://github.com/vyos/vyatta-cfg-system/pull/124

PR https://github.com/vyos/vyatta-cfg-quagga/pull/48
Also added the second commit which fixes the path to zebra daemon

BGP Router ASN 65001 .
PeerGroup ipv4 & ipv6 ASN65002

Hello @lawrencepan , can you explain, why you need different AS for route-reflector-client?
Can you add your route-maps ROUTE-V4 and 'ROUTER-V6?

@jjakob, yes, thank you.
PR for 1.3: https://github.com/vyos/vyos-1x/pull/434
I will summit PR for 1.2 once 1.3 is released and tested.

Just to confirm, increasing the route,max_size fixed this issue completely. I think it can be closed. But maybe we should set these settings by default before closing this.

I think the way to do this is in src/conf-mode/interfaces-ethernet.py in apply(), don't change the interfaces mac if eth['is_bond_member'] is set.

@runar, thanks for clarification! I will change the initial description accordingly.

To clarify the hw-id tag. This is the only way VyOS scripts know what interface to give what name on bootup, as the boot-order of nics could be different on every reboot (potentially) vyos needs a way to identify the "correct" order of the nics when it boots. if you remove the hw-id tag from the interface the configuration script don't know what interface to give the configuration to, so you could potentially get nic-reordering on every single reboot.

https://github.com/vyos/vyos-cloud-init/pull/10

This PR should built proper images