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

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 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

In T6439#190868, @Viacheslav wrote:

Should be fixed in T6373

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

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:

If possible, can you try duplicating with more than one vni configured, then delete one of them? I'm pretty sure I tried that case a few weeks ago on an older 1.4 rolling with same issue. This was just the minimum config to reproduce.

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