网络丢包现象分析处理指导书6(出处：www.ipdata.cn)
缩小故障范围及确定故障点
缩小故障范围及定位故障点，通常是测试从信源到信宿的每一段的健康情况从而有利于问题的集中处理，即所谓的逐段分析法。可以说ping和traceroute工具为我们提供了极大的便利。为了简化问题，我们先考察一个全路由式网络如何缩小故障范围。
如下拓扑图：
假设从A点ping H点出现丢包，那么我想我们每个人都会从A点去检测B、C、D、E、F、G是否有丢包现象。假定ping B、C未出现丢包，ping D有丢包现象。那么大家都会将目光盯在链路L2和R3的D接口上。对L2、D点的检测，往往可以通过查看R2的C接口和R3的D接口状态来判断。比如：
R2# sh int e0/0
Interface eth0/0 is up, Line protocol is up
Internet address is 210.12.114.42/29 Broadcast 210.12.114.47
mtu 1500 <UP,BROADCAST,MULTICAST>
Physical layer is Ethernet, hardware address is 00:50:77:88:CC:DF
Auto-Negotiation is enabled, Half-duplex, 10Mb/s
Queueing strategy: 3-BAND fast fifo (default)
Output queue (size/max/drops) : 0/100/0
5 minutes input rate 303.02 bytes/sec, 0.37 packets/sec
5 minutes output rate 42.04 bytes/sec, 0.31 packets/sec
249785 packets input, 366307962 bytes, 0 no buffers
168866 packets output, 10403563 bytes, 0 no buffers
0 input errors, 0 CRC, 0 frame errors
0 overrunners, 0 aborted sequences, 0 input no buffers
0 packets throwed(tx)
首先要注意端口的工作状态：“Auto-Negotiation is enabled, Half-duplex, 10Mb/s”，确认R2和R3互连接口状态是否一致。
假设从A点ping H点出现丢包，那么我想我们每个人都会从A点去检测B、C、D、E、F、G是否有丢包现象。假定ping B、C未出现丢包，ping D有丢包现象。那么大家都会将目光盯在链路L2和R3的D接口上。对L2、D点的检测，往往可以通过查看R2的C接口和R3的D接口状态来判断。比如：
R2# sh int e0/0
Interface eth0/0 is up, Line protocol is up
Internet address is 210.12.114.42/29 Broadcast 210.12.114.47
mtu 1500 <UP,BROADCAST,MULTICAST>
Physical layer is Ethernet, hardware address is 00:50:77:88:CC:DF
Auto-Negotiation is enabled, Half-duplex, 10Mb/s
Queueing strategy: 3-BAND fast fifo (default)
Output queue (size/max/drops) : 0/100/0
5 minutes input rate 303.02 bytes/sec, 0.37 packets/sec
5 minutes output rate 42.04 bytes/sec, 0.31 packets/sec
249785 packets input, 366307962 bytes, 0 no buffers
168866 packets output, 10403563 bytes, 0 no buffers
0 input errors, 0 CRC, 0 frame errors
0 overrunners, 0 aborted sequences, 0 input no buffers
0 packets throwed(tx)
首先要注意端口的工作状态：“Auto-Negotiation is enabled, Half-duplex, 10Mb/s”，确认R2和R3互连接口状态是否一致。
另外查看接口错误帧、缓冲区统计情况：“0 input errors, 0 CRC, 0 frame errors
0 overrunners, 0 aborted sequences, 0 input no buffers
0 packets throwed(tx) ”，路由器的接口有物理故障、DSU/CSU、modem或线路传输质量差，在这里都能体现出来。
0 overrunners, 0 aborted sequences, 0 input no buffers
0 packets throwed(tx) ”，路由器的接口有物理故障、DSU/CSU、modem或线路传输质量差，在这里都能体现出来。
如果有input errors的话，只能到R2端去进一步查看了。DSU/CSU、modem灯状态，连线接头都需要我们留心观察。当然最终确认某个部件是否有问题，还需要更换该部件来做判断。如果链路出现故障，那么不同的链路要求的判断方法就有很大不同了。Ethernet、DDN、FR、E1、POS、ADSL等，简单的判断是更换链路协助判断。为了准确定位问题，还需要我们掌握各种链路的理论知识。建议大家认真学习部门FTP上BBS目录的《常用网络协议原理》，里面链路协议的介绍很不错。
举个判断DDN链路传输质量的例子，在cisco路由器上debug serial interface便能查看路由器之间链路的同步状态，如果myseq（本端序列号）与mineseen（对端看到的我的序列号）不一致，则说明DDN链路失步。
全路由式网络丢包的故障点，其实是最好判断的，因为每台路由器实际上提供了一个有力的检测工具，通过逐跳检测路由器接口很容易将丢包故障缩小在某一段链路上。对于全交换式的网络或路由交换式网络又如何去定位故障点呢？
看如下全交换式网络拓扑图：
假如pc ping 骨干网出现丢包，那么我们不再可能像全路由式网络那样去检测A、B、C、D、E点的连通状况了。一般情况下，pc的网关在E点，中间的L2交换机不具有路由接口。Ping L2的管理IP能否作出判断呢？可以肯定的说，对于一个运营的网络，十有八九十不行的。考虑到网络设备的安全性，设备的管理IP与用户的IP不会处于一个网段。当你去ping L2交换机的IP时，通常报文会透传到L3设备在转发回来给L2信宿，因此，无助于故障范围的缩小。象上图拓扑，如果pc ping E点仍出现丢包，那么问题可能出现在A、B、C、D点上。由于L2没有路由接口作为检测点，此时我们不得不变换一下思维方式。
为了检测报文是否被L2_1所丢弃，在允许的条件下，我们人为地在B处设置一个检测点B’。如下图：
Test pc与用户pc在一个网段，pc去ping Test pc，如果出现丢包，那么问题就可能出现在L2_1或者pc连L2_1的链路上；如果未出现丢包，那么我们需要将检测点后移如下：
如果ping test pc出现丢包，那么我们需要怀疑是BC链路或L2_2的问题了；如果不出现丢包，还需要将检测点进一步后移。假设是出现丢包，那么到底是BC链路还是L2_2二层转发有问题呢？为了确定L2_2的二层转发情况，此时你不妨用Test pc去ping L3的E点，如果出现丢包，那么说明L2_2的二层转发有问题，如果不丢包，可能需要将确认BC链路的传输质量了。
上面所讲的都是宽松测试环境下的一般分析方法，在实际的环境中或许做不到，这是我们就不得不考虑变通的手法了。
假设Test pc不允许你配用户网段的IP（用户的IP地址采用30位掩码时，用户和网关各占用一个IP，没有剩余IP可用），有该如何检测网络的丢包点呢？
见如下示意图：
B’、C’、D’点分别为B、C、D的镜像端口，我们可以让pc ping E点100个包，我们在B’点用协议分析仪sniffer定义捕获pc所发送的报文。注意pc上显示丢失了几个报文（比如n个），假如sniffer能捕获到100个pc发给L3 E接口的icmp echo request报文和L3回应给pc的（100－n）个icmp echo reply报文，则说明L2_1交换机工作良好，需要将检测点移到C’。如果L2_1只转发出（100－n）个pc所发的icmp echo request报文，那么说明故障出现在L2_1上了。当然，捕获报文的的数目可能存在小的偏差，这可能是sniffer所在网卡的过滤能力有限等因素造成，可以忽略。检测点后移的分析情况类似，不再罗嗦了。
看如下全交换式网络拓扑图：
假如pc ping 骨干网出现丢包，那么我们不再可能像全路由式网络那样去检测A、B、C、D、E点的连通状况了。一般情况下，pc的网关在E点，中间的L2交换机不具有路由接口。Ping L2的管理IP能否作出判断呢？可以肯定的说，对于一个运营的网络，十有八九十不行的。考虑到网络设备的安全性，设备的管理IP与用户的IP不会处于一个网段。当你去ping L2交换机的IP时，通常报文会透传到L3设备在转发回来给L2信宿，因此，无助于故障范围的缩小。象上图拓扑，如果pc ping E点仍出现丢包，那么问题可能出现在A、B、C、D点上。由于L2没有路由接口作为检测点，此时我们不得不变换一下思维方式。
为了检测报文是否被L2_1所丢弃，在允许的条件下，我们人为地在B处设置一个检测点B’。如下图：
Test pc与用户pc在一个网段，pc去ping Test pc，如果出现丢包，那么问题就可能出现在L2_1或者pc连L2_1的链路上；如果未出现丢包，那么我们需要将检测点后移如下：
如果ping test pc出现丢包，那么我们需要怀疑是BC链路或L2_2的问题了；如果不出现丢包，还需要将检测点进一步后移。假设是出现丢包，那么到底是BC链路还是L2_2二层转发有问题呢？为了确定L2_2的二层转发情况，此时你不妨用Test pc去ping L3的E点，如果出现丢包，那么说明L2_2的二层转发有问题，如果不丢包，可能需要将确认BC链路的传输质量了。
上面所讲的都是宽松测试环境下的一般分析方法，在实际的环境中或许做不到，这是我们就不得不考虑变通的手法了。
假设Test pc不允许你配用户网段的IP（用户的IP地址采用30位掩码时，用户和网关各占用一个IP，没有剩余IP可用），有该如何检测网络的丢包点呢？
见如下示意图：
B’、C’、D’点分别为B、C、D的镜像端口，我们可以让pc ping E点100个包，我们在B’点用协议分析仪sniffer定义捕获pc所发送的报文。注意pc上显示丢失了几个报文（比如n个），假如sniffer能捕获到100个pc发给L3 E接口的icmp echo request报文和L3回应给pc的（100－n）个icmp echo reply报文，则说明L2_1交换机工作良好，需要将检测点移到C’。如果L2_1只转发出（100－n）个pc所发的icmp echo request报文，那么说明故障出现在L2_1上了。当然，捕获报文的的数目可能存在小的偏差，这可能是sniffer所在网卡的过滤能力有限等因素造成，可以忽略。检测点后移的分析情况类似，不再罗嗦了。
这上面的分析可以看出，全交换式的丢包问题故障点的定位，不外乎是在信源和新宿之间人为插入检测点，使之类似于全router网络，便于运用分段分析法。对于路由交换混合网络，则需要在交换部分加入检测点即可。
需要提醒的是，网络丢包有时候不只是一个故障点，所以我们在排除完一个故障点后，需要确认问题是否存在。有多处丢包的故障，分析起来可能麻烦些，但是，只要我们头脑里有此意识，单故障点的分析手法同样适用。
分析故障原因
在我们缩小了丢包的故障范围、确定了丢包的故障点后，下一步的工作就是分析故障成因了。从上一章节可以看到故障成因的多样性，因此分析故障要求我们具备三方面的素质：
1、扎实掌握网络的基本理论，特别是TCP/IP协议、路由协议、交换理论，并能够自如运用理论知识分析解决问题；
2、熟悉产品特性，要求我们尽可能多的了解掌握设备供应商提供得网络产品特性、性能指标等，在复杂的网络环境中，存在着多个厂家的设备，不同厂家的产品特性也不尽相同，只有充分掌握网络中的每个产品特性，才能深入地剖析故障；
3、注意多积累经验，包括别人的经验，此所谓他山之石，可以攻玉。下面我们分别举例说明。
从XX油田的案例看，当从Big400与NetScreen互连的链路捕获到不断循环的报文后，我们完全有理由去怀疑两设备之间的路由配合问题。通过仔细地分析了Big400和NetScreen100的路由表后，不难发现交换机和防火墙确实按路由表如实转发报文。那么我们可以根据路由最长匹配原理，将问题给予消除。这就要求我们熟悉理论知识。IP寻址原理、ping应用程序的理解、IP报文路由过程、交换机的二三层转发原理是我们分析丢包问题的最基本、最重要的知识，相关内容在三季度培训中已给大家做过详细的讲解，想必大家已熟练掌握。事实上，我们可以看到附录上的案例，都是从基本原理出发，通过逐步分析问题，最终定位、解决问题的。
熟悉产品特性，有助于你快速切入问题。二层交换机产品FDB表的特殊性（u设备双链路连接到同一台L3设备上采用同一MAC地址的两个接口）而引起的网络丢包问题，在全国多次发生过。这也给我们重要教训，一定要深入掌握产品特性，要求我们平时注意对比某个产品线与其他产品线某个特性的区别、与其他厂家产品特性的区别。
聪明的人善于借鉴已往的经验。在上一章节，我们罗列了大量的丢包案例，这些案例就是我们的经验总结的一部分，希望大家能够理解消化，并在碰到类似问题时，做到心中有数，少走弯路。同时也希望大家能够提供自己处理过的案例与他人分享。
扎实掌握网络理论知识、熟悉产品特性和注意积累经验，是快速、准确定位故障的基本要求，也是我们技术方面努力的目标。
解决问题
在定位出故障的原因后，是否下一步理所当然是排除故障呢？不一定。与其说是排除故障，倒不如说是解决问题。很简单，或许故障是由其他厂家的产品引起的，而且我们又无能力去排除它，此时不必强求自己。我们只需要将一份有理有据的故障分析报告提交给客户，耐心跟客户解释，并得到客户认可就可以了。如果故障确实是由于我方产品缺陷、网络设计、设备配置不合理引起的，需要我们谨慎处理。在对业务没有造成较大影响的情况下，有时客户更看中我们解决问题的态度和行动。如果是产品缺陷引起，要求我们及时反馈问题，配合研发人员准确了解网络环境，有利于问题的快速解决。如果是网络设计、设备配置等原因引起的，那么积极与客户交流、博得客户的理解和支持是最重要的。
总之，网络故障的解决，除了根据定位出的故障原因从技术角度去解决问题外，还需要我们耐心与客户做好沟通工作。特别是碰到“非我方原因”引起的网络问题时，最好主动向客户提交分析报告，并要求客户在纸质报告上签名确认，作为备忘录。
 |
 |
 |
0人
|
了这篇文章 |
类别： 网络┆阅读(
0)┆评论(
0) ┆ 返回博主首页┆ 返回博客首页
上一篇 网络丢包现象分析处理指导书5(出处：www.ipdat.. 下一篇 网络丢包现象分析处理指导书7(出处：www.ipdat..
文章评论
发表评论
- 昵 称：
- 登录 快速注册
- 验证码：
-
点击图片可刷新验证码请点击后输入验证码博客过2级，无需填写验证码
- 内 容：
同时赞一个
每日博报 精彩不止一点
Copyright By 51CTO.COM 版权所有
