@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 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

Hello, I found this is because the lcp_nl_resync operation is a potentially long-running full netlink synchronization, but the VyOS wrapper invokes it with the generic VPP PAPI response timeout of 5 seconds.

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

I had a thought about this today, and I think a more immediate fix for this specific issue could simply be replacing these lines in the nftables.j2 templates:

"{%     if ipv4.forward is vyos_defined %}"

With these lines:

"{%     if ipv4.forward is vyos_defined and ((ipv4.forward.filter | length) > 1 or ipv4.forward.filter.default_action == 'drop') %}"

So if someone has anything other than default-action configured, like description, then it will generate that chain. Or if default-action is configured as "drop", as that differs from the <defaultValue> element. But this could maybe be a better fix for this specific issue, and be a better backport candidate if it is deemed so.

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

PR for podman build fix: https://github.com/vyos/vyos-build/pull/1277

Three changes came out of review and testing on PR #5392. Two of them narrow or widen what verify() accepts relative to the original description above, so the rules listed there are superseded by the list at the end of this comment.

The Pull Request is merged. This can be closed. I can't edit the task, because I get the error, that i can't change the edit policy.

A PR has been raised for this here: https://github.com/vyos/vyos-1x/pull/5422

It seems we may need the both features: the one requested by this ticket, and the one that also allows for configuration in a form of flat, 'set/delete' commands?

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

Fixed in the https://vyos.dev/T8329 for the rolling
https://github.com/vyos/vyos-build/pull/1249
https://github.com/vyos/vyos-1x/pull/5338

Fix PRs: