做DHCP实验很多人配完三台设备看到PC自动拿到了IP就以为完事了。这不是实验这顶多算“验证配置”。我这句话可能有点刺耳但确实是我见过太多人的通病——DHCP实验真正值钱的地方不在于“自动获取IP成功”而在于你把整个交互过程拆开看清地址是怎么发出去的、租约是怎么维护的、故障又是怎么暴露的。这篇文章我会从零开始把我自己实际做过的一套DHCP实验完整摆出来。环境不算复杂一台作为网关与DHCP服务器的网络设备、一台傻瓜交换机、几台终端外加抓包工具。适合刚学网络、准备网工认证或者工作中要自己排查终端上不了网问题的人。照着这套思路做完你能回答清楚几个很关键的问题客户端为啥有时拿不到IP地址池快满了会怎样续租的报文凭什么能简化流程1. 别把DHCP当成“自动填IP”它的底层逻辑其实是一笔租约先纠正一个最常见的认知偏差。很多人都把DHCP理解成“服务器给客户端发个IP”好像是一次性的配置下放。真实情况完全不是这样DHCP是向客户端“出租”一个IP地址租期一过这个地址要被收回重新放入地址池。这一点是整个实验的灵魂。如果你脑子里没有“租约”这个概念后面所有抓包、所有故障模拟都会看得云里雾里。1.1 那四个报文才是DHCP真正的骨架IP地址的分配过程严格来说没啥魔法就是客户端和服务器之间握手交换四个关键报文。你不需要背RFC文档但要把它们当成一条流水线来理解。DHCP DISCOVER客户端找网段里有没有“管地址的人”这是一个广播包。DHCP OFFER服务器回应“我这有地址给你预留这个”通常是单播或广播。DHCP REQUEST客户端说“我就要这个地址”同样广播出去。DHCP ACK服务器盖章确认“好这个地址正式归你用一段时间”。这个流程有个容易忽略的细节OFFER阶段只是“预留”到了ACK之后地址才算真正分配给客户端。如果服务器在收到REQUEST后发现问题会回一个DHCP NAK客户端就得重新从DISCOVER开始。我见过有人用“租房子”来比喻这个过程其实并不完全贴切租房子是你先看中再签合同而DHCP是中介已经帮你锁定了房源你签完合同才算定下来。不过“预留”和“分配”的区别真的很重要你在抓包里看到OFFER不能立刻下结论说“这个PC已经拿到地址了”。1.2 租约、续租和冲突检测不搞清楚这三个词实验等于白做租约最基本的行为就是地址有使用寿命。比如你给地址池设置的租期是12小时那客户端用满一半时间50%后就会主动找服务器续租。续租就不需要把四个报文完全重来一遍了客户端会直接发单播的DHCP REQUEST询问“这个地址我还能继续用吗”。服务器同意了就回ACK租约时间重新开始算不同意就回NAK客户端乖乖去走完整的四报文流程。冲突检测也很值得玩味。客户端在拿到OFFER之后、发出REQUEST之前其实会先发一个免费的ARP探测问一下“这个IP有人用吗”如果局域网里有人手工配置了相同IP对方会回应ARPDHCP客户端就会放弃OFFER重新开始DISCOVER。这个机制放在实验里是用来模拟IP地址冲突的必要前置理解。我在后面第4章的故障模拟里就是靠这个细节人为制造了冲突场景一开始很多人都没意识到客户端自己就会检测冲突。2. 拓扑与规划实验开始前先把“谁发地址、谁拿地址、谁中转”定清楚DHCP实验最常见的问题是拓扑随意、规划更随意。有人直接在虚拟机里把路由器、交换机、PC全堆在一个网段模拟软件自带的DHCP服务还留着没关结果抓包一团乱。这里我给出的建议是先别碰设备在纸上把这几个角色画出来。2.1 我用的环境与最小拓扑我实际做的这套实验用的是某款常见的网络模拟软件但以下思路完全适用于真实交换机路由器和Linux服务器混合组网。拓扑只需要三部分一台DHCP服务器我用的是网络设备上集成的DHCP服务也可用一台虚拟机里的Linux服务器替代一台二层交换机纯透传不配置任何DHCP相关功能若干终端PC其中一两个设置为DHCP自动获取另一个手工配置IP用于模拟冲突。我的网段是192.168.20.0/24网关和DHCP服务器放同一台设备上地址是192.168.20.1。地址池规划了两段一段是给普通PC用的动态池另一段是给打印机这类固定设备做的保留地址。这么做不是小题大做而是为了后面讲保留地址时有个对照物。2.2 地址池、保留、租期这三个参数怎么配才合理配置DHCP池子最忌讳“想到什么填什么”。我给自己的规划定了三条约束后面实验全程都受益。第一地址池不要覆盖整个网段。比如我的网段是192.168.20.0/24但池子只开了192.168.20.100到192.168.20.200。这样网关192.168.20.1、交换机管理地址192.168.20.2、留给手工配置的测试地址192.168.20.50全都在池子外面天然不会跟动态分配撞车。第二固定设备的保留地址要放在池子范围内但绑定MAC。我预留了192.168.20.150给一台模拟打印机配置项就是把MAC和IP绑定。这样做的好处是客户说“打印机IP怎么又变了”这种问题能一次性被堵死。第三租期在实验环境里别用默认24小时改成10分钟。这不是鼓励生产环境也这么做而是为了方便观察续租过程。10分钟租期意味着你抓包十分钟左右就能看到续租报文实验效率会高很多。配置完这些我的服务器侧核心配置大概是这么个样子dhcp enable dhcp server ip-pool pool_dynamic network 192.168.20.0 mask 255.255.255.0 gateway-list 192.168.20.1 dns-list 192.168.20.1 lease day 0 hour 0 minute 10 excluded-ip-address 192.168.20.1 192.168.20.50 dhcp server ip-pool pool_static network 192.168.20.0 mask 255.255.255.0 gateway-list 192.168.20.1 static-bind ip-address 192.168.20.150 mac-address 00e0-fc12-3456 lease day 30 hour 0 minute 0注意我这里用的是模拟设备命令到了真实厂商设备上语法会有差异。但逻辑共通的部分是先建池子再指定网段和网关然后排掉不该分配的地址最后绑定特殊设备。这个顺序别反特别是excluded-ip-address与static-bind的顺序。如果先把保留地址加入池子再写排除部分设备会报冲突。3. PC拿到地址的全过程抓包验证四个交互阶段配置弄完后真正的好戏才刚开始。这个实验最让人上头的时刻是你在抓包软件里完整看到从DISCOVER到ACK四个报文依次出现的那一刻。比看状态栏里“已连接”三个字踏实得多。3.1 抓包前必须忍住的两个缺省行为先说两个容易翻车的细节。第一Windows和多数桌面系统的DHCP客户端在开机重新获取地址时会先走“旧地址续租”流程。也就是说如果PC之前已经拿到过IP你现在抓包很可能看不到完整的四报文交互只看到两三个包就结束了。这会让实验结论变得很单薄。所以我建议在设备上先执行一次“释放地址”操作Windows下就是ipconfig /release再执行ipconfig /renew。第二抓包软件的过滤器不能只在“过滤栏”里写bootp或dhcp。很多人以为过滤了DHCP就万事大吉结果没看到免费ARP就忽略了冲突检测环节。我的做法是同时开一个ARP过滤页签两边对照看。因为客户端在发出REQUEST前会发免费ARP这个包恰恰能证明客户端自己也会做冲突检查。3.2 从DISCOVER到ACK每个包都意味着什么在PC端释放地址并开启重新获取后我用抓包软件捕获了以下完整过程。为了让你看得明白我把关键字段拆一下DISCOVER源0.0.0.0目的255.255.255.255客户端还没有IP只能广播喊话。这个包里有个字段很重要——选项55请求参数列表里面是客户端希望服务器下发的参数清单比如子网掩码、网关、DNS、租期。不同系统请求的参数顺序还不一样但不影响服务端处理。OFFER源192.168.20.1目的255.255.255.255服务器回应说“我这有192.168.20.100”同时还带出了子网掩码、网关、DNS、租期10分钟以及服务器标识。REQUEST源0.0.0.0目的255.255.255.255客户端选了192.168.20.100。这里有个关键点是它依然用广播而不是单播。为什么因为局域网上可能不止一台DHCP服务器广播REQUEST相当于告诉所有服务器“我选了这台你们其他的OFFER我不用了”。ACK源192.168.20.1目的255.255.255.255服务器确认。从这一刻开始PC才真正把地址配置到网卡上。抓包软件还能直接看到租期时间也就是选项51。我那次设置的租期是600秒所以ACK里显示的lease time就是600。这个数字会在续租时被重新计算。如果你抓到的包没有这些选项先别急着怀疑代码多半是你拿客户端系统自带的防火墙挡住了报文或者抓包端口不在数据通路上。4. 人为制造故障授信接口、IP冲突、地址池耗尽逐一复现实验做到“成功拿到IP”只能算及格。要体现其价值必须反着来把正常的东西故意弄坏观察客户端和服务器各自会有什么反应。这比背十遍协议字段管用。4.1 故障一GVWR接口被关客户端陷入“无IP可用”第一个故障是模拟“服务端接口挂了”。我在DHCP服务器的客户端网段接口上执行了关闭操作然后让PC重新获取IP。结果就是客户端一直发DISCOVER服务器不回OFFER。抓包上看同一行DISCOVER被重发了好几遍间隔从几秒慢慢拉长客户端进入指数退避。这个现象特别适合观察它说明DHCP客户端有重传机制不是傻等而是越来越“不着急”。这个故障的价值在于它帮你理解了为什么真实环境里“终端忽然跳成169.254.x.x自动私有地址”这么常见。169.254是客户端在尝试DHCP失败后给自己分配的一个链路本地地址不会路由。很多人一看到169.254就先检查物理链路但我建议先看服务器接口状态和地址池有没有配置很多时候是接口挂了或VLAN没放通。4.2 故障二手动配置的IP与租约段重叠冲突如何暴露第二个实验是模拟“手工IP”和“DHCP地址”打架。我把一台PC改成手工地址192.168.20.100正好落在动态地址池100到200的范围里。然后让另一台DHCP状态的PC重新获取。结果第一次获取其实可能成功但随后客户端会发现网络异常因为每次它使用这个地址时都有免费ARP回应冲突。这个过程的细节值得单独说我第一次做的时候差点被误导。DHCP客户端在REQUEST前会发一个免费ARP探测。如果192.168.20.100已经被手工那台PC占用对方就会回ARP应答。客户端发现自己要用的地址已经有人回应了就会放弃这个OFFER重新从DISCOVER开始。抓包会显示一跳一跳地反复循环一会儿DISCOVER一会儿又被ARP响应打断就是拿不到IP。这个故障帮我养成一个好习惯检查DHCP分配区域是否与手工地址重叠比先抓包查DHCP报文更优先。任何排除地址、保留地址配置之前都要想一想“这个IP有没有人手工在用”。4.3 故障三池子很小、租期很长服务器怎么拒绝服务第三个故障我把地址池改成只有192.168.20.100到192.168.20.102三个地址租期改成了1440分钟。然后我从交换机的三个接口接入三台PC让它们都自动获取。三台PC各自拿到一个地址使用正常。等第四台PC接入时它发的DISCOVER也会得到OFFER——很多人的惯性思维是“没地址了服务器就该沉默”其实不然。服务器会在OFFER里明确说“没有可用地址”或者直接不回应取决于厂商实现。我抓到的现象是第四台PC不会收到任何OFFER客户端重试了几次宣告放弃最终变成169.254.x.x。这里需要强调一下地址池的占用情况不是看动态地址分配表而是看“过期地址”和“冲突地址”也会占位。一台PC强制关机导致租约还没到时地址会在租期内继续被标记不会马上释放。为此我习惯在地址池之外单独开一个小地址段放故障测试机免得它占用正常PC的地址。5. 排障链路从“没拿到IP”倒推到根因的完整顺序有了前面三组故障的铺垫你的排查思路会比看文档清晰得多。但实际动手时很多人还是会在抓包软件里乱翻。我这里把一套“三步定位法”具体写出来是我自己在实验里反复验证过的一套顺序。5.1 先看哪个字段三步定位法第一步先看客户端网卡是否获得了169.254.x.x这种自动私有地址。如果拿到了说明DHCP请求根本没成功问题大概率在服务器到客户端的二三层链路或DHCP服务本身。第二步再看服务器侧有没有收到DISCOVER。在服务器接口或交换机镜像口抓包如果能收到客户端广播而服务器没回包问题在DHCP服务配置如果连广播都没收到问题在二层链路和VLAN。第三步如果服务器回包了但客户端没收到基本可以判定是报文下发路径被拦截了要么是接口安全策略阻断广播要么是交换机端口隔离了广播域。这三步适用绝大多数“PC拿不到IP”的场景。我非常不建议一上来就打开抓包一顿乱看。你至少应该先确认PC端是自动获取还是手工写了地址这能排除掉一半问题。表格化总结一下现象优先查的地方可能根因客户端169.254DHCP服务器接口状态服务关闭、接口down、地址池耗尽服务器收不到DISCOVER交换机端口VLAN、物理链路VLAN放通问题、口被关、广播被过滤服务器回了OFFER但客户端收不到接口过滤策略、端口安全广播被拦截、DHCP Snooping丢弃、ARP干扰5.2 Wireshark过滤与关键提示以及我踩过的伪故障抓包软件里的显示过滤器我常用的是这两个一个是纯看DHCP包写dhcp或bootp另一个是同时带ARP写dhcp || arp。后者适合同时观察免费ARP冲突和DHCP交互做故障二时能省不少时间。真正想定位服务器回包有没有被网络中间设备吃掉还得看两个细节一是过滤栏里会不会出现重传。如果客户端发出REQUEST后服务器一直没回ACK客户端会重发。二是看包里的选项54“服务器标识”是否指向正确地址。如果网上有多个DHCP服务没关客户端会按应答顺序做选择经常出现“明明服务器地址池有剩余PC却拿了别的网段IP”的诡异现象。我踩过一次特别典型的伪故障PC拿不到IP抓包发现DISCOVER到了服务器但是OFFER也发出去了PC却依然169.254。排查半天最后发现交换机的某个接口开了DHCP Snooping但信任列表里没有包含服务器所接的接口导致OFFER被当作非法报文丢弃。这种情况如果不抓包看双向报文只盯着服务器配置会浪费大量时间。所以做实验时最好一开始就把交换机上的DHCP Snooping与接口信任关系当作排查对象之一。6. 实验后的体会与两条建议我把这套实验完整做完后的最大收获不是“我会配DHCP了”而是理解了为什么很多网络问题的根因会藏得那么深。地址获取成功不代表报文路径健康地址获取失败也不一定是DHCP服务本身的问题。这套逻辑放在真实办公网络、校园网、无线网络里都是一样的。在实验收尾阶段建议你抓包后保留几个关键文件比如正常四交互、租约续租、冲突场景、地址池耗尽场景各存一份。以后别人问起类似问题你不用重新搭环境直接打开pcap就能照着讲。这不是偷懒是建立个人知识库最有效的方式。6.1 DHCP实验真正训练的是什么它训练的是你对“网络里所有设备都在协作”这件事的敏感度。网关提供出网能力交换机透传广播服务器分配地址客户端做冲突检测任何一个环节断了表现都可能一模一样电脑右下角出现黄色感叹号。这也是我建议任何一个网络方向的人哪怕工作已经和DHCP无关也应该做一遍这个实验的原因。它把一个看起来很简单的服务拆成了值得深挖的协议交互而这种拆解能力在排查其他问题时会迁移过去。6.2 想进阶可以再加实验DHCP Snooping 与按MAC保留如果时间允许我强烈建议加两个进阶玩法。第一个是DHCP Snooping在交换机上开启针对DHCP报文的检查功能配置合法接口为信任口其他接口为非信任口。然后模拟有人私接了一台伪造DHCP服务器观察合法客户端最终会拿到谁给的地址。第二个是给打印机电统一做MAC保留再试着改一个错误MAC填入绑定表观察客户端被拒绝的现象。这两个实验做完你对“安全与业务地址规划如何协调”会有非常具体的体感不再只是文档里的一段概念。我在实际做实验的过程中最大的感受是千万不要看到“拿到地址”就停手。多抓一次包多故意配错一个参数多模拟一次断电重启收获会成倍增加。网络这门手艺就是在这种试错和排障中练出来的。
