中兴ZXMP S385设备SEC单板在处理大吞吐量业务时丢包故障

问题描述（故障现象）

中兴ZXMP S385设备SEC单板在处理大吞吐量（500M左右带宽）业务有丢包故障，在实际承载业务时吞吐量在430M左右时开始丢包，业务实际配置trunk8模式，每个系统口配置带宽为31个2M共62M的带宽，在用仪表测试时在不到100M的吞吐量时就开始丢包，经过检查SEC单板性能值发现只有其中一个系统口有收发包，其余系统口无收发字节。

原因分析

我们的系统口trunk8模式对每个系统口的带宽分配不是平均分配，而是根据hash算法来分配每个系统口的带宽，即使这个系统口的带宽占满也不会把这部分带宽分配到其他的系统口，因而造成了业务虽然没有达到满配带宽，但是依然有丢包现象的发生。

解决方案

在现场首先根据其中一个方向业务流向来依次检查用户口和系统口的性能值，并除以时间算出每个端口的平均速率，发现在带宽达到430M左右时个别做了trunk8配置的系统口带宽被占满，而一些系统口还有一定的富裕流量，在这个时候开始少量丢包。而在使用仪表测试时在500M带宽测试模式下丢包率达到惊人的80%，依然依据业务流向检查各端口性能值，发现在外接测试仪表时只有一个系统口有数据包收发，其他系统口都没有数据包的收发，经过验证确认SEC单板trunk模式算法采用HASH算法，Hash算法主要取决于报文内容，对于IP报文，取决于源IP和目的IP地址，对于其它报文，取决于源MAC和目的MAC地址。对于同样的报文总会Hash到相同的转发端口，即使其它端口有富裕带宽，也无法利用。 

注意事项

基于上述分析和验证，故障原因已经很明显了，处理方案采用增加系统端口带宽来临时解决大吞吐量业务的丢包问题，根本的解决方案为用千兆以太网透传单板来替代。