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.
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.
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.
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 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
Fix PRs:
Addressed review on https://github.com/vyos/vyos-1x/pull/5342 (e17b4e433):
Addressed review on https://github.com/vyos/vyos-1x/pull/5341 (e1d43131f):
Addressed review on https://github.com/vyos/vyos-1x/pull/5340 (fe9ceb1ac):
add sys-rawio :
@Viacheslav if we could merge it soon that would be fantastic: https://github.com/vyos/vyos-1x/pull/5418
Hey @Viacheslav, sure, why not, give me a couple of days.
Commit for this is in my own fork until VyOS catches up to FRR 10.7: https://github.com/jvoss/vyos-1x/commit/b3f0f77de5fef0a380f015c21e739198d8a4598c
@ebowsky would you like to claim the task and add a PR?
I second that it should be at least well documented that setting this sysctl is required to allow non local binds. I had to introduce a check for it being active in my PR solving a regression with HAProxy (and other services relying on the same code path) here: https://github.com/vyos/vyos-1x/pull/5266
@jestabro can we close it?
Implemented in https://github.com/vyos/vyos-build/pull/1222