Have tried as you suggested, and confirmed it works.

I can confirm that happens only if you ssh via vrf and set static route6 in default vrf
And it works without debug, if you stop vyos-configd service

I can reproduce this issue on different routers (Baremetal or VMs). Debug mode on, ipv6 routes install. Debug mode off, static route config is missing in frr, thus not installed into the kernel.

Do you use standard user (vyos) or not?
yes, standard vyos user

I can't reproduce it in any version.
Let's check what is different, and why only in your case do you have a problem, but other users never have this issue.

The latest .deb with fixed in pr above

It happens on different versions and not fixed in the latest version.

No issue on 1.4-rolling-202107191536 and later.

Interesting. But I never saw it.
Can you check the latest rolling? I have no other ideas yet.

Just that shitty. When i enable debug mode route install works fine when i disable debugging i won't work.
I have that situation on multiple routers.

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

[email protected]# compare 
[edit interfaces]
+vxlan vxlan0 {
+    mtu 1430
+    remote fe80::2
+    source-address fe80::3
+    source-interface eth0
+    vni 0
+}
[edit]
[email protected]# 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.