以太网故障定位

Metro产品培训以太网故障定位1课程目标以太网故障定位的思路以太网故障定位的常见方法常用工具软件、仪表的使用方法如何策划联合测试方案通过本次课程，学员应掌握以下内容：系统的方法论，必须建立在对传送网、数据通信、网络产品等知识全面、系统的了解之上2工程师的疑惑当我们接到用户投诉时，如何迅速完成以下工作判断是否真的发生了故障

判断故障的严重程度判定故障界面定位故障原因解决之道：知己（MSTP）知彼（数通）MSTP产品以太网故障定位的难点：3以太网理论基础

CSMA/CD

端口工作模式帧格式以太网各种错帧以太网流控

VLAN“知己”的第一项——以太网二者有何联系？三者有何联系？错帧对业务的影响？何时需要？如何实现？实际效果？功能、实现与引入的问题？4以太网特性单板基础基于不同平台的单板的共性与特征

封装协议、封装颗粒、接口类型、功能实现、版本特征、配置方法……

单板的性能指标

吞吐量、时延、背靠背和交换容量

单板可支撑故障定位的功能

环回、测试帧、流量统计、黑匣子、SDH类告警与性能、以太网类告警与性能（RMON）

单板固有缺陷

运行稳定性、软件BUG、批次问题……同SDH相比，以太网特性单板规格更多、配置和应用更复杂，只能多花精力来学习和记忆！当然，理解是记忆的基础。“知己”的第二项——以太网特性单板5数通理论基础数据通信的发展

了解数据通信技术的发展历史，加深对各项数通技术的理解，把握数据通信发展的趋势。高层协议

初步掌握TCP/IP协议族主要内容，了解交换、路由等方面基础理论知识。业务内容与实现

了解应用层业务内容与高层协议的关系，了解业务与底层技术的联系。

根本目的：建立一套系统的数据通信知识体系，并同已有的传输知识体系有机结合，站在业务的角度、网络的角度来思考问题、理解网络。“知彼”的第一项——数通理论知识6网络产品基础产品的功能与分类

了解数通产品的基本功能与分类，掌握与其对接的要点。常见主流网络产品

了解常见主流数通产品的主要功能与网络地位，学习其基本的配置方法。混合组网与测试

具备根据业务和对接数通设备需要设计MSTP网络的能力，具备根据对接数通设备特点筹划联合组网测试的能力。

熟悉了宽带产品，才能远离处理对接问题时的尴尬与无奈，才能底气十足的和C公司的NB工程师交涉，才能让用户用崇拜的眼光仰视自己……

“知彼”的第二项——数通宽带产品知识7工具使用

工具软件

SERV－U：FTP服务器端软件，可基于WIN98/2000/XP平台，利用FTP可在一定条件下近似反映出通道带宽。

SNIFFER：简明实用的抓包工具，可基于WIN98/2000/XP平台，处理疑难杂症时推荐使用，缺点是发包功能较弱。

SolarWinds：功能纷繁复杂，适合数通专业人员使用，附带的Ping工具功能强大，并可输出log文件，缺点是部分功能不够准确，会对用户产生误导。

测试仪表

SmartBits：主流以太网测试仪表（又名数据分析仪），主要功能：1、性能指标测试；2、构造并发送各种类型报文；3、收、发包统计；4、抓包并解码分析。

IXIA：常用功能和SmartBits基本相同。工欲善其事，必先利其器8以太网故障定位

原则：与SDH故障定位思路一样，以太网故障定位也遵循“先外部、再内部；先软件、再硬件；先单板、再系统”的原则，充分利用性能事件、环回、测试帧等技术手段，结合工具软件、测试仪表进行有计划有步骤的定位。

步骤弄清故障现象查询伴随的告警和性能

难点：判定故障界面恭喜恭喜：一旦判定了故障界面，则整个定位工作完成了70%如何找准问题的锲入点业务全阻业务部分丢包非故障MSTP故障数通产品故障对接故障SDH侧以太网侧9以太网性能分析处理SDH故障时，我们首先做的就是查告警查性能，同样，处理以太网故障时，我们第一步也是查清告警和性能。请注意，涵盖SDH侧和以太网侧。排除A类告警：Ethlos、AIS、LOP等必然导致业务中断的告警排除B类告警和性能：B3SD、LPBBE等导致业务丢包重点分析RMON：最直观的定位工具－－RMON错包碰撞与延迟流控硬件异常发送接收发送接收10以太网性能分析

A类错包事件（蓝色字体）AlignmentErrors：对齐错误---碰撞引起或硬件故障（对端居多）FCSErrors：CRC校验错---碰撞（全双工VS半双工）、网线质量差或受到干扰、对端硬件故障结论：查端口模式、查网线、查对端硬件

B类碰撞相关事件（紫色字体）结论：1、本端口实际工作在半双工模式，建议调整到全双工模式；

2、CSMA/CD算法所决定，非故障。

C类流控事件（绿色字体）结论：反映了通道的“拥挤”程度，建议根据需要扩容。

D类硬件异常（红色字体）DropEvents：由于FIFO溢出而导致的丢包结论：若数量较大，则先硬复位单板，如现象持续，则更换单板。RMON分析11以太网故障定位方法

判定故障原因是否在MSTP侧

探询故障的触发事件－－是否对网络做过操作、发生倒换等隔离法：两端直接使用PC互Ping

发测试帧：简单实用，但并非所有产品都支持

定位故障点

法宝一：环回－－老套路，再熟悉不过的东东了

法宝二：测试帧－－不支持咋办啦？不支持那就用法宝三呗。法宝三：RMON性能统计

套路：从近端开始逐段环回（以太网单板、交叉、线路），每环回一段，通过测试帧测试是否收、发一致，当收发不一致时，即找到故障所在点。如产品不支持测试帧功能，则只能利用PC发包，通过单板端口RMON的收、发包数量是否一致来判断。

“啊哈哈哈哈……这点小问题，轻松搞定！”

“STOP!别得意太早，想想还遗漏了什么？”故障类型---业务严重受损12以太网故障定位方法

测试帧的不足

测试帧是由虚通道侧发出和接收，未能覆盖到整个业务通路，因此有可能测试帧收发正常而实际业务不正常，怎么办？继续定位MAC和PHY芯片状态是否异常。

PS：虽然此时复位、拔插能迅速恢复业务，但为了定位故障根本原因（实验室一般都不能重现故障），就辛苦一下查查其他数据了。

收、发包数量一致就万事大吉了吗

NO！如果硬件出现故障，有可能会将包随机修改后发送出去，从而导致实际业务产生大量异常甚至中断。故障类型---业务严重受损（二）总结陈词：一般而言，业务出现明显受损的故障相对容易判定故障界面，同时其定位手段容易流程化、规则化，加上故障现象较单一，因此定位难度较低。提醒：1、正确的配置是应首先确保的。2、环回定位手段仅针对以太网透传版本。13以太网故障定位方法

判定故障原因是否在MSTP侧

由于此时业务损伤不明显，甚至不能称之为“故障”，因此通过隔离法往往难以迅速判定故障界面；或故障具有突发性和自愈性，不能及时抓到故障信息，需要长期监测定位。此类问题，一般有以下几种处理方法:

协调用户调走业务，使用仪表对问题通道进行长期（24～72小时）稳定性测试，验证通道的长期可靠性。

不调动业务，使用仪表或软件工具进行在线长期监测，记录并输出log文件和其他信息。替换法，直接更换相应单板，在线长期观察。难点：MSTP做为业务承载平台，目前缺乏相应的OAM手段来记录、反映业务状态，因此出现问题时经常要“替人受过”，这点在二层交换版本尤为严重。一方面通过不断改进MSTP产品为定位提供功能支撑，一方面需要工程师更多的了解对接数通产品，站在整个业务流程的角度来分析问题，寻找解决问题的方法。故障类型---业务损伤不明显14案例分析

某日，用户投诉不能上网，QQ、E－mail和WEB全部中断，Ping门户网站都不通，运营商M检查数通设备认为一切正常，于是向我司工程师小A申述传输故障。小A接到申诉后：

反映一：心想这下问题大了，啥都干不了，肯定ET1出了大问题。于是一边打800一边飞奔到现场，手忙脚乱查告警查性能，最后没招了还折腾着跟小B求援要他到对端接个PC来对Ping一把。反映二：心想ET1挺稳定的呀，不会这么容易撂担子，用户也动过设备，肯定是其他哪个疙瘩出茬子了。于是，仔细而冷静的分析了用户的故障现象，发现用户都是使用域名上网，难道是DNS不正常？那就Ping一下Internet的某个IP或者Telnet到某个BBS，果然，此时Ping和Telnet都正常，显然是DNS出了故障。总结：做为一个网络用户，平日多思考一下网络业务的实现原理和过程，了解其中关键环节，出现问题时应站在业务的高度来分析，要能看到传输以外的其他环节。准确判断故障15案例分析

网络割接，次日用户投诉不能上网，QQ、E－mail和WEB全部中断，但Ping各个门户网站都能通，运营商M检查数通设备一切正常，于是向我司工程师小A申述传输故障。小A接到申诉后：吸取了上次的经验，和用户确认的确能Ping通，于是认为故障在上游数通环节，与ET1无关，至于为何割接后出现问题那纯属偶然。运营商M也认为小A有理，又去折腾了半天数通产品还是没搞定，于是又投诉小A说的确是传输割接引起的故障，要求必须到现场处理。小A极不情愿但又有点心虚的到了现场：告警、性能都正常，看不出毛病

Ping的确是通的

PC直连在ET1都不能上网小A一筹莫展了，咋办呢？可恨用户刁蛮，问题显然跟传输无关嘛。问题真的跟传输无关吗？准确判断故障（二）16案例分析

小A无奈之下打数通800求援，学到一招：Ping大包。Mygod！果然200字节以上的大包都Ping不通，看来问题的确出在传输上。配置原因？硬件损坏？版本缺陷？思路：对于此类问题，首先应从单板的工作原理下手分析，找到导致问题发生的可能原因，然后逐项排除。

ET1将以太网帧首先拆分成N个64字节的分片，然后轮循放进虚通道绑定的VC12中传送，对端从相应的VC12中取出完成的分片后再恢复成一个完整的以太网帧发送出去。因此，绑定的任意一个VC12出现异常或两端虚通道绑定的VC12没有一一对应，都会导致业务出现有规律的损伤。如何定位：检测配置是否出现了两端VC12不对应的情况排除法，减少绑定的VC12（二分法）总结：1、检查业务Ping要带包长参数，建议包长1500字节

2、要理解单板原理，从原理出发来分析问题深入理解单板工作原理17案例分析

某日，用户投诉和公司总部的网络连接异常，网络速度缓慢。运营商已排除数通设备故障可能，要求小A处理。端口性能事件中反映收到了较多的超长包，初步怀疑是这些超长包被丢弃而导致的业务异常，但这些超长包从何而来呢？

咨询运营商数通人员得知：此用户新近开通了VPN业务。

VPN业务需要在用户数据帧的基础上打上MPLS或IPTunnel标签，因此会将数据帧加长N个字节，如果用户数据帧较长，则打上VPN标签后会超过1522字节，而ET1将此类超长帧丢弃。修改ET1的MTU值即可解决问题。提醒：目前VPN技术正在逐步向基于MPLS的二层VPN过渡，由于此类VPN的MPLS标签在以太网帧头之前，老一代以太网单板（ET1/EGT等）不能识别此类封装格式会将所有帧丢弃。配合用户开VPN业务时，一定要了解清楚其VPN的实现方式，并决定是否需要使用EMS/EFS系列单板。了解用户业务的特征18案例分析某运营商通过C公司交换机和我司GE02单板开通千兆以太网业务（绑定4个VC4），用户进行视频点播，使用UDP协议时画面频繁出现停滞，使用TCP协议时偶尔出现跳帧。

思路：

我司产品对以太网帧进行透传，并不识别3层及以上内容，为何TCP和UDP出现如此大差别？看起来问题似乎与MSTP产品无关，但为何用户通过光纤直连开通相同业务无类似问题？因此问题还是出在网络引入了MSTP产品，难道是对接问题？如果是对接问题，那应是不区分高层协议而通通出现相同问题，因此问题跟高层协议的具体应用有关，那么首先应弄清楚视频点播业务在分别使用TCP和UDP时数据流的差别，这是问题的突破点。问题：使用何种手段来分析TCP和UDP的数据流差别？Answer：使用Sniffer等软件工具在客户端PC抓包并解码分析，找到使用不同高层协议时数据流的差别。学会使用软件工具19案例分析

通过抓包并解码分析，TCP协议时IP包长都在1510左右，UDP协议时IP包长都在8000多，即需要分拆到大约6个以太网帧中。同时，Sniffer显示UDP时只能收到前面连续4个分片，而后面的分片丢失，这就说明的确是GE02把连续分片的一部分丢失，导致画面停滞。思路：

此时实际流量并不大，并未超过绑定的4个VC4，但GE02会规律性的丢弃帧，为什么？用ET1开通类似业务，却无上述问题，WHY？为何使用TCP和UDP时有IP的包长有上述差别，这其中是否还隐含了其他我们不知晓的问题？请思考：以上两个方面是否存在什么联系？Answer：TCP的确认-重传机制和UDP的面向非连接的突发特性，因而产生了使用不同协议时数据流的差别，而这种差别刚好又同GE02的某种缺陷相吻合，导致了问题的产生。熟悉TCP/IP基础知识20案例分析分析：从UDP的突发性和连续分片只能通过4片来分析，怀疑是GE02对业务突发的容忍能力有限而导致连续突发分片只能通过4片，后续分片则由于FIFO溢出而丢弃。请思考：以太网单板性能指标中哪些项能反映单板对突发的处理能力？

BACKTOBACK：使用仪表对GE02进行B2B专项测试，发现其指标非常差，说明的确是GE02无法承受数据流的突发而造成了丢包。

如何解决：由于性能指标是固化于产品的，无法单纯的通过软件设置来优化，因此只能通过将绑定的带宽从4个VC4增加到8个VC4，使GE02能够线速转发千兆以太网，问题解决。在对接交换机的GE口做流量整形（shaping），让数据流尽量变的平滑，减轻GE02的压力。总结陈词：理解高层协议的基本原理，熟练的使用软件工具来抓住问题的蛛丝马迹并推理出问题的可能原因，同时要理解常用性能指标的意义，有的放矢定位并解决问题。理解性能指标的意义21案例分析

某次业务扩容后，ET1S同时有两个端口连接到了同一L3，此时业务严重异常，断开其中任何一条网线，则另一端口业务恢复正常。分析：

怀疑是ET1S和L3直接形成了环路导致广播风暴而影响到业务，但再三检测配置，可确认两端都进行了隔离不会形成环路。

单端口连接时业务一起正常，可排除硬件故障可能性，同时单板也无复位等异常。基于二层交换的原理，怀疑是ET1S的CAM表异常。请问：如何证明ET1S的CAM表异常。查询CAM表中对应L3相应端口MAC地址的表项是否稳定。那如何知道L3端口的MAC地址？

L3直接连接PC，查询PC的ARP表。ARP表显示针对L3的不同端口竟然使用了相同的MAC地址，从而造成ET1S针对该MAC的表项不停的发生抖动，业务大量异常。解决：如L3多端口使用相同的MAC，则不允许和ET1S多个端口连接。理解二层交换原理22测试在故障定位中的应用

使用场合仪表测试重大故障且难以通过其他手段判定故障界面偶发故障且故障存在自愈性证明“非故障”对于第1、3种情况，主要是使用仪表进行性能指标的测试，包括和对接数通产品进行联合的性能测试（证明对接无问题）；对于第2种情况，主要针对MSTP进行单独的长期（24小时以上）可靠性测试。需要注意的是：对于第3种情况，重点在于引导用户对以太网特性单板的功能和性能指标的正确认识，纠正其关于“带宽”等概念及测试方法的错误理解。强调：“带宽”的单位是bps，其定义与“吞吐量”有本质不同。测试“吞吐量”必须使用仪表，任何软件都不具备此项功能。可以使用一些软件来近似测试通道的“带宽”，但存在局限性。一切测试结果以仪表为准。23工具软件的使用应用软件测试在没有仪表的情况下，为了证明“非故障”，在某些条件下可以使用软件对通道进行测试。

Ping使用ICMP的Echo功能，一般用来判断对端是否可达，同时可以反映出报文在网络中一个来回的延时（包括传输延时和终端处理延时），无论如何应用，Ping都不具有直接反映网络带宽的功能。

UDPEcho和ICMPEcho有些类似，也是发送一个报文给对方，对方收到后再回复一个确认报文，从而判断对方是否可达，不同在于分别为传输层和网络层协议，但前者更消耗主机资源，适合做网络攻击。注意：某些工具软件通过不停调整发送UDPEcho报文的速率，并根据是否能收到对应的确认报文来测试通道的带宽，这种二分法的算法是合理的（和仪表算法类似），但是其忽略了主机对UDPEcho的处理能力，即此种方法引入了主机处理能力对测试结果的影响且影响程度不可知，因此结果不可信。综上：不要相信所谓的带宽测试工具软件，其测试理论基础都不可靠，测试结果充其量具有一点参考价值。24工具软件的使用应用软件测试

FTP与相互COPYFTP是应用层效率较高的一种协议，在同等网络条件下，FTP的传送速率一般要高于其他应用，如HTTP，同时FTP应用软件往往有速率统计功能，能直观的反映出当前速率和平均速率，因此一般建议在没有数据分析仪的情况下可以利用FTP来近似测试通道带宽。

相互