网络丢包现象分析处理指导书

1、“网络丢包现象是常见的网络故障，但弓I起丢包的原因却多种多样、 千奇百怪。因此对于此类故障的解决，要求处理人员洞悉网络基础理 论、了解不同厂家产品特性，有耐心、深入地进行分析定位。”一一 一网络丢包现象分析处理指导书摘录从今天开始，本A(ipdata)将陆续发布系列网络丢包问题分析处理 的技术文章。该系列文章来源于网络丢包现象分析处理指导书， 主要分成三大部分：第一部分：讲解从产生网络丢包问题的原因来看，网络丢包问题大致 可以分为六大类因素，1、网络设备软、硬件问题；2、线路传输质 量差引起丢包；3、网络设备配置不合理导致丢包；4、网络设计不 合理导致丢包；5、人为攻击、广播泛滥造成的丢包；6

2、、网络环境 造成的丢包。对于每类丢包原因配置以大量的案例进行详细的说明。第二部分：主要有三方面的内容，一是深入剖析网络丢包现象并加以 总结；二是网络丢包的一般处理步骤;最后就是讲解网络故障处理中 相关工具使用的注意事项。第三部分：四个故障案例处理过程分析。应该说是对前面两部分内容 的一个综合应用。网络丢包问题往往是没有规律的故障，对于没有固定规律的故障，咱 们技术工程师往往有吃力不讨好的痛苦!如本手稿中环境因素导致丢 包案例中的电源浪涌，时值北方的冬季，加之故障这个魔鬼出现的时 间是晚上7:00-9:00这个时段，现场工程师在用户单元楼道可以用 饥寒交迫来形容！网络丢包现象分类：网络设备软、硬

3、件问题导致丢包首先对出现过丢包的案例进行描述并给出解决办法，同时对丢包问题 进行分类，主要加强大家对丢包现象的感性认识。在后续的章节中再 做深入的剖析，并提供问题的解决思路。1、uHammer24百兆光口/电口模块问题问题描述：uHammer24芯片为C版且PCB为2.33版的设备百 兆端口模块第25 口，在高温及常温下会出现严重丢包，高温条件下 尤为明显。C 版(PCB v2.33)uHammer24 port 25丢包示意图问题解释：uHammer24的硬件分B版和C版，C版uHammer24 的百兆端口模块25 口的接口电路（千兆端口不受影响）在高温条件 下（50C以上）不稳定，造成丢包

4、；B版在高温条件下（达到60C） 仍不会出现丢包。问题解决：正确识别B版和C版设备。C版设备尽量使用在不用百 兆端口模块的环境，如果一定要使用百兆模块的话，则建议更换B 版设备或采用PCB为2.44/2.55的设备。备注：此类丢包由于硬件芯片（产品序列号的第九到第十二位为 “A233”）离散性较大引起，产品的PCB已做修改，新生产的设备， 同样为C版，如果产品序列号的第九到第十二位为入244或“入255 则不存在此bug。重要提示：如果出现某个端口丢包，建议更换端口做测试，查看丢包 现象是否是个别端口问题。问题描述：部分uHammer1008v (或者VDSL modem)由于晶振品质问题，导

5、致与uHammer3100互连，距离较长时，出现严重 丢包或同步不上。问题解释：晶振品质不好，产生的脉冲信号在长距离传输时崎变较大， 使得接收端无法识别。问题解决：uHammer1008v(VDSL modem)更换品质较好的晶 振。备注：此类丢包也属于暂时性问题，更换硬件器件后将不再复现。网络的拓扑如下GvrJ ID. lT7.2tt&.124UMGvrJ ID. lT7.2tt&.124UMQirj2IDLl77.1Aa.1tflflTr*L L l-申匕I/ hs“ huinghrt P-22 ki44ihviCFTX JFriS蛙#侣小MM FlbufkrrtiFtrt 2*121Lm

6、.2VVrJJCrt 2*121Lm.2VVrJJC2核心交换机，Flex16i汇聚了RiverSto ne3000 ( L3)核心交换机，Flex16i汇聚了1S41272I. 177.29L L63?Z720几台接入层交换机u2, Flex16i只作为二层透传，所有用户的网关均指向Rs3000。网络稳定运行了3天后，Flex16i的下连用户出 现 5%丢包。Test pc ping 210.177.208.163或 164 均出现 5% 左右的丢包。Rs3000上ping server出现5%的报文出现延时时 间达到1秒。可以判断，客户端丢包是由于icmp报文超时的缘故。问题解释：为了更准

7、确地定位问题，做了如下测试环境。用 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,故障依然

8、；将Flex16i关电重启，故障消失，网络恢复正常！热启动和冷启动对于Flex16i来说，其硬 件的初始化过程不一样，冷启动对硬件的初始化处理比较彻底，是否 硬件还存在深层的Bug，需要研发人员做进一步的定位。备注：虽然该故障定位在Flex16i上，但是是什么原因引起Flex16i 的二层转发异常，并未能给出一个圆满的答案，不能不说是个遗憾。 不过，这里要强调的是故障的定位处理，事实上这样的工作已经有利 于研发对产品的改进工作了。问题描述：uHammer24软件版本为vl.323以下的版本的部分设 备存在着14、18、22端口严重丢包，下连用户上网速度慢。在 vl.323版本出现个别端口丢包的

9、现象已很少见（到目前为止市场上 反馈过2例v1.323port14有丢包现象），升级为v1.4版本可以 彻底解决。问题解释：某些u24的phy芯片对时钟很敏感，如果交换机主板硬 件出现频差，则phy芯片工作就不正常。目前v1.323版本中通过 定期写寄存器去修正频差产生的影响。但是V1.323中轮循的时间过 长，phy芯片的寄存器没有及时得到更新，所以会产生很明显的link down现象。在v1.4版本中，缩短了轮询时间，到目前为止未发现 个别端口丢包现象。问题解决：升级到v1.4版本可彻底解决此问题。备注：对于新上设备，要求最低可用版本V1.323。问题描述：Flex5010 v1.0网段表

10、设置算法缺乏考虑路由最长匹配 原则，当路由条目存在多个匹配信息时，容易出现数据包循环转发， 表现为用户上网速度慢、丢包甚至网络不通。拓扑结构见下图：（为 了说明问题，网络拓扑已做简偈上图为一大型行政机关的网络拓扑图，该单位网络为专网，与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 下一跳 1

11、0.95.1.25310.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.

12、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不再采用先 激活先置入网段表的算法，而是一开始则将所有路由条目置入网段表 中