厦大学生公寓故障排查

厦大学生公寓故障排查

把主要的排故过程进行归纳总结：

     为了确保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  多讨论、多沟通；

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

 

所以通过这次项目写这个报告希望能给大家带来点帮忙，这些都是个人的一些看法、观点，如有不同观点、看法，也希望大家共享下，以后多多交流、沟通！相互提高！