一、概述
1、ARP作業原理：根據IP找MAC
2、ARP決議分為兩種情況：
-
目的IP與我在同一個網段，ARP直接請求目的IP的MAC地址
-
目的IP與我不在同一個網段，ARP請求自己網關的MAC地址
這篇文章詳細分析了第2種情況，即目的IP與我不在同一個網段時，ARP請求的具體流程，
二、實驗驗證
1、實驗拓撲
此實驗拓撲使用GNS3模擬器搭建的，SW1上配置了2個SVI介面，192.168.10.254和192.168.20.254作為vlan 10、vlan 20 PC的網關，
2、實驗步驟
（1）先看sw1的MAC地址表，所有SVI介面的MAC地址是一樣的！！！
（2）先來聽我分析一下PC1 ping PC3時ARP決議的流程：
-
PC1 ping PC3封裝資料幀時，發現自己本地沒有目的MAC，需要發送ARP請求
-
PC1、PC3不在同一個網段，所以ARP請求的是自己網關的MAC地址，PC1的ARP快取表中沒有自己網關的MAC地址，發送ARP請求報文，源MAC為PC1的MAC，目的MAC為12個F，ARP請求的資料部分：誰是192.168.10.254，把你的MAC發給我
-
SW1收到ARP請求以后，封裝ARP回應報文，將自己的MAC（192.168.10.254的MAC）告訴PC1
-
PC1知道自己網關的MAC以后，重新封裝二層資料幀，源MAC為PC1的MAC，目的MAC為網關的MAC，資料幀發送給SW1
-
資料幀到達SW1以后，目的MAC是自己的，拆掉二層幀頭，查看目的IP為192.168.20.1
-
SW1的ARP快取表中沒有192.168.20.1對應的MAC地址，發送ARP請求，源MAC為PC3網關的MAC（和PC1網關的MAC一致），目的MAC為12個F，ARP請求的資料部分：誰是192.168.20.1，把你的MAC發給192.168.20.254
-
PC3收到ARP請求以后，封裝ARP回應報文，將自己的MAC告訴自己的網關（SW1）
-
SW1收到以后，重新封裝二層資料幀，源MAC為PC3網關的MAC，目的MAC為PC3的MAC
-
資料幀到達PC3，目的MAC是自己的，拆掉二層幀頭，查看目的IP也是自己，拆掉IP頭部，查看目的埠號，最后將資料扔給應用層對應的業務
（3）口說無憑，接下來我們用wireshark抓包驗證我說的對不對~
抓包分析：pc1 ping pc3時（可同時在sw1的f0/1、f0/3，pc1的f0/0，pc3的f0/0開啟抓包一起分析）
-
由于不在同一網段，pc1先請求自己網關192.168.10.254的MAC（在pc1的f0/0介面抓包）
-
在sw1的f0/1介面抓包
-
由于pc1發送的ARP請求是廣播幀，所以sw1也會泛洪到其他介面，但不會收到ARP回應（在sw1的f0/2、f0/3介面抓包）
-
由于sw1的ARP快取表中也沒有pc3的MAC，繼續發送ARP請求pc3的MAC（在sw1的f0/3介面抓包）
-
pc3發送ARP回應報文（在pc3的f0/0介面抓包）
（4）最終sw1的ARP快取表如下
結語：至于 “ 目的IP與我在同一個網段，ARP直接請求目的IP的MAC地址 ” 的情況，大家可以自己動手試一試，最后問大家一個問題：ARP快取表中的條目老化時間是多少呢？MAC地址表中的條目老化時間呢？歡迎大家在評論區留言~
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/283177.html
標籤：其他
上一篇：MySQL冪等復制
下一篇：運維實戰 Nginx配置優化