上周帮朋友公司查网络延迟，发现核心交换机 CPU 长期飙到 85%。一翻路由表，吓一跳：光是 10.200.0.0/16 下面就塞了 327 条 /32 主机路由，全是手动配的 VIP 和容器 IP。这不是在跑网络，是在跑 Excel 表格。
路由表不是记事本，撑不住“想到就加”
很多运维习惯把路由当备忘录用：新上一台数据库，加一条；测试环境扩两台 Pod，再加两条；临时调试开个隧道，又加一条……没过三个月，路由表里全是孤零零的 /32 和 /30，互相重叠、优先级打架，连 traceroute 都绕晕。
先画图，再动配置
动手前花 15 分钟做三件事：
- 列出所有业务网段（比如：
10.10.1.0/24是订单服务，10.10.2.0/24是用户中心） - 标出东西向流量路径（微服务间调用走哪台 ToR？是否绕行 Spine？）
- 圈出必须精确控制的出口（比如：支付流量强制走 BGP 线路，日志上传走单独 VRF）
这时候你会发现，90% 的“单点路由”其实可以归并——10.10.1.10/32、10.10.1.11/32、10.10.1.12/32，不如直接写成 10.10.1.8/29。
实战技巧：少写路由，多靠协议
能用动态协议搞定的，别手写静态路由。例如：
容器平台用 Calico 或 Cilium，默认通过 BGP 把 Node 路由自动宣告到 ToR；你只要在 Spine 上配好对等体，整个机房的 Pod 网段就自动可达，不用每加一个 Deployment 就 SSH 登一次交换机。
真要写静态路由时，记住两个铁律：
- 聚合优先：
ip route 10.100.0.0 255.255.0.0 192.168.1.1比 256 条 /24 更轻量 - 带描述不带注释：部分设备支持
description order-db-migration，比藏在配置文件里的 # 注释靠谱得多
检查清单（每次变更后必跑）
登录核心设备，顺手敲几条命令：
show ip route summary # 看总条数有没有突增
show ip route 10.10.1.0 255.255.255.0 # 查这个网段是不是只有一条最优路径
show ip route | inc \*\> # 找出被标记为“最佳但不可达”的黑洞路由某次上线后发现 10.20.30.0/24 在 ToR 上有两条等价路由，一条指向已下线的老服务器，一条指向新集群——因为老路由没删干净，新流量一半进黑洞。这种问题，show ip route summary 一眼就能揪出来。
路由表不是越大越牛，而是越干净越稳。省下的每一条冗余路由，都是未来半夜不用爬起来 reload 配置的理由。