网络丢包现象分析处理指导书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丢包示意图
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报文超时的缘故。
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
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
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引起，因此准确定位问题比较困难。往往通过捕获链路上的数据流定位出现问题的设备，再深入分析设备的硬件、软件路由信息，任务、进程等等，最终才能确定问题所在。
 |
 |
 |
0人
|
了这篇文章 |
类别： 网络┆阅读(
0)┆评论(
0) ┆ 返回博主首页┆ 返回博客首页
上一篇 ASP防止盗链或防止下载的方法 下一篇 网络丢包现象分析处理指导书2(出处：www.ipdat..
文章评论
<<
1 2 >> 页数 ( 1/2 )
[2楼]
[匿名]ipdata 回复
[匿名]ipdata 回复
2007-03-01 16:22:48
你摘录的《网络丢包现象分析处理指导书》系列文章涉及到没有经过我公司授权，请务必进入和我公司取得联系，我们的联系方式 -028-66312556！
[3楼]
[匿名]ipdata 回复
[匿名]ipdata 回复
2007-03-01 16:55:55
[4楼]
[匿名]ipdata 回复
[匿名]ipdata 回复
2007-03-02 13:01:20
请博客主人尽快与我们取得联系，我方将保留一切必要的手段以期双方能够协商解决未经授权擅自发布我公司网站上的文章问题。
回避不是解决问题的关键，希望能够抱着积极心态面对已经出现的问题！
回避不是解决问题的关键，希望能够抱着积极心态面对已经出现的问题！
[5楼]楼主
xiong2127 回复
xiong2127 回复
2007-03-02 13:19:29
呵呵，昨天已经发消息给你拉，奇怪，这个有什么好逃避的，转你的文章本来给你们起到宣传作用，如果觉得不合适，我立即删掉
[6楼]
peadog 回复
peadog 回复
2007-03-06 13:26:01
技术是用来让大家学习的，我个人认为没有必要人为搞什么技术交流的壁垒。当然，重视版权也是应该的。希望博主能和贵公司就此事打成谅解。
<<
1 2 >> 页数 ( 1/2 )
发表评论
- 昵 称：
- 登录 快速注册
- 验证码：
-
点击图片可刷新验证码请点击后输入验证码博客过2级，无需填写验证码
- 内 容：
同时赞一个
每日博报 精彩不止一点
Copyright By 51CTO.COM 版权所有
联系方式：028-66312556