赫斯曼交換機環網失效現象的分析與研究

劉其勇

（南京地鐵運營有限責任公司，江蘇 南京 210012）

0 引 言

在赫斯曼交換機運行過程中，正常業務的單播數據會出現被廣播的現象，導致車地無線傳輸網絡速度大幅下降，下發大小約2 GB的單個乘客信息系統（Passenger Information System，PIS）視頻文件需要20～30 h，使得車載PIS視頻文件下發功能并不具備真正意義上的可使用性[1-3]。針對這一問題展開分析與研究，從而完善與優化車地無線傳輸網絡。

1 研究背景

南京地鐵S1號線自2014年7月1日建成通車以來，PIS系統一直采取祿口基地線下通過U盤直接拷貝視頻文件的方式下發車載PIS視頻文件。原始設計的PIS系統通過車地無線傳輸網絡下發視頻文件的功能始終無法正常使用，問題主要體現在控制中心PIS視頻服務器的視頻流通過有線網絡和無線網絡后傳輸至車載PIS服務器，下發單個PIS視頻文件所需要的時間較長[4]。

南京地鐵S1號線PIS系統由赫斯曼MACH1000骨干網交換機組成一個骨干網，赫斯曼RS20交換機組成AP交換機環網，設置在控制中心的PIS視頻服務器控制數據報文通過有線網絡和無線網絡到達車載PIS服務器，完成軌旁對列車點對點的單播功能，如圖1所示[5]。

圖1 PIS系統網絡

2 問題回顧

首先，對祿口基地運用庫內的任意一個AP交換機進行抓包。將赫斯曼RS20交換機的業務端口（連接AP端口）的VLAN設置由VLAN100 Trunk模式改為VLAN100 access模式，以便抓取業務報文。S1號線共配置15列電客車，祿口基地運用庫內有3列車，其中2車升弓上電、9車和13車降弓下電（車載PIS系統不工作）。此外，其余12列車在正線上電運行。在用Wireshark抓包軟件進行分析時發現，在138 s內鏡像端口共捕獲數據包429 795個，包含了全部13列已上電列車的數據包，除去兩列車降弓下電外，所有升弓上電列車收/發的數據包均能被捕獲到。抓取的數據包如圖2所示。控制中心PIS服務器（源地址為192.10.61.17）發送數據至其他所有列車，目的地址為192.168.X.4（X車車頭）/192.168.X.5（X車車尾），其中IP地址的第3字節X表示列車編號。

圖2 AP交換機抓包數據

通過以上抓包數據，可知任意一個AP交換機端口的帶寬被占用了20～40 Mb/s，且大多數流量為其他列車通信數據。對于目標列車來說，帶寬幾乎被其他列車流量完全占用。業務端口數據流量如圖3所示。

圖3 業務端口數據流量

發送至AP交換機的數據包中充滿了大量被廣播的單播數據包，即本應被交換機以單播形式轉發的數據包現在被以廣播的形式發送到了每一個終端處。與正常的單獨送信相比，整個網絡的傳輸負荷是呈指數性上升的。圖3是鏡像端口138 s時間內捕獲的數據包I/O（輸入輸出）圖，共捕獲數據包429 795個，平均帶寬33 Mb/s，峰值帶寬46 Mb/s。根據實際測量，發送至AP交換機的數據速率高達30～40 Mb/s，而中心下發至車輛的實時視頻信息和控制信息所使用的帶寬設計值為6 Mb/s，故至少有4/5的數據包因AP交換機無法送出而被丟棄。

其次，對控制中心的骨干網交換機進行抓包分析。由于同樣可以抓取到服務器與所有列車交互的用戶數據報協議（User Datagram Protocol，UDP）業務數據，因此驗證了本應單播的業務數據包確實被赫思曼交換機廣播轉發。骨干網交換機抓包數據如圖4所示。

圖4 骨干網交換機抓包數據

最后，對PIS系統網絡中位于赫斯曼骨干網交換機上游的華為3層交換機展開抓包分析。由于未抓到上述UDP業務數據包，因此證明單播數據包被廣播轉發并非上游華為交換機所為。

結合上述分析結果，可以確定PIS系統車地通信不佳的原因是正常業務單播數據包被赫斯曼交換機廣播占用業務帶寬，進而導致環網失效。基于此，對這一現象展開研究與分析。

3 原因分析

首先查看控制中心骨干網交換機的MAC地址表項，以驗證交換機是否能正確學習到相關MAC地址表[6,7]。通過觀察MAC表，發現全線赫斯曼交換機的MAC地址表一直反復處于不斷清空再學習的狀態，因此初步判斷為交換機存在MAC地址表被清空的時間段，在此時間段內赫斯曼交換機會對業務報文做出廣播處理。其次進一步檢查全線赫斯曼交換機日志，發現翠屏山站赫斯曼交換機存在異常，此交換機的1.7端口開啟SubRing的Redundant Manager功能，從日志來看此端口狀態一直不斷變化，基本上每秒都會產生收斂日志，導致交換機向全網廣播FLUSH FDB刷新消息，進而導致全網交換機不斷清空MAC地址表。檢查翠屏山赫斯曼交換機1.7端口下所接的子環交換機配置，發現收集的交換機配置沒有AP0723-SW，而是DP11的配置，而DP11沒有相關子環的正確配置。基于此，懷疑此交換機配置錯誤。最后檢查車載直播軟件工作狀態，發現列車自動監控系統（Automatic Train Control，ATS）服務器上的車載直播軟件一直給多列車發送直播業務數據，包括一部分未在線列車[8]。由于赫斯曼交換機MAC地址表中沒有未在線列車的MAC地址，因此服務器發送至未在線列車的數據包被全網廣播轉發，占用業務帶寬。

通過以上排查信息得知，赫斯曼交換機環網失效的原因主要有以下兩點。一是網絡中存在交換機環網協議配置錯誤，導致向全網廣播FLUSH FDB刷新消息，全網交換機不斷地去清空MAC地址表，環網處于失效狀態。二是車載直播軟件機制問題導致去往未在線列車的業務數據包被全網廣播轉發，由于未在線列車的MAC地址在赫斯曼交換機上不存在，因此控制中心PIS視頻服務器發往列車的流量被網絡廣播轉發，所有列車都收到其他列車的無效數據包，造成業務帶寬被嚴重擠壓，從而影響視頻業務的正常傳輸。

4 整改措施

斷開赫斯曼AP0723（172.26.129.187）交換機的端口1.1，保證子環處于單鏈路狀態。關閉交換機撥碼開關，登錄赫思曼AP0723（172.26.129.187）交換機Web配置界面，刪除現有環網協議Hiper-Ring配置。選擇介質冗余協議（Media Redundancy Protocol，MRP），選擇環網端口1.1和1.2，開啟功能并配置環網Vlan15。配置完成后開啟1.1端口，從網管上檢查交換機連接狀態，檢查環網冗余狀態是否運行正常，最后保存全局配置。除此之外，在遠程下發視頻文件或其他較大數據需要無線傳輸時，通過暫時關閉車載直播軟件的方式大幅提高有效業務帶寬[9,10]。

整改完畢后，測試車地遠程傳輸視頻文件功能，有效業務帶寬達到3.5 Mb/s左右，實現了顯著提升。

5 結 語

本課題研究成果已經幫助S1號線技術人員成功解決正常業務單播數據被交換機廣播轉發時車地網絡無法正常通信的問題，目前工作人員只需在控制中心遠程操作便可以將視頻文件下發至在線列車，無需等待線路停運后登上每一輛列車進行視頻文件的本地上傳工作，大大提高了工作效率，減輕了工作負擔。