/proc/net/rt_cache 已废弃，无法用于评估多专线策略路由分流效率；应改用 ip -s rule/route 计数器、CONNMARK 标记流级观测、eBPF 精准路径追踪三类真实可观测方法。
/proc/net/rt_cache 是 Linux 内核中用于显示路由缓存（已废弃）的接口，在现代内核（2.6.32+ 且特别是 3.6 及以后）中默认禁用、编译时移除或完全淘汰。自 2012 年起，Linux 已全面转向基于 fib_trie 的无缓存、前缀匹配路由查找机制，rt_cache 不再反映真实转发行为，也不参与策略路由（policy routing）决策。
因此，无法通过监控 /proc/net/rt_cache 来评估多物理专线并存场景下的策略路由分流效率——它既不更新、不统计、不区分策略表，也不体现流量实际走向。依赖它会产生严重误判。
下面直接给出在真实企业级多专线网络中可落地、可观测、可量化的评估方法：
策略路由分流效率的真实监控路径
策略路由依赖 ip rule + 多张路由表（如 table 100, table 200），流量按源地址、ToS、fwmark 等条件匹配规则后查对应表。要评估“分流是否均衡、是否按预期走指定专线”，关键不是看缓存，而是看：
- 谁走了哪条路（流粒度溯源）
- 每条路径实际承载多少（带宽/包量/连接数）
- 是否发生意外回切或绕行（路径偏离）
建议组合使用以下三类指标：
-
基于
ip -s rule show和ip -s route show table X的计数器
Skill Weave Chains — 技能链路由引擎下载开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
-
ip -s rule show中每条 rule 后的matches字段：表示该规则被匹配的次数（即触发该策略表的流量数量） -
ip -s route show table 100中每条路由后的uses字段：表示该路由项被实际选中转发的次数（注意：仅对未启用 ECMP 的单路径有效；若启用了nexthop组，则需结合ip nexthop show） - ✅ 实操：定时采集
matches增量，对比各 rule 的相对占比，即可判断策略分流比例是否符合预期（例如from 192.168.10.0/24 lookup telecom应占 60%，实测是否稳定在 58–62%）
-
-
基于
ss -i或nethogs的实时流级出口归属-
ss -i src 192.168.10.100查该主机所有连接的skmem:(r,rb,wt,tm->atm)和cwnd，配合cat /proc/[pid]/net/nf_conntrack或conntrack -L可反查 NAT 后的出接口 - 更直接：用
tc filter+iptables -t mangle -j CONNMARK标记不同策略出口的连接，再用iftop -P或iptraf-ng按 mark 过滤观察实时吞吐 - ✅ 实操：对关键业务 IP 段做标记分流（如
iptables -t mangle -A OUTPUT -s 192.168.20.0/24 -j CONNMARK --save-mark），再用watch -n1 'cat /proc/net/ip_vs_stats | grep -A5 "Conns"（若用 LVS）或ip -s link show eth1对比eth1vseth2的tx bytes增长速率
-
-
基于 eBPF 的精准路径追踪（推荐用于生产环境）
- 使用
bpftool加载轻量级 tracepoint：tracepoint:net:netif_receive_skb→kprobe:ip_route_input_slow→kretprobe:__dev_queue_xmit，提取skb->dev->name和skb->mark - 工具链示例：
bpftrace -e 'tracepoint:net:netif_receive_skb { printf("in:%s mark:%d\n", str(args->name), args->mark); }' - 结合
tc exec bpf pin /sys/fs/bpf/egress_monitor在出方向统计 per-mark 流量字节数，精度达微秒级、零采样丢失 - ✅ 实操：为每条专线绑定唯一 fwmark（如
0x100→ 电信，0x200→ 联通），用 eBPF 直接统计各 mark 在__dev_queue_xmit阶段的实际出口字节数，排除中间设备干扰
- 使用
吞吐拐点识别的关键不是“缓存满没满”，而是“策略瓶颈在哪”
多专线网络中的拐点通常出现在：
- 策略规则链过长导致
ip rule查找延迟上升（>10μs/包） - 某专线出口队列堆积（
tc -s qdisc show dev eth1中backlog> 1000 packets） - conntrack 表耗尽（
nf_conntrack_count接近nf_conntrack_max） -
ip rule的goto跳转引发嵌套查找（应避免超过 3 层）
这些都能通过 /proc/net/nf_conntrack、/sys/class/net/eth*/queues/*/byte_queue_limits、/proc/sys/net/ipv4/route/max_size 等真实接口获取，而非 rt_cache。
不复杂但容易忽略
