配置完路由别急着收工，先验证一遍
在公司新上了一套业务系统，网络部署完成后，最怕的就是“看似通了，其实藏着坑”。尤其是路由配置，哪怕一个掩码写错，或者下一跳地址填错了，都会导致部分节点访问异常。这时候，光看设备状态是UP的没用，得动手验证。
用ping和traceroute快速定位问题
最基础也最实用的方法，就是从终端发起ping测试。比如财务部无法访问服务器，直接从财务电脑ping服务器IP。不通？那就从接入层开始一步步查。
接着用traceroute（Windows下是tracert），能看出数据包走到哪一跳卡住了。如果第三跳是核心交换机，第四跳是出口路由器，结果第三跳能通，第四跳超时，那问题大概率出在核心到出口这段的路由或ACL策略上。
查看路由表确认路径是否正确
登录到关键节点的路由器或三层交换机，执行查看路由表命令。比如在华为设备上：
display ip routing-table 192.168.10.0在思科设备上则是：
show ip route 192.168.10.0重点看目标网段有没有被正确学习到，下一跳是不是预期的设备。有时候OSPF邻居建起来了，但因为区域配置不对，路由没传过来，表面上协议正常，实际转发失败。
模拟流量路径：使用ping指定源地址
多宿主环境下，一个设备有多个接口，ping默认可能走错源地址。这时候要指定源来模拟真实流量路径。例如，想测试从VLAN 20去往外网的路由是否正常：
ping -a 192.168.20.1 -c 5 8.8.8.8这里的 -a 参数指定源IP为192.168.20.1，确保测试的是VLAN 20的出口路由，而不是其他接口的路径。
利用ACL日志辅助判断
有些时候路由表看着没问题，但数据就是过不去。可能是中间设备的ACL拦截了。可以在关键路由器的接口入方向加一条带日志的ACL规则：
rule 100 permit ip source 192.168.10.10 0 destination 10.0.0.50 0 log然后抓日志看这条流是否被匹配。如果没记录，说明流量根本没到这台设备；如果有记录但还是不通，就得查后续节点。
动态路由协议状态不能忽略
跑OSPF或BGP的环境，除了看路由表，还得确认邻居状态。比如OSPF邻居卡在INIT状态，说明双向通信有问题；BGP的Established状态没起来，再配静态路由也没用。
查OSPF邻居：
display ospf peer查BGP会话：
display bgp ipv4 peer状态正常不代表路由同步成功，还要结合路由表一起看。
实际案例：分公司连不上总部
之前遇到一次故障，分公司通过MPLS专线连总部，部署完静态路由后测试，个别子网通，个别不通。排查发现，总部那边漏配了一条回程路由，导致响应包没法原路返回。用ping测试时显示时通时断，其实是负载分担把部分流量引到了错误路径。
解决办法很简单：在总部路由器补上缺失的静态路由，再从分公司traceroute验证路径一致性，问题立刻消失。
自动化脚本提升验证效率
对于频繁变更的网络，手动验证太耗时间。可以写个简单脚本，定时从多个关键点发起ping和traceroute，并记录结果。比如用Python调用paramiko登录设备执行命令，或者用PingCastle这类工具做外部探测。
哪怕只是每天早上自动跑一遍核心链路检测，也能提前发现不少潜在问题。