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.

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

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?

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!

PKI Wireguard PR: https://github.com/vyos/vyos-1x/pull/929

Can you send more examples how it looks like in podman cli?
Which parameters do you set, and how to check if it is successfully applied?

Can you please try running this test on a more recent VyOS version?

brctl is a deprecated package and superseeded by iproute2. Commands will be adjusted, thanks for reporting.

@jingyun Can you describe more details?

note: Record the process of upgrading from 1.4-rolling-202107010537 to 1.4-rolling-202107122017

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

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

Thanks @jestabro this seems like a good place to start learning VyOS internals, will give it a go when I have some off time and submit a pull request.

@artooro This sounds reasonable, and I don't imagine a problem, though I have yet to try it; if you would like to submit a pull request with fix, I will review.

Most likely related to T3505

This error occurs because the ipsec module blindly updates the l2tp module after a commit change to ensure any l2tp via ipsec config is then refreshed also.

Workaround for missing DHCP default route:

Parent task: https://phabricator.vyos.net/T2816

Other instances:

@sdev It still shows the ikev2 as the default version in the output.
I agree with your point that strongswan has changed the default version. A quote from their documentation: "Since 5.0.0 both protocols are handled by Charon and connections marked with ike will use IKEv2 when initiating, but accept any protocol version when responding."

@Viacheslav but that sounds more of a decent FRR bug. We could still consider adding EIGRP support for 1.4