關注交換機版本

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

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

故障現象

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

圖1 視頻會議系統網絡組織圖

圖2 視頻交換機一個月的內存變化曲線

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

故障分析

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

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

（備注：運維系統每3分鐘采集一次，以上數據為每天晚上8點整的瞬時內存利用率。）

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

故障分析

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

圖3 故障發生時的內存監測曲線

圖4IPv6-TCP-MIB

為進一步深入分析內存溢出的原因，請來了華為公司設備研發工程師對故障現象進行確認，并協助調查故障原因，從故障交換機的系統版本入手，進行查找問題。

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

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

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

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

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

display inspect memdebug-info 29000

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

試驗驗證

1.實驗環境

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

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

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

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

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

2.測試結論

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

分析以上測試結果可以得出以下結論：

（1） 版 本 為Version 5.110（S5700 V200R001C00SPC300）的華為S5700系列交換機，會在網管系統的采集觸發下出現內存利用率單調遞增的現象。

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

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

故障啟示

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