The general direction seems really good. I would only invite @dmbaturin to share his view on two topics:

Yes, this is still relevant. While it may not be one of the top priorities, it is definitely one of the gaps we would be very happy to address.

We have not seen anything like this in our tests.

The default config for an image targeted for such platforms must contain set system console device ttyAMA0, which I think is still missing there.

In T8202#249474, @rh7819 wrote:

AF_XDP serves as the bridge between VPP and "soft interfaces". When packets originating from non-Ethernet interfaces (such as Wi-Fi, LTE, PPPoE, or OpenVPN) need to be processed inside VPP, it is the only available mechanism. it's required.

This is good - the problem seems more isolated now.

However, the problem comprises two distinct issues:

The version should follow the format: [epoch:]upstream_version[-debian_revision].

I believe the root cause of this memory leak lies in the default-originate route-map logic. This issue has already been addressed in the FRR upstream with the following commit: FRR Commit 74c1d4f

This appears to be a kernel issue.

I think we hit the same issue in 1.4.3. This is reproducible with the following configs:

The documentation part should be covered now by https://github.com/vyos/vyos-documentation/pull/1680

While technically this is not a VPP config validation error, I think something needs improvement.

@guerralucasdaniel7 Could you please share the topology map with all interfaces and networks included?

My opinion: the problem is not technical but rather lies in the documentation. Any attempts to change the behavior of set interfaces bridge br0 ip adjust-mss will result in losing important capabilities.

This should fix the problem: https://github.com/vyos/vyos-vpp/pull/37

Adding a simple condition seems to do the work:

The current fix is necessary, but it's not complete.

The problem exists because, in the latest builds, the config.boot.default file was moved to /usr/share/vyos/config.boot.default. Therefore, when Cloud-init searches for one of the config files to apply the initial configuration, it cannot find any - neither the main nor the default file.