路由表项达上限时表现为新增失败、网络不通或内核日志提示，排查需分四步：确认现象（查条目数及错误信息）、定位瓶颈（区分业务与冗余路由）、分析诱因（BGP未过滤、容器残留、ICMP重定向）、优化防控（调GC阈值、禁转发、ARP调优）。
路由表项达到上限时，系统通常不会直接报错，而是表现为新增路由失败、部分网络不通、或内核日志中出现隐晦提示。排查需从确认现象、定位瓶颈、分析诱因到调整优化四步展开，重点不在“加条目”，而在“控来源”和“清无效”。
确认是否真达上限而非配置错误
先排除误判：运行 ip route show | wc -l 查看当前主表（main）条目数；再检查策略路由表（如 local、default、自定义表），用 ip route show table all | grep -v "empty" | wc -l 统计全表总量。若接近 10 万以上，需警惕；但更关键的是观察行为异常——比如执行 ip route add 返回 “No buffer space available” 或静默失败，或 dmesg 中出现 “fib6_gc_thresh3 reached” 类提示。
查清哪些路由在撑满表项
区分真实业务路由与冗余/自动生成项：
- 对比
ip route show table main和ip route show table local：容器平台（如 Docker、CNI）常在 local 表大量添加local xxx.xxx.xxx.xxx dev eth0 proto kernel scope host，这类条目多为每个 Pod 分配一个，极易堆积 - 搜索 unreachable / blackhole 路由：
ip route show | grep -E "unreachable|blackhole"，这类多由 ARP 失败后内核自动注入，非手动添加，但占位不释放 - 检查策略路由规则是否泛化：
ip rule show中若存在无to/from限定的 rule（如仅lookup 200），会导致每次查路由都遍历额外表，间接加剧压力
识别动态膨胀源头
多数“满表”不是手工加出来的，而是以下三类自动行为失控所致：
- BGP/OSPF 等协议未做前缀过滤：接收全网 IPv4 路由（约 90 万+）或 IPv6（超 10 万），远超单机处理能力。应检查 FRR、BIRD 或 Quagga 配置中的 import policy，限制接收前缀长度（如只收 /24 及更粗）和总数（如 max-prefix 5000）
-
容器网络反复重建未清理：Kubernetes Node 重启或 CNI 插件异常时，旧 Pod 的 local 路由残留。可用
ip route flush table local清理（注意不影响 active 接口） -
ICMP 重定向被接受：若
net.ipv4.conf.all.accept_redirects = 1，恶意或错误重定向可能注入伪造路由。生产环境必须设为 0
参数调优与长期防控
临时缓解可调回收阈值，但治本要控源头：
- IPv6 路由缓存 GC 阈值偏低是常见瓶颈，修改
/etc/sysctl.conf：
net.ipv4.fib6_gc_thresh1 = 1024
net.ipv4.fib6_gc_thresh2 = 4096
net.ipv4.fib6_gc_thresh3 = 8192
然后执行sysctl -p - 禁用无用转发功能：
net.ipv4.conf.all.forwarding = 0（非路由器场景），减少内核维护的转发相关状态 - ARP 行为调优防抑制路由生成：
net.ipv4.conf.all.arp_ignore = 1和net.ipv4.conf.all.arp_announce = 2，避免因 ARP 失败触发批量 unreachable 条目 - 定期巡检脚本示例：
#!/bin/bash<br>echo "Main table: $(ip route show table main | wc -l)"<br>echo "Local table: $(ip route show table local | wc -l)"<br>echo "Unreachables: $(ip route show | grep unreachable | wc -l)"
