相信很多人都知道媒體存取控制位址（Media Access Control Address），但是並不完全了解其所牽涉的網路技術範圍，對此本文將介紹MAC的設計格式、產生緣由、如何查找MAC位址，以及在網路中所牽涉的技術範圍。另外，還會介紹交換機是如何透過MAC位址的設計與操作來產生另外一個協定，以便改善整個運作流程，並解決網路迴圈等問題。
交換機在網路拓撲中所造成的問題
大多複雜的網路架構都會使用相同重複的設備來避免某一設備運作失常的情況，交換機設備也是如此。要了解交換機設備的技術，免不了一定要知道這些問題，這樣一來，當發生類似的問題時，才能了解背後真正的原因。
同一個網路中使用多個交換機設備
在許多大型的網路拓撲內，網路管理人員通常會使用一個以上的交換機設備，這樣一來，一旦某些交換機設備運作失常，其他交換機設備就能夠繼續維持整個網路的運作。
以上圖所顯示的網路拓撲為例，在這個網路內使用兩個交換機設備，若交換機A或是交換機B有其中一者運作失常，則另外一台可以馬上取而代之，維持網路運作。
這樣的做法當然是不錯，不過也因此造成其他的問題，可能發生的網路問題有以下三種：
1. 廣播風暴（Broadcast Storm）
2. 發送多個重複資料（Multiple Frame Copies）
3. MAC位址資料庫不一致（MAC Address Table Instability）
接著，就分別針對這三個問題予以介紹。
廣播風暴
如同上一張圖所示，假設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位址還沒有被下面這兩台交換機設備學習到，這裡假設兩台交換機設備上方的埠為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）。
運作於MAC上的STP
STP協定使用MAC位址等資訊來解決剛才上述提到的問題。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。