1.4-rolling-20220418
Issue is still not fixed

Adding logs. dhcpv6 configured for interfaces eth0 and eth3. Depending which starts first, the other one fails and gives "unexpected interface":

At least dhcpv6 address assign correctly, VyOS 1.4-rolling-202204162001

set interfaces ethernet eth2 address 'dhcp'
set interfaces ethernet eth2 address 'dhcpv6'
set interfaces ethernet eth3 address 'dhcp'
set interfaces ethernet eth3 address 'dhcpv6'

Show interfaces:

vyos@vyos:~$ show int
Codes: S - State, L - Link, u - Up, D - Down, A - Admin Down
Interface        IP Address                        S/L  Description
---------        ----------                        ---  -----------
eth0             -                                 u/u  
eth1             -                                 u/u  
eth2             100.64.20.21/24                   u/u  WAN01
                 2001:db8:23::934f/128                  
eth3             100.64.30.21/24                   u/u  WAN02
                 2001:db8::934f/128

In dhcpdv6.conf I have added the following to support Cisco VoIP phone provisioning over IPv6:

It was a lot of issues with it in openvpn.
So we decide to avoid to use raw options
Let us know which options do you need?

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

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

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

I would like to call it system-as(n)

Of course. This restriction comes from the communication providers. Through (VPN) - everything works well.

Review code: https://github.com/vyos/vyos-1x/blob/current/data/templates/firewall/nftables-nat.tmpl#L141-L142

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

Tested in VyOS 1.4-rolling-202204130521
All works, thanks!

@fernando can you take a look at this one.
maybe we will need report it to FRR team

The issue with this check
A possible original issue with the function exists as it checks the only first value

bond
  member
    - eth2
    - eth3

It returns only eth2 as a member of the bonding

Relevant configuration on one PE router:

Large packets fastnetmon/podman

30 largest packages in 1.4 dev build:

telegraf 144 MB
linux-image-5.10.109-amd64-vyos 107 MB
libwireshark14 100 MB
vyos-linux-firmware 68.8 MB
containernetworking-plugins 51.2 MB
vyos-http-api-tools 40.4 MB
podman 37.3 MB
python3-pycryptodome 36.0 MB
libicu67 33.9 MB
vim-runtime 32.9 MB
vyos-1x 29.2 MB
libperl5.32 28.5 MB
salt-common 27.9 MB
nmap-common 21.2 MB
frr 20.2 MB
libruby2.7 17.9 MB
coreutils 17.9 MB
perl-modules-5.32 17.9 MB
grub-common 17.8 MB
systemd 16.4 MB
locales 16.4 MB
libc6 13.1 MB
pmacct 13.0 MB
ieee-data 12.3 MB
vyos-intel-qat 11.7 MB
aptitude-common 10.3 MB
gdb 10.0 MB
udev 9,184 kB
grub-efi-amd64-bin 8,831 kB
squid 8,582 kB

This seems to be Cloudflare's doing, not ours. We're investigating this issue.

smoketest https://github.com/vyos/vyos-1x/pull/1283

Theoretically, must be fixed in https://github.com/FRRouting/frr/pull/11004

For some reason is_bond_member is not in the configuration after the description
eth2 with option is_bond_member
eth3 without option is_bond_member

############## MY DEBUG START: 
{'description': 'fofof',
 'duplex': 'auto',
 'hw_id': '50:08:00:01:00:03',
 'ifname': 'eth3',
 'ip': {'arp_cache_timeout': '30'},
 'mtu': '1500',
 'speed': 'auto'}
####### MY DEBUG END #######

regarding this behavior , I found a similar task where there was a bug with chain VYOS_PRE_SNAT_HOOK that jumps to WANLOADBALANCE ,although it was solved .
However , policy traffic rule seems to be affected with this issues(the main difference is that now there is a pass on this chain/ POSTROUTING) , below I'll share the task just to know where you can find the problem.

Did similar tests with your big config >20k lines:

teleport Linux 64-bit DEB - 94 Mb
https://goteleport.com/teleport/download/

@n.fort I have upgraded following the path 1.2.6-S1 --> 1.3-S1 --> 1.4 Following the tips of not using port names for bootps and ssmtp and not using "set system ipv6 disable" and everything went fine.

VyOS 1.4-rolling-202204090217 works well.

I've tested the scenario using VyOS 1.4-rolling-202204090217 and (esp lifetime '30'). Attached is the config.
After turning on the right and left routers, IPsec creates two tunnels that are updated every 10 seconds. (Tunnels are updated using strange intervals, the first 1-10 seconds, the second 10-20 seconds).

@hakwerk I'm sorry for the delay of the response. It seems that this PR(https://github.com/vyos/vyos-vm-images/pull/28) fixes the enable_dhcp issue.
I can't reproduce the install-grub issue for now. If I get the warning, I will try to fix it.

VyOS 1.3 and 1.2 use the legacy Perl based IPSec implementation. A test would still be good just to be sure!

I tested it with VyOS 1.4-rolling-202204090217 and it works well for a while.