一次DHCP地址池耗尽导致大面积断网的排查实录

发表于 分类于 ， 阅读次数： 本文字数： 3k 阅读时长 ≈ 11 分钟

问题背景

周一早上 9 点，刚到办公室坐下，内部沟通群里就开始炸了——整层楼的员工纷纷反馈”连不上网””网页打不开””钉钉掉线”。我们公司办公区大约 200 人，分布在两个楼层，通过核心交换机连接到上联防火墙出口。网络拓扑相对简单：核心交换机做 DHCP Server，每个 VLAN 对应一个子网，地址池按楼层划分。

我作为网络运维负责人，第一时间意识到这不是个别用户的问题，而是大面积故障。好在服务器区域使用的是静态 IP，不受 DHCP 影响，核心业务系统还在正常运行。但办公网的瘫痪意味着 200 人无法工作，紧急程度属于 P1 级别——必须 30 分钟内恢复。

故障现象

用户反馈的具体表现如下：

  1. 新接入设备无法获取 IP：部分刚开机或重新连接的电脑显示”正在获取网络地址”，持续等待后最终提示”无 Internet 连接”，ipconfig /all 显示 IP 为 0.0.0.0。
  2. 已在线设备部分正常：之前已经拿到 IP 且租期未过期的设备暂时还能上网，但网络明显变慢， ping 内网网关偶尔出现 50-200ms 的异常延迟。
  3. DHCP 请求超时：在受影响的终端上抓包，可以看到 DHCP Discover 包正常发出，但始终没有收到 DHCP Offer 回应。

关键信息：

  • 核心交换机（华为 S5735-L48T4X）上配置了 VLAN 10（一楼）和 VLAN 20（二楼）的 DHCP 地址池
  • VLAN 10 地址池：192.168.10.100 - 192.168.10.250，共 151 个地址
  • VLAN 20 地址池：192.168.20.100 - 192.168.20.250，共 151 个地址
  • 楼层实际办公电脑数量：一楼约 90 台，二楼约 110 台

排查过程

第一步：确认 DHCP 服务状态

登录核心交换机，首先检查 DHCP Server 是否正常运行：

1
2
3
4
5
6
7
<HX-Switch> display dhcp server statistics
  DHCP Server Statistics:
    Request Received     : 4238
    Offer Sent           : 151
    Ack Sent             : 151
    Discover Received    : 4087
    Offer Failed         : 3936

关键发现：Offer Failed 达 3936 次！ 这意味着交换机收到了大量 DHCP Discover 请求，但无法回复 Offer。这几乎可以确定是地址池出了问题。

第二步：检查地址池使用情况

继续查看地址池的分配状态：

1
2
3
4
5
6
7
<HX-Switch> display dhcp server ip-in-use pool vlan10
  IP Address       Hardware Address   Lease Expired   Status
  192.168.10.100   00e0-4c68-01a2    2026/06/20 18:00  Used
  192.168.10.101   00e0-4c68-03b5    2026/06/20 18:00  Used
  ...（省略中间）
  192.168.10.250   a860-b117-55c3    2026/06/20 18:00  Used
  Total : 151    Used : 151    Idle : 0
1
2
<HX-Switch> display dhcp server ip-in-use pool vlan20
  Total : 151    Used : 151    Idle : 0

地址池 100% 占用，零空闲！ VLAN 10 和 VLAN 20 的 302 个地址全部被分配。但实际办公电脑只有约 200 台，多出来的 100 多个地址被谁占走了？

第三步：分析 DHCP 租约表

导出完整租约表进行详细分析。我用 Python 脚本处理交换机输出的 MAC-IP 映射：

1
<HX-Switch> display dhcp server ip-in-use pool vlan10 all

拿到全部 151 条记录后，我重点关注 MAC 地址的前缀（OUI），用来识别设备类型：

MAC 前缀 设备类型 数量
00e0-4c Realtek（PC 网卡） 68
a860-b1 Apple（iPhone/Mac） 42
dc:a6:32 Raspberry Pi 12
88:15:44 智能家居/IoT 设备 15
ac:de:48 私有 MAC（随机化） 14

发现了！42 台 iPhone + 15 台 IoT 设备 + 12 台 Raspberry Pi + 14 台随机化 MAC 设备 = 83 台非办公设备，它们占用了大量 DHCP 地址。这些是员工个人手机、测试设备以及不明 IoT 设备。

VLAN 20 的情况更严重：二楼有 110 台办公电脑，地址池只有 151 个，被 48 台手机和一堆 IoT 设备挤占后，留给办公电脑的只有不到 100 个——根本不够用。

第四步：定位非法设备的接入端口

接下来需要找到这些非办公设备是从哪些端口接入的。在交换机上查询 MAC 地址表：

1
2
3
4
5
6
7
8
9
<HX-Switch> display mac-address dynamic vlan 10
  MAC Address      VLAN  Port          Type
  a860-b117-55c3   10    GE0/0/15     Dynamic
  a860-b117-66d4   10    GE0/0/15     Dynamic
  a860-b117-78e1   10    GE0/0/15     Dynamic
  ...（多个 Apple MAC 均从 GE0/0/15 学习到）
  dc:a6-32-01-ab   10    GE0/0/22     Dynamic
  dc:a6-32-01-cd   10    GE0/0/22     Dynamic
  88:15:44-xx      10    GE0/0/28     Dynamic

发现规律：

  • GE0/0/15：会议室区域的大屏和员工手机大量接入（一个端口下挂 AP，AP 下连接了数十个无线设备）
  • GE0/0/22：研发测试区的交换机下联了 12 台 Raspberry Pi
  • GE0/0/28：茶水间区域的 IoT 设备（智能灯控、温湿度传感器等）

根本问题很清楚了：无线 AP 没做 MAC 过滤，任何人都可以用手机连上办公 Wi-Fi 拿到 IP；研发区随意接入测试设备；IoT 设备也混在办公 VLAN 里。

第五步：查看 DHCP 租期配置

再看一下租期设置：

1
2
3
<HX-Switch> display dhcp server pool vlan10
  Pool Name      : vlan10
  Lease Day      : 1    Hour : 0    Minute : 0

租期 1 天！ 手机连上 Wi-Fi 后拿到的 IP 要 24 小时才会过期释放，即使手机离开了网络，地址也一直被占着。这进一步加剧了地址池耗尽的问题。

解决方案

紧急恢复（5 分钟内实施）

第一步：清除非法设备的 DHCP 租约，立即释放被占用的地址：

1
2
3
4
5
6
7
<HX-Switch> system-view
# 批量释放非办公MAC的租约
<HX-Switch> reset dhcp server ip-in-use mac-address a860-b117-55c3 pool vlan10
<HX-Switch> reset dhcp server ip-in-use mac-address a860-b117-66d4 pool vlan10
# ...（按MAC前缀批量清除所有Apple/iOS设备的租约）
<HX-Switch> reset dhcp server ip-in-use pool vlan10 conflict
# 清除冲突地址

由于手动一条条清太慢，我用了更高效的方法——缩短租期到 1 小时，让所有现有租约快速过期：

1
2
3
4
<HX-Switch> dhcp server ip-pool vlan10
<HX-Switch-vlan10> lease day 0 hour 1 minute 0
<HX-Switch> dhcp server ip-pool vlan20
<HX-Switch-vlan20> lease day 0 hour 1 minute 0

这样 1 小时后所有设备的租约都会到期需要重新续租，到那时我们再通过端口安全策略拦截非法设备。

第二步：临时扩大地址池，缓解当前压力：

1
2
3
4
5
<HX-Switch> dhcp server ip-pool vlan10
<HX-Switch-vlan10> network 192.168.10.0 mask 255.255.254.0
# 地址范围从 .100-.250 扩大到 .1-.510（实际可用约 500）
<HX-Switch> dhcp server ip-pool vlan20
<HX-Switch-vlan20> network 192.168.20.0 mask 255.255.254.0

将子网掩码从 /24 改为 /23，地址池翻倍，确保即使有手机接入也不会耗尽。

注意：扩大子网后需要同步更新上联防火墙的路由和 NAT 规则。

约 3 分钟后，用户开始陆续恢复网络连接。紧急恢复完成。

根治方案（当天下午实施）

1. VLAN 隔离——IoT 和访客设备独立网段

1
2
3
4
5
6
7
8
9
10
11
<HX-Switch> vlan 30  # IoT专用VLAN
<HX-Switch-vlan30> dhcp server ip-pool iot
<HX-Switch-iot> network 192.168.30.0 mask 255.255.255.0
<HX-Switch-iot> lease day 0 hour 0 minute 30  # IoT设备租期30分钟
<HX-Switch-iot> gateway-list 192.168.30.1

<HX-Switch> vlan 40  # 访客Wi-Fi VLAN
<HX-Switch-vlan40> dhcp server ip-pool guest
<HX-Switch-guest> network 192.168.40.0 mask 255.255.255.0
<HX-Switch-guest> lease day 0 hour 2 minute 0  # 访客租期2小时
<HX-Switch-guest> gateway-list 192.168.40.1

无线 AP 配置双 SSID：Office-WiFi（仅办公设备，绑定 VLAN 10/20）和 Guest-WiFi（访客/手机，绑定 VLAN 40），通过 802.1X 认证区分合法办公设备。

2. 端口安全——限制接入设备数量

1
2
3
4
5
6
7
8
9
<HX-Switch> interface GE0/0/15  # 会议室端口
<HX-Switch-GE0/0/15> port-security enable
<HX-Switch-GE0/0/15> port-security max-mac-num 5  # 最多5台设备
<HX-Switch-GE0/0/15> port-security protect-action shutdown  # 超限则关闭端口

<HX-Switch> interface GE0/0/22  # 研发测试区
<HX-Switch-GE0/0/22> port-security enable
<HX-Switch-GE0/0/22> port-security max-mac-num 20  # 研发区允许较多设备
<HX-Switch-GE0/0/22> port-security protect-action restrict  # 超限仅丢弃新MAC

3. DHCP 租期优化

  • 办工 VLAN：租期从 1 天调整为 8 小时（足够一个工作日，下班后地址自动释放）
  • IoT VLAN：租期 30 分钟（IoT 设备重启频繁，短租期避免地址浪费）
  • 访客 VLAN：租期 2 小时（访客停留时间有限）

4. DHCP Snooping 防护

1
2
3
4
5
<HX-Switch> dhcp snooping enable
<HX-Switch> vlan 10
<HX-Switch-vlan10> dhcp snooping enable
<HX-Switch> interface GE0/0/1  # 上联口（信任口）
<HX-Switch-GE0/0/1> dhcp snooping trust

防止非法 DHCP Server 干扰，同时记录 DHCP 绑定表便于审计。

根因分析

问题的根本原因有三层：

  1. 网络架构设计缺陷：所有设备（办公电脑、手机、IoT、测试设备）混在同一个 VLAN 里，没有按设备类型做网络隔离。地址池按”办公电脑数量”规划，完全忽略了无线 AP 下挂的手机和 IoT 设备。

  2. DHCP 租期过长：1 天的租期导致设备断开连接后 IP 仍然被占用长达 24 小时。手机这种高流动性设备（连上 Wi-Fi 就拿 IP，离开后 IP 一直不释放）是地址池耗尽的最大推手。

  3. 无线网络缺乏准入控制：办公 Wi-Fi 无认证无过滤，任何人的手机都可以随意接入，等于给 DHCP 地址池开了一个无底洞。

三层因素叠加：架构上没有隔离 → 准入上没有限制 → 租期上没有优化 → 地址池被挤爆。

预防措施

基于这次故障，我们制定了以下长期预防措施：

1. 定期巡检 DHCP 地址池利用率

编写巡检脚本，每小时采集地址池利用率并推送监控：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
import paramiko
import re

def check_dhcp_pool(switch_ip, pool_name):
    ssh = paramiko.SSHClient()
    ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
    ssh.connect(switch_ip, username='admin', password='xxx')
    cmd = f'display dhcp server ip-in-use pool {pool_name}'
    output = ssh.exec_command(cmd)[1].read().decode()
    # 解析 Total / Used / Idle
    match = re.search(r'Total\s*:\s*(\d+)\s*Used\s*:\s*(\d+)\s*Idle\s*:\s*(\d+)', output)
    if match:
        total, used, idle = int(match.group(1)), int(match.group(2)), int(match.group(3))
        utilization = used / total * 100
        if utilization > 85:
            send_alert(f'DHCP池 {pool_name} 利用率 {utilization:.1f}%，空闲仅 {idle} 个')
    ssh.close()

# 定时巡检所有地址池
for pool in ['vlan10', 'vlan20', 'iot', 'guest']:
    check_dhcp_pool('10.0.0.1', pool)

2. VLAN 规划标准化

新建网络区域必须遵循 VLAN 隔离原则：

  • 办工设备 VLAN：仅允许通过 802.1X 认证的设备接入
  • IoT 设备 VLAN：单独隔离，ACL 限制只能访问特定服务器
  • 访客 VLAN：独立 SSID，ACL 限制只能访问 Internet，禁止访问内网资源

3. 地址池容量预留

地址池规划时预留 50% 以上冗余。例如 200 台办公设备，地址池至少 300 个地址。同时预留一个备选子网，在紧急扩容时可快速启用。

4. 无线网络准入强化

  • 办工 Wi-Fi 启用 802.1X 企业认证，绑定 AD 域账号
  • 访客 Wi-Fi 启用 Web 认证（短信验证码或临时账号）
  • 定期审计无线 AP 的关联终端列表，清理异常设备

5. 建立变更审批流程

任何人接入非办公设备（测试服务器、IoT 设备等）必须提前提交网络变更申请，运维团队评估 VLAN 归属和地址池容量后才允许接入。

总结

这次故障从发现到紧急恢复用了约 15 分钟，根治方案在当天下午完成。最大的教训是：**网络规划不能只看”有多少台电脑”，要看”有多少台设备会连上来”**。

在移动办公时代，每个员工至少有一台手机会连 Wi-Fi，加上各种 IoT 设备和测试设备，实际接入数往往是办公电脑数的 1.5-2 倍。如果地址池按电脑数来规划，必然会被挤爆。

另一个关键认知是：DHCP 租期不是越大越好。长租期在设备稳定的场景（服务器、固定工位）是好实践，但在高流动性场景（手机、访客）就是灾难。不同类型的设备要用不同的租期策略。

最后，网络隔离是最基本的防护——把办公、IoT、访客分到不同 VLAN，不仅仅是为了安全，也是为了资源管理。当你发现一个 VLAN 的地址池快满时，至少不会拖垮其他 VLAN 的正常设备。