1. 确认CPU升高来源
登录设备执行：
display cpu-usage
display cpu-usage history
查看是哪个任务或进程占用CPU。重点关注软中断、路由协议、STP、ARP等模块。
2. 检查ARP与MAC表项
该时段可能是终端批量上线/下线或ARP扫描导致。
display arp count
display mac-address count
display arp | include <异常IP段>
若ARP表项突增或存在大量未解析条目，可考虑开启ARP限速或调整ARP老化时间。
3. 检查STP拓扑变化
部分接口配置边缘端口，若其他接口发生STP震荡，会导致CPU处理拓扑变更。
display stp topology-change
display stp tc
若TC频繁，需定位震荡端口，将其配置为边缘端口或启用BPDU保护。
4. 检查广播/组播流量
display interface | include broadcast|multicast
查看是否存在广播风暴或异常组播流量冲击CPU。
5. 检查管理面保护
确认是否开启管理面保护功能，避免业务流量冲击CPU影响管理通道。
display maa
若未开启，可配置：
maa
maa slot 1
maa global
6. 抓包分析
在故障时段对管理VLAN进行镜像抓包，确认是否存在大量发往CPU的协议报文（如ARP、ICMP、SNMP等）。
7. 版本与已知问题
确认设备软件版本，查询H3C官网或论坛是否有类似已知问题及补丁版本。
建议优先排查ARP和STP，这两类问题最符合“定时出现、业务正常、管理异常”的特征。
最可能的原因
1. 非边缘端口的 TC 风暴（首要怀疑）
- 没配
stp edged-port的接入口，终端关机/拔线/休眠时会产生 TC（拓扑变化） - 下班时大量终端同时下线，TC 报文激增，全网交换机清空 MAC 表，未知单播泛洪，CPU 升高
- 汇聚和接入同时出问题，符合 TC 全网扩散的特征
2. 终端下线/上线引发的协议报文上送
- ARP、DHCP、mDNS/SSDP/NetBIOS 广播在下班前后集中出现
- 如果有 ARP 扫描、网关 ARP 表项老化重建，也会冲击 CPU
3. 环路或 MAC 漂移（需排除）
- 个别小交换机/桌面 hub 接回，傍晚人多时触发
排查步骤
在故障窗口内抓现场：
display stp tc-bpdu-statistics # 各端口 TC/TCN 收发计数 display stp history # 拓扑变化历史 display stp root # 确认根桥有没有变 display cpu-usage history # CPU 趋势 display cpu-usage # 看是哪个进程高 display cpu-defend statistics all # 各协议上送 CPU 的计数与丢弃 display mac-address mac-move # MAC 漂移（型号不同命令略有差异）display logbuffer | include (STP|LOOP|MAC|ARP)重点看：
- TC 计数是否在故障时段明显增长，来自哪个端口（定位源头）
- CPU 高的进程是 STP、ARP、DHCP 还是 MAC 相关
cpu-defend里哪类报文上送量大
STP/6/STP NoTIFIED TC: Instance 0's port Ten-GigabitEthernetl/0/45 was notified a topology change. 确实是和TC相关，但是我抽取了几台接入交换机进行检查都是有配置边缘端口的，并且通过display stp tc查看了接入汇聚接入TC收发，其实从下联接收较少，但是重要是从上联接收比较多，发现主要要是核心send多，从下联re 的少，不知道华为有什么机制会造成TC一直往外发送
STP/6/STP NoTIFIED TC: Instance 0's port Ten-GigabitEthernetl/0/45 was notified a topology change. 确实是和TC相关，但是我抽取了几台接入交换机进行检查都是有配置边缘端口的，并且通过display stp tc查看了接入汇聚接入TC收发，其实从下联接收较少，但是重要是从上联接收比较多，发现主要要是核心send多，从下联re 的少，不知道华为有什么机制会造成TC一直往外发送
- 故障时间固定在 17:00‑18:30 下班时段；
- 终端业务访问正常，仅交换机管理 IP ping 延迟巨大（2000ms）、偶发 ping 不通；
- 故障期间 CPU 上升；
- 只有部分接入端口配置 stp edged‑port 边缘端口，大量终端口未配置边缘端口。
原理关键点：S66 是芯片硬件转发，用户业务流量走芯片快转不受 CPU 影响；但 ping 交换机本机属于上送 CPU 的控制平面报文；CPU 被大量协议报文占满之后，管理 ICMP 报文排队延迟、丢包，但是二层三层业务转发不受影响H3C。
下班时间特征：大量办公电脑、IP 电话、无线终端关机、下线，大量端口同时 down/up，触发 STP 拓扑变更 TC 报文、大量 ARP、DHCP 报文上送 CPU，这是该故障最匹配场景华为。
主要根因（按概率排序）
1、大量终端接入端口没有配置边缘端口（最高概率）
终端 PC、电话、AP 下线 / 关机，端口物理 down；非边缘端口端口 down 会触发发送 STP TC 拓扑变更报文，TC 报文全网泛洪。 TC 报文触发全网交换机：清空 MAC 地址表，快速重新学习 MAC，同时大量 ARP‑Miss 报文上送 CPU；下班时段批量终端下线，短时间持续产生大量 TC，CPU 升高，管理报文排队延迟，业务硬件转发不受影响H3C。
现状：只有部分端口配边缘端口，剩余大量终端口没有配置
stp edged‑port enable，批量终端上下线就触发大量 TC 震荡。
2、下班时段批量终端下线 / 上线，ARP、DHCP 报文冲击控制平面
下班电脑关机，早上上班开机；17‑18:30 部分人员关机，大量终端离开网络，产生海量 ARP 广播、DHCP 释放报文上送 CPU，占用控制平面 CPU。硬件转发业务不受影响，访问交换机管理地址（CPU 处理）出现 ping 大延迟、丢包Cisco。
3、CPP（控制平面保护）默认阈值宽松，没有对 ARP/DHCP/STP 报文限速
V7 默认 CPP 限速比较宽松，突发大量协议报文时，无法保护 CPU，管理 ICMP 报文被挤压。
4、次要可能性
1）接入存在间歇性小环路，下班人员插拔网线产生短时环路； 2）接入交换机端口频繁 flapping（up/down 震荡），大量接口事件上报 ifmgr 进程，CPU 抬升。
排查采集命令（故障复现前后执行）
#查看CPU历史，确认故障时间段CPU抬升
display cpu‑usage history
#查看哪些进程CPU高；重点看L2MOD、ARP、IFMGR
display process cpu slot 1
#查看STP拓扑变更TC计数，故障发生时TC计数快速上涨就是典型TC风暴
display stp statistics
#查看控制平面上送CPU各类报文统计，看ARP/DHCP/STP报文计数暴涨
display system internal control‑plane statistics slot 1
#查看是否有端口频繁up‑down日志
display logbuffer | include "GigabitEthernet.*changed status to"
判断关键点：故障时刻
display stp statistics中 TC‑received 计数快速持续增加 → 确认是 TC 拓扑变更风暴，就是边缘端口缺失导致。
完整整改配置方案
1、所有终端接入端口统一配置边缘端口 + BPDU 保护（解决 TC 风暴根源）
所有接 PC、AP、IP 电话的接入端口，必须配置边缘端口；只有互联交换机的 Trunk 不配置边缘端口。
interface range GigabitEthernet 1/0/1 to GigabitEthernet 1/0/48
stp edged‑port enable
#边缘端口开启BPDU保护，防止终端侧私接交换机产生环路
stp bpdu‑protection
quit
#全局开启BPDU保护生效
stp bpdu‑protection global
边缘端口收到 BPDU 会 err‑down 端口，防止私接小交换机环路。
2、CPP 控制平面保护，对 STP、ARP、DHCP 报文做限速保护 CPU（S66 支持）
system‑view
#进入CPP策略视图
control‑plane
#对ARP报文限速，根据现场适度调整
rate‑limit arp 128
rate‑limit dhcp 64
rate‑limit stp 64
作用：突发大量协议报文时，丢弃超额部分，保障 SSH、ping 管理报文优先被 CPU 处理。
3、广播风暴抑制（接入端口），防止接入侧广播泛洪
interface range GigabitEthernet 1/0/1 to GigabitEthernet 1/0/48
broadcast‑suppression ratio 5
quit
4、可选优化：开启 TC 报文抑制（V7），进一步降低 TC 对设备冲击
stp tc‑protection
限制 1 秒内处理 TC 报文最大数量，避免短时间大量 TC 反复刷新 MAC 地址表。
补充说明现象解释
为什么业务正常，ping 交换机管理地址丢包延迟很大？ S66 系列业务数据报文走 ASIC 硬件转发，不消耗 CPU；而 ping 交换机管理 IP 的 ICMP 报文需要上送主控 CPU 处理。当 CPU 被大量 STP‑TC、ARP、DHCP 协议报文占满，管理报文排队、延迟、丢包；但是用户之间业务转发完全不受影响，这是该故障典型特征。
排错验证标准
整改完成，等待下班时段观察：
display stp statisticsTC‑received 不再持续暴涨；display cpu‑usage history下班时段 CPU 不再异常冲高；- ping 交换机管理 IP 延迟稳定，不再出现 2000ms 大延迟。
如果整改后还出现，需要进一步查接入层是否存在端口频繁 up/down，或者终端存在 ARP 扫描行为。
编辑答案
亲~登录后才可以操作哦!
确定你的邮箱还未认证，请认证邮箱或绑定手机后进行当前操作
举报
×
侵犯我的权益
×
侵犯了我企业的权益
×
- 1. 您举报的内容是什么？（请在邮件中列出您举报的内容和链接地址）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
- 3. 是哪家企业？（营业执照，单位登记证明等证件）
- 4. 您与该企业的关系是？（您是企业法人或被授权人，需提供企业委托授权书）
抄袭了我的内容
×
原文链接或出处
诽谤我
×
- 1. 您举报的内容以及侵犯了您什么权益？（请在邮件中列出您举报的内容、链接地址，并给出简短的说明）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
对根叔社区有害的内容
×
不规范转载
×
举报说明