交換機與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">高效運維 ”,瞭解相關資訊可以關注“ 高效運維 ”。