了解并驗證：DHCP的工作原理、怎麼檢測IP位址沖突

動态主機配置協定（Dynamic Host Configuration Protocol, DHCP）被設計用于動态的為網絡中的主機配置設定IP位址及其它相關的TCP/IP屬性，它屬于客戶/服務模式的應用程式，使用UDP協定号67（服務端）和68（用戶端）工作。它代替了網絡管理者手工為網絡中的計算機配置IP位址及其它TCP/IP屬性的工作，如果網絡中的計算機數量較大，使用人工靜态配置IP位址容易造成配置錯誤，比如：把一個IP位址配置到兩台不同的計算機，當配置量過大時，這種失誤是很有可能的，造成過大的管理成本開銷，是以，在中大型網絡中通常都使用DHCP為計算機自動配置IP位址及其它相關的TCP/IP屬性，本小節将以描述DHCP的工作原理與示範DHCP在思科路由器上的配置為重點。

了解DHCP的雛形BOOTP（Bootstrap Protocol）:

DHCP的前生是BOOTP（Bootstrap Protocol），要了解DHCP，不得不說明一下這個BOOTP（Bootstrap Protocol），它比DHCP出現得更早，與DHCP提供類似的服務，用于網絡早期的無盤工作站，這個無盤工作站在現今的網絡應用中基本上已經退出應用市場了，如果還能看到它影子，那就是超市和商場所用的收銀機。BOOTP的功能就是為這些無盤終端自動的配置設定IP位址、子網路遮罩、預設網關、DNS位址。

DHCP的為什麼要替代BOOTP；它們的差別在哪裡？

由于DHCP的出現，BOOTP逐漸被DHCP所替代，因為DHCP有更完善、更安全的工作機制、能夠提供更靈活的IP位址配置設定方式、能夠為客戶機自動配置更多的TCP/IP參數，如果更具體的講就是：BOOTP在配置設定IP位址時，IP位址和請求主機的MAC必須被預置到BOOTP伺服器上，如果BOOTP用戶端發來的IP位址請求消息中，請求主機的源MAC位址在BOOTP伺服器上有記錄，并對應了一個IP，那麼，BOOTP伺服器将對應的IP發放給BOOTP的用戶端，如果沒有對應記錄的存在，請求會話将失敗，這是BOOTP缺泛靈活性的一種典型代表；另外DHCP支援發放IP位址的“租約”機制，但是BOOTP不支援，關于“租約”機制，後面會有詳細的描述；BOOTP隻能最多配置設定4個網絡參數，分别是IP位址、子網路遮罩、預設網關、DNS位址，DHCP可以提供更多的TCP/IP屬性的自動配置。

了解DHCP的工作原理與每個過程的資料幀驗證：

現在來了解DHCP的工作原理并驗證每個工作過程的資料幀，如下圖 9.12所示為DHCP的工作過程，這四個過程，基本上是現今網絡領域公認的四大過程，但事實上，DHCP的工作原理在這四個公認的過程中還有一些小插曲，關于這一點，驗證了如下圖9.13所示的DHCP完整工作過程的資料幀，是以現在拟訂一個清晰的學習思路：

了解DHCP四個工作步驟，并分析每個工作步驟的資料幀。

了解為什麼在這四個工作步驟中會攜帶兩個ARP請求消息，并分析這兩個ARP請求消息。

<a target="_blank" href="http://blog.51cto.com/attachment/201308/055504768.png"></a>

第一步：DHCP用戶端向本地子網發送一個DHCP的Discover消息，該消息是以廣播的形式被發送到網絡上，源MAC位址是發送源主機的MAC位址，源IP位址是0.0.0.0，因為此時的客戶機還沒有被DHCP動态的配置IP位址，目标MAC位址是廣播MAC（FFFF.FFFF.FFFF），目标IP位址是廣播IP（255.255.255.255）,為什麼該消息會是廣播，因為用戶端現在根本就不知道網絡上誰是DHCP伺服器，關于DHCP用戶端發送的DHCP Discover消息的資料幀如下圖 9.14所示。

<a target="_blank" href="http://blog.51cto.com/attachment/201308/055618661.png"></a>

圖9.14 DHCP的在Discover資料幀

在執行DHCP第二步Offer消息前的小插曲：當收到用戶端發來的Discover消息的DHCP伺服器會立即查尋自己可對外提供IP位址的位址池，提供一個可以配置設定給DHCP客端的機會IP，比如192.168.2.5；注意：此時并不是立即将這個位址配置設定出去，這隻是一個可供配置設定的機會IP，DHCP伺服器會以自己的MAC作為源MAC，自己的IP作為源目标，向網絡中發送一個目标IP位址為192.168.2.5（事實上，就是那個機會IP）的ARP請求，目的在于：确認這個它（DHCP伺服器）認為可以配置設定給某個用戶端的IP位址，是否正在被别的主機使用，如果網絡上有主機正在使用這個IP位址，可能是管理者人工輸入的，該主機就會對這個ARP請求應答，這說明，192.168.2.5這個位址正在被使用，反之，沒有應答，就表示DHCP可以将這個位址配置設定給某個DHCP的用戶端，關于DHCP用于檢測機會IP是否被其它主機使用的資料幀如下圖9.15所示。

<a target="_blank" href="http://blog.51cto.com/attachment/201308/055752161.png"></a>

第二步：DHCP伺服器必須完在上述的小插曲後，方可确定機會IP位址可以提供給DHCP的用戶端，這也是為什麼在DHCP工作的四個步驟中會出現一個ARP消息的原因。此時DHCP向網絡中發送一個Offer消息，為用戶端提供IP位址。

注意：行業工程師一直在争論着一個問題：Offer消息到底是以單點傳播的方式進行發送，還是以廣播的方式進行發送，然後，在進行協定分析時，有時會出現廣播消息的Offer資料幀；有時會出現單點傳播消息的資料幀，這是怎麼回事？

首先說明：DHCP伺服器發送的Offer消息，即可以是單點傳播形式，也可以是廣播形式，這要分情況而定，如果将Offer消息單純的定義為廣播或是單點傳播發送都是不嚴密的定義，事實上DHCP的Offer消息是廣播還是單點傳播，這取決于DHCP客戶的具體情況，它可以從如下圖圖 9.16所示DHCP封包中的兩個關鍵字段來做出定義，用戶端IP位址（CIAddr）和标志（Flags）中的Broadcast flag來決定：

n如果Broadcast flag被轉置位為1，則表示客戶機不允許DHCP伺服器的Offer消息以單點傳播的方式回應，是以必須使用廣播回應，在如下圖 9.16所示的資料幀中Broadcastflag被轉置位為0，是以DHCP伺服器可以選擇以單點傳播的方式發送Offer消息。

n如果用戶端IP位址（CIAddr）有一個明确的IP位址，這個已經存在的IP位址，可能是上次引導計算機時DHCP伺服器提供的IP位址。那麼，此時DHCP伺服器的Offer消息将以單點傳播的方式回應。

n如果Broadcast flag和用戶端IP位址（CIAddr）都是0；此時，DHCP伺服器既可以使用廣播進行Offer消息發送，也可以使用上一步小插曲中的ARP記錄進行單點傳播發送，因為在小插曲中的機會位址檢測說明網絡上沒有主機使用這個位址，是以，此時DHCP服務可以假定192.168.2.5這個IP位址可供請求主機使用，是以，可以使用單點傳播的形式回送Offer消息給DHCP客戶機，但事實上，請求主機此時還沒有真正的獲得這個IP。

<a target="_blank" href="http://blog.51cto.com/attachment/201308/055855747.png"></a>

第三步：當DHCP的客戶機收到伺服器發來的Offer消息後，它會以廣播的形式發出一個DHCP的Request消息，正式向DHCP伺服器申請IP位址，注意該消息并不是隻發給提供機會IP的DHCP伺服器，而是以廣播的形式發送給網絡中的所有DHCP伺服器，因為一個網絡上有可能存在多台DHCP伺服器，現在DHCP用戶端正是使用這個DHCP的Request廣播向整個網絡可能存在的所有DHCP伺服器講：“我現在準備申請192.168.2.1這台DHCP伺服器所提供的192.168.2.5這個IP位址如下圖 9.17所示，其它DHCP伺服器，你們的好意心領了！”相當于是委婉的拒絕其它的DHCP伺服器提供相應的IP位址，也就是說：如果網絡上還有其它的DHCP伺服器，它們收到這個Request廣播後，拆開廣播幀，發現該資料幀裡面的DHCP伺服器Identifier字段為192.168.2.1，就視作用戶端對自己的拒絕。

<a target="_blank" href="http://blog.51cto.com/attachment/201308/060025246.png"></a>

第四步：當DHCP伺服器收到用戶端發來的Request消息後，提供IP位址的DHCP伺服器會給DHCP用戶端發送一個DHCP的ACK消息，目的在于告訴DHCP用戶端配置設定的IP位址的“租期”生效；并且告之什麼時間可以送出“續租請求”；以及什麼時候被配置設定的IP位址将從客戶機上解除綁定；如下圖9.18所示，所謂IP位址的“租期”訓示IP位址在客戶機上存在的有效時間，思科的路由器一般“租期”為24小時（１天），“續租請求”訓示當“租期”已經使用了一天的一半時間時即12小時的時候，DHCP用戶端可以發送續訂這個IP位址的請求，如果DHCP伺服器有更多的位址供配置設定給其它主機，那麼，DHCP伺服器将答應用戶端的“續租請求”，然後将“租期”時間重新複位到24小時，如果，此時DHCP伺服器上的位址池很緊張，已經沒有多餘的IP位址可供配置設定給其它主機，那麼，DHCP伺服器将拒絕“租期”，但是，它暫時不會回收IP位址，直到解除綁定時間到期，它仍然沒有多餘的IP供配置設定，那麼DHCP伺服器将回收已經配置設定出去的IP位址。關于DHCP伺服器發送ACK消息的類型，可以是單點傳播，也可以是廣播，這與第二步中的DHCP Offer消息一樣，關鍵取決于DHCP的用戶端的幾個關鍵字段，在這裡就不再重複描述。

<a target="_blank" href="http://blog.51cto.com/attachment/201308/060130446.png"></a>

當DHCP用戶端完成IP位址申請後的一個小插曲：

當完成上述DHCP的四個工作過程後，得到IP位址的主機為了最終確定在網絡中，沒有其它主機正在使用配置設定給它的IP位址，DHCP用戶端會向網絡中發送一條IP位址沖突檢測的ARP消息，如下圖 9.19所示，源和目标IP位址都是自己的IP，源MAC位址為DHCP用戶端的MAC位址，目标MAC全為0；這個ARP請求，将永遠不希望得到回應，因為“自己請求解析自己，如果網絡上沒有一個相同的自己（冒牌貨，實際上就是位址沖突）”那麼，這個ARP請求永遠不可能得到回應，如果主機回應了這個ARP請求，就表示網絡上有兩台主機正在使用相同的IP位址，此時，DHCP用戶端會給DHCP伺服器發送一個DHCP的Decline的消息，意思就是“DHCP伺服器，我被你忽悠了！現在我不要你的IP位址”。

<a target="_blank" href="http://blog.51cto.com/attachment/201308/074404740.png"></a>

本文轉自 kingsir827 51CTO部落格，原文連結：http://blog.51cto.com/7658423/1270601，如需轉載請自行聯系原作者