I'll see if I can whip up a patch for the detail commands.

Because not all netadmins sits physically close to the devices being managed.

In T6445#191083, @Apachez wrote:

Yes but this is what the peer would do on its own - if the opposite device is lost in connectivity it can rollback to previous config which is enabled by default (that is history of configs).

It will delete all unused images
Did you try this command, as the command does not work?

@Viacheslav sorry, for some reason I didn't see this until now. I actually moved the routers to 1.4-epa3 to test whether it occurs on that version, and it does. Here are my conntrack stats after a week on 1.4-epa3 (note that I haven't started seeing connectivity issues yet, but I imagine I will in the next few days once I hit the limit):

trae@cr01a-vyos:~$ show conntrack-sync statist
cache internal:
current active connections:           403218
connections created:                 4998006    failed:            0
connections updated:                11289840    failed:            0
connections destroyed:               4594788    failed:            0

Included in PR:
https://github.com/vyos/vyos-1x/pull/3587

PR:
https://github.com/vyos/vyos-1x/pull/3587
Companion PR's listed therein.

Yes but this is what the peer would do on its own - if the opposite device is lost in connectivity it can rollback to previous config which is enabled by default (that is history of configs).

@talmakion Good catch! Thanks for contributing!

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

In T6445#191034, @Apachez wrote:

This can be handled just like "how others does it" as in if the peer is lost after a sync then the peer will automatically return to previous config.

This can be handled just like "how others does it" as in if the peer is lost after a sync then the peer will automatically return to previous config.

Swap/change/hide config entries are not implemented.
It is not a bug but a feature request.

The config-sync is not a HA.
I don't think config-sync should save, reboot, or do something else.
Imagine if, due to config-sync, you lose access to the secondary node and if it was saved by config-sync.

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

I've created a quick PR for this: https://github.com/vyos/vyos-1x/pull/3581

Sure, I will fill this report with the whole picture. At first the used configuration in both devices / ping test between the endpoints via the outer tunnel IPs first then via the inner IPs.

Please paste exact VyOS versions you have tested this with incl the config (in full or partial output of show config command | strip-private) of both VyOS and the opposite side.

We do have a procedure to reproduce it.

Do you get it now @FP1985 ?

please, read the guidelines that I shared, the point here if it works with our system , is not error in cli structure o functionality you should open a forum topic or support case (in case you have an active subscription), before opening a task here that is not clear.(without configuration ,debug attached or packet capture)

this is not a support request, we know how to configure tunnels and so on, we're not asking for it.

This is a support request

In T6439#190868, @Viacheslav wrote:

Should be fixed in T6373

I'm not sure if you've fully read what I've explained, but this is a regular GRE (IPv4 over IPv6) Tunnel configured in VYOS and in the Huawei Routers. The communication doesn't works in this specific case. If we do VYOS to VYOS then everything is alright. But VYOS to Huawei is not working at all.

please , read the guidelines on this post . it doesn't see a bug if not a support task:

If you add this config after the server is configured, it works as it requires a restart of the service

sudo systemctl restart accel-ppp@pppoe.service

Or reconfigure the service again

@L0crian Some TC combinations are affected by locks, so they are impossible to use with, for example, /16 networks.

Add the set of commands to reproduce.

Should be fixed in T6373

Great work, thanks for checking that case too.

This is without my patch applied, confirming both the problem and a workaround: