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 的工作原理以及建立相關網絡聯繫的流程和原理:
【未完待續…. 下一部分將加上華為模擬設備上的】
