代理ARP實驗

聲明：由於此文章本人先發表於網易，後由網易copy過來，故若出現圖片無法顯示現象，可到如下地址閱讀此文章：http://zqdiadra.blog.163.com/blog/static/656710672010921101237/，另附上本人制作的PDF實驗筆記。

實驗目的：

TCP/IP卷一中代理ARP一節下有這麼一段話：主機123.1.1.1需要向主機34.1.1.4發送數據包，但是它沒有配置缺省網關信息，因而也就不知道如何到達路由器。這時它可以向34.1.1.4發送一個ARP請求；本地路由器收到這一請求，並且路由器知道如何到達網絡34.1.1.0，因此路由器將回復以上請求，其中把自己的數據鏈路標識符作爲ARP回覆數據包中的硬件地址。

對於該段話描述，本人產生很大的疑問，後經網上搜索一些資料，又產生更多的疑問：

沒有缺省網關的主機是否會發出ARP請求？

如果按書中所說，主機只需要將ARP請求發出來，接着就會得到網關路由器的應答，也就意味着主機能形成所有IP與網關路由器接口的MAC地址的對應關係。這也就是說，當主機想要進行數據通信的時候，它的數據幀中的所有報頭信息是完全的，它只要像扔出ARP請求數據那樣扔出其它數據包，它就是能正常上網的。但在實際情況中，未配置缺省網關的主機是無法上網的。這兩種結果是相互矛盾的。
後經向老師請教，遂得知該段話並不嚴謹，實際主機是不會發出ARP請求的，但用路由器模擬的主機是可以的。
關閉代理後，不同網段是否能正常通信？

既然通過代理ARP可以是兩個網段通信，那麼當關閉代理ARP時，兩個網段是否能正常通信？此時，數據幀裏的信息怎麼打？
ARP請求是否能跨網段傳遞？

資料顯示，在以太網協議中規定，同一局域網中的一臺主機要和另一臺主機進行直接通信，必須要知道目標主機的MAC地址。而在TCP/IP協議棧中，網絡層和傳輸層只關心目標主機的IP地址。這就導致在以太網中使用IP協議時，數據鏈路層的以太網協議接到上層IP協議提供的數據中，只包含目的主機的IP地址。於是需要一種方法，根據目的主機的IP地址，獲得其MAC地址。這就是ARP協議要做的事情。所謂地址解析（address resolution）就是主機在發送幀前將目標IP地址轉換成目標MAC地址的過程。另外，當發送主機和目的主機不在同一個局域網中時，即便知道目的主機的MAC地址，兩者也不能直接通信，必須經過路由轉發纔可以。所以此時，發送主機通過ARP協議獲得的將不是目的主機的真實MAC地址，而是一臺可以通往局域網外的路由器的某個端口的MAC地址。於是此後發送主機發往目的主機的所有幀，都將發往該路由器，通過它向外發送。這種情況稱爲ARP代理（ARP Proxy）。
疑問點是，如果ARP不能跨網段傳遞，那麼在和遠程主機通信時，數據幀中的信息又是怎麼打的？

因此實驗目的主要是爲了解決上述疑問，另外通過抓包學習ARP結構，推測數據的路由轉發過程。

實驗設計：

用路由器R1、R2、R4模擬主機，R3爲路由器。

研究123.1.1.0/24網段內，ARP表的形成過程及ARP數據包信息結構。
開啓R3的代理功能、和關閉R3的代理功能，ARP表是否有區別。
開啓所有路由器的路由功能，研究無路由協議時ARP表狀況；有路由協議時，開啓和關閉R3代理功能兩種情況下，ARP數據表情況。

實驗拓撲圖：

實驗過程：

基本的配置信息我就不寫了，現在撿要點說。

主機在沒有缺省網關的情況下是不會發出數據包的，下圖是抓取的虛擬機中windows主機以太網接口數據。

    簡要說明一下該過程，在黃色信息以上，是配置有缺省網關的時候，192.168.100.0網段是可以ping通的，黃色信息之後是刪掉缺省網關信息之後的ping，此時，192.168.100.0網段就不通了，未抓取到去往192.168.100.0的ping包，說明主機根本未產生該種數據包，也爲進行過ARP的查詢，因此也說明了卷一中那段話是有問題的。
    然後再說一下no ip routing這條命令，這是用路由器R1、R2、R3模擬主機時所使用的，這條命令也許就是路由器模擬主機與真實主機之間區別的關鍵命令。no ip routing就是禁用了路由器的路由功能。當網絡設備接收到數據的時候，首先就是要進行路由匹配來進行選路的，如果沒有匹配項，數據將會被丟棄。因此，在使用no ip routing命令模擬主機之後，路由器將不能在進行路由匹配工作，從嚴格意義來說，應該是任何數據包都無法發出的，這就與要用其模擬主機的目的不符。所以，對no ip routing的理解應該是：對於該路由器自身產生的流量，無條件發出，對於接收到的流量，不進行路由轉發。這就解釋了爲什麼主機在沒有缺省網關的情況下不能正常通信，而路由器模擬的主機在沒有缺省網關的情況下可以正常通信。
    另外，根據資料，真實的主機自身是存在主機路由表（可參考http://wenku.baidu.com/view/e648e67101f69e314332944a.html）的，該表項中包括本機迴環地址、本機局域網網段路由等，因此，在不配缺省網關的情況下，主機無法與外界進行通信。同時這也表明，數據轉發的第一步是要進行路由匹配。
在R1上ping R2的地址，進行抓包，獲取ARP包信息如下：

    上面的小框爲簡明信息，包括源地址、目標地址、協議、簡明信息。在下面的具體數據信息中，二層頭部中的源地址爲ca00.04a0.0000，目標地址爲二層廣播地址，上層的ARP信息中表明其是一個請求信息，硬件地址類型爲以太網、協議地址類型爲IP、硬件地址長度爲6字節、協議地址長度爲4字節、操作類型爲請求。注意下面的目的MAC地址，此處爲全0，與二層頭部中使用廣播地址不同。

    ARP應答消息抓包如下：

    應答時使用的是單播地址，且在ARP包信息中，源/目地址均會明確的註明。
在R1、R2、R4爲模擬主機，R3開啓代理ARP功能的情況下，首先看看arp表的情況，如下圖：

    34.1.1.0/24網段的MAC地址均爲R3 F0/0口的MAC地址，對於R3的兩個接口進行抓包，其結果如下：

    R3 F0/0口

    這是一個請求34.1.1.4的MAC地址的ARP請求包，再看隨後的第59條ARP的應答信息，表明34.1.1.4的MAC地址爲ca04.04a0.0000，該地址是R3 F0/0接口的MAC地址，即使用了代理ARP。

    R3 F1/0

    由此可看出，當數據跨網段傳遞後，路由器並未告訴目的地址34.1.1.4，123.1.1.1要查詢其MAC，反而表明是它自己（34.1.1.3）要查詢其MAC。再隨後的兩條ARP信息，是因爲ping需要回包，而R4當時並沒有123.1.1.1的MAC地址故發送了請求，同樣路由器返回了自己接口的MAC地址。
下面再ping一下該網段內不存在的地址，假設爲34.1.1.5，抓包如下：

    R1 F0/0

    R3 F1/0


    由抓包結果可知，對於34.1.1.0/24網段內的一個不存在的主機地址，路由器依然會告訴123.1.1.1自身接口的MAC地址，然後在34.1.1.0/24網段內發送ARP請求。因此這種情況下，R1並沒有丟棄數據，數據被髮送到R3後才被丟棄。如圖中的ping包，R1已形成數據包，併發送了ping請求，達到R3後，因R3查不到34.1.1.5的MAC，故丟棄了該數據包。
    對於實際的情況而言，如果R1收不到ARP應答，則後續包就不會產生，如下圖：

    上圖中均爲由ping引起的路由器在另一網段內的ARP請求信息，而ping包卻未形成。
當關閉代理ARP功能之後，34.1.1.0/24網段便不再可達，如下圖，R1的ARP請求無人應答：

3、4、5說明一條ARP信息是無法跨網段傳播的。
在全部開啓路由功能的情況下，無論是否開啓R3打代理ARP功能，R1的arp表項只有3條，而且一直是同網段內的三條，如下圖所示：

    R1上抓包結果如下所示：

    此圖爲在R1上多次使用clear arp-cache命令後所產生的結果，仔細觀察可發現，這些包與傳統的ARP請求應答包還是有很多不同的，詳見第8點。
    在隨後的ping實驗中，無路是否開啓代理ARP功能，R1去往34.1.1.0/24的數據目的MAC地址也一直都是R3 F0/0接口的MAC地址。如圖：
接下來，在開啓路由功能的情況下，用R1 ping 34.1.1.5，抓包結果如下：
    R3 F0/0

    R3 F1/0


    同樣可看出，R1的形成了ping包並全部發送給了R3，R3發出了ARP請求，但無人應答，因此丟棄了全部的ping請求。

    在此，首先說明一個我目前仍然存在的疑問：那就是在隨後的開啓路由功能的實驗中，R1去往34.1.1.4的數據包的二層頭部中使用的還是R3 F0/0接口的MAC地址，這與代理ARP很相似，因爲如果不這樣做的話，二層頭部信息將會是不正確的，所以我懷疑它是不是真正的代理ARP的情況。
    結合一下路由轉發規則和數據封裝過程說明一下。首先，數據自上而下進行封裝，跳過上幾層不考慮，它需要一個三層的頭部，其中需要源、目IP地址信息，然受是一個二層頭部，需要源、目的硬件地址信息。當路由器收到一個需要路由的數據包時，首先他會解封並讀取數據中二層地址信息，確定該信息是不是轉給它自己的（不是自己的硬件地址將丟棄）（由此也可知爲什麼在5中，當關閉代理ARP的時候，兩網段便不能再通信了），然後讀取三層地址信息，查詢自己的路由表，確定需要將數據從哪裏轉發出去，然後重新生成二層頭部將數據轉發出去。如下圖所示，在路由器路由表中，可查詢到去往某個網段的下一跳及出接口信息，基於這些信息可在CAM表中查詢到與之相對應的MAC地址信息。也就是說，當R1要向34.1.1.4發送數據時，在三層頭部中封裝的信息爲：34.1.1.4（目）、123.1.1.1（源），在查詢過路由表後，確定下一跳爲123.1.1.3，因此將其硬件地址信息封裝在二層頭部中，由下一個路由器決定該數據的後續處理過程。所以，以這麼一個過程來看的的話，路由環境下的這種情況不能被稱爲代理ARP。另外幾點佐證是：首先，在開啓路由功能的情況下，ARP表中不會有其他網段的ARP映射信息，同樣主機在配置缺省網關後，也不會存在其它網段的ARP映射關係，換句話說，就是這種情況下，是不可能得到第3點中的那張代理ARP表的；再者，無論R3 F0/0上的代理功能是否開啓，它均不會對兩個網段之間的通信產生任何影響，包括誘發新的數據包的產生（這一點是比較有說服力的理由）。
    但是話又說回來，如果不將路由環境下的情況視爲代理ARP，那麼代理ARP的功能似乎只能存在於“實驗情況”以及卷一中的“透明路由器”情況之下，這又似乎讓它缺乏實際的存在價值。所以，這讓我懷疑我的判斷。
在開啓路由功能後，抓到了很奇怪的ARP包，如下：

    首先看簡明信息，123.1.1.1的MAC地址是ca00.04a0.0000，操作類型字段也表明這是一個ARP應答消息，但是在此之前，卻沒有關於123.1.1.1的ARP請求信息。作爲一個應答ARP消息，其二層頭部目的地址卻是廣播地址，另外，ARP信息中源、目的IP均爲123.1.1.1，目的MAC地址爲ffff.ffff.ffff。很像是一個無故ARP，但是卻與無故ARP的特定有着很大的區別。首先無故ARP是一個ARP請求消息，而此包是一個應答包；其次，在ARP消息字段中目的MAC地址應該是0000.0000.0000，而此處是ffff.ffff.ffff；再者，無論是開啓還是關閉無故ARP功能，使用clear arp-cache命令後都能抓到該包。同樣，123.1.1.2與123.1.1.3也都發出過該包。在某人博客上，將其也歸爲無故ARP，但是未作詳細解釋，故不是很有說服力，詳見http://zhangxiaoshi82.blog.163.com/blog/static/43100801200782065734617/，該blog中包含有無故ARP的抓包圖（我並未抓到無故ARP的包）。
    隨後，在與老師探討過該問題後，我便再次進行實驗，將路由器一個個分別配好，經抓包發現，當路由器接口開啓後，它便會發出兩條此類ARP應答廣播，抓包如下圖：

    因此，說該ARP爲無故ARP也不爲過，但是，與此同時又出現了新的問題。仍舊看上圖，可以發現R1、R2竟然都向路由器R3發出了ARP請求？！卷一中講無故ARP的用途的時候便有這麼一條：無故ARP可用於通告自身的數據鏈路標識符，以便其它設備學到。但是奇怪的是R1、R2、R3都通告了自己的數據鏈路標識符，卻都沒有更新自己的CAM表。因此該消息是否爲無故ARP，真的的無從判斷。
    另外還有一點奇怪的是，R1、R2都像節點路由器R3發出ARP請求，但是R1、R2之間卻未出現過ARP請求，而且R1、R2的ARP表中均不包含對方的表項。但是當用R1 ping R2之後，無論如何用clear arp-cache清表，卻都無法再將對方的表項清楚，抓包結果見第6點第2幅圖。此點可能與CEF有關，因爲當關閉CEF後，將接口shutdown然後再開啓，ARP表項便只有它自己；但當開啓CEF功能的時候，ARP表中就包含它自己（非節點）與節點路由器，節點路由器上則有全部的鄰居ARP表項。但是同樣，在路由環境下，無論CEF是開啓還是關閉，clear arp-cache命令均無法達到清表的目的。


    從簡明信息上看，這應該是一個請求包，操作類型字段也證明了這一點，但是它的二層頭部地址卻是一個單播地址。另外，ARP消息中目的MAC地址信息是存在的，而不像普通ARP請求那樣全被設置爲0。其後who has 123.1.1.3? tell 123.1.1.1也是如此。這同樣很讓人費解，既然知道了對方的MAC，爲何還要進行查詢。隨後我考慮會不會是CEF的問題，但是當關閉CEF功能的時候此現象依然存在。而後我想到，既然能存在CEF這麼一種機制來實現快速轉發，那麼會不會存在另外一張表來使的路由器繞過ARP查詢這一步，也就是說當我清ARP緩存的時候，路由器便要發送ARP請求，但是當它進行數據轉發的時候使用了另外一張表，從而獲得了MAC地址，因此便形成了一個目的明確的單播請求。當然一切都只是猜測，剩下的疑問留待以後解決。