消弭網路迴圈 解決多交換器並存問題

廣播風暴

如同上一張圖例所示，假設Server發送一個廣播封包出來，當Server想發送ARP（Address Resolution Protocol） request根據IP查找MAC位址時，這種ARP request就是屬於廣播封包（DHCP也屬於廣播封包的一種）。

接著，當交換器A收到這個廣播之後，如同剛才所說的，會把這個廣播封包Flooding出去，假設交換器A是從Segment 1收到廣播封包，則交換器A會把這個封包從兩個方向再送給交換器B，而交換器B收到這個廣播之後，也會做相同的動作，並把這個廣播封包再送給交換器A。

此時，交換器B也會從另一個方向收到另一次的廣播，因此又會再一次地發送更多的廣播封包，如此一來，即使目的地已經收到廣播封包，但是這樣的無窮迴圈所造成的廣播風暴會繼續，並占據網路頻寬，而且網路上的廣播封包會越來越多，直到整個網路被這樣的廣播封包占滿為止。

這樣的廣播風暴不只會造成網路癱瘓，也會耗盡網路上各個設備的資源，因為此種廣播封包的處理過程需要CPU的處理。解決這個問題的方法，就是避免迴圈的產生（Loop Avoidance），詳細情形將在之後的文章為各位介紹。

發送多個重複性資料

與上面的問題相同，透過上一張圖來解釋這個可能造成的問題。假設左上角的伺服器要發送一個封包給路由器，而此時路由器的MAC位址還沒有被下面這兩台交換器設備學習到，這個封包內的目的地MAC位址當然指定著路由器的MAC位址。

當伺服器送出這個封包之後，路由器因為與伺服器處於同一個網路區段，所以路由器會從Segment 1直接收到這個封包。

另外，這個伺服器也會把這個封包傳送給交換器A，而交換器A收到之後，因為在MAC位址資料庫中找不到相對應的資料，所以會採用Flooding的做法，把這個封包傳送出去。

接著，當交換器B經由Segment 2網段收到由交換器A送過來的封包後，當然也會因為在MAC位址資料庫中找不到相對應的資料，又再次把這個封包Flooding出去。

最後，路由器又會收到一次由交換器B送出的相同封包。這個問題的解決之道和上面的一樣，只須避免迴圈的產生即可。

MAC位址資料庫不一致

MAC位址資料庫不一致的問題，主要是因為上一個問題而產生的。如同上一個問題所談到的範例，假設左上角的伺服器要發送一個封包給路由器，而此時路由器的MAC位址還沒有被下面這兩台交換器設備學習到。

這裡假設圖片中兩台交換器，上面的埠為E0，下面的埠為E1，以方便解釋。這裡取部分圖示來講解。

當伺服器送出要給路由器的封包之後，這兩台交換器設備都是從E0介面收到這個封包，但由於在MAC位址資料庫中找不到相對應的資料，所以都會從E1的介面Flooding出去。

但是同時也學到伺服器的MAC位址，所以兩個交換器的MAC位址資料庫的內容類似於下面這樣的表格（假設伺服器的MAC位址為0260.8C01.0001）。

接著，交換器A會從Segment 2的E1介面收到封包，E1介面就會以為伺服器在Segment 2這邊，於是又會更改MAC位址資料庫中的內容。

而交換器B也會從Segment 2的E1介面收到封包，它的E1介面也以為伺服器在Segment 2這邊，於是又更改了MAC位址資料庫中的內容，此時，這兩個交換器的MAC位址資料庫的內容會被改成：

但事實上，伺服器的實體位置根本就沒有變動過，卻因為收到不應該收到的重複封包，而影響MAC位址資料庫的內容，造成不一致的情況。同樣地，這個問題的方法也是透過迴圈的避免（Loop Avoidance）來解決。

使用多交換器的解決方案

現在大家都了解在同一個網路中使用多個交換器會有什麼問題，接下來最重要的當然就是介紹解決方案。

從以上的問題可以觀察出來，主要的問題都是因為多個交換器會重複扮演對方的角色，而讓整個網路的資料不一致，或是讓原本應該要執行一次的事情變成多次執行。

因此，解決方式就是讓這些交換器能夠互相合作，彼此溝通了解由誰來負責，而最主要的解決方法就是使用STP協定。

STP是Spanning Tree Protocol的縮寫，也是IEEE 802.1d協定。STP原本是由Digital Equipment Corporation所研發的，後來這份研發出來的演算法經由IEEE協會修訂並且訂立成為IEEE 802.1d協定。

這裡要注意的是，原本Digital Equipment Corporation所研發的STP演算法和IEEE 802.1d協定中的演算法並不相同，也無法互相相容。而Cisco交換器設備都是採用802.1d協定的STP。

STP最大的目的就在於避免網路拓樸中的迴圈，網路拓樸中的迴圈如同下圖所示：