以太網(wǎng)中的交換機之間存在不恰當?shù)亩丝谙噙B會造成網(wǎng)絡環(huán)路，如果相關(guān)的交換機沒有打開STP功能，這種環(huán)路會引發(fā)數(shù)據(jù)包的無休止重復轉(zhuǎn)發(fā)，形成廣播風暴，從而造成網(wǎng)絡故障。我們在校園網(wǎng)的維護過程中多次遇到過這種故障，其中有一次排除故障的過程令我們印象深刻。

故障描述

一天，我們在校園網(wǎng)的網(wǎng)絡運行性能監(jiān)控平臺上發(fā)現(xiàn)某棟摟的VLAN有問題——其接入交換機與校園網(wǎng)的連接中斷。檢查放置在網(wǎng)絡中心的匯聚交換機，測得與之相連的100BASE－FX端口有大量的入流量，而出流量卻非常少，顯得很不正常。然而這臺匯聚交換機的性能似乎還行，感覺不到有什么問題。于是，我們在這臺匯聚交換機上鏡像這個異常端口，用協(xié)議分析工具Sniffer來抓包，最多時每秒鐘居然能抓到10萬多個。對這些數(shù)據(jù)包進行簡單分析，我們發(fā)現(xiàn)其中一些共同特征。

1、絕大部分的包長為62個字節(jié)（加上4字節(jié)的差錯檢測FCS域即為66個字節(jié)），TCP狀態(tài)為SYN；
2、源IP為其他網(wǎng)段的IP、目的IP均為該樓網(wǎng)段的IP；
3、盡管源IP地址不同，但源MAC地址卻是一樣的；
4、目的IP地址和目的MAC地址與在這臺匯聚交換機上綁定該樓VLAN的IP—MAC參數(shù)一致；

5、實際的數(shù)據(jù)流向（流入）與這些數(shù)據(jù)包中的源IP地址和目的IP地址所確定的流向（流出）相反。

當時，我們急于盡快搶修網(wǎng)絡，沒去深究這些數(shù)據(jù)包的特征，只看到第1點就以為網(wǎng)絡受到不明來歷的Syn Flood攻擊，估計是由一種新網(wǎng)絡病毒引起，馬上把這臺匯聚交換機上該端口禁用掉，以免造成網(wǎng)絡性能的下降。 

故障排除

為了能在現(xiàn)場測試網(wǎng)絡的連通性，在網(wǎng)絡中心，我們把連接那棟大樓接入交換機的多模尾纖經(jīng)光電轉(zhuǎn)換器用雙絞線連到一臺PC上，并將其模擬成那個問題VLAN的網(wǎng)關(guān)。然后，到現(xiàn)場找來大樓網(wǎng)管員，想讓他協(xié)助我們盡快把感染了未知病毒的主機查到并隔離。據(jù)大樓網(wǎng)管員反映，昨天網(wǎng)絡還算正常，不過，當時本大樓某部門正在做網(wǎng)絡調(diào)整，今天上班就發(fā)現(xiàn)網(wǎng)絡不行了，不知跟他們有沒有關(guān)系。我們認為調(diào)整網(wǎng)絡應該跟感染病毒關(guān)系不大。 在大樓主配線間，我們把該接入交換機上的網(wǎng)線都拔掉，接上手提電腦，能連通網(wǎng)絡中心的測試主機。我們確認鏈路沒問題后，每次將剩余網(wǎng)線數(shù)量的一半插回該交換機，經(jīng)測試沒問題則如是繼續(xù)下去，否則換插另一半，逐漸縮小懷疑有問題網(wǎng)線的數(shù)量。我們最終找到一條會引起問題的網(wǎng)線，只要插上這根網(wǎng)線，該大樓網(wǎng)絡就會與模擬網(wǎng)關(guān)中斷連接。經(jīng)大樓網(wǎng)管員辨認，這條網(wǎng)線是連接昨天在做網(wǎng)絡調(diào)整的那個部門的。他還說以前該部們拉了一主一備兩條網(wǎng)線，應該還有一條，并親自在那臺交換機上把另一條找了出來。隨意插上這兩條網(wǎng)線中的一條，網(wǎng)絡沒問題，但只要同時插上，就有問題，哪有在一臺交換機上同時插上兩條網(wǎng)

線才會激活網(wǎng)絡病毒的SYN Flood攻擊的？這時我們倒是覺得這種現(xiàn)象更像是網(wǎng)絡中有環(huán)路。 我們到了那個部門發(fā)現(xiàn)有三臺非管理型交換機，都是串在一起的，然而其中兩臺又分別通過那兩條網(wǎng)線與接入交換機相連，從而導致了網(wǎng)絡環(huán)路。顯然是施工人員對網(wǎng)絡拓撲不清楚，當時大樓網(wǎng)管員有事外出，就自以為是地把線接錯了，從而造成了這起網(wǎng)絡事故。原因找到就好辦了，只需拔掉其中一條上聯(lián)網(wǎng)線即可恢復網(wǎng)絡連通。 經(jīng)過一番周折，網(wǎng)絡恢復了正常，但我們還一直在想，是什么干擾了我們的判斷呢？ 

故障分析

一起典型的網(wǎng)絡環(huán)路故障，用協(xié)議分析工具Sniffer抓了這么多的數(shù)據(jù)包，經(jīng)過一番分析卻沒看出問題來。顯然，第一眼看到大量的SYN包讓我們產(chǎn)生了錯覺，想當然地就以為是SYN Flood攻擊。事后，我們就這起網(wǎng)絡環(huán)路故障排除過程做了檢討，重新仔細地分析抓回來的這些數(shù)據(jù)包，據(jù)此解釋一下前面提到這些數(shù)據(jù)包所具有的5個共同特征，以便今后遇到同類問題時能及時作出正確的反應。 先看前4個特征：匯聚交換機是網(wǎng)絡層設備，該大樓所屬VLAN的網(wǎng)絡層接口就設置在這臺匯聚交換機上，出于實施網(wǎng)絡管理策略的需要，對已注冊或沒注冊的IP地址都進行了MAC地址的綁定。TCP連接要經(jīng)過3次握手才能建立起來，在這里發(fā)起連接的SYN包長度為28個字節(jié)，加上14個字節(jié)的以太幀頭部和20個字節(jié)的IP報頭，由Sniffer捕獲到的幀長度共為62個字節(jié)（不包含4字節(jié)的差錯檢測FCS域）。恰巧當時訪問該VLAN的單播幀是來自外網(wǎng)的TCP請求包，根據(jù)以太網(wǎng)橋的轉(zhuǎn)發(fā)機制，通過CRC正確性檢測后，因已做靜態(tài)ARP配置，這臺匯聚交換機會將該單播幀的源MAC地址轉(zhuǎn)換成本機的MAC地址，其目的MAC地址依據(jù)綁定參數(shù)來更換，并重新計算CRC值，更新FCS域，經(jīng)過這樣重新封裝后，再轉(zhuǎn)發(fā)到那棟樓的接入交換機。

再看最后1個特征：網(wǎng)橋是一種存儲轉(zhuǎn)發(fā)設備，用來連接相似的局域網(wǎng)。這些網(wǎng)橋在所有端口上監(jiān)聽著傳送過來的每一個數(shù)據(jù)幀，利用橋接表作為該數(shù)據(jù)幀的轉(zhuǎn)發(fā)依據(jù)。橋接表是MAC地址和用于到達該地址的端口號的一個“MAC地址－端口號”列表，它利用數(shù)據(jù)幀的源MAC地址和接收該幀的端口號來刷新。網(wǎng)橋是這樣來使用橋接表的：當網(wǎng)橋從一個端口接收到一個數(shù)據(jù)幀時，會先刷新橋接表，再在其橋接表中查找該幀的目的MAC地址。如果找到，就會從對應這個MAC地址的端口轉(zhuǎn)發(fā)該幀（如果這個轉(zhuǎn)發(fā)端口與接收端口是相同，就會丟棄該幀）。如果找不到，就會向除了接收端口以外的其他端口轉(zhuǎn)發(fā)該幀，即廣播該幀。這里假定在整個轉(zhuǎn)發(fā)過程中，網(wǎng)橋A、B、C和D都在其橋接表中查找不到該數(shù)據(jù)幀的目的MAC地址，即這些網(wǎng)橋都不知道應該從哪個端口轉(zhuǎn)發(fā)該幀。當網(wǎng)橋A從上聯(lián)端口接收到一個來自上游網(wǎng)絡的單播幀時，會廣播該幀，網(wǎng)橋B、C收到后也會廣播該幀，網(wǎng)橋D收到分別來自網(wǎng)橋B、C的這個單播幀，并分別經(jīng)網(wǎng)橋C、B傳送回網(wǎng)橋A，到此網(wǎng)橋A收到了該單播幀的兩個副本。在這樣的循環(huán)轉(zhuǎn)發(fā)過程中，網(wǎng)橋A不停地在不同端口（這時已經(jīng)不涉及上聯(lián)端口了）接收到相同的幀，由于接收端口在改變，橋接表也在改變“源MAC－端口號”的列表內(nèi)容。前面已經(jīng)假定網(wǎng)橋的橋接表中沒有該幀的目的MAC地址，網(wǎng)橋A在分別收到這兩個單播幀后，都只能再次向除了接收端口以外的其他端口廣播該幀，故該幀也會向上聯(lián)端口轉(zhuǎn)發(fā)。

就每個單播幀而言，網(wǎng)橋A重復前面提到的過程，理論上，廣播一次會收到21個幀，廣播兩次就會收到22個幀，…，廣播到第n次就會收到2n個幀。總之，網(wǎng)橋A照這樣轉(zhuǎn)發(fā)下去，很快就會形成廣播風暴，這個單播幀的副本最終會消耗完100BASE-X端口帶寬。盡管在這期間上聯(lián)端口會有許多數(shù)據(jù)幀在相互碰撞而變的不完整，令Sniffer捕獲不到，但可以想象得到這個單播幀的重復出現(xiàn)次數(shù)仍然會非常多。我們再次檢查那些抓回來的數(shù)據(jù)包，幾乎都發(fā)現(xiàn)有當時沒有注意到的重復標志。按64字節(jié)包長來計算，以太網(wǎng)交換機的100BASE-FX端口轉(zhuǎn)發(fā)線速可達144000pps。在這種網(wǎng)絡環(huán)路狀態(tài)下，Sniffer完全有可能每秒抓到10萬多個包長為66字節(jié)的數(shù)據(jù)包。

基于上述理由，由于當時那4臺交換機的橋接表中都沒有該包的目的MAC地址，處于上游網(wǎng)絡的這臺匯聚交換機向該大樓發(fā)送了一個TCP請求包后，就會不斷地收到由該大樓接入交換機轉(zhuǎn)發(fā)回來的該TCP包的副本，而且數(shù)量非常地多（形成大流量），然而，它并不會把接收到的這些包重發(fā)回去；Internet的網(wǎng)絡應用是基于請求/應答模式的，只有發(fā)送/接收兩條信道都暢通，才能進行端到端的通信。一旦本次網(wǎng)絡應用中有一條信道被堵塞了，就會使得該應用因無法進行而結(jié)束。網(wǎng)絡應用結(jié)束后，一般來說，發(fā)起請求一方不會就本次應用再次自動發(fā)出請求包。于是，在網(wǎng)絡環(huán)路狀態(tài)中普遍會有一條信道有大流量，另一條信道幾乎沒有流量的現(xiàn)象。因為VLAN有隔離廣播域的功能，這些大流量不會穿越網(wǎng)絡層，所以不會對匯聚交換機造成很大壓力。

事實上，由于這種網(wǎng)絡環(huán)路是數(shù)據(jù)鏈路層上的故障，只涉及到源MAC地址和目的MAC地址，不管高層封裝的是什么類型的包都有可能引起廣播風暴。也就是說，當時用Sniffer抓到各種各樣的數(shù)據(jù)包都是有可能的。 

故障預防

校園網(wǎng)的接入層是面向用戶的網(wǎng)絡界面，有許多不可控的成分，情況很復雜，應由專人管理，也應在設備上給予可靠性保證。本摟接入交換機是可管理型的，有STP功能，其他交換機都是非管理型交換機，沒有STP功能。本來事先在該接入交換機上配置了STP功能，這起網(wǎng)絡事故是完全可以避免的，但不知何故沒有這樣做，事后再做只能權(quán)當“亡羊補牢”了。由此可見，即使接入交換機打開了STP功能，下游網(wǎng)絡也會因某種原因構(gòu)成環(huán)路，產(chǎn)生廣播風暴，造成對上游網(wǎng)絡本VLAN的沖擊，故該接入交換機還應有廣播包抑制功能，以便能將影響限制在局部范圍內(nèi)。對于下游網(wǎng)絡的交換機同樣有這些需求，只是成本問題而已。一句話，在網(wǎng)絡故障排除時，技術(shù)和經(jīng)驗固然重要，但在平時就要注意維護網(wǎng)絡的規(guī)范連接、落實基本的防范措施更為重要。