问题描述

详细组网见附件，六台UA5000及一台MA5616组成环网，上行到两台A厂家交换机，启用STP生成树协议避免环路。两台UA5000使用COPA单板新开启E1数据专线业务。
在Remote site(CEB-708站点)的UA5000挂2M误码仪做24小时链路监测，每次测试均会出现误码。使用transparent on 0/X命令进入COPA模式后使用dsp show pll 0x0命令查看COPA单板的时钟状态，发现有时钟传送时延严重超时：History Max Pdv : 1485933.744(us)，并偶有时钟失锁状态，见附件相关LOG。
发生COPA时钟失锁问题的UA5000 站点IPMD版本为V100R017C02B111+SPH305，COPA单板版本为915。同一环上其他三台UA5000版本为V100R017C02B032。

告警信息

测试有E1误码故障的UA5000(CEB708)无任何告警。
同一环上其它站点的UA5000（777，778，774站点）上有STP状态变化告警。
ALARM 651256 EVENT MAJOR 0x29000002 COMMUNICATION 2012-04-02 21:14
  ALARM NAME  : Port STP status change to forwarding
  PARAMETERS  : frame: 0, slot: 2, port: 0
  DESCRIPTION : Port STP status change to forwarding
  CAUSE       : Port has been set to forwarding state
  ADVICE      : No need to proceed
  --- END

  ALARM 651255 EVENT MAJOR 0x29000002 COMMUNICATION 2012-04-02 21:14
  ALARM NAME  : Port STP status change to forwarding
  PARAMETERS  : frame: 0, slot: 2, port: 1
  DESCRIPTION : Port STP status change to forwarding
  CAUSE       : Port has been set to forwarding state
  ADVICE      : No need to proceed
  详细告警见附件。
 

处理过程

1、查看版本，已升级至最新版本，确认软件版本无问题。
2、更换COPA单板，问题依旧，排除硬件问题。
3、更换了新的E1链路，问题重现。
4、确认业务流已设置QoS值为7，沿途交换机已配置绝对优先高度。分析IP网络，发现从Remote site到host site的MA5616上有TC报文计数增长，怀疑网络中有STP振荡。
5、查看环上其它UA5000，有STP端口状态变化告警，其中部分在STP端口状态变化恢复时长为30s，STP振荡会导致UA5000清除学习的MAC地址表，在网络收敛前可能引发丢包。
6、排查STP振荡原因，发现发生STP告警时，没有其它相应的物理端口或链路状态变化告警，查看设备端口，没有相关Error计数，光口光功率也在正常范围，排除物理传送丢包可能。
7、开启debug抓取BPDU信息，发现当774，777，778站点的UA5000发生STP状态告警同时，邻居的UA5000正常发送了BPDU报文，但发生问题的UA5000的debug却没有收到，并在等待超时后开始发送以自身为根桥的BPUD。可以确认邻居发送的BPDU没有得到CPU的及时处理，进一步分析为CPU不处理原因，为UA5000版本V100R017C02B032的CPU处理机制问题，升级至最新维护版本后，问题解决。

根因

E1误码告警，并有时钟失锁现象，可能原因如下：
1、COPA单板本身硬件及软件问题。
2、时钟源的E1链路时钟质量偏低。
3、从remote site到host site的IP网络质量问题。 

解决方案

建议与总结

所有有IP网络中时延敏感的业务，均有可能会对网络丢包敏感，IP网络丢包原因复杂，特别在启用了类似STP，RRPP或者动态路由协议的网络里，振荡的原因可能是因其它网元端口变化或者光纤单通问题引起，而并非本设备原因导致，分析需要基于全网，不可只局限于一个网元。

很好的案例

感谢分享，赞一个！

受益匪浅，支持一下，赞！！！

感谢分享

赞一个！

支持一下

谢谢分享

很好！点赞！向你学习

学习啦，哈哈，赞！