现象：全部终端同时断网，间隔 1‑3 小时复现，十几分钟自行恢复；日志打印
GigabitEthernet1/0/21 changed to up，不是单端口故障，是整网业务中断后恢复。
⚠️重点：不是所有端口物理 down，终端显示断网，过十多分钟业务自动恢复。优先排查广播风暴 / 二层环路、设备 CPU 满载、硬件（电源 / 散热）、软件版本 bug、上联链路震荡五大方向。
第一步：故障发生时优先收集信息（Console 登录最佳，断网时 SSH 大概率登不上）
display logbuffer # 查看系统日志，重点看断网前后日志
display cpu‑usage # 查看CPU使用率，是否冲到90‑100%
display memory # 内存占用
display device # 硬件状态，电源、风扇是否异常
display environment # 温度告警，是否高温
display stp brief # STP状态，是否TC报文频繁震荡
display mac‑address | count # MAC表数量是否异常暴涨
导出日志：
logbuffer完整日志务必保存，是定位关键。日志里出现大量 TC、MAC 漂移，基本判定环路风暴。
故障原因分级排查
1、二层环路 / 广播风暴（最高概率）
现象特征：CPU 跑满，网络卡死，风暴报文被设备慢慢抑制，十几分钟后风暴衰减，网络自动恢复；过 1‑3 小时流量累积再次触发风暴，循环往复。
- 查看日志有没有
MAC address flapping（MAC 漂移）、大量 STP TC 报文。 - 检查：接入是否私接小路由器、傻瓜交换机；是否存在双线互联形成环路。
临时处置
stp mode rstp
stp global enable
loopback‑detection global enable
接入层终端端口配置边缘端口：
interface range GigabitEthernet 1/0/1 to GigabitEthernet 1/0/24
stp edged‑port enable
2、硬件问题：电源、散热高温保护
1）风扇故障、进风口堵塞，设备温度过高，转发异常降速，温度回落之后业务恢复，周期性复现。执行display environment看温度数值、温度告警。
2）单电源供电，电压波动，设备间歇性工作异常；WS5800‑24P 支持双电源，条件允许接上双电源测试。
特征：环境温度高时故障发作更频繁；机房空调停机后故障概率变大。
3、上联链路震荡引发全网震荡
日志出现GigabitEthernet1/0/21 changed to up，1/0/21 极有可能是上行 Trunk 口。
- 上联口频繁 up/down，会触发全网 STP TC，整网 MAC 地址表全部刷新，全网短暂断网；端口稳定后网络慢慢恢复。
- 排查上联口：网线、光模块、对端设备，
display interface GigabitEthernet 1/0/21看 CRC 错误、错包是否持续增长。
4、软件版本缺陷
WS5800‑24P 属于老款 Comware5 平台，早期版本存在 CPU 调度、表项溢出类 bug，长时间运行会业务卡死，内部自动恢复。
执行display version确认版本，建议升级到官方推荐的稳定版本。
5、资源耗尽（ARP/MAC 表项满）
内网存在 ARP 攻击，大量虚假表项占满设备表项，转发失效，设备定时清理表项后网络恢复。
display arp statistics看 ARP 表使用率。
现场应急定位小技巧
- 故障复现时，Console 口直连交换机，不要通过网络 SSH，网络故障时 SSH 会无法登录拿不到信息。
- 故障发生如果 CPU100%，基本锁定环路 / 广播风暴。
- 如果 CPU 正常，重点看温度、电源、上联口错包计数。
一、 优先排查（最常见原因）
1. 检查环路与STP：
这是最典型的“网络拥塞-崩溃-恢复”现象。
命令：
display stp brief 检查是否有端口被阻塞，确认根桥位置是否稳定。
display logbuffer 翻看日志，除了接口UP/Down，是否有大量的 STP TC (拓扑变化) 报文，或者CRC错误增长。
排查： 虽然你只看到了一个UP日志，但询问现场是否有人动过网线，或检查网络中是否有下联交换机成环。
2. 检查设备温度/CPU/内存：
命令：
display environment 查看温度是否过高告警。
display cpu-usage 查看CPU利用率。断网时通常利用率很高。
display memory 查看内存占用。
二、 深入排查
3. 检查ARP与网关：
现象： 断网时终端Ping不通网关。
原因： 可能存在ARP扫描或ARP欺骗导致ARP表资源耗尽。
命令： display arp count 检查ARP表项数量。
4. 检查是否有广播风暴：
命令： display interface 查看接口下的 Input bandwidth utilization 和 Output bandwidth utilization，以及 broadcast/pkts 计数是否在短时间内激增。
三、 临时处理建议
如果条件允许，断网时通过Console口登陆（如果网络管理IP都Ping不通），立即收集 display diagnostic-information 信息，并联系400或上传日志到知了社区分析。
建议配置：
如果尚未配置，建议开启 stp global enable，并在接口下配置 broadcast-suppression 1 (广播流量抑制到1%)。
暂无评论
你描述的“正常运行1-3小时 → 断网10多分钟 → 自动恢复”的循环，结合GigabitEthernet1/0/21接口状态变为up的日志，强烈指向二层网络环路或生成树协议（STP）异常导致的广播风暴。
核心排查方向
1. 二层环路与广播风暴（最高概率）
环路会导致广播报文在交换机内无限循环，迅速耗尽CPU和带宽资源，造成全网瘫痪。交换机的环路检测机制在超时后可能会暂时阻断环路端口，使网络在10多分钟后“自动恢复”，但根源未除，循环会再次发生。
检查STP状态：执行
display stp brief，确认GigabitEthernet1/0/21等端口的STP状态。如果该端口本应处于DISCARDING（阻塞）状态却显示FORWARDING，则说明STP未能正确破环。检查MAC地址漂移：执行
display mac-address mac-move，查看是否存在大量MAC地址在两个端口间反复迁移的记录。这是环路非常典型的特征。查看CPU与广播统计：执行
display cpu-usage，并在故障时观察CPU是否飙升。同时可用display interface GigabitEthernet1/0/21查看接口的广播报文计数是否异常。
2. STP协议兼容性问题
如果网络中存在其他品牌的交换机（如Cisco、华为），且STP模式不一致，可能导致BPDU报文格式错误，引发STP震荡和拓扑频繁变化，造成周期性断网。
检查STP模式：执行
display stp，查看当前的STP模式（MSTP/PVST/RSTP）。配置BPDU兼容：如果存在多厂商环境，可在相关Trunk接口下配置
stp compliance dot1s，使H3C交换机只收发标准格式的MSTP报文。
解决方案与加固配置
在定位并排除物理环路（如拔掉可疑线缆）后，建议在WS5800-24P上进行以下配置加固，防止类似问题再次发生。
1. 启用环路检测与自动保护
在接入端口上开启环路检测，并配置动作为shutdown，使交换机在检测到环路时能主动关闭端口，而不是被动等待超时。
2. 配置BPDU保护
为防止用户私自接入交换机或错误连接形成环路，建议在所有连接终端的边缘端口上配置BPDU保护。这样当边缘端口收到BPDU报文时，交换机会自动将其关闭，从而阻断环路。
3. 配置风暴抑制
在接口上配置广播风暴抑制，可作为最后一道防线，限制广播流量对CPU和带宽的冲击。
暂无评论
期性全网断 10 多分钟 → 自动恢复，1~3 小时再次复现；日志看到 G1/0/21 物理 UP。端口物理没 down，是转发 / 协议层面断业务，不是单纯网线闪断。
最可能排序：二层环路 + STP 震荡 > 风暴控制触发阻断 > CPU 过载 > 双机 VRRP/IRF 震荡
快速排查命令（H3C）
display logbuffer重点搜：STP、BPDU、storm、VRRP、MAC 迁移display cpu-usage故障瞬间看 CPU 是否冲到 90%+display stp brief看端口角色是否频繁变化display mac-address看同一个 MAC 在多个端口来回跳（MAC 漂移 = 环路）display interface GigabitEthernet 1/0/21看 CRC 错包、广播包持续暴涨
根因分析 & 处理
- 二层环路（最高概率）
私接小路由 / 傻瓜交换机，广播风暴逐步累积，CPU 被打满、转发卡死；风暴抑制 / STP 保护阻断流量，等待老化后网络自动恢复，循环往复。
✅ 处理：接入端口配置
stp edged-port、开启环路检测；分段拔接入上行线定位故障接入交换机。 - 风暴控制阈值过低
广播流量累积到阈值，端口阻塞，超时自动恢复。
✅ 处理：检查
storm-constrain broadcast，临时调大或关闭测试。 - VRRP/IRF 虚拟化震荡 核心双机场景，hello 报文丢包，主备反复切换，业务中断，等待协议重新协商恢复。 ✅ 处理：检查 peer 链路、VLAN 放行、BFD。
- 设备硬件 / 散热、电源不稳 温度高、电源降载，转发芯片假死，不触发端口 down 日志，业务断流，等待硬件复位恢复。 ✅ 处理：看风扇、温度、电源状态。
暂无评论
编辑答案
亲~登录后才可以操作哦!
确定你的邮箱还未认证，请认证邮箱或绑定手机后进行当前操作
举报
×
侵犯我的权益
×
侵犯了我企业的权益
×
- 1. 您举报的内容是什么？（请在邮件中列出您举报的内容和链接地址）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
- 3. 是哪家企业？（营业执照，单位登记证明等证件）
- 4. 您与该企业的关系是？（您是企业法人或被授权人，需提供企业委托授权书）
抄袭了我的内容
×
原文链接或出处
诽谤我
×
- 1. 您举报的内容以及侵犯了您什么权益？（请在邮件中列出您举报的内容、链接地址，并给出简短的说明）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
对根叔社区有害的内容
×
不规范转载
×
举报说明
暂无评论