巧解路由烦恼

路由是指路由器从一个接口上收到数据包，根据数据路由包的目的地址进行定向，并转发到另一个接口的过程。路由器在查看路由表时会遵循最长匹配的原则,即掩码最长的那条路由。笔者单位的某专线业务出现故障，具体的故障现象是终端采集器IP地址可以Ping通，但是数据采集不上来，经过对网路拓扑结构的分析，使用ping、tracert、show等命令将故障定位在了路由的匹配上。经过对静态路由子网掩码的修改，完成了对故障的排除。

图1 电力远程抄表的组网拓扑

故障现象

近日，有同事反映国家电网的电力抄表业务出现大面积故障，得知这一信息后。我们立即着手开始排查。

故障分析

首先通过监控大屏，对电力抄表的网管模块进行查看，并没有发现异常。该专线网络拓扑结构如图1所示。

从图1可以看到，位于末端的信息采集器设备，通过我们的EPON网络将数据传输至电业局核心交换机，在电业局和我方基站机房之间部署了互联路由器，该路由器主要用于路由的转发，并在网络中起到一定的安全防范作用。

上面我们讲到在监控大屏上对电力抄表的整个网络进行了梳理并没有发现异常，根据图1并结合监控的体系，只监测到基站机房三层交换机至信息采集器这一环节。接下来开始排查核心路由器之上的部分。

为了防止设备宕机以及来自外界的入侵，我们对该专线网络中的核心设备进行了配置存档。在对互联路由器以及电业局核心交换机配置检查核对无误后，在主控服务器上对任一采集器IP地址10.218.7.2进行Ping测试，可以Ping通的，但是信息采集器的数据就是传输不上来。在10.218.7.2采集器上Ping网关（互联路由器）没有问题。

故障分析到这里，再一次梳理思路，采集器可以Ping通网关，说明从采集器至互联路由器的链路没有问题。主控服务器可以Ping通信息采集器，说明从主控服务器至信息采集器也没有问题，那问题究竟出在什么地方呢？会不会是路径出现了问题？这里指的路径是指主控服务器至信息采集器的路径。

索性在主控服务器上对信息采集服务器进行trace测试，具体的路由跟踪如下所示：

C:Useradministrator racert 10.218.7.2

通过最多30个跃点跟踪到10.218.7.2的路由：

1 ＜1 毫秒 ＜1 毫秒＜1 毫秒 200.200.200.66

2 3ms 4ms 4ms 10.141.194.1 4

3 5ms 4ms 4ms 10.253.141.34

4 10ms 10ms 10ms 192.168.96.1

5 * * * 请求超时。

6 * * * 请求超时。

7 * * * 请求超时。

8 16ms 14ms 19ms 172.16.1.2

9 11ms 11ms 11ms 10.218.7.2

根据上面的路由跟踪信息，我们找到了故障的原因，具体原因是路由出现了问题。正常的路由应该是第一跳到达电业局核心交换机，即10.158.223.13，第二调是互联路由器10.253.223.16，第三条是我方的三层交换机，第四条就是采集器的IP，那么接下来要解决的是查找trace的第一跳IP地址200.200.200.66究竟是什么？

登录到电业局核心三层交换机上，查看到该地址是和端口5/1互联地址即：

interface GigabitEthernet5/1

no switchport

ip address 200.200.200.84 255.255.255.192

从上面的配置文件可以看到，trace结果的第一跳IP地址200.200.200.66和接口5/1接口地址200.200.200.84在同一个网段，并得知该地址是连接省电业局网络的，而不是连接到图1中的互联路由器。使用命令show ip route |include 10.218.7.0查看路由学习情况，即：

O E1 10.218.7.0/26[110/3] via 200.200.200.66, 00:01:35,GigabitEthernet5/1

S 10.218.7.0/24[1/0] via 10.158.223.16

通过对路由学习情况的查看，显而易见地 得 知10.218.7.2这一IP地址匹配上了10.218.7.0/26 [110/3] via 200.200.200.66这条路由，这是基于路由的最长匹配原则来计算的，并且该路由是OSPF的路由条目。而正常的静态路由10.218.7.0/24[1/0] via 10.158.223.16由于子网掩码较短于10.218.7.0/26，出现了文章开头的路由匹配错误。

故障解决

经过和专线单位沟通联系，其网络工程师也不知情。当时正值节假日，在搞清楚10.218.7.0/26网段只是集采器使用的情况下，为了尽快恢复电力抄表的数据畅通，有两个办法可以解决。第一，在电业局核心交换机的5/1端口上应用路由策略，限制交换机学习到来至省电业局的非法路由。第二个办法就是将电业局核心交换机指向互联路由器的10.218.7.0/24网段进行小段划分，保证该网段的子网掩码长于10.218.7.0/26。

经过对两个方案的对比，方案一需要在上联省电业局的端口应用策略，风险极大，一旦操作不慎会影响所有业务。方案二比较中庸，能够快速解决故障，还不会影响其他业务的正常使用。选择方案二进行实施后，接下来需要配置电业局的核心交换机，具体的配置命令即：

no ip route 10.218.7.0 255.255.255.0

删除原有指向互联路由器的静态路由

//重新添加指向互联路由器的静态路由

完成路由的重新设置后，再一次使用命令show ip route | include 10.218.7.0查看路由的学习情况：

可以看到，路由学习恢复正常。通过对网络进行验证，采集器的数据恢复正常，故障排除。

故障总结

上面我们从得知故障现象着手，首先按照网络层次进行排查，利用ping、tracert和show命令将故障准确定位到了交换机路由学习上，为了尽快恢复故障，通过延长子网掩码长度的办法，优先解决了网络故障。后期经过电业局的排查，找到了真正的故障根源，从而达到了故障解决的目的。