- 程序有所改变。发帖如还有问题请报告
- 【征集】西西河的经济学，及清流措施，需要主动参与者，『稷下学宫』新认证方式，24年网站打算和努力目标
主题：【原创】寻找小强 -- 数据传输故障调查实例 一 -- 萨苏
我们公司在类似的时间上海的一条线路也有类似的问题，具体表现是特定服务传输效率急剧下降，影响正常使用。查了一个多礼拜，所有的东西都换过，所有的供应商也骂完了，最后是中国电信出来承认说他们没打招呼就把我们线路上的QOS关了。。。
为虾米不是www.daie.com乜？试了一下，原来已经人抢注鸟……
为什么不着急呢？
因为大多数网络问题，往往都是无疾而终。
这当然不是说网络是和人一样有再生功能的，肚皮上切两道口子，不理它过几天就好了，网络可没有这个功能。虽然也有太阳黑子活动剧烈导致网络中断，不管它也会恢复的例子，但大多数的网络问题，还是“没病死不了人”，没有人去解决，不会自己消失。
查！看是不是铁道游击队改行了？
但是，IT行里心知肚明的一个潜规则就是，ISP很少承认自己网络存在故障。这在我国十分典型。您公司要是有专线可能会体会到，要是线路断掉，给电信的八路打电话去问，八路的回答往往是 – “我们查一下阿。”
然后，没动静了。
再打，人家会说 – “没问题阿，你再试一下。”
聪明人一试，通了，什么话也别说，打枪的不要，乖乖接着干活儿就完了。
笨的呢，通了，还给人家八路打电话 – “长官，你们干了什么了？怎么就通了？”
人家回答 – “我们什么也没干阿。”
浪费电话钱。。。
你又不是电信的领导，人家就发现混线了或者哪个Shaping做得不对有必要跟你汇报么？
国外的ISP要客气得多，五分钟一次地跟你汇报进展，就是每次都没找着毛病之前自然病愈。
你只能相信他也不明白是怎么回事。。。
这次，我们组的工程师上来一测，线路两端通畅，六脉吉祥，心里大体就有数了 – 多半是哪家服务商的线路出了故障，可没抓住人家的手。公司内部有监控系统，但监控的对象是点对点，中间这段儿的炮楼是好几家负责的，究竟哪里出了问题，刁世贵说是汤司令通八路，汤司令说是易先生脚踩两条船，易先生说刁世贵是地下党，那可是个打不清的官司。
现在，虽然慢，接到报告时数据传送的事情已经干完了，而且网上测了测，所有指标都正常，看不出不正常的地方来。工程师只能发个公函给各个服务商，要每家给份报告说明自己那段有没有看见过八路，结果自然可想而知。
太君，俺们这疙瘩肯定没来过八路
这种事，通常拖过一段大家就会忘记。
然而，这一次不行了，第二天业务部门又半夜鸡叫起来 – 还是慢。
不敢怠慢，工程师登录上去看的时候，数据还在传，果然是慢悠悠的样子。一面冒火一面首先联系各炮楼。
结果还是 – 太君，八路的没有。
不信我们的话，有种你自己上炮楼瞧去
还真说不出什么来。
为什么呢？
线路测试确实表明，依然是两端通畅，六脉吉祥，传输时限要求是200MS，结果只有127MS，这供应商是个有心的，专门提供给我们一个网页可以随时看他们的网络状况，真的假的不说，显得满有诚意。
上面这张图是个例子，并不是当天的实际情况，可以看到作为ISP，提供的资料还是很详细的。
特别是我们一直担心的数据传输出错率，这里可以看到是0.00%，说明出错很低，按说不应该有问题啊。
还有一种可能，双方负责传输的网络设备负荷过高，无法承担工作。
检查了双方路由器的工作状况，CPU和内存的使用率都不高，显得富富有余。
可数据传输还是慢。
一线不行，就得叫二线了，半夜把老萨叫醒。
老大，快出来看看，弟兄们顶不住啦！
半夜里爬起来，就算不是冬天也不舒服，不过，对于解决问题，老萨比这哥们儿还自信。
因为网络上的故障，说穿了复杂的并不多，多半是土八路用汽油桶放炮仗，红灯照作法，只要找到症结，不难解决。
于是，听了听这位的汇报 –
两端路由器之间没有丢包，两端对着测一下，速度值令人满意。看来，至少广域网上不该有问题。
为什么不从两端的服务器做一个简单的点对点Ping对测呢？
这比较困难，主要是防火墙上对Ping这种简单的测试手段进行了屏蔽。这还要归功于当年中国红客攻打白宫造成的震慑。为了报复美机轰炸中国驻南斯拉夫大使馆，2001年5月4日，八万名大多不懂网络技术为何物的中国网民，在某些“别有用心的人”指挥下，于固定时间一二三同时对白宫网站的地址发出了Ping测试的数据包。百川归海，这些每一个都不起眼的数据流汇集到白宫就成了超强的“数据炸弹”，白宫网站因而一时瘫痪。
从那儿以后，各国乃至各大公司，普遍在防火墙上设置拒绝Ping所使用的ICMP数据包。由于这是一条国际线路，双方合作精神不够，都没有为对方的Ping测试解禁，这下子给寻找问题带来了意外的困难。
一方面联系双方的防火墙负责人紧急解禁，一方面我们也不能干等着吧。萨调出Sky-X上的数据传输记录来，想看出问题何在。
几分钟以后，还真让我看出点儿东西来。
初看，传输的速度很高，最高的时候几乎把10M的带宽占满，似乎网络传输的效率颇高。但是，老萨把传输记录每秒取一值，问题就露出来了 。。。
在我的眼前出现了一排锯齿。
而正常的数据传输，应该是一条平滑曲线阿。
曙光，好像就在前面。
好像。。。
[待续]
作者意外获得【西西河通宝】一枚
推荐成功!
闯关东里的潘老板出来了
一个会藏，一个会找啊
到SC卧底过？
唉，有的时候真的是无奈到极点。
兄弟我就是混迹IT，这种感觉由来已久，IT就是挨踢，此言不虚。
俺们罗刹国的ISP最差劲...网络也是传输速率极慢...这俩月我天天跑他们公司,天天打电话...也没结果...技术部门还让我写申请,派人来看看...写了2份了也没动静...罗刹朋友说 他们国家就这样~公司都是开了今天,就不知道明儿的...
对于没明显征兆的问题！
IT解决这些问题只好用排除法
用不同设备，不同端口，不同链路，不同运营商线路
去一部分一部分替换这样来查！
分段打软环排除，运营商应该提供测试端口
网内有没有中毒？
端口利用率一直很高吗？
看着这排锯齿，老萨一声冷笑，这东西看着眼熟阿。
锯齿的含义就是数据传输不能稳定保持在某个速率，忽快忽慢。这种问题的起因往往是数据传输中丢包造成的线路不稳定。
对啊，想想如果运军火的列车一路上老丢东西，货运单永远对不上号，那整个运输计划能不乱么？这就是铁道游击队厉害的地方。
前面处理这个问题的工程师表示他也有同样的看法，但是日本到对端的国际线路上，数据包的传送丢失率很低。
巴嘎，你的，军人的不是，战术的不懂，土八路不在铁路上下手，难道他不会在车站里头截么？
一句话惊醒梦中人。这网络上呢，讲究的是铁路警察各管一段 – 比如这位工程师所属的部门，只管国际之间的线路 – WAN，这相当于铁道线；另有部门负责公司内部的网络连接 – LAN，这相当于车站；还有部门专门负责服务器，这相当于军火仓库。这样的分工协作，可以各自发挥专长，但也容易造成缺乏换位思考的现象，
彩云追月：听说鬼子已经盯上车站这块儿。。。 忘情：你是说走私臭豆腐那事儿咱先不干了？
虽然数据传递实际上既要跨越国际线路也要通过内部网，任何一段都可能出现丢包，但一般来说，国与国之间的线路出问题，大家想的多半还是国际线路上有没有故障，因为那毕竟好几千里地呢，从距离上看，公司楼里头的网络基本可以忽略不计。可是如果吃过几次苦头，就会考虑问题是否可能出在公司内部网上。因为虽然国际线路很漫长，但光缆埋在地底下很少有人会去动它，而公司内部，经常有些多动症的家伙冲着各种设备一直在改，造成种种事端。
和平阿姨：小伙子，这影射城主的话儿可不能乱说
甚至，我都能猜测出问题可能出在什么地方。
于是萨一个电话把负责内部网的同事也从被窝里拎出来，让他测试相邻设备之间的连结有无问题。这是个大连来的小伙子，刚毕业，处理故障经验不太多，但挺肯干的，几分钟就把结果拿出来了。
这种测试的方法很简单，上一部分说过，公司内部的连结是服务器 –〉Switch -> 防火墙-〉Switch ->路由器。这个测试就是要求他从每个设备对邻居作Ping，来看结果。
在路有器和Switch之间的Ping结果有些值得注意的地方，有兴趣的朋友可以看看 – 不是这一行的看不懂也不要紧，注意最后一段就可以了。(我把真正的地址用xxx代替了)
>ping
Protocol [ip]:
Target IP address: xxx.xxx.xxx.xxx
Repeat count [5]: 123
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 123, 100-byte ICMP Echos to xxx.xxx.xxx.xxx, timeout is 2 seconds:
!!!.!!!!!.!!!!!!.!!!!!.!!!!!.!!!!!.!!!!!!!!.!!!!!!.!!!!!.!!!!!.!!!!!!!
!.!!!!!!!!!!!!.!!!!!.!!!!!!!!.!!!!!!.!!!!!.!!!!!.!!!!
Success rate is 86 percent (106/123), round-trip min/avg/max = 1/3/31 ms
问题，就出在加重的部分。网络Ping测试结果中，“！”表示通，“.”表示不通，这个结果说明了什么呢？可以看到123个测试包中只有86%（106个）回应，其他的都被丢弃！据此我判断路由器与Switch之间通信存在问题。
如果是这样，那这条线路上的故障就迎刃而解了 – 远端的数据跋涉千里到达本地的时候并无问题，但通过路由器传递向服务器的时候，在通过Swtich数据交换机时丢包，所以降低了传输质量，引起速度锐减。
说，皇军饭盒里的臭豆腐，是不是你放的？！
这个结果在我意料之中。路由器和Switch数据交换机都有高速以太网端口，是用网线直接连结的。这种构造的连结上，经常会出现一种错误，结果正是造成丢包。（stam69兄弟提到了这种可能，行家阿）
什么问题呢？这就是Cisco两台设备之间连结时，端口Duplex参数的设定不匹配错误。
Duplex参数是干什么的呢？它是用来决定网络端口怎样工作的，可以设成三种 – Full（全双工）, Half（半双工）和Auto（自动设定）。
Full全双工的意思是这个口收数据的时候同时也能发数据，是复线铁路，进出互不影响。Half半双工的意思是这个口收数据的时候只能收，发数据的时候只能发，是个单线铁路，效率低一点。
网络端口的全双工和半双工工作方式说明示意图，上面是半双工，下面是全双工
今天大多数网络端口都是全双工的，也有少数只能半双工工作。
两个端口相连的时候，双方的工作方式必须一致，你是Full,我也得是Full，你是Half，我也得是Half。
否则双方之间的数据通讯就会大量出现丢包。
做IT的里头，象老萨这种棒槌不是很多，大多数干这行的家伙都属于浑身是消息儿，一按就会动，眼睛毛都是空的。假如端口的配置只有Full和Half两种，多半不会有人弄错。那是，跟男浴池女浴池一样，那也能走错么？
问题是Cisco公司比老萨还棒槌，它规定，Duplex的设定呢，除了Full，Half以外，还有一种叫做 – Auto。
按照Cisco公司的说法，这Auto（自动设定）可是个好功能。比如你不熟悉端口的技术，弄不清该设Full还是Half的时候，两边就设成Auto，两端的机器会自动将双方之间数据传递的工作方式调整成都是Full或都是Half，于是，双方就可以流畅通信了。
好功能吧？
嘿嘿，问题就出在这个“好功能”上。
Auto（自动设定）的这种功能，会让人想当然地认为，既然两端都设成Auto可以，那一端设成Auto，对端设成Full，Auto一端就应该也能把自己的工作方式调整成Full吧，如果一端设成Auto，对端设成Half，Auto一端也应该能把自己的工作方式调整成Half吧？
错！
也不知道Cisco公司怎么想的，按他们的设计，如果对端是Full,自己是Auto的时候，会把工作方式设成Half，如果对端是Half，自己是Auto的时候，会把工作方式设成Full，刚好弄得双方不匹配。
怎么拧劲儿怎么来，难道这样设计的老板是吃剑麻长大的？
于是，路由器和Switch连结的时候，往往换个口就会出现大量丢包现象，因为Switch上各个口的工作方式，出厂设置都是Auto，假如路由器设的不是Auto，随便换个口双方会不匹配。
这种事情我们排故障的时候遇到很多次了。
好你个小强，穿上马甲就以为咱找不着你了？
看着测试结果我把自己的设想和工程师说了，大家都说太阳底下无新事，八成是这问题。
萨对此也颇为自信，让负责内部网的工程师查查设置。
五分钟以后，人家说 – 老大，不对阿，两边设的都是Full…
80%的支持率一下子摔到了零。。。
嗯？如果不是工作方式设错了。。。那肯定是网线有问题！
这句话也不全是为了面子，确实有网线使用不当，被重物压坏等事情发生过的，网线受损造成的丢包也会出现同样后果。
然而，这样说着，我的眼睛扫过刚刚取下来的网络端口信息，心里往下一沉。
sh int gi0/0 | in err
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
107527195 packets output, 1536956913 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
如果网线出了问题，根据我的经验，网络端口上应该出现CRC错误报警，而这里CRC错误数居然是0！
上当了，小强不在这儿！
这就说明网线应该是好的。
可要是都没错，怎么Ping会有那么多丢包呢？
这时候，有个工程师在说 – “要不，把网线换一根试一下？”
“不行啊，上面还有很多数据在跑，现在可不能换。。。”
听到这句话，我忽然若有所悟，拿过Switch的工作情况细看。
这一看看出了个沮丧的结论 – 嘿，从一开始我就判断错了！
这回可栽啦！
[待续]