lbmap: Correct issue that port info display error

[Jianlin-lv]

The port info is stored in the bpf map in network byte order;

bpftool map dump pinned /sys/fs/bpf/tc/globals/cilium_lb4_backends
key: 02 00 value: 0a 00 00 55 00 35 00 00
key: 01 00 value: 0a a9 d0 d6 19 2b 00 00
key: 04 00 value: 0a 00 00 64 00 35 00 00
key: 08 00 value: 0a 00 01 db 00 50 00 00
key: 03 00 value: 0a 00 00 55 23 c1 00 00
key: 05 00 value: 0a 00 00 64 23 c1 00 00
key: 07 00 value: 0a 00 01 e6 00 50 00 00
key: 06 00 value: 0a 00 00 59 00 50 00 00

cilium map get cilium_lb4_backends
Key Value State Error
6 ANY://10.0.0.89:20480 sync
7 ANY://10.0.1.230:20480 sync
8 ANY://10.0.1.219:20480 sync

When displaying the given lbmap content, the port needs to be
converted to host byte order.

cilium map get cilium_lb4_backends
Key Value State Error
8 ANY://10.0.0.64:80 sync
6 ANY://10.0.1.158:80 sync
7 ANY://10.0.1.66:80 sync

Signed-off-by: Jianlin Lv Jianlin.Lv@arm.com

Fixes: #13243

[qmonnet]

test-me-please

[pchaigno]

Isn't the same issue present for the three IPv6 maps?

[Jianlin-lv]

Isn't the same issue present for the three IPv6 maps?

Thanks for reminding, I will check it.

[pchaigno]

test-me-please

[Jianlin-lv]

Isn't the same issue present for the three IPv6 maps?

@pchaigno I want to honestly let you know that I have not verified this patch in my test environment;
Because I don’t have an ipv6 experimental environment, today I spent a long time building k8s cluster that supports IPv4/IPv6 dual-stack networking, but the cilium agent only received ipv4 service information; I don’t know what is wrong, nor how to set up a pure ipv6 network in the cluster.
In short, I did not successfully verify the patch.

[pchaigno]

No problem, I was expecting this; IPv6-only clusters are a bit painful to setup. I think that's fine since we both tested on IPv4 and the change is fairly trivial. I'll ask on Slack how folks usually setup their IPv6-only clusters, but I don't think we need to block on that.

[qmonnet]

test-me-please

[Jianlin-lv]

Please note, I will append a new patch to this RP to fix a newly discovered issue tomorrow.

[borkmann]

Please also add some CI tests, verifying that the output of cilium service list, cilium bpf lb list and cilium map get cilium_lb*_backends works as expected.

I just looked at one of the sysdumps from the CI and see the following:

The cilium service list looks okay:

ID   Frontend             Service Type   Backend                   
1    10.106.162.7:3000    ClusterIP                                
2    10.111.80.118:9090   ClusterIP      1 => 10.0.0.83:9090       
3    10.96.0.1:443        ClusterIP      1 => 192.168.36.11:6443   
4    10.96.0.10:53        ClusterIP      1 => 10.0.1.62:53         

But the cilium bpf lb list doesn't (though it was correct before the PR):

SERVICE ADDRESS       BACKEND ADDRESS
10.106.162.7:47115    0.0.0.0:0 (1) [ClusterIP]   
10.96.0.1:47873       192.168.36.11:6443 (3)      
                      0.0.0.0:0 (3) [ClusterIP]   
10.96.0.10:13568      0.0.0.0:0 (4) [ClusterIP]   
                      10.0.1.62:53 (4)            
10.111.80.118:33315   10.0.0.83:9090 (2)          
                      0.0.0.0:0 (2) [ClusterIP]   

[Jianlin-lv]

Please also add some CI tests, verifying that the output of cilium service list, cilium bpf lb list and cilium map get cilium_lb*_backends works as expected.

I just looked at one of the sysdumps from the CI and see the following:

The cilium service list looks okay:

ID   Frontend             Service Type   Backend                   
1    10.106.162.7:3000    ClusterIP                                
2    10.111.80.118:9090   ClusterIP      1 => 10.0.0.83:9090       
3    10.96.0.1:443        ClusterIP      1 => 192.168.36.11:6443   
4    10.96.0.10:53        ClusterIP      1 => 10.0.1.62:53         

But the cilium bpf lb list doesn't (though it was correct before the PR):

SERVICE ADDRESS       BACKEND ADDRESS
10.106.162.7:47115    0.0.0.0:0 (1) [ClusterIP]   
10.96.0.1:47873       192.168.36.11:6443 (3)      
                      0.0.0.0:0 (3) [ClusterIP]   
10.96.0.10:13568      0.0.0.0:0 (4) [ClusterIP]   
                      10.0.1.62:53 (4)            
10.111.80.118:33315   10.0.0.83:9090 (2)          
                      0.0.0.0:0 (2) [ClusterIP]   

What you found is accurate, I have fixed this issue today and resolved the RevNatKey display issue.
After applying this patch, the execution result of lb cmd as follows:

root@jianlin:~# kubectl exec -it -n kube-system cilium-mzrbn -- cilium service list
ID   Frontend               Service Type   Backend
1    172.16.1.10:53         ClusterIP      1 => 10.0.0.199:53
                                           2 => 10.0.0.111:53
2    172.16.1.10:9153       ClusterIP      1 => 10.0.0.199:9153
                                           2 => 10.0.0.111:9153
3    172.16.1.1:443         ClusterIP      1 => 10.169.208.214:6443
4    172.16.1.13:80         ClusterIP      1 => 10.0.1.144:80
                                           2 => 10.0.0.236:80
                                           3 => 10.0.1.78:80
5    10.169.208.214:31427   NodePort       1 => 10.0.1.144:80
                                           2 => 10.0.0.236:80
                                           3 => 10.0.1.78:80
6    0.0.0.0:31427          NodePort       1 => 10.0.1.144:80
                                           2 => 10.0.0.236:80
                                           3 => 10.0.1.78:80
root@jianlin:~# kubectl exec -it -n kube-system cilium-mzrbn --  cilium bpf lb list
SERVICE ADDRESS        BACKEND ADDRESS
172.16.1.10:9153       10.0.0.111:9153 (2)
                       10.0.0.199:9153 (2)
                       0.0.0.0:0 (2) [ClusterIP]
172.16.1.10:53         10.0.0.111:53 (1)
                       0.0.0.0:0 (1) [ClusterIP]
                       10.0.0.199:53 (1)
0.0.0.0:31427          10.0.1.144:80 (6)
                       10.0.0.236:80 (6)
                       0.0.0.0:0 (6) [NodePort, non-routable]
                       10.0.1.78:80 (6)
172.16.1.1:443         10.169.208.214:6443 (3)
                       0.0.0.0:0 (3) [ClusterIP]
172.16.1.13:80         10.0.1.78:80 (4)
                       10.0.0.236:80 (4)
                       0.0.0.0:0 (4) [ClusterIP]
                       10.0.1.144:80 (4)
10.169.208.214:31427   0.0.0.0:0 (5) [NodePort]
                       10.0.1.144:80 (5)
                       10.0.1.78:80 (5)
                       10.0.0.236:80 (5)
root@jianlin:~# kubectl exec -it -n kube-system cilium-mzrbn -- cilium map get cilium_lb4_services_v2
Key                    Value                 State   Error
172.16.1.10:53         0 (1) [FLAGS: 0x40]   sync
172.16.1.10:9153       0 (2) [FLAGS: 0x40]   sync
172.16.1.1:443         0 (3) [FLAGS: 0x40]   sync
172.16.1.13:80         0 (4) [FLAGS: 0x40]   sync
10.169.208.214:31427   0 (5) [FLAGS: 0x42]   sync
0.0.0.0:31427          0 (6) [FLAGS: 0x2]    sync
root@jianlin:~# kubectl exec -it -n kube-system cilium-mzrbn -- cilium map get cilium_lb4_backends
Key   Value                       State   Error
5     ANY://10.0.0.236:80         sync
6     ANY://10.0.0.111:9153       sync
7     ANY://10.0.0.111:53         sync
8     ANY://10.0.1.78:80          sync
1     ANY://10.169.208.214:6443   sync
2     ANY://10.0.0.199:9153       sync
3     ANY://10.0.0.199:53         sync
4     ANY://10.0.1.144:80         sync
root@jianlin:~# kubectl exec -it -n kube-system cilium-mzrbn -- cilium map get cilium_lb4_reverse_nat
Key   Value                  State   Error
4     172.16.1.13:80         sync
5     10.169.208.214:31427   sync
6     0.0.0.0:31427          sync
1     172.16.1.10:53         sync
2     172.16.1.10:9153       sync
3     172.16.1.1:443         sync

[Jianlin-lv]

Fixed an issue that is when restarting cilium, Service`s port does not match;
Report by: https://jenkins.cilium.io/job/Cilium-PR-Runtime-4.9/1939/execution/node/100/log/

[Jianlin-lv]

test-me-please

[Jianlin-lv]

Squash commits into one.