Cilium cilium-dbg bpf ipcache delete 实战指南从 BPF IPCache 精确删除 IP 身份映射【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium你怀疑某个 IP 的 identity 记录错了导致策略误拦截。这时可以直接用 Cilium 的cilium-dbg bpf ipcache delete命令从 BPF IPCache 映射中删掉这条 IP 身份映射条目。该命令直接操作内核 BPF map删除精确、后果直接适合排障场景。命令速览一条命令删掉一个前缀条目语法模板只有一行cilium-dbg bpf ipcache delete PREFIX [--clusterid N]PREFIX是带前缀长度的 CIDR比如10.244.3.110/32。最小示例与成功输出$ cilium-dbg bpf ipcache delete 10.244.3.110/32 Deleted entry 10.244.3.110/320输出末尾的0是 clusterid即集群编号0 表示本集群。bpf ipcache命令族共 5 个子命令delete 负责删其余四个分别管查和写子命令职责delete按精确键删除一个前缀条目update插入或覆盖一个前缀条目可指定 identity、隧道端点等list别名ls列出全部 IP 前缀与 identity 的映射get给定一个 IP返回最长前缀匹配命中的 identitymatch给定一个前缀做精确匹配查询实现源码在 cilium-dbg/cmd/bpf_ipcache_delete.go父命令定义在 cilium-dbg/cmd/bpf_ipcache.go。为什么能精确删除LPM Trie 的键结构先说结论delete 是精确删键。它只删与你给的前缀完全相同的那个键不会连带动其他前缀。IPCache 在内核中是一个 LPM Trie 类型的 BPF map。LPM Trie 即最长前缀匹配树是内核原生支持的按前缀查找的 map。这个 map 名字固定为cilium_ipcache_v2每个 Agent 只有一份单例容量上限 512000 条。定义见 pkg/maps/ipcache/ipcache.go。键由 4 部分拼成Prefixlen前缀位数。它含一段固定偏移IPv4 的 /32 实际编码为 96 位ClusterIDclusterid多集群时区分条目归属Family地址族IPv4 或 IPv6IP16 字节地址字段IPv4 放在低 4 字节源码注释要求该结构与 bpf/lib/eps.h 中的struct ipcache_key保持同步。值则是该前缀的完整信息security identity安全身份编号、tunnel endpoint远端节点的隧道端点地址、IPsec 加密密钥编号以及标志位skiptunnel、hastunnel、ipv6tunnel、remotecluster 等。两个直接推论删一个 /32 条目不影响同网段的 /24 条目两者在 map 里是两个独立的键--clusterid参与建键。写入时 clusterid 是 1删除时你传了 0默认值构造出的键就不同自然删不到。动手三步走先查后删最后验证第一步确认执行条件在运行 Cilium Agent 的节点上执行以 root 权限执行。源码里有强制校验非 root 会直接拒绝。第二步用 list / match / get 确认目标条目$ cilium-dbg bpf ipcache list | grep 10.244.3.110 $ cilium-dbg bpf ipcache match 10.244.3.110/32 $ cilium-dbg bpf ipcache get 10.244.3.110match要求前缀完全一致才命中。get传裸 IP它遍历全部条目做最长前缀匹配返回命中的最长前缀对应的 identity。两者配合可以确认这个 IP 到底走了哪条条目。第三步删除并验证$ cilium-dbg bpf ipcache delete 10.244.3.110/32 Deleted entry 10.244.3.110/320 $ cilium-dbg bpf ipcache match 10.244.3.110/32 10.244.3.110/32 does not match to any ipcache entry完整增删演练先写入再删除$ cilium-dbg bpf ipcache update 10.244.3.110/32 \ --tunnelendpoint 172.21.0.2 --identity 6 --encryptkey 255 --clusterid 0 Updated entry 10.244.3.110/320 identity6 encryptkey255 tunnelendpoint172.21.0.2 flagshastunnel $ cilium-dbg bpf ipcache list | grep 10.244.3.110 $ cilium-dbg bpf ipcache delete 10.244.3.110/32 Deleted entry 10.244.3.110/320 $ cilium-dbg bpf ipcache get 10.244.3.110 10.244.3.110 does not map to any identityupdate 和 delete 走同一套键构造逻辑。所以删除时前缀和 clusterid 必须与写入时完全一致。进阶场景跨集群条目与 IPv6 前缀ClusterMesh 下删非 0 clusterid 的条目远端集群的条目同步到本地时带非 0 的 clusterid。删除时也要带上同样的值$ cilium-dbg bpf ipcache delete 10.244.3.110/32 --clusterid 1 Deleted entry 10.244.3.110/321clusterid 是 uint16取值范围 0-65535。传错值不会在参数校验阶段报错只会得到一个 ENOENT见下节。删除 IPv6 前缀地址族由键构造时自动识别并写入 Family 字段不需要额外参数$ cilium-dbg bpf ipcache delete fd00::a0/128 --clusterid 0 Deleted entry fd00::a0/1280注意IPv4 和 IPv6 属于不同地址族。10.244.3.110/32永远删不到fd00::a0/128前缀位数也不同它们就是两个完全不同的键。报错速查删除失败先对照这张表报错信息可能原因处理办法Error deleting entry ...: no such file or directoryENOENT前缀拼错、clusterid 与写入时不一致、条目本就不存在先list看真实键再对齐前缀与 clusteridInvalid prefix address.参数不是合法 CIDR比如漏了/32位置参数必须带前缀长度No prefix provided.没传位置参数补上前缀参数权限不足提示非 root 执行用sudo或切到 rootNo entries found.来自 list/get/matchmap 为空确认 Agent 已正常加载数据路径风险边界这条命令直接改数据路径⚠️ 删除一条 IPCache 条目后该前缀立刻失去 identity 和隧道端点。后果是策略判定拿不到身份相关流量按未知身份处理可能被拦截跨节点封装决策失去隧道端点转发行为随之改变。所以只把 delete 用于排障、测试或纠正异常条目。正常情况下 IPCache 由 Agent 根据集群资源自动维护你手动删掉的条目通常很快会被重新同步回来。要长期修正一条映射应该改上游配置而不是手动操作 map。结语cilium-dbg bpf ipcache delete把 BPF IPCache 的删除操作收敛到一条命令键由前缀加 clusterid 决定删除只作用于精确键。排障时先 list 后删、clusterid 对齐它就是一把安全可靠的钥匙。【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
