网络丢包现象分析处理指导书1(出处：www.ipdata.cn）

“网络丢包现象是常见的网络故障，但引起丢包的原因却多种多样、千奇百怪。因此对于此类故障的解决，要求处理人员洞悉网络基础理论、了解不同厂家产品特性，有耐心、深入地进行分析定位。” －－－《网络丢包现象分析处理指导书》摘录

 

从今天开始，本人(ipdata)将陆续发布系列网络丢包问题分析处理的技术文章。该系列文章来源于 《网络丢包现象分析处理指导书》，主要分成三大部分：

第一部分：讲解从产生网络丢包问题的原因来看，网络丢包问题大致可以分为六大类因素，1、网络设备软、硬件问题；2、线路传输质量差引起丢包；3、网络设备配置不合理导致丢包；4、网络设计不合理导致丢包；5、人为攻击、广播泛滥造成的丢包；6、网络环境造成的丢包。对于每类丢包原因配置以大量的案例进行详细的说明。

第二部分：主要有三方面的内容，一是深入剖析网络丢包现象并加以总结；二是网络丢包的一般处理步骤；最后就是讲解网络故障处理中相关工具使用的注意事项。

第三部分：四个故障案例处理过程分析。应该说是对前面两部分内容的一个综合应用。

该系列文章的原始版本是原GW的HB老大当年的手稿，经过与原作者协商，同意在[url]www.ipdata.cn[/url]网站上发布。为此非常感谢HB，对HB的无私精神表示深深的感谢。

网络丢包问题往往是没有规律的故障，对于没有固定规律的故障，咱们技术工程师往往有吃力不讨好的痛苦！如本手稿中环境因素导致丢包案例中的电源浪涌，时值北方的冬季，加之故障这个魔鬼出现的时间是晚上7:00-9:00这个时段，现场工程师在用户单元楼道可以用饥寒交迫来形容！ 在此感谢为本手册付出了无数心血的原GW技术资源部的XDJM，正是他们的加班熬夜，将经历过故障进行总结，才能有今天这份珍贵的手册。

本手册是在原《网络丢包现象分析处理指导书》基础上进行部分的改动，谨此献给所有原GW技术资源部的XDJM，献给那段美好的光阴！献给那段偶们一起共同奋斗的岁月！

网络丢包现象分类：网络设备软、硬件问题导致丢包

首先对出现过丢包的案例进行描述并给出解决办法，同时对丢包问题进行分类，主要加强大家对丢包现象的感性认识。在后续的章节中再做深入的剖析，并提供问题的解决思路。

1、uHammer24百兆光口/电口模块问题

问题描述：uHammer24 芯片为C版且PCB为2.33版的设备百兆端口模块第25口，在高温及常温下会出现严重丢包，高温条件下尤为明显。

C版(PCB v2.33)uHammer24 port 25丢包示意图

 

问题解释：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（或者VDSL modem）由于晶振品质问题，导致与uHammer3100互连，距离较长时，出现严重丢包或同步不上。

问题解释：晶振品质不好，产生的脉冲信号在长距离传输时崎变较大，使得接收端无法识别。

问题解决：uHammer1008v(VDSL modem)更换品质较好的晶振。

备注：此类丢包也属于暂时性问题，更换硬件器件后将不再复现。

 

网络的拓扑如下

RiverStone3000（L3）作为网络的核心交换机，Flex16i汇聚了20几台接入层交换机u2，Flex16i只作为二层透传，所有用户的网关均指向Rs3000。网络稳定运行了3天后，Flex16i的下连用户出现5％丢包。Test pc ping 210.177.208.163或164均出现5％左右的丢包。Rs3000上ping server 出现5％的报文出现延时时间达到1秒。可以判断，客户端丢包是由于icmp报文超时的缘故。

问题解释：为了更准确地定位问题，做了如下测试环境。

 

用Test pc ping pc2同样出现5％的丢包率。Rs3000 ping test u2 5％报文的延时在1秒左右。在测试过程中，测试过Flex16i同一设备（510芯片）和不同设备（510芯片）下的二层用户互ping，同样出现5％丢包。显然可以排除光纤、u2等其他设备引起该问题。实际环境和测试环境中RS3000直接pingFLex16i的IP地址均没有出现报文延时时间长的现象。但ping Flex16i下连的u2则出现5％左右的报文延时长。因此，可以判断问题出现在Flex16i的二层转发上。

问题解决：将Flex16i reboot，故障依然；将Flex16i关电重启，故障消失，网络恢复正常！热启动和冷启动对于Flex16i来说，其硬件的初始化过程不一样，冷启动对硬件的初始化处理比较彻底，是否硬件还存在深层的Bug，需要研发人员做进一步的定位。

备注：虽然该故障定位在Flex16i上，但是是什么原因引起Flex16i的二层转发异常，并未能给出一个圆满的答案，不能不说是个遗憾。不过，这里要强调的是故障的定位处理，事实上这样的工作已经有利于研发对产品的改进工作了。

问题描述：uHammer24 软件版本为v1.323以下的版本的部分设备存在着14、18、22端口严重丢包，下连用户上网速度慢。在v1.323版本出现个别端口丢包的现象已很少见（到目前为止市场上反馈过2例v1.323 port 14有丢包现象），升级为v1.4版本可以彻底解决。

问题解释：某些u24的phy芯片对时钟很敏感，如果交换机主板硬件出现频差，则phy芯片工作就不正常。目前v1.323版本中通过定期写寄存器去修正频差产生的影响。但是V1.323中轮循的时间过长，phy芯片的寄存器没有及时得到更新，所以会产生很明显的link down现象。在v1.4版本中，缩短了轮询时间，到目前为止未发现个别端口丢包现象。

问题解决：升级到v1.4版本可彻底解决此问题。

备注：对于新上设备，要求最低可用版本V1.323。

问题描述：Flex5010 v1.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引起，因此准确定位问题比较困难。往往通过捕获链路上的数据流定位出现问题的设备，再深入分析设备的硬件、软件路由信息，任务、进程等等，最终才能确定问题所在。