? 這兩天一直在客戶這邊測試DHCP，由于客戶的網絡是現成的server 2008 是后來加上去的，所以沒有多的IP地址用于測試，只好拿客戶的樓層網段來測試，由于需要跨VLAN實行DHCP地址分配，所有需要做DHCP中繼。廢話不多說，先看下各部分的原理；然后在說遇到的問題；

DHCP協議工作原理：

由于在IP地址動態獲取過程中采用廣播方式發送報文，因此要求DHCP客戶端和服務器位于同一個網段內。如果DHCP客戶端和DHCP服務器位于不同的網段，則需要通過DHCP中繼來中繼轉發DHCP報文。通過DHCP中繼完成動態配置的過程中，客戶端與服務器的處理方式與不通過DHCP中繼時的處理方式基本相同。下面僅以DHCP客戶端與DHCP服務器在同一網段的情況為例，說明DHCP協議的工作過程。

為了動態獲取并使用一個合法的IP地址，需要經歷以下幾個階段：

(1) 發現階段：即DHCP 客戶端尋找DHCP 服務器的階段。

(2) 提供階段：即DHCP 服務器提供IP 地址的階段。

(3) 選擇階段：即DHCP 客戶端選擇某臺DHCP 服務器提供的IP 地址的階段。

(4) 確認階段：即DHCP 服務器確認所提供的IP 地址的階段。

1. 發現階段

在發現階段，DHCP客戶端通過發送DHCP-DISCOVER報文來尋找DHCP服務器。由于DHCP服務器的IP地址對于客戶端來說是未知的，所以DHCP客戶端以廣播方式發送DHCP-DISCOVER報文。所有收到DHCP-DISCOVER報文的DHCP服務器都會發送回應報文，DHCP客戶端據此可以知道網絡中存在的DHCP服務器的位置。

2. 提供階段

網絡中接收到DHCP-DISCOVER報文的DHCP服務器，會選擇一個合適的IP地址，連同IP地址租約期限和其他配置信息（如網關地址，域名服務器地址等）一同通過DHCP-OFFER報文發送給DHCP客戶端。DHCP服務器通過地址池保存可供分配的IP地址和其他配置信息。當DHCP服務器接收到DHCP請求報文后，將從IP地址池中取得空閑的IP地址及其他的參數，發送給DHCP客戶端。

DHCP服務器為客戶端分配IP地址的優先次序如下：

(1) 與客戶端MAC 地址或客戶端ID 靜態綁定的IP 地址；

(2) DHCP 服務器記錄的曾經分配給客戶端的IP 地址；

(3) 客戶端發送的DHCP-DISCOVER 報文中Option 50 字段指定的IP 地址；

(4) 在DHCP 地址池中，順序查找可供分配的IP 地址，最先找到的IP 地址；

(5) 如果未找到可用的IP 地址，則依次查詢租約過期、曾經發生過沖突的IP 地址，如果找到則進行分配，否則將不予處理。

DHCP服務器為客戶端分配IP地址時，服務器首先需要確認所分配的IP沒有被網絡上的其他設備所使用。DHCP服務器通過發送ICMP Echo Request（ping）報文對分配的IP進行探測。如果在規定的時間內沒有應答，那么服務器就會再次發送ping報文。到達規定的次數后，如果仍沒有應答，則所分配的IP地址可用。否則將探測的IP地址記錄為沖突地址，并重新選擇IP地址進行分配。

3. 選擇階段

如果有多臺DHCP服務器向DHCP客戶端回應DHCP-OFFER報文，則DHCP客戶端只接受第一個收到的DHCP-OFFER報文。然后以廣播方式發送DHCP-REQUEST請求報文，該報文中包含Option 54（服務器標識選項），即它選擇的DHCP服務器的IP地址信息。以廣播方式發送DHCP-REQUEST請求報文，是為了通知所有的DHCP服務器，它將選擇Option 54中標識的DHCP服務器提供的IP地址，其他DHCP服務器可以重新使用曾提供的IP地址。

4. 確認階段

收到DHCP客戶端發送的DHCP-REQUEST請求報文后，DHCP服務器根據DHCPREQUEST報文中攜帶的MAC地址來查找有沒有相應的租約記錄。如果有，則發送DHCP-ACK報文作為應答，通知DHCP客戶端可以使用分配的IP地址。DHCP客戶端收到DHCP服務器返回的DHCP-ACK確認報文后，會以廣播的方式發送免費ARP報文，探測是否有主機使用服務器分配的IP地址，如果在規定的時間內沒有收到回應，客戶端才使用此地址。否則，客戶端會發送DHCP-DECLINE報文給DHCP服務器，通知DHCP服務器該地址不可用，并重新申請IP地址。

如果DHCP服務器收到DHCP-REQUEST報文后，沒有找到相應的租約記錄，或者由于某些原因無法正常分配IP地址，則發送DHCP-NAK報文作為應答，通知DHCP客戶端無法分配合適IP地址。DHCP客戶端需要重新發送DHCP-DISCOVER報文來請求新的IP地址。

重用曾經分配的IP地址

DHCP客戶端每次重新登錄網絡時，不需要再發送DHCP-DISCOVER報文，而是直接發送包含前一次分配的IP地址的DHCP-REQUEST請求報文，即報文中的Option 50（請求的IP地址選項）字段填入曾經使用過的IP地址。DHCP服務器收到這一報文后，判斷DHCP客戶端是否可以使用請求的地址：

如果可以使用請求的地址，DHCP服務器將回復DHCP-ACK確認報文。收到DHCP-ACK報文后，DHCP客戶端可以繼續使用該地址進行通信。

如果請求的IP地址已無法再分配給DHCP客戶端（例如，此IP地址已分配給其它DHCP客戶端使用），則DHCP服務器將回復DHCP-NAK否認報文。DHCP客戶端收到此報文后，必須重新發送DHCP-DISCOVER報文來請求請求新的IP地址；

DHCP中繼工作過程：

原始的DHCP協議要求客戶端和服務器只能在同一個子網內，不可以跨網段工作。因此，為進行動態主機配置需要在所有網段上都設置一個DHCP服務器，這顯然是不經濟的。

DHCP中繼的引入解決了這一問題，它在處于不同網段間的DHCP客戶端和服務器之間承擔中繼服務，將DHCP協議報文跨網段中繼到目的DHCP服務器，于是不同網絡上的DHCP客戶端可以共同使用一個DHCP服務器

DHCP客戶端發送請求報文給DHCP服務器，DHCP中繼收到該報文并適當處理后，發送給指定的位于其它網段上的DHCP服務器。服務器根據請求報文中提供的必要信息，通過DHCP中繼將配置信息返回給客戶端，完成對客戶端的動態配置。

(1) DHCP 中繼接收到DHCP-DISCOVER 或DHCP-REQUEST 報文后，將進行

如下處理：

為防止 DHCP 報文形成環路，拋棄報文頭中hops 字段的值大于限定跳數的DHCP 請求報文。否則，繼續進行下面的操作。檢查 giaddr 字段。如果是0，需要將giaddr 字段設置為接收請求報文的接口IP 地址。如果接口有多個IP 地址，可選擇其一。以后從該接口接收的所有請求報文都使用該IP 地址。如果giaddr 字段不是0，則不修改該字段。將 hops 字段增加1，表明又經過一次DHCP 中繼。將請求報文的 TTL 設置為DHCP 中繼設備的TTL 缺省值，而不是原來請求報文的TTL 減1。對中繼報文的環路問題和跳數限制問題都可以通過hops 字段來解決。

DHCP 請求報文的目的地址修改為DHCP 服務器或下一個DHCP 中繼的IP地址。從而，將DHCP 請求報文中繼轉發給DHCP 服務器或下一個DHCP中繼。

(2) DHCP 服務器根據giaddr 字段為客戶端分配IP 地址等參數，并將DHCP 應答報文發送給giaddr字段標識的DHCP 中繼。DHCP 中繼接收到DHCP 應答報文后，會進行如下處理：

DHCP 中繼假設所有的應答報文都是發給直連的DHCP 客戶端。giaddr 字段用來識別與客戶端直連的接口。如果giaddr 不是本地接口的地址，DHCP 中繼將丟棄應答報文。DHCP 中繼檢查報文的廣播標志位。如果廣播標志位為1，則將DHCP 應答報文廣播發送給DHCP 客戶端；否則將DHCP 應答報文單播發送給DHCP客戶端，其目的地址為yiaddr，鏈路層地址為chaddr。

原理講了這么多，談正題：客戶這邊的網絡很亂連客戶自己都不清楚是怎么走的，客戶的核心使用的是6509-E，在測試DCHP過程中，發現客戶端不能自動獲取地址，通過抓包分析在客戶端和服務器上面抓發分析，發現客戶端只有發出去的廣播消息，而服務器那段也沒有接收到相關的DHCP單播的報文，通過做端口鏡像流量分析也是如此，由此判斷該問題應該是出現在中繼配置這塊；配置過中繼的人都應該知道在Cisco的三層設備上面配置中繼就幾條命令，（service dhcp, ip helper-address server ip adress ）查看6509的特殊發現該機型的特殊跟36的基本相似，中繼命令是一樣的，起初判斷是中繼上面配置了抑制廣播和DHCP監聽的相關配置，查看配置發現該核心上面沒有類似的服務，因為客戶這邊的6509上過FWSM防火墻，所以有去查看防火墻配置，也沒有發現相關的配置，通過進一步分析，發現客戶這邊做了相對應的樓層VLAN隔離，查看該樓層的ACL發現最后一條permit語句寫的太死了。直接把DHCP的相關流量給干死了，所以直接在后面加了兩條語句（permit udp any eq bootpc any eq bootps,permit udp any any eq domain）放過DHCP和DNS就行了；

轉載于:https://blog.51cto.com/sxsure/1333806

總結

以上是生活随笔為你收集整理的DHCP中继处理办法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。