网络丢包现象分析处理指导书111.docx
《网络丢包现象分析处理指导书111.docx》由会员分享，可在线阅读，更多相关《网络丢包现象分析处理指导书111.docx（84页珍藏版）》请在冰豆网上搜索。
网络丢包现象分析处理指导书111
“网络丢包现象是常见的网络故障，但引起丢包的原因却多种多样、千奇百怪。
因此对于此类故障的解决，要求处理人员洞悉网络基础理论、了解不同厂家产品特性，有耐心、深入地进行分析定位。
”－－－《网络丢包现象分析处理指导书》摘录
从今天开始，本站将陆续发布系列网络丢包问题分析处理的技术文章。
该系列文章来源于《网络丢包现象分析处理指导书》，主要分成三大部分：
第一部分：
讲解从产生网络丢包问题的原因来看，网络丢包问题大致可以分为六大类因素，1、网络设备软、硬件问题；2、线路传输质量差引起丢包；3、网络设备配置不合理导致丢包；4、网络设计不合理导致丢包；5、人为攻击、广播泛滥造成的丢包；6、网络环境造成的丢包。
对于每类丢包原因配置以大量的案例进行详细的说明。
第二部分：
主要有三方面的内容，一是深入剖析网络丢包现象并加以总结；二是网络丢包的一般处理步骤；最后就是讲解网络故障处理中相关工具使用的注意事项。
第三部分：
四个故障案例处理过程分析。
应该说是对前面两部分内容的一个综合应用。
该系列文章的原始版本是原GW的HB老大当年的手稿，经过与原作者协商，同意在网站上发布。
为此非常感谢HB，对HB的无私精神表示深深的感谢。
网络丢包问题往往是没有规律的故障，对于没有固定规律的故障，咱们技术工程师往往有吃力不讨好的痛苦！
如本手稿中环境因素导致丢包案例中的电源浪涌，时值北方的冬季，加之故障这个魔鬼出现的时间是晚上7:
00-9:
00这个时段，现场工程师在用户单元楼道可以用饥寒交迫来形容！
在此感谢为本手册付出了无数心血的原GW技术资源部的XDJM，正是他们的加班熬夜，将经历过故障进行总结，才能有今天这份珍贵的手册。
本手册是在原《网络丢包现象分析处理指导书》基础上进行部分的改动，谨此献给所有原GW技术资源部的XDJM，献给那段美好的光阴！
献给那段偶们一起共同奋斗的岁月！
网络丢包现象分类：
网络设备软、硬件问题导致丢包
首先对出现过丢包的案例进行描述并给出解决办法，同时对丢包问题进行分类，主要加强大家对丢包现象的感性认识。
在后续的章节中再做深入的剖析，并提供问题的解决思路。
1、uHammer24百兆光口/电口模块问题
问题描述：
uHammer24芯片为C版且PCB为2.33版的设备百兆端口模块第25口，在高温及常温下会出现严重丢包，高温条件下尤为明显。
C版（PCBv2.33）uHammer24port25丢包示意图
问题解释：
uHammer24的硬件分B版和C版，C版uHammer24的百兆端口模块25口的接口电路（千兆端口不受影响）在高温条件下（50ºC以上）不稳定,造成丢包；B版在高温条件下（达到60ºC）仍不会出现丢包。
问题解决：
正确识别B版和C版设备。
C版设备尽量使用在不用百兆端口模块的环境，如果一定要使用百兆模块的话，则建议更换B版设备或采用PCB为2.44/2.55的设备。
备注：
此类丢包由于硬件芯片（产品序列号的第九到第十二位为“A233”）离散性较大引起，产品的PCB已做修改，新生产的设备，同样为C版，如果产品序列号的第九到第十二位为“A244”或“A255”则不存在此bug。
重要提示：
如果出现某个端口丢包，建议更换端口做测试，查看丢包现象是否是个别端口问题。
问题描述：
部分uHammer1008v（或者VDSLmodem）由于晶振品质问题，导致与uHammer3100互连，距离较长时，出现严重丢包或同步不上。
问题解释：
晶振品质不好，产生的脉冲信号在长距离传输时崎变较大，使得接收端无法识别。
问题解决：
uHammer1008v（VDSLmodem）更换品质较好的晶振。
备注：
此类丢包也属于暂时性问题，更换硬件器件后将不再复现。
网络的拓扑如下
RiverStone3000（L3）作为网络的核心交换机，Flex16i汇聚了20几台接入层交换机u2，Flex16i只作为二层透传，所有用户的网关均指向Rs3000。
网络稳定运行了3天后，Flex16i的下连用户出现5％丢包。
Testpcping210.177.208.163或164均出现5％左右的丢包。
Rs3000上pingserver出现5％的报文出现延时时间达到1秒。
可以判断，客户端丢包是由于icmp报文超时的缘故。
问题解释：
为了更准确地定位问题，做了如下测试环境。
用Testpcpingpc2同样出现5％的丢包率。
Rs3000pingtestu25％报文的延时在1秒左右。
在测试过程中，测试过Flex16i同一设备（510芯片）和不同设备（510芯片）下的二层用户互ping，同样出现5％丢包。
显然可以排除光纤、u2等其他设备引起该问题。
实际环境和测试环境中RS3000直接pingFLex16i的IP地址均没有出现报文延时时间长的现象。
但pingFlex16i下连的u2则出现5％左右的报文延时长。
因此，可以判断问题出现在Flex16i的二层转发上。
问题解决：
将Flex16ireboot，故障依然；将Flex16i关电重启，故障消失，网络恢复正常！
热启动和冷启动对于Flex16i来说，其硬件的初始化过程不一样，冷启动对硬件的初始化处理比较彻底，是否硬件还存在深层的Bug，需要研发人员做进一步的定位。
备注：
虽然该故障定位在Flex16i上，但是是什么原因引起Flex16i的二层转发异常，并未能给出一个圆满的答案，不能不说是个遗憾。
不过，这里要强调的是故障的定位处理，事实上这样的工作已经有利于研发对产品的改进工作了。
问题描述：
uHammer24软件版本为v1.323以下的版本的部分设备存在着14、18、22端口严重丢包，下连用户上网速度慢。
在v1.323版本出现个别端口丢包的现象已很少见（到目前为止市场上反馈过2例v1.323port14有丢包现象），升级为v1.4版本可以彻底解决。
问题解释：
某些u24的phy芯片对时钟很敏感，如果交换机主板硬件出现频差，则phy芯片工作就不正常。
目前v1.323版本中通过定期写寄存器去修正频差产生的影响。
但是V1.323中轮循的时间过长，phy芯片的寄存器没有及时得到更新，所以会产生很明显的linkdown现象。
在v1.4版本中，缩短了轮询时间，到目前为止未发现个别端口丢包现象。
问题解决：
升级到v1.4版本可彻底解决此问题。
备注：
对于新上设备，要求最低可用版本V1.323。
问题描述：
Flex5010v1.0网段表设置算法缺乏考虑路由最长匹配原则，当路由条目存在多个匹配信息时，容易出现数据包循环转发，表现为用户上网速度慢、丢包甚至网络不通。
拓扑结构见下图：
（为了说明问题，网络拓扑已做简化）
上图为一大型行政机关的网络拓扑图，该单位网络为专网，与Internet没有互连，采用10.0.0.0/8的地址段。
其中Flex5010以千兆光口与Big800互连，Big800端分配到10.94.0.0/16的网段，Flex5010端分配到10.95.0.0/16的网段。
Flex5010软件路由表存在的条目如下：
10.94.101.4/30直连
10.95.1.0/24直连
10.95.2.0/24下一跳10.95.1.253
10.0.0.0/8下一跳10.94.101.5
而Flex5010v1.0的硬件网段表在开机时是空白的，只有当软件路由表的路由条目使用过一次后，才将其置入硬件网段表中。
同时，一个报文在Flex5010路由时，是先去匹配硬件网段表，如果匹配不到才去匹配软件路由表。
考虑一种特殊的情况：
10.0.0.0/8的路由早于10.95.2.0/24置入硬件网段表。
即此时的硬件网段表只有一项：
10.0.0.0/8下一跳10.94.101.5
此时，当Flex5010下连的一台主机（10.95.1.1）去与10.95.2.0/24网段的设备通信时，则会出现:
10.95.1.1发给10.95.2.0/24的报文到达Flex5010后，Flex5010查找硬件网段表，首先匹配到10.0.0.0/8的条目，因此该报文转发给10.94.101.5（Big800）,Big800查找路由表，发现该报文应该转发给Flex5010，Flex5010再此将报文转发给Big800，于是，此类报文在Flex5010和Big800之间循环转发，指导TTL值为0，设备才将报文丢弃。
由于大量的废弃报文在Big800和Flex5010的链路传送（一个上述的报文在该链路需要转发250多遍），因此造成链路拥塞，网络丢包、不通。
问题解释：
先激活先置表的算法违背了最长匹配算法，因此，在多路由匹配的环境下会出现上述问题。
问题解决：
OS为v1.1以上版本可解决此问题。
V1.1不再采用先激活先置入网段表的算法，而是一开始则将所有路由条目置入网段表中（除了路由条目超过16条的情况）；如果路由条目超过16条则放弃网段表不用完全走软路由（关于路由条目超过16条后如何充分发挥Flex5010的硬件资源请详见《Flex5010硬件表设置方案》。
备注：
此类问题由于是设备软件bug引起，因此准确定位问题比较困难。
往往通过捕获链路上的数据流定位出现问题的设备，再深入分析设备的硬件、软件路由信息，任务、进程等等，最终才能确定问题所在。
问题描述：
Flex16i与u1光口互连，u1下连用户出现严重丢包。
由于现场没有光功率计，未能直接测试光纤的传输质量。
于是更换Flex16i、u1来定位故障点，更换设备后问题依旧。
最终将焦点集中在传输链路上。
问题解释：
从Flex16i到下连的u1，中间经过Flex16i－光纤跳线－传输光纤链路－光纤跳线－u1，由于缺少光纤线路测试仪器而未能确认传输链路是否有问题，因此通过更换设备来协助判断是有效的方法。
既然Flex16i、u1的设备更换后问题仍然存在（更换设备前，最好先确认新替换的设备不存在问题），那么传输链路就是最大的嫌疑了。
问题解决：
用酒精清洁光纤传输链路两边接头，问题解决。
备注：
光纤接头被污染，导致接头信号耦合不良，引发线路误码，最终体现为丢包。
问题描述：
Hammer10000做二层透传，通过光纤链路上连到cisco4006，Hammer10000只作L2透传。
Hammer10000下连用户反映，上网速度慢，有时断线。
局方反映网管也有断线现象。
问题解释：
Hammer10000二层版本前期不稳定，DSLmodem与用户网卡匹配存在问题，因此一直将目光盯在Hammer10000上。
事实上，Hammer10000经过软件升级、用户网卡更换后，Hammer10000已趋稳定。
上连链路仍旧出现丢包，完全有理由要求局方测试光纤链路传输质量。
但局方却自认为光纤链路没问题，使得故障的解决拖延时间较长。
问题解决：
后来经过协调，局方清洗了未纤，用户上网及网管中断问题得以解决。
问题描述：
网通XX公司在XX大厦中心机房的3100设备目前有两户用户，分别在第1端口和第2端口。
放号几个月以来，在线路距离相差无几的情况下，位于第2端口的用户使用情况正常，没有发生任何故障投诉。
但是第1端口的用户却经常投诉说上不了网，或是丢包率高。
问题解释：
为了彻底对故障进行定位，在1端口用户即中国技术进出口公司的机房，发现VDSL的modem同步不上。
从该公司的维护工程师张工处了解到，MODEM每隔一段时间就同步不上，丢包发生主要在这种情况下。
但在同步的情况下，也仍然有丢包情况存在。
在这种情况下，我们认为最有可能是线路质量问题。
但是也不排除设备1端口故障。
在网通中心机房，对设备相关参数进行仔细分析，在1端口偶尔同步上的间隙，发现该端口的线路信噪比为21db。
而线路质量要求信噪比起码要在25db以上。
所以1端口掉线频繁。
而与此同时测试2端口，其信噪比为34，所以同步状况一直良好。
在1端口近端连上一个MODEM，很快同步，信噪比为34，因此推定一定是从机房出去途经物业到25层中国技术进出口公司的线路有问题。
为了使这个判断更可信，我们将这次带来的新的3100替换原来机房的3100，在配置不变的情况下，情况和前面如出一撤。
随后我们与XX大厦物业联系，携带笔记本和MODEM对每段跳线进行详细的检查。
确认从网通中心机房到物业配线架端同步情况良好。
在物业配线架上将该用户端口改跳至另一位置，再到位于XX大厦9楼的一个竖＃的配线架进行改跳线后，检查同步情况及信噪比参数，显示为34，说明正常。
而9楼竖井直接由一根5类线到25层的XX技术进出口公司，所以应该没有问题。
最后再回到25层技术进出口公司，发现MODEM同步状态正常，但是一查看线路信噪比却依然是21db！
而且MODEM拔电之后又同步不上！
最终问题只能定位在连接MODEM的那根线的RJ11水晶头上。
问题解决：
得知该水晶头是公司的某个工程师自做的。
仔细一看，该水晶头的中间两芯竟然不是同一对线！
而是一根数据线和一根不相关的线，这样H3100和modem的地线不同，所以同步当然有问题，掉线也好，丢包也好都由它引起。
重做了水晶头之后很快同步上，线路信噪比也达到了34db，ping10000个大包几乎没有丢包现象。
备注：
由于用户端口出现有时同步不上、丢包等现象，使得我们很难跟用错线对挂上钩。
这也说明了丢包现象的内因具有多样性，排障过程要求我们不放过任何蛛丝马迹。
设备端口不匹配
问题描述：
在用户的上网高峰期，出现速度慢、严重丢包等现象。
问题解释：
经过查看cisco2621的上行端口（与光电收发器连接的端口），发现输入报文出现大量的CRC校验错，由此可以确定为路由器的物理端口或上行链路问题。
进一步查看上联交换机catalyst，发现其下连端口工作于自协商状态，而协商结果为100M半双工。
光电收发器一般不具有自协商功能，工作于100M全双工状态。
由于上连设备端口状态不一致，因此整条链路出现大量报文出错。
问题解决：
保证互连设备的端口的工作方式一致，问题解决。
备注：
1、两网络设备之间互连，要确认两端端口的工作状态一致；如果设备之间通过光电收发器做转接，需要确认如图三所以的四个端口的状态一致，只要其中一个端口状态跟其他端口不一样，则整条链路均受影响。
另外，要求理解端口自协商的工作机制。
2、100BSAE-TX/10BASE-T端口的协商机制：
目前，多数网络设备的以太网口都支持自协商。
支持自协商的以太网口对接，可以采用一种标准的物理层信号FLP（对于FASTETHERNET）或NLP（对于ETHERNET），通过一种协商机制，将双方的工作模式设置为双方都能支持的最高速率。
例如，双方都支持自协商，并且两端的最高速率都是100M全双工，协商结果应是100M全双工；如果双方都支持自协商，一端的最高速率是100M全双工，另一端是100M半双工，协商结果应是100M半双工；10M全/半双工的情况可依此类推。
通过自协商机制可以保证双方的速率和双工模式一致并且达到双方都支持的最高速率，从而保证传输的效率。
但是如果一个支持自协商的网口与一个不支持自协商的网口对接，则可能出现问题。
支持自协商的网口通过接收的信号可以判断出对方的速率是100M还是10M，但因为没有携带足够信息的FLP或NLP，无法判断出对方的全/半双工模式，所以通常只能根据对端的速率将自己设为100M半双工或10M半双工。
例如：
一个支持自协商的网口与一个固定100M半双工网口对接，自协商网口通常会将自己的模式设为100M半双工，两端模式一致，可正常通讯；但是如果一个支持自协商的网口与1个固定100M全双工网口对接，自协商网口通常会将自己的模式设为100M半双工，这样一端半双工一端全双工，通讯时链路上会出现碰撞，导致丢包错包。
所以我们设置网口模式的一个基本原则是：
互连的2个设备的对应网口工作模式设置一致。
必须杜绝将一端设置为自协商，一端设置为全双工的方式；如果一端网络设备不支持自协商，应该也禁止对端的自协商功能，强制将两端的速率和全/半双工模式设成一致。
问题描述：
网络拓扑见下图，在用户上网高峰期，在big400上ping外网出现严重丢包，内网通信正常。
问题解释：
设备之间一边工作自协商，一边工作100M全双工，当自协商的一边没有收到对端完整的端口协商信号时（FLP）时，将自己设为100M，半双工，造成两边端口状态不一致，报文在链路中产生冲突、错误。
问题解决：
将互连设备两边端口设为一致，则问题解决。
备注：
做工程时，要求检查与我司设备互连的设备的端口的工作状态，并要求配置一致。
牵涉到其他厂家设备时，客户有时不大愿意让你去操作其设备或者自认为配置没问题而不需要查看其他厂家设备，这时需要我们灵活处理，其实很多时候只要你把排障意图跟客户讲清楚，客户觉得你有道理，还是能到达你希望的目的的。
比如，濮阳油田的这次故障，客户很肯定的说其NetScreen的trust端口的双工方式是固定全双工的，不需要确认。
但是，通过跟他们分析端口之间的协商原理后，客户意识到设备之间端口的工作状态一致的重要性，同意检查NetScreen的情况，甚至到后来让我们自己操作，帮助他们查看NetScreen的配置是否合理。
问题描述：
cisco3640与Big800互连，cisco3640作为出口路由器，在上网高峰期，Big800下连用户出现上网速度慢，ping外网大量丢包。
Cisco3640一侧采用10M端口，Big800一侧采用100/10M端口，出现故障时看到cisco3640的端口有大量CRC错误。
问题解释：
cisco3640的早期IOSv12.0版本对10M端口的双工方式不提供配置命令，默认工作状态就是10Mhalf；Big800一侧端口工作于10Mfull，两边不匹配导致丢包。
问题解决：
将Big800的端口配置成10Mhalf可以解决问题，但是我们知道cisco3640与Big800在物理上是点到点的连接，建议最好让双方都工作在Full状态。
通过升级cisco3640新的IOS，问题得到彻底解决。
备注：
当然，其他厂家设备的软件升级我方最好不做，以免承担过多的责任，建议客户自己升级。
不过，在有充分把握的情况下，客户自己升级有困难（得不到最新的软件、不会升级），我方也可以替客户排忧解难――包办，有利于工程的顺利进展
路由配置不合理
问题描述：
简化的网络拓扑如上图所示,在用户上网的高峰期，在出口链路上出现大量的丢包，而Big400内部用户的通信却正常。
问题解释：
Big400作为全网的核心交换，上面存在全网路由信息，包含：
172.16.0.0/24——172.16.31.0/24直连路由，默认缺省路由，下一跳指向NS100。
NS100作为出口设备，包含路由信息：
172.16.0.0/16（汇聚路由），下一跳指向big400，默认缺省路由，下一跳指向internet。
从上面两设备的路由配置，可以发现，当big400下连用户发wins报文（目的IP为172.16.255.255）或进行主机扫描（目的IP为172.16.32.0－－－172.16.255.255）时，Big400根据路由表（iproute0.0.0.0/0172.16.1.1）将报文转发给NS100,而NS100又根据路由表（iproute172.16.0.0/16172.16.1.2）将报文转发给Big400，这样造成报文在big400和NS100之间循环转发，直到TTL为0才将报文丢弃！
因此，大量的垃圾报文拥塞big400与Netscreen之间的链路，而且NetScreen需要为这些报文做会话连接，加重了NetScreen的负载。
问题解决：
以上Big400和NS100路由存在的问题，可以在Big400上添加一条汇聚路由172.16.0.0/16指向一个空接口来解决。
因为，根据路由最长匹配原则，172.16.0.0/16网段中包含的具体路由如果在Big400上不存在，则会匹配到该汇聚路由，从而将相应报文丢弃，不再往NS100转发。
消除了非法报文循环转发的隐患。
注意：
由于Big/Flex目前不存在黑洞路由功能，因此，建议用如下方式替代，在Big/Flex上创建一个汇聚路由，下一跳指向一个不存在的IP（直连网段的ip），为了避免交换机对不存在IP进行ARP解析，在交换机上针对该IP创建永久的arp条目和FDB条目。
如本例例可以配置如下，
Iproute172.16.0.0/16172.16.1.100
createfdbentry00053b999999 vlanv10:
1
configarp172.16.1.100 00053b999999
备注：
该故障具有典型的意义，像大部分的企业网、驻地网都采用类似的网络结构，在路由规划时要特别小心，除了考虑正常报文的路由外，还要防止异常报文不正常的路由。
网络设计不合理：
存在环路
问题描述：
校方要求H3100的端口之间实现二层隔离。
故障现象当有多个学生上网时出现速度慢，有严重丢包现象。
问题解释：
由于校方对用户进行端口隔离，学生宿舍之间无法互相通信，于是学生自己将宿舍之间的hub互连起来。
在网络的末端形成了环路，幸好H3100实现端口隔离避免了广播风暴的形成，但是将产生如下影响：
1、多个学生宿舍的数据流可能压到某个H3100端口上，造成某个端口负载过重，而且具有随机性，从H3100的一个端口上可能发现有几十个MAC地址；
2、router往下发出的arp广播报文会在H3100的接入端的环路走一遍，因此H3100的FDB表的用户端口会出现router的MAC条目，造成用户报文的转发异常，即丢包。
问题解决：
问题的解决需要防止环路的产生：
1、拆除学生宿舍之间的连线，H3100不启用端口隔离。
该方案校方未同意，而且学生宿舍之间的网络互连不好管理。
2、在H3100上启用stp，虽然stp能够防止环路的产生，但是必将阻塞多个产生环路的H3100端口，只留一个转发端口，所以该方案也不能解决单端口承受大流量的压力。
3、H3100上关闭各个端口的学习功能，实现MAC和port的静态绑定，将router、学生pc的MAC绑定在各自的端口上。
该方案实现起来比较麻烦，但是对该网络来说是最有效的。
FDB表结构问题
问题描述：
Catalyst4003和u24上分别存在两个vlan（vlan1、vlan2），两台设备的每个vlan各有一物理连线。
Pc1、pc2ping网关出现间断性丢包，pc3同样出现严重丢包，当拆除两根物理连
升级会员 