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

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

I see. Thank you for explaining this.
Will this new storage continue to be public - or only for those with paid subscriptions?
If it will be public - will it be possible to mirror, to serve plain http to those who need it?

The current host is scheduled for decommissioning.
Future repositories will use object storage that doesn't support plain HTTP

I don't know how to solve this problem. I suggest rejecting the problem.

I've created a PR for this one: https://github.com/vyos/vyos-1x/pull/3590 covering both pieces - for Remote Port, if the PortID type is ifname, we use the PortID before falling through to Descr and so on. The detail view side of things is a straightforward call to lldpcli in this PR but could be improved.

In T6448#191156, @HappyShr00m wrote:

I have not used it since I thought it would delete even running instances or stop them. if it doesn't, then may I suggest adding a description to the command to indicate that it will not impact the running containers. thanks

Ok, auto-rollback might be a topic for another thread? Don't you think? OpenWRT does it, for example, and it has been useful to me in a few situations.

https://github.com/vyos/vyos-1x/pull/3588

In T6448#191124, @Viacheslav wrote:

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

Which original podman command are you expecting?

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: