欢乐颂小说txt,网络小说排行榜,《完美世界》txt全集

１關于DHCP服務器的沖突檢測的總結

２取證DHCP中繼代理的工作原理與IP地址沖突（因為不在一個子網，所以gratuitous ARP肯定不行老）

關于DHCP服務器的沖突檢測

業內常有工程師提出這樣一個問題：當在一個子網內為了提高DHCP的冗余，同時架設了兩臺DHCP服務器而且配置了相同的地址池范圍（比如都是分配192.168.2.1-192.168.2.254/24）；那么，兩臺DHCP服務器會把同一個IP地址作兩次分配給不同的主機嗎？，比如：DHCP服務器A分配一個192.168.2.5的IP；DHCP服務器B又分配一個192.168.2.5的IP，這樣就會在網絡上造成IP地址沖突。答案是不會造成IP地址沖突，因為現在的DHCP多數都采取了沖突檢測特征，就是說，在DHCP服務器準備向網絡上的某臺主機提供IP地址之前，做沖突檢測，檢測的方式大致有兩種：一是DHCP服務器向網絡上發送一個關于機會IP（準備分配給DHCP客戶端的IP地址）的ARP請求，無應答就表示地址沒有被使用，當然也不希望得到ARP的回應，如果得到回應則表示該地址已被使用，那么DHCP不會把該地址分配出去；另一種方案是DHCP服務器在分配某個IP地址之前向網絡上發送一個ICMP的回顯報文，如果沒有主機應答，證明該IP地址沒有被使用，可以被分配出去，相反之則不能。

DHCP是基于廣播和單播工作的，至少客戶端發出的discover消息肯定是廣播，因為它要尋找網絡中的DHCP服務器，都知道路由器是隔斷網絡廣播的三層設備，那么，位于路由器不同接口上的DHCP服務器與客戶端將無法進行正常工作，因為客戶端的Discover消息被路由器給切斷。此時，在這種跨網段的DHCP部署環境中，提出一種概念叫做中繼代理（Relay Agent），在思科的IOS中叫幫助地址（Helper address）它能幫助DHCP客戶端跨越路由器申請IP地址及其它TCP/IP參數，從而解決由于廣播域的分隔，導致DHCP不能正常工作的問題。關于DHCP中繼代理的工作原理如下圖9.23所示。

第一步：DHCP客戶端發送DHCP的Discover廣播尋找本地子網上的DHCP服務器，毫無疑問，這個尋找將失敗，因為本地子網上根本沒有部署DHCP服務器，但是，此時DHCP的中繼代理路由器R1的E1/0（192.168.5.1）會收到這個Discover廣播消息。

第二步：中繼代理路由器會幫助DHCP客戶端到指定的DHCP服務器去申請IP地址，這里所謂指定的DHCP服務器，事實上，就是在中繼路由器上申明了誰是DHCP服務器，比如申明192.168.4.1為DHCP服務器，那么DHCP的中繼路由器會將Discover消息單播到DHCP服務器（192.168.4.1），注意，此時中繼使用單播的方式把Discover消息發送到DHCP服務器，因為中繼明確的知道它該向哪臺DHCP服務器進行申請，

第三步：DHCP服務器會以單播的方式回應中繼的Discover消息，并發送Offer消息，該消息中包括了DHCP可以給中繼提供的機會IP(192.168.5.2)，關于DHCP服務器提供給中繼的Offer消息如下圖9.24所示，這個Offer消息以單播的形式發送，因為，DHCP服務器知道中繼是誰，并且在該消息中包括了中繼的IP地址，值得提出的是，DHCP服務器向中繼提供機會IP（192.168.5.2）之前，它還是會做一個IP地址沖突檢測，它需要知道192.168.5.2這個IP地址，在網絡上是否有主機正在使用它，它的檢測方式是發送一個目標地址為192.168.5.2的ICMP回顯消息，如果沒有回應，說明該地址沒有被使用，可以被分配出去，反之則不能；DHCP服務器還會檢測與中繼的連通性，確保中繼能成功的得到這個Offer消息，關于這個過程可以通過如下圖9.25所示的數據幀證實。在這里DHCP服務器為什么不使用ARP進行IP地址沖突探測？原因很簡單，因為在通過中繼申請IP地址的DHCP環境中，DHCP提供的IP地址通常都不是本地子網的IP地址范圍，ARP不能穿越路由器工作。

第四步：中繼向DHCP服務器發起DHCP的Request請求消息，該消息仍然以單播的方式發送，這與本地子網上DHCP的工作原理不同，在本地子網上的這個過程應該是以廣播的形式進行發送，而在中繼的環境中，中繼以單播發送，因為在這種情況下，通信雙方是很明確的，不可能存在有其它的DHCP服務器向中繼提供IP，兩個原因：第一個原因是中繼設備上會明確指示它該向哪臺DHCP服務器申請IP；第二個原因是中繼發起DHCP的Discover消息時，就是單播發送的，不會有第二臺DHCP服務器來為中繼提供IP，因為它不會自作多情。

第五步：DHCP服務器收到中繼的單播Request消息后，會回應一個ACK消息給中繼，指示IP地址的租期正式生效，注意該消息仍然是以單播的形式發送，前面已經描述了原因，這里不再重復描述。

第六步：事實上述第二步到第五步對于DHCP客戶端而言是完全透明的，它看不見中繼為它完成IP地址申請的過程。它只能看見中繼與自己的DHCP消息交互過程，當DHCP的中繼成功的從DHCP服務器獲得地址后，中繼會給DHCP客戶端發送一個DHCP的Offer消息，告訴DHCP的客戶端可以提供給它的IP地址，注意，此時中繼就無需再檢測該IP地址在網絡上是否有沖突的可能性了，因為這個過程在上述的第三步中已經做了檢測。

第七步：DHCP客戶端在收到DHCP中繼所提供的Offer消息后，會向DHCP的中繼發送一個DHCP的Request消息，正式請求IP地址。該消息以廣播的形式發送，為什么是會以廣播形式發送，在標準的DHCP環境已經有明確說明。

第八步：DHCP中繼收到客戶端的Request消息后，會回應一個ACK消息給DHCP客戶端，申明租約正式生效，然后DHCP客戶端在得到ACK消息后，會將DHCP中繼頒發給它的IP地址使用“免費的ARP（請求的目標IP和源IP地址一樣，它不希望得到任何回應）”做一個最終的地址沖突檢測。然后正式使用該IP地址。

注意：DHCP中繼，就其本身而言，它沒有任何資格頒發IP地址及其它TCP/IP屬性，它只是代理DHCP客戶端向DHCP服務器做申請，中繼與DHCP服務器交互DHCP消息的過程對于DHCP客戶端而言是透明的。