時(shí)間：2015-06-28 00:00:00 來源：IT貓撲網(wǎng) 作者：網(wǎng)管聯(lián)盟 我要評(píng)論(0)
?? 以太網(wǎng)中的交換機(jī)之間存在不恰當(dāng)?shù)亩丝谙噙B會(huì)造成網(wǎng)絡(luò)環(huán)路，如果相關(guān)的交換機(jī)沒有打開STP功能，這種環(huán)路會(huì)引發(fā)數(shù)據(jù)包的無休止重復(fù)轉(zhuǎn)發(fā)，形成廣播風(fēng)暴，從而造成網(wǎng)絡(luò)故障。我們在校園網(wǎng)的維護(hù)過程中多次遇到過這種故障，其中有一次排除故障的過程令我們印象深刻。????
?? 故障描述
?? 一天，我們在校園網(wǎng)的網(wǎng)絡(luò)運(yùn)行性能監(jiān)控平臺(tái)上發(fā)現(xiàn)某棟摟的VLAN有問題——其接入交換機(jī)與校園網(wǎng)的連接中斷。檢查放置在網(wǎng)絡(luò)中心的匯聚交換機(jī)，測得與之相連的100BASE－FX端口有大量的入流量，而出流量卻非常少，顯得很不正常。然而這臺(tái)匯聚交換機(jī)的性能似乎還行，感覺不到有什么問題。于是，我們在這臺(tái)匯聚交換機(jī)上鏡像這個(gè)異常端口，用協(xié)議分析工具Sniffer來抓包，最多時(shí)每秒鐘居然能抓到10萬多個(gè)。對(duì)這些數(shù)據(jù)包進(jìn)行簡單分析，我們發(fā)現(xiàn)其中一些共同特征。
?? 1、絕大部分的包長為62個(gè)字節(jié)（加上4字節(jié)的差錯(cuò)檢測FCS域即為66個(gè)字節(jié)），TCP狀態(tài)為SYN；
?? 2、源IP為其他網(wǎng)段的IP、目的IP均為該樓網(wǎng)段的IP；
?? 3、盡管源IP地址不同，但源MAC地址卻是一樣的；
?? 4、目的IP地址和目的MAC地址與在這臺(tái)匯聚交換機(jī)上綁定該樓VLAN的IP—MAC參數(shù)一致；
?? 5、實(shí)際的數(shù)據(jù)流向（流入）與這些數(shù)據(jù)包中的源IP地址和目的IP地址所確定的流向（流出）相反。
?? 當(dāng)時(shí)，我們急于盡快搶修網(wǎng)絡(luò)，沒去深究這些數(shù)據(jù)包的特征，只看到第1點(diǎn)就以為網(wǎng)絡(luò)受到不明來歷的Syn Flood攻擊，估計(jì)是由一種新網(wǎng)絡(luò)病毒引起，馬上把這臺(tái)匯聚交換機(jī)上該端口禁用掉，以免造成網(wǎng)絡(luò)性能的下降。
?? 故障排除
?? 為了能在現(xiàn)場測試網(wǎng)絡(luò)的連通性，在網(wǎng)絡(luò)中心，我們把連接那棟大樓接入交換機(jī)的多模尾纖經(jīng)光電轉(zhuǎn)換器用雙絞線連到一臺(tái)PC上，并將其模擬成那個(gè)問題 VLAN的網(wǎng)關(guān)。然后，到現(xiàn)場找來大樓網(wǎng)管員，想讓他協(xié)助我們盡快把感染了未知病毒的主機(jī)查到并隔離。
?? 據(jù)大樓網(wǎng)管員反映，昨天網(wǎng)絡(luò)還算正常，不過，當(dāng)時(shí)本大樓某部門正在做網(wǎng)絡(luò)調(diào)整，今天上班就發(fā)現(xiàn)網(wǎng)絡(luò)不行了，不知跟他們有沒有關(guān)系。我們認(rèn)為調(diào)整網(wǎng)絡(luò)應(yīng)該跟感染病毒關(guān)系不大。在大樓主配線間，我們把該接入交換機(jī)上的網(wǎng)線都拔掉，接上手提電腦，能連通網(wǎng)絡(luò)中心的測試主機(jī)。我們確認(rèn)鏈路沒問題后，每次將剩余網(wǎng)線數(shù)量的一半插回該交換機(jī)，經(jīng)測試沒問題則如是繼續(xù)下去，否則換插另一半，逐漸縮小懷疑有問題網(wǎng)線的數(shù)量。
?? 我們最終找到一條會(huì)引起問題的網(wǎng)線，只要插上這根網(wǎng)線，該大樓網(wǎng)絡(luò)就會(huì)與模擬網(wǎng)關(guān)中斷連接。經(jīng)大樓網(wǎng)管員辨認(rèn)，這條網(wǎng)線是連接昨天在做網(wǎng)絡(luò)調(diào)整的那個(gè)部門的。他還說以前該部們拉了一主一備兩條網(wǎng)線，應(yīng)該還有一條，并親自在那臺(tái)交換機(jī)上把另一條找了出來。隨意插上這兩條網(wǎng)線中的一條，網(wǎng)絡(luò)沒問題，但只要同時(shí)插上，就有問題，哪有在一臺(tái)交換機(jī)上同時(shí)插上兩條網(wǎng)
?? 線才會(huì)激活網(wǎng)絡(luò)病毒的SYN Flood攻擊的？這時(shí)我們倒是覺得這種現(xiàn)象更像是網(wǎng)絡(luò)中有環(huán)路。我們到了那個(gè)部門發(fā)現(xiàn)有三臺(tái)非管理型交換機(jī)，都是串在一起的，然而其中兩臺(tái)又分別通過那兩條網(wǎng)線與接入交換機(jī)相連，從而導(dǎo)致了網(wǎng)絡(luò)環(huán)路。顯然是施工人員對(duì)網(wǎng)絡(luò)拓?fù)洳磺宄?，?dāng)時(shí)大樓網(wǎng)管員有事外出，就自以為是地把線接錯(cuò)了，從而造成了這起網(wǎng)絡(luò)事故。原因找到就好辦了，只需拔掉其中一條上聯(lián)網(wǎng)線即可恢復(fù)網(wǎng)絡(luò)連通。 經(jīng)過一番周折，網(wǎng)絡(luò)恢復(fù)了正常，但我們還一直在想，是什么干擾了我們的判斷呢？
?? 故障分析
?? 一起典型的網(wǎng)絡(luò)環(huán)路故障，用協(xié)議分析工具Sniffer抓了這么多的數(shù)據(jù)包，經(jīng)過一番分析卻沒看出問題來。顯然，第一眼看到大量的SYN包讓我們產(chǎn)生了錯(cuò)覺，想當(dāng)然地就以為是SYN Flood攻擊。事后，我們就這起網(wǎng)絡(luò)環(huán)路故障排除過程做了檢討，重新仔細(xì)地分析抓回來的這些數(shù)據(jù)包，據(jù)此解釋一下前面提到這些數(shù)據(jù)包所具有的5個(gè)共同特征，以便今后遇到同類問題時(shí)能及時(shí)作出正確的反應(yīng)。
??
?? 先看前4個(gè)特征：匯聚交換機(jī)是網(wǎng)絡(luò)層設(shè)備，該大樓所屬VLAN的網(wǎng)絡(luò)層接口就設(shè)置在這臺(tái)匯聚交換機(jī)上，出于實(shí)施網(wǎng)絡(luò)管理策略的需要，對(duì)已注冊或沒注冊的 IP地址都進(jìn)行了MAC地址的綁定。TCP連接要經(jīng)過3次握手才能建立起來，在這里發(fā)起連接的SYN包長度為28個(gè)字節(jié)，加上14個(gè)字節(jié)的以太幀頭部和 20個(gè)字節(jié)的IP報(bào)頭，由Sniffer捕獲到的幀長度共為62個(gè)字節(jié)（不包含4字節(jié)的差錯(cuò)檢測FCS域）。恰巧當(dāng)時(shí)訪問該VLAN的單播幀是來自外網(wǎng)的 TCP請(qǐng)求包，根據(jù)以太網(wǎng)橋的轉(zhuǎn)發(fā)機(jī)制，通過CRC正確性檢測后，因已做靜態(tài)ARP配置，這臺(tái)匯聚交換機(jī)會(huì)將該單播幀的源MAC地址轉(zhuǎn)換成本機(jī)的MAC地址，其目的MAC地址依據(jù)綁定參數(shù)來更換，并重新計(jì)算CRC值，更新FCS域，經(jīng)過這樣重新封裝后，再轉(zhuǎn)發(fā)到那棟樓的接入交換機(jī)。
?? 再看最后1個(gè)特征：網(wǎng)橋是一種存儲(chǔ)轉(zhuǎn)發(fā)設(shè)備，用來連接相似的局域網(wǎng)。這些網(wǎng)橋在所有端口上監(jiān)聽著傳送過來的每一個(gè)數(shù)據(jù)幀，利用橋接表作為該數(shù)據(jù)幀的轉(zhuǎn)發(fā)依據(jù)。橋接表是MAC地址和用于到達(dá)該地址的端口號(hào)的一個(gè)"MAC地址－端口號(hào)"列表，它利用數(shù)據(jù)幀的源MAC地址和接收該幀的端口號(hào)來刷新。網(wǎng)橋是這樣來使用橋接表的：當(dāng)網(wǎng)橋從一個(gè)端口接收到一個(gè)數(shù)據(jù)幀時(shí)，會(huì)先刷新橋接表，再在其橋接表中查找該幀的目的MAC地址。如果找到，就會(huì)從對(duì)應(yīng)這個(gè)MAC地址的端口轉(zhuǎn)發(fā)該幀（如果這個(gè)轉(zhuǎn)發(fā)端口與接收端口是相同，就會(huì)丟棄該幀）。
?? 如果找不到，就會(huì)向除了接收端口以外的其他端口轉(zhuǎn)發(fā)該幀，即廣播該幀。這里假定在整個(gè)轉(zhuǎn)發(fā)過程中，網(wǎng)橋A、B、C和D都在其橋接表中查找不到該數(shù)據(jù)幀的目的MAC地址，即這些網(wǎng)橋都不知道應(yīng)該從哪個(gè)端口轉(zhuǎn)發(fā)該幀。當(dāng)網(wǎng)橋A從上聯(lián)端口接收到一個(gè)來自上游網(wǎng)絡(luò)的單播幀時(shí)，會(huì)廣播該幀，網(wǎng)橋B、C收到后也會(huì)廣播該幀，網(wǎng)橋D收到分別來自網(wǎng)橋B、C的這個(gè)單播幀，并分別經(jīng)網(wǎng)橋C、B傳送回網(wǎng)橋 A，到此網(wǎng)橋A收到了該單播幀的兩個(gè)副本。
?? 在這樣的循環(huán)轉(zhuǎn)發(fā)過程中，網(wǎng)橋A不停地在不同端口（這時(shí)已經(jīng)不涉及上聯(lián)端口了）接收到相同的幀，由于接收端口在改變，橋接表也在改變"源MAC－端口號(hào)"的列表內(nèi)容。前面已經(jīng)假定網(wǎng)橋的橋接表中沒有該幀的目的MAC地址，網(wǎng)橋A在分別收到這兩個(gè)單播幀后，都只能再次向除了接收端口以外的其他端口廣播該幀，故該幀也會(huì)向上聯(lián)端口轉(zhuǎn)發(fā)。
?? 就每個(gè)單播幀而言，網(wǎng)橋A重復(fù)前面提到的過程，理論上，廣播一次會(huì)收到21個(gè)幀，廣播兩次就會(huì)收到22個(gè)幀，…，廣播到第n次就會(huì)收到2n個(gè)幀?？傊?，網(wǎng)橋A照這樣轉(zhuǎn)發(fā)下去，很快就會(huì)形成廣播風(fēng)暴，這個(gè)單播幀的副本最終會(huì)消耗完100BASE-X端口帶寬。盡管在這期間上聯(lián)端口會(huì)有許多數(shù)據(jù)幀在相互碰撞而變的不完整，令Sniffer捕獲不到，但可以想象得到這個(gè)單播幀的重復(fù)出現(xiàn)次數(shù)仍然會(huì)非常多。我們再次檢查那些抓回來的數(shù)據(jù)包，幾乎都發(fā)現(xiàn)有當(dāng)時(shí)沒有注意到的重復(fù)標(biāo)志。按64字節(jié)包長來計(jì)算，以太網(wǎng)交換機(jī)的100BASE-FX端口轉(zhuǎn)發(fā)線速可達(dá)144000pps。在這種網(wǎng)絡(luò)環(huán)路狀態(tài)下， Sniffer完全有可能每秒抓到10萬多個(gè)包長為66字節(jié)的數(shù)據(jù)包。
?? 基于上述理由，由于當(dāng)時(shí)那4臺(tái)交換機(jī)的橋接表中都沒有該包的目的MAC地址，處于上游網(wǎng)絡(luò)的這臺(tái)匯聚交換機(jī)向該大樓發(fā)送了一個(gè)TCP請(qǐng)求包后，就會(huì)不斷地收到由該大樓接入交換機(jī)轉(zhuǎn)發(fā)回來的該TCP包的副本，而且數(shù)量非常地多（形成大流量），然而，它并不會(huì)把接收到的這些包重發(fā)回去；Internet 的網(wǎng)絡(luò)應(yīng)用是基于請(qǐng)求/應(yīng)答模式的，只有發(fā)送/接收兩條信道都暢通，才能進(jìn)行端到端的通信。
?? 一旦本次網(wǎng)絡(luò)應(yīng)用中有一條信道被堵塞了，就會(huì)使得該應(yīng)用因無法進(jìn)行而結(jié)束。網(wǎng)絡(luò)應(yīng)用結(jié)束后，一般來說，發(fā)起請(qǐng)求一方不會(huì)就本次應(yīng)用再次自動(dòng)發(fā)出請(qǐng)求包。于是，在網(wǎng)絡(luò)環(huán)路狀態(tài)中普遍會(huì)有一條信道有大流量，另一條信道幾乎沒有流量的現(xiàn)象。因?yàn)閂LAN有隔離廣播域的功能，這些大流量不會(huì)穿越網(wǎng)絡(luò)層，所以不會(huì)對(duì)匯聚交換機(jī)造成很大壓力。
?? 事實(shí)上，由于這種網(wǎng)絡(luò)環(huán)路是數(shù)據(jù)鏈路層上的故障，只涉及到源MAC地址和目的MAC地址，不管高層封裝的是什么類型的包都有可能引起廣播風(fēng)暴。也就是說，當(dāng)時(shí)用Sniffer抓到各種各樣的數(shù)據(jù)包都是有可能的。
?? 故障預(yù)防
?? 校園網(wǎng)的接入層是面向用戶的網(wǎng)絡(luò)界面，有許多不可控的成分，情況很復(fù)雜，應(yīng)由專人管理，也應(yīng)在設(shè)備上給予可靠性保證。本摟接入交換機(jī)是可管理型的，有STP功能，其他交換機(jī)都是非管理型交換機(jī)，沒有STP功能。本來事先在該接入交換機(jī)上配置了STP功能，這起網(wǎng)絡(luò)事故是完全可以避免的，但不知何故沒有這樣做，事后再做只能權(quán)當(dāng)"亡羊補(bǔ)牢"了。
?? 由此可見，即使接入交換機(jī)打開了STP功能，下游網(wǎng)絡(luò)也會(huì)因某種原因構(gòu)成環(huán)路，產(chǎn)生廣播風(fēng)暴，造成對(duì)上游網(wǎng)絡(luò)本VLAN的沖擊，故該接入交換機(jī)還應(yīng)有廣播包抑制功能，以便能將影響限制在局部范圍內(nèi)。對(duì)于下游網(wǎng)絡(luò)的交換機(jī)同樣有這些需求，只是成本問題而已。一句話，在網(wǎng)絡(luò)故障排除時(shí)，技術(shù)和經(jīng)驗(yàn)固然重要，但在平時(shí)就要注意維護(hù)網(wǎng)絡(luò)的規(guī)范連接、落實(shí)基本的防范措施更為重要。
關(guān)鍵詞標(biāo)簽：交換機(jī),網(wǎng)絡(luò)環(huán)路
相關(guān)閱讀
熱門文章
提示dns服務(wù)錯(cuò)誤怎么辦 dns錯(cuò)誤問題多種解決方法
“無法瀏覽網(wǎng)頁” 十招解決疑難雜癥
路由器無線不能上網(wǎng)等故障排除
解決VPN路由設(shè)置不能訪問外網(wǎng)的問題
人氣排行 解決VPN路由設(shè)置不能訪問外網(wǎng)的問題 登錄SSH服務(wù)器失敗問題的分析及解決 光纖上網(wǎng) 路由器設(shè)置頁面進(jìn)不去怎么辦 核心交換機(jī)故障現(xiàn)象及解決辦法 無線網(wǎng)卡連接不上怎么辦_無線網(wǎng)卡連接不上解決方法 路由設(shè)置不當(dāng) 導(dǎo)致VPN無法訪問外網(wǎng) 提示dns服務(wù)錯(cuò)誤怎么辦 dns錯(cuò)誤問題多種解決方法 徹底避免環(huán)路問題 正確配置交換機(jī)步驟