An analysis of the code base from VyOS 1.2 -> 1.3 -> 1.4 revealed the following "root-cause"

VyOS 1.4 uses persistent OpenVPN interfaces.

In T3782#102239, @trystan wrote:

I can confirm that applying

Possible bug after this commit https://github.com/vyos/vyos-1x/pull/621/commits/ede2972be4c49962a04b1addb9df6ce58f2d9f42
As it works in vyos-1.3-rolling-202011 before that commit.

1.3 fixed in T3779

The issue may be with OpenVPN/dynamic interfaces only, without the option "persist".
In that case, if no connectivity between interfaces it tried to re-add the interface "down/up" vtunX with a new SNMP index. And it will be in the loop until connectivity will be restored with the remote site.

This can be done via the tc kernel module AFAIK. Something like fireqos would be great to have in here, but they're pretty opinionated in how they do things in their tools so probably not a viable drop-in solution.
This can also be done with OSSEC using active response, either by building an OSSEC agent into the image (client key management is kind of a PITA) or by way of remote feed for FW log events showing attempts to connect with an active-response script to temporarily block the offenders with progressively longer blocks on repeat offenses.

lshw does this already

Difference between 1.2 and 1.3
1.3 don't have option qdisc ingress ffff: dev eth0 parent ffff:fff1 ----------------

I added the kernel netflow module to my pull request a while back - collects and forwards flows to a destination defined in the module parameter set at load-time.
If we want to actually process flows on-system, there's a bunch of modern tooling for that; but in terms of just aggregation and export in canonical format, the kernel module is the best way to go IMO due to the fact that it works at the same tier as the network code itself (ring0).

Not seeing this issue when setting "description" field - we've run it in production for years bridging our OpenStack and datacenter environments, and the names show up correctly (blanked sensitive details):

From a post-exploitation perspective, this would permit attackers who've compromised an older vulnerable version to persist their payloads in the shell elements (~/.bashrc and friends) across upgrades.

This seems similar to the "configuration drive" option for OpenStack, which is already handled by cloud-init. Might be handy to implement as a cloud-init local data source and just include CI on all builds since thats becoming an industry standard even on bare metal.

How about CLI set system syslog atop file 5
That means save the latest 5 files.

I've managed to get this working in our own builds by restoring the openstack target and making some changes there - runs fine in AWS, even with a grsec kernel and hardened userspace (Xen is often the worst visor for ring0 memory defenses).