一次办公网DHCP地址池耗尽导致部分终端无法获取IP的排查记录

Wed, 08 Jul 2026 07:00:00 +0000

问题背景

公司办公网核心是一台三层交换机，下挂多个接入交换机，员工 PC、手机、打印机和一堆 IoT 设备都划分在同一个 /24 网段里，由 Windows Server 上的 DHCP 服务统一下发地址。平时一切正常，管理员也没太关注地址池的剩余量。某天周一早高峰，几乎同一时刻上百人打卡开机、连 WiFi，问题就爆发了。这类"容量型"故障最隐蔽的地方在于：它平时毫无征兆，一旦触发就是大面积、且每次重启都只是暂时缓解，很容易让排障者陷入"重启试试"的误区。

故障现象

早上 9 点前后，IT 服务台在十分钟内涌进二十多个报障工单，集中在同一楼层：

部分员工插上网线或连上办公 WiFi 后，系统托盘网络图标显示"黄色感叹号"，状态是"已连接，但无法访问 Internet"；
ipconfig /all 看到的不是正常的 192.168.10.x，而是 169.254.x.x（APIPA 自动专用地址），说明没有从 DHCP 拿到地址；
能 Ping 通网关 192.168.10.1，但打不开任何网页，DNS 解析也失败；
已在线的人不受影响，问题只集中在新开机、或休眠唤醒、或重新连网的那批终端；
现场重启交换机、重启网卡后能临时恢复，但半小时后同样的人又掉回 169.254，形成"重启救一时、过会儿又复发"的怪圈。

初步判断这不是线路或交换机故障——能 Ping 通网关就说明二层、三层转发是好的，问题大概率出在"地址下发"这一环。

排查过程

第一步：确认是否真的没拿到地址。 在故障终端上执行 ipconfig /release && ipconfig /renew，观察输出。正常情况下会立刻拿到 192.168.10.x；而故障终端卡在 “正在等待 DHCP 服务器响应” 几十秒后，退回 169.254.x.x。结合 ipconfig /all 里"自动配置 IP 地址 169.254.x.x"，基本锁定：DHCP Discover/Offer 阶段就拿不到地址，不是 DNS 也不是网关问题。

第二步：直奔 DHCP 服务器看地址池。 登录 Windows DHCP 控制台（或 dhcputil / PowerShell Get-DhcpServerv4Scope），展开作用域 192.168.10.0/24，重点看两个数字：“地址总数” 与 “可用地址”。结果发现：253 个可用地址里，剩余可用显示为 0，租约列表里 253 条全是"已租用 (Active)“状态。这就对上了——不是服务器宕了，而是它"无地址可发”，只能让客户端退到 APIPA。

第三步：分析租约构成，找出"占坑"的设备。 把租约按"租约过期时间"排序，发现大量租约剩余时间还挂着 6~7 天（默认租期 8 天），且客户端标识里混着很多手机 MAC（OUI 一眼能认出是 Apple / Xiaomi / Huawei）、几台访客笔记本、十几台打印机和智能电视。也就是说：一个 /24 既要养员工 PC，又要养所有人的手机、访客设备、IoT，253 个地址根本不够早高峰并发。

第四步：确认有没有"放大器"。 进一步排查发现，有员工在工位私接了一台家用无线路由器当 AP，LAN 口又接回办公网——这本身不直接耗地址，但更严重的是另一处：访客 WiFi 的 DHCP 中继（DHCP Relay / IP Helper）错误地指向了办公网这个作用域，导致访客手机也来抢办公地址。再加上几个研发在测试环境开了几十台虚拟机，桥接到了办公网桥，每台都来要地址。三重叠加，地址池直接被打满。

第五步：用数据验证根因。 在核心交换机上 show ip dhcp snooping binding（或 Windows 侧用 Get-DhcpServerv4Lease -ScopeId 192.168.10.0 | Measure-Object），统计当前活跃租约里非员工 PC 的占比，超过 55%。结合早高峰工单时间曲线与租约申请日志峰值时间完全吻合，确认"地址池容量不足 + 租期过长 + 访客/测试流量串入"是本次故障的组合根因。

解决方案

排障要快、根治要稳，分两步走：

应急（10 分钟内恢复业务）：

在 DHCP 控制台对抢占严重的访客 MAC、测试虚拟机 MAC 做保留排除（Reservation / Exclusion），把它们从办公作用域剔除；
临时把办公作用域的租期从 8 天改成 8 小时，Set-DhcpServerv4Scope -LeaseDuration 08:00:00，让休眠/离线的设备更快释放地址；
立即修正访客 WiFi 的 DHCP Relay，指向独立的访客作用域，并给研发测试网单独划 VLAN、单独地址池；
对仍卡在 169.254 的终端批量 ipconfig /release && ipconfig /renew，几分钟内全部恢复正常。

根治（当天完成）：

按部门/楼层拆分 VLAN，把办公、访客、IoT、打印机分属不同子网，每个子网独立 /24，从物理上隔离地址竞争；
启用接入交换机的 DHCP Snooping + 端口安全，非法私接的路由器/小交换机无法下发地址，从源头堵住"家用路由当 AP"的乱接行为；
对固定设备（打印机、服务器、AP）做静态保留，把动态池留给真正的流动终端。

根因分析

根本原因是地址规划与容量管理缺位，而非设备故障：单个 /24（253 地址）承载了远超设计容量的终端类型，且默认 8 天租期让离线设备长期"占坑不释放"；同时访客网络与测试网络的 DHCP 流量错误串入办公作用域，成了压垮地址池的最后一根稻草。169.254 只是表象，地址池归零才是真凶。

预防措施

容量规划前置：按"终端数 × 1.3"预留地址，移动设备多的办公区直接上 /23 或拆 VLAN，别拿一个 /24 硬扛；
租期分级：员工 PC 可长（如 1 天），手机/访客用短租期（2~4 小时），让地址快速周转；
网络分区：办公、访客、IoT、打印严格分 VLAN，各用各的地址池，互不影响；
监控告警：对 DHCP 作用域的"可用地址数"做监控，低于 20% 就告警，把故障消灭在爆发前；
接入管控：开启 DHCP Snooping + 端口安全，禁止私接 NAT 路由，避免地址池被意外放大消耗。

总结

DHCP 地址池耗尽是典型"平时无感、爆发致命"的容量型故障，排查关键就一句话：看到 169.254，先别查线路，直接去 DHCP 服务器看"可用地址"是不是 0。真正要做的不是反复重启，而是缩短租期、隔离访客、拆 VLAN、加监控——把容量和管理补齐，故障才不会下个周一再来一遍。

地址池 on Zero Day Notes