Backport PR: https://github.com/vyos/vyos-cloud-init/pull/57

Similar tasks T2045, T1519

PR https://github.com/vyos/vyatta-cfg-quagga/pull/98

For 1.4 resolved in the https://github.com/vyos/vyos-cloud-init/commit/d385e3655e9eed77397136f5e27325a93719332d
Waiting several days for tests before doing a backport.

PR with fix is here: https://github.com/vyos/vyatta-cfg-firewall/pull/35

@pasik please see https://github.com/vyos/vyatta-cfg-system/pull/191

@marc_s Would you be able to open a PR against 1.3 ?

@trae32566 My apologies for the inconveniences. You are right. The criteria for triggering this action shall be narrowed down further.
It would be necessary to issue the warning if and only if such colliding peers also specify the exact same remote endpoint addresses (with empty endpoints also being accounted as to be the same).
In other words, we need to identify incoming peers and apply the rule only to them, not the outgoing ones which already have specific remote endpoint addresses statically defined.

This breaks a perfectly valid use case which I utilize regularly: using IPv4 + IPv6 peers with the same public key. Why would I want to create multiple keys for the exact same devices going over IPv4 and IPv6? If you want to include a warning, fine, but don't limit functionality based on someone's interpretation of how something will be used. I understand where this came from, but any time you limit functionality, you limit your users. As Donald Knuth once said:

Unix was not designed to stop you from doing stupid things, because that would also stop you from doing clever things.

@marc_s thanks for testing !

TLDR; confirmed fixed for 1.3, please backport.

Sure, it is fully compatible with 1.3. If no problems are found after the changes in 1.4 it must be backported.

@zsdc could we backport it to 1.3?

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

Fixed in https://github.com/vyos/vyatta-cfg-system/pull/188

In the 1.4 nat translations were rewritten, but I didn't delete the old python code yet https://github.com/vyos/vyos-1x/pull/1501

I need to reopen this, because after T3781 op-mode CLI references were reverted as well, and now we are in the strange situation when show_nat_translations.py is in the system, but CLI still refers to the old vyatta-nat-translations.pl.
The old script uses too much CPU and RAM, and can even crash on big conntrack tables.
We should backport updates from sagitta to op-mode scripts and replace CLI references to use them.

PR for 1.3 https://github.com/vyos/vyos-build/pull/258

@c-po @itspngu , as mentioned above, we have held off on implementing the fix, as there is a compelling argument to disallow whitespace in tag node names, just as it is disallowed in node names in general; making an exception in the case of tag node names invites problems going forward. On the other hand, thanks to the details that you provided, @itspngu, we can implement a workaround for the case of ssh-copy-id; I know of no other instance of the problem. If we do find a necessary use case of whitespace in tag node names in the future, the simple fix can then be implemented.

@itspngu you might try tomorrows rolling release and upgrade again. The issue should be resolved - it also helps us to see of the fix works!

In T4628#129192, @jestabro wrote:

Note that a fix for 1.4 will address the user's issue, as he is updating to 1.4-rolling, so the migration will take place upon booting into 1.4.

This is on hold, pending discussion on whether whitespace should be allowed in tag node names in 1.4.

Note that a fix for 1.4 will address the user's issue, as he is updating to 1.4-rolling, so the migration will take place upon booting into 1.4.