把DHCP实验完整跑一遍，最值钱的部分不是记住了几条配置命令，而是把“它到底在链路里做了什么”这件事彻底搞清楚。这篇文章是我在模拟器里从零搭出一套DHCP中继环境的完整记录，覆盖地址池规划、服务器配置、跨网段获取、抓包验证和故障排查，适合正在学交换路由、准备网络认证考试，或者单纯想搞明白“为什么电脑插上网线就能上网”的同学。实验环境是模拟器，但所有协议行为和现象，和真实设备完全一致。
1. 实验目标与拓扑设计
1.1 这次实验解决什么问题
DHCP（动态主机配置协议）是我们每天都在用、但很少仔细琢磨的协议。电脑一插网线就能拿到IP地址，手机连上WiFi就能上网，背后都是DHCP在分配地址、网关和DNS。但真正在实验环境里把它完整跑通，会发现不少隐藏细节：广播请求怎么跨网段？服务器怎么知道该给客户端分配哪个网段的地址？地址冲突又是怎么避免的？
这次实验我给自己定了三个目标。第一，搭建一个包含两个网段的模拟环境，让客户端所在的网段和DHCP服务器所在的网段不同，必须通过中继（Relay）才能获取地址，把跨网段分配的核心机制走一遍。第二，抓包分析完整的DORA交互过程，从报文层面验证Discover、Offer、Request、Acknowledge这四步的状态和关键字段。第三，把实验中容易踩的坑记录下来，比如地址池配置错误、中继失效、客户端拿到保留地址等典型问题。
这个实验适合所有刚入门网络技术的人。不管是准备考网络工程师认证，还是负责公司局域网运维，都可以按这个思路自己搭一遍。实验全部在模拟器上完成，不需要真实硬件，复现成本很低，而且可以随时清空重来。
1.2 模拟拓扑与网段规划
拓扑规划直接决定实验的复杂度和覆盖的知识点。我这次设计了两个网段：
- 网段A（客户端侧）：192.168.10.0/24，网关是路由器接口的192.168.10.1
- 网段B（服务器侧）：192.168.20.0/24，DHCP服务器使用192.168.20.2
拓扑链路是：两台PC（Client-1和Client-2）接入交换机，交换机上联路由器，路由器另一边接DHCP服务器。PC和服务器不在同一个广播域，PC发出的DHCP广播无法直接到达服务器，必须由路由器开启DHCP中继功能，把广播转换成单播转发给服务器。这样设计有两个好处：一是真实场景中服务器集中管理、客户端分散在不同网段的情况非常普遍，中继是必须掌握的技能；二是能验证服务器端地址池选择和giaddr字段的交互逻辑。
设备地址规划如下表：
| 设备 | 接口 | IP地址/网段 | 作用 |
|---|---|---|---|
| Router | GigabitEthernet0/0/0 | 192.168.10.1/24 | 客户端网关，启用DHCP中继 |
| Router | GigabitEthernet0/0/1 | 192.168.20.1/24 | 连接服务器侧网段 |
| DHCP Server | 物理接口 | 192.168.20.2/24 | 配置两个网段的地址池 |
| Client-1 | 网卡 | DHCP动态获取 | 验证同网段/跨网段分配 |
| Client-2 | 网卡 | DHCP动态获取 | 验证地址池分配范围 |
地址规划有个容易忽略的点：地址池范围不能包含网络地址、广播地址，也不能包含网关和路由器接口的地址。如果不做排除，服务器很可能会把网关地址分配给客户端，导致网络异常。我习惯把所有基础设施地址集中分配到地址段的前半部分，然后用排除语句统一排除。
2. 核心机制与关键参数选择
2.1 DORA交互流程到底是怎么走的
DHCP的核心交互被称为DORA，四个字母分别对应Discover、Offer、Request、Acknowledge。用租房子来类比很好理解：客户端是租客，DHCP服务器是房东。
Discover阶段，租客在小区里喊了一声“我要租房”。因为客户端此时还没有IP地址，源IP是0.0.0.0，目的IP是255.255.255.255，目的MAC是广播地址，UDP源端口68，目的端口67。这一步的目的是让网段内所有DHCP服务器都能听到请求。
Offer阶段，房东们听到后纷纷回复“我这有房源”。同网段内服务器直接单播回复客户端，跨网段时则由中继把服务器的Offer转发回客户端所在网段。Offer里携带了候选IP地址、子网掩码、网关、DNS、租期等参数。
Request阶段，租客从多个房东中选择一个，然后再次广播“我决定租这位房东的房子”。为什么要再次广播？因为客户端可能收到了多个Offer，它需要明确告诉所有服务器“我选了谁”，这样其他服务器就能把自己预分配的地址收回，避免地址浪费。这个阶段的目的地址依然是广播，因为被选中的服务器知道客户端的选择，没被选中的服务器也要收到消息才能释放地址。
Acknowledge阶段，被选中的服务器最终确认租约，把正式的IP地址和配置参数下发给客户端。客户端收到ACK后，才会真正配置网卡并使用这个地址。
还有一个细节值得注意：DHCP Discover和Request都是广播，但中继场景下，路由器收到广播后会把它封装成单播转发给服务器，并在报文里写入giaddr字段，记录客户端的网关地址。服务器看到giaddr是192.168.10.1，就知道应该从对应192.168.10.0/24网段的地址池中挑选地址。这是跨网段分配能成功的关键。
2.2 关键参数选型：租期、地址池、排除与保留
配置DHCP不是随便写两条命令就完事，有几个关键参数必须想清楚。
租期（Lease Time）决定客户端可以使用某个IP地址多长时间。默认值通常是1天（86400秒），但实验时我建议把租期改短，比如10分钟甚至2分钟，方便观察租约续租和重绑过程。租期到了50%时，客户端会单播向原服务器请求续租；到了87.5%还没续租成功，客户端会重新走广播Discover流程。这两个阈值T1和T2是协议内置的，配置时不用管，但抓包时能看到对应行为。
地址池是分配IP地址的空间。配置时需要指定网段和掩码，然后设置网关、DNS、租期等参数。地址池大小要覆盖实际终端数量，同时留出足够的扩展空间。例如网段有254个可用地址，实际终端50台，地址池可以设成100个左右，其余保留给静态分配或未来扩容。
排除地址（Excluded IP）用得非常频繁。路由器接口地址、交换机管理地址、打印机、监控摄像头这类需要固定IP的设备，都应该从动态地址池中排除。否则一旦服务器把网关地址分配给某台电脑，整个网段都会出问题。
静态绑定（Static Binding）适合MAC地址已知且需要固定IP的设备，比如服务器、门禁控制器。通过将MAC地址和IP地址做一对一绑定，DHCP服务器只对这个MAC返回固定地址。我通常把整个地址段划分成三块：前50个做静态绑定和基础设施，中间100个做动态分配池，最后一段留作扩展。
2.3 中继配置前必须确认的三个前置条件
开启DHCP中继之前，有三个前置条件必须确认，否则配置了也是白配。
第一，客户端所在网段的网关接口必须有三层地址。中继是发生在路由器三层接口上的功能，如果网关接口还没有配置IP地址，客户端根本无法通过这个网关通信，中继也无从谈起。第二，服务器和路由器之间的路由必须可达。中继把Discover单播发给服务器时，源IP是网关地址，目的IP是服务器地址，这条路径上的路由必须通。第三，服务器必须存在与giaddr对应的地址池。服务器收到中继转发的请求后，会读取giaddr字段找到网关所在的网段，然后从该网段的地址池中分配地址。如果服务器上没有这个网段的地址池，即使收到请求也不会回复。
这三个条件我在实验中全部踩过，尤其是第三个，配置服务器时只建了服务器侧的地址池，导致客户端侧一直获取不到地址，排查了很久才发现是地址池缺失。
3. 完整配置实操过程
3.1 DHCP服务器配置与地址池划分
进入设备后先开启DHCP服务，然后创建地址池。以下命令以模拟器内置的网络操作系统为准，真实厂商设备命令风格大同小异。
system-view dhcp enable服务器上配置两个地址池，一个对应客户端网段，一个对应服务器自身网段。服务器自身网段的地址池可以不用建，但如果想验证同网段分配，也可以建出来做对比。
ip pool pool_client_10 network 192.168.10.0 mask 255.255.255.0 gateway-list 192.168.10.1 dns-list 8.8.8.8 114.114.114.114 excluded-ip-address 192.168.10.1 192.168.10.50 lease day 1这里的关键点是gateway-list必须写成客户端网段的网关192.168.10.1，不能写成服务器自己的网关。因为地址池是面向客户端网段的，下发的网关地址是给客户端用的。DNS可以使用公网DNS，也可以使用实验环境自定义的DNS地址。
我想让实验能观察续租行为，所以同时配置了一个租期很短的地址池做对照：
ip pool pool_client_short network 192.168.10.0 mask 255.255.255.0 gateway-list 192.168.10.1 dns-list 114.114.114.114 excluded-ip-address 192.168.10.1 192.168.10.50 lease 0 0 2配置完可以用display ip pool查看地址池的状态和使用情况，确认地址池创建成功并且没有把网段范围写错。
3.2 路由器网关与DHCP中继配置
路由器上先给两个接口配上IP地址，然后在客户端侧接口启用中继。
system-view interface GigabitEthernet0/0/0 ip address 192.168.10.1 255.255.255.0 dhcp select relay dhcp relay server-ip 192.168.20.2 quit interface GigabitEthernet0/0/1 ip address 192.168.20.1 255.255.255.0 quit注意看第二条和第三条命令，dhcp select relay表示该接口下的DHCP请求全部走中继模式，dhcp relay server-ip 192.168.20.2指定了DHCP服务器的单播地址。在接口上同时执行这两条，客户端发来的广播Discover才会被网关转换成单播，转发给服务器。
有个配置顺序的问题需要提醒：dhcp select relay和dhcp relay server-ip两条命令是配对的，只配了relay模式而没配server-ip，接口收到DHCP请求后会直接丢弃。反过来，只配了server-ip而没配relay模式，接口不会主动干预DHCP报文。这类遗漏在模拟器上经常发生，排查时先检查这两条命令是否同时存在。
3.3 PC端地址获取与连通性验证
PC端在模拟器里通常是图形界面操作，但核心动作等同于Windows下的两条命令。先释放旧地址，再重新获取新地址。
ipconfig /release ipconfig /renew ipconfig /all正常情况下，Client-1会拿到192.168.10.51起的地址（因为192.168.10.1到192.168.10.50被排除），子网掩码255.255.255.0，默认网关192.168.10.1，DNS为配置的公网DNS。验证获取成功只是第一步，还要验证通信链路：
ping 192.168.10.1 ping 192.168.20.2第一个ping验证客户端到网关的链路，第二个ping验证客户端到服务器的链路，后者能顺便确认配置的网关和路由是否正确。如果第二个ping不通，常见原因是服务器自身防火墙或安全策略拦截了来自客户端网段的流量，而DHCP报文不受影响，因此地址能获取但数据不通。
同网段场景和中继场景我都做了对比。把服务器临时挪到网段A或再起一台服务器，客户端不经过路由器直接和服务器通信，获取地址的过程少了giaddr封装，服务器直接广播回复。中继场景则能明显看到服务器响应来自中继转发，并且在服务器端抓包时源地址是网关的192.168.10.1。
4. 抓包分析与协议细节
4.1 Wireshark抓包点位与过滤方法
抓包是整个实验里最有价值的一步。没有抓包验证，配置再成功也只是“看起来通了”。在模拟器环境中，抓包工具通常集成在链路接口上，可以在客户端侧选择抓包接口，然后在PC上执行地址获取操作。
抓包时的过滤条件很关键。DHCP协议基于BOOTP，Wireshark显示框里协议名可能是DHCP，但过滤表达式用bootp或者dhcp都能命中。我习惯用bootp，因为DHCP和BOOTP报文在过滤机制上属于同一类。如果想过滤得更精确，可以加条件限制源或目的UDP端口68，比如udp.port == 68。
抓包点位选择也有讲究。要观察客户端和中继的交互，就抓客户端侧接口；要观察服务器是否收到请求以及如何回复，就抓服务器侧接口。两边都抓是最好的，能对比发现中继是否丢包、服务器是否回复。
4.2 DORA报文关键字段解读
抓到的报文从Wireshark里按顺序看，会依次出现Discover、Offer、Request、Acknowledge四条，分别对应Option 53的1、2、3、5。
第一条Discover报文是最值得细看的。源MAC是客户端网卡MAC，目的MAC是ff:ff:ff:ff:ff:ff，源IP是0.0.0.0，目的IP是255.255.255.255，UDP源端口68、目的端口67。此时客户端没有IP地址，也没有默认网关，所有字段都是空的，只在Option 55的参数请求列表里带上它想要的配置项，比如子网掩码、路由、DNS、域名等。
第二条Offer报文里，yiaddr字段出现了分配给客户端的IP地址，这是最直观的变化。除此之外，Option 53值是2，Option 54记录DHCP服务器自己的IP地址，Option 51记录租期时间，Option 3记录网关地址，Option 6记录DNS地址。客户端正是从这条报文中得知自己将要使用哪些网络参数。
第三条Request报文仍然使用广播地址。为什么在已经有服务器回应的情况下还用广播？因为客户端要向所有DHCP服务器宣告“我选定了谁”，其他服务器收到后就能释放各自预留的地址。报文的Option 53值是3，Option 50携带了客户端请求的IP地址，Option 54携带了选中服务器的IP地址。
第四条ACK报文由被选中的服务器发出，Option 53值是5，yiaddr再次确认最终分配给客户端的IP地址，同时携带租期、网关、DNS、子网掩码等参数。客户端收到这条报文后，才会在本地网卡上正式配置地址。
如果抓到的报文中出现大量Discover但没有Offer，说明服务器没有响应；如果出现Offer但没有Request，说明客户端拿到的Offer可能有问题被丢弃了，比如网关参数缺失。抓包能非常直观地定位问题出在DORA的哪一步。
5. 常见问题排查与实操心得
5.1 典型故障现象与排查速查表
实验过程中我整理了四类最常见故障，整理成表格方便对照排查。
| 故障现象 | 可能原因 | 排查动作 |
|---|---|---|
| 客户端获取不到地址 | DHCP服务未开启、中继未配置或server-ip缺失、服务器地址池不存在 | 检查dhcp enable状态；检查网关接口下relay命令；在服务器上display ip pool |
| 客户端获取169.254.x.x地址 | 客户端未收到任何DHCP响应，自动使用APIPA地址 | 抓包确认Discover是否发出、Offer是否到达；检查广播是否被过滤 |
| 客户端获取到错误网段地址 | 服务器地址池与客户端网段不匹配、giaddr识别错误 | 检查服务器地址池network是否与客户端网段一致；确认中继接口IP正确 |
| 地址冲突导致通信异常 | 网关或基础设施地址未从地址池排除 | 检查excluded-ip-address配置；用ping测试冲突地址 |
169.254开头的地址是Windows系统在无法获取DHCP地址时的临时地址，俗称APIPA地址。看到这个地址基本可以断定DHCP交互完全没有成功，优先排查链路上是否存在广播隔离、中继是否生效。
5.2 中继不生效的典型案例复盘
我在实验里遇到一次中继失效的场景：客户端一直拿不到地址，抓包显示客户端正常发出Discover，但服务器侧没有任何收到请求的记录。排查过程做了三件事：第一，在网关接口上执行display dhcp relay确认中继配置状态；第二，检查中继服务器IP是否写错，结果发现server-ip写成了服务器的旧地址192.168.20.5，而服务器后来改成了192.168.20.2；第三，手动ping测试网关到服务器的连通性。三件事做完后发现是配置错误，但第三件事也提醒我，路由不通同样会导致中继转发失败。
5.3 实操中的避坑记录
几个容易踩的坑值得单独记录。
地址池排除范围一定要包含网关。我在第一次配置时只排除了广播地址，没有排除192.168.10.1，结果有一台客户端拿到了网关地址，整网段的PC都开始不稳定。后来统一把系统预留地址固定在地址段前50个，一条excluded命令全部排除，再没出现过问题。
实验环境模拟器和真实设备有一个差别：模拟器上DHCP服务默认开启状态可能不一致。有些环境里必须先敲dhcp enable全局开启，否则后续配置全部无效，而设备不会给出明确报错，只是客户端一直获取不到地址。这个坑我踩过一次，后来把dhcp enable放在所有配置的第一步，形成习惯后就再没被坑过。
验证顺序也很重要。先验证同网段获取，再验证跨网段中继。如果同网段都获取不到地址，优先怀疑服务器配置和地址池，而不是怀疑中继。中继配置的复杂度更高，把变量控制在最小范围能节省大量排查时间。
最后再分享一个小技巧：把租期设置成2分钟做实验，你会发现抓包里每隔1分钟就能看到一次单播续租的Request，这是观察T1续租的最佳方式。地址池规划、租期设计、中继转发这些知识点，全部可以在一个实验里通过抓包得到直观验证。把DORA每一步的报文看明白了，DHCP相关的疑难杂症基本都能自己定位。
