ATS子系統(tǒng)單播泛洪引發(fā)網(wǎng)絡(luò)風(fēng)暴仿真及網(wǎng)絡(luò)優(yōu)化

孫海峰

ATS子系統(tǒng)單播泛洪引發(fā)網(wǎng)絡(luò)風(fēng)暴仿真及網(wǎng)絡(luò)優(yōu)化

孫海峰

摘 要：列車自動監(jiān)控（ATS）子系統(tǒng)網(wǎng)絡(luò)的穩(wěn)定和優(yōu)化，關(guān)乎整個信號系統(tǒng)的穩(wěn)定和安全。以真實線路硬件和組網(wǎng)方式為基礎(chǔ)，模擬仿真了網(wǎng)絡(luò)中的單播泛洪網(wǎng)絡(luò)風(fēng)暴，收集了第一手的數(shù)據(jù)資料，并對數(shù)據(jù)通信系統(tǒng)（DCS）網(wǎng)絡(luò)結(jié)構(gòu)優(yōu)化做了進(jìn)一步的分析。

關(guān)鍵詞：ATS；DCS；泛洪；單播；廣播；網(wǎng)絡(luò)風(fēng)暴；仿真；優(yōu)化

孫海峰：通號國際控股有限公司，工程師，北京 100166

在城市軌道交通信號系統(tǒng)中，列車自動監(jiān)控（ATS）子系統(tǒng)作為行車運營不可或缺的部分，已經(jīng)越來越得到各個廠家的重視。在非基于無線的信號系統(tǒng)中，數(shù)據(jù)通信系統(tǒng)（DCS）網(wǎng)絡(luò)只負(fù)責(zé)承載ATS子系統(tǒng)網(wǎng)絡(luò)流量，但是到了基于無線通信的列車控制（CBTC）階段，DCS網(wǎng)絡(luò)開始承載整個車-地通信的重任。DCS網(wǎng)絡(luò)的安全完整性等級一般為SIL0，而ATS子系統(tǒng)的安全完整性等級一般為SIL2。SIL0級的安全等級甚至可以被認(rèn)為沒有安全等級的限制，從這個意義上說，ATS子系統(tǒng)和DCS網(wǎng)絡(luò)均為非安全系統(tǒng)。但是，DCS網(wǎng)絡(luò)作為信號系統(tǒng)通信的基礎(chǔ)，A T S子系統(tǒng)作為信號系統(tǒng)的人機界面，它們在列車正常運營中的重要地位是不容忽視的。A T S主要功能有：①編制運行圖，根據(jù)運行圖自動辦理列車進(jìn)路，自動調(diào)整列車運行間隔，必要時可以人工介入調(diào)整列車間隔；②記錄運行數(shù)據(jù)；③運營人員對信號系統(tǒng)進(jìn)行控制的人機接口，如設(shè)置進(jìn)路、設(shè)置停站時間、設(shè)置線路或列車的臨時限速等。因此，一旦ATS出現(xiàn)故障，操作員將失去對整個信號系統(tǒng)的操作權(quán)，造成線路無法正常運營的嚴(yán)重后果。

A T S子系統(tǒng)的組網(wǎng)方式通常有2種：一種是由通信系統(tǒng)的傳輸子系統(tǒng)提供透傳的網(wǎng)絡(luò)通道，ATS提供網(wǎng)絡(luò)交換機等設(shè)備與傳輸子系統(tǒng)進(jìn)行接口，達(dá)到組網(wǎng)的目的；還有一種是信號系統(tǒng)使用光纖、光端機、光交換機等設(shè)備自己組建DCS網(wǎng)絡(luò)，以便達(dá)到傳輸安全信息的目的。2種傳輸方式各有利弊，分別適配不同制式的信號系統(tǒng)。前一種方式在組建網(wǎng)絡(luò)方面要經(jīng)過DCS網(wǎng)絡(luò)與傳輸系統(tǒng)的接口，且涉及到2種網(wǎng)絡(luò)拓?fù)涞倪B接，因此，接口的穩(wěn)定與否決定了整個DCS網(wǎng)絡(luò)的穩(wěn)定性，潛在的問題較多；后者由于是信號系統(tǒng)自己建網(wǎng)，網(wǎng)絡(luò)結(jié)構(gòu)由信號系統(tǒng)設(shè)計方控制，網(wǎng)絡(luò)拓?fù)漭^為透明，因此，穩(wěn)定性較高。本文的仿真環(huán)境將使用前一種組網(wǎng)方式，以便充分說明在復(fù)雜網(wǎng)絡(luò)環(huán)境下可能出現(xiàn)的問題。在本仿真中，暫不考慮車載無線信號的接入情況。

1　仿真環(huán)境

1.1網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)

本文所采用的信號系統(tǒng)DSC仿真環(huán)境整體網(wǎng)絡(luò)拓?fù)淙鐖D1所示。

網(wǎng)絡(luò)中采取雙網(wǎng)環(huán)形連接，通信傳輸系統(tǒng)同步數(shù)字體系（SDH）采用雙網(wǎng)冗余結(jié)構(gòu)，它為DCS網(wǎng)絡(luò)在每個節(jié)點提供2條獨立的通道，分別連接交換機的2個端口。

圖1　仿真拓?fù)鋱D

圖2　控制中心與車站連接示意圖

為了比較清晰地說明問題，圖2為控制中心（OCC）和車站的一個典型連接示意圖。

1.2硬件設(shè)備組成

在圖2控制中心與車站連接示意圖中，左側(cè)為控制中心的設(shè)備連接示意圖，右側(cè)為車站設(shè)備連接示意圖。所有交換機均為3層交換機，但暫不使用其路由功能，OCC 的3臺交換機之間采用星形連接的方式，以防止單點故障導(dǎo)致網(wǎng)絡(luò)通信中斷；所有車站的網(wǎng)絡(luò)配置均相同。為保證單點故障不影響網(wǎng)絡(luò)通信，中心交換機3和車站的交換機均采用雙線冗余的連接方式接入SDH傳輸系統(tǒng)。為了防止產(chǎn)生網(wǎng)絡(luò)環(huán)路，所有交換機上均啟用了生成樹協(xié)議（STP），使2條同時接入SDH的網(wǎng)線通道有1條邏輯上是斷開的。

為了充分模擬真實的運營環(huán)境，仿真共連接了19個車站網(wǎng)絡(luò)節(jié)點，1個OCC網(wǎng)絡(luò)節(jié)點，所有車站配備ATS工作站；車站節(jié)點中，車站ATS工作站采用惠普計算機，采用雙網(wǎng)卡配置，搭載雙網(wǎng)卡綁定程序（稱為“HP NIC teaming”技術(shù)）達(dá)到熱備冗余的目的，2塊網(wǎng)卡綁定后使用1個邏輯IP地址與控制中心ATS應(yīng)用服務(wù)器通信，邏輯上相當(dāng)于1塊網(wǎng)卡。每塊網(wǎng)卡分別連接車站3層交換機的2個端口，2個端口配置的VLAN相同。

仿真環(huán)境下，所有的ATS設(shè)備均處于同一個VLAN中。整個ATS網(wǎng)絡(luò)為平面結(jié)構(gòu)。SDH設(shè)置為透傳模式，僅為信號ATS子系統(tǒng)提供傳輸通道，不對傳輸?shù)膱笪倪M(jìn)行任何處理。

2　仿真實驗過程

網(wǎng)絡(luò)硬件連接完畢后，通過SDH網(wǎng)管軟件，為每1條SDH通道加入“TAG”標(biāo)簽以保證DCS網(wǎng)絡(luò)中VLAN信息的正確傳輸。

由于D C S網(wǎng)絡(luò)的交換機已經(jīng)開啟了STP，因此，當(dāng)車站逐個接入網(wǎng)絡(luò)并與OCC通信時，每當(dāng)接入1個車站（節(jié)點）時，STP就會更新自己的內(nèi)部拓?fù)鋱D（拓?fù)涓淖兺ǜ?，簡稱TCN），并且重新計算每1條路徑，當(dāng)發(fā)現(xiàn)存在1條或者多條環(huán)路時，STP會從邏輯上打斷環(huán)路，因此，在同一時刻只有1條邏輯通道保證網(wǎng)絡(luò)的正常通信。從一定程度上保證了網(wǎng)絡(luò)的聯(lián)通性。

在每1個車站接入網(wǎng)絡(luò)前，開啟各個車站的ATS客戶端軟件，一旦網(wǎng)絡(luò)連通，ATS客戶端軟件會自動和控制中心的ATS服務(wù)器軟件進(jìn)行通信，可以看到，剛接入幾個車站時，ATS客戶端軟件和服務(wù)器通信是正常的，但當(dāng)接入的車站越來越多時，網(wǎng)絡(luò)節(jié)點逐漸增加時，各個車站交換機的端口指示燈閃爍頻率開始變快，網(wǎng)絡(luò)開始出現(xiàn)延遲的現(xiàn)象，同時，ATS客戶端與服務(wù)器的連接也不再正常，開始出現(xiàn)時斷時續(xù)的現(xiàn)象。

隨后，開始從中心交換機2上的1個可通信的端口進(jìn)行抓包分析。

3　仿真實驗結(jié)果

試驗中選取的端口為ATS網(wǎng)絡(luò)中的1個端口，正常情況下，此端口可與ATS網(wǎng)絡(luò)中的車站ATS、ATS服務(wù)器正常通信。這里需要特殊說明一下，一般在正常的網(wǎng)絡(luò)中，需要抓取數(shù)據(jù)包的時候需要設(shè)置“監(jiān)測”端口，這個端口可以獲取流經(jīng)本交換機的所有數(shù)據(jù)流量，在交換機正常工作時，監(jiān)測端口的流量就已經(jīng)很大了，而且會消耗交換機很大的運算資源。在本仿真中，為了真實反映交換機某一個普通端口所受到的網(wǎng)絡(luò)沖擊，另外，為了減少交換機死機的概率，因此，未啟用監(jiān)測端口進(jìn)行監(jiān)測，而是采用了1個普通通信端口進(jìn)行抓包分析。

由于瞬時的數(shù)據(jù)量比較大，因此，提取的數(shù)據(jù)包的檢測時長為155.155 s。在此時間段內(nèi)，平均每秒采集數(shù)據(jù)包6 913.504個，流量約為4.522 Mbit/s，獲取的數(shù)據(jù)包約有1 072 667個。在107萬個數(shù)據(jù)包中，TCP（傳輸控制協(xié)議）數(shù)據(jù)包為907個，占總數(shù)量的0.08%；UDP（用戶數(shù)據(jù)報協(xié)議）數(shù)據(jù)包為16 253個，占總數(shù)量的1.52%；廣播數(shù)據(jù)包為54 985個，占總數(shù)量的5.126%，其中ARP（地址解析協(xié)議）數(shù)據(jù)包為40 840個，占總數(shù)量的3.81%；L L C（邏輯鏈路控制）數(shù)據(jù)包為1 013 699個，占到了94.5%。大部分的交換機資源和帶寬都被LLC數(shù)據(jù)消耗了。交換機每隔0.1～0.08 ms便會收到一個LLC數(shù)據(jù)包，這些數(shù)據(jù)包發(fā)送頻率快且內(nèi)容重復(fù)性高。

從LLC數(shù)據(jù)包中可以發(fā)現(xiàn)，它首先按照IEEE 802.3 Ethernet報頭進(jìn)行封裝，包含了目標(biāo)MAC地址和源MAC地址；其次，LLC層報頭包含了鏈路的控制信息；下面的數(shù)據(jù)包含了58 bytes的連續(xù)數(shù)據(jù)，但內(nèi)容非常有限。從整個報文封裝的形式和內(nèi)容來看，它的作用是惠普雙網(wǎng)卡綁定后網(wǎng)卡驅(qū)動程序的心跳（Heartbeat）信息。由于它包含了明確的目標(biāo)MAC地址和源MAC地址，因此，不屬于廣播報文，而是點對點的單播報文。但為什么會出現(xiàn)如此多的單播數(shù)據(jù)包并造成網(wǎng)絡(luò)崩潰呢？這是最大的疑問。

在收集到的數(shù)據(jù)中，廣播報文數(shù)量為5.5萬個，絕對數(shù)量還是比較大的，占總數(shù)據(jù)包的5.14%，從比例來講不算太高。其中，ARP數(shù)據(jù)占到了廣播報文的74.27%，占比也比較高。初步分析和網(wǎng)絡(luò)出現(xiàn)環(huán)路有部分關(guān)系。

另外，校驗碼錯誤的數(shù)據(jù)包的數(shù)量為29 243個，其中有一部分?jǐn)?shù)據(jù)出現(xiàn)大量的、連續(xù)校驗錯誤數(shù)據(jù)包。這也是交換機資源將要耗盡，或者由于大量的擁塞數(shù)據(jù)導(dǎo)致的。

4　原因分析

從仿真結(jié)果中可以看出，雖然此次仿真中收集到了超過正常網(wǎng)絡(luò)的廣播報文，但導(dǎo)致網(wǎng)絡(luò)中斷的真正元兇為數(shù)量巨大的LLC單播報文，這種報文不僅數(shù)量多且報文重復(fù)率高，最終耗盡了網(wǎng)絡(luò)資源引發(fā)網(wǎng)絡(luò)崩潰。這種現(xiàn)象稱為泛洪。泛洪產(chǎn)生的原因分析如下。

(1）首先從網(wǎng)絡(luò)結(jié)構(gòu)上進(jìn)行分析，在此次仿真中，所有網(wǎng)絡(luò)交換機均被配置為2層交換機，每1個交換機均能夠檢測到其他的交換機。雖然每個交換機都啟用了STP，但在增加車站的節(jié)點交換機時，交換機之間會通過發(fā)送TCN來交換拓?fù)鋱D數(shù)據(jù)，并且當(dāng)拓?fù)浒l(fā)生變化時，也會通過TCN來通知其他的交換機。STP會據(jù)此來計算新的拓?fù)鋱D中的環(huán)路。

對照圖2的控制中心和車站的典型連接圖，可以發(fā)現(xiàn)其中環(huán)路如圖3所示。

在圖3中，僅僅考慮了OCC和1個車站之間的情況，車站與車站之間也存在環(huán)路。在此次仿真中，有多達(dá)19個車站交換機，因此，類似環(huán)路3的環(huán)路的數(shù)量將異常龐大。STP不得不針對如此多的環(huán)路進(jìn)行計算。

STP在計算環(huán)路路徑并且更新拓?fù)鋽?shù)據(jù)的過程中，受限于2個條件：當(dāng)拓?fù)鋱D非常大時，交換機之間更新拓?fù)鋱D數(shù)據(jù)需要時間；更新數(shù)據(jù)完成后，交換機需要消耗一定的資源進(jìn)行環(huán)路的計算。如果拓?fù)鋱D比較大，STP需要擴散BPDU（網(wǎng)橋協(xié)議數(shù)據(jù)單元）數(shù)據(jù)包，相應(yīng)計算的時間將成倍增長，在計算結(jié)果尚未出現(xiàn)之前，由于STP無法通知交換機邏輯上應(yīng)該關(guān)閉哪一條連接，因此，2條連接都是打開的狀態(tài)，重復(fù)數(shù)據(jù)包可以暢通無阻地被轉(zhuǎn)發(fā)。因此，大量環(huán)路的出現(xiàn)是單播泛洪出現(xiàn)的前提。

(2）交換機是通過2層交換機的MAC地址表和CAM（中央地址存儲器）表來轉(zhuǎn)發(fā)數(shù)據(jù)。如果1個數(shù)據(jù)幀到達(dá)交換機后，交換機MAC地址表中沒有此數(shù)據(jù)幀中目的MAC地址的表項，那么交換機會將此數(shù)據(jù)幀廣播到對應(yīng)VLAN中除了接收端口外的其他端口，這樣就形成了泛洪。泛洪可能由3種原因?qū)е拢孩俨粚ΨQ路由；②生成樹拓?fù)涓淖?；③轉(zhuǎn)發(fā)表溢出。

由于仿真的網(wǎng)絡(luò)呈環(huán)形，因此，基本不存在不對稱路由的情況。另外，現(xiàn)在的交換機一般都有很大容量的地址表空間，所以，轉(zhuǎn)發(fā)表溢出是可能的但是很少見。因此，生成樹拓?fù)涓淖兪潜敬螁尾シ汉槌霈F(xiàn)的原因。

綜合上述兩點分析，可以發(fā)現(xiàn)：當(dāng)網(wǎng)絡(luò)中不斷增加新的節(jié)點，網(wǎng)絡(luò)拓?fù)浒l(fā)生變化后，到達(dá)某一個目的地址的路徑可能發(fā)生變化，例如，以前數(shù)據(jù)包從端口1轉(zhuǎn)發(fā)，現(xiàn)在變成了端口2，這樣就可能導(dǎo)致數(shù)據(jù)包不能正確轉(zhuǎn)發(fā)，所以，必須用某種機制去避免出現(xiàn)這種情況。S T P中T C N的作用是通知交換機網(wǎng)絡(luò)拓?fù)渥兓?，并且減小交換機中MAC轉(zhuǎn)發(fā)表的超時時間。TCN由端口轉(zhuǎn)發(fā)狀態(tài)改變觸發(fā)。在一個配置合理的網(wǎng)絡(luò)中TCN報文是很少的，也就是網(wǎng)絡(luò)拓?fù)鋷缀鹾苌侔l(fā)生改變。

在正常的情況下，交換機收到TCN后會使MAC轉(zhuǎn)發(fā)表加速老化，但是不久就會更新MAC表項，這樣泛洪不會持續(xù)很久的時間，所產(chǎn)生的數(shù)據(jù)包的數(shù)量也不會很多，且可以隨著端口轉(zhuǎn)發(fā)狀態(tài)的改變而逐漸被交換機丟棄。但是，如果有交換機不斷接入網(wǎng)絡(luò)，或者從網(wǎng)絡(luò)斷開連接，那么就會產(chǎn)生大量的TCN，交換機則會連續(xù)收到TCN的報文，那么MAC轉(zhuǎn)發(fā)表就會處于不斷的變化之中，如果此時1個未知MAC地址的數(shù)據(jù)幀到達(dá)，就會引起單播泛洪；再加上STP尚未收斂，網(wǎng)絡(luò)中存在大量的環(huán)路，被轉(zhuǎn)發(fā)的泛洪數(shù)據(jù)包會通過環(huán)路，再次回到此交換機，并在復(fù)制后再次被轉(zhuǎn)發(fā)，大量的泛洪就會產(chǎn)生，同時，由于交換機的運算資源被用來計算STP的環(huán)路，它用于轉(zhuǎn)發(fā)數(shù)據(jù)包的能力就會減少，會造成大量數(shù)據(jù)包的阻塞，因此，有用的數(shù)據(jù)包無法轉(zhuǎn)發(fā)出去，無用的廣播和多播信息卻不斷增多，周而復(fù)始的惡性循環(huán)，最終會導(dǎo)致交換機資源的耗盡、死機和網(wǎng)絡(luò)中斷。

圖3　潛在的環(huán)路示意圖

5　網(wǎng)絡(luò)改進(jìn)及優(yōu)化

如上節(jié)所述，不對稱路由、生成樹拓?fù)涓淖兒娃D(zhuǎn)發(fā)表溢出可能會導(dǎo)致單播泛洪，而不對稱路由在DCS網(wǎng)絡(luò)中基本不存在，由于現(xiàn)在交換機的配置較高，轉(zhuǎn)發(fā)表溢出也很少發(fā)生，因此，我們還是將目光集中在生成樹拓?fù)涓淖冞@個原因上。采取將原來的2層平型網(wǎng)絡(luò)劃分為3層帶路由的網(wǎng)絡(luò)，并劃分不同的VLAN來隔絕廣播域，使每個STP作用的網(wǎng)絡(luò)范圍變小，從而達(dá)到減少TCN的目的。

網(wǎng)絡(luò)的優(yōu)化示意如圖4所示。在交換機3及車站的交換機N上啟用了路由功能，原本存在的環(huán)路2和環(huán)路3被切斷，網(wǎng)絡(luò)域1和網(wǎng)絡(luò)域2上分別運行各自的STP，環(huán)路1則由網(wǎng)絡(luò)域1上運行的STP控制。這樣優(yōu)化以后，STP的作用范圍明顯變小了，單播泛洪的可能性隨著減小，另外，即使網(wǎng)絡(luò)域2中產(chǎn)生了大量的廣播數(shù)據(jù)包，也不會影響到整個網(wǎng)絡(luò)。

由于ATS在OCC會有很多與其他子系統(tǒng)的網(wǎng)絡(luò)接口（如PIS、大屏、時鐘、無線系統(tǒng)等），這些外部系統(tǒng)一般是信號ATS子系統(tǒng)認(rèn)為不安全的網(wǎng)絡(luò)，即使如圖4所示進(jìn)行了網(wǎng)絡(luò)優(yōu)化，它們的接入也會對ATS網(wǎng)絡(luò)有潛在的影響。因此，建議在控制中心用防火墻替代交換機3，用來保護(hù)ATS內(nèi)部網(wǎng)絡(luò)，并增加外部接口交換機專門負(fù)責(zé)外部接口的接入。重新優(yōu)化后的網(wǎng)絡(luò)連接方式如圖5所示。

圖4　網(wǎng)絡(luò)域優(yōu)化示意圖

圖5　加入防火墻后的網(wǎng)絡(luò)優(yōu)化方案

6　總結(jié)

單播泛洪造成的網(wǎng)絡(luò)風(fēng)暴與廣播包造成的網(wǎng)絡(luò)風(fēng)暴相比，二者發(fā)生的原因不同，某些情況下，廣播報文可以直接進(jìn)行放棄處理；但是單播報文含有數(shù)據(jù)，交換機不會輕易進(jìn)行放棄處理，而一旦發(fā)生泛洪，同樣會引起網(wǎng)絡(luò)崩潰，它的發(fā)生具有相當(dāng)?shù)碾[蔽性。

針對信號系統(tǒng)的D C S網(wǎng)絡(luò)，一旦產(chǎn)生了網(wǎng)絡(luò)風(fēng)暴將會對系統(tǒng)產(chǎn)生非常大的破壞，輕者導(dǎo)致網(wǎng)絡(luò)中斷，重者會因此造成數(shù)據(jù)延遲、混亂，以至于影響到行車的安全。在目前信號系統(tǒng)的應(yīng)用中，網(wǎng)絡(luò)通信已經(jīng)逐漸成為控制信號傳輸非常重要的一個環(huán)節(jié)，因此，在網(wǎng)絡(luò)的設(shè)計之初，就要從源頭上截斷出現(xiàn)網(wǎng)絡(luò)風(fēng)暴的可能性。由于DCS網(wǎng)絡(luò)是一個封閉的局域網(wǎng)，因此，預(yù)防措施也很簡單：恰當(dāng)劃分VLAN，縮小廣播域，隔離廣播風(fēng)暴，使用防火墻對重要設(shè)備進(jìn)行防護(hù)，定期對網(wǎng)絡(luò)進(jìn)行查毒、殺毒，加強對網(wǎng)絡(luò)線路運行狀態(tài)的監(jiān)控，常態(tài)化對網(wǎng)絡(luò)設(shè)備的硬件維護(hù)，做到了這些措施，基本能夠保證網(wǎng)絡(luò)風(fēng)暴的不再發(fā)生。

參考文獻(xiàn)

[1] 張欣. 生成樹協(xié)議及其優(yōu)化策略[J]. 科技信息，2006（S1）：15.

[2] 王震宇，馬曉軍，蔣烈輝. STP協(xié)議與生成樹設(shè)計優(yōu)化[J]. 信息工程大學(xué)學(xué)報，2003，4（1）：66-68.

[3] 朱凱進(jìn),席小剛. 淺析生成樹協(xié)議在大型局域網(wǎng)內(nèi)的正確應(yīng)用[J].硅谷，2010（24）：2.

責(zé)任編輯 冒一平

Simulation in Unicast Flooding Causing Data Storm on ATS and Network Optimization

Sun Haifeng

Abstract:Stability and optimization on the subsystem of the network of the automatic train supervision (ATS) have impact directly on the stability and security of entire signaling system. Taking the real hardware and networking mode as the basis, the paper describes the flooding broadcast storm simulation, collects data, and makes further analysis on network structure optimization of the data communication system (DCS).

Keywords:ATS, DCS, flooding, unicast, broadcast, data storm, simulation, optimization

收稿日期2014-07-25

中圖分類號：U231.7