以太网故障查询、定位方法小结.doc

以太网数据板的相关查询和定位（SS61ET1） 我们希望各位能熟悉下面的相关内容，但本资料的文档结构顺序并不代表处理实际问题所应遵循的排查流程，因为故障类型多样，需要排查点多不相同，所以，希望通过本资料能给大家一个比较清晰的思路，同时在处理实际问题的时候结合相关的各种命令和手段来综合的处理，有关的故障处理流程请参考相关资料。 本资料虽然大多数命令是针对SS61ET1单板的，不过目前在用的大多数以太单板、业务相关故障都可参考本资料的大部分故障排查、处理思路。原理都是相通的。 同时，也希望大家在了解本资料的同时能充分思考，结合各自工作中的实际情况不断的提出需求和指正，使本资料不断完善、充实、内容准确，从而能更好的帮助、指导我们的工作，更好的提高用户的满意度。 一．故障定位 发生事故时该查询哪些数据，一直是困扰以太网板维护的一个问题，这里总结了一些常用的定位方法和查询命令，及其含义的注解，希望对以后的维护工作有所帮助。 与SDH故障定位思路一样，以太网故障定位也遵循“先外部、再内部；先软件、再硬件；先单板、再系统”的原则，充分利用性能事件、环回、测试帧等技术手段，结合工具软件、测试仪表进行有计划有步骤的定位。 首先需要对于事故做一下初步的定位，首先排除SDH层面的问题，通过查询相关的告警和性能，确认SDH层面没问题后，转入以太网层面的定位。 对于以太网业务的故障定位，还是首先检查有无和ET1板相关的告警，主要集中在一些低阶的告警。比如BIP-EXEC，TU-LOP，LP-SLM等等。注意查询时候最好使用单板侧的告警查询命令： :ptp:bid,16,0 如果存在低阶业务告警，可以对SDH层面进行一些相应的检查，否则就需要定位一下是否是对接的路由器或者以太网交换机的故障造成。这种定位比较困难，手段也不多。 环回当然是我们的法宝了，有关环回的一些常用命令请参见第4节相关内容。找局方数据维护人员配合也是很重要的，一般多用PING+环回手段来定位故障点。比如通过ET1网口PING对端路由器或者交换机的IP地址，能够PING通基本证明我们这边正常，建议采用如下的格式PING包： ping xxx.xxx.xxx.xxx –l 1000 –t –l 1000代表是1000字节的包长，-t代表是持续ping包。可以变换多种包长，同时多开几个ping窗口试试。当然ping包正常也不能完全排除metro设备的问题，因为在端口工作模式不正确的时候，小流量的ping也是可以ping通的。它更多意义上是证明我们以太网链路的配置没问题，SDH层面也是没有问题的。我们的首先需要检查、确认SDH层的配置和通道没有问题，才能集中精力来排查以太网数据层面的问题。 让我们先来看看常见的相关故障类型吧。 一般来说以太网板（这里专指SS61ET1）的故障都分成两种类型： 链路完全中断。 链路上持续存在丢包。 从目前来看可能造成故障的原因如下： 以太链路完全中断 链路上持续存在丢包 1 端口TAG属性(TAG/UNTAG)设置被改变 业务量大，配置带宽不够 2 物理层出现故障，表现为实际端口工作模式不正确，或者端口某些参数异常，或接口板故障，物理层寄存器被随意改写等。 带宽足够，但是业务突发比较大 3 网线或者光纤出现故障 业务量过大的时候，对端设备不响应流控 4 以太网静态路由数据丢失 单板设置的最大传输包长MTU小于实际设备的传输包长 5 在某些情况下，出现网元指针调整的情况下，ET1的一些通道上报BIP-OVER和TU-LOP，业务中断。更换单板或者复位只能引起故障通道的转移，但是不能完全解决问题。 端口模式和对端设备不匹配，造成工作在异常状态 6 单板硬件故障 网线或者光纤出现故障 7 因为大量丢包造成的业务中断。这种情况转第二种故障类型处理 当双向的以太网业务包长持续相差太大的时，或者全部是短字节包长（64—128字节）时，可能会造成ET1性能下降较多，造成大量丢包。 8 目前我们的生成树是基于user的，所以在两个站有一个以上mp连接时，如果只用vlan隔离会出现bpdu报文的广播风暴 单板硬件故障 9 我们的设备只有一个mac地址学习表，所有的user和vlan共用这一个表象。由于三层设备转发报文会用自己的mac地址，所以对于只有一个mac地址的三层设备和我们连接时一定不要和一个以上的端口连接（无论用user还是vlan隔离都无法规避，因为我们设备只有一个mac学习表） 10 收发过量BPDU报文时的复位 11 因为耦合入干扰的原因，在正常运行过程中出现上报ETH-LOS，业务中断。可能自行恢复，也可能一直不恢复，另ETH-LOS也可能以5秒钟为周期瞬报（误报）。 注：其中的蓝色字体仅仅针对ET1V2(二层交换版本有效)，红色字