厦大学生公寓故障排查

厦大学生公寓故障排查

把主要的排故过程进行概括总结：

     为了确保ME60上没有问题，咱们决定先在美仁宫进行测试，再去厦大排故

·    测试方法：在美仁宫8505下挂一台3505三交换机再接PC进行测试

·    测试结果：正常（打开网页响应快、延迟小）

确保在美仁宫测试没有问题以后，先在赛尔办公室进行测试，看下客户端目前拨号状况。

在客户端测试的状况：

·    拨号前先ping 112.5.66.69(ME60上的地址）延迟1ms正常

·    完成拨号须要时间10s左右，打开网页慢

·    拨号后pingDNS延迟53ms

这个明显有问题，因此为了确保走的路径是正确的，所以进行了tracert LNS地址（112.5.66.66）如图

 

而这个路径明显是有问题的，经过查询便可知道在拨号前到达该地址是走了教育网出去了，这样问题其实就基本解决了。

 

致使这个问题就是校方在思科6509上没有把去往ME60的LNS的静态路由重分发至其内网，致使下面用户没路由但经过教育网也可以到达LNS（从上面Tracert可知），而这样绕一圈确定速度慢不少，从而出现拨号慢、上网慢的问题。

 

 

解决的方法有二个：

·    校方在思科6509上把指向LNS地址的静态路由下发至网部内部

·    把ME60的LNS的地址配置成69（由于校方已经把直连的下发到内部了）

 

为了少麻烦到校方，所以咱们把ME60上的LNS地址改为69，再进行测试拨号正常、打开网页正常！

·    拨号前先ping 112.5.66.69(ME60上的地址）延迟1ms正常

·    完成拨号须要时间5s左右，打开网页正常

·    拨号后pingDNS延迟6ms

 

 到这里其实已经排故成功！

但这让我更莫名其妙的感受，由于我一开始就怀疑绕路问题，但我没有依据，由于我印象很深，我前两天作过的tracert66、69跟今天tracert是彻底不一样的结果，咱们tracert结果以下图，只通过三跳！

 

 

任何事情知其然，更应该知其因此然，而后结合前面咱们测试的时候出现网络不稳定的状况，时好时坏而非一直都是慢！所以我更加确信确定有别的缘由致使这样，而究竟是什么缘由的问题呢？请你们结合上面拓扑跟我一块儿进行分析如下几个问题：

 

 

第一点：在思科6509上下挂PC测试正常，这个很容易迷惑，就认为整个厦大学生公寓内网都有去往LNS的路由，并且老师强调他们已经在6509下发了，这样就更加的肯定内部有学习到去往LNS的路由（当时不知道老师所下发的是直连路由，觉得是下发静态路由）

 

若是光是第一点，咱们若是在客户端Tracert路由也一下就发现了，可是为何咱们拨号前tracert时的路径是三跳是对的(跟今天的tracert不一样，今天的是绕了一圈）？因此我在排故后一直在想缘由，这个很奇怪，后来决定再问校方它的具体拓扑链接状况，虽然老师讲得很含糊，但我了解到厦大学生公寓这块网络连至厦大校园网的接法，并非只有一条经过6509到校园网，而是有二条作自动流量负载分担（基于什么方式分流，没有具体问，有可能在流量比较小的时候走上面一条，若是超过必定的流量的时候就超出部分的走下面的一条，这样对核心设备也能够启到分流功能）而这样一分析就明白了为何那天早上8点测试的时候是正常的，而到11点后测试就不正常了。

由于正常的时候是走上面一条的，不正常时是走下面一条，而为何选择走上面一条时会是正常的呢？？？（注：这里的正常包含：拨号正常3-4s,下载正常220左路、打开网页速度快！）

流量走上面与走下面的区别在于：走上面那条是有通过思科6509，而在6509上有配置了静态路由，而走下面的没有通过6509，且没有去LNS的路由，可是经过绕教育网也可以到达ME的LNS，所以拨号慢！

也能够简单的说在没有把LNS地址重分发到内网时，只要有通过思科6509就能够正确的路由到LNS（6509上没有作策略）．若是这么分析这就取决于这个流量的路径是如何走，直接影响到拨号的路径及创建隧道后的速度。

 

而当时咱们一直是认为只有一个出口（老师大概跟咱们讲的三层结构，由于他们认为校园网跟这次项目关系不大，没有必要说这些），而且有出现同一台电脑在不一样时段出现情况彻底不一样的状况。由于是同台电脑、同个环境tracert，正常时tracert66与tracert69结果都同样三跳，而致使后面一直错误的认为ME60上66跟69同样，认为tracert69与tracert66同样，这个是潜意识，但仔细分析就知道是彻底不一样的。（直连分发了，静态没有分发）而以前就一直认为是网络不稳定、加之说联通同样环境是正常，因此又把思惟转到去想是否是距离太远了？光模块不兼容等等其它因素。

 

 

总结心得：

l  不能以篇盖全；

虽然在正常状况（直连和静态路由都在作重分发的状况下），Tracert112.5.66.69与Tracert112.5.66.66这两个地址的跳数是同样的（66、69是在同一台ME60上的地址，通常状况下同一台设备上的地址，tracert都是同样的），但不能由于这样就认为Tracert66与69都同样，事实证实在没有下发静态路由而只下发直连路由的时候，Tracert这两个地址是彻底不一样的，而这也是最大的迷惑点，由于都在同一个ME60上的地址，咱们就是由于开始去tracert这两个地址，都是同样是三跳，从而致使咱们认为每次去tracert 69就认为够了，使得开始判断方向就错误了。

l  思路要清晰、目的要明确；

特别是这种很是重要的大客户、大项目，在关键时候出问题，时间又很是有限，真的会叫人茶不思、饭不香，我想这个文涛应该跟我在这几天深会颇深，而这也是考验咱们的时候，越在这种关键时候，越不能急、慌，相反思路要清晰、目标要明确，须要要作好更多的准备工做，甚至包含备用方案，假如问题尚未解决，要如何应对，也就是缓兵之计，尽可能给咱们争取更多的时间。由于对于客户来讲是要把问题解决，而对于这次项目咱们也是同样，在这么短的时间里极可能尚未排故出来，就可能须要采用备用方案。

l  多尝试、多变换;

固然任何故障、问题在排解成功后，都会认为就这么简单，其实这就跟脑筋紧转弯同样，在你没有知道结果前都是很迷惑，感受到好难，当你知道答案时候就会有一种恍然大悟的感受；可能会去感叹本身前面作了这么多的无用功，没有什么意义！就像此次项目，前面作了光路、设备兼容性、模块兼容性、方案的可行性、抓包分析、距离太长等一系列的工做，去确保任何一个环节是没有问题的，在如今看来都是无用功，没意义！可是在没有找出缘由以前却不是这么认为的，而在分析须要尝试的状况下这一切咱们能够想到的、要尝试的都有意义，这是一我的的技能经验提升的一个过程！固然这个尝试须要进行分析，不能盲目性。

还有在排查故障时要多变换,此次项目，若是测试的方式、测试的地点、测试的时间点、多变换，进行横向、纵向的对比！可能就更快的排查出来了！

l  多讨论、多沟通；

这点让我感悟较深，之前我碰到问题就本身一我的在思考、在作实验、找资料，其实不少时候碰到问题的时候就是要多沟通、多讨论，由于每一个人都有本身的思惟方式、想法、每一个人的知识面涵盖的范围不一样，可能讨论、沟通并不必定能直接帮助你解决问题，但也许他说所的东西可能就启发了你，让你找到解决问题的方法！

 

因此经过此次项目写这个报告但愿能给你们带来点帮忙，这些都是我的的一些见解、观点，若有不一样观点、见解，也但愿你们共享下，之后多多交流、沟通！相互提升！