交换机 on Zero Day Notes

记一次交换机物理环路引发的整栋楼广播风暴

Mon, 29 Jun 2026 11:16:49 +0000

问题背景

某周一上午9:15，正是全员打卡上班的高峰时段，IT服务台电话瞬间被打爆——6楼整层约120台终端全部断网，OA系统、邮件、ERP一律打不开，连本地文件共享都无法访问。与此同时，5楼和7楼也开始零星报障，部分终端时断时续。

这是一栋12层的办公大楼，核心交换机是两台华为S12700做CSS集群，每层楼一台华为S5735-L48T4X-A做接入，上行10G光纤到核心，接入交换机之间没有横向互联。6楼接入交换机是SW-F6-01，负责6楼全部48个信息点。网络拓扑很标准：核心—接入两层架构，按理说不该出现环路。但事实是——6楼瘫痪了，而且速度极快，从第一个报障电话到整层断网，不到3分钟。

紧急程度：P1——整个楼层业务中断。

故障现象

从监控系统和现场排查来看，故障表现非常典型：

1. 终端侧现象

所有6楼终端Ping网关10.6.254.1丢包率95%以上，偶尔通一个包延迟高达2000ms+
DHCP无法获取地址，已有IP的终端ARP表混乱，网关MAC频繁跳变
部分终端右下角网络图标黄色感叹号，提示"未识别的网络"

2. 交换机侧现象

登录SW-F6-01，CPU利用率飙到99%，命令行响应极慢，display cpu-usage需要30秒才返回
display interface brief看到多个端口流量异常：G0/0/1到G0/0/48中有十几个端口出方向流量持续跑到线速（1000Mbps）
display mac-address表项数量从正常的200条暴涨到64000条（MAC表容量上限），且MAC地址在端口之间疯狂漂移
核心交换机CSS集群CPU也达到78%，6楼VLAN对应的VLANIF接口入方向流量达到8Gbps（正常不到200Mbps）

3. 日志关键信息

SW-F6-01上持续刷出以下日志：

%%01L2IFPPI/4/MAC_FLAPPING_ALARM(l):OID 1.3.6.1.4.1.2011.5.25.160.3.7
MAC address 00e0-fc12-3456 has flapped from GE0/0/5 to GE0/0/22, lasted 2 seconds.
%%01L2IFPPI/4/MAC_FLAPPING_ALARM(l):OID 1.3.6.1.4.1.2011.5.25.160.3.7
MAC address 00e0-fc12-3456 has flapped from GE0/0/22 to GE0/0/5, lasted 1 seconds.
%%01L2IFPPI/4/MAC_FLAPPING_ALARM(l):OID 1.3.6.1.4.1.2011.5.25.160.3.7
MAC address ffff-ffff-ffff in VLAN 206 has flapped from GE0/0/5 to GE0/0/22

核心交换机日志：

1
2

%%01SECE/4/ARPMISS(l):Speed of ARP Miss packets exceeded the configured rate limit.
%%01SECE/4/ARPMISS(l):Speed of ARP Miss packets exceeded the configured rate limit.

MAC地址在GE0/0/5和GE0/0/22之间反复跳变，且出现了全F的广播MAC漂移——这是典型的二层环路广播风暴特征。

排查过程

第一步：确认故障范围

先通过核心交换机确认故障边界。登录核心CSS集群，查看各VLAN接口流量：

<CORE-SW> display interface Vlanif 206
Vlanif206 current state: UP
Line protocol current state: UP
Description: 6F-Office-VLAN
Input bandwidth utilization: 98%    ← 正常应 <5%
Output bandwidth utilization: 3%
Input: 8234567 packets/sec, 8.2 Gbps
Output: 12345 packets/sec, 12 Mbps

VLAN 206（6楼办公VLAN）入方向流量8.2Gbps，而上行10G链路带宽的80%+都被这些垃圾流量吃掉了。其他楼层VLAN流量正常。

结论：故障范围锁定在6楼VLAN 206，且是二层广播风暴。

第二步：判断环路类型

广播风暴的常见原因有三：物理环路、ARP风暴攻击、蠕虫病毒扩散。通过以下特征快速判断：

特征	物理环路	ARP攻击	蠕虫病毒
MAC漂移	两个端口间高频往复	分散，无规律	分散
广播包占比	>95%	ARP包为主	混合流量
全F广播MAC漂移	有	无	偶尔
流量对称性	两个端口双向跑满	单向为主	不定

SW-F6-01的MAC漂移集中在GE0/0/5和GE0/0/22两个端口之间，且双向流量都跑到线速——典型物理环路特征。

第三步：定位环路端口

在SW-F6-01上执行MAC漂移检测，获取精确的环路端口对：

[SW-F6-01] display mac-address flapping
Flapping VLAN 206:
MAC Address    From/To        Flapping Time
00e0-fc12-3456 GE0/0/5  -> GE0/0/22    2026-06-29 09:17:32
00e0-fc12-3456 GE0/0/22 -> GE0/0/5     2026-06-29 09:17:33
00e0-fc89-abcd GE0/0/5  -> GE0/0/22    2026-06-29 09:17:33
00e0-fc89-abcd GE0/0/22 -> GE0/0/5     2026-06-29 09:17:34

MAC地址只在GE0/0/5和GE0/0/22之间跳变，环路就出在这两个端口之间。

第四步：确认物理连接

通过网管系统查看GE0/0/5和GE0/0/22的端口描述信息：

[SW-F6-01] display interface GE0/0/5
GigabitEthernet0/0/5 current state: UP
Description: 6F-MeetingRoom-A

[SW-F6-01] display interface GE0/0/22
GigabitEthernet0/0/22 current state: UP
Description: 6F-MeetingRoom-A-2

两个端口都连着6楼A会议室。联系行政确认：A会议室有6个信息点，4个墙面面板+2个地插。今天早上8:50有一个供应商来会议室做产品演示，需要联网，自行从地插拉了一根网线插到墙面上——他把同一台交换机下的两个端口用一根网线连了起来。

地插（GE0/0/22）——网线——墙面面板（GE0/0/5），物理环路就这样形成了。

第五步：检查STP状态——为什么环路没有自动阻断？

这是最关键的问题。按照我们的网络标准，所有接入交换机都应该启用MSTP，环路应该被STP自动阻断。查看MSTP状态：

[SW-F6-01] display stp interface GE0/0/5 brief
Port           Role   State
GE0/0/5        -      -

[SW-F6-01] display stp interface GE0/0/22 brief
Port           Role   State
GE0/0/22       -      -

端口STP角色显示为空——说明STP根本没在这两个端口上生效。进一步检查全局MSTP配置：

1
2

[SW-F6-01] display stp global
MSTP is disabled globally.

MSTP全局未启用！ 这才是问题的根源——去年6楼交换机因硬件故障更换，新交换机上线时是用的初始配置模板，模板里漏掉了stp enable全局命令。虽然端口下有stp edged-port enable的配置，但全局STP未开启，端口级的STP配置等于白搭。

第六步：紧急止血

必须立即打断环路。有两种方案：

方案A：直接shutdown环路端口——风险低，见效最快 方案B：全局启用STP——在广播风暴期间启用STP，STP报文可能被淹没在风暴中无法正常收发，收敛时间不可控

选择方案A，先shutdown再处理根因：

[SW-F6-01] interface GE0/0/5
[SW-F6-01-GE0/0/5] shutdown
[SW-F6-01-GE0/0/5] quit
[SW-F6-01] interface GE0/0/22
[SW-F6-01-GE0/0/22] shutdown
[SW-F6-01-GE0/0/22] quit

Shutdown后10秒，CPU从99%降到12%，MAC表项从64000条降到180条，6楼网络在30秒内完全恢复。

解决方案

1. 紧急恢复（已完成）

shutdown环路端口，网络恢复正常。通知会议室供应商正确使用单口连接。

2. 根治——全局启用MSTP

在SW-F6-01上启用MSTP并配置最佳实践参数：

# 全局启用MSTP
[SW-F6-01] stp mode mstp
[SW-F6-01] stp enable

# 配置MSTP域（与核心交换机保持一致）
[SW-F6-01] stp region-configuration
[SW-F6-01-mst-region] region-name HQ-OFFICE
[SW-F6-01-mst-region] revision-level 1
[SW-F6-01-mst-region] instance 1 vlan 201 to 210
[SW-F6-01-mst-region] active region-configuration
[SW-F6-01-mst-region] quit

# 核心交换机作为根桥
[SW-F6-01] stp instance 0 root secondary
[SW-F6-01] stp instance 1 root secondary

# 优化STP收敛参数
[SW-F6-01] stp timer hello 2
[SW-F6-01] stp timer forward-delay 15
[SW-F6-01] stp timer max-age 20

3. 接入端口安全加固

对所有接入端口启用BPDU Guard和边缘端口，防止终端侧引入环路：

# 批量配置接入端口
[SW-F6-01] port-group group-member GE0/0/1 to GE0/0/48
[SW-F6-01-port-group] stp edged-port enable
[SW-F6-01-port-group] stp bpdu-protection enable
[SW-F6-01-port-group] quit

# 上行端口保持默认STP参与（不设为边缘端口）
[SW-F6-01] interface XGE0/0/1
[SW-F6-01-XGE0/0/1] undo stp edged-port
[SW-F6-01-XGE0/0/1] quit

BPDU Guard的作用：如果有人在边缘端口上接入了一台交换机（发了BPDU），端口会立即err-down，阻断环路产生。这是防止终端侧环路的最有效手段。

4. 开启环路检测（Loop Detection）作为双保险

即使STP启用，也配置环路检测作为补充防护：

[SW-F6-01] loop-detect enable
[SW-F6-01] loop-detect interval 5
[SW-F6-01] port-group group-member GE0/0/1 to GE0/0/48
[SW-F6-01-port-group] loop-detect action shutdown
[SW-F6-01-port-group] quit

5. 全网排查STP状态

对全部12台接入交换机逐一检查MSTP是否全局启用：

1
2

# 在每台接入交换机上执行
display stp global

发现除了SW-F6-01，SW-F9-01和SW-F11-01也是MSTP全局关闭的——这两台也是去年硬件更换时遗漏的。立即补上相同的MSTP配置。

根因分析

这次故障的根本原因是双重防护缺失：

1. 直接原因：会议室供应商用一根网线连接了同一台交换机下的两个接入端口，形成物理环路，触发广播风暴。

2. 根本原因：SW-F6-01（以及SW-F9-01、SW-F11-01）的MSTP协议全局未启用。去年这三台交换机因硬件故障更换，上线时使用的初始配置模板遗漏了stp enable全局命令。虽然端口下配置了stp edged-port enable，但在全局STP关闭的情况下，端口级STP配置不会生效，等于形同虚设。

3. 管理原因：交换机上线缺少配置合规检查流程。新设备上线后只有Ping通网关的连通性验证，没有协议级检查（如STP状态、LLDP邻居、端口安全策略等），导致配置遗漏长期潜伏。

预防措施

1. 配置基线检查自动化

编写Python脚本，通过NETCONF/SSH批量巡检所有接入交换机的关键配置项，纳入每日自动巡检：

#!/usr/bin/env python3
"""接入交换机配置基线巡检脚本"""
import paramiko
import csv

CHECK_LIST = [
    ("STP全局状态", "display stp global", "MSTP is enabled"),
    ("Loop Detection", "display loop-detect", "Loop detect is enabled"),
    ("NTP同步状态", "display ntp-service status", "clock is synchronized"),
    ("SSH版本", "display ssh server status", "SSH version : 2.0"),
    ("SNMPv3", "display snmp-agent group", "v3"),
]

def check_switch(host, username, password):
    results = []
    ssh = paramiko.SSHClient()
    ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
    ssh.connect(host, username=username, password=password)
    for name, cmd, expected in CHECK_LIST:
        stdin, stdout, stderr = ssh.exec_command(cmd)
        output = stdout.read().decode()
        ok = expected in output
        results.append((name, "PASS" if ok else "FAIL"))
    ssh.close()
    return results

# 批量巡检并输出报告...

将巡检结果接入企业微信告警，任何一台交换机的STP状态变为disabled，5分钟内通知网络组。

2. 交换机上线SOP完善

新增交换机上线检查清单中的必检项：

检查项	命令	期望结果
MSTP全局启用	`display stp global`	MSTP is enabled
MSTP域配置	`display stp region-configuration`	Region与核心一致
BPDU Guard	`display stp bpdu-protection`	至少48个边缘端口启用
环路检测	`display loop-detect`	Loop detect is enabled
端口安全	`display port-security`	已配置

上线后必须由第二人复核并签字确认。

3. 会议室信息点管理

会议室信息点在面板上标注编号，与交换机端口一一对应
地插面板贴上醒目标签：“请勿将网线连接两个网络面板”
非IT人员需要联网时，统一联系IT前台，由IT人员协助接线
对会议室端口启用端口安全（限制MAC地址数量为2个），减少环路风险

4. 网络监控增强

在Zabbix中新增以下监控项：

接入交换机CPU利用率 >70% 触发告警
接入交换机MAC表项数量超过阈值的80%触发告警
单端口出方向流量持续超过800Mbps超过30秒触发告警
STP拓扑变更通知（TCN）次数监控，单台交换机5分钟内超过3次触发告警

总结

这次故障的教训非常深刻：防护机制配置了不等于生效了。端口下写了stp edged-port enable，但全局STP没开，等于白搭。就像买了保险但没激活保单，出事了才发现根本赔不了。

网络运维中，以下几点值得铭记：

全局开关优先于端口配置——STP、DHCP Snooping、环路检测等功能都有全局开关，配置时一定要先确认全局是否启用。这不仅是华为设备的特点，思科、H3C、锐捷等厂商也是同样的逻辑。
配置合规检查要自动化——人工检查永远有遗漏，尤其是批量设备上线的时候。脚本巡检+告警推送，才是可靠的保障。
物理环路是最暴力的故障——一个简单的双头插线操作，就能在几秒内让一台48口交换机的CPU跑到100%，MAC表打满，三层设备也跟着遭殃。二层环路的影响范围和扩散速度远超大多数网络故障，必须把STP当成本命技能来维护。
BPDU Guard是终端接入的最后一道防线——接入端口设为边缘端口+BPDU Guard，一旦有终端侧设备发BPDU就自动err-down，简单粗暴但极其有效。

最终，从故障发生到网络恢复，用时约18分钟。其中5分钟是确认故障范围，3分钟是定位环路端口，2分钟是检查STP状态，1分钟shutdown止血。如果STP正常启用，这个环路从产生到被自动阻断只需要几秒钟，用户甚至不会感知到——这才是网络协议应有的价值。

排查工具备忘：display mac-address flapping、display stp global、display cpu-usage、display interface brief是二层环路排查的四件套，建议熟记。

记一次 DHCP 地址池耗尽引发的大面积断网

Thu, 27 Mar 2025 12:15:27 +0000

问题背景

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

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

故障现象

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

新接入设备无法获取 IP：部分刚开机或重新连接的电脑显示"正在获取网络地址”，持续等待后最终提示"无 Internet 连接"，ipconfig /all 显示 IP 为 0.0.0.0。
已在线设备部分正常：之前已经拿到 IP 且租期未过期的设备暂时还能上网，但网络明显变慢， ping 内网网关偶尔出现 50-200ms 的异常延迟。
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 是否正常运行：

<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。这几乎可以确定是地址池出了问题。

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

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

<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 地址表：

<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 租约，立即释放被占用的地址：

<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 小时，让所有现有租约快速过期：

<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 小时后所有设备的租约都会到期需要重新续租，到那时我们再通过端口安全策略拦截非法设备。

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

<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 和访客设备独立网段

<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. 端口安全——限制接入设备数量

<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 防护

<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 绑定表便于审计。

根因分析

问题的根本原因有三层：

网络架构设计缺陷：所有设备（办公电脑、手机、IoT、测试设备）混在同一个 VLAN 里，没有按设备类型做网络隔离。地址池按"办公电脑数量"规划，完全忽略了无线 AP 下挂的手机和 IoT 设备。
DHCP 租期过长：1 天的租期导致设备断开连接后 IP 仍然被占用长达 24 小时。手机这种高流动性设备（连上 Wi-Fi 就拿 IP，离开后 IP 一直不释放）是地址池耗尽的最大推手。
无线网络缺乏准入控制：办公 Wi-Fi 无认证无过滤，任何人的手机都可以随意接入，等于给 DHCP 地址池开了一个无底洞。

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

预防措施

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

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

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

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 的正常设备。

核心交换机 STP 根桥被抢，广播风暴怎么来的？

Mon, 03 Feb 2025 13:26:40 +0000

一、问题背景

公司园区网采用典型三层架构：核心层一台华为 S7706（以下简称 CORE）作为 STP 根桥，汇聚层两台 S5730，接入层大量 S5731 接入交换机，全网联一、二层均启用 MSTP（多生成树）。根桥 CORE 上通过 stp root primary 设定为最优根，优先级 0（实际显示为 0/4096，按实例计），确保生成树拓扑稳定。

节后复工第一天，行政楼 3 层新扩了 12 个工位，施工方临时搬来一台华为 S1730S 傻瓜型可网管交换机（以下简称 NEW）用于补点。该交换机按惯例应作为接入层叶子节点挂到现有接入交换机下，不配置 STP 优先级（用默认 32768），乖乖当阻塞端口的下游即可。中午 13 点左右，行政楼整层及相邻的 2、4 层陆续出现网络卡顿、视频会议花屏、部分工位甚至拿不到 IP。

二、故障现象

现场观察与监控告警汇总如下：

行政楼 2/3/4 层用户大面积反馈“网页打开慢、钉钉转圈、共享文件夹访问超时”，但核心业务系统（位于数据中心）偶发可达，整体是“时通时断”的严重劣化，而非完全断网。
登上汇聚交换机 display interface brief，发现多个上联口入方向带宽长期 90%+，且 Broadcast 计数每秒几万包疯涨：

1
2
3

Interface                  PHY   Protocol  InUti  OutUti  Broadcast(pps)
GE0/0/24                   up    up        98%    95%     42000
GE0/0/23                   up    up        97%    92%     39000

接入交换机面板端口指示灯呈“集体疯狂闪烁”状态，典型广播风暴特征。
网管平台 Zabbix 触发 High Broadcast Ratio 与 STP Topology Change 告警，且 Topology Change Count 在几分钟内从 0 涨到 600+，说明生成树在频繁震荡重算。

三、排查过程

广播风暴 + 拓扑频繁变更，基本锁定在二层环路或 STP 异常，按“先抑制、再定位”的思路推进。

先登录核心 CORE，查看当前根桥是否还是自己：

`1`	`display stp`

-------[CIST Global Info][Mode MSTP]-------
Protocol Status       : Enabled
Bridge Priority       : 0
Root Bridge ID        : 4c1f-ccxx-xxxx
Root Cost             : 0

Root Bridge ID 的 MAC 不是 CORE 自己的桥 MAC，而是 4c1f-cc...，说明根桥被别人抢走了！本应是自己（Cost 0、自己就是根），现在 Root Cost 仍是 0 只是因为命令行显示的是“到根的开销”，需要进一步比对。

精确查看根桥身份：

`1`	`display stp root`

1
2

Root Bridge ID   : 4c1f-cc12-3456
Root Bridge Cost : 0

4c1f-cc12-3456 经 MAC 前缀查询是华为 S1700 系列，正是那台新搬来的 NEW 交换机！它成了根桥。

查看 NEW 的 STP 优先级：

`1`	`display stp \| include Bridge Priority`

在 NEW 上回显 Bridge Priority : 0（被施工方误设为 stp priority 0 或 stp root primary 想“保证稳定”），优先级高于 CORE，于是 STP 重新选举，NEW 抢占根桥。

根桥漂移后，原稳定拓扑被推翻， NEW 与周边交换机之间形成次优路径且出现临时环路窗口，广播帧在环路中无限泛洪，形成广播风暴。再查拓扑变更：

`1`	`display stp topology-change`

1
2

Topology Change Count : 612
Last Topo Change Time : 2025-02-03 13:02:11

与告警时间吻合，确认 NEW 接入是触发点。

四、解决方案

目标是让 CORE 恢复根桥、消除环路、压制风暴。

应急抑制：在汇聚/核心上临时对上联接入口开启广播抑制，先止血，避免风暴蔓延：

1
2

interface GigabitEthernet0/0/24
 storm-control broadcast min-rate 1000 max-rate 5000

纠正根桥：将 NEW 的 STP 优先级改回默认，并取消其抢占设置：

1
2
3

system-view
stp priority 32768
undo stp root

强制 CORE 重新稳坐根桥（双保险）：

1
2

system-view
stp root primary

等待 STP 重新收敛后，再次 display stp root，根桥 MAC 变回 CORE，Topology Change Count 停止增长，端口 Broadcast pps 回落到个位数，用户网络在 3 分钟内恢复。
事后复盘：NEW 作为临时补点本应只做接入，施工方却顺手配了根桥优先级。已要求所有接入层设备出厂/入场前统一刷标准配置模板，禁止任何非核心设备设置 stp root 或优先级低于 8192。

五、根因分析

根因是 NEW 交换机被错误配置了 STP 优先级 0（等价于 stp root primary），使其桥优先级高于原根桥 CORE。MSTP 选举根桥时比较“桥优先级 + MAC”，优先级数值越小越优，0 优于 CORE 的 4096（显示值），于是 NEW 被选举为新的根桥。

根桥变更触发全网生成树重算：大量端口角色/状态翻转（根端口、指定端口、阻塞端口重新分配），在收敛的过渡窗口内，本应阻塞的冗余链路短暂进入转发态，与既有物理连线构成二层环路。广播帧、未知单播帧在环路中反复泛洪且无法 TTL 终结，迅速演变为广播风暴，表现为端口灯狂闪、Broadcast pps 爆表、终端卡顿断网。拓扑每次震荡又产生新的 TC（Topology Change）报文，进一步加剧不稳定，形成“变更—环路—风暴—再变更”的恶性循环，直到根桥归位、环路消除才停止。

六、预防措施

根桥保护（Root Protection）：在所有的接入交换机上联口配置 stp root-protection，一旦收到更优 BPDU 直接将该口置为 root-inconsistent（丢弃）状态，从协议层面杜绝下级设备抢占根桥。

1
2

interface GigabitEthernet0/0/1
 stp root-protection

BPDU 保护（BPDU Protection）：在连接终端/临时设备的边缘端口开启 stp edged-port enable 并全局 stp bpdu-protection，收到 BPDU 立即 shutdown 边缘口，防止私接设备扰乱生成树。
标准配置模板 + 入场审计：所有交换机（含临时补点）入场前必须刷公司标准模板，模板中明确禁止设置 stp root 与低优先级，并由网络组验收后方可上线。
环路防护与 TC 防护：开启 loop-protection 与 tc-protection，限制单位时间 TC 报文处理速率，避免频繁重算拖垮 CPU。
监控加固：在 Zabbix 对 Topology Change Count、Broadcast pps、端口利用率设阈值告警，争取在风暴成形前发现。

七、总结

这起广播风暴的根因不在“环路本身”，而在“根桥被抢”——一台被误配优先级的临时交换机颠覆了整网生成树，收敛窗口里出现的瞬时环路才是风暴的直接推手。排查关键在于第一时间 display stp root 比对根桥 MAC，发现身份异常便知有人抢桥。最该记住的教训是：STP 不能只靠“约定”，必须用 root-protection、bpdu-protection 等协议机制把根桥和边缘口钉死，再配合标准模板与入场审计，才能避免“好心配置”变成全网故障。

记一次 ARP 欺骗攻击导致的楼层网络间歇断网

Wed, 14 Aug 2024 16:10:00 +0000

问题背景

公司办公楼 3 楼为市场部和法务部办公区，该楼层通过一台 H3C S5130 接入交换机上联至核心交换机。接入交换机下联约 60 个工位端口和一个会议室的墙插。网络规划为 VLAN 30（192.168.30.0/24），网关为 192.168.30.1，由核心交换机提供 VLAN 间路由。

故障现象

下午 2:30 开始，3 楼多名同事反馈网络间歇性断网。现象非常规律：

每 15-20 分钟触发一次
断网期间 ping 网关 192.168.30.1 丢包率 80-90%
断网持续 2-3 分钟后自动恢复
恢复后一切正常，直到 15 分钟后再次断网
断网期间可以在本网段内互 ping（同 VLAN 通信正常，跨 VLAN 不通）

典型现象是浏览器页面打不开、企业微信掉线、内网 OA 超时。

排查过程

第一步：基础网络诊断

断网时登录到故障终端检查：

PS> ipconfig /all
IPv4 Address: 192.168.30.85
Subnet Mask: 255.255.255.0
Default Gateway: 192.168.30.1
DHCP Server: 192.168.30.1

PS> arp -a
Interface: 192.168.30.85 --- 0x16
  Internet Address     Physical Address         Type
  192.168.30.1         00-0c-29-3a-7b-1e       dynamic
  192.168.30.1         8c-53-c3-12-45-8f       dynamic    # 两个不同MAC！

网关 IP 对应了两个不同的 MAC 地址——这是 ARP 欺骗的经典特征！

00-0c-29-3a-7b-1e 是 VMware 虚拟网卡（核心交换机的 MAC）
8c-53-c3-12-45-8f 是小米设备的 OUI（小米公司）

第二步：抓包确认

在接入交换机上做端口镜像，用 Wireshark 在断网期间抓包：

filter: arp
Time          Src MAC            Src IP           Dst IP
16:12:15.523  00-0c-29-3a-7b-1e  192.168.30.1    192.168.30.0/24  (正常ARP)
16:12:15.789  8c-53-c3-12-45-8f  192.168.30.1    192.168.30.0/24  (伪造ARP!)

一台小米设备在以 192.168.30.1 的身份广播免费 ARP（Gratuitous ARP），持续宣告"我才是网关"。

第三步：追踪恶意设备

MAC 地址表追踪：

1
2
3

[H3C] display mac-address 8c53-c312-458f
MAC Address      VLAN  Port             State
8c53-c312-458f   30    GigabitEthernet1/0/12   Learned

对应端口为 G1/0/12——会议室墙插。

会议室里发现了一台员工自带的小米路由器。该路由器 WAN 口接入了墙插，LAN 口被用来给手机充电（只插了电源线无网线），但路由器的 DHCP 服务已自动开启。

第四步：分析断网-恢复的循环机制

小米路由器通过 WAN 口从公司 DHCP 获取了 192.168.30.200，但它自身开启了 DHCP 服务且地址池默认为 192.168.30.100-192.168.30.250，发送的 DHCP OFFER 中也包含自己作为网关。

同时，路由器启动了 ARP 代理功能，收到 ARP 请求时会以自己的 MAC 地址应答——于是出现了"双网关 MAC"现象。

为什么是 15 分钟周期？因为 Windows 的 ARP 缓存超时时间默认为 ArpCacheLife = 15 分钟。终端缓存了正版网关的 ARP 后在周期内正常，过期后重新发起 ARP 请求，有概率收到小米的伪造应答，于是切换到"假网关"，流量被黑洞。

解决方案

物理拔除：立即拔掉小米路由器的 WAN 口网线，问题当场恢复。
交换机端口安全加固：

[H3C] interface GigabitEthernet1/0/12
[H3C-GigabitEthernet1/0/12] port-security enable
[H3C-GigabitEthernet1/0/12] port-security max-mac-count 1
[H3C-GigabitEthernet1/0/12] port-security port-mode autolearn

全局开启 DHCP Snooping + DAI（Dynamic ARP Inspection）：

[H3C] dhcp snooping enable
[H3C] interface GigabitEthernet1/0/1 to GigabitEthernet1/0/48
[H3C-range] dhcp snooping trust          # 上联口设trust
[H3C-range] arp detection enable         # 开启ARP检测

根因分析

直接原因：员工自带的小米路由器接入公司网络后，其内置 DHCP 服务和 ARP 代理功能干扰了正常网络通信，终端随机获取到假网关的 MAC 地址。

深层原因：

接入交换机未启用端口安全，任何设备插上就能通信
未部署 DHCP Snooping，无法阻止非法 DHCP 服务器
未部署 ARP 防护（DAI），无法过滤伪造的 ARP 报文
缺少"禁止私接网络设备"的行政管理制度

预防措施

技术层面：
- 全交换机启用 DHCP Snooping + DAI + IP Source Guard
- 接入端口绑定端口安全（max-mac-count=1）
- 802.1X 准入控制，陌生设备无法获取网络访问权限
管理层面：
- 发布《办公网络安全管理规定》，明确禁止私接路由器、随身WiFi等设备
- 新员工入职时签署网络安全承诺书
监控告警：
- 监控交换机日志中的 MAC flapping 和 duplicate IP 事件
- ARP 表异常变动触发告警

总结

一个价值 99 元的小米路由器，差点瘫痪了整个楼层的网络。“自带设备"是办公网络中最大的不可控因素。ARP 欺骗不是只有黑客才会做，很多时候一个同事的无心之举就能造成同等级别的破坏。从源头上看，只要开启 DHCP Snooping + DAI + 端口安全这"三件套”，99% 的类似事件都可以在接入层被扼杀在摇篮里。

记一次核心交换机 LACP 协商失败致带宽骤降

Sun, 05 Feb 2023 10:45:00 +0000

问题背景

公司数据中心采用 Spine-Leaf 架构，核心层由两台华为 CE12800 组成集群，汇聚层为 CE6800，核心与汇聚之间通过 2 条 10G 光纤链路做 LACP 链路聚合，逻辑带宽 20Gbps。汇聚下联 40 台物理服务器，承载微服务集群。

故障现象

上午 10:00，运维监控突然发出多条告警：多个微服务实例的连接池耗尽，Nginx 日志中 upstream timed out 错误激增。服务器之间 ping 延迟从 <1ms 飙升到 15ms-30ms，但未出现完全断网。

# 核心交换机上查看聚合组状态
[CE12800] display eth-trunk 10
Eth-Trunk10's state information is:
WorkingMode: NORMAL
LAG ID: 10
Operating Status: down      # 一条成员口 down！
...
Member Port Status:
GigabitEthernet1/0/1: Up    (Selected)
GigabitEthernet1/0/2: Down  (Unselected)

链路聚合组（Eth-Trunk）中 G1/0/2 状态为 Down/Unselected——20G 聚合组只剩一条链路在工作，带宽减半。业务高峰期的流量（峰值约 14Gbps）超过单链路 10Gbps 容量，导致拥塞丢包。

排查过程

第一步：物理层排查

[CE12800] display interface gigabitethernet 1/0/2
GigabitEthernet1/0/2 current state: UP
Line protocol current state: UP
...
Last physical up time: 2023-02-05 09:58:21   # 今天刚up过
Last physical down time: 2023-02-05 09:47:15  # 9:47掉线

端口物理层 UP，光功率正常：

1
2
3

[CE12800] display transceiver interface gigabitethernet 1/0/2
RX Power(dBM): -5.21   # 正常范围 -1 ~ -10
TX Power(dBM): -2.35   # 正常

物理层没有问题。

第二步：检查 LACP 协商日志

[CE12800] display lacp statistics eth-trunk 10
Port: GigabitEthernet1/0/2
  LACPDUs Sent: 0          # 未发送任何LACPDU！
  LACPDUs Received: 4852
  Marker Sent: 0
  Marker Received: 0

本端收到了对端发来的 LACPDU 包（4852 个），但本端一条 LACPDU 都没发送——说明本端压根没有启动 LACP 协商。

[CE12800] display eth-trunk 10 verbose | include "Actor|Partner|System"
Actor System ID: 0x8000, 00e0-fc12-3456
Partner System ID: 0x8000, 00e0-fc65-4321
Actor System Priority: 32768
Partner System Priority: 32768

对端的 System ID 是本端完全不认识的 MAC——汇聚交换机不是被换过主控板，就是这条光纤插到了另一台设备上。

第三步：追踪物理链路

登录汇聚交换机 CE6800 检查：

1
2

[CE6800] display interface gigabitethernet 1/0/24
Description: TO-CORE-01-G1/0/2

光模块信息显示型号是 SFP-10G-SR（多模，850nm），但核心交换机这一端的型号是 SFP-10G-LR（单模，1310nm）。两个模块的波长和光纤类型完全不匹配！

进一步追溯变更记录：前天晚上有人更换了 CE6800 侧的故障光模块，但使用了库存中型号不匹配的备件——应该装 SFP-10G-LR，却装了一支 SFP-10G-SR。

两端的物理层其实都是 UP：核心端看到了 1310nm 波长的光（来自汇聚端原装 LR 模块的漏光），汇聚端看到了 850nm 波长的光（来自核心端 LR 模块的漏光），所以接口显示物理 UP，但实际上两端根本不是同步通信——只能在极低速率下看到对方的 LACPDU 包却无法正常协商。

解决方案

更换正确光模块：将 CE6800 侧的 SFP-10G-SR 更换为 SFP-10G-LR，接口短暂 down/up 后 LACP 自动协商成功。
验证聚合带宽：

[CE12800] display eth-trunk 10
Member Port Status:
GigabitEthernet1/0/1: Up (Selected)
GigabitEthernet1/0/2: Up (Selected)   # 恢复

业务流量恢复，延迟回落到正常水平。

根因分析

直接原因：备件管理中光模块型号混用——SFP-10G-SR（多模短距）替换了 SFP-10G-LR（单模长距），波长和光纤类型不匹配，导致 LACP 协商数据包只能勉强到达但无法完成协议握手。

深层原因：

备件仓库光模块未按型号分库存放和标识
更换流程中没有"更换前验证型号、更换后验证链路聚合状态"的标准化步骤
缺少光模块插入后的自动型号校验告警

预防措施

光模块备件管理：所有备件按型号独立存放，标签标注类型、波长、适用场景
更换 SOP：光模块更换必须包含"更换前拍照记录型号 → 更换后验证 eth-trunk 状态"两步
交换机告警规则：新增"Eth-Trunk 成员口状态变更"告警，成员口 Down/Unselect 立即通知
光模块数字诊断：定期通过 display transceiver 收集全量光模块的型号、序列号，生成资产清单
备件定期盘点：每季度盘点光模块备件，清点型号和数量

总结

链路聚合故障的排查往往最先关注的是协议配置、系统版本、电缆质量，很少人会第一时间想到——光模块型号。但这次就是典型的物理层欺骗：两个波长不对的光模块硬生生点亮了对方的端口状态灯（因为确实检测到了光），让运维在第一轮排查时排除了物理层故障的可能性。在数据中心环境中，光模块型号的严格管理不是矫情，是底线。

核心交换机 STP 风暴，全楼网络为何瘫痪？

Wed, 08 Jun 2022 14:20:00 +0000

问题背景

某周三下午 14:20 左右，公司全楼约 300 名员工突然反映网络中断，表现为无法访问内网系统、互联网全部断开。影响持续约 25 分钟，直到网络恢复正常。

公司网络架构为三层设计：核心层（H3C S7503 核心交换机 ×2，堆叠）、汇聚层（各楼层汇聚交换机）、接入层（各区域接入交换机）。出口通过核心交换机直连防火墙接入互联网。

事故期间 IT 监控告警系统收到大量告警：核心交换机 CPU 使用率达到 100%，大量接口出现 CRC 错误。

故障现象

全楼用户无法访问内外网，ping 内网网关均超时
核心交换机 SSH 无法登录（CPU 负载过高导致管理面板无响应）
监控系统显示核心交换机上行接口流量在故障期间突然暴增至满带宽
各楼层汇聚交换机日志中出现大量 MAC 地址表抖动告警：

%STP-3-TOPOLOGY_CHANGE: Topology Change notification received on GigabitEthernet1/0/12
%STP-3-TOPOLOGY_CHANGE: Topology Change notification received on GigabitEthernet1/0/12
%STP-3-TOPOLOGY_CHANGE: Topology Change notification received on GigabitEthernet1/0/12
（以上日志每秒出现数十条）

核心交换机 CPU 告警日志：

`1`	`%SYSTEM-3-CPU_OVERLOAD: CPU utilization reached 100%`

排查过程

第一步：现场快速响应

接到告警后立即赶到机房，此时核心交换机 SSH 已经无法连接，只能通过 Console 口连接。Console 口可以登录，但响应非常慢，输入命令后需要等几秒才有回显。

第二步：查看当前 CPU 状态

1
2
3

<H3C-Core> display cpu-usage
Slot 1:
CPU Usage: 100%

CPU 持续 100%，正常运维操作受阻。先查看进程占用：

1
2
3

<H3C-Core> display process cpu
Process  CPU%  Process Name
STP      89%   Spanning Tree Protocol

STP 进程占用了 89% 的 CPU，几乎可以确认是生成树相关问题。

第三步：查看 STP 状态

<H3C-Core> display stp brief
 MST ID  Port                     Role  STP State    Protection
  0      GE1/0/1                  DSGN  FORWARDING   NONE
  0      GE1/0/2                  DSGN  FORWARDING   NONE
  0      GE1/0/12                 ROOT  FORWARDING   NONE
  ...

注意到 GE1/0/12 这个接口频繁出现拓扑变更通知（TCN），正常情况下 STP 拓扑是稳定的，不应该持续触发 TCN。

第四步：定位问题接口

查看 GE1/0/12 接口详情：

<H3C-Core> display interface GigabitEthernet 1/0/12
GigabitEthernet1/0/12 current state: UP
Input bandwidth utilization : 99.8%
Output bandwidth utilization: 99.7%

接口带宽利用率接近 100%，流量极不正常。

查看该接口连接的设备：

<H3C-Core> display lldp neighbor interface GigabitEthernet 1/0/12
Neighbor index  :1
Chassis ID      :5c-dd-70-xx-xx-xx
Port ID         :GigabitEthernet1/0/1
TTL             :120s
System name     :SW-Floor3-Access

该接口连接的是三楼的接入交换机。再查看三楼接入交换机的 MAC 地址表变化情况（通过另一条管理路径连上汇聚交换机，再 telnet 到接入交换机）：

1
2
3

[SW-Floor3-Access] display mac-address learning
MAC address learning: enabled
MAC entries: 8764 (normal: 256)

MAC 表条目高达 8764！正常一台接入交换机最多几百条，出现这么多条目强烈说明有广播风暴，MAC 地址表在不断刷新。

第五步：找到广播风暴源头

在三楼接入交换机上，查看各接口的流量情况，发现有两个接口的 In/Out 流量都异常高：

GE1/0/23：In 95% / Out 94%
GE1/0/24：In 96% / Out 95%

立刻到现场查看这两个接口连接的是什么设备。

发现问题所在：三楼的一个会议室，一台 5 口的 TP-Link 哑交换机（无管理接口）将它的两个口分别插到了接入交换机的 GE1/0/23 和 GE1/0/24，形成了一个环路！

经询问，是当天下午有人觉得会议室网口不够用，就从库房找了一台旧的哑交换机接上，并且为了多用几个口，把两根网线都插到了楼层接入交换机上（一根接到 23 口，另一根接到 24 口），然后把会议室的网线也接到哑交换机上。这台哑交换机没有 STP 支持，直接形成了二层环路。

第六步：验证并处理

立即拔掉哑交换机上的一根网线，断开环路。

几秒钟后，核心交换机 CPU 开始下降：

1
2
3

CPU Usage: 67%  (30 seconds later)
CPU Usage: 24%  (60 seconds later)
CPU Usage:  8%  (90 seconds later)

全楼网络逐渐恢复，SSH 可以正常登录。

解决方案

立即处理：

移除会议室哑交换机，或只保留一根网线连接到楼层交换机
对接入交换机的 GE1/0/23 和 GE1/0/24 端口开启 BPDU Guard 和 Port Fast（如接入层交换机支持）

接入交换机端口配置（以 H3C 为例）：

1
2
3

[SW-Floor3-Access] interface GigabitEthernet 1/0/23
[SW-Floor3-Access-GE1/0/23] stp edged-port enable
[SW-Floor3-Access-GE1/0/23] stp bpdu-protection enable

stp edged-port enable 将该端口设为边缘端口（快速进入转发状态），stp bpdu-protection 确保一旦收到 BPDU 就关闭端口，防止哑交换机引发环路。

对所有接入端口（下联终端的端口）批量开启保护：

`1`	`[SW-Floor3-Access] stp bpdu-protection`

此命令在全局开启 BPDU Guard，适用于所有已配置为边缘端口的接口。

根因分析

此次事故的根本原因是未经授权的网络设备接入，且接入的是不支持 STP 的哑交换机，直接造成二层环路。环路导致广播风暴，大量 STP TCN 帧充斥网络，核心交换机 STP 进程持续处理拓扑变更请求，CPU 飙至 100%，正常数据转发能力丧失，全楼断网。

预防措施

1. 端口安全配置（核心）

所有接入端口启用 BPDU Guard 和 Port Fast，一旦检测到非法接入的交换机就自动关闭端口：

1
2

# 全局开启接入端口保护
stp bpdu-protection

2. 端口 MAC 地址绑定

对固定位置的终端，绑定 MAC 地址，防止未知设备接入：

1
2
3

port-security enable
port-security max-mac-count 1
port-security violation restrict

3. 用户权限管控

制定规定：任何人不得自行增减或调整网络设备，需求须提交 IT 工单处理。

4. 监控告警细化

完善接入层交换机的 STP 拓扑变更告警，发现 TCN 频繁触发时立即通知运维人员，缩短响应时间。

总结

这次事故对我们的提醒是：二层网络的风险往往来自"无害"的小设备。一台十几块钱的哑交换机就能让全楼断网 25 分钟，损失的是几百人的工作效率。

对于 IT 运维来说，不仅要把核心网络设备管理好，接入层的安全策略同样不可忽视。BPDU Guard、Port Security 这些配置看起来很基础，但往往是防止意外事故的关键防线。

另外，员工的安全意识培训也很必要——让大家知道"随便接交换机"可能会带来什么后果。