DHCP这个协议几乎所有网络入门教材都会讲四步交互画得明明白白考试也爱考DISCOVER、OFFER、REQUEST、ACK这几个名字。但我在带新人的时候发现一个挺普遍的现象能把四个报文名字背下来的人很多真让他打开抓包软件从一堆广播帧里把完整的地址分配过程捞出来、逐个字段对上号的人少得可怜。更麻烦的是实验环境里DHCP几乎不会出错一旦上了真实网络地址池重叠、中继配置漏了、租期设得太短、客户端拿到169.254开头的地址这些问题的排查全都要回到报文层面去看。这篇东西就是围绕这个落差写的。前半部分把DHCP的报文结构、字段含义、租期计时机制拆开讲清楚重点放在教材往往一笔带过的地方比如REQUEST为什么要广播、T1和T2到底怎么算、giaddr字段在跨网段时起了什么作用后半部分是完整的抓包实操从抓包位置怎么选、过滤器怎么写、字段怎么逐条核对到抓不到包的几种典型原因都给出来。适合正在备考网络初级认证的朋友也适合已经上手干活但每次遇到地址分配问题只能靠重启设备碰运气的同行。文中配置以通用思路呈现关键字按你手头的设备做调整逻辑是通的。1. DHCP真正的价值不在自动配地址而在把变更成本压下去1.1 手配IP在小规模下确实没什么毛病先把话说透如果一张网里只有五台设备、拓扑三年不动、也没有笔记本进进出出那手工配静态地址反而是最稳的做法不用管服务器在不在、不用管租期到期、出了问题一目了然。很多老机房到现在还是这么干的我不觉得这有什么问题。DHCP真正开始体现价值是在变化出现之后。设备数量从十台变成两百台笔记本、手机、打印机、监控摄像头全都要接入人员流动导致工位和设备对不上号业务上线要求新网段明天就能用。这时候手工维护一张Excel地址表出错的概率跟设备数量基本是成正比往上走的。我在一个项目里见过地址表最后三个版本同时在用谁也说不清哪个是准的最后是靠全网扫一遍ARP才把冲突理清楚。所以理解DHCP第一个要建立的认知是它是一套集中式的地址租借管理机制不是简单的自动填IP。中心化的地址池意味着地址的分配权收归一处谁在用、用了多久、什么时候该回收都有据可查。这才是它在大网络里不可替代的原因。顺带说一句DHCP管的不只是IP。网关、DNS服务器、域名后缀、NTP服务器地址、WINS现在基本没用了这些参数都可以通过选项字段一起下发。设备多了以后改一次DNS要挨个机器点一遍这种活靠DHCP一个选项就能全网生效。1.2 备考阶段为什么要抠到报文级考试题里DHCP的考法通常比较规矩问报文顺序、问端口号、问租期百分比。但我觉得如果只按考点来学会留下一个很大的空洞你知道有这四个报文但不知道每个报文里装了什么、为什么这么装。举个很具体的例子。很多人第一次抓包会疑惑为什么客户端发出的DISCOVER源IP是0.0.0.0这个地址看起来像个错误值其实是刻意为之——客户端此刻还没有地址只能用全零作为源地址占位目的地址用255.255.255.255做本地广播。同理为什么OFFER有时候是广播、有时候是单播这就牵扯到Flags字段里的广播标志位以及客户端实现上的差异。这些细节不看报文是理解不了的。再比如REQUEST报文教材上写客户端广播REQUEST确认但实际抓包你会发现续租阶段的REQUEST是单播直接发给原服务器的源地址就是自己正在用的那个IP。同一类报文在不同阶段的行为完全不同这个差别在排查为什么续租失败的时候就是关键线索。我的建议是备考阶段至少完整抓一次包把四个报文的每个字段对一遍做完这一次后面看任何DHCP相关的文档都不会再有陌生感。1.3 这个协议的设计里藏着哪些妥协DHCP脱胎于BOOTP保留了BOOTP的报文格式和67/68端口这解释了为什么抓包时用bootp过滤器依然能过滤出DHCP报文——本质上是同一套帧格式DHCP只是把选项字段用起来了。它的设计里有几处明显的妥协理解了这些妥协很多看起来很奇怪的行为就说得通了设计取舍具体表现带来的后果基于广播起步客户端无地址只能广播找服务器广播域边界就是DHCP的天然边界跨网段必须靠中继无认证机制任何设备都能应答DHCP请求存在私设服务器的风险需要额外的防护手段靠租期自愈地址不是永久绑定到期回收租期设置不当会导致频繁续租或地址长期被占依赖客户端自觉客户端发现冲突后要主动发DECLINE客户端实现不规范时冲突地址会被反复下发最后一条尤其值得注意。DHCP服务器本身并不做冲突检测部分实现可以配ping探测但有延迟和漏判它默认地址池里是干净的。真正发现冲突的是客户端——拿到地址后做一次ARP探测发现有别人应答就发DECLINE告诉服务器这个地址别用了。这套机制能不能生效完全取决于客户端实现。2. 四个报文只是骨架字段和选项才是血肉2.1 DISCOVER一个我什么都不知道的广播抓到的第一个包通常是这样的源0.0.0.0目的255.255.255.255UDP源端口68目的端口67。帧层面目的MAC是全F广播。这就是DISCOVER。这个报文里的信息量其实很少但有几个字段值得看Transaction IDxid一个随机数后续三个报文都会带着同一个值。这是把一次交互的四个包串起来的唯一线索抓包时用它做过滤非常有效bootp.id 0x开头的那串就能锁定一次完整会话。Flags16位最高位是广播标志位。置1表示我还没配好IP栈请用广播回我。有些客户端尤其是早期的嵌入式设备、部分PXE引导场景必须靠广播才能收到回应。chaddr客户端MAC地址六字节。服务器分配地址、做静态绑定靠的就是这个字段。Option 53消息类型DISCOVER对应值1。这是区分四个报文最直接的方式。Option 55Parameter Request List客户端在这里列出我想要哪些参数比如子网掩码(1)、路由器(3)、DNS(6)、域名(15)、NTP(42)。服务器会尽量按这个清单来组织OFFER的内容。这个字段挺有意思不同操作系统的请求列表差别很大抓包时靠它猜客户端是什么系统准确率不低。Option 61Client Identifier有些客户端会带通常是类型MAC作用是让服务器在MAC变化比如虚拟机迁移时仍能识别同一台客户端。Option 12Hostname客户端主机名配了的话服务器日志里能看到是谁来的。2.2 OFFER地址池往外掏东西的那一刻服务器收到DISCOVER后从地址池里挑一个可用地址回OFFER。源地址是服务器自己的IP源端口67目的端口68。目的地址是广播还是单播取决于DISCOVER里的Flags位和服务器实现。OFFER里最关键的是yiaddr字段——your IP address也就是服务器打算给你的地址。另外几个字段也值得看siaddr下一个服务器地址主要在PXE网络引导场景里用普通地址分配时一般是0。Option 54Server Identifier服务器自己的IP。这个字段非常重要因为一个网段里可能有多台DHCP服务器客户端要靠它区分是谁给的OFFER。Option 51IP Address Lease Time租期单位秒。比如86400就是一天。Option 58Renewal Time ValueT1和Option 59Rebinding Time ValueT2这两个是可选的服务器不给的话客户端按租期的50%和87.5%自己算。Option 3Router网关地址可以有多个。Option 6DNSDNS服务器列表。这里有个实操经验如果你在抓包时发现OFFER给了地址但客户端拿到后上不了网先看OFFER里有没有Option 3和Option 6。有些服务器配置只写了地址池范围忘了配网关和DNS客户端确实能拿到IP但路由和解析全是空的表现为能ping通网关但打不开网页或者干脆什么都通不了。2.3 REQUEST为什么它要喊给所有人听这是四个报文里最容易让人困惑的一个。客户端已经收到了OFFER明明可以直接单播回复那台服务器为什么还要广播原因是客户端可能收到了多个OFFER。一个网段里如果存在两台DHCP服务器不管是刻意做的冗余还是有人私接客户端会收到两份OFFER。它只能选一个但其他服务器并不知道自己落选了还占着一个地址等着。所以客户端用广播的方式发REQUEST并在里面带两个关键字段Option 50Requested IP Address我想要的是这个地址。Option 54Server Identifier我是向这台服务器要的。广播出去之后被选中的服务器回ACK没被选中的服务器看到Option 54不是自己就把刚才预留的地址收回池子。这个设计用一次广播解决了多方竞争下的资源释放问题挺巧妙的。续租阶段的REQUEST就完全不同了此时客户端已经有地址直接用单播发给原来的服务器源地址是自己的IP目的地址是服务器IP报文里通常不带Option 54因为它就是发给原来那台的。这个差别在抓包里一眼就能看出来也是判断这台机器是在初次获取还是在续租的依据。2.4 ACK之后计时器才开始真正运转ACK是服务器对REQUEST的确认里面包含最终的地址、租期和各项参数。客户端收到ACK后做几件事把地址配到网卡上、按Option 3配默认路由、按Option 6配DNS、启动三个计时器。这三个计时器是很多人记不住的地方其实逻辑很直白计时器触发时间客户端动作报文形式T1 续租计时器租期的50%向原服务器单播REQUEST请求续租单播T2 重绑定计时器租期的87.5%广播REQUEST向任意服务器请求广播租期到期100%放弃地址重新走DISCOVER流程广播假设租期是86400秒一天那么T1在43200秒12小时触发T2在75600秒21小时触发。如果T1时刻服务器没回应比如服务器宕机或者网络不通客户端会一直重试到T2然后转为广播找其他服务器。T2之后还是没回应到租期结束就只能放弃地址此时网卡上的地址会被清掉业务中断。这里有个经常被忽略的点租期设得太短续租流量会明显增加。假设你有500台设备租期设成2小时那平均每分钟就有4台多在发续租请求虽然流量不大但DHCP服务器的日志会被刷得很满排查问题的时候很难找。反过来租期设得太长比如30天地址回收不及时临时设备走了地址还占着池子容易被耗尽。办公网一般设1到8天比较合适访客网络可以设几小时。3. 地址池怎么划几个必须想清楚的问题3.1 地址池的边界要和网关、网段对齐配地址池第一件事是想清楚这段地址属于哪个网段、网关是谁。地址池的network必须和网关所在网段一致否则服务器分配出去的地址客户端根本用不了。假设网段是192.168.10.0/24网关是192.168.10.1那么地址池大概长这样# 通用配置思路关键字按设备厂商做调整 ip pool office-pool network 192.168.10.0 mask 255.255.255.0 gateway-list 192.168.10.1 dns-list 223.5.5.5 119.29.29.29 excluded-ip-address 192.168.10.1 192.168.10.2 excluded-ip-address 192.168.10.100 192.168.10.120 lease day 3 hour 0然后在网关接口上启用全局地址池模式interface Vlanif10 ip address 192.168.10.1 255.255.255.0 dhcp select global注意最后一行很多初学者配完地址池忘了在接口上启用结果客户端一直拿不到地址抓包只能看到DISCOVER反复发一个OFFER都没有。这个坑我见过太多次排查的时候第一件事就是看接口上有没有启用DHCP。3.2 排除地址留多少怎么留地址池里必须排除掉几类地址网关地址本身192.168.10.1不能分给客户端否则网关和客户端抢地址。服务器、打印机、监控NVR这类固定设备它们用静态地址必须排除否则DHCP可能把同一个地址分给别的设备造成冲突。网络地址和广播地址.0和.255正常配置下服务器不会分配但排除掉更保险。预留区给未来扩容或者临时设备留一段。留多少我的经验是按网段规模的10%到20%来留。24位掩码的网段有254个可用地址排除20个左右比较合理。如果这个网段里固定设备特别多比如机房、监控专网排除比例要更高有时候能到40%。还有个细节如果做了多台DHCP服务器做冗余两台服务器的地址池要错开不能重叠。比如A服务器管100-150B服务器管151-200公共部分用排除地址处理。重叠的地址池会导致同一地址被两台服务器同时认为可用冲突概率极高。3.3 租期长短背后的计算租期这个参数很多人是随手填的。其实可以简单算一下。假设某办公网有300台设备租期设为8小时。按最坏情况估算每台设备每天至少续租一次实际上设备开关机会重新走流程续租次数会更多那么DHCP服务器每天要处理的交互大概在600次以上平均每分钟不到一次压力可以忽略。如果租期设为30分钟300台设备每15分钟续租一次每天就是28800次交互平均每分钟20次虽然服务器扛得住但日志量会暴涨而且一旦服务器有一分钟不可用就会有大批设备进入重绑定状态。我的取值习惯是固定办公终端3到7天笔记本、移动设备用的无线网络8到24小时人员流动大地址要及时回收访客网络2到4小时用短租期控制池子占用会议室、培训室这类集中接入区域1到2小时3.4 静态绑定怎么做什么场景用有些设备确实需要固定地址但又不想在设备上手工配比如网络打印机、摄像头配置界面难用。这时候用DHCP静态绑定把MAC和IP对应起来走DHCP流程但每次拿到的都是同一个地址。ip pool office-pool static-bind ip-address 192.168.10.50 mac-address 00e0-fc12-3456静态绑定的地址会自动从动态池里排除不用重复配置excluded。什么场景用静态绑定我的判断标准是设备本身没有配置界面或者配置界面极其难用但地址又必须固定。如果设备能方便地配静态地址我倾向于直接在设备上配少一层依赖——DHCP服务器挂了静态配的设备照样能用。4. 抓包这件事位置选错后面全白搭4.1 抓包点怎么选DHCP是广播起家的协议这意味着抓包位置非常关键。可选的位置有几个客户端本机抓最直接能拿到客户端视角的完整交互但要注意抓包软件本身要占用网卡而且如果客户端是嵌入式设备就没法抓。接入交换机上做端口镜像把客户端所在端口镜像到抓包口适合客户端不方便装软件的场合。注意镜像要配双向只镜像入方向会漏掉服务器的回应。网关接口上抓如果是跨网段场景DHCP报文会经过网关在这里抓能看到中继处理后的报文能看到giaddr字段被填充的过程。服务器本机抓能看到服务器视角的所有请求但过滤起来比较麻烦因为一个服务器可能服务多个网段。我一般优先选客户端本机或者接入交换机镜像。原因很实在DHCP问题十有八九出在客户端到服务器这段路径上服务器本身反而是最稳的一环。4.2 过滤器怎么写才不漏Wireshark里过滤DHCP有几种写法各有适用场景# 最宽松老版本Wireshark用这个能抓到DHCP bootp # 新版本支持直接写dhcp dhcp # 按端口过滤能同时抓到客户端和服务端视角 udp.port 67 || udp.port 68 # 只看某个客户端 bootp.hw.mac_addr 00:e0:fc:12:34:56 # 按事务ID锁定一次完整交互 bootp.id 0x3d1e0a2b # 只看某个类型的报文53号选项值为1是DISCOVER bootp.option.dhcp 1几个经验点不要上来就写很复杂的过滤器。先开bootp看全貌确认报文确实存在再逐步收窄。我见过有人一开始就写了个超长的过滤表达式结果什么都没抓到折腾半天发现是表达式把报文过滤掉了。如果一张网里活跃客户端很多广播帧会刷屏。这时候用bootp.option.dhcp按消息类型过滤或者干脆先用bootp.hw.mac_addr锁定你要查的那台设备的MAC。设备的MAC地址从哪来让用户报一下或者从交换机MAC地址表里查。还有一个隐蔽的坑某些版本的Wireshark对DHCPv6和DHCPv4的过滤器是分开的写dhcp可能只匹配v4。如果抓不到包试着换成bootp因为是同一个底层协议。4.3 四个报文逐个字段核对清单抓到包之后我习惯按下面这个清单走一遍基本能覆盖90%的问题报文要核对的字段异常表现说明什么DISCOVER源IP、目的IP、xid、Option 55源IP不是0.0.0.0说明客户端已有地址可能在续租OFFERyiaddr、Option 51、Option 54、Option 3、Option 6yiaddr为0说明池子耗尽缺Option 3/6说明配置漏了REQUESTOption 50、Option 54、目的地址没有Option 54通常是续租有则是初次获取ACKyiaddr、Option 51、Option 58、Option 59与OFFER不一致说明服务器配置有变或存在多台服务器再补一条看时间戳。正常情况下四个报文之间的间隔在毫秒级如果看到DISCOVER和OFFER之间隔了好几秒说明网络有延迟或者服务器负载高。如果看到DISCOVER重复发了好几次才有OFFER说明中间有丢包或者服务器响应不过来。这个时间维度是很多人抓包时忽略的。4.4 抓不到包的五种典型原因排查抓不到包比分析报文更考验经验我按遇到频率排个序第一种抓包位置不对。在错误的接口上抓或者镜像口只配了单向。这个最常见解决办法是先在网关接口上抓一次确认报文确实存在再往客户端方向找。第二种过滤表达式写错。比如把bootp写成bootps或者用了新版本才支持的语法在老版本上跑。把过滤器清空再看一遍是最快的验证方法。第三种客户端压根没发DHCP请求。有些设备配置了静态地址或者网卡被禁用或者DHCP客户端服务没启动。这时候抓包一片安静看起来像网络问题实际上是设备行为问题。让用户确认一下网卡状态。第四种报文被中间设备拦了。接入交换机上如果启用了DHCP Snooping但没配信任端口来自服务器的OFFER会被丢弃。这个现象很典型客户端一直发DISCOVER服务器日志显示正常回应了但客户端收不到。抓包位置如果在客户端侧就只能看到DISCOVER看不到OFFER。第五种虚拟化环境的特殊性。虚拟机里的抓包有时受虚拟交换机影响抓不到广播帧。这种情况下要么在宿主机上抓要么在物理交换机上做镜像。4.5 一个完整案例的排查链路说个我印象很深的场景。某办公区反馈部分电脑开机后半小时上不了网重启就好。听起来像随机故障实际上有规律。第一步在出问题的电脑上抓包。发现完整走完了DISCOVER、OFFER、REQUEST、ACK地址也拿到了。看起来正常。第二步看ACK里的租期。租期只有1800秒也就是半小时。这就跟半小时上不了网对上了。第三步看续租过程。发现T1时刻15分钟的续租REQUEST发出去了但没有ACK回应。客户端一直重试到T2改成广播还是没有回应。第四步去服务器侧抓包。发现服务器压根没收到续租请求。问题定位到路径上。第五步查中间设备。发现客户端和服务器之间跨了一个网段中间有台设备做了地址转换续租的单播报文目的地址是服务器IP但转换表里没有对应条目包被丢了。结论是初次获取时用的是广播能穿过续租用单播被转换设备挡了。解决方案是调整转换策略或者把DHCP服务器挪到本地网段。这个案例说明一件事初次获取正常不代表DHCP没问题续租路径是独立的必须单独验证。5. 跨网段场景下中继到底做了什么5.1 广播过不了路由器这是硬限制DHCP的起点是广播而路由器默认不转发广播。这就意味着如果一个网段里没有DHCP服务器客户端喊破嗓子也没人应。解决办法是DHCP中继。中继设备部署在客户端所在网段的网关上它监听67端口收到客户端的广播后把报文重新封装成单播发给远端配置好的DHCP服务器。服务器回应的报文再经由中继转回给客户端。整个过程中客户端完全感知不到中继的存在——它仍然以为自己是在跟本地服务器对话。这种透明性靠的就是giaddr字段。5.2 giaddr字段服务器判断该给哪个池的依据中继转发请求时会把收到请求的那个接口的IP填到giaddrGateway IP Address字段里。服务器收到后看giaddr的值判断这个请求来自哪个网段然后从对应的地址池里分配地址。这个机制非常关键。如果giaddr填错了比如中继配置了错误的接口或者地址服务器就会从错误的池里分配地址客户端拿到的地址根本不在自己网段自然用不了。配置大概是这个思路# 在客户端侧网关接口上启用中继指向DHCP服务器地址 interface Vlanif20 ip address 192.168.20.1 255.255.255.0 dhcp select relay dhcp relay server-ip 10.1.1.100服务器侧则要配置对应192.168.20.0/24的地址池并且保证到中继地址有路由可达。一个容易忽略的点服务器回包的目的地址是giaddr不是客户端的MAC。这意味着服务器到中继之间的路由必须通。如果服务器配置了到客户端网段的路由但漏了到中继接口地址的路由回包发不出去客户端就永远收不到OFFER。5.3 中继环境下的抓包差异跨网段场景下抓包看到的东西跟同网段不一样客户端侧抓到的DISCOVER还是0.0.0.0到255.255.255.255。中继侧转发的报文源地址变成中继接口IP目的地址是服务器IPgiaddr字段被填充。服务器回应的OFFER目的地址是giaddr也就是中继的地址。中继再把OFFER转给客户端此时的报文形式取决于Flags位。如果你在中继设备上抓包会看到两套报文一套是广播进来的一套是单播转出去的。这两套的xid是相同的靠这个能对应起来。5.4 几个容易翻车的地方中继地址和地址池对不上。这是最常见的配置错误。客户端在192.168.20.0/24中继接口配了192.168.20.1但服务器上没有对应这个网段的地址池或者池子写成了192.168.2.0。表现是客户端一直发DISCOVER服务器日志里有请求但拒绝分配或者根本不回应。多台中继指向同一台服务器地址池没区分。服务器靠giaddr区分网段如果两台中继的giaddr恰好落在同一个池的范围里就会从同一个池分配地址客户端拿到跨网段地址用不了。中继服务器组配置了多个地址主用挂了没切过去。冗余配置要验证不能只配不测。测试方法很简单把主服务器接口关掉看客户端能不能从备用服务器拿到地址。Option 82的处理。部分中继会在报文里插入Option 82Relay Agent Information携带接入端口信息。有些服务器不认识这个选项会直接丢弃报文表现为中继配了但就是不生效。这时候要么在服务器上开启对Option 82的支持要么在中继上关掉这个功能。6. 那些文档里不会写的坑6.1 地址冲突为什么会出现DECLINE起了什么作用DHCP服务器分配地址时是不做冲突检测的可以配ping探测但会增加延迟而且很多场景下不启用。它只保证这个地址当前没有被自己分配出去但如果有设备手工配了一个池子里的地址服务器是不知道的。这时候客户端的作用就体现出来了。规范要求客户端在收到ACK后做一次ARP探测如果发现这个地址已经有人应答就发DECLINE报文告诉服务器这个地址有问题。服务器收到DECLINE后会把地址标记为不可用通常隔离一段时间不再分配。但这里有个现实问题不是所有客户端都规范实现了DECLINE。有些嵌入式设备、部分老系统压根不做ARP探测拿到冲突地址就直接用结果就是间歇性的网络异常——有时候通有时候不通排查起来极其难受。我的做法是如果发现某个网段频繁出现冲突先查是不是有人手工配了池子里的地址。方法很简单在网关上抓ARP把应答的IP和MAC列出来跟DHCP服务器的分配记录对一遍对不上的就是手工配的。6.2 NAK什么时候出现出现了说明什么NAK是服务器对REQUEST的拒绝。出现NAK通常有三种情况第一种客户端请求的地址已经不在服务器的池子里了比如池子被改小了或者地址被排除掉了。客户端重启后还记着上次的地址发REQUEST想续用服务器一看这个地址不归我管了回NAK。第二种客户端换网段了。笔记本从办公室拿到192.168.10.x的地址合上盖子到会议室192.168.20.0/24醒来后还在续租原来的地址。中继把这个请求转给服务器服务器发现giaddr是20网段但请求的是10网段的地址回NAK。客户端收到NAK后立刻放弃地址重新走DISCOVER。第三种地址已经被分配给别的设备了。这种情况一般发生在服务器重启后状态丢失或者多台服务器之间没有同步。看到NAK不用慌它本身是个正常机制客户端收到后重新获取就行。但如果NAK出现得很频繁说明租期设置或者网络切换策略有问题值得优化。6.3 私设DHCP服务器怎么发现这是运维里比较头疼的问题。有人在办公网里插了个家用路由器LAN口接上网线路由器的DHCP功能没关开始给周围设备发地址。表现是部分设备突然拿到192.168.1.x或者192.168.x.x的地址网关指向一个陌生的IP上不了网。发现方法有几个最直接的是抓包看OFFER的源地址。如果你的网络里只有一台合法服务器是10.1.1.100抓包看到OFFER来自192.168.1.1那就锁定问题了。这时候看这个OFFER是从哪个交换机端口进来的通过MAC地址表就能定位到物理端口。预防手段是在接入交换机上启用DHCP Snooping把连接合法服务器的端口设为信任端口其他端口收到的OFFER直接丢弃。这个功能配置起来不复杂但要注意两点信任端口一定要配对否则合法的OFFER也会被丢另外如果网络里有中继中继的上行端口也要设为信任。6.4 无线环境下的特殊表现无线网络里DHCP的表现和有线不太一样值得单独说。终端在AP之间漫游时如果跨了三层网段会重新走一遍DHCP流程。这个过程通常在几百毫秒内完成用户感知不到。但如果DHCP服务器响应慢或者中继配置有问题漫游时就会出现明显的断网表现为走着走着网断了等一会儿又好了。另一个常见问题是地址池耗尽。无线网络的地址池消耗速度比有线快得多因为手机、平板、笔记本加起来人均两三台设备很常见。一个能坐50人的会议室如果按50个地址配池子肯定不够用。我一般按人数的2到3倍来配租期设短一点2到4小时保证离场后地址能快速回收。还有一种情况是终端休眠后唤醒续租失败。移动设备为了省电休眠时会断开无线唤醒后网卡可能还在用旧的地址信息发续租请求而此时AP已经把它踢下线了。这种问题的表现是手机锁屏一会儿再打开要等十几秒才能上网抓包能看到续租请求发出去没回应然后重新走DISCOVER。解决办法一般是缩短租期配合终端的快速重连机制或者干脆接受这个延迟——它其实是终端省电策略的一部分。6.5 抓包文件怎么保存和复盘最后说个实操细节。抓包的时候建议直接保存成pcap文件不要只看着实时界面。原因是DHCP的问题往往要跨时间对比比如昨天好的今天不行有历史抓包文件才能对比出租期、地址池、服务器地址有没有变。Wireshark保存的时候注意几个设置抓包缓冲区设大一点防止高速流量下丢包抓包文件按大小或者时间自动切分避免单文件过大打不开文件名带上时间戳和位置标识方便后面找。复盘的时候用Statistics Flow Graph能看到交互的时序图比逐个点报文直观得多。不过要注意这个功能对UDP广播的展示可能不够准确我一般还是看报文列表配合时间列。一个我常用的技巧把bootp.time或者帧编号加到列里按时间排序然后对照客户端的开机时间就能算出从发第一个DISCOVER到拿到地址用了多久。正常情况下这个值应该在100毫秒以内如果超过1秒说明中间有重传或者服务器响应慢值得深挖。