Does disabling of vyos-configd has any impact in production?

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

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

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.

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

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.

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.

I haven't access to the Cisco one because that is configured by another provider:

I can reproduce the issue on our productive route in following way:

Why you closing the issue? Bug or issue is not resolved.

My expectation is that you can configure MTU 1500 at a GRETAP device to ensure same mtu at bridge. This solves a lot of problems caused by mixing host with different MTU size.
Larger frames that exceed pmtu and have df = 1 are fragmented and send to the gretap endpoint. Thus, underlay MTU has no impact of the communitcation between two hosts that are bridged via GRETAP and communicate with MTU 1500.

Iproute2 is too old and needs a newer version. So, we have to upgrade that package.

Fix should be easy implement in create function with following add in:

Thanks for the hint.

Did you read the error description? It doesn't look like.

Maybe I found the issue:

@Viacheslav Looks like it is already fixed with newer release then VyOS 1.4-rolling-202102141111.
I can also add the interface with newer release.

I will take at look if I can implement a short fix to generate IPv6 Link Local addresses on wireguard interfaces.

I have written an "fast" fix until tunnel is rewritten. Can you test it?