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