Numgen has GOTO directive and not Jump (Phil asked to change it), I thought it means after hitting any chains in numgen the processing will go back to service chain, no?
It is Ubuntu 18.04
sbezverk@kube-4:~$ uname -a
Linux kube-4 5.4.10-050410-generic #202001091038 SMP Thu Jan 9 10:41:11 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
sbezverk@kube-4:~$ sudo nft --version
nftables v0.9.1 (Headless Horseman)
sbezverk@kube-4:~$
I also want to remind you that I do NOT use nft cli to program rules, I use nft cli just to see resulting rules.
If you need to enable any kernel/module debugging or try some debugging code, please let me know I am opened, also live debugging session on my server is also possible. This issue has a very high priority as it would be a real show stopper in kubernetes environment.
Thank you
Serguei
On 2020-01-20, 4:39 PM, "Florian Westphal" <fw@xxxxxxxxx> wrote:
sbezverk <sbezverk@xxxxxxxxx> wrote:
> Changed kernel to 5.4.10, and switch to use "inc" instead of "random". Now first curl works and second fails. Whenever second chain is selected to be used, curl connection gets stuck.
>
> chain k8s-nfproxy-svc-M53CN2XYVUHRQ7UB {
> numgen inc mod 2 vmap { 0 : goto k8s-nfproxy-sep-TMVEFT7EX55F4T62, 1 : goto k8s-nfproxy-sep-GTJ7BFLUOQRCGMD5 }
> counter packets 1 bytes 60 comment ""
> }
>
> chain k8s-nfproxy-sep-TMVEFT7EX55F4T62 {
> counter packets 1 bytes 60 comment ""
> ip saddr 57.112.0.41 meta mark set 0x00004000 comment ""
> dnat to 57.112.0.41:8080 fully-random
> }
>
> chain k8s-nfproxy-sep-GTJ7BFLUOQRCGMD5 {
> counter packets 0 bytes 0 comment ""
> ip saddr 57.112.0.52 meta mark set 0x00004000 comment ""
> dnat to 57.112.0.52:8989 fully-random
> }
>
> Any debug I could enable to see where the packet goes?
The counter after numgen should not increment, but it does.
Either numgen does something wrong, or hash alg is broken and doesn't
find a result for "1".
There was such a bug but it was fixed in 5.1...
please show:
uname -a
nft --version
