轉載：https://blog.csdn.net/ym815753607/article/details/75150593
下面將談談MAC地址學習這塊的東西
PC1要與PC2通信，基於以太網通信中，必須在數據幀中指定目標MAC地址才可以進行正常通信。
假定PC1的arp表項中沒有對應通信的PC2的MAC地址B與IP映射，那么PC1將廣播一個“arp請求”，交換機通過port1 接收到PC1廣播的arp請求報文，通過查找交換機內部的轉發表，發現沒有PC1的MAC地址A與端口1對應關系（假定交換機處於初始化狀態），如表1
表1 初始化的交換機轉發表
於是，交換機會將PC1發來的數據幀的源MAC地址A與端口1的對應關系更新到自己的轉發表中，如表2；
接着交換機會廣播arp請求（flooding）到除了接收端口的的其他端口，如圖2
PC2的情況：
PC2接收到arp請求后，通過對比目的IP與自己IP，如果相等，則會將PC1的MAC地址A與IP映射關系更新到自己的arp表項中，並且會以單播的形式通過端口2返回一個“arp應答”，交換機接收到此arp應答后，會將PC2發來的數據幀的源MAC地址B與對應的端口2更新到自己的轉發表中，如表3
接着交換機查看自己的轉發表發現arp應答目標MAC地址A對應端口1，如表4，
表4 查找MAC：A
於是將此arp應答請求通過端口1發送給PC1，PC1得到arp應答，將PC2 的MAC地址B與IP映射關系更新到自己的arp表項中。PC1發送由鏈路層封裝的數據幀給PC2，如圖3
經過交換機，交換機通過轉發表發現目的MAC地址是B，如表5，對應端口為2，於是通過端口2 將此數據幀傳給PC2。
表5 數據轉發
PC3的情況
PC3也接收到交換機廣播來的arp請求，如圖2，發現目的IP不是自己的IP，於是不作出任何回應
下面是模擬Cisco交換機做的實驗（用CiscoPacket Tracer 做的實驗，不能抓包用wireshark分析）
網絡拓撲如圖1，交換機型號Cisco 2950-24
下圖6是模擬交換機初始化的轉發表，轉發表為空
由於不能通過wireshark抓包分析，我查看PC1 ping PC2的動畫演繹數據報收發過程。事先PC1、PC2 、PC3 arp表項均為空，均如圖7，交換機轉發表MAC表項為空，如圖6
圖7 PC1、PC2和PC3初始arp表項
PC1先廣播arp請求，交換機接收到arp請求后，將PC1發來的arp數據幀中源MAC和端口映射關系更新到自己的轉發表中，如圖8，接着交換機會廣播arp請求（flooding）到除了接收端口的其他端口，如圖9、圖10
圖8 交換機接收到PC1廣播的arp請求
圖9 交換機廣播arp請求
圖10 交換機廣播arp請求的模擬過程
PC2接收到廣播來的arp請求后，查看目標IP發現是自己的IP，於是將PC1的MAC與IP映射關系更新到自己的arp表項中，並單播一個arp應答給交換機，而PC3查看收到的arp請求后查看目標IP並不是自己的IP，於是不做任何回應，如圖11、圖12。
圖11 PC2單播arp應答
交換機接收到arp應答后將源MAC和端口映射關系更新到自己的轉發表中，如圖13，然后將arp應答通過端口1扔給PC1，PC1將PC2的MAC與IP映射更新到自己的arp表項，然后向PC2發送ping包，數據幀到達交換機后，交換機查看轉發表，發現PC2的MAC與端口2的映射關系，於是將數據幀通過端口2扔給PC2，如圖14、圖15和圖16
圖14/15 數據幀轉發模擬過程
圖16 數據幀轉發過程
Cisco交換機轉發表老化時間默認也是300s，PC1與PC2自從上一次通信后沒有進行數據交互，一段時間后查看轉發表項，如圖17
在Cisco這款交換機條件下做了一個錯誤鏈路實驗，PC1的MAC與端口1映射在老化時間內，我斷開PC1與交換機連接，查看交換機轉發表，結果如下圖18，PC1的MAC對應端口映射立即消失了。
作者：saygoodbye_e92e
鏈接：https://www.jianshu.com/p/c0f2ab8756e4
來源：簡書
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。