一次接入交换机storm-control阈值过低误杀正常广播导致整层间歇卡顿的排查记录

Tue, 12 May 2020 07:05:00 +0800

问题背景

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

故障现象

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

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

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

排查过程

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

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

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

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

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

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

时间	变更	备注
T-12 天	接入模板统一下发 storm-control	广播/组播/未知单播均启用
T-12 天	阈值写法从「按端口速率百分比」改为「绝对值 pps」	模板来自数据中心万兆口经验值
T 日起	早高峰工单抬头	与 DHCP 租约集中续期日叠加后更重

关键点：模板里广播抑制写的是类似「每口 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

观察要点：

故障时段 Input broadcast 上升的同时，StormControl / broadcast-suppression 丢弃计数同步爬升。
上联口广播占比并不夸张——说明广播主要在接入 VLAN 内横向，被入口策略直接扔掉，还没冲到汇聚。
有人第一反应去查 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. 对比实验：抬阈值 / 临时关闭验证

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

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

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

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

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

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

解决方案

止血（分钟～小时级）

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

根治（制度化）

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

根因分析

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

深层原因有三：

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

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

预防措施

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

总结

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

StormControl Drops on Zero Day Notes