相信很多人都知道媒體存取控制位址（Media Access Control Address），但是並不完全了解其所牽涉的網路技術範圍，對此本文將介紹MAC的設計格式、產生緣由、如何查找MAC位址，以及在網路中所牽涉的技術範圍。另外，還會介紹交換機是如何透過MAC位址的設計與操作來產生另外一個協定，以便改善整個運作流程，並解決網路迴圈等問題。
交換機學習MAC位址的過程
剛剛提到交換機設備會把Frame內來源端的MAC位址與埠的對應表記錄到MAC資料庫中，而這資料庫所能記錄的筆數和設備的型號有關，例如Cisco Catalyst交換機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」。
經由Hub的Frame篩選過程
假設目前在Cisco交換機設備和一般PC端之間架設Hub設備，而這台Cisco交換機設備已經學到A和B兩台電腦MAC位址和埠的對應關係，如下圖所示。
A想送Frame給B，一開始，A會把Frame送給Hub，而Hub因為沒有辦法像交換機設備可以學習MAC位址，所以為了能夠送達目的地，Hub會把這個Frame做Flooding，送往所有的埠，用亂槍打鳥的心態傳送Frame。
這樣一來，B在不需要Cisco交換機轉送Frame的情況下就可以收到由A發送過來的Frame，此時Cisco交換機設備收到這個Frame之後，會怎麼辦呢？答案是不會再經由原來的埠送回給Hub。
廣播與群播的轉送過程
即使交換機設備已經學習完整個網路各個電腦的MAC位址與交換機設備的埠之對應關係，對於廣播與群播的封包而言，也是都會用Flooding的方式來轉送，算是比較特別的案例。
不過，也是因為廣播與群播所代表的MAC位址，根本不可能存在於真正的網路之中，例如廣播的MAC位址是FF.FF.FF.FF.FF.FF，所以在找不到這個MAC位址的情況下，MAC資料庫中根本不知道廣播與群播的MAC位址要送往哪裡，因為無從學習起，所以就會用Flooding的方式來解決。