从哪一侧开始查
DHCP 排障的关键是分清「请求到底有没有发出去」。客户端侧先看租约与释放续租，必要时抓包确认交互走到第几步；设备侧再看统计与事件调试。两侧对齐同一时间点，就能判断丢在哪一跳——客户端没发、中继丢弃，还是服务器没有回应。
基本信息
| 适用平台 | Windows 与 Linux 客户端，配合三厂设备 |
|---|---|
| 客户端侧 | ipconfig 与 tcpdump，以及设备自身的 DHCP 客户端命令 |
| 服务端侧 | 统计命令与事件调试 |
| 中继侧 | 中继统计命令，用于确认请求是否被转发 |
典型使用场景
- 终端拿不到地址或拿到不符合预期的地址
- 排查中继链路上的 DHCP 报文丢失
- 确认四步交互停在哪个阶段
- 服务端统计与客户端现象对不上时对齐时间点
- 割接后 DHCP 服务不生效的快速定位
客户端侧（Windows / Linux）
客户端侧（Windows / Linux）
ipconfig /all # 查看租约来源与 DHCP 服务器
ipconfig /release && ipconfig /renew # 释放并重新申请
tcpdump -i eth0 -n port 67 or port 68 # 抓取四步交互过程
dhclient -v eth0 # Linux 侧看申请细节华为 VRP
华为 VRP
<Huawei> display dhcp client verbose # 客户端地址、租期与 DNS
<Huawei> display dhcp server statistics # 服务端收发包统计
<Huawei> display dhcp server ip-in-use # 已分配地址列表
<Huawei> display dhcp relay statistics # 中继侧再看一遍思科 IOS
思科 IOS
SW-CORE-01# terminal monitor
SW-CORE-01# debug ip dhcp server events
SW-CORE-01# show ip dhcp server statistics
SW-CORE-01# show ip dhcp binding
SW-CORE-01# undebug allH3C Comware
H3C Comware
<H3C> display dhcp client verbose
<H3C> display dhcp server statistics
<H3C> display dhcp server ip-in-use
<H3C> display dhcp relay statistics四步交互与卡点判断
| 阶段 | 报文作用 | 缺失说明什么 |
|---|---|---|
| Discover | 客户端广播寻找可用服务器 | 客户端未发出，或接入链路与中继拦截 |
| Offer | 服务器回应可分配的地址 | 服务器未收到请求，或地址池内没有可用地址 |
| Request | 客户端确认请求该地址 | 客户端未接受 Offer，通常是地址已被占用 |
| Ack | 服务器确认分配完成 | 服务器侧拒绝或资源竞争失败 |
调试输出只在当前终端可见，开调试前确认业务低峰，用完立即关闭（思科为 undebug all）。长时间开启不仅占用 CPU，还会产生大量日志，反而干扰排障。
只盯服务器侧统计容易误判：请求若在客户端或中继处被丢弃，服务器端毫无记录，看现象会像「服务器故障」。客户端抓包与服务端统计要同时看，时间点对齐后再下结论。