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

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 做爲獨特的端口號，會被打開，而對於其餘的設備來講這個端口不被打開，那麼這個數據包就被丟棄。

在華爲的數通教材中，給出的例子是路由器上運行了 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 服務的客戶端，終端如何區分是否是本身發出的DHCPDISCOVER請求呢？其實可會斷在發送 DHCPDISCOVER 請求的時候就已經建立了一個用於區別請求且獨一無二的交易號(Transaction ID) ，這個交易號會在服務端向客戶端發送DHCPOFFER回執的時候

3.Client 根據收到的Offer報文，選擇一個DHCP Server，並選擇它提供的IP地址。而後廣播Request報文，向DHCP Server請求該IP地址，同時向本地網絡（尤爲是其餘DHCP Server）公告本身已經選擇了某個DHCP Server的某個IP地址。

4.DHCP Server 迴應ACK報文，將IP地址分配給client端 （特殊狀況：DHCP Server在發送Offer報文和接收到Request的短暫時間內把IP分配給了其餘主機）。

5.DHCP Client 收到ACK報文後，會針對得到的IP地址發送ARP Request，進行IP地址衝突檢測。

6.若是IP地址已經被其餘主機使用，則Client放棄該IP地址，向Server發送DHCP DECLINE報文告訴Server該地址不能使用。而後一段時間後（通常10s）再此嘗試獲取該IP地址

7.若是Client仍然沒法使用該IP地址，則發送DHCP RELEASE報文，放棄該地址。

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

1.此時能夠跳過DHCP Discover報文和DHCP Offer報文。

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

3.若是Server贊成Client續約，則發送DHCP ACK報文。若是拒絕續約，則發送DHCPNAK報文。

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

【未完待續.... 下一部分將加上華爲模擬設備上的】