DHCP实验网络课程里几乎人手一份的东西看起来无非是配个地址池、让终端点一下“自动获取IP”然后截图交差。但我前后把这套实验完整跑了很多遍从单网段跑到跨网段从路由器内置服务跑到独立DHCP服务器中间踩过的坑比想象中多得多。这篇文章就把DHCP实验从拓扑搭建、DORA过程拆解、地址池配置到DHCP中继排障的完整链路捋一遍适合正在学网络基础的学生也适合准备网络认证、或者偶尔要处理办公网IP分配问题的运维朋友。如果你已经会配地址池却说不出为什么客户端跨网段就收不到Offer这篇东西应该能帮你把这块补上。1. 实验环境怎么搭拓扑、设备和地址规划一次理清1.1 模拟器与设备选型GNS3上怎么搭出最小可用拓扑我自己平时跑这个实验用GNS3比较多原因是抓包方便设备的启动方式、命令行习惯也更接近真实环境。如果你手头没有实体设备用Packet Tracer也能把流程跑通只是有些细节没有GNS3看得直观。一个最小可用的DHCP实验拓扑其实不复杂一台路由器、一台二层交换机、三台PC就够用了。GNS3里添加设备时有一个容易忽略的点路由器默认可能只有两个接口如果要做跨网段实验至少需要保证路由器有两个三层接口可用。我习惯把接口规划成“一个口接模拟的上联区域一个口接内网交换机和PC”。很多人在拓扑拖完之后发现PC插上交换机却迟迟拿不到地址先检查的往往是地址池最后才发现路由器接口一直是shutdown状态。所以在配置DHCP之前先敲一遍show ip interface brief确认参与实验的接口都是up/up这是整个实验的地基。如果你想把实验做得更接近生产环境还可以把其中一台PC换成Linux虚拟机装上DHCP客户端工具用命令行主动发起地址请求。这样能更直观地看到客户端侧完整的状态变化比在图形界面里点“renew”要有感知得多。不过第一次做实验还是建议先用Windows自带的自动获取把DORA流程看明白再逐步换工具。1.2 两种DHCP服务形态内置服务与独立服务器的取舍这个实验里“DHCP服务器”可以由两种角色扮演。第一种是路由器或三层交换机上直接开启DHCP服务配置简单适合教学环境第二种是独立的DHCP服务器比如局域网里一台跑着DHCP服务的Linux主机或Windows Server。这两种形态在实际生产中都很常见实验时建议都接触一遍。我个人的建议是第一遍做实验先在路由器上把DHCP服务开起来省事而且所有状态都能用show命令直接看。等到你理解了整个分配流程再把服务器换成独立主机在配置文件里手动指定网段和地址范围。跨网段实验尤其建议用独立服务器来做因为生产环境里DHCP服务器很少和终端在同一个广播域这时候你会发现ip helper-address这条命令的意义比在纯路由器实验中重要得多。1.3 地址规划给整个实验定好“坐标系”动手配置之前先把IP规划写清楚不然中途很容易乱。我常用的规划如下设备/接口IP地址作用路由器上连接服务器侧接口192.168.1.1/24作为服务器侧网关和后续中继的标识路由器连接内网交换机的接口192.168.10.1/24作为内网网关也是DHCP池里的默认网关二层交换机不配置IP透明转发广播帧隔离不了DHCP广播PC1-PC3DHCP自动获取192.168.10.2-192.168.10.200测试DHCP分配效果为什么地址池要留一段排除地址因为网关192.168.10.1肯定不能分给终端如果以后想加一台打印服务器或者固定IP的网络打印机也需要一个保留地址。所以地址池规划成192.168.10.0/24实际分配范围从192.168.10.20开始比较合理。先把规划写在纸上再往设备上敲命令能避免很多低级错误。2. 动手配置前先把DHCP的运行机制问一遍“为什么”2.1 DORA四步的背后为什么Request还要广播一次DHCP的完整交互过程被叫了很多年的DORA四个字母分别是Discover、Offer、Request、Ack。网上关于这一步的图解一抓一大把但很多人只记住了名字没理解每一步为什么要这么做。客户端一开始并不知道局域网里有哪些DHCP服务器所以Discover广播出去本质上就是在喊“谁手里有多余的IP分我一个”。所有收到这个广播并且还有空闲地址的服务器都会回应一条Offer。但Offer到达客户端之后客户端只会选择第一个到达的或者它主观“看上”的那一台而不是把所有Offer都收下。这里有一个容易忽略的点服务器在发出Offer的时候会把这个地址临时预留一段时间防止别人也把它分走。紧接着客户端发送Request。这个Request看起来只是告诉选中的服务器“我就要这个地址”但它偏偏再用广播发送而不是单播给选中那台服务器。原因很巧妙局域网里可能还有其他DHCP服务器它们刚才也发出了Offer并预留了地址现在听到客户端的Request之后发现自己没有被选中就可以把之前预留的地址释放回地址池。如果Request只发给选中的服务器其他服务器会一直等到预留超时才释放地址在实验室里无所谓但在地址紧张的办公网里就是浪费。最后服务器回Ack客户端拿到完整配置开始使用这个地址。整个流程至少能看出来DHCP设计得非常重视“避免地址浪费”这件事后面所有租期机制也都是围绕这个核心展开的。2.2 报文中值得重点看的字段Option与giaddr做这个实验的时候我强烈建议打开Wireshark抓一次包因为只看配置命令很难理解协议本身。抓包不需要认识DHCP报文里所有字段但有几个地方要重点看Option 53消息类型标识当前包是Discover、Offer、Request还是Ack。Option 50客户端希望获取的IP地址比如客户端上次用过某个地址会在Discover里把这个地址带上。Option 51租期长度单位是秒。Option 54服务器标识也就是客户端选定的那台服务器地址。Option 55参数请求列表客户端会告诉服务器“我需要网关、DNS、域名”等信息。giaddr这个字段平时是0一旦经过中继设备转发就会被填成中继设备接收请求的那个接口IP。这些字段不是随便看看就完事的排障时非常有用。比如你发现客户端能拿到IP但拿不到DNS抓包去看Offer里返回的Option 6是不是空的就能顺着链条排查是服务器没配DNS还是DNS配置被中间设备过滤掉了。2.3 看见169.254.x.x第一反应是什么很多人在实验里看到客户端IP变成了169.254.x.x第一反应是“是不是地址池满了”。其实这个地址是操作系统自动分配的一个备用地址说明网卡在反复尝试DHCP之后依然没有得到任何有效的Offer。169.254.x.x的出现只代表一件事客户端和DHCP服务器之间的交互断了。看到这个地址之后正确的排查顺序是先确认客户端和服务器在同一个广播域再确认服务器服务确实在运行接着在客户端侧抓包看Discover有没有发出去、有没有收到Offer。如果Discover都没发出去问题大概率在网卡或客户端配置如果Discover发出去了但收不到Offer再往服务器和中继方向查。这个地址就像是DHCP世界里的“故障指示灯”每次看到它都意味着四步握手没有完成。3. 路由器上开DHCP服务从地址池到客户端的完整配置3.1 地址池相关命令一条一条说清楚路由器上的DHCP配置并不复杂但每一条命令都有含义。我这里以某主流厂商设备为例给出一个可以直接照着敲的配置! 先排除掉需要固定使用的地址 ip dhcp excluded-address 192.168.10.1 192.168.10.20 ! 创建地址池并分配网段 ip dhcp pool LAB-POOL network 192.168.10.0 255.255.255.0 default-router 192.168.10.1 dns-server 192.168.10.1 223.5.5.5 lease 0 0 30先看排除地址这行。192.168.10.1是网关必须保留而把它到192.168.10.20都排除是为了给以后可能出现的固定IP设备留空间。第一次做实验时我犯过一个错误就是排除了整个网段结果客户端当然一个地址都拿不到。所以这条命令虽然简单敲的时候还是要过一下脑子。然后network后面指定的是分配给客户端的网段注意这里是网络地址加掩码不是接口IP。default-router是下发给客户端的默认网关必须和路由器上连接该网段的接口IP一致否则客户端能分配到地址也上不了网。dns-server可以写路由器接口IP让路由器做DNS转发也可以直接指向公共DNS。实验环境下建议至少配置一个能用的DNS不然“能拿到IP但解析不了域名”会让你误以为DHCP还有问题。租期这里我设置的是30分钟。实验中不建议把租期设太长因为你要反复测试地址获取、续租、释放等行为租期太长的话你改完配置还得等很久才能看到效果。3.2 客户端验证从申请到续租完整走一遍配置完服务器端就能在客户端看到效果了。Windows系统里依次执行ipconfig /release和ipconfig /renew命令的意思是先释放当前地址再重新发起DHCP请求。为什么顺序不能反因为如果网卡上还保留着旧的租约renew会先尝试续租旧地址而不是重新走完整的DORA过程你看到的抓包可能就不对。在路由器上执行show ip dhcp binding可以看到当前已经分配的地址列表里面有客户端MAC、分配的IP、租约剩余时间。这个命令是验证DHCP实验是否成功的核心依据。你还可以故意把PC网卡禁用再启用观察客户端重新申请地址的行为以及路由器上binding表的变化。整个过程能帮你把“DHCP是动态的”这句话变成看得见摸得着的状态变化。如果是Linux客户端则可以使用dhclient -r释放地址再用dhclient加网卡名重新获取地址。这里有一个小细节有些Linux环境下释放地址之后网卡上可能会短暂出现0.0.0.0这是正常的紧接着的DHCP请求过程会在几秒后完成。3.3 地址池设计里的三个常见误区第一个误区是把地址全部排除了。我见过有人为了方便直接把整个网段排除掉结果池里一个可分配的IP都没有客户端反复请求路由器日志里全是“address pool exhausted”。第二个误区是default-router漏配。分配出去的地址没有网关客户端就会变成一个“能拿到IP但哪都去不了”的状态。第三个误区是租期过长。如果租期设置成几天客户端获取一次地址之后你后面无论怎么调整池里的参数已经拿到地址的机器都要等到续租时才会感知到变化。所以做实验时我建议先刻意制造一次“地址池耗尽”的现象看看客户端会是什么表现再恢复正常配置。这种反向验证比直接看正常流程更能加深对DHCP工作机制的理解。4. 跨网段分配还得靠中继一条命令背后的转发逻辑4.1 广播为什么过不了三层中继为什么能解决基础DHCP实验做到这里你已经能看到客户端和服务器在同一网段下正常交互。但现实办公网通常不是一个网段而DHCP Discover又是一个广播包。路由器默认不会把广播从一个网段转发到另一个网段因为无差别转发广播会迅速把网络带宽吃光也会带来严重的安全问题。所以如果服务器的地址池在另一个网段客户端发出的Discover就只能在自己的广播域里“喊”永远到不了服务器那边。解决办法是在连接客户端网段的三层接口上配置ip helper-address指定DHCP服务器的IP地址。这条命令的原理是把特定类型的广播报文转成单播转发给指定的服务器。这里一定要强调的是它只处理特定协议比如DHCP、BOOTP、DNS、TFTP等并不是把客户端的所有广播都一股脑转发过去。有些实验报告中这条命令只是被当作“玄学配置”但要真正理解它你得知道这是“定向的协议代理”不是“广播大挪移”。4.2 giaddr字段与地址池选择跨网段排障的关键跨网段场景里理解giaddr字段是重中之重。当路由器收到来自客户端网段的DHCP广播后会用自己的接收接口IP去填充giaddr字段然后单播给DHCP服务器。服务器看到giaddr非零就知道这个请求来自哪个网段然后从对应的地址池里挑一个地址。这意味着服务器端地址池的network必须和中继接口所在网段匹配否则逻辑就断了。举个例子客户端在192.168.10.0/24网段路由器接口IP是192.168.10.1中继配置指向192.168.1.5的服务器。服务器收到经过中继转发的Discover后发现giaddr是192.168.10.1就会去自己的地址池里找network 192.168.10.0的池子来分配。如果你的服务器只配了192.168.1.0/24的池子那即使服务器和路由器之间的网络完全通它也没办法回应这个请求因为你要求它分配一个它根本“不管理”的网段地址。这个机制也解释了为什么跨网段故障的排查重点经常在服务器端而不是中继端。跨网段时服务器侧抓包看到的源IP往往不是客户端IP而是中继设备的接口IP很多新手第一次看到这个现象会一脸懵其实这正是giaddr机制在起作用。4.3 中继配置与抓包验证中继配置本身很轻量在网络设备上就是一句interface命令的事interface GigabitEthernet0/0 ip address 192.168.10.1 255.255.255.0 ip helper-address 192.168.1.5假设DHCP服务器地址是192.168.1.5服务器侧接在同一台路由器的另一个接口上。配置完成后我在客户端重新renew一次然后分别在客户端侧和服务器侧抓包对比一下两边看到的报文。客户端侧能看到完整的Discover广播和来自中继转回的Offer服务器侧则只看到一个源IP为192.168.10.1的单播请求。看完这个对比你就能明白之前说的“广播不出三层”到底是什么意思也能理解为什么中继是这个实验里不可跳过的一环。如果时间允许可以把ip helper-address那条命令临时删除再让客户端renew一次观察客户端一直拿不到地址的表现。做过这个对照实验之后以后遇到真实网络中“某些网段能拿到地址、某些网段不行”的情况你会第一时间想到是不是哪个三层接口漏配了中继。5. 抓包与排障拿不到地址时按现象对号入座5.1 常见故障现象速查表把实验里经常出现的问题整理成下面这张表按现象定位能省很多时间现象可能原因优先排查方向客户端一直显示169.254.x.x客户端没收到有效Offer抓包看Discover有没有到达服务器确认服务器服务是否运行拿到的IP不在规划的网段里局域网里还有其他DHCP服务在回应停止电脑上多余的DHCP/共享网络服务抓包看Offer来源能拿到IP但是网关不通default-router漏配或写错检查地址池里的default-router是否等于三层接口IP能拿到IP但域名解析不了DNS配置为空或指向了不存在的服务器检查dns-server配置和客户端拿到的Option 6跨网段客户端拿不到地址中继没开或服务器没有对应网段地址池检查ip helper-address和服务器地址池network地址冲突提示频繁池内地址和手工配置的静态IP重叠检查是否有设备手动配置了池内地址修改排除范围这张表不只是一个排障参考也是一种很好的“反向学习”工具。做实验的时候可以故意制造其中几种故障观察现象和抓包结果再通过恢复配置来验证你的排查思路对不对。5.2 Wireshark抓DORA位置不同看到的完全不一样抓包是整个DHCP实验里最有价值的一步。Wireshark过滤器可以直接用udp.port 67 || udp.port 68也可以直接输入bootp或者dhcp作为显示过滤器两种都能过滤出DHCP流量。在客户端侧抓包会看到完整的四步过程Discover的源IP是0.0.0.0目的IP是255.255.255.255源端口68目的端口67Offer由DHCP服务器发出目的地址通常写的是客户端的MAC地址因为这时客户端还没有IP只能靠MAC来识别Request重新变回广播Ack再单播给客户端。每一步的目的地址变化背后都有原因对着抓包结果再看一遍协议的理论解释理解会清晰很多。如果在中继链路或者服务器侧抓包看到的景象完全不同。服务器收到的请求源IP是中继接口的IP而不是客户端的0.0.0.0服务器回应时也不再直接发给客户端而是发给中继设备由中继转给客户端。这个细节可以说是检验你是否真正理解DHCP中继的关键。很多人在这里会困惑“为什么服务器收到的源地址不是客户端”一旦想通了giaddr机制整个跨网段流程就通了。5.3 我踩过、也帮别人排查过的几个典型坑第一个坑是路由器接口没启用。我见过不止一次地址池、排除范围、DNS都配得好好的但客户端就是拿不到地址最后发现接口一直处于shutdown状态。原因很简单接口没有起来DHCP服务再有地址也无从下发。所以排查任何网络问题前先看接口状态这个习惯能帮你少走很多弯路。第二个坑是电脑上还开着其他DHCP服务。比如虚拟机的NAT网卡、某些共享软件自带的DHCP功能这些服务可能会在局域网里“抢答”。客户端一旦收到多个Offer选择结果是不可控的抓包看到Offer来源不止一个就要考虑是不是本机或旁边设备有隐藏服务在捣乱。第三个坑和DHCP Snooping有关。有些模拟器环境或者交换机上开了DHCP Snooping功能默认会把非信任端口的DHCP报文全部丢弃。实验环境里为了简化问题通常不建议开启这个功能但如果你的实验环境本身就有这个功能客户端一直拿不到地址时也要怀疑是不是被Snooping拦了。第四个坑是静态IP和动态池重叠。有的人习惯给打印机或测试设备手动配置一个192.168.10.x的固定IP但地址池没有排掉这个范围。结果打印机占用的地址被分给了其他终端于是现场出现地址冲突严重时整个网段的终端会轮流掉线。做实验时先规划好排除范围这种问题其实完全可以避免。第五个坑是用debug命令不关。调试命令比如debug ip dhcp server packet确实能输出很详细的过程但实验做完之后一定要记得用undebug all关掉否则路由器的CPU会被持续刷屏拖累。尤其是模拟器环境下这个问题更容易被忽略最后整个设备卡死你还以为是自己配置搞错了。这组实验做下来我最大的体会是DHCP的配置命令确实少但这个协议的含金量都在细节里。如果你已经能不看文档指着抓包窗口把Request为什么广播、Offer为什么单播、跨网段为什么看giaddr解释清楚那这个DHCP实验算是真正入门了。后续想往深处挖可以把路由器换成Linux上的dhcpd再跑一遍观察租约文件的底层逻辑或者把DHCP Snooping打开看看它对整个分配过程的影响。实验的价值不在于第一次把地址拿到的成就感而在于你能把“为什么”讲给自己听。