TCPIP卷一（1）：二層封裝與路由器轉發數據過程

二層封裝

爲何須要了解二層封裝呢？ 由於在一個路由器轉發數據包的時候，除了知道目的地怎麼去（有路由），還須要二層的正確封裝，不然就算有路由的話，也沒法進行通訊。

這是卷一提到過的，雖然沒有像協議卷一說得那麼細，可是，它也說明了，必須獲取數據鏈路層的信息才能正常進行封裝，而這個二層的信息一般就是目的mac地址，而提供這個IP對應MAC的機制，就經過ARP來完成，而且經過緩存保存下來。而網絡層，則是經過靜態或者動態路由協議獲取相關的信息，保存在路由表中，也叫路由選擇信息庫 RIB。

這個拓撲主要介紹ARP和代理ARP在以太網類型中起一個什麼做用。IP地址信息如圖上所示

證實一

第一個證實，二層若是沒有獲取到封裝的信息，則數據包都不會發送出去。
根據這個圖就配置了IP地址，右邊路由有一跳缺省路由，這時候隨便測試一個不存在的地址，查看數據包發送的狀況。
在R2上telnet 12.1.1.3，一個不存在的地址 。

沒有響應是正常的，可是這個沒響應，到低是由於找不到二層的封裝，仍是應用層沒有響應呢。 三層信息路由是沒有問題的，由於是直連網段，，那麼以太網通訊，必須知道對方的MAC地址，而默認狀況下，是不知道的，那麼就須要一個機制來進行查詢，就是ARP了。

發送了三個ARP查詢，而網絡中沒有人進行響應，因此，二層沒法獲得封裝（沒有獲取12.1.1.3的MAC地址）則通訊失敗。

這時候，咱們作一個靜態ARP綁定，而後在進行telnet，MAC地址能夠隨意定義。

其中1.1.1就是表示MAC 0001.0001.0001 能夠省略寫的。

發現了什麼？ 由於MAC地址有了封裝（就是手工綁定的），它直接發送TCP鏈接給12.1.1.3了，發送了4個SYN的包，由於對方沒有響應SYN+ACK，因此這個TCP會話沒有繼續進行下去。

結論： 不管在一個相同網段，仍是不一樣網段的狀況下，若是二層的介質是以太網，那麼就必須獲取對方的MAC地址信息，相同網段則是目的地址的MAC地址，不一樣網段則是路由表中的下一跳 ，一種特殊狀況下，就是啓用了代理arp的話，那麼也是目的地址，可是MAC則是下一跳。 這也是在當前IPV4的網絡中，ARP是一個很是不安全的協議，由於很容易就實現***了，只要網關的MAC被***者以錯誤的MAC告訴當前網絡的設備，那麼整個網絡就通訊不正常了。

證實二

第二個證實：路由器在路由模式和主機模式下，數據包是怎麼通訊的。

仍是這個拓撲，在右邊路由器上關閉路由功能，no ip routing，那麼能與 1.1.1.1通訊麼？

答案是：能夠的。

通了是通了，那麼它是怎麼通的呢

在show arp後，發現除了有12.1.1.1的MAC地址信息（以前ping過了），還有1.1.1.1對應的MAC信息，另一個重要的信息就是12.1.1.1和1.1.1.1的MAC地址信息都是關於12.1.1.1的，這是爲何？ 這就是所謂的代理ARP和主機模式工做的工程。

主機模式工做：

一、無網關狀況下：當沒有網關的狀況下，它會對當前網絡進行ARP查詢，詢問訪問的目的地址的MAC地址信息，若是這個時候，網關知道怎麼去這個目的地址，而且開啓了代理ARP的功能，那麼就會迴應這個ARP響應，那麼迴應的內容就是這個目的地址的MAC地址是本身，這對於PC或者主機路由器來講是不知道的，它就認爲這個MAC是對應目的主機，每次發送去往這個目的地址的時候，二層就封裝這個目的MAC，而後發送出去。

二、有網關的狀況下：當有網關的狀況下，它只會詢問網關的MAC是多少，若是網關響應了後，那麼PC或主機路由器，就會把這個數據包發送出去，它無論網關是否知道怎麼去往這個目的地址不。

能夠進行證實：一、在沒有網關的狀況下，把R1的代理ARP給關閉了，默認是打開的，而且把ARP 緩存清掉 shutdown接口，clear arp

不通，由於R1的接口已經關閉了代理ARP了，因此不不會去響應這個ARP的Request。

二、設置網關爲R1的接口，而且發送一個去往2.2.2.2的telnet的會話，看TCP會話是否會發出去，若是出去了，就證實以前說的是對的，無論網關是否知道目的地可達，PC或主機路由器都會發送。

這時候開始telnet 2.2.2.2

telnet2.2.2.2 ,提示目的不可達，或者網關和主機是downde

首選，路由器發送ARP的Request選爲12.1.1.1（GW）的MAC地址是多少。R1響應這個ARP的請求。緊接着一個TCP會話發送出去，R1直接回復一個ICMP的差錯報文，主機不可達。

路由模式下的路由器：

路由模式的數據包轉發，不跟主機模式同樣，主機模式是隻要設置了網關或者沒設置都會發送arp請求，可是，路由模式的話，先查看路由表，若是路由表中沒有該路由，則不作任何動做。

能夠看出，由於路由表沒有去往2.2.2.2的路由信息，因此不採起任何動做，連ARP都沒有發送。

證實三

第三個證實：兩個不一樣網段的主機，可否進行通訊？
在設置有GW的狀況下，確定是不可能的，可是，在某種狀況下，它卻成爲可能，那就是兩個主機都不設置IP，而且有代理ARP功能。

說明：R1和R2都是關閉了路由功能的路由器，而且接口開啓了代理ARP功能。IP地址與圖

從R1開始ping 2.2.2.2，而且抓取R1的數據包進行分析。

沒看錯，R1與R2能夠通訊了，仔細看抓包的內容，首先R1發送一個arp的查詢，｛how has 2.2.2.2？ tell 1.1.1.1｝一個詢問2.2.2.2的MAC Request包就發送出去了，由於R2與R1是直連（鏈路），因此，R2收到了這個ARP 的Request，並且R2是開啓了代理ARP功能的，也就是說只要R2知道2.2.2.2怎麼去，就會響應這個ARP的請求（這裏明顯就是本身），因此第二個訴舉報就是arp的reply｛2.2.2.2 is at c0：01：05：04：00：00｝,那麼這時候R1就有R2的mac地址映射了，因此就發送了數據包出去，也就是icmp的echo，這時候R2收到，須要迴應這個數據包，可是，它並不知道對方的MAC是什麼，緊接着也發送了一個ARP的請求過去，詢問1.1.1.1的MAC，而後,R1回覆這個ARP請求。後續，通訊就正常了。
注意：若是是正常的ARP詢問，那麼只要一方放送ARP請求，另一份響應的時候，還會把請求方的ARP的信息緩存起來。而且在主機模式下的路由器是不能關閉代理ARP的，就算接口下關閉了，也同樣會響應請求。

其實，不僅有代理ARP能實現這個需求，好比在PC的狀況下，由於PC沒有代理ARP機制，因此，能夠直接把1.1.1.1的網關設置爲2.2.2.2，2.2.2.2的網關爲1.1.1.1，它同樣能通訊，由於它會發送ARP信息來請求網關。

注意：並非全部的操做系統都是能執行的，有些是禁止的，之全部說明這個案例，主要是說明ARP在MAC和IP對應時候的做用，已經二層封裝。

本文首發於公衆號：網絡之路博客