CI: Cilium L4LB XDP - NAT46x64 test

[rastislavs]

CI failure

Error:

Run cd /home/runner/work/cilium/cilium/test/nat46x64 && sudo ./test.sh cilium 4f91a9ec07a4cb879bdd780a3e910b81ceda38de

...

Error: Cannot add/update recorder: [PUT /recorder/{id}][500] putRecorderIdFailure  loading eBPF collection into the kernel: program tail_lb_ipv6: load program: argument list too long: BPF program is too large. Processed 1000001 insn (2474 line(s) omitted)

Hit on two different PRs already:

• https://github.com/cilium/cilium/actions/runs/5175665325
• https://github.com/cilium/cilium/actions/runs/5175441653

Sysdump could not be retrieved due to an error:

Run sudo cilium sysdump --output-filename cilium-sysdump-out
🔍 Collecting sysdump with cilium-cli version: v0.14.5, args: [sysdump --output-filename cilium-sysdump-out]
failed to create sysdump collector: failed to detect Cilium namespace: Get "http://localhost:8080/api/v1/namespaces/kube-system": dial tcp [::1]:8080: connect: connection refused

[sayboras]

Happens in the below as well

PR: #25711
Run: https://github.com/cilium/cilium/actions/runs/5161149871/attempts/2

[julianwiedmann]

The funky thing is that the same test then succeeds when re-running.

[sayboras]

seems like I am not lucky enough, 5 failures and counting

https://github.com/cilium/cilium/actions/runs/5161149871

[julianwiedmann]

Looks like a complexity regression in the verifier, I see

good run: 5.15.0-1036-azure
bad run: 5.15.0-1038-azure

And as GH is slowly updating their fleet, we now probably end up on bad kernels more often and fail consistently.

[rastislavs]

It seems that #25826 resolved the issue, the test is passing on my PRs after rebasing.