Won't do as the requested feature is in netcommon and more advanced. I see no point in re-creating it specifically in this collection

https://github.com/vyos/vyos-build/pull/1279

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

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

PR: https://github.com/vyos/vyos-build/pull/1278

@Viacheslav
I used an AI assistant to draft the write-up. The bug, the diagnosis and the production validation are mine — I've been chasing this for two days on a live HA pair. Happy to answer anything about the code.

if that helps, I worked on a fix for defect 2 and created a draft PR
https://github.com/vyos/vyos-1x/pull/5430

vyos-1x#5421 closed by jestabro: post-config.d is unused Vyatta-era and will not be returned in this form. docs#2217 closed to match. We keep an operator vyos-postconfig-bootup.script runner out of tree.

Addressed alexk37 2026-08-22 follow-up on https://github.com/vyos/vyos-1x/pull/5342 (a526ccdde; rebased onto current rolling):

Addressed alexk37 2026-08-22 follow-up on https://github.com/vyos/vyos-1x/pull/5340 (6d2ee03b2; rebased onto current rolling):

@Viacheslav which option would you choose for Defect 1 ? regex extension ?
I probably shoudn't have claimed this one, should I ?

Fix proposed in https://github.com/vyos/vyos-1x/pull/5429

@Viacheslav, sure

@rockfish do you want to claim the task and add a PR fix?

PR https://github.com/vyos/vyos.vyos/pull/499

FYI, this is meant for VyOS Ansible Collection but the "Submit Bug Report" link from the home page populates the form with the VyOS Rolling tag, and I was not able to update it.

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

Is there any update on this at all, please? Stream is still sitting vulnerable as far as I can see. Even a Stream 2006.03-1 with just an updated kernel would have been vastly preferable, versus no mitigation and no new Stream image for >3 months since the CVE disclosures (and five months since the last Stream release).

Reminder for myself, update initial post as soon as that is possible to:

There are all dependencies that were used for podman build https://github.com/vyos/vyos-build/blob/14d959fbb5ce0d2bf051c236b9050be81e17c885/scripts/package-build/podman/package.toml#L189-L198

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

Podman upstream has an open PR related to exactly this case: https://github.com/podman-container-tools/podman/pull/27033 ("healthcheck for non-systemd podman"). The current non-systemd implementation doesn't schedule health checks automatically, and that PR adds a scheduler for it.

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

If you need to temporarily resolve this issue, you can try increasing the number of all ethX (for example, starting the interface naming from eth100). I have a server with 8x E823-L ports and named them from eth101-eth108.

https://github.com/vyos/vyos-vpp-patches/pull/55

@canoziia we've discussed with maintainers, could you add a PR for the vyos-vpp-patches repo?

We should try to find the root cause.

If you don't mind I can post a report from LLM. Although it's long, I think it did find the problem.

Hello, I finally use 2 patches to solve this:

diff --git a/src/plugins/linux-cp/lcp_interface_sync.c b/src/plugins/linux-cp/lcp_interface_sync.c
index ca7638e..61db256 100644
--- a/src/plugins/linux-cp/lcp_interface_sync.c
+++ b/src/plugins/linux-cp/lcp_interface_sync.c
@@ -363,7 +363,7 @@ lcp_itf_interface_add_del (vnet_main_t *vnm, u32 sw_if_index, u32 is_create)
   const vnet_sw_interface_t *sw;
   uword is_sub;

Hi @canoziia
Our developers will review the suggested fix and add the correct patch for the rolling/patched version.

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

I am not a huge expert in VPP, nor DPDK, but I think the answer is simple enough to be done without deep expertize.

Correction - change 2 above was too broad, and rule 3 in the resulting list with it.

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