赫斯曼交換機(jī)環(huán)網(wǎng)失效現(xiàn)象的分析與研究

劉其勇

（南京地鐵運(yùn)營(yíng)有限責(zé)任公司，江蘇 南京 210012）

0 引 言

在赫斯曼交換機(jī)運(yùn)行過程中，正常業(yè)務(wù)的單播數(shù)據(jù)會(huì)出現(xiàn)被廣播的現(xiàn)象，導(dǎo)致車地?zé)o線傳輸網(wǎng)絡(luò)速度大幅下降，下發(fā)大小約2 GB的單個(gè)乘客信息系統(tǒng)（Passenger Information System，PIS）視頻文件需要20～30 h，使得車載PIS視頻文件下發(fā)功能并不具備真正意義上的可使用性[1-3]。針對(duì)這一問題展開分析與研究，從而完善與優(yōu)化車地?zé)o線傳輸網(wǎng)絡(luò)。

1 研究背景

南京地鐵S1號(hào)線自2014年7月1日建成通車以來，PIS系統(tǒng)一直采取祿口基地線下通過U盤直接拷貝視頻文件的方式下發(fā)車載PIS視頻文件。原始設(shè)計(jì)的PIS系統(tǒng)通過車地?zé)o線傳輸網(wǎng)絡(luò)下發(fā)視頻文件的功能始終無法正常使用，問題主要體現(xiàn)在控制中心PIS視頻服務(wù)器的視頻流通過有線網(wǎng)絡(luò)和無線網(wǎng)絡(luò)后傳輸至車載PIS服務(wù)器，下發(fā)單個(gè)PIS視頻文件所需要的時(shí)間較長(zhǎng)[4]。

南京地鐵S1號(hào)線PIS系統(tǒng)由赫斯曼MACH1000骨干網(wǎng)交換機(jī)組成一個(gè)骨干網(wǎng)，赫斯曼RS20交換機(jī)組成AP交換機(jī)環(huán)網(wǎng)，設(shè)置在控制中心的PIS視頻服務(wù)器控制數(shù)據(jù)報(bào)文通過有線網(wǎng)絡(luò)和無線網(wǎng)絡(luò)到達(dá)車載PIS服務(wù)器，完成軌旁對(duì)列車點(diǎn)對(duì)點(diǎn)的單播功能，如圖1所示[5]。

圖1 PIS系統(tǒng)網(wǎng)絡(luò)

2 問題回顧

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

圖2 AP交換機(jī)抓包數(shù)據(jù)

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

圖3 業(yè)務(wù)端口數(shù)據(jù)流量

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

其次，對(duì)控制中心的骨干網(wǎng)交換機(jī)進(jìn)行抓包分析。由于同樣可以抓取到服務(wù)器與所有列車交互的用戶數(shù)據(jù)報(bào)協(xié)議（User Datagram Protocol，UDP）業(yè)務(wù)數(shù)據(jù)，因此驗(yàn)證了本應(yīng)單播的業(yè)務(wù)數(shù)據(jù)包確實(shí)被赫思曼交換機(jī)廣播轉(zhuǎn)發(fā)。骨干網(wǎng)交換機(jī)抓包數(shù)據(jù)如圖4所示。

圖4 骨干網(wǎng)交換機(jī)抓包數(shù)據(jù)

最后，對(duì)PIS系統(tǒng)網(wǎng)絡(luò)中位于赫斯曼骨干網(wǎng)交換機(jī)上游的華為3層交換機(jī)展開抓包分析。由于未抓到上述UDP業(yè)務(wù)數(shù)據(jù)包，因此證明單播數(shù)據(jù)包被廣播轉(zhuǎn)發(fā)并非上游華為交換機(jī)所為。

結(jié)合上述分析結(jié)果，可以確定PIS系統(tǒng)車地通信不佳的原因是正常業(yè)務(wù)單播數(shù)據(jù)包被赫斯曼交換機(jī)廣播占用業(yè)務(wù)帶寬，進(jìn)而導(dǎo)致環(huán)網(wǎng)失效。基于此，對(duì)這一現(xiàn)象展開研究與分析。

3 原因分析

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

通過以上排查信息得知，赫斯曼交換機(jī)環(huán)網(wǎng)失效的原因主要有以下兩點(diǎn)。一是網(wǎng)絡(luò)中存在交換機(jī)環(huán)網(wǎng)協(xié)議配置錯(cuò)誤，導(dǎo)致向全網(wǎng)廣播FLUSH FDB刷新消息，全網(wǎng)交換機(jī)不斷地去清空MAC地址表，環(huán)網(wǎng)處于失效狀態(tài)。二是車載直播軟件機(jī)制問題導(dǎo)致去往未在線列車的業(yè)務(wù)數(shù)據(jù)包被全網(wǎng)廣播轉(zhuǎn)發(fā)，由于未在線列車的MAC地址在赫斯曼交換機(jī)上不存在，因此控制中心PIS視頻服務(wù)器發(fā)往列車的流量被網(wǎng)絡(luò)廣播轉(zhuǎn)發(fā)，所有列車都收到其他列車的無效數(shù)據(jù)包，造成業(yè)務(wù)帶寬被嚴(yán)重?cái)D壓，從而影響視頻業(yè)務(wù)的正常傳輸。

4 整改措施

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

整改完畢后，測(cè)試車地遠(yuǎn)程傳輸視頻文件功能，有效業(yè)務(wù)帶寬達(dá)到3.5 Mb/s左右，實(shí)現(xiàn)了顯著提升。

5 結(jié) 語

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