DHCP (Dynamic Host Configuration Protocol )協議的探討與分析

問題背景

最近在工作中遇到了連接外網的交換機在IPv6地址條件下從運營商自動獲取的DNS地址與本機手動輸入配置的IPv4地址下的DNS發生沖突的問題，這個問題在實際的生產網上會帶來業務的中斷和不穩定，在進入到生產環境中的本地終端發送給數據中心的網絡流量會因為IPv4 和 IPv6 下的DNS沖突而導致無法正確的發送流量。

在終端中，默認的IPv6 的優先級會大於IPv4的優先級，這樣就會帶來沖突問題，解決的問題就是將連接外網的網絡線從與連接內網的交換機中斷開即可以解決。下邊的圖片說明了該問題的發生的場景:

從上邊的圖看出，業務終端連接着“本地業務網核心交換機”來獲取和轉發網絡流量到數據中心生產網絡中的服務器，在正常的條件下，“本地業務網核心交換機”和“本地運營商交換機”是不能通過網絡跳線連接在一起並配置到同一個Vlan中的。在本次問題中，因為“本地運營商交換機”和“本地業務網核心交換機”連接在了同一個Vlan，導致了業務終端的業務流量從數據中心生產網絡來源的不穩定，而造成了業務不穩定。

在這個解決問題的過程中，有DHCP和ARP在實際網絡環境下的運用場景和背景模糊不清的問題，故而撰寫這篇博客來復習和鞏固DHCP協議。

DHCP 概念

1. 什么是 DHCP 網絡協議

網絡是非常復雜且抽象的，網絡中的硬件設備比如 路由器、交換機、集線器、網線、網卡、網橋共同組成了核心網絡，在硬件設備上流通的網絡流量，做到怎么去引導網絡流量正確得流向到正確的網絡設備上，需要TCP/IP 協議作為網絡流量的核心協議。

但是如果一個網絡管理員想要正確地讓TCP/IP協議正確運行，需要給網絡中的主機和路由器配置一些關鍵信息，比如說接口的IP地址。我們可以輕易地在電腦上輸入 ipconfig 命令去顯示當前網絡設備的網絡地址信息，那么這個地址到底是怎么被分配到當前的設備上的？

對於一個網絡設備(終端)的核心IP信息主要有: IP地址、子網掩碼 和 DNS服務器地址。

而獲取網絡設備的 TCP/IP信息主要有這幾個方面：

• 手動配置 - 通過終端上的配置界面根據業務的要求進行手動配置。
• 動態獲取 - 例如 windows 上的手動配置選項上的動態獲取選項。
• 特定的算法進行計算。

一般來說，對於服務器端的采用手動配置方式來適應業務的核心需求，對於客戶端比如連接網絡拓撲上的個人終端那么采用動態獲取方式來獲取相關信息。

原因有以下幾個方面:

• 客戶端與服務器端的交互會更加頻繁，並且客戶端可能會在網絡中發生遷移。
• 服務器端的配置服務要求客戶端的網絡一定必須是固定的。

在這個場景下，客戶端需要從服務器端動態地獲取服務器端的信息並配置到本地中，這個時候 DHCP就派上了用場。在本文中，主機 == 客戶端，即任何需要從網絡中獲取地址的設備( 不包括 網絡中的路由器)，請區別開這個方面的概念。服務器 = 服務端，有時候並不一定是一個獨立的設備，而是一個應用程序(在大多數條件下)，希望能將這些方面的概念區別出來。

DHCP，從英文的含義來說，Dynamic Host Configuration Protocol，是用來動態地配置主機的相關狀態，從DHCP的發展來說，DHCP是繼承於BOOTP 協議 ( Bootstrap Protocol )，后者在設計協議的過程中僅僅提供了有限的主機信息配置，並且主機的信息一旦從遠程服務器端分配之后，就很難再被修改；DHCP的出現改變了這種局面，DHCP幾乎提供了所有的主機配追信息，並且引入了租約的概念，使得主機信息能夠動態地產生變化和進行更改。此外，作為可以動態地更改主機的配置的協議，

DHCP 是一個基於 Client/Server 模式的網絡協議。

DHCP 是基於UDP/IP協議進行傳輸，服務器端使用端口 67, DHCP客戶端使用端口號 68。

2. DHCP 協議內容

DHCP主要分為兩個部分: 網絡IP地址的管理 和 配置信息的傳遞

• 網絡IP地址的管理： 地址管理處理 IP 地址的動態分配， 並且為每一個主機 (Host) 提供地址的租約
• 配置信息傳遞: 從服務器端向主機端傳遞報文 和 狀態機的配置。

3.DHCP 地址管理

地址池 與 地址租約

如果用戶在客戶端中申請配置一個 動態網絡地址配置，那么 DHCP客戶端(Host) 會向 DHCP服務器 發送一個 IP地址請求。 這個時候在遠程的 DHCP服務器 就會維護一個 IP地址池，並且從這個地址池來取出一個IP回應給 DHCP客戶端。 在地址分配的過程中，DHCP服務器也會指定回應給 DHCP客戶端的IP地址的租約期，在租約期中，這個地址可以被客戶端使用，租約期到之后這個IP地址被 DHCP服務器自動收回。客戶端可以在租約期內請求延長租約。

DHCP 報文內容

DHCP的組成從網上有很多解釋，下圖來自網絡:

• Op： 報文類型，分為 兩大類： Request（1） 和 Reply（2）
• HW Type： 硬件類型，一般是以太網：1
• HW Len： 硬件地址長度，單位字節。對應以太網：6（mac地址長度為6字節48bit）
• Transaction ID：事務ID，隨機數，有客戶端生成，服務器Reply時，會把 Request 中創建的 Transaction 拷貝到Reply報文中。用於客戶端區分網絡上的目的地為自己的報文。
• Secs： 距離第一次發射IP請求或Renew請求過去的秒數
• Flags：標志位，目前僅第一個bit有使用，置1 標明廣播
• Client IP Address：當前客戶端的IP地址，如果當前客戶端沒有IP地址，則置0
• Your IP Address： 服務器想客戶端提供IP地址時，會把IP地址填入本字段
• （Next）Server IP Address：客戶端引導時需要的另一個服務器的IP地址
• Gateway （Relay） IP Address： 網關（中繼）IP地址，有DHCP 中繼器在轉發DHCP報文的時候填入
• Server Name： Server名字，有64bytes，一般不使用，填充為0
• Boot File name： boot file的路徑，128bytes， 一般不使用，填充為0
• Option： 選項，不定長度。 DHCP報文中比較重要的字段

DHCP Option 內容

之前介紹過，因為DHCP是從Bootp 協議繼承和拓展過來的，因此很多不能在Bootp實現的內容都放到了Option 來實現。通俗來說，DHCP協議其實就是攜帶許多Option的Bootp。

報文中的Option遵循以下的形式:

• 如果Option沒有值，則只有標志位之類的內容，則以一個字節表示
• 如果Opiton有值，即Opiton是以下name-value對，則Opiton需要多個字節表示，其中第一個字節表示 option的名字，第二字節表示value的長度，第三個字節開始表示value。

常見的Option類型情參照下圖:

4.DHCP 工作原理

主機加入到一個新的網絡中

DHCP 將一台從未分配過的主機加入到網絡需要經歷四個階段: 1. 發現階段，2.提供階段，3.請求階段，4.確認階段。

發現階段

新的Client加入網絡時，會使用0.0.0.0作為源地址，發送discover廣播報文，查詢網絡上有哪些DHCP Server，以及這些DHCP Server 能Offer哪些IP地址。這個廣播幀的MAC地址為新的Client的MAC地址，類型字段為 0x0800，載荷數據為一個廣播 IP 報文，該報文的目的IP地址 為有限的廣播地址: 255.255.255.255， 協議字段值為 0x11, 載荷數據是一個 UDP報文，消息為 DHCPDISCOVER。

在該階段中，與客戶端所在二層網絡中的所有網絡設備都會接收到這個廣播幀，並將這個廣播幀洪泛出去，在其他設備接收到這個數據幀的時候會將相關的載荷按照網絡分層的結構逐層上傳。在設備的傳輸層 UDP模塊 在接收網絡層上傳的數據包之后會解析數據包的端口號。 對於一個DHCP服務器來說，67 作為獨特的端口號，會被打開，而對於其他的設備來說這個端口不被打開，那么這個數據包就被丟棄。

在華為的數通教材HCNA中，給出的例子是路由器上運行了 DHCP服務器 ， 但是鏈路中可能有多個設備也運行了DHCP服務器，這個時候所有收到該請求包的DHCP服務器都會給請求客戶端回復一個響應數據包來證明自己已經接收到了請求信息，返回的數據包都會被發送到請求的客戶端。

對於DHCP的傳輸模式 - UDP協議，是一種面向無連接的、不需要可靠傳輸的通信方式，因此 DHCP 需要依賴自己的一種可靠的傳輸傳輸方式，其中包括：什么情況下需要重復發送已經發送過的請求（重傳消息機制），重復請求的間隔時間是多少，最大重復次數是多少等等...

提供階段

DHCP Server接收到DHCP Discover報文后，回應Offer報文，提供IP地址（可能包含DNS等其他信息）給Client。

這個階段中，不涉及客戶端是否接受服務端給出的 IP 地址，只是服務器端給客戶端的一個響應。 每個接收到 DHCPDISCOVER 消息的服務器，都從自己維護的 IP 地址池分配出一個有效的且未被使用的 IP地址，並通過 DHCPOFFER 消息將這個IP地址分配發送給客戶端。

對於一個 DHCPOFFER 消息來講，消息被封裝在客戶端預留端口號為68，源端口號67的一個UDP報文中，該UDP報文又是被上層封裝到一個被廣播的IP報文中。 這個IP報文的目的地址是一個有限廣播地址：255.255.255.255，源地址為DHCP服務器端所對應的單播地址，其中協議字段為0x11，該IP報文又被上層封裝到了一個廣播幀中，這個廣播幀的源MAC地址為 DHCP Server 所對應的單播MAC地址，類型字段的值為 0x0800。

在傳輸的過程中，與請求客戶端所在同一個二層網絡中的所有設備都會接收到這個請求數據包，只有開啟了 DHCP Client 服務的客戶端才會接收到這個數據包的載荷數據（DHCPOFFER），並上傳至應用層上的 DHCP Client 中。

但是在同一個二層網絡中可能存在着其他同樣打開 DHCP Client 服務的客戶端，一個請求客戶端在接收到從 DHCP Server 返回的報文DHCPOFFER如何區分在收到的返回報文是不是自己發出的請求呢？

• 其實請求客戶端發送 DHCPDISCOVER 請求的時候就已經創建了一個用於區別請求和返回且獨一無二的交易號(Transaction ID) ，這個交易號會在服務端向客戶端發送DHCPOFFER回執的時候會將這個交易號一起發送回去，在請求客戶端接收到DHCPOFFER時會判斷響應的報文中的交易號是否與之前創建的交易好相同。
• 創建的交易號為一個 4字節 （32bit） 二進制數。

請求階段

在請求階段中，發送請求的客戶端可能會接收到多個 DHCPOFFER報文，這個時候請求客戶端會自己選擇一個DHCP Server，並廣播一個 DHCPREQUEST 的請求包給選擇的 DHCP Server。並向本地中其他的 DHCP Server 公告自己已經選擇了某個 DHCP Server的某個IP地址，這個時候其他的未被選擇的 DHCP Server 接收到了DHCPREQUEST 報文明白該請求客戶端已經選擇好了DHCP Server，那么這些服務器就會收回當初分配給請求客戶端的 DHCPOFFER 以及 預留的IP地址。

請求客戶端該過程發送的廣播幀的源MAC地址為該請求客戶端的MAC地址，類型字段的值為0x0800，載荷數據是一個廣播IP報文。該IP報文的目的地址是廣播地址（255.255.255.255），源地址是 0.0.0.0，協議字段的值為 0x11，載荷數據是一個UDP報文。該UDP報文的目的端口號為67，源端口號為68，載荷數據是一個 DHCPREQUEST。

DHCPREQUEST上攜帶者有請求客戶端已經選定的 DHCP Server 的標識號 (Identifier)，表示這個請求客戶端只接受已經選定的DHCP Server 的 OFFER。

確認階段

在該階段中，DHCP Server 會向請求客戶端（DHCP Client）回復 DHCPACK 消息用來表示自己已經接收到了請求客戶端的請求。

DHCPACK 消息的類型是一廣播IP報文，IP報文的目的IP地址是一個有限的廣播地址 255.255.255.255，其源地址為請求客戶端對應的單播IP地址。其載荷數據是一個UDP報文，UDP報文的源端口號是67，目的端口號是68。

在這個過程中有一個特殊情況，就是在請求客戶端和分配IP地址的DHCP Server通訊的過程中預先分配給請求客戶端的IP地址分配給了其他的主機應該怎么辦？

• 請求客戶端接收到了 DHCPACK 報文之后，會立即借助 Gratutious ARP 消息機制來檢查自己的IP地址是不是唯一的。
• 如果這個地址已經被其他的客戶端占用，那么該請求客戶端就會主動放棄該IP地址，並向 DHCP Server發送 DHCPDECLINE 告訴該地址已經被其他客戶端占用，然后經過一段時間之后重新嘗試獲取改地址。
• 如果這個地址一直無法被分配，那么請求客戶端就會發送一個DHCPRELEASE 報文給 DHCP Server聲明放棄這個地址，然后重新從談發現階段開始。

主機已經有IP地址，只想更新租約

1.此時可以跳過DHCP Discover報文和DHCP Offer報文。

2.Client發送攜帶當前IP地址的Request報文。

3.如果Server同意Client續約，則發送DHCP ACK報文。如果拒絕續約，則發送DHCPNAK報文。

下邊有一個圖來具體的說明 DHCP 的工作原理以及建立相關網絡聯系的流程和原理:

【未完待續.... 下一部分將加上華為模擬設備上DHCP的請求過程詳解以及配置過程】