linux路由表本身不占大量内存，但路由条目膨胀、策略路由混乱或内核缓存失衡会推高slab内存消耗（如fib6_node、ip_fib_alias、arp_cache），导致查找变慢、gc频繁、响应迟滞。
Linux中路由表本身不直接“占用大量内存”，但当路由条目异常膨胀、策略路由混乱或内核缓存机制失衡时，会间接推高内核内存消耗（尤其是 slab 中的 fib6_node、ip_fib_alias、arp_cache 等对象），甚至引发路由查找变慢、GC 频繁、系统响应迟滞等问题。排查重点不是“路由表占了多少 MB”，而是识别哪些路由相关行为正在持续消耗不可回收内核内存。
查看当前路由规模与分布
先量化路由数量和来源，避免凭感觉判断：
-
ip route show | wc -l—— 查总条目数（注意：含 local、broadcast、unreachable 等隐式条目） -
ip route show table local | wc -l和ip route show table main | wc -l—— 分表统计，容器/虚拟化环境常在 local 表堆叠大量 host 路由 -
ip route show proto kernel | wc -l—— 内核自动生成的路由（如子网直连、loopback），过多可能说明接口配置冗余 -
ip route show proto static | wc -l—— 手动添加的静态路由，检查是否遗漏清理
示例：若
table local条目超 5000 条，而物理主机仅几十个容器，大概率存在 CNI 插件未清理或重复添加问题。
检查内核 slab 中路由相关缓存
路由条目主要驻留在内核 slab 分配器中，用以下命令定位热点：
-
slabtop -o | grep -E "(fib6|FIB|ip_fib|arp)"—— 实时排序查看路由/ARP 相关 slab 占用 -
cat /proc/slabinfo | awk '$1 ~ /^(fib6_node|ip_fib_alias|arp_cache|neigh_table)$/ {print $1, $3, $4}'—— 输出对象名、活跃对象数、总对象数 - 若
fib6_node或ip_fib_alias的active数持续增长且不回落，说明 IPv4/IPv6 FIB 节点未被及时回收，常与net.ipv4.fib*_gc_thresh*设置过低有关
关联分析 ARP 与 unreachable 路由
大量 unreachable、blackhole 或 prohibit 路由，往往不是手动配置的，而是内核对 ARP 失败的“抑制响应”：
-
ip route show | grep unreachable | head -10—— 看是否集中于某网段（如10.244.0.0/16） -
ip neigh show nud failed | wc -l—— 统计失败 ARP 条目数；若远高于正常值（>100），说明网络连通性差或网关异常 - 检查
net.ipv4.conf.all.arp_ignore和arp_announce：设为1或2可减少错误 ARP 请求，从而抑制衍生路由
核查策略路由规则与多表滥用
ip rule 创建的策略路由若无精确匹配范围，会导致每次查路由都遍历多个表，加重内核负担并隐式维持更多缓存：
-
ip rule show—— 查看所有规则，重点关注from all、to all、lookup *类宽泛规则 -
ip route show table 100（假设 table 100 是某自定义表）—— 确认该表是否真有有效路由，还是空表或仅含默认路由 - 删除无用规则：
ip rule del from all to all lookup 100（示例）
不复杂但容易忽略
