引言：在網(wǎng)絡的運行維護中，網(wǎng)管人員經(jīng)常關(guān)注的是網(wǎng)絡的通斷、丟包率和時延等指標，而對組成網(wǎng)絡的各個網(wǎng)絡設備的性能關(guān)注不夠，導致看似運行正常的網(wǎng)絡，故障的隱患正在悄然積聚。筆者單位發(fā)生的一起故障，就是因為交換機系統(tǒng)問題，導致內(nèi)存利用率出現(xiàn)單調(diào)遞增的現(xiàn)象。

單位為實現(xiàn)總部與各分散下屬單位召開視頻會議，根據(jù)需要先后采購了3套視頻會議系統(tǒng)，在總部中心機房利用3臺華為S5700交換機分別作為3套系統(tǒng)的接入交換機，進行連接入網(wǎng)。同時，利用現(xiàn)有的運維管理系統(tǒng)對新入網(wǎng)的3臺交換機進行了監(jiān)測。網(wǎng)絡結(jié)構(gòu)如圖1所示。

故障現(xiàn)象

某天，最先投入使用的視頻會議系統(tǒng)在一次使用中突然出現(xiàn)畫面中斷，現(xiàn)場保障人員迅速到機房查看系統(tǒng)運行情況，發(fā)現(xiàn)是網(wǎng)絡連接中斷導致。由于查看及時，還觀察到了該視頻會議系統(tǒng)的接入交換機正在進行重啟。隨即排除了線路的原因，將排查的重點定位在華為S5700視頻接入交換機上。約5分鐘后，交換機重新啟動，并恢復了視頻會議系統(tǒng)的業(yè)務功能。

圖1 視頻會議系統(tǒng)網(wǎng)絡組織圖

圖2 視頻交換機一個月的內(nèi)存變化曲線

由于事先將該交換機納入了運維系統(tǒng)的監(jiān)測管理，運維系統(tǒng)通過SNMP主動向交換機輪詢采集各種數(shù)據(jù)，同時交換機也通過trap配置，適時向運維服務器發(fā)送trap事件。就在故障發(fā)生的同時，在運維系統(tǒng)的監(jiān)測畫面中也出現(xiàn)了該交換機發(fā)生linkdown事件的告警，由此更加斷定確實是由于交換機故障才導致的視頻會議系統(tǒng)中斷。

故障分析

故障發(fā)生后，單位組織技術(shù)專家對問題交換機進行分析，先后查看了交換機日志，并沒有發(fā)現(xiàn)異常的告警，之后又查看了交換機的其他配置，也沒有發(fā)現(xiàn)問題，故障前也沒有出現(xiàn)丟包等不正?，F(xiàn)象。就在調(diào)查進行了2天后，終于在運維管理系統(tǒng)的一項數(shù)據(jù)統(tǒng)計中發(fā)現(xiàn)了端倪。

通過運維系統(tǒng)，在對該交換機各類數(shù)據(jù)近一個多月的分析中發(fā)現(xiàn)，內(nèi)存利用率在發(fā)生故障時為91.003%，進一步查看歷史數(shù)據(jù)，發(fā)現(xiàn)5月1日的內(nèi)存使用率為61.267%，每天內(nèi)存利用率以07%～1%的速度單調(diào)遞增，歷時33天，達到峰值91.003%，隨后發(fā)生了交換機重啟（如圖 2、圖 3）。至此，故障確診為交換機內(nèi)存溢出，引起重啟，最終導致故障發(fā)生。

（備注：運維系統(tǒng)每3分鐘采集一次，以上數(shù)據(jù)為每天晚上8點整的瞬時內(nèi)存利用率。）

交換機自動重啟后內(nèi)存利用率恢復為56.994%，3天后又上升為59.626%，仍然在按照之前的單調(diào)遞增規(guī)律，每天不斷累計內(nèi)存。此外，在對另外2臺視頻接入交換機的內(nèi)存利用率統(tǒng)計時，也發(fā)現(xiàn)了同樣的變化趨勢。為防止故障再次發(fā)生，當利用率達86%時，對交換機進行了計劃重啟，暫時延緩了故障的發(fā)生。

故障分析

在涉及視頻會議系統(tǒng)的4臺交換機中，型號均為華為S5700，其中匯聚交換機1臺，版本為V100R005C01SPC100，未出現(xiàn)類似的故障現(xiàn)象，接入交換機3臺，版本為V200R001C00SPC300（2012年6月版本）。會不會是后者的系統(tǒng)版本存在內(nèi)存溢出的漏洞導致的呢？帶著這個疑問，筆者查閱了華為官方網(wǎng)站相關(guān)信息，自2014年底以來，華為交換機通告了有關(guān)該問題版本的部分漏洞，會導致內(nèi)存溢出。經(jīng)與華為客服的工程師聯(lián)系溝通，得知曾經(jīng)在其他單位也遇到類似問題（內(nèi)存使用率單調(diào)遞增）。由此，故障原因可以確定是交換機的IOS版本存在隱患。

圖3 故障發(fā)生時的內(nèi)存監(jiān)測曲線

圖4IPv6-TCP-MIB

為進一步深入分析內(nèi)存溢出的原因，請來了華為公司設備研發(fā)工程師對故障現(xiàn)象進行確認，并協(xié)助調(diào)查故障原因，從故障交換機的系統(tǒng)版本入手，進行查找問題。

1.確認當前交換機型號及系統(tǒng)版本，現(xiàn)網(wǎng)華為S5700設備為v200r001c00spc300，加載補丁V2R1SPH002.PAT，交換機作為一個二層設備使用，無特殊配置。

2.查看日志，沒有看到導致設備內(nèi)存升高的信息。

3.查看MAC漂移信息，沒有看到有MAC漂移記錄，dis mac-address flapping record。

4.查看攻擊報文的統(tǒng)計數(shù)據(jù)，只有icmp-flood有計數(shù)增長。因為運維服務器在一直Ping交換機，所以該項有計數(shù)增長是正常 的，display anti-attack statistics。

在分析了所有可能的問題后，開始懷疑存在運維管理系統(tǒng)和被管交換機之間的配合存在問題，通過命令行：

display inspect memdebug-info 29000

發(fā)現(xiàn)設備內(nèi)存的BLK1024字節(jié)的內(nèi)存大量占用，而且不斷累加，沒有正常釋放。通過反復實驗，原來是運維管理系統(tǒng)在進行SNMP采集輪詢中，當獲 取IPv6-TCP-MIB中ipv6TcpConnTable（OID：1.3.6.1.2.1.6.16）的任意節(jié)點時，交換機對申請的配置消息內(nèi)存未做釋放處理，導致出現(xiàn)1024字節(jié)內(nèi)存泄漏（如圖 4）。

試驗驗證

1.實驗環(huán)境

為進一步驗證華為S5700系列交換機在內(nèi)存性能方面存在的隱患問題，我們搭建了實驗環(huán)境，分為兩個部分：

（1）對交換機加運維管理系統(tǒng)進行測試：將相同型號、相同版本的3臺華為S5700交換機與2臺運維管理服務器組成一個局域網(wǎng)（如圖5）。其中一臺加載最新的SPH018補丁，另一臺升級版本為Version 5.130(S5700 V200R003C00SPC300)，第三臺保持原始版本不變。這三臺交換機均配置SNMP，并利用運維管理系統(tǒng)進行監(jiān)控。三臺交換機上均沒有加載任何業(yè)務。

（2）對原始版本不加運維管理系統(tǒng)進行觀測：將一臺華為S5700交換機直接與一臺計算機利用Console線相連，用于觀測其內(nèi)存使用情況，交換機上不加載任何業(yè)務。測試環(huán)境如圖5所示。

圖5 華為5700系列交換機內(nèi)存溢出驗證測試拓撲圖

圖6 華為5700系列交換機內(nèi)存溢出試驗測試登記表

2.測試結(jié)論

在測試環(huán)境中，未升級版本的3臺交換機開機后，初始內(nèi)存利用率均為57%，升級版本后的1臺交換機開機后初始內(nèi)存利用率為48%。7月3日至7月13日，10天內(nèi)我們均定時對交換機內(nèi)存使用率進行采集，不同條件的交換機內(nèi)存增長曲線圖如圖6所示。

分析以上測試結(jié)果可以得出以下結(jié)論：

（1） 版 本 為Version 5.110（S5700 V200R001C00SPC300）的華為S5700系列交換機，會在網(wǎng)管系統(tǒng)的采集觸發(fā)下出現(xiàn)內(nèi)存利用率單調(diào)遞增的現(xiàn)象。

（2）版本為Version 5.110的交換機加載SPH018補丁后，內(nèi)存使用率保持穩(wěn)定在57%左右，不再單調(diào)遞增。

（3）版本為Version 5.110的交換機在進行整體IOS版本升級后，內(nèi)存使用率較升級前降低了8%，并保持穩(wěn)定在48%左右，未出現(xiàn)利用率單調(diào)遞增的現(xiàn)象，但升級后CPU利用率較升級前上升了5%。

故障啟示

網(wǎng)管人員在網(wǎng)絡維護過程中，不應只關(guān)注端到端的網(wǎng)絡狀態(tài)，組成網(wǎng)絡的各個網(wǎng)元設備的性能，更需要進行經(jīng)常性的預檢維護，將各種故障和隱患的苗頭解決在萌芽狀態(tài)。當然，要進行分析就必須依托現(xiàn)代化的運維管理平臺，進行自動的數(shù)據(jù)采集、傳輸和存儲，并根據(jù)需要產(chǎn)生相應的報表，方便網(wǎng)管人員進行預測分析。在分析過程中，要善于運用各種手段進行多角度驗證，確保分析的結(jié)果真實可靠。