Cilium 1.20 with kube-ovn chaining classifies node-local host traffic to a pod as world
Maintainer thường phản hồi trong vòng 2 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 30/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Lĩnh vực
- networking
Hướng nghiên cứu
Start by reproducing on a kube-ovn chained cluster with cilium-dbg monitor --type drop, confirming the SYN is dropped in tail_ipv4_to_endpoint (bpf_lxc.c:2477) with identity world, then bisect v1.19.5..v1.20.2 for the commit that stops carrying the host mark from to-netdev on ovn0 to the pod veth. Inspect the to-container ipcache path in bpf_lxc.c:2429-2444 where HOST_ID for reserved sources is discarded. Done means same-node host-to-pod traffic classifies as host again, with the fix carried as a patch under packages/system/cilium/images or reported upstream.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
On Cilium v1.20.2 with kube-ovn chaining, traffic from a node's host network namespace to a pod on the same node is classified as world instead of host. On v1.19.5 the same path arrived as host. Traffic from the host to a pod on another node is still classified correctly. The datapath runs generic-veth chaining with kube-ovn as the chaining target.
Any ingress rule keyed on world or host misfires for this traffic. The kube-ovn webhook and ingress-nginx admission policies had a fromEntities: [world] deny on the webhook port, so the API server timed out calling the webhook replica on its own node (failed calling webhook ... context deadline exceeded). #3343 replaces that deny with the two /1 CIDR halves of each address family. This only works around it for those policies. An allow rule with fromEntities: [host] on a default-deny endpoint would drop the same traffic.
The drop happens on delivery to the pod. cilium-dbg monitor --type drop shows the SYN from the node IP dropped in tail_ipv4_to_endpoint (bpf_lxc.c:2477) with identity world. The host mark is still there at to-netdev on ovn0 and is gone by the time the packet reaches the pod's veth. Without the mark, the to-container path falls back to an ipcache lookup. That lookup ignores a HOST_ID result for a reserved source (bpf_lxc.c:2429-2444 at v1.20.2), so the identity stays world. Setting enable-identity-mark=true does not change it, and bpf-lb-sock-hostns-only=false does not either. I haven't found the 1.20 change that caused this.
The real fix is in the datapath. Next step is a bisect between v1.19.5 and v1.20.2 on a kube-ovn chained cluster. With the commit found, either carry a patch under packages/system/cilium/images or report it upstream.
- Ngôn ngữ chính
- Go
- Star
- 2.2k
- Fork
- 209
- Merge trung bình
- 3 ngày 12 giờ
- Pull request đã merge (30 ngày)
- 230
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của cozystack/cozystack
-
e2e: cozyreport lists a shared zpool twice and ships an empty zfs-pools.txt that does not say whyĐang mởtriage/needs-triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
cozystack/cozystack#4809 · 1 reaction ·
Maintainer thường phản hồi trong vòng 2 ngày
-
area/ci kind/bug triage/needs-triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 85/100
cozystack/cozystack#4806 · 1 bình luận · 2 reaction ·
Maintainer thường phản hồi trong vòng 2 ngày
-
triage/needs-triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
cozystack/cozystack#4787 · 1 reaction ·
Maintainer thường phản hồi trong vòng 2 ngày
-
kubernetes-nodes: raising minReplicas does not raise the MachineDeployment's replicas on upgradeĐang mởtriage/needs-triage
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
cozystack/cozystack#4786 · 1 reaction ·
Maintainer thường phản hồi trong vòng 2 ngày
-
triage/needs-triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
cozystack/cozystack#4785 · 1 reaction ·
Maintainer thường phản hồi trong vòng 2 ngày
Tất cả issue của cozystack/cozystack
Issue tương tự
-
agent-research-recommend agent-review-finding chore
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
jordansmall/spindrift#4821 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
area:web
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
praetorianer777/GoTome#178 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
oracle/go-oracledb#105 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 84/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
Maintainer thường phản hồi trong vòng 1 ngày