链路状态正常，但是大量丢包故障初步分析、试验

用户报告故障。技术支持16点到达现场。现场是两台S9609做堆叠，跨设备链路聚合。聚合链路有丢包。有的终端ping完全不同。17点定位出来是S9609上一个光模块有问题，更换光模块后通信就正常了。和堆叠和链路聚合的关系在于。链路聚合是根据报文的SMAC地址来进行hash计算，决定走那条成员链路。被hash到问题成员链路上的报文就会丢失。有的终端ping完全不通。说明它的报文被hash到问题成员链路上了。但是需要明确，跨设备链路聚合与故障原因没有关系，它只是受影响者。

故障定位出来了，故障也已经解除了。但是用户不太相信就是单纯的光模块问题。按道理，我们可以尝试从以下两个方面做进一步处理。

1. 对比试验。把这个光模块放到其它能正常工作的链路中，也会出现这个问题。来佐证确实是光模块有问题。比如两台设备直接相连，其中一台使用了问题光模块，这样互相ping，就发现大量丢包，甚至彻底。但是用户目前不愿意将光模块交给我们。没有条件做试验。后续取出光模块后做试验。
2. 技术分析：查看光模块的内部工作状态，说明内部出了什么问题，导致光模块收到的光信号强度正常，为-13dbm，但是收包不正常。但是这个需要专业的检测。就算取出光模块，时间也来不及。只能后期去做。

更远期的防御性的，需要确认这个品牌、这个型号和批次的光模块，质量情况如何。

用户要求我司在模拟环境中重现类似的现象。并且第二天早晨10点之前提交报告给他们。

真正有效的两个技术方法，都没有办法执行。导致这个问题短期来看不再是一个技术问题，而主要是一个沟通问题。就是如何让用户相信，是单纯的光模块的问题。更换光模块之后，我们的设备能够稳定运行。并且让用户允许我们带走问题光模块，让我司进行做进一步的试验和检测。

技术支持暂时没有条件搭建环境，领导安排我们产品测试部搭建类似环境重现类似现象。虽然我很清楚实际上现在要求做的是在另外一套环境中来重现这个问题。逻辑上来说。这其实和原本要解释的故障现象已经没有什么关系了。但是因为目前技术支持已经答应客户公司里会做这个试验。领导也已经安排。就只能去做了。即使只是增加了技术支持和用户沟通的素材。但却是对用户承诺的履行。就有效性的差异，我和领导和技术支持做了沟通。防止他们对验证的有效性产生误解。

最终重现的目标变成了弄出这样一种现象，接口link up，但是不收发包或者大量丢包。

用好的光模块来模拟不知道具体出了什么问题的光模块的行为，本身并不可行。我们只能想办法使光信号的质量变差、光强度变低。我需要再次强调，就算重现了故障现象，和现场的故障原因也是完全不同的。不过我还是需要坚决执行领导的安排。

我查看光模块的参数文档。发现LOS alert的光强度远小于receiver要求的最小光强度。所以逻辑上只要光强度大于LOS alert光强度，小于receiver要求的最小光强度，那么就可以出现link up但是不收包的情况。

这是一个非常规任务。所以我亲自制定了试验思路，然后安排人去执行。能够使用的手段有拔松光模块、拔松光纤、使用光衰减器、单模模块（现场是单模）错配多模光纤。光功率计作为检测手段备用。

需要说明的是：光衰减器只有5dbm和10dbm两种，无法灵活调整光衰减程度。另外，拔松光纤、光模块，这种操作精确度很低，可控性非常低，有可能拔松一点就link down，插紧一点就完全不丢包了。

所以无法明确预期可以很有把握重现类似的故障现象。就这一点我同领导和技术支持做了沟通。以免他们期望太高，导致不必要的失望。

17点30分任务到达产品测试部，18点完成沟通，开始寻找资源、搭建环境、执行任务。

最终21点发现在使用光衰减器的情况下，拔松光纤会出现类似现象。接口link up，但是数据流不管收还是发。都有大量丢包、有时甚至完全不转发。测试仪接收端收到的流量速率在不断波动。

我指导执行人做了相关的对比测试，写出报告。21点30分将报告发给技术支持。

第二天9点我通过微信语音通话召集技术支持、领导一起开了多人会议。将试验结果进行了沟通。