解析双向路由怪象 换思路巧妙解决路由故障

　　一，双向路由信息的意义：

　　数据包的通讯是需要有两个方向的，在发送数据的同时也承担着接收数据的任务。因此当A计算机与B计算机进行正常网络通讯时，网络中一定拥有相关路由实现从A指向B的条目，同时也一定拥有相关路由实现B指向A的条目。一旦缺少其中一个方向的条目，那么两台计算机是无法通讯的，即使是最普通的PING命令检测也是超时time out的结果。

　　正因为这种数据通讯的双向性使得很多网络管理员在配置网络路由交换设备时频繁出现问题，忘记双向路由条目设置原则而造成网络故障。所以在解决网络故障时核对路由表以及双向性方面的设置准确与否是非常重要的手段。

　　二，亲身经历网络路由故障：

　　近日笔者在对旗下一个分公司的网络进行维护时发现该下连网络的WWW服务无法顺利访问，在IE浏览器里通过https加密协议通讯显示“该页无法打开”。(如图1)

　　该子公司的网络结构是这样的内网计算机的IP地址范围是XX.XX.91.1-XX.XX.91.126，其中XX.XX.91.126是出口路由器连接内网的LAN0接口IP地址，XX.XX.91.120是子公司的WWW服务器，对外提供WWW服务。(如图2)

　　接下来按照传统的办法ping XX.XX.91.120该地址发现提示超时，但是登录到子公司的出口路由器上PING该内网计算机却没有任何问题，PING完全是通的。(如图3)

　　使用tracert命令跟踪数据路由转发情况后发现数据包到达第18跳后就出现了request timed out的错误提示，看来问题出在这个环节。(如图4)

　　然而笔者PING该子公司出口路由器内网接口XX.XX.91.126时却没有任何问题，PING是正常的，而且速度和稳定性都很好。(如图5)

　　三，步步为营解决路由故障：

　　为什么内网接口能够PING通但是内网主机却无法PING通呢?开始笔者也曾经怀疑是路由表条目的设置问题，但是经过判断从外网是可以PING通XX.XX.91.126这个地址的，这说明网络中存在着到达XX.XX.91.126所在网段的路由，路由信息应该是全的。

　　接下来就要从其他方面考虑了，笔者准备在子公司路由器上做设置，通过NAT实现数据转发，同时将XX.XX.91.120这个地址以NAT SERVER的方式对外宣告出去，这样理论上讲数据包就能够顺利到达XX.XX.91.120了，毕竟经过宣告只要数据可以到达路由器外网接口就能够顺利转发到内网相关NAT SERVER中。笔者使用nat server global XX.XX.91.120 any inside XX.XX.91.120 any ip命令完成宣告服务的任务。(如图6)

　　同时利用nat outbound 2001 interface命令在外网接口上开启NAT服务，保证nat server的顺利宣告。(如图7)

　　然而通过宣告NAT SERVER后问题依旧，至此笔者就再也不怀疑路由器相关路由表问题了。接下来冷静分析发现只要在外网PING XX.XX.91.120都是不通的，而在内网或出口路由器上PING XX.XX.91.120却没有任何问题。笔者继续尝试其他主机的连通性，发现除了XX.XX.91.120有这个问题外，其他IP地址都不存在无法PING通的问题。看来故障的根源再于这台主机。经过排查发现这台安装了PANABIT流量管控程序的freebsd系统自身网络设置存在问题，没有设置网关地址为XX.XX.91.126，使用ifconfig命令添加完毕后故障解决。

　　四，总结：

　　实际上在本次路由故障解决的全过程中笔者走了一些弯路，首先由于我是上级网络管理者，所以无法对该子公司内网计算机的设置状况有一个清晰的了解，在出现PING不通无法访问的问题时也没有及时的通过PING其他主机是否畅通来判断是网络问题还是主机问题，因为我自己无法判断到底该子公司哪台机器处于开机状态可以PING通;另外笔者在进行tracert XX.XX.91.120时在第18跳时发现了request timed out的错误提示，这点迷惑了我，认为是网络问题，路由问题。而后来的结果证实了这个推断的错误性，看来以后在进行网络维护时Tracert的结果并不能太过分相信，本例中应该再执行tracert XX.XX.91.120后再执行tracert XX.XX.91.126来判断他们在tracert路径上是否存在差异来快速定位故障。