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

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

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

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

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

四，总结：

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