为什么路由验证不能跳过
公司刚搬了新办公室，网络工程师小李忙着部署新的路由器和交换机。设备一通电，网线一插，电脑马上能上网，看起来一切正常。可第二天财务部发现无法连接总部的财务系统，销售部发不出邮件。问题出在哪？其实就在路由配置没做验证。
很多网络部署中，只要设备亮灯、终端能上外网，就认为“通了”。但真正的“通”不是看网页能不能打开，而是看每一条数据包是否走对了路径。路由验证就是确认这些路径正确无误的关键步骤。
常用路由验证方法
最基础也最常用的工具是 ping 和 traceroute（Windows 下叫 tracert）。它们就像网络的听诊器，能帮你判断通路是否通畅。
比如，你配置了一条静态路由指向分公司网段 192.168.10.0/24，下一跳是 10.0.0.2。先用 ping 测试连通性：
ping 192.168.10.1如果超时，说明可能路由未生效或中间节点阻断。接着用 traceroute 查看路径：
traceroute 192.168.10.1输出会显示每一跳的IP，你可以看到数据包是否经过了你设定的下一跳 10.0.0.2。如果不是，就得回头检查路由表。
查看路由表确认配置
在 Linux 或网络设备上，使用 ip route show 或 route -n 查看当前路由表：
ip route show输出类似：
default via 192.168.1.1 dev eth0
192.168.10.0/24 via 10.0.0.2 dev eth1确认目标网段和下一跳是否正确出现在表中。有时候配置命令敲错了，比如把 10.0.0.2 写成 10.0.0.20，这种低级错误靠肉眼很难发现，必须通过命令验证。
策略路由与多出口场景
有些企业有两条宽带，一条走办公流量，一条专供视频会议。这时候要用策略路由，按源地址或端口分流。验证就不能只靠 ping 了，得模拟不同类型的流量。
比如从财务部电脑（IP 192.168.1.100）发起请求，看它是否走指定线路。可以用 tcpdump 抓包，确认数据从哪个接口发出：
tcpdump -i eth1 host 192.168.1.100如果 eth1 是办公线路接口，却没抓到包，反而在 eth2 上出现了，那说明策略路由没生效。
动态路由协议的验证要点
如果用了 OSPF 或 BGP 这类动态路由，光看本地配置不够，还得确认邻居关系是否建立、路由是否被正确学习。
在路由器上执行：
show ip ospf neighbor看状态是不是 Full。如果是 Init 或 Down，说明邻居没通。再查路由表里有没有学到的 OSPF 路由：
show ip route ospf没有条目？可能是区域配置不一致，或者网络类型不匹配。
自动化脚本提升效率
大型网络每次变更都手动验证太费劲。可以写个简单脚本，自动执行 ping、traceroute 并记录结果。
比如一个 Bash 脚本：
#!/bin/bash
for ip in 192.168.10.1 192.168.20.1 10.1.1.1; do
echo "Testing $ip"
ping -c 3 $ip >/dev/null
if [ $? -eq 0 ]; then
echo "$ip OK"
else
echo "$ip FAILED"
fi
done部署后运行一遍，快速判断关键节点连通性。
别让“看起来通”掩盖真实问题
网络部署完成后，别急着打卡下班。花十分钟做一次完整路由验证，可能避免第二天全公司断网的尴尬。尤其是跨网段访问、多线路备份、策略路由等复杂场景，手动验证一步都不能省。工具就在手边，关键是养成习惯。