事情是這樣的，公司內部技術部門一般屬於一個局域網段，我們當然也不例外。如果部門內部人員太多但是又不方便用VLAN隔離的話，一般使用switch或者hub來進行隔離，這種設備是不隔離廣播域的，hub甚至都不隔離沖突域，既然這樣，事故很容易就發生了。 我和部門其它3個人共同接在一個hub上，D-Link的設備，可能是低端的switch，不管它了！不知道怎麼回事，我們這裡的這個hub總是莫名奇妙的出現問題，一下子我們4人都無法正常聯網。起初是以為設備壞了，後來網管給換了一台新的，心想這下子可好了，然而沒過幾天，同樣的事故又發生了，又一次叫來網管，折騰了好一陣子，未果！ 下意識感覺到並不是硬件出了問題，就算是上行網線出了問題，網絡也不會瞬間掛掉，然後莫名其妙的就好了，因此我感覺是協議出了問題，只可惜網絡協議在最開始都是針對最簡單的情況，然後大部分的特性都是事後修補的，因此排查問題特別不便，當然這也給了那些CCIE們黃金鑄成的飯碗... 還是抓包工具出場比較好，在網絡狀況惡化的時候，大量的廣播包和stp包進入本地主機，很顯然，出現了廣播風暴。到底在哪裡出了風暴呢？為何這種風暴只影響我們4個人呢？上個世紀，為了應對廣播風暴，人們提出了STP協議，也就是生成樹協議，這個協議有效的防止了廣播風暴，原理十分簡單，那就是將環路剪斷。然而還有一個事實，那就是交換機可以選擇不開啟STP功能... 哪個交換機會不開啟STP，網管難道這麼X嗎？另外，又有哪個交換機會一會兒開啟又一會兒關閉STP呢？...最終，發現把我的虛擬機關掉，網絡就好了，開啟虛擬機，網絡就瘋掉了。 原來是虛擬機造成的，這下就好辦了，那就是想辦法重現問題。於是在家裡的幾台機器上進行試驗，沒有任何問題...到了公司，一開虛擬機就又掛了。虛擬機裡面到底有什麼？ 原來，為了測試OpenVPN，我在虛擬機裡面部署了一個bridge，然後將兩塊虛擬網卡都加入了這個bridge，而這兩塊虛擬網卡又都是bridge模式的(VMWare中bridge，host-only，nat三種網絡中的一種)，要命的是，兩塊虛擬網卡bridge到了物理機器的同一塊物理網卡上，更要命的是，虛擬機中創建的bridge沒有開啟STP協議！！！ 這樣，在虛擬機網橋的兩塊虛擬網卡和物理主機的那一塊物理網卡之間就構成了一個環，廣播會從一個物理網卡進入，然後再從物理網卡繞出來... 那為何僅僅影響我們4個人呢？實際上我們部門不同辦公區域之間是通過“更高級”的交換機來連接的，這種設備本身就是抑制廣播風暴的能力，請注意，所謂廣播風暴並不僅僅是環路引起的。因此我們4個人的這個小設備如果出了問題，問題是很難擴散的，但是我們的這個小設備就沒有那麼厲害了，它很便宜，也很弱小，本人虛擬機只要一開，其它3個人以及小小交換機就都能了活靶子，交換機哪還有處理其它正常數據包的機會啊！ 本次事故的圖示如下，以備以後再出現類似問題時排錯(紅色的粗線表示了一個環路)：
對這個事情做一下總結是有意義的，排查網絡問題有幾步： 1.先看線纜是不是有問題，比如線皮破損，導體外露，設備掉電等； 2.看直連機器是否暢通； 3.排除軟件問題，比如配置失誤，先看鏈路層配置，再看IP層配置 4.玩虛擬機的時候，一定要慎重網絡方面的配置，雖然虛擬機是虛擬的，但是它實質上在別人看來是完全真實的 雖然本次事件最終是軟件問題導致的，問題深深隱藏在虛擬機中，然而排查問題的時候，切忌先從軟件開始排查。 另外，本次事件還有一個疑點，幕後的神秘家伙還沒有被揪出來，誰那麼神秘呢？原來，當廣播風暴爆發的時候，就會有一台神秘的機器(IP是192.168.0.251，我們網段的IP是192.168.0.0/24)發出大量的STP包，是root通告以及拓撲變更包，我們老大問了一圈都問不出這台機器在哪，也沒有人知道它在哪裡，它確實是存在的，能ping通，還開著telnet 23端口...它在哪？晚上怎麼也睡不著，後來感覺正是它探測出了廣播風暴，然後發來STP包，希望下游交換機趕緊剪枝！它實際上應該是一台管理者或者監督者，如果我沒有猜錯，它應該記錄了大量的審計記錄，然而我可能沒有權限證實這一點。
