交換機mac表的獲取？

當一個交換機收到一個數據幀的時候，會查看自己的mac表，如果mac表中沒有數據幀的源mac和目的mac，則會將源mac加入mac表，並且廣播這個數據幀。
那麼廣播的這個數據幀的源mac和目標mac是什麼，是否源mac是交換機的mac，目標mac是ff.ff.ff。
如果是，那麼收到的廣播幀的設備怎麼知道是要找它的，是不是通過在設備的網路層進行ip比對。

---

交換機上電啟動之後，MAC地址表如初生嬰兒的大腦，一片空白，好在交換機勤於學習，怎麼學習呢？

第一步：MAC地址學習過程
每次在一個埠接收到一個以太幀，都要先學習幀頭的源MAC，如果該MAC地址在MAC地址表不存在，記錄到MAC地址表，並啟動一個300秒的定時器，類似這樣表項：

MAC 埠號 超時時間
X 0/1 300

如果該MAC地址X在MAC地址表存在，刷新超時時間為300秒。

如果300秒內沒有流量刷新，該表項將會被刪除。

以上是交換機學習MAC的過程，切記，是通過源MAC地址來學習。

第二步：以太幀的轉發過程
根據以太幀的目的MAC地址，來匹配MAC地址表，會有以下幾種情況：

1）匹配到特殊MAC地址
比如生成樹地址「01:80:C2:00:00:00」，將以太幀直接給STP模塊處理

2）匹配到MAC地址的一個表相
從對應的埠發送出去

3）沒有匹配的表相
從所有的埠（除了接收到此幀的埠）發送出去，通常稱為泛洪。

以上所有過程，都假設沒有配置VLAN，如果配置了VLAN，學習過程、轉發過程都需要檢查幀頭802.1Q的VLAN ID欄位，泛洪也只在屬於該VLAN ID的埠上泛洪。

由於「FF.FF.FF.FF.FF.FF」是廣播地址，永遠都不會出現在源MAC欄位，所以永遠不會被交換機學習到。

「FF.FF.FF.FF.FF.FF」只能出現在目的MAC欄位，所以交換機永遠都匹配不到，只有泛洪，該VLAN里的所有埠都可以接收到，此乃廣播。

當交換機無法匹配到一個非「FF.FF.FF.FF.FF.FF」的地址時，也是採用廣播泛洪的方式，對於交換機是一個巨大的處理負擔，這就是常被提到的廣播風暴。

造成廣播風暴的原因很多，網路拓撲不穩定，造成MAC地址表超時時間大大縮短，很多表項因而被刪除，造成流量因為MAC地址表空而被迫廣播泛洪，所以保持二層網路穩定也可以避免廣播風暴。

---

我說說我的看法，說的有問題 歡迎大家指正。首先要區分廣播報文 和 泛洪報文的 區別：
廣播報文是因為主機不知道目的mac，然後發起目的地址為全f的廣播報文，交換機收到之後只是按照規則將這個報文廣播到入介面之外所有的介面。而泛洪報文也是由主機發起，但是是單播報文，報文封裝的目的mac 就是真實目的地的mqc地址，交換機收到這個報文發現目的mac不存在於表項中，只能將這個報文複製多份發出去，當然除了入介面，並且發送之前對報文不做修改，只有目的主機擁有報文中的目的mac，才會接受報文處理，其他主機都會丟棄報文，這種情況類似於hub。能工作但是效率較低，但是這種主機先於交換機知道知道目的mac的情況應該很少見，因為主機要想知道目的mac就要發arp廣播，arp reply 在返回的時候經過交換機的時候已經被交換機處理而先於主機獲得目的mac，除非你在主機上配置靜態mac。

---

CCNA視頻看5遍，一切都豁然開朗了。（CCNA PPT裡面講得很明白的，所有的的回答都是止痛，不能治痛）

當一個交換機收到一個數據幀的時候，會查看自己的mac表，如果mac表中沒有數據幀的源mac和目的mac，則會將源mac加入mac表，並且廣播這個數據幀。

二層交換機對 未知單播，會 「 洪泛 」 ，但不是廣播，洪泛 幀結構/源目地址完全不變。

別把ARP協議與二層交換原理搞混了，前者就PC做的事情，後者是交換機的職責。

附 二層交換原理圖，出自CCNA：


---

「並且廣播這個數據幀」
里的廣播只是每個埠轉發的意思
並不是FF:FF:FF:FF:FF:FF 的意思

---

看了你的提問，感覺你和三層跨網段轉發弄混了
從交換機的交換原理上說一下，這個問題就好理解了
你說的這個問題，交換機這個概念，用來在一個廣播域內控制數據幀走向。那麼怎麼控制數據幀走向呢？

交換機有一個mac表(這個表是怎麼來的先不說)大概就是這樣

mac1a出口為port1
mac1b出口為port1
mac2a出口為port2

交換機先提取所收到的數據幀的目的mac，然後根據目的mac查找mac表
1.如果mac表中能找到對應mac(mac為mac1a/mac1b/mac2a)，則將數據幀只從對應的port發出
2.如果找不到對應mac(比如mac為mac2b)，則交換機不知道這個數據幀應該從哪個port發出，這時候交換機採取的策略是從同vlan里的所有port都發出這個數據幀(交換機的廣播動作，從vlan內所有port發出同樣的數據幀，但不會改動這個數據幀)，以犧牲網路性能的方式確保這個數據幀最大限度可能被正確的接受者收到。至於其他原本不需要的設備也會接收到這個數據幀？其他設備自行處理。
整個過程中不需要改變數據幀中的mac。
另外，可以看出，在這個過程中，不需要有交換機的mac參加，所以概念上交換機可以沒有mac。交換機的mac/ip是為了方便用戶能用telnet之類的通信手段管理交換機。

如果想知道交換機怎麼維護mac表，搜索「交換機mac表地址學習過程」

---

默認你說的都是乙太網交換機。

你要先搞明白一件事情，不是交換機發出的這個廣播包，交換機不管產生廣播包(
這裡先不討論智能交換機自己有irb之類的情況)，只是把收到的廣播包繼續泛洪出去而已。所以這個廣播包原來的源mac地址是啥那麼交換機泛洪的時候就還是啥。

目的mac地址是ff ff ff ff ff ff。

至於目的主機為啥知道這個廣播是給我的？我還要繼續解封裝看目的ip啊，如果目的ip是我那就說明這個廣播包實際上是想給我的。

以上說的都是廣播包的情況，但是單播包也一樣。

目的主機回應廣播或者單播後，交換機將此mac地址加入mac表中。

---

那個叫泛洪flood 不叫廣播

---

如果源主機不知道目的主機的mac地址，應該是ARP廣播請求得到這個目的Mac。目的主機判斷是否是發給自己的，就是通過目的IP地址是否是自己的地址來決定的，如果是就響應請求發回自己的mac地址給源主機，同時一來一去交換機都學習到了源主機和目的主機mac並添加到mac表。

---

這個洪泛的幀還是剛剛找不到目的mac對應port的那個幀，只不過被洪泛傳輸了。源mac和目的mac不變化，剛剛請教了同事，他在某傑設備測試中遇到過這種情況。linuxbridge好像也是這麼處理的。

---

在二層交換機看來，報文分為三種：
a.已知單播
b.未知單播
c.廣播

已知單播是說交換機上存在FDB表項。當交換機收到一個已知單播時，根據DMAC查到出口埠，則轉發該報文。

未知單播表示交換機上不存在該FDB表，交換機也不知道報文發送到哪個埠，於是他在該VLAN的所有埠裡面（除了源埠）做了一個泛洪（flood，形式和廣播一樣，但不叫廣播），即在所有埠上轉發該報文。

廣播報文直接在該廣播域上的所有埠（除了源埠）上發送一遍。

二層交換前後DA/SA不發生改變。

---

推薦閱讀：