DHCP Server向Client分配IP地址的先后顺序如下

  1. 分配管理员配置了与Client mac地址静态绑定的IP地址；
  2. 分配Client曾经使用过的IP地址；
  3. 在地址池中顺序查找可供分配的IP地址，找到之后分配给Client。

无论是管理员手工分配IP地址，还是通过DHCP自动分配，非常重要的一个原则就是不能出现地址分配冲突的情况。

DHCP 网络上解决重复的 IP 地址冲突的方法有两种

在DHCP server上实现冲突检测

按照协议规定，Client在申请IP地址时，会在它的本地物理子网上广播一个DHCPDISCOVER报文，用以寻找一个可用的DHCP Server。DHCP Server会通过DHCPOFFER报文回应Client，并携带一个可用的IP地址。在发送DHCPOFFER报文之前，DHCP Server有义务保证这个IP地址没有被网络上其他的设备占用，从而出现IP地址冲突。在DHCP服务器上做冲突检测的方式大致有两种：

一是DHCP服务器向网络上发送一个关于机会IP(准备分配给DHCP客户端的IP地址)的ARP请求，无应答就表示地址没有被使用，当然也不希望得到ARP的回应，如果得到回应则表示该地址已被使用，那么DHCP不会把该地址分配出去；

另一种方案是DHCP服务器会向该IP地址发送ICMP回显消息来检验该IP是否被占用(即发起一个ping的过程)。如果没有主机应答，证明该IP地址没有被使用，可以被分配出去，相反之则不能。如果被占用，需要按照IP地址分配顺序重新分配，并且再次重复IP地址冲突检测。

在client上实现冲突检测

在最后的确认阶段，当Client收到DHCP Server发送的DHCPACK报文之后，并不会马上使用Server分配的这个地址，而是会发送目的地址为Server分配地址的ARP请求报文作最后的确认(即免费ARP)。如果没有检测到冲突，则将此地址与自己绑定。如果检测到冲突，就向DHCP Server发送DHCPDECLINE报文，在Request IP Address(option 50)字段填入Server提供的发生冲突的IP地址。发送完成后，等待一段时间再开始重新申请IP地址，直至申请到一个可用的IP地址。

注：

交换机是不支持DHCP的冲突检测机制的

存在DHCP中继代理的情况下

关于DHCP的冲突检查_DHCP

DHCP的中继代理的工作原理：

  1. 第一步：

DHCP客户端发送DHCP的Discover广播寻找本地子网上的DHCP服务器，毫无疑问，这个寻找将失败，因为本地子网上根本没有部署DHCP服务器，但是，此时DHCP的中继代理路由器R1的E1/0(192.168.5.1)会收到这个Discover广播消息。

  1. 第二步：

中继代理路由器会帮助DHCP客户端到指定的DHCP服务器去申请IP地址，这里所谓指定的DHCP服务器，事实上，就是在中继路由器上申明了谁是DHCP服务器，比如申明192.168.4.1为DHCP服务器，那么DHCP的中继路由器会将Discover消息单播到DHCP服务器(192.168.4.1)，注意，此时中继使用单播的方式把Discover消息发送到DHCP服务器，因为中继明确的知道它该向哪台DHCP服务器进行申请。

  1. 第三步：

DHCP服务器会以单播的方式回应中继的Discover消息，并发送Offer消息，该消息中包括了DHCP可以给中继提供的机会IP(192.168.5.2)，这个Offer消息以单播的形式发送，因为，DHCP服务器知道中继是谁，并且在该消息中包括了中继的IP地址，值得提出的是，DHCP服务器向中继提供机会IP(192.168.5.2)之前，它还是会做一个IP地址冲突检测，它需要知道192.168.5.2这个IP地址，在网络上是否有主机正在使用它，它的检测方式是发送一个目标地址为192.168.5.2的ICMP回显消息，如果没有回应，说明该地址没有被使用，可以被分配出去，反之则不能；DHCP服务器还会检测与中继的连通性，确保中继能成功的得到这个Offer消息。在这里DHCP服务器为什么不使用ARP进行IP地址冲突探测？原因很简单，因为在通过中继申请IP地址的DHCP环境中，DHCP提供的IP地址通常都不是本地子网的IP地址范围，ARP不能穿越路由器工作。

关于DHCP的冲突检查_DHCP_02

  1. 第四步：

中继向DHCP服务器发起DHCP的Request请求消息，该消息仍然以单播的方式发送，这与本地子网上DHCP的工作原理不同，在本地子网上的这个过程应该是以广播的形式进行发送，而在中继的环境中，中继以单播发送，因为在这种情况下，通信双方是很明确的，不可能存在有其它的DHCP服务器向中继提供IP，两个原因：第一个原因是中继设备上会明确指示它该向哪台DHCP服务器申请IP；第二个原因是中继发起DHCP的Discover消息时，就是单播发送的，不会有第二台DHCP服务器来为中继提供IP，因为它不会自作多情。

  1. 第五步：

DHCP服务器收到中继的单播Request消息后，会回应一个ACK消息给中继，指示IP地址的租期正式生效，注意该消息仍然是以单播的形式发送，前面已经描述了原因，这里不再重复描述。

  1. 第六步：

事实上述第二步到第五步对于DHCP客户端而言是完全透明的，它看不见中继为它完成IP地址申请的过程。它只能看见中继与自己的DHCP消息交互过程，当DHCP的中继成功的从DHCP服务器获得地址后，中继会给DHCP客户端发送一个DHCP的Offer消息，告诉DHCP的客户端可以提供给它的IP地址，注意，此时中继就无需再检测该IP地址在网络上是否有冲突的可能性了，因为这个过程在上述的第三步中已经做了检测。

  1. 第七步：

DHCP客户端在收到DHCP中继所提供的Offer消息后，会向DHCP的中继发送一个DHCP的Request消息，正式请求IP地址。该消息以广播的形式发送，为什么是会以广播形式发送，在标准的DHCP环境已经有明确说明。

  1. 第八步：

DHCP中继收到客户端的Request消息后，会回应一个ACK消息给DHCP客户端，申明租约正式生效，然后DHCP客户端在得到ACK消息后，会将DHCP中继颁发给它的IP地址使用“免费的ARP(请求的目标IP和源IP地址一样，它不希望得到任何回应)”做一个最终的地址冲突检测。然后正式使用该IP地址。

注：

DHCP中继，就其本身而言，它没有任何资格颁发IP地址及其它TCP/IP属性，它只是代理DHCP客户端向DHCP服务器做申请，中继与DHCP服务器交互DHCP消息的过程对于DHCP客户端而言是透明的。

参考 ​​http://blog.51cto.com/7658423/1279320​​