CLI nodes already present under reset tree

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

PR for current: https://github.com/vyos/vyos-1x/pull/3776

This can be reproduced even without real hardware:

@a.apostoliuk if you accept the explanation above and the workaround suffices (as recently discussed), we will close this task.

Adding parent T6543 as contributing factor of issue in comment:
https://vyos.dev/T5991#178786

The biosdevname question is a matter for T5603; this task will be closed.

A version of this change will be part of T5528, only for Circinus initially.

I've checked this bug , it's still present the vesion 1.4./1.5 and the 1.3.x , this problem is related to the update of the new version (openvpn) where the syntax to create a tunnel tap (layer2) is changed , this command allow to transport frame and it's needed when you want to bridge a vtun :

@Viacheslav found the issue which I've documented below.

Spring cleaning PR:
https://github.com/vyos/vyos-1x/pull/3760

@Giggum The main reason for using ipaddrcheck is its speed (it's a compiled binary). Python is way too slow for validators due to the interpreter startup cost, so it's not an option until we completely overhaul the CLI backend. I'll look into the issue.

FRR issue is still open, no progress.

Since ISC DHCP relay agent is abandoned, I wonder if there are any chances of getting it fixed.

The critical issue was addressed in T5520, and the matter avoided with the move to revised image tools. No more to do on this at this point, and will close.

I agree with @Apachez: people should be able to disable IPv4 or IPv6 forwarding if they feel like it. For example, a router used exclusively as a looking glass or a load balancer arguably shouldn't forward any packets on L3.

Since the task as worded is no actionable, I'm closing it as invalid. I'm not against using any tools that might help us, but we need to be sure what the task is (e.g., to implement regular scanning, or to fix specific suggestions from a scan...).

No urgency here, so moving out of LTS.

No simple solution, so it should be done and tested in a development release first in any case, not in LTS.

Moving to 1.5 for now. If we are confident about the solution, we can backport it to 1.4 later. New architectures certainly should be introduced in development releases first.