问题背景

某园区办公网采用「核心—汇聚—接入」三层架构，接入以千兆电口交换机为主，按楼层划分 VLAN，上网认证走 802.1X + 访客门户并存。安全基线整改周期里，厂商模板与「防广播风暴」要求被一并下发到接入口：对 broadcast / multicast / unicast 打开 storm-control，并把 pps 阈值写得很「保守」——目的是防环路、防恶意洪泛，本意没错。整改后第二周起，三层某侧办公区开始出现「早高峰卡一会儿、中午又好了」的间歇性故障：网页偶发打不开、打印机发现不了、域登录慢半拍，但核心链路、出口防火墙、DNS 监控曲线都近乎正常。业务侧最初当成「无线干扰」和「电脑有毒」，网络侧则长期被「带宽利用率不高」的表象误导。根因最终落在接入口 storm-control：阈值按万兆/十万兆模板缩放过小，把合法的 ARP、DHCP、mDNS 等正常控制面广播当成了风暴，静默丢包。

故障现象

故障形态「轻」、时间「尖」，很容易被当成桌面问题：

1. 时段性强：工作日 08:30–09:30、13:30–14:30 最重；晚间与周末几乎无感。恰是终端集中开机、大量 DHCP/ARP 并发窗口。
2. 范围按接入边界切：同一汇聚下，A 楼层整片间歇卡顿，相邻 B 楼层正常；有线与同楼无线 AC 覆盖区同步受影响，说明问题在接入二层而非单台 PC。
3. 业务表象分散：HTTPS 偶发超时、共享盘列表慢、OA 单点登录跳转卡、打印机/扫描仪发现失败；ping 网关多数时间通，丢包呈突发尖峰而非持续高延迟。
4. 监控「看起来没事」：上联口带宽峰值不足 20%，CPU/内存正常，STP 无拓扑变更，出口会话表与 DNS 延迟正常；只有接入交换机接口计数里 Broadcast Suppress / StormControl drops 类计数在早高峰陡增——而这条计数默认未进值班大屏。
5. 自愈假象：过了高峰丢包归零，用户「刷新一下就好了」，工单大量关成为「无法复现」。

串起来看：不是链路挂了，而是接入口在合法广播高峰时主动「限速误杀」。

排查过程

1. 先画边界：从「整网」缩到「某楼层接入」

按「核心 → 汇聚 → 接入 → 终端」自上而下排除：

• 核心与出口：无告警、无会话打满、无策略变更窗口重合。
• 汇聚：与故障楼层同机的其他 VLAN 正常，跨楼互通也正常，排除汇聚上行与核心侧。
• 接入：故障楼层两台堆叠成员的用户口在故障时段同时出现 storm-control drop 计数上涨；上联口 drop 不明显。
• 抽样终端：有线直连接入口复现「间歇 ARP 超时」；换到其他楼层接入立即正常。

边界锁定在该楼层接入交换机的下联用户口策略，而不是线路质量或应用本身。

2. 对比变更窗口：安全基线何时改了 storm-control

变更平台与配置备份对账：

关键点：模板里广播抑制写的是类似「每口 100～200 pps」量级，对空闲口「看起来够用」，但对 /24 办公 VLAN + 早高峰集中开机 远远不够——一次合法的 ARP 解析风暴、DHCP Discover/Request、Windows 网络发现，就可能把计数顶穿。

3. 接口计数与 ACL/QoS 误区

在接入交换机上（以常见厂商命令语义为例，实际以设备 CLI 为准）：

1
2
3

display interface GigabitEthernet1/0/x
display storm-control interface
display logbuffer | include [Ss]torm

观察要点：

1. 故障时段 Input broadcast 上升的同时，StormControl / broadcast-suppression 丢弃计数同步爬升。
2. 上联口广播占比并不夸张——说明广播主要在接入 VLAN 内横向，被入口策略直接扔掉，还没冲到汇聚。
3. 有人第一反应去查 QoS 限速、端口安全 max-mac、DHCP Snooping 丢弃：这三项在本环境均有部署，但计数平稳，且 deny 日志形态不同，可排除。

抓包（镜像用户口 + 同源 VLAN 的空闲口）进一步验证：

• 高峰时客户端重传 DHCP Request、ARP Request 明显增多。
• 交换机 CPU 抓到的「应进软件处理」的协议报文稀少，与 drop 计数吻合——不是「没人发」，是「发了被战略丢弃」。

4. 算一笔「合法广播需要多少 pps」

粗算比拍脑袋重要：

• 单 VLAN 约 180 终端，早高峰 10 分钟内约 70% 开机或从休眠恢复。
• 每台上线常见组合：DHCP × 数次、网关 ARP、若干业务服务器 ARP、打印机/发现协议、组策略访问前的名字解析失败回退等。
• 瞬时同秒并发按「数十台同时发送」估，单口观测到的广播 pps 峰值轻松到数百；再叠加偶发的 mDNS/LLMNR（即便已计划关停，存量终端仍有），200 pps 绝对阈值会频繁误触发。

另：部分口把 multicast 一并压到极低，影响了合法的路由组播协议与部分会议终端发现——用户描述成「视频会议进不去会议室设备」，进一步干扰判断。

5. 对比实验：抬阈值 / 临时关闭验证

在维护窗口对单台非核心业务接入做对照：

1. 将故障口 storm-control 广播阈值临时提高到经计算后的安全水位（并保留未知单播的较严限制）。
2. 次日早高峰：该楼层工单清零，drop 计数接近 0，打印机发现恢复。
3. 回退阈值：症状 20 分钟内重现。

因果闭环成立：不是环路，也不是病毒扫段，是防护阈值低于合法控制面流量。

6. 排除真环路与病毒扫描

为防止「阈值问题」盖住真风暴：

• STP/RSTP：无 root 变更、无频繁 TCN；接入口 bpdu-guard 未动作。
• 流量镜像未见单一源 MAC 对全网段 ARP 扫穿；EDR 无内外网同步扫段告警。
• 历史上真环路（本站有独立复盘）特征是全网广播占比顶满上联、CPU 飙高、多楼层同时瘫；本次是单楼层、时段性、计数型丢弃，画像不同。

解决方案

止血（分钟～小时级）

1. 按 VLAN/楼层紧急抬升广播 storm-control 阈值到经测算的临时水位，或对已确认无环、有 BPDU Guard 的接入口暂时取消过严绝对值、改回「端口速率百分比」且百分比不低于经验下限。
2. 未知单播（UU） storm-control 保持偏严——真环路与 CAM 溢出时 UU 往往先爆，这是该功能真正该防的对象；与「合法广播」区分对待。
3. 值班大屏临时挂上接入 StormControl drops 与早高峰关联，避免再被「带宽正常」骗过。
4. 对仍异常的终端查是否有受损网卡驱动狂发 DHCP（个例），避免全局抬阈值后掩盖单点故障源。

根治（制度化）

1. 重写接入模板：broadcast / multicast / unicast 三套阈值分离设计；广播阈值按「VLAN 规模 × 上线模型 × 安全余量」计算，禁止直接套用数据中心或万兆口绝对值。
2. 变更门禁：storm-control、port-security、dhcp-snooping 同类二层防护变更，必须附「早高峰观察窗」与回滚阈值；灰度一栋楼再铺开。
3. 基线分层：办公接入、服务器接入、会议室/IoT 口分模板；IoT 口可更严，办公口给足合法协议余量。
4. 可观测性：把 storm-control drop、广播 pps 分位数进 NMS；连续 N 分钟超阈值告警但「上联带宽不高」时走专用 runbook，而不是派桌面重装系统。
5. 协议面收敛并行：在阈值合理的前提下，继续推进关闭 LLMNR/多余发现协议、规范 DHCP 租期与开机风暴（错峰唤醒），从源头降低合法广播峰值——防护与减负两手一起做。

根因分析

直接原因是接入交换机用户口 storm-control 广播（及部分组播）阈值过低，在早高峰合法控制面报文并发时触发硬件/软件抑制，报文被静默丢弃。

深层原因有三：

1. 模板错位：把机房/高带宽口的「防攻击绝对值」拷到办公千兆接入，未按终端密度重算。
2. 防护目标含混：broadcast 与 unknown-unicast 未区分；为「防环路」一刀切压广播，结果误伤 ARP/DHCP 等生存性协议。
3. 观测缺失：drop 计数未进主监控，故障自愈快，形成「无证据—难升级—反复工单」的闭环失败。

一句话：二层防护的阈值如果低于业务合法峰值，安全配置本身就会变成稳定性故障源。

预防措施

1. 设计阶段：接入模板评审必须包含「风暴控制阈值计算表」（VLAN 主机数、上线模型、协议清单、安全余量、UU 与广播分设）。
2. 变更阶段：二层防护类变更默认灰度 + 次日早高峰复盘；未过观察窗不得全网固化。
3. 运行阶段：监控 storm-control drop、广播 pps P95/P99；与「上联利用率」解耦告警，避免带宽正常就判健康。
4. 演练阶段：年度桌面推演增加「假风暴 / 真抑制」辨识——会看 drop 计数与抓包，而不是只看环路灯和 CPU。
5. 终端侧：规范镜像与开机脚本，减少无意义的全网段探测；IoT/打印机单独 VLAN，缩小广播域。
6. 文档与回滚：每栋楼保留「最后已知良好」的 storm-control 参数快照，支持一键回退。

总结

这是一起典型的「安全基线好心办坏事」：storm-control 本身是防广播风暴的正确控件，但阈值脱离办公接入流量模型后，会在早高峰把 ARP/DHCP 等正常广播当攻击丢掉，制造整层间歇卡顿，而核心带宽与出口监控几乎无感。排查关键是缩小边界到接入口、读懂 StormControl drop、用变更窗口与抬阈值对照实验闭环，并排除真环路。处理上应「UU 从严、广播按模型核定、监控补 drop、变更带早高峰观察窗」。对网络运维而言，任何限速/抑制类保护，都必须先回答「合法峰值是多少」——答不上来的阈值，就不该进生产模板。