Currently I'm not sure, might be related to changes from T4519

please , Could you share configuration on how to replicate it ? it's also here the guideline about report a bug :

The suggested change as in matching number of "x" with number of characters in each octet/hextet in the IPv4/IPv6 address will be less anonymizing than todays method.

@blueish want to do a docs article for this?

If you can use the APT then you can create mirror as well - the same way APT talks to the repository. There is no need for additional protocols like rsync.

Draft PR Added: https://github.com/vyos/vyos-1x/pull/3599

Can this be assigned to me please, will give it a go.

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

Will pull that on Sunday and give it a try, thanks!

Required updates in reusable workflows done.
Please approve/merge https://github.com/vyos/vyos-1x/pull/3596

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

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

In T6448#191159, @Viacheslav wrote:

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

It should not affect running container images.
Try it on some test instance.

what about moving the dhcp high-availability configuration under the existing high-availability node? that would allow the entire dhcp section to be synced.

@fatred fix should be in the latest rolling, if you'd like to give it a go?

PR for 1.5: https://github.com/vyos/vyos-1x/pull/3592

Public - yes.
Mirroring is not sure, as object storage does not support rsync, but maybe other tools can do it.

Tested as working in: VyOS 1.5-rolling-202406060020

At the meeting, we concluded that tables should not intersect with protocols static table x
This PR was just to make this use case when they intersect and have a more flexible configuration.
Without using the same tables, it makes no sense in this PR.
That's why it was closed

Care to elaborate on why this became "wontfix"?

Resolved by T6006.

Resolved by PR merged in T6006.

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