记一次典型的故障排错

    前两天处理了一个网络故障,整个过程虽然只有10分钟,但是我觉得很考验排错的思路,这里写出来分享一下。

    现场的拓扑结构十分简单,一台堡垒机,一台网闸,都直接接在核心上,IP地址是两个网段,网关也都在核心上,相互PING不通。

      问题就这么简单,我的排错思路如下:

      1.在核心分别PING两台设备,测试线路及IP,结果:正常

      2.由于两台设备不是我负责的,无法直接登录检查网关配置是否正确,这里找了一台其他网段的电脑分别PING这两台设备,结果:正常

      3.虽然核心上我是没有配置过任何ACL来进行限制,我还是又检查了一次,确认没有任何过滤限制

      4.到了这一步,就必须要登到设备上看一下了,这里要到了网闸的信息登录进去,检查了网络配置,都正确

      5.网闸是网页操作,找到测试的页面,ping堡垒机,不通;ping堡垒机的网关,不通;ping自己的网关,通。//到了这一步,大家如何进行下一步,可以先不看下面的过程,自己思考一下。

      6.两种可能性,第一,ping包就没从设备发出来;第二,ping包发出来了,核心丢掉了。

      7.开启了核心的DEBUG抓包,然后再从网闸上ping,发现没有提示,核心就没收到包。包去哪了。

      8.再检查网闸的配置,看看是否有限制,过滤一类的配置。看到了管理口配置,地址和堡垒机是一个段,询问了一下,这个接口没接线。按正常来说,接口没接线,地址应该也就不生效,但是为了排除一切可能性,还是把这个地址改掉了。然后就通了,说明就是这个没启用的接口地址影响了。属于产品自身的设计问题。

      上面这步大家是不是觉得很运气,正好就看到了,然后也不确定就删了测一下,就测通了。从结果倒推出原因。那么如果没看到,下一步应该怎么做。

      9.把笔记本接到核心上,地址先配成网闸一个段的,测一下到堡垒机通不通,还不放心可以把物理接口对调,最后还可以把网闸先断一下,把地址给笔记本再测试,这样就可以判断出问题是在网闸这个设备上。

      最后总结,这个问题的处理由于组网确实太简单,又是产品本身原因导致,思路如果不清晰,就会出现无从下手的情况。理清楚思路,是处理故障的首要。形成自己的方法论,解决问题才能事半功倍。

猜你喜欢

转载自blog.51cto.com/648909/2585479