VLAN/Trunk以及三層交換

很多時候，如果對技術隻是概要全懂，細節上多個概念混淆，勢必在做具體工作的時候會走很多彎路。比較典型的就是關于VLAN的一些技術細節。在這個主題上，最容易引起混淆的就是VLAN，三層交換以及Trunk的概念，以下是一些個問題點：

1.支援VLAN的交換機一定是三層交換機嗎？

2.Trunk配置了就可以VLAN間通信嗎？

3.Trunk具體怎麼工作的？

4.VLAN間的通信到底是怎麼執行的？

如果說給若幹個純二層環境加上若幹個路由器，我想絕大多數的人都可以設計出一個個完美的互聯互通的網絡，然而加上了VLAN之類的概念，反而被繞暈了，具有諷刺意義的是，VLAN本來就是用來簡化純二層環境+交換機的配置的。是以首先要理清VLAN的基本概念，然後具體VLAN間将如何進行通信就不解自知了。

如果先不提Trunk而純粹的VLAN實際上就是将多個純二層的以太網交換機合并成了一個，用軟體進行控制。合并後的交換機就是支援VLAN的交換機，參與合并的多個實體交換機如今退化成了邏輯意義上的交換機。多個實體交換機并不是傻乎乎的合并後完事，VLAN交換機的另一個意義就是可以通過各種政策指定哪個實體port屬于哪個邏輯交換機，如果讓實體交換機實作這個，就不得不涉及購置，布線等問題，這就說明了軟體真的比硬體更加靈活，以軟體為基準，硬體其實就是固化了的軟體。

        如果想明白VLAN的含義，在Linux上配置幾個Bridge就可以了。我們知道，Linux内置了一個軟Bridge實作，通過brctl可以進行配置，一個單獨的Linux實體主機配置了N塊以太網卡，就可以簡單的模拟VLAN的概念(注意，此時還沒有引入VLAN的本質-Trunk)了：

a.新增一個br0，将網卡1/2/3加進去；

b.新增一個br1，将網卡4/5/6加進去；

c....

d.網卡1連接配接一個純二層交換機1；

e.網卡4連接配接一個純二層交換機2；

f....

這樣Linux主機上就存在了多個Bridge，你可以将Linux主機這個實體的機器視為一個支援VLAN的機器了。

        VLAN交換機是一個純二層的裝置。然而，如果僅僅這樣，那就沒有必要推出VLAN的概念了，VLAN到底和上述的簡單配置有什麼不同呢？這就涉及到了IEEE802.1q标準，請看下節。

如果一個VLAN交換機上配置了兩個VLAN，分别為VLAN1和VLAN2，另外幾台VLAN交換機上可能也需要配置VLAN1和VLAN2，畢竟單獨一台機器的口子有限，是以對于組網，不級聯的拓撲是很少見的，現在關鍵的問題就是需要讓處在不同VLAN交換機的口子可以屬于同一個VLAN，即屬于同一個廣播域。辦法很簡單，那就是每一個VLAN用一個線将兩個VLAN交換機上屬于同一個VLAN的口子連起來，如果兩台交換機上分别有3個VLAN，那就扯3根線...這不得不說是一個好方法，但決不是一個妙方法。對于硬體上的體力活兒，軟體一般都能很好的解決，這一次，又是軟體幫了忙，正如VLAN的概念提出時那樣(見上一節)。

        Trunk标準提出來了，所謂的Trunk就是可以讓多個VLAN在兩個交換機級聯時複用一根線，是以軟體上需要對資料幀做一些文章，以便資料幀到達另一個交換機的時候知道自己屬于哪個VLAN進而限制幀的傳輸域，802.1q正是做這個的，進而這也成了VLAN的核心。Trunk隻是簡化了布線，降低了硬體成本，這是一個通過軟體降低硬體成本的絕好的例子。

        既然Trunk可以通過多個VLAN的資料，那麼實際上Trunk是将廣播域延伸到了另外一台交換機上，而對于LAN，其廣播域延伸到哪裡，LAN也就延伸到了那裡。事實上這并不與VLAN的初衷之一-限制廣播域相沖突，Trunk将廣播透傳的時候是打着VLAN id标記的，也就是說廣播除了可以在Trunk上或者在自己VLAN内部傳輸，是決不會到達其它VLAN裡面的，如果一個廣播到達了這樣一個交換機，其上既沒有别的Trunk口，也沒有廣播攜帶的VLAN id對應的VLAN，那麼廣播也就到此為止而消失了。

        到此為止，絲毫沒有任何第三層的概念出現。

VLAN接口的概念和Linux上Bridge的實作十分相像，就是可以為一個VLAN配置一個或者多個接口，在該接口上可以指定三層的IP位址，在VLAN的某一個口子(實體二層接口)上配置這樣一個VLAN接口(三層接口)實際上就等同于在VLAN的該口子上插入了一台三層裝置，隻是這台裝置是一台虛拟的裝置罷了，另外和真正插一台裝置不同的是，由于它是處在本機内部的，是以它所配置IP位址當然也就屬于本機IP位址了，處在路由表的Local域中。

        了解了這一點就會明白，實際上配置了VLAN接口的VLAN交換機實際上是往純VLAN交換機裡面硬塞了一台三層裝置，二者合而為一，是以更能加深對“VLAN交換機是一個純二層的裝置”這個觀點的認識。

姑且先抛開VLAN的概念，說一下LAN交換機。一般以為LAN交換機是純二層的裝置，可是知道了VLAN接口的概念後，我們發現即使沒有VLAN，也是可以将一台虛拟的三層裝置插入到一個LAN交換機的口子上去的，其實Linux的軟Bridge就是這樣做的，那麼内置了三層虛拟裝置的LAN交換機就有了三層的功能。這是什麼呢？還是以Linux為例，在Linux上配置兩個Bridge，分别為br0，br1，在br0上配置IP位址1.1.1.1/24，在br1上配置IP位址2.2.2.2/24，我們就可以看到br0标示的一個LAN上的流量可以通過br0的IP位址被路由到br1，反之，br1标示的LAN流量也可以通過br1的IP位址路由到br0，這是什麼？這就是三層交換機，一個将路由器接口變成交換機接口的路由器，這部三層交換機上擁有兩組LAN接口，雖然可以略見VLAN的概念，但是沒有任何标準說這個三層交換機上的兩組LAN就是兩個VLAN。

        可見，三層交換機可以和VLAN沒有關系。

從上述第4節可以看出，三層交換機可以和VLAN沒有關系，然而實際情況下，三層交換機一般都支援VLAN，為何裝置廠商要如此做呢？這涉及到一個工業設計的問題(沒有畢業的大學年代學習工業設計，大專年代學習了網絡~~)，工業上的設計主要關注産品的使用而不是理論上的合理性，是以将VLAN引入第4節的“兩組LAN”是最合适不過的了。

        另外，三層交換機本質上還是偏重于“交換機”而不是“三層”，交換機的特征就是交換，所謂的交換是一個快速轉發的概念，基本都是使用硬體晶片完成的，大量的存儲晶片以空間換時間完成快速交換，這得益于以太網幀頭的簡單易操作性以及LAN交換機設計時關注了基于源MAC的自動學習和基于目标MAC的轉發，之是以能如此還是因為以太網是一個BMA，即廣播網絡，到底資料應該由誰接收不是交換機決定的，而是各個端點主機決定的，這樣的話交換機就可以模糊的進行轉發，做到盡可能的精确-通過源MAC/端口學習，大不了就廣播。這就是以太網交換的特征，三層交換機可以利用以太網交換的大量存儲晶片用來存儲IP層的路由結果，利用以太網快速交換的思想用來進行三層轉發，資料包的第一次通過還是要走三層，這相當于一次學習的過程，類似以太網的MAC/端口學習，以後的結果就可以存儲于ASCI了，這樣就完成了快速轉發。

這個問題的答案鋪天蓋地，然而内容也是千篇一律，很少有人研究其背後的原因。既然以太網三層交換機可以做到一次路由多次轉發，那麼為何不再WAN上使用呢？如果僅僅是因為WAN不一定是以太網的話，那大可為了性能在WAN上引入以太網技術，這并不是主要原因，實際上，如果再深入一點看一下WAN上的路由器和接入層路由器的路由表就會恍然大悟了，WAN路由器上的表項數量十分龐大，且在BGP的影響下雖不頻繁但是還是會有重新整理，如果使用硬體來轉發的話，光是對存儲空間的需求就是一個挑戰，三層交換機的快速轉發實際上用到了cache的概念，有cache就會有沖突，特别在WAN環境下，IP位址的變動，可達性資訊的變動會導緻大量的cache沖突，是以三層交換機帶來的收益會被馬上抵消，另外WAN環境實際上用不到很多交換機口子，是以三層交換機内部背闆晶片布線對于WAN環境是不合理的。其實用不着為WAN的性能擔心，WAN路由器早就使用了類似Cisco CEF的快速轉發技術了。

        三層交換機的使用場合是單個小型機構内部，因為這種地方的特定IP位址幾乎不會變動，路由相對穩定，IP位址總量也不多，且路由基本都能彙聚，正好符合cache最優化使用的原則，三層交換機用武之地正在于此。

這個問題的方案也是鋪天蓋地，答案同樣千篇一律。VLAN間的通信方式被總結出來有兩種：1.使用單臂路由方式；2.使用三層交換方式。這好像是從CCNP/CCIE或者華為的HCSE的考試指南中流出來的，如果背下來當然是有用的，當初我考HCSE的時候還背了呢。學習到了一定程度就應該抛棄答案，回歸本質。兩個VLAN間的通信其實就是兩個LAN間的通信，兩個LAN間的通信需要一個網關來路由，那麼VLAN間通信也就需要一個網關來路由了，這個網關的選擇就多樣了，可以選擇VLAN接口，可以選擇路由器等等，最終具體屬于一個VLAN的主機在通路另一個VLAN的主機時如何能尋址到這個三層接口，那也有很多選擇，VLAN的access鍊路上幀保持原樣，流量若要跨越交換機的級聯線，那麼需要通過Trunk鍊路，最終總能找到這個下一跳三層接口。

        VLAN間的通信就這麼簡單，不要被支援VLAN，支援Trunk的三層交換機這個All for one的雜燴概念迷住了雙眼。

 本文轉自 dog250 51CTO部落格，原文連結:http://blog.51cto.com/dog250/1268905