Cilium 1.20 with kube-ovn chaining classifies node-local host traffic to a pod as world
维护者通常 2 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 30/100
- Issue 类型
- 缺陷
- 描述清晰度
- 基本清楚
- 活跃度
- 活跃
- 领域
- networking
调研方向
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.
由索引模型根据 Issue 内容生成。
描述
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.
- 主要语言
- Go
- 星标
- 2.2k
- 派生
- 209
- 平均合并
- 3 天 12 小时
- 30 天内合并 PR
- 230
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
cozystack/cozystack 的其他 Issue
-
e2e: cozyreport lists a shared zpool twice and ships an empty zfs-pools.txt that does not say why未关闭triage/needs-triage
难度 2/5 1-3 小时 新手友好度 76/100
cozystack/cozystack#4809 · 1 个 reaction ·
维护者通常 2 天内回复
-
area/ci kind/bug triage/needs-triage
难度 2/5 1-3 小时 新手友好度 85/100
cozystack/cozystack#4806 · 1 条评论 · 2 个 reaction ·
维护者通常 2 天内回复
-
triage/needs-triage
难度 2/5 1-3 小时 新手友好度 78/100
cozystack/cozystack#4787 · 1 个 reaction ·
维护者通常 2 天内回复
-
kubernetes-nodes: raising minReplicas does not raise the MachineDeployment's replicas on upgrade未关闭triage/needs-triage
难度 1/5 1 小时以内 新手友好度 88/100
cozystack/cozystack#4786 · 1 个 reaction ·
维护者通常 2 天内回复
-
triage/needs-triage
难度 2/5 1-3 小时 新手友好度 82/100
cozystack/cozystack#4785 · 1 个 reaction ·
维护者通常 2 天内回复
查看 cozystack/cozystack 的全部 Issue
相似的 Issue
-
kind/bug
难度 2/5 1-3 小时 新手友好度 76/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 4 天内回复
-
bug needs-acceptance
难度 2/5 1-3 小时 新手友好度 86/100
vllm-project/semantic-router#4744 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 78/100
jaegertracing/jaeger#9794 ·
维护者通常 1 天内回复
-
ScalingModifiers formula fails with "formula returned non-float result" when expression evaluates to an integer可能已有人在做 @Sarthak-Pandey 今天认领。 未关闭bug
难度 2/5 1-3 小时 新手友好度 73/100
维护者通常 1 天内回复