1、DHCP类故障通用排查思路
工程师碰到上述故障时，可以参考如下排查思路，定位问题点：
1）确认故障真实现象
2）确认故障涉及的网络环境，特别是拓扑
工程师必须首先掌握网络拓扑图，至少是故障点到DHCP
SERVER所在设备的整个数据通路上所涉及到的所有网络设备，以及他们之间的物理互联情况，另外还需要考虑一些特殊环境因素可能造成的影响，比如PVLAN应用，SUPER
VLAN应用，MSTP的block端口，是否存在DHCP SERVER欺骗，链路上的加密机是否过滤掉了bootps（UDP 68），bootpc(UDP
67)端口等
3）确认配置是否正确，是否有改动
确认关于DHCP SERVER的一些配置是否正确，是否有被修改过，是否存在一些特殊的参数配置（比如配置client-identifier以实现某个已知的PC获取固定的一个ip地址），是否存在其他冲突的功能配置（比如配置了ACL过滤掉相应地址或者端口）
4）测试故障点到DHCP SERVER间的连通性
可以通过手动设置静态ip来测试故障机与DHCP
SERVER间的通信是否是正常的。
5）通过显示与监控命令来判断故障点
如果配置，联通性没有问题，那就可以通过show，debug命令来查看，监控当前DHCP
SERVER设备的一个工作状态，协议是否正常响应等。
在RGOS 10.4（3）平台上的常见显示及监控命令如下：
show dhcp lease
show ip dhcp
binding
show ip dhcp
conflict
show ip dhcp
server statistics
debug ip dhcp
client
debug ip dhcp
server
6）通过逐点抓包，分析报文定位故障点
通过在故障机，DHCP
SERVER端接口，必要时可能还需要数据通路上的逐点抓包，分析报文交互过程及字段结构等，对比相应RFC文档来判断故障设备，是否环境因素还是软件bug，特别是涉及第三方设备的时候。
2、DHCP SERVER设备上部分网段无法获取IP地址的常见故障排查方法
1）检查配置是否正确，最好做到最小化配置(DHCP
SERVER方面）其他可能影响的配置都先删除
2）检查下有没有误将正常的地址排除掉
ip dhcp excluded-address
172.17.1.1 172.17.10.100 就是将1.1---10.100这10个网段内的地址都排除掉了
3）show ip dhcp
conflict 查看下是否存在ip地址检查冲突的情况，导致无可用地址，如果发现很多表项，可以尝试clear ip dhcp conflict清除后做尝试获取
4）PC端，DHCP
SERVER下联口抓包，设备上debug ip dhcp server packet ，debug ip dhcp server event确认DHCP交互过程在那个节点出问题
3、client-identifier参数设置不当引起客户端无法获取固定地址
问题描述
XX大学5750交换机原软件版本为10.2（2），在57上设置静态dhcp地址分配的方式。设备升级之前，用户上网，获取地址完全正常，当软件版本升级至10.3（4b3）后，所有用户反应无法获取地址，重新将软件版本降回原版本，仍然不能够获取地址。
关键配置
service dhcp
ip dhcp pool
P_192.168.128.173
hardware-address 0013.d43a.8167
host 192.168.128.173 255.255.255.128
lease 1 0 0
dns-server 202.116.64.2 202.116.64.3
default-router 192.168.128.254
!
ip dhcp pool
P_192.168.128.174
hardware-address 0002.b304.1265
host 192.168.128.174 255.255.255.128
lease 1 0 0
dns-server 202.116.64.2 202.116.64.3
default-router 192.168.128.254
!
ip dhcp pool
P_192.168.128.175
hardware-address 0010.c6e2.d3ce
host 192.168.128.175 255.255.255.128
lease 1 0 0
dns-server 202.116.64.2 202.116.64.3
default-router 192.168.128.254
分析过程
拓扑结构为典型的接入+汇聚结构，s57上面的配置也比较正常，物理联通性也是正常的，debug的信息反馈为只能收到discover，但是57没有响应request，后续报文也都没有.在RGOS新版本实现中，通过ClientID来对租约进行识别，如果报文中存在client
identifier选项，但交换机没有配置client identifier，PC将无法获得地址。目前已催促研发尽快更新相关配置文档。DHCP SERVER优先使用client
identifier选项标识DHCP CLIENT，如果不存在此选项，则使用chaddr标识DHCP CLIENT。
解决方法
根据RFC的定义，可以看出该问题为我司软件故障导致的，最佳的方式是需要出临时版本解决，但是也可用下面的方法规避。
增加配置client-identifier
01+用户MAC，如：
ip dhcp pool
P_192.168.128.174
hardware-address 0100.02b3.0412.65
host 192.168.128.174 255.255.255.128
lease 1 0 0
dns-server 202.116.64.2 202.116.64.3
default-router 192.168.128.254
client-identifier选项
= 网络类型 + MAC
网络类型，以太网是01。
4、excluded-address参数配置不合理，PC无法获取地址
问题描述
XX办公网内，s3760作为dhcp
server，总共4个网段，客户反馈原来4个vlan都是可以正常获取地址，但是突然某天就只有vlan 4网段内的用户可以获取地址，其他vlan的用户都无法获取地址，故障机修改为静态ip通信正常。
分析过程
首先判断内网环境，拓扑比较简单，接入+汇聚结构，故障机配置静态ip可以正常通信，表示连通性这块问题不大，下面我们来看下s3760上的配置吧，希望能找到突破口。
ip dhcp
excluded-address 192.168.1.1 192.168.1.9
ip dhcp
excluded-address 192.168.1.250 192.168.1.254
ip dhcp
excluded-address 192.168.2.1 192.168.2.9
ip dhcp
excluded-address 192.168.2.250 192.168.2.254
ip dhcp
excluded-address 192.168.3.1 192.168.3.9
ip dhcp
excluded-address 192.168.3.250 192.168.3.254
ip dhcp
excluded-address 192.168.1.1 192.168.4.9
ip dhcp
excluded-address 192.168.1.200 192.168.4.200
此时我们应该可以惊喜的发现s3760上面错误的配置了一个大的网段的排除地址（ip
dhcp excluded-address 192.168.1.1 192.168.4.9，ip dhcp excluded-address
192.168.1.200 192.168.4.200），导致1.1-4.200的所有地址都无法分配出去，而只有192.168.4.201-192.168.4.254间的地址可以分配出去，这个配置也正好符合客户索反馈的故障现象，只有vlan
4的用可以获取地址。
解决方法
删除错误的配置，或者重新规划下excluded-address需要排除的地址范围。
5、交换机做DHCP服务器，下联PC获取不到地址故障排查
A、确认配置，包括如下几项排查：
1）是否有开启全局DHCP服务命令
Ruijie(config)#service dhcp
2）SVI接口的IP地址是否与DHCP服务器的default-router
IP是否一致；
3）PC所在的VLAN与所配置的DHCP 服务器是否在同一个VLAN；
4）network的子网掩码是否与SVI接口所配置的子网掩码一致。
配置上需要注意，default-router后面配置IP地址后不能再接子网掩码，如下配置是错误的：
Ruijie(config)#ip dhcp pool ruijie
Ruijie(dhcp-config)#network
192.168.1.0 255.255.255.0
Ruijie(dhcp-config)#default-router 192.168.1.254 255.255.255.0
Ruijie(dhcp-config)#exit
Ruijie(config)#int
vlan 1
Ruijie(config-if-VLAN
1)#ip address 192.168.1.254 255.255.255.0
Ruijie(config-if-VLAN
1)#end
Ruijie#wr
出现故障现象时xp的用户能获取到IP地址，win7的用户却获取不到IP。
B、确认配置没有问题后，确认下客户现场环境，包括如下几个方面：
1）中间是否有其他设备，包括是否配置了ACL，端口安全等阻止下联PC的报文通过，确认PC直连到DHCP服务器所在的交换机，看是否能获取到IP地址；
2）确认DHCP 服务器绑定表项被占满，使用如下命令查看
Ruijie#show ip
dhcp binding
3）确认是否冲突表项被占满，使用如下命令查看
Ruijie#show ip
dhcp conflict
如果该表项被占满，由于默认conflict表项永久保存，可以使用如下命令来清除conflict表项
Ruijie#clear ip
dhcp conflict *
4）更换PC或网线测试
C、如果以上步骤依然无法解决问题，可确认如下几点：
1）版本是不是最新，如果不是最新，建议升级到最新版本；
2）如果在1）基础上依然无法解决客户现场问题，单台PC直连DHCP服务器所在交换机，同时PC端开启抓包工具，然后同时在交换机上开启如下debug信息
Ruijie#debug ip dhcp server
events
Ruijie#debug ip dhcp server
packet
搜集完整的DHCP交互过程信息，如果还无法定位，可拨打4008111000技术支持热线联系后台寻求帮助。
6、交换机的SVI接口下面配置主ip与secondary
ip，下联pc动态获取ip，发现只能获取主ip网段的地址？
1）设备做DHCP RELAY：如果一个用户的SVI接口上面配置了一个主ip，一个secondary
ip，那么我们的relay报文是只会携带主ip地址段的网关。所以下联pc只能获取主地址一个网段的ip。即使主地址池分配完了，也无法分配备IP的地址池；
2）设备做DHCP server：如果一个用户的SVI接口上面配置了一个主ip，一个secondary
ip，并且针对主备IP地址都创建了对应的dhcp pool，那么设备先分配主IP网段的地址池里的IP，当主pool池分配完了后，开始分配secondary
IP所在网段的DHCP pool。
7、DHCP如何ICMP回应攻击，导致DHCP地址分配异常
DHCP CONFICT表形成过程：
Client在向DHCP
Server申请IP时，Server先查看地址池，若池中有空余IP则执行ping检测，如果没有回应则直接派发IP地址。若有回应，日志中会显示如下LOG：
*Jul 14
15:46:00.778: %DHCPD-4-PING_CONFLICT: DHCP address conflict: server pinged 172.18.45.39.
因此可能有人用此机制的漏洞，开设ICMP回应攻击，使得短时间内DHCP地址池所有地址被放进conflict表，导致DHCP地址无法分配，如何避免？
全局关闭DHCP ping检测，跳过DHCP地址检测阶段，以此来规避；
Ruijie(config)#ip
dhcp ping packets 0
备注：此时，IP地址冲突的检测则根据客户端免费ARP检测到地址冲突后，会发送DHCP Decline 报文给服务器，服务器根据此报文来将地址添加进dhcp-conflict表；