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

DHCP協(xié)議工作原理：

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

為了動態(tài)獲取并使用一個合法的IP地址，需要經(jīng)歷以下幾個階段：

(1) 發(fā)現(xiàn)階段：即DHCP 客戶端尋找DHCP 服務(wù)器的階段。

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

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

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

1. 發(fā)現(xiàn)階段

在發(fā)現(xiàn)階段，DHCP客戶端通過發(fā)送DHCP-DISCOVER報文來尋找DHCP服務(wù)器。由于DHCP服務(wù)器的IP地址對于客戶端來說是未知的，所以DHCP客戶端以廣播方式發(fā)送DHCP-DISCOVER報文。所有收到DHCP-DISCOVER報文的DHCP服務(wù)器都會發(fā)送回應(yīng)報文，DHCP客戶端據(jù)此可以知道網(wǎng)絡(luò)中存在的DHCP服務(wù)器的位置。

2. 提供階段

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

DHCP服務(wù)器為客戶端分配IP地址的優(yōu)先次序如下：

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

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

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

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

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

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

3. 選擇階段

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

4. 確認階段

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

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

重用曾經(jīng)分配的IP地址

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

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

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

DHCP中繼工作過程：

原始的DHCP協(xié)議要求客戶端和服務(wù)器只能在同一個子網(wǎng)內(nèi)，不可以跨網(wǎng)段工作。因此，為進行動態(tài)主機配置需要在所有網(wǎng)段上都設(shè)置一個DHCP服務(wù)器，這顯然是不經(jīng)濟的。

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

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

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

如下處理：

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

DHCP 請求報文的目的地址修改為DHCP 服務(wù)器或下一個DHCP 中繼的IP地址。從而，將DHCP 請求報文中繼轉(zhuǎn)發(fā)給DHCP 服務(wù)器或下一個DHCP中繼。

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

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

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

轉(zhuǎn)載于:https://blog.51cto.com/sxsure/1333806

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。