I think it is already fixed in T3674

@ramaxlo You can try to set this workaround:

In T3694#98436, @ernstjo wrote:

How to get the debug logs? I already enabled debug mode.

Tested configuration:

set interfaces ethernet eth1 address '192.0.2.1/24'
set interfaces ethernet eth1 address 'dead:beef:b004:3::1/64'
set interfaces tunnel tun0 address '2a0f:5707:b004:3::1/64'
set interfaces tunnel tun0 encapsulation 'sit'
set interfaces tunnel tun0 parameters ip ttl '255'
set interfaces tunnel tun0 parameters ipv6 hoplimit '255'
set interfaces tunnel tun0 remote '192.0.2.2'
set interfaces tunnel tun0 source-address '192.0.2.1'
set protocols static route6 cafe:e1f:b046:1::/64 next-hop 2a0f:5707:b004:3::2
set protocols static route6 cafe:e1f:b046:c000::/56 next-hop 2a0f:5707:b004:3::2

How to get the debug logs? I already enabled debug mode.

Try to touch frr debug to collect more information
https://docs.vyos.io/en/latest/debugging.html#frr

Have tried, but no luck.

It's a basic tunnel setup and also reproducible with routes which do not point to a tunnel interface and happens also with physical interfaces.

@ernstjo Can you share an example of your tunnel interface?
I don't understand yet how to reproduce it.
If you delete routes and add again, do you get the same result?

Want to test latest rolling iso, but equuleus seems to be stuck at vyos-1.3-beta-202107121144-amd64.iso which doesn't have this fix yet.

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

With 1.4-rolling-202107202017 at the latest l2tp over ipsec works with swanctl.

Will be available in the next 1.3 beta release.

PR https://github.com/vyos/vyatta-cfg-quagga/pull/85

set protocols static table 1 route6 ::/0 next-hop fe80::11 interface eth0
commit

To reproduce, without the "interface" option

set protocols static table 1 route6 ::/0 next-hop fe80::11
commit

Unfortunately, it seems that the same problem still happened. Although it seems that the container can be started normally after restart due to priority adjustment and some factors, it is not a normal operation result!

Also, the bug still present, fix for which I sent above in diff

vyos@r5-1.3-myb# compare 
[edit interfaces]
+vxlan vxlan0 {
+    mtu 1430
+    remote fe80::2
+    source-address fe80::3
+    source-interface eth0
+    vni 0
+}
[edit]
vyos@r5-1.3-myb# commit
WARNING: RFC7348 recommends VXLAN tunnels preserve a 1500 byte MTU

@c-po It seems doesn't work

No tried with 1.3 / 1.2. But problem has been solved with enabling ebgp multihop support, but both routers are directly connected.
Looks like an issue during the capabilities negotiation.