１关于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客户端而言是透明的。
本文转自 kingsir827 51CTO博客，原文链接：http://blog.51cto.com/7658423/1279320，如需转载请自行联系原作者
