2. DHCP 服务器故障：地址池耗尽、Option 66/67 配置错误、跨网段 DHCP Relay 问题
DHCP 服务器，说白了就是网络启动的「发牌员」。客户端要启动，得先拿到 IP 地址，还得知道引导文件在哪儿。这个环节要是出问题，整个 PXE 启动就卡死在第一步。我这些年排查过的网络启动故障，少说有一半都跟 DHCP 有关。今天咱们就把这块掰开揉碎了讲清楚。
2.1 地址池耗尽：最容易被忽视的「软故障」
地址池耗尽听起来简单，但实际排查起来往往最坑人。为什么？因为 DHCP 服务器本身没坏，日志里也没有报错，就是客户端拿不到地址。
核心判断方法：
- 客户端网卡灯亮，但一直显示「获取 IP 地址中」
- DHCP 服务器上抓包能看到 Discover，但看不到 Offer
- 服务器事件日志里出现 Event ID 1003（地址池无可用地址）
我在一个工厂项目里遇到过这种情况。生产线新加了一批终端，结果第二天早上全部 PXE 启动失败。查了一圈，发现是 DHCP 地址池的租期设成了 7 天，而终端数量刚好超过了池子大小。你想想看，那些下班不关机的设备把地址全占着，新设备自然拿不到。
我的习惯做法：
给 PXE 启动的客户端单独划一个地址池，租期设短一些（比如 30 分钟）。这样即使设备异常断电，地址也能快速回收。另外，建议在 DHCP 服务器上开启地址冲突检测，避免手工配置的静态 IP 跟池子里的地址打架。
2.2 Option 66/67 配置错误：引导文件找不到的罪魁祸首
拿到 IP 只是第一步。客户端接下来要问：「我的启动文件在哪儿？」这时候就看 Option 66 和 Option 67 了。
| Option | 作用 | 常见错误 |
|---|---|---|
| Option 66 | 指定 TFTP 服务器地址（IP 或主机名） | 写成了 HTTP 地址，或者用了不可达的 IP |
| Option 67 | 指定引导文件名（如 pxelinux.0） | 文件名大小写不对，或者路径写错了 |
嗯，这里要注意一个细节：Option 66 填的是 TFTP 服务器地址，不是 HTTP 服务器。我见过有人把 HTTP 的 URL 直接填进去，结果客户端拿着这个地址去连 TFTP，自然连不上。
避坑指南：
我曾经在一个项目中排查了整整两天，最后发现是 Option 67 的文件名大小写问题。Linux 下的 TFTP 服务器是区分大小写的，pxelinux.0 和 PXELINUX.0 是两个完全不同的文件。建议统一用小写，并且在 TFTP 服务器上确认文件确实存在。
另外，有些 DHCP 服务器支持用 Option 66 传主机名而不是 IP。我个人不建议这么干——万一 DNS 解析出问题，客户端就找不到 TFTP 服务器了。直接填 IP 最稳。
2.3 跨网段 DHCP Relay：广播过不去怎么办？
实际生产环境里，客户端和 DHCP 服务器很少在同一个网段。这时候就需要 DHCP Relay（也叫 IP Helper）来帮忙转发请求。
DHCP Relay 的工作原理其实不复杂：
- 客户端发广播 Discover（目标 255.255.255.255）
- 路由器或三层交换机收到广播，发现是 DHCP 请求
- Relay 把广播转成单播，发给 DHCP 服务器
- 服务器回复 Offer，Relay 再转回广播发给客户端
跨网段 DHCP 故障排查清单：
- 确认三层设备上配置了
ip helper-address指向正确的 DHCP 服务器 - 检查 DHCP 服务器上是否创建了对应网段的作用域
- 确认客户端和 Relay 设备之间的 VLAN 配置正确
- 抓包确认 Relay 设备确实转发了 Discover 报文
我记得有一次帮客户排查，客户端在 VLAN 100，DHCP 服务器在 VLAN 200。Relay 配了，作用域也建了，但就是拿不到地址。最后抓包发现，Relay 设备把 Discover 转发给了 DHCP 服务器，但服务器回复的 Offer 被防火墙拦了——因为防火墙只允许特定端口的流量通过。这种问题，光看配置是看不出来的，必须抓包。
2.4 知识体系总览
下面这张图把 DHCP 相关的故障点串起来了。你可以把它当成排查时的路线图。
2.5 实战排查步骤
如果你现在遇到 DHCP 相关的 PXE 启动故障，按这个顺序来：
- 第一步：确认客户端能否获取 IP
- 在客户端抓包，看有没有 DHCP Discover 发出
- 有没有 DHCP Offer 回来
- 如果没有 Offer，大概率是地址池耗尽或 Relay 没配好
- 第二步：检查 Option 66/67
- 在 DHCP ACK 报文里查看 Option 字段
- 确认 TFTP 服务器地址可达（ping 一下）
- 确认引导文件在 TFTP 服务器上存在且权限正确
- 第三步：跨网段场景专项检查
- 登录三层设备，确认
ip helper-address配置 - 检查 DHCP 服务器上是否添加了对应网段的作用域
- 检查中间防火墙是否放行了 DHCP 端口（UDP 67/68）
- 登录三层设备，确认
一个小技巧：
我习惯在 DHCP 服务器上开调试日志。Windows Server 可以用 netsh dhcp server show scope 查看地址池使用情况。Linux 下用 dhcpd -d -f 前台运行，日志直接打屏幕上，排查起来特别直观。
说白了，DHCP 这块的故障，90% 都是配置问题。地址池规划好、Option 填对、Relay 配通，基本就稳了。剩下的 10% 才是网络层面的问题，比如防火墙拦截、VLAN 不通这些。按上面的步骤一步步来，大部分问题都能在半小时内定位到根因。