交換機中網路環路常見問題詳解

　　 　　乙太網中的交換機之間存在不恰當的埠相連會造成網路環路，如果相關的交換機沒有開啟STP功能，這種環路會引發資料包的無休止重複轉發，形成廣播風暴，從而造成網路故障。

一天，我們在校園網的網路執行效能監控平臺上發現某棟摟的VLAN有問題——其接入交換機與校園網的連線中斷。檢查放置在網路中心的匯聚交換機，測得與之相連的100BASE－FX埠有大量的入流量，而出流量卻非常少，顯得很不正常。然而這臺匯聚交換機的效能似乎還行，感覺不到有什麼問題。於是，我們在這臺匯聚交換機上映象這個異常埠，用協議分析工具Sniffer來抓包，最多時每秒鐘居然能抓到10萬多個。對這些資料包進行簡單分析，我們發現其中一些共同特徵。

當時，我們急於儘快搶修網路，沒去深究這些資料包的特徵，只看到第1點就以為網路受到不明來歷的Syn Flood攻擊，估計是由一種新網路病毒引起，馬上把這臺匯聚交換機上該埠禁用掉，以免造成網路效能的下降。

故障排除

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

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

故障分析

一起典型的網路環路故障，用協議分析工具Sniffer抓了這麼多的資料包，經過一番分析卻沒看出問題來。顯然，第一眼看到大量的SYN包讓我們產生了錯覺，想當然地就以為是SYN Flood攻擊。事後，我們就這起網路環路故障排除過程做了檢討，重新仔細地分析抓回來的這些資料包，據此解釋一下前面提到這些資料包所具有的5個共同特徵，以便今後遇到同類問題時能及時作出正確的反應。先看前4個特徵：匯聚交換機是網路層裝置，該大樓所屬VLAN的網路層介面就設定在這臺匯聚交換機上，出於實施網路管理策略的需要，對已註冊或沒註冊的 IP地址都進行了MAC地址的繫結。TCP連線要經過3次握手才能建立起來，在這裡發起連線的SYN包長度為28個位元組，加上14個位元組的以太幀頭部和 20個位元組的IP報頭，由Sniffer捕獲到的幀長度共為62個位元組（不包含4位元組的差錯檢測FCS域）。恰巧當時訪問該VLAN的單播幀是來自外網的 TCP請求包，根據乙太網橋的轉發機制，透過CRC正確性檢測後，因已做靜態ARP配置，這臺匯聚交換機會將該單播幀的源MAC地址轉換成本機的MAC地址，其目的MAC地址依據繫結引數來更換，並重新計算CRC值，更新FCS域，經過這樣重新封裝後，再轉發到那棟樓的接入交換機。

再看最後1個特徵：網橋是一種儲存轉發裝置，用來連線相似的區域網。這些網橋在所有埠上監聽著傳送過來的每一個資料幀，利用橋接表作為該資料幀的轉發依據。橋接表是MAC地址和用於到達該地址的埠號的一個“MAC地址－埠號”列表，它利用資料幀的源 MAC地址和接收該幀的埠號來重新整理。網橋是這樣來使用橋接表的：當網橋從一個埠接收到一個資料幀時，會先重新整理橋接表，再在其橋接表中查詢該幀的目的 MAC地址。如果找到，就會從對應這個MAC地址的埠轉發該幀（如果這個轉發埠與接收埠是相同，就會丟棄該幀）。

如果找不到，就會向除了接收埠以外的其他埠轉發該幀，即廣播該幀。這裡假定在整個轉發過程中，網橋A、B、C和D都在其橋接表中查詢不到該資料幀的目的MAC地址，即這些網橋都不知道應該從哪個埠轉發該幀。當網橋A從上聯埠接收到一個來自上游網路的單播幀時，會廣播該幀，網橋B、C收到後也會廣播該幀，網橋D收到分別來自網橋B、C的這個單播幀，並分別經網橋C、B傳送回網橋 A，到此網橋A收到了該單播幀的兩個副本。在這樣的迴圈轉發過程中，網橋A不停地在不同埠（這時已經不涉及上聯埠了）接收到相同的幀，由於接收埠在改變，橋接表也在改變“源MAC－埠號”的列表內容。前面已經假定網橋的橋接表中沒有該幀的目的MAC地址，網橋A在分別收到這兩個單播幀後，都只能再次向除了接收埠以外的其他埠廣播該幀，故該幀也會向上聯埠轉發。

就每個單播幀而言，網橋A重複前面提到的過程，理論上，廣播一次會收到21個幀，廣播兩次就會收到22個幀，…，廣播到第n次就會收到2n個幀。總之，網橋A照這樣轉發下去，很快就會形成廣播風暴，這個單播幀的副本最終會消耗完100BASE-X埠頻寬。儘管在這期間上聯埠會有許多資料幀在相互碰撞而變的不完整，令Sniffer捕獲不到，但可以想象得到這個單播幀的重複出現次數仍然會非常多。我們再次檢查那些抓回來的資料包，幾乎都發現有當時沒有注意到的重複標誌。按64位元組包長來計算，乙太網交換機的100BASE-FX埠轉發線速可達144000pps。在這種網路環路狀態下， Sniffer完全有可能每秒抓到10萬多個包長為66位元組的資料包。

基於上述理由，由於當時那4臺交換機的橋接表中都沒有該包的目的MAC地址，處於上游網路的這臺匯聚交換機向該大樓傳送了一個TCP請求包後，就會不斷地收到由該大樓接入交換機轉發回來的該TCP包的副本，而且數量非常地多（形成大流量），然而，它並不會把接收到的這些包重發回去；Internet 的網路應用是基於請求/應答模式的，只有傳送/接收兩條通道都暢通，才能進行端到端的通訊。一旦本次網路應用中有一條通道被堵塞了，就會使得該應用因無法進行而結束。網路應用結束後，一般來說，發起請求一方不會就本次應用再次自動發出請求包。於是，在網路環路狀態中普遍會有一條通道有大流量，另一條通道幾乎沒有流量的現象。因為VLAN有隔離廣播域的功能，這些大流量不會穿越網路層，所以不會對匯聚交換機造成很大壓力。事實上，由於這種網路環路是資料鏈路層上的故障，只涉及到源MAC地址和目的MAC地址，不管高層封裝的是什麼型別的包都有可能引起廣播風暴。也就是說，當時用Sniffer抓到各種各樣的資料包都是有可能的。

故障預防

校園網的接入層是面向使用者的網路介面，有許多不可控的成分，情況很複雜，應由專人管理，也應在裝置上給予可靠性保證。本摟接入交換機是可管理型的，有STP功能，其他交換機都是非管理型交換機，沒有STP功能。本來事先在該接入交換機上配置了STP功能，這起網路事故是完全可以避免的，但不知何故沒有這樣做，事後再做只能權當“亡羊補牢”了。由此可見，即使接入交換機開啟了STP功能，下游網路也會因某種原因構成環路，產生廣播風暴，造成對上游網路本VLAN的衝擊，故該接入交換機還應有廣播包抑制功能，以便能將影響限制在區域性範圍內。對於下游網路的交換機同樣有這些需求，只是成本問題而已。一句話，在網路故障排除時，技術和經驗固然重要，但在平時就要注意維護網路的規範連線、落實基本的防範措施更為重要。