Cilium 里为什么删不掉这条记录cilium-dbg bpf ipcache delete 三步安全清理指南【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium上周值班遇到一个怪现象某节点上的 Pod 换了新 IP 后跨集群流量开始莫名丢包。顺着日志查下来问题出在 Cilium 的 BPF IPCache——数据面靠它把每个 IP 解析成安全身份并决定隧道封装而旧 IP 回收后残留的那条映射一直没被清掉新流量的身份判定和封装决策全都跟着跑偏。正常情况下这块缓存由 Agent 自动维护但状态一旦异常就得亲手下场。这篇文章带你用cilium-dbg bpf ipcache delete把 BPF IPCache 条目删干净顺便讲清楚参数怎么配、删之前查什么、删不掉时怎么排障。这条命令到底是干什么的一句话定位它直接从内核里的 BPF map 中删掉一条“IP/CIDR 前缀 → 身份 隧道端点”的记录是清理 IP 身份映射的最低层手段。删掉之后这个前缀在数据面上就查不到身份了策略判定和封装决策会立刻按“未知”处理所以动手前想清楚影响面。最小可用示例就一条命令cilium-dbg bpf ipcache delete 10.244.3.110/32 --clusterid 0执行成功后会看到这样的输出其中0表示条目所属的 clusteridDeleted entry 10.244.3.110/320参数怎么写才对位置参数只有一个要删的前缀。必须是带前缀长度的 CIDR裸 IP 不认。下面这组对照可以贴在工位上合法写法非法写法为什么不行10.244.3.110/3210.244.3.110缺前缀长度报 Invalid prefix addressfd00::a0/12810.244.3.110/33前缀位数越界192.168.0.0/24空参数报 No prefix provided专属选项其实只有两个--clusteriduint16默认 0和-h。--clusterid决定什么时候该传单集群场景缺省即可一旦条目来自 ClusterMesh 远端集群写入时带了非 0 的 clusterid删除时必须原样带上。传错的后果不是“删错了别的”而是构造出来的键和 map 里那条对不上命令报条目不存在ENOENT什么也没删掉。其余像--config、-D/--debug、-H/--host这些全局选项从根命令继承而来标准安装下用不到知道即可。删除前必做的三步检查⚠️ 先把安全原则放前面先查后删一次只碰一条。ipcache 命令族里三个只读兄弟命令各回答一个问题list别名lsmap 里总共有哪些条目——用来确认真实键的格式和 clusterid 后缀长什么样match PREFIX这个前缀精确存在吗——按键做精确匹配删之前先跑它能直接排除“键没写对”的嫌疑get IP这个 IP 实际会命中哪个身份——按最长前缀匹配LPM按前缀长度做最长匹配的一种查找回答的是数据面真实的行为。“查→删→验”的完整序列长这样# 1) 确认目标键真实存在注意看输出里的 clusterid cilium-dbg bpf ipcache match 10.244.3.110/32 # 2) 顺带确认该 IP 当前解析到的身份 cilium-dbg bpf ipcache get 10.244.3.110 # 3) 执行删除 cilium-dbg bpf ipcache delete 10.244.3.110/32 # 4) 验证此时应提示 no match / does not match cilium-dbg bpf ipcache match 10.244.3.110/32组合演练update 写入 → 删除的四步法排障时最常见的场景是和update搭配临时纠正或重建一条映射。update支持--tunnelendpoint、--identity、--encryptkey、--skiptunnel、--clusterid五个参数。完整走一遍# 1) 写入10.244.3.110/32 归属 identity 6隧道端点 172.21.0.2 cilium-dbg bpf ipcache update 10.244.3.110/32 \ --tunnelendpoint 172.21.0.2 --identity 6 --encryptkey 255 --clusterid 0 # 2) 确认写入 cilium-dbg bpf ipcache list | grep 10.244.3.110 # 3) 删除 cilium-dbg bpf ipcache delete 10.244.3.110/32 --clusterid 0 # 4) 验证删除 cilium-dbg bpf ipcache match 10.244.3.110/32两个写法差异顺手记一下多集群ClusterMesh场景下写入和删除必须用同一个 clusterid上面第 1 步和第 3 步的--clusterid要一致IPv6 前缀则不需要任何额外参数地址族由键自动识别直接delete fd00::a0/128即可。底层机制速览为什么删除参数必须和写入时一致先解释两个名词LPM Trie 是按前缀长度做最长匹配的一种内核查找结构Cilium 的 IPCache map常量名cilium_ipcache_v2容量上限 512000 条正是这种类型。map 的键由“前缀 clusterid”共同编码地址族IPv4/IPv6由前缀自动识别后写入键中值侧则装着身份号、隧道端点、IPsec 密钥编号和若干标志位如 skiptunnel、remotecluster。delete 的执行流程其实很短校验 root 权限解析前缀用NewKey(prefix, clusterID)组装键再对这个 map 单例执行Delete成功打印Deleted entry ...失败报错并以退出码 1 结束。所以“参数必须与写入一致”的原因就一句话键是确定性编码的前缀或 clusterid 任何一位不同你拿到的就是一把指向空槽位的钥匙——LPM Trie 的删除是精确删键不会级联影响更宽或更窄的前缀删 /32 不会动 /24 的条目。避坑清单你可能会遇到下面这四种情况对号入座现象/报错原因处理Error deleting entry ...: no such file or directoryENOENT键没命中前缀拼错、clusterid 与写入时不一致先list看真实键格式注意clusterid后缀再照抄重删Invalid prefix address.参数不是合法 CIDR裸 IP 或前缀位数越界补上/32、/128等前缀长度No prefix provided.没传位置参数把前缀作为第一个参数权限不足、命令直接拒绝未以 root 在 Agent 节点执行源码里有强制校验用sudo或切 root 重试收尾排障检查清单✅ 下次再遇到 IPCache 状态异常按这张清单过一遍就能收工已在 Agent 节点以 root 身份执行命令用list/match确认了条目的存在、格式与clusterid后缀删除参数前缀、clusterid与写入时完全一致删除后已用match/get复核并观察了数据面转发是否恢复明确告知团队手动改动只是止血根因要回到 Agent 的自动维护链路去查源码入口就两处想深挖时直接看命令实现在 cilium-dbg/cmd/bpf_ipcache_delete.go键/值结构与 map 定义在 pkg/maps/ipcache/ipcache.go。【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Cilium 里为什么删不掉这条记录？cilium-dbg bpf ipcache delete 三步安全清理指南
Cilium 里为什么删不掉这条记录cilium-dbg bpf ipcache delete 三步安全清理指南【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium上周值班遇到一个怪现象某节点上的 Pod 换了新 IP 后跨集群流量开始莫名丢包。顺着日志查下来问题出在 Cilium 的 BPF IPCache——数据面靠它把每个 IP 解析成安全身份并决定隧道封装而旧 IP 回收后残留的那条映射一直没被清掉新流量的身份判定和封装决策全都跟着跑偏。正常情况下这块缓存由 Agent 自动维护但状态一旦异常就得亲手下场。这篇文章带你用cilium-dbg bpf ipcache delete把 BPF IPCache 条目删干净顺便讲清楚参数怎么配、删之前查什么、删不掉时怎么排障。这条命令到底是干什么的一句话定位它直接从内核里的 BPF map 中删掉一条“IP/CIDR 前缀 → 身份 隧道端点”的记录是清理 IP 身份映射的最低层手段。删掉之后这个前缀在数据面上就查不到身份了策略判定和封装决策会立刻按“未知”处理所以动手前想清楚影响面。最小可用示例就一条命令cilium-dbg bpf ipcache delete 10.244.3.110/32 --clusterid 0执行成功后会看到这样的输出其中0表示条目所属的 clusteridDeleted entry 10.244.3.110/320参数怎么写才对位置参数只有一个要删的前缀。必须是带前缀长度的 CIDR裸 IP 不认。下面这组对照可以贴在工位上合法写法非法写法为什么不行10.244.3.110/3210.244.3.110缺前缀长度报 Invalid prefix addressfd00::a0/12810.244.3.110/33前缀位数越界192.168.0.0/24空参数报 No prefix provided专属选项其实只有两个--clusteriduint16默认 0和-h。--clusterid决定什么时候该传单集群场景缺省即可一旦条目来自 ClusterMesh 远端集群写入时带了非 0 的 clusterid删除时必须原样带上。传错的后果不是“删错了别的”而是构造出来的键和 map 里那条对不上命令报条目不存在ENOENT什么也没删掉。其余像--config、-D/--debug、-H/--host这些全局选项从根命令继承而来标准安装下用不到知道即可。删除前必做的三步检查⚠️ 先把安全原则放前面先查后删一次只碰一条。ipcache 命令族里三个只读兄弟命令各回答一个问题list别名lsmap 里总共有哪些条目——用来确认真实键的格式和 clusterid 后缀长什么样match PREFIX这个前缀精确存在吗——按键做精确匹配删之前先跑它能直接排除“键没写对”的嫌疑get IP这个 IP 实际会命中哪个身份——按最长前缀匹配LPM按前缀长度做最长匹配的一种查找回答的是数据面真实的行为。“查→删→验”的完整序列长这样# 1) 确认目标键真实存在注意看输出里的 clusterid cilium-dbg bpf ipcache match 10.244.3.110/32 # 2) 顺带确认该 IP 当前解析到的身份 cilium-dbg bpf ipcache get 10.244.3.110 # 3) 执行删除 cilium-dbg bpf ipcache delete 10.244.3.110/32 # 4) 验证此时应提示 no match / does not match cilium-dbg bpf ipcache match 10.244.3.110/32组合演练update 写入 → 删除的四步法排障时最常见的场景是和update搭配临时纠正或重建一条映射。update支持--tunnelendpoint、--identity、--encryptkey、--skiptunnel、--clusterid五个参数。完整走一遍# 1) 写入10.244.3.110/32 归属 identity 6隧道端点 172.21.0.2 cilium-dbg bpf ipcache update 10.244.3.110/32 \ --tunnelendpoint 172.21.0.2 --identity 6 --encryptkey 255 --clusterid 0 # 2) 确认写入 cilium-dbg bpf ipcache list | grep 10.244.3.110 # 3) 删除 cilium-dbg bpf ipcache delete 10.244.3.110/32 --clusterid 0 # 4) 验证删除 cilium-dbg bpf ipcache match 10.244.3.110/32两个写法差异顺手记一下多集群ClusterMesh场景下写入和删除必须用同一个 clusterid上面第 1 步和第 3 步的--clusterid要一致IPv6 前缀则不需要任何额外参数地址族由键自动识别直接delete fd00::a0/128即可。底层机制速览为什么删除参数必须和写入时一致先解释两个名词LPM Trie 是按前缀长度做最长匹配的一种内核查找结构Cilium 的 IPCache map常量名cilium_ipcache_v2容量上限 512000 条正是这种类型。map 的键由“前缀 clusterid”共同编码地址族IPv4/IPv6由前缀自动识别后写入键中值侧则装着身份号、隧道端点、IPsec 密钥编号和若干标志位如 skiptunnel、remotecluster。delete 的执行流程其实很短校验 root 权限解析前缀用NewKey(prefix, clusterID)组装键再对这个 map 单例执行Delete成功打印Deleted entry ...失败报错并以退出码 1 结束。所以“参数必须与写入一致”的原因就一句话键是确定性编码的前缀或 clusterid 任何一位不同你拿到的就是一把指向空槽位的钥匙——LPM Trie 的删除是精确删键不会级联影响更宽或更窄的前缀删 /32 不会动 /24 的条目。避坑清单你可能会遇到下面这四种情况对号入座现象/报错原因处理Error deleting entry ...: no such file or directoryENOENT键没命中前缀拼错、clusterid 与写入时不一致先list看真实键格式注意clusterid后缀再照抄重删Invalid prefix address.参数不是合法 CIDR裸 IP 或前缀位数越界补上/32、/128等前缀长度No prefix provided.没传位置参数把前缀作为第一个参数权限不足、命令直接拒绝未以 root 在 Agent 节点执行源码里有强制校验用sudo或切 root 重试收尾排障检查清单✅ 下次再遇到 IPCache 状态异常按这张清单过一遍就能收工已在 Agent 节点以 root 身份执行命令用list/match确认了条目的存在、格式与clusterid后缀删除参数前缀、clusterid与写入时完全一致删除后已用match/get复核并观察了数据面转发是否恢复明确告知团队手动改动只是止血根因要回到 Agent 的自动维护链路去查源码入口就两处想深挖时直接看命令实现在 cilium-dbg/cmd/bpf_ipcache_delete.go键/值结构与 map 定义在 pkg/maps/ipcache/ipcache.go。【免费下载链接】ciliumeBPF-based Networking, Security, and Observability项目地址: https://gitcode.com/GitHub_Trending/ci/cilium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考