網管人NetAdmin
2012/4/3

維持網路運作的要角

了解交換器如何傳遞封包

胡凱捷
交換器是網路中一個相當重要的設備,肩負著將網路封包送到正確目的地的任務。本文將講述交換器的主要功能、各種傳送Frame的運作模式以及如何學習來源端MAC位址等等,並且說明交換器在虛擬區域網路內的運作原理。
網路交換器(Switch)設備在網路中負責傳遞網路封包。在傳遞網路封包之前,交換器必須先知道目的地在哪裡、網路封包應該要從哪一個埠傳送出去。為了達到這樣的功能,交換器必須學習並且記錄哪個埠可以到達哪些網路位置,而這個學習過程牽扯到傳遞網路封包的方式。
接著,還會介紹更複雜的環境:虛擬區域網路(VLAN)。交換器若處於多個VLAN的情況時,如何傳遞資料呢?畢竟有VLAN的環境和沒有VLAN的環境還是不一樣,而VLAN剛好又是交換器一個很重要的功能。因此,本文會詳細說明交換器網路設備在不同的網路環境中如何傳遞網路封包。
交換器的主要功能
用於乙太網路中的交換器能夠增加網路的可用頻寬,同時也能根據發送過來的網路封包,分析其中的來源端與目的端的MAC位址,製作出MAC位址表,並藉由這樣的MAC位址表正確地轉發網路封包。
交換器雖然都是運作在網路七層架構當中的第二層,但是由於交換器擁有較高速的內部結構以及擁有比較多的埠介面,所以與傳統的閘道器(Bridge)比較起來,交換器能夠提供更多的網路流量。
關於MAC位址的學習,交換器會從它們的埠上監聽所傳進來的Frame(經過交換器的網路封包稱之為Frame),檢測這些資料的來源端MAC位址,並且把MAC位址與埠號的對應關係記錄下來,儲存在本地端的MAC資料庫內,而這份MAC資料庫通常稱之為MAC Address Table或是Content-addressable Memory (CAM) Table。
當交換器再次收到Frame時,會先到MAC資料庫中查看從哪個埠出去可以到達這個目的地MAC位址所指定的機器,如果目的端的MAC位址能夠在MAC資料庫內被找到,則這個Frame就只會從學習到的埠號轉發出去。
倘若在MAC資料庫中找不到這樣的對應關係,這個Frame就會從所有其他的埠轉發出去(來源埠除外)。這裡所指的Frame,有人用中文稱它為「幀」,但是筆者建議還是使用原有英文來指稱會比較好。
交換器網路設備傳送Frame的模式
交換器在傳送Frame時,有「Store and Forward」、「Cut Through」、「Fragment-Free」三種可用的運作模式,以下分別加以介紹。
Store and Forward模式
在Store and Forward模式下,交換器會先把Frame完整地接收下來,然後才進行轉發的動作。因為在這個模式下,整個Frame都會被讀取,所以來源端及目的端的MAC位址都能夠被讀取。
另外,CRC(Cyclic Redundancy Check)的錯誤檢查動作也會被執行,並採用相關的篩選動作,之後才會進行轉發。如果CRC的檢查失敗,這個Frame就會被遺棄。這種轉送模式雖然能夠確保Frame中資料的正確性,但是也比較費時,其所需要的延遲時間與Frame的資料長度有關。
Cut-Though模式
在Cut-Through轉送模式中,就不會像Store and Forward模式這樣的麻煩,一旦接收到Header之後,看到目的端的MAC位址,就會馬上執行Frame的轉送動作。
因此,Cut-Though模式比Store and Forward模式快上許多,而且Cut-Though模式所需要的時間,並不會因為Frame的長度變長就跟著變多,因為閘道器及交換器只想取得目的端的MAC位址,而目的端的MAC位址都一定會存放在Frame資料內最前面的Header之內。
不過,雖然有些交換器在這種模式下只想讀取MAC位址,但還是有某些交換器會讀取CRC值並記錄下錯誤數目,不過一旦有錯誤發生,在這種模式下,是不會將這個Frame遺棄,而是針對設定值自動或手動切換成Store and Forward模式。
這種可以允許切換的Cut-Though又稱為Adaptive Cut-Though模式,此種模式結合了Cut-Though模式與Store and Forward模式的優點。
Fragment-Free模式
在Fragment-Free模式中,交換器只會讀取Frame的前64個bytes(這也是乙太網路中Frame最小的資料單位),而最主要原因是,在乙太網路中碰撞幾乎都是發生在前64個bytes之中,因此一旦發生碰撞,就會產生小於64個bytes的Frame資料。所以,交換器經由讀取前64個bytes資料,就可以初步篩選經由碰撞所產生的Frame資料。
Fragment-Free模式的速度比Cut-Though更快,而且一旦發現有錯誤的Frame,將會把這樣的Frame丟棄,這是與Cut-Though模式不同的地方。這個模式也稱為Modified Cut-Though模式。


交換器如何學習來源端MAC位址
剛剛提到交換器會把Frame內來源端的MAC位址與埠的對應表記錄到MAC資料庫中,而這資料庫所能記錄的筆數和設備的型號有關,例如Cisco Catalyst Switch 2950系列就能記錄8,192筆。
假設現在有一台Cisco交換器,其中四個埠分別接到不同的電腦,其各個電腦的MAC位址如下圖所示:


當交換器第一次開機後,MAC位址資料庫是空的。也因此,當交換器收到Frame之後,一定會從所有其他的埠轉發出去,除了來源埠之外。這種轉發到除來源埠以外的其他埠的動作,稱為「Flooding」。用這種Flooding的動作來轉送Frame很沒有效率,因為會浪費很多網路頻寬。
假設現在A發送一個Frame要送給D,如下圖所示,則這個Frame會經由E0介面傳送給中間這個Cisco交換器,假設這台Cisco交換器是使用Store and Forward模式,則這個Frame到了Cisco交換器之後會先存放在暫時緩衝區中。


接著,因為這台交換器還沒有學到這個MAC位址應該要送往哪個埠,所以預設上就會採用Flooding的作法,透過其他的埠把這個Frame轉送出去,而在收到這個Frame的同時,這台交換器同時也學到一件事情:從E0這個埠出去可以到達A這台機器(因為交換器能夠經由E0介面收到由A這台機器的MAC位址所發送的Frame)。
因此,這個新學習到的資訊就成為MAC資料庫的第一筆資料。此時MAC資料庫中可能就有以下這樣的資料:


在MAC資料庫中的每一筆資料並非永遠存在,一旦某筆資訊在MAC位址資料庫中經過300秒沒有更新,就會被強制移除,除非這筆資料的MAC位址所對應的電腦在300秒內繼續發送Frame到交換器上,這筆資訊的計時器才會重新開始計算。
假設接著C想發送Frame給A,如下圖所示。這個Frame會經由E4這個埠傳送到中間這個交換器。緊接著,Cisco交換器會去查看MAC位址資料庫中是否可以找到A這台機器的MAC位址資訊。


因為剛才這台交換器已經學到可以透過E0這個埠找到A,所以這個Frame就只會經由E0這個埠傳送出去,這是因為C送給A而學習到C的MAC位址與E2的關係。
此時,MAC資料庫中的資料就會存放以下的對應關係:


這樣的學習模式會一直進行,等到所連接之網段上的所有MAC位址都被學習過,這台交換器就能夠完完全全做到智慧型的轉發動作(Intelligent Forwarding)。
不僅如此,這樣的學習也有助於Frame的篩選動作,因為Frame只會發送到真正需要送往的埠而已,這樣就可以節省整體的網路頻寬,這種篩選動作稱為「Frame Filtering」。
經由集線器的Frame篩選過程
假設目前在Cisco交換器和一般PC端之間架設集線器(Hub)設備,而這台Cisco交換器已經學到A和B兩台電腦的MAC位址和埠的對應關係,如下圖所示。


若A想送Frame給B,一開始,A會把Frame送給集線器,而集線器因為沒有辦法像交換器一樣可以學習MAC位址,所以為了能夠送達目的地,集線器就會把這個Frame做Flooding,送往所有的埠,用亂槍打鳥的心態傳送Frame。
這樣一來,B在不需要Cisco交換器轉送Frame的情況下就可以收到由A發送過來的Frame,此時,Cisco交換器收到這個Frame後,將不會再經由原來的埠送回給集線器。
廣播與群播的轉送過程
即使交換器已經學習完整個網路中各個電腦的MAC位址與交換器的埠的對應關係,對於廣播與群播的封包而言,也都會用Flooding的方式來轉送,算是比較特別的案例。
不過也是因為廣播與群播所代表的MAC位址,根本不可能存在於真正的網路中,例如廣播的MAC位址是FFFF.FFFF.FFFF,所以在找不到這個MAC位址的情況下,MAC資料庫內根本不知道廣播與群播的MAC位址要送往哪裡,因為無從學習起,所以就會用Flooding的方式來解決。
交換器在VLAN之中的傳輸封包方式
一般來說,若在眾多的交換器之間架設VLAN,則只有在同一個VLAN中的電腦才可以互相傳遞資料。在交換器內部,事實上是透過限制資料的轉送來達到這種VLAN的資料傳遞過程。
剛提到當交換器收到資料之後,會根據學習過的MAC位址對應表來決定資料要送往哪個埠,如果沒有學習過的話,則預設會Flooding到所有的埠,這是因為預設上所有的埠都是屬於預設的VLAN中,換句話說,所有的埠都屬於同一個VLAN,因此這樣的Flooding動作不會有什麼問題。
但如果有分割VLAN的話,就不能這樣做,因為這樣做就會把某個VLAN的資料送往其他的VLAN,因此在這種情況下,交換器會了解哪些埠是屬於哪個VLAN,而會限制Flooding的時候只能送往同一個VLAN之中。
而當VLAN的資料要跨越多個交換器傳遞到其他交換器所連接的同一個VLAN時,就必須使用Trunk技術。因為交換器之間只會用一條網路線連接起來,而這條網路線必須要能傳遞承載所有VLAN的資料。為了達到這種需求,在設定這種交換器之間的連線時,就必須設定成Trunk類型。
Trunk的分類
Trunk主要分成兩種協定:802.1Q協定和ISL協定。簡單來說,Trunk會在資料中增加一個標籤,也就是Tag,用來表示目前這份資料是屬於哪一個VLAN。
貼上標籤之後,再把這份資料傳到另一台設備,另一台設備收到之後,再根據這個標籤得知這份資料是屬於哪個VLAN,然後把這份資料送往所屬的VLAN。這就是Trunk主要的工作。
所以,這個Trunk必須要能夠傳送所有VLAN的資料,反正也不會搞混,因為都會在資料上貼上標籤。接著,就分別針對這兩種Trunk協定探討它們之間的不同之處。
802.1Q協定 IEEE 802.1Q協定通常在VLAN中用來連接多個交換器與路由器(Router)設備,而Cisco的設備在Fast Ethernet和Gigabit Ethernet的介面上都支援IEEE 802.1Q協定。
基本上,每一個套用802.1Q協定的埠都會被指定成Trunk類型,而所有在Trunk上的埠都隸屬於native VLAN當中,預設上,是這樣沒錯,但是管理者還是可以指定到不同的VLAN中。
而native VLAN是設備上預設的VLAN,一開始拿到Cisco交換器時,所有的埠都會被指派到native VLAN中,所以全部的埠都可以互相通訊,因為都是屬於同一個VLAN。
native VLAN有一個作用,就是所有沒有被貼上標籤的資料都會被送往這個native VLAN。每個VLAN都會有一個ID,用來區分各個VLAN,而native VLAN的預設ID就是VLAN 1。
還有一點值得注意的是,只有802.1Q協定才有native VLAN,ISL並沒有native VLAN。也因為沒有貼上標籤的資料都會在native VLAN上遊走,所以交換器設備也不會在native VLAN內所傳遞的資料中貼上標籤了。
接著來看看下面這個範例,就可以參透native VLAN的所有觀念。
假設現在要架設三個VLAN,其VLAN ID分別是VLAN 1、VLAN 2及VLAN 3,其中,VLAN 1是native VLAN,之間用兩台Cisco交換器連接著,在Cisco交換器中間有一台集線器,如下圖所示:


其中IP為10.1.*.*是處於VLAN 1中,而IP為10.2.*.*則是處於VLAN 2中,IP為10.3.*.*則被分派於VLAN 3內。因為10.1.1.1和10.1.1.3都屬於native VLAN,所以由10.1.1.1和10.1.1.3互相傳遞的資料都不會被貼上標籤,因此這樣的資料也可以被10.1.1.2收到。
至於資料封包的標籤位置,則是置放在封包中間。一個標準的IP封包依序包含以下各個欄位:
1. 目的端位址資訊,占封包的6個位元組。
2. 來源端位址資訊,占封包的6個位元組。
3. 用來指明資料長度或乙太網路種類的資訊,占封包的2個位元組。
4. 資料本身,占封包的46∼1,500個位元組。
5. FCS,占封包的4個位元組。
貼上標籤後,整個資料封包會變成:
1. 目的端位址資訊,占封包的6個位元組。
2. 來源端位址資訊,占封包的6個位元組。
3. 802.1Q協定專用標籤,占封包的4個位元組。
4. 用來指明資料長度或是乙太網路種類的資訊,占封包的2個位元組。
5. 資料本身,占封包的46∼1,500個位元組。
6. FCS,占封包的4個位元組。
由上面可以看出,802.1Q協定會把標籤插在資料封包的中間位置,並增加4個位元組的空間,因此,整個資料長度最長會是1,522個位元組。而標籤中的內容包含乙太網路類型、PRI值、Token Ring專屬封裝用的Flag以及VLAN ID。
ISL協定
另外一種協定就是ISL,ISL是Inter-Switch Link的縮寫。ISL協定是Cisco設備專用的,但也不是每一款Cisco設備都有支援,只有某幾款Cisco設備才支援ISL協定。
ISL協定運作於OSI網路七層架構的第二層,作法就是在前面增加一段表頭,並在最後面新增一段CRC。由於ISL協定與任何協定無關,因此ISL協定能夠封裝任何種類的上層協定資料。
ISL協定所新增的表頭大小為26個位元組,而最後面新增的CRC大小為4個位元組。在前面的表頭中包含VLAN ID和BPDU資訊,當然還有包含很多其他的資訊,例如埠的ID、SA的前三個位元組等等,由於過於繁雜,這裡就不一個個詳細介紹。
若要使用ISL協定,網路中每一台設備都必須做好正確的ISL設定才行,因為ISL協定所使用的資料封包長度超過乙太網路所能接受的長度,所以一旦不支援ISL協定的設備收到這樣的封包,會認為是錯誤的封包而直接遺棄。乙太網路的正確封包大小是64到1,518個位元組。
802.1Q與ISL協定的比較
ISL協定是用硬體來實作,因此所能支援的VLAN個數依照硬體的好壞而定,速度也是依照硬體的等級而定,與802.1Q協定不同。802.1Q協定是在軟體上處理的,所以速度想必一定比較慢。
另外,當決定要使用哪一種的協定時,也要考慮到整個網路的設備廠牌,若使用ISL協定,則代表所有的設備都一定要採用Cisco的設備,因為這是Cisco專屬的協定。兩者各有好壞,端由網路管理人員來決定。
802.1Q和ISL協定最大的不同,在於它們的標籤置放方式不同,這點請讀者注意,尤其是要準備CCNA認證的讀者,Trunk一向都是考試的重點之一。
交換器可能造成的問題
大多數複雜的網路架構都會使用相同重複的設備來避免某一設備運作失常的情況,交換器也是如此。要了解交換器的技術,免不了一定要知道這些問題,如此一來,當發生類似的問題時,才能了解背後真正的造成原因為何。
同一個網路中使用多個交換器
許多大型的網路拓樸中,網路管理人員通常會使用一個以上的交換器,這樣一來,當某些交換器運作失常,其他交換器也能繼續維持整個網路的運作,例如下圖所顯示的網路拓樸:


在這個網路中使用兩個交換器,若Switch A或Switch B其中一個運作失常,則另外一台可以馬上取而代之,維持網路運作。這樣的作法當然是不錯,不過也因此造成其他的問題。可能造成的網路問題有三個:
1. 廣播風暴(Broadcast Storm)
2. 發送多個重複資料(Multiple Frame Copies)
3. MAC位址資料庫不一致(MAC Address Table Instability)
以下就分別針對這三個問題予以介紹。
廣播風暴
如同上一張圖例所示,假設伺服器(Server)發送一個廣播封包出來,例如當伺服器想發送ARP(Address Resolution Protocol) Request來根據IP查找MAC位址時,這種ARP request就是屬於廣播封包。另外,DHCP也是屬於廣播封包的一種。
接著,當Switch A收到這個廣播之後,如同剛才所說的,會把這個廣播封包Flooding出去,假設Switch A是從Segment 1收到廣播封包,則Switch A會把這個封包從兩個方向再送給Switch B,而Switch B收到這個廣播後,也會做相同的動作,並把這個廣播封包再送給Switch A。
此時,Switch B也會從另一個方向收到另一次的廣播,因此又會再一次地發送更多的廣播封包,如此一來,即使目的地已經收到廣播封包,但是這樣的無窮迴圈所造成的廣播風暴會繼續,並占據著網路頻寬,而且網路上的廣播封包會越來越多,直到整個網路被這樣的廣播封包占滿為止。
這樣的廣播風暴不只會造成網路癱瘓,也會耗盡網路上各個設備的資源,因為這種廣播封包的處理過程需要CPU來處理。解決這個問題的方法就是避免迴圈的產生(Loop Avoidance)。
發送多個重複資料
和上面的問題一樣,可透過上一張圖例來解釋這個可能造成的問題。假設左上角的伺服器要發送一個封包給路由器,而此時路由器的MAC位址還沒有被下面這兩台交換器學習到,這個封包中的目的地MAC位址當然指定著路由器的MAC位址,而當伺服器送出這個封包後,路由器因為和伺服器處於同一個網路區段,所以路由器會從Segment 1直接收到這個封包。
另外,這個伺服器也會把這個封包傳送給Switch A,而Switch A收到之後,因為在MAC位址資料庫內找不到相對應的資料,所以會採用Flooding的作法,把這個封包傳送出去。
接著,當Switch B經由Segment 2網段收到由Switch A送過來的封包之後,也因為在MAC位址資料庫中找不到相對應的資料,又會再次把這個封包Flooding出去。
最後,路由器又會收到一次由Switch B送出的相同封包。這個問題的解決之道和上面的一樣,只要避免迴圈產生即可。
MAC位址資料庫內容不一致
這個問題主要是因為上一個問題而產生的。如同上一個問題所談到的範例,假設左上角的伺服器要發送一個封包給路由器,而此時路由器的MAC位址還沒有被下面這兩台交換器學習到。這裡假設圖片中,兩台交換器上面的埠為E0,下面的埠為E1,以方便解釋。這裡取部分圖例來講解:


當伺服器送出要給路由器的封包之後,這兩台交換器都是從E0介面收到這個封包,但由於在MAC位址資料庫中找不到相對應的資料,所以都會從E1的介面Flooding出去。但是,因為同時也學到伺服器的MAC位址,所以兩個交換器的MAC位址資料庫的內容類似於下面這樣的表格(假設伺服器的MAC位址為0260.8C01.0001):


接著,Switch A會從Segment 2的E1介面收到封包,E1介面就會以為伺服器在Segment 2這裡,於是又會更改MAC位址資料庫中的內容,而Switch B也會從Segment 2的E1介面收到封包,它的E1介面也會以為伺服器在Segment 2這邊,於是又會更改MAC位址資料庫中的內容。此時,這兩個交換器的MAC位址資料庫的內容會被改成:


但事實上,伺服器的實體位置根本就沒有變動過,卻因為收到不應該收到的重複封包而影響MAC位址資料庫的內容,造成不一致的情況。
同樣地,解決這個問題的方法也是透過迴圈的避免(Loop Avoidance),而STP(Spanning Tree Protocol)就是用來避免網路迴圈的問題發生。
結語
讀完這篇文章之前,也許很多讀者原本就大略耳聞交換器在網路中所扮演的角色,但是可能對於運作的細節並不清楚。
這一篇文章針對交換器如何在網路之中傳遞網路封包做了完整的介紹,並且針對有無VLAN來分別介紹。最後也介紹了交換器是否可能因為在學習網路封包目的地的過程中而造成的問題和解決方案,希望這些對讀者們有所幫助。
http://www.netadmin.com.tw