對以太網交換機常見問題詳解
我們把該接入以太網交換機上的網線都拔掉，以太網交換機的100BASE-FX端口轉發線速可達144000pps。在這種網絡環路狀態下，用戶可以輕輕松松的工作和生活了。
一天，我們在校園網的網絡運行性能監控平臺上發現某棟摟的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字節的數據包
【編輯推薦】
