交換機與VLAN：辦公室太複雜，我要回學校
上一次，我們在宿舍裡組建了一個本地的區域網 LAN，可以愉快地玩遊戲了。這是一個非常簡單的場景，因為只有一臺交換機，電腦數目很少。今天，讓我們切換到一個稍微複雜一點的場景，辦公室。
拓撲結構是怎麼形成的？
我們常見到的辦公室大多是一排排的桌子，每個桌子都有網口，一排十幾個座位就有十幾個網口，一個樓層就會有幾十個甚至上百個網口。如果算上所有樓層，這個場景自然比你宿舍裡的複雜多了。具體哪裡複雜呢？我來給你具體講解。
首先，這個時候，一個交換機肯定不夠用，需要多臺交換機，交換機之間連線起來，就形成一個稍微複雜的 拓撲結構 。
我們先來看 兩臺交換機 的情形。兩臺交換機連線著三個區域網，每個區域網上都有多臺機器。如果機器 1 只知道機器 4 的 IP 地址，當它想要訪問機器 4，把包發出去的時候，它必須要知道機器 4 的 MAC 地址。
於是機器 1 發起廣播，機器 2 收到這個廣播，但是這不是找它的，所以沒它什麼事。交換機 A 一開始是不知道任何拓撲資訊的，在它收到這個廣播後，採取的策略是，除了廣播包來的方向外，它還要轉發給其他所有的網口。於是機器 3 也收到廣播資訊了，但是這和它也沒什麼關係。
當然，交換機 B 也是能夠收到廣播資訊的，但是這時候它也是不知道任何拓撲資訊的，因而也是進行廣播的策略，將包轉發到區域網三。這個時候，機器 4 和機器 5 都收到了廣播資訊。機器 4 主動響應說，這是找我的，這是我的 MAC 地址。於是一個 ARP 請求就成功完成了。
在上面的過程中，交換機 A 和交換機 B 都是能夠學習到這樣的資訊：機器 1 是在左邊這個網口的。當了解到這些拓撲資訊之後，情況就好轉起來。
當機器 2 要訪問機器 1 的時候，機器 2 並不知道機器 1 的 MAC 地址，所以機器 2 會發起一個 ARP 請求。
這個廣播訊息會到達機器 1，也同時會到達交換機 A。這個時候交換機 A 已經知道機器 1 是不可能在右邊的網口的，所以這個廣播資訊就不會廣播到區域網二和區域網三。
當機器 3 要訪問機器 1 的時候，也需要發起一個廣播的 ARP 請求。
這個時候交換機 A 和交換機 B 都能夠收到這個廣播請求。交換機 A 當然知道主機 A 是在左邊這個網口的，所以會把廣播訊息轉發到區域網一。
同時，交換機 B 收到這個廣播訊息之後，由於它知道機器 1 是不在右邊這個網口的，所以不會將訊息廣播到區域網三。
如何解決常見的環路問題？
這樣看起來，兩臺交換機工作得非常好。隨著辦公室越來越大，交換機數目肯定越來越多。當整個拓撲結構複雜了，這麼多網線，繞過來繞過去，不可避免地會出現一些意料不到的情況。其中常見的問題就是環路問題。
例如這個圖，當兩個交換機將兩個區域網同時連線起來的時候。你可能會覺得，這樣反而有了高可用性。但是卻不幸地出現了環路。出現了環路會有什麼結果呢？
我們來想象一下機器 1 訪問機器 2 的過程。一開始，機器 1 並不知道機器 2 的 MAC 地址，所以它需要發起一個 ARP 的廣播。廣播到達機器 2，機器 2 會把 MAC 地址返回來，看起來沒有這兩個交換機什麼事情。
但是問題來了，這兩個交換機還是都能夠收到廣播包的。
交換機 A 一開始是不知道機器 2 在哪個區域網的，所以它會把廣播訊息放到區域網二，在區域網二廣播的時候，交換機 B 右邊這個網口也是能夠收到廣播訊息的。
交換機 B 會將這個廣播息資訊傳送到區域網一。區域網一的這個廣播訊息，又會到達交換機 A 左邊的這個介面。
交換機 A 這個時候還是不知道機器 2 在哪個區域網，於是將廣播包又轉發到區域網二。左轉左轉左轉，好像是個圈哦。
可能有人會說，當兩臺交換機都能夠逐漸學習到拓撲結構之後，是不是就可以了？
別想了，壓根兒學不會的。機器 1 的廣播包到達交換機 A 和交換機 B 的時候，本來兩個交換機都學會了機器 1 是在區域網一的，但是當交換機 A 將包廣播到區域網二之後，交換機 B 右邊的網口收到了來自交換機 A 的廣播包。
根據學習機制，這徹底損壞了交換機 B 的三觀，剛才機器 1 還在左邊的網口呢，怎麼又出現在右邊的網口呢？哦，那肯定是機器 1 換位置了，於是就誤會了，交換機 B 就學會了，機器 1 是從右邊這個網口來的，把剛才學習的那一條清理掉。同理，交換機 A 右邊的網口，也能收到交換機 B 轉發過來的廣播包，同樣也誤會了，於是也學會了，機器 1 從右邊的網口來，不是從左邊的網口來。
然而當廣播包從左邊的區域網一廣播的時候，兩個交換機再次重新整理三觀，原來機器 1 是在左邊的，過一會兒，又發現不對，是在右邊的，過一會，又發現不對，是在左邊的。
這還是一個包轉來轉去，每臺機器都會發廣播包，交換機轉發也會複製廣播包，當廣播包越來越多的時候，按照上一節講過一個共享道路的演算法，也就是路會越來越堵，最後誰也別想走。所以，必須有一個方法解決環路的問題，怎麼破除環路呢？
STP 協議中那些難以理解的概念
在資料結構中，有一個方法叫作 最小生成樹 。有環的我們常稱為 圖 。將圖中的環破了，就生成了 樹 。在計算機網路中，生成樹的演算法叫作 STP ，全稱 Spanning Tree Protocol。
STP 協議比較複雜，一開始很難看懂，但是其實這是一場血雨腥風的武林比武或者華山論劍，最終決出五嶽盟主的方式。
在 STP 協議裡面有很多概念，譯名就非常拗口，但是我一作比喻，你很容易就明白了。
● Root Bridge ，也就是 根交換機 。這個比較容易理解，可以比喻為“掌門”交換機，是某棵樹的老大，是掌門，最大的大哥。
● Designated Bridges ，有的翻譯為 指定交換機 。這個比較難理解，可以想像成一個“小弟”，對於樹來說，就是一棵樹的樹枝。所謂“指定”的意思是，我拜誰做大哥，其他交換機通過這個交換機到達根交換機，也就相當於拜他做了大哥。這裡注意是樹枝，不是葉子，因為葉子往往是主機。
● Bridge Protocol Data Units （BPDU） ，網橋協議資料單元 。可以比喻為“相互比較實力”的協議。行走江湖，比的就是武功，拼的就是實力。當兩個交換機碰見的時候，也就是相連的時候，就需要互相比一比內力了。BPDU 只有掌門能發，已經隸屬於某個掌門的交換機只能傳達掌門的指示。
● Priority Vector，優先順序向量 。可以比喻為實力 （值越小越牛）。實力是啥？就是一組 ID 數目，[Root Bridge ID, Root Path Cost, Bridge ID, and Port ID]。為什麼這樣設計呢？這是因為要看怎麼來比實力。
先看 Root Bridge ID。拿出老大的 ID 看看，發現掌門一樣，那就是師兄弟；再比 Root Path Cost，也即我距離我的老大的距離，也就是拿和掌門關係比，看同一個門派內誰和老大關係鐵；最後比 Bridge ID，比我自己的 ID，拿自己的本事比。
STP 的工作過程是怎樣的？
接下來，我們來看 STP 的工作過程。
一開始，江湖紛爭，異常混亂。大家都覺得自己是掌門，誰也不服誰。於是，所有的交換機都認為自己是掌門，每個網橋都被分配了一個 ID。這個 ID 裡有管理員分配的優先順序，當然網路管理員知道哪些交換機貴，哪些交換機好，就會給它們分配高的優先順序。這種交換機生下來武功就很高，起步就是喬峰。
既然都是掌門，互相都連著網線，就互相傳送 BPDU 來比功夫唄。這一比就發現，有人是嶽不群，有人是封不平，贏的接著當掌門，輸的就只好做小弟了。當掌門的還會繼續發 BPDU，而輸的人就沒有機會了。它們只有在收到掌門發的 BPDU 的時候，轉發一下，表示服從命令。
數字表示優先順序。就像這個圖，5 和 6 碰見了，6 的優先順序低，所以乖乖做小弟。於是一個小門派形成，5 是掌門，6 是小弟。其他諸如 1-7、2-8、3-4 這樣的小門派，也誕生了。於是江湖出現了很多小的門派，小的門派，接著合併。
合併的過程會出現以下四種情形，我分別來介紹。
情形一：掌門遇到掌門
當 5 碰到了 1，掌門碰見掌門，1 覺得自己是掌門，5 也剛剛跟別人 PK 完成為掌門。這倆掌門比較功夫，最終 1 勝出。於是輸掉的掌門 5 就會率領所有的小弟歸順。結果就是 1 成為大掌門。
情形二：同門相遇
同門相遇可以是掌門與自己的小弟相遇，這說明存在“環”了。這個小弟已經通過其他門路拜在你門下，結果你還不認識，就 PK 了一把。結果掌門發現這個小弟功夫不錯，不應該級別這麼低，就把它招到門下親自帶，那這個小弟就相當於升職了。
我們再來看，假如 1 和 6 相遇。6 原來就拜在 1 的門下，只不過 6 的上司是 5，5 的上司是 1。1 發現，6 距離我才只有 2，比從 5 這裡過來的 5（=4+1）近多了，那 6 就直接彙報給我吧。於是，5 和 6 分別彙報給 1。
同門相遇還可以是小弟相遇。這個時候就要比較誰和掌門的關係近，當然近的當大哥。剛才 5 和 6 同時彙報給 1 了，後來 5 和 6 再比較功夫的時候發現，5 你直接彙報給 1 距離是 4，如果 5 彙報給 6 再彙報給 1，距離只有 2+1=3，所以 5 乾脆拜 6 為上司。
情形三：掌門與其他幫派小弟相遇
小弟拿本幫掌門和這個掌門比較，贏了，這個掌門拜入門來。輸了，會拜入新掌門，並且逐漸拉攏和自己連線的兄弟，一起棄暗投明。
例如，2 和 7 相遇，雖然 7 是小弟，2 是掌門。就個人武功而言，2 比 7 強，但是 7 的掌門是 1，比 2 牛，所以沒辦法，2 要拜入 7 的門派，並且連同自己的小弟都一起拜入。
情形四：不同門小弟相遇
各自拿掌門比較，輸了的拜入贏的門派，並且逐漸將與自己連線的兄弟棄暗投明。
例如，5 和 4 相遇。雖然 4 的武功好於 5，但是 5 的掌門是 1，比 4 牛，於是 4 拜入 5 的門派。後來當 3 和 4 相遇的時候，3 發現 4 已經叛變了，4 說我現在老大是 1，比你牛，要不你也來吧，於是 3 也拜入 1。
最終，生成一棵樹，武林一統，天下太平。但是天下大勢，分久必合，合久必分，天下統一久了，也會有相應的問題。
如何解決廣播問題和安全問題？
畢竟機器多了，交換機也多了，就算交換機比 Hub 智慧一些，但是還是難免有廣播的問題，一大波機器，相關的部門、不相關的部門，廣播一大堆，效能就下來了。
就像一家公司，創業的時候，一二十個人，坐在一個會議室，有事情大家討論一下，非常方便。但是如果變成了 50 個人，全在一個會議室裡面吵吵，就會亂的不得了。
你們公司有不同的部門，有的部門需要保密的，比如人事部門，肯定要討論升職加薪的事兒。
由於在同一個廣播域裡面，很多包都會在一個局域網裡面飄啊飄，碰到了一個會抓包的程式員，就能抓到這些包，如果沒有加密，就能看到這些敏感資訊了。
還是上面的例子，50 個人在一個會議室裡面七嘴八舌的討論，其中有兩個 HR，那他們討論的問題，肯定被其他人偷偷聽走了。
那咋辦，分部門，分會議室唄。那我們就來看看怎麼分。
有兩種分的方法，一個是 物理隔離 。每個部門設一個單獨的會議室，對應到網路方面，就是每個部門有單獨的交換機，配置單獨的子網，這樣部門之間的溝通就需要路由器了。路由器咱們還沒講到，以後再說。
這樣的問題在於，有的部門人多，有的部門人少。人少的部門慢慢人會變多，人多的部門也可能人越變越少。如果每個部門有單獨的交換機，口多了浪費，少了又不夠用。
另外一種方式是 虛擬隔離 ，就是用我們常說的 VLAN ，或者叫 虛擬區域網 。使用 VLAN，一個交換機上會連屬於多個區域網的機器，那交換機怎麼區分哪個機器屬於哪個區域網呢？
我們只需要在原來的二層的頭上加一個 TAG，裡面有一個 VLAN ID，一共 12 位。為什麼是 12 位呢？因為 12 位可以劃分 4096 個 VLAN。這樣是不是還不夠啊。現在的情況證明，目前雲端計算廠商裡面絕對不止 4096 個使用者。當然每個使用者需要一個 VLAN 了啊，怎麼辦呢，這個我們在後面的章節再說。
如果我們買的交換機是支援 VLAN 的，當這個交換機把二層的頭取下來的時候，就能夠識別這個 VLAN ID。這樣只有相同 VLAN 的包，才會互相轉發，不同 VLAN 的包，是看不到的。這樣廣播問題和安全問題就都能夠解決了。
我們可以設定交換機每個口所屬的 VLAN。
如果某個口坐的是程式設計師，他們屬於 VLAN 10；如果某個口坐的是人事，他們屬於 VLAN 20；如果某個口坐的是財務，他們屬於 VLAN 30。
這樣，財務發的包，交換機只會轉發到 VLAN 30 的口上。程式設計師啊，你就監聽 VLAN 10 吧，裡面除了程式碼，啥都沒有。
而且對於交換機來講，每個 VLAN 的口都是可以重新設定的。一個財務走了，把他所在的作為的口從 VLAN 30 移除掉，來了一個程式設計師，坐在財務的位置上，就把這個口設定為 VLAN 10，十分靈活。
有人會問交換機之間怎麼連線呢？將兩個交換機連線起來的口應該設定成什麼 VLAN 呢？對於支援 VLAN 的交換機，有一種口叫作 Trunk 口 。它可以轉發屬於任何 VLAN 的口。交換機之間可以通過這種口相互連線。
好了，解決這麼多交換機連線在一起的問題，辦公室的問題似乎搞定了。然而這只是一般複雜的場景，因為你能接觸到的網路，到目前為止，不管是你的桌上型電腦，還是筆記本所連線的網路，對於頻寬、高可用等都要求不高。就算出了問題，一會兒上不了網，也不會有什麼大事。
我們在宿舍、學校或者辦公室，經常會訪問一些網站，這些網站似乎永遠不會“掛掉”。那是因為這些網站都生活在一個叫做資料中心的地方，那裡的網路世界更加複雜。在後面的章節，我會為你詳細講解。
小結
好了，這節就到這裡，我們這裡來總結一下：
● 當交換機的數目越來越多的時候，會遭遇環路問題，讓網路包迷路，這就需要使用 STP 協議，通過華山論劍比武的方式，將有環路的圖變成沒有環路的樹，從而解決環路問題。
● 交換機數目多會面臨隔離問題，可以通過 VLAN 形成虛擬區域網，從而解決廣播問題和安全問題。
本年度最後一場覆蓋 DevOps 全領域的技術大會，包括：精益與敏捷、持續交付/自動化測試、技術運營、高可用架構與微服務、DevSecOps、組織與文化。
18 個分會場，60 餘位全球 DevOps 專家與您暢聊 DevOps 轉型與實踐。
原文釋出時間為：2018-10-29
本文作者：某逆風的後花園
本文來自雲棲社群合作伙伴“ OA==&mid=2651674266&idx=1&sn=bdfe8f2d36958d16ec71c2bad9b777f6&chksm=8bcb9533bcbc1c2551c4cb7581b5f0f3499605547db6413f2f462199f7e88caa45396633db49&scene=0#rd" target="_blank" rel="nofollow,noindex">高效運維 ”，瞭解相關資訊可以關注“ 高效運維 ”。