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

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

原因分析

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

解決方案

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

注意事項(xiàng)

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