DHCP中继处理办法

  这两天一直在客户这边测试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就行了；