問題描述（故障現(xiàn)象）

中興ZXMP S385設(shè)備SEC單板在處理大吞吐量（500M左右?guī)挘I(yè)務(wù)有丟包故障，在實際承載業(yè)務(wù)時吞吐量在430M左右時開始丟包，業(yè)務(wù)實際配置trunk8模式，每個系統(tǒng)口配置帶寬為31個2M共62M的帶寬，在用儀表測試時在不到100M的吞吐量時就開始丟包，經(jīng)過檢查SEC單板性能值發(fā)現(xiàn)只有其中一個系統(tǒng)口有收發(fā)包，其余系統(tǒng)口無收發(fā)字節(jié)。

原因分析

我們的系統(tǒng)口trunk8模式對每個系統(tǒng)口的帶寬分配不是平均分配，而是根據(jù)hash算法來分配每個系統(tǒng)口的帶寬，即使這個系統(tǒng)口的帶寬占滿也不會把這部分帶寬分配到其他的系統(tǒng)口，因而造成了業(yè)務(wù)雖然沒有達到滿配帶寬，但是依然有丟包現(xiàn)象的發(fā)生。

解決方案

在現(xiàn)場首先根據(jù)其中一個方向業(yè)務(wù)流向來依次檢查用戶口和系統(tǒng)口的性能值，并除以時間算出每個端口的平均速率，發(fā)現(xiàn)在帶寬達到430M左右時個別做了trunk8配置的系統(tǒng)口帶寬被占滿，而一些系統(tǒng)口還有一定的富裕流量，在這個時候開始少量丟包。而在使用儀表測試時在500M帶寬測試模式下丟包率達到驚人的80%，依然依據(jù)業(yè)務(wù)流向檢查各端口性能值，發(fā)現(xiàn)在外接測試儀表時只有一個系統(tǒng)口有數(shù)據(jù)包收發(fā)，其他系統(tǒng)口都沒有數(shù)據(jù)包的收發(fā)，經(jīng)過驗證確認SEC單板trunk模式算法采用HASH算法，Hash算法主要取決于報文內(nèi)容，對于IP報文，取決于源IP和目的IP地址，對于其它報文，取決于源MAC和目的MAC地址。對于同樣的報文總會Hash到相同的轉(zhuǎn)發(fā)端口，即使其它端口有富裕帶寬，也無法利用。 

注意事項

基于上述分析和驗證，故障原因已經(jīng)很明顯了，處理方案采用增加系統(tǒng)端口帶寬來臨時解決大吞吐量業(yè)務(wù)的丟包問題，根本的解決方案為用千兆以太網(wǎng)透傳單板來替代。