S7003E，设备突然不发流量
- 0关注
- 0收藏，114浏览
最佳答案
H3C S7003E 17:30~18:00 无流量、端口 UP、未重启、双出口静态负载排查
一、先判定核心现象
- 物理端口全 UP、光 / 网线正常；
- 设备无重启，CPU / 单板不死机；
- 双上行默认路由负载分担，时间段固定断流；
- 纯转发中断，管理地址大概率能登录。
二、即刻现场排查命令（优先敲）
1. 先看设备全局资源（晚间峰值共性：CPU / 缓存打满）
display cpu-usage
display cpu-usage history
display memory
display interface summary
display logbuffer reverse
2. 核查双出口路由 & 下一跳有效性
display ip routing-table 0.0.0.0
display ip routing-table protocol static
- 现象 1：默认路由还在，但下一跳 ARP 失效 / 老化
- 检查 ARP：
display arp | include 下一跳网关IP
3. 看上行出接口计数是否停滞
display interface Gig1/0/X
display interface Gig1/0/Y
- Input 有、Output零增长：交换机本地不上行转发；
- 双向计数不动：终端侧也无交互，疑似 VLAN / 二层阻塞。
4. 检查 STP / 环路震荡（傍晚接入增多高发）
display stp brief
display stp history
5. 查看堆叠 / IRF（S7003E 常用）状态
display irf
display link-aggregation summary
6. 是否定时 ACL / 流控 / 时间段策略命中
display time-range
display acl all
display packet-filter all
display qos policy all
三、高概率根因（匹配你现场场景）
- 晚间广播风暴 / ARP 风暴下班终端扫码、IoT 上线、环路触发，CPU 跑满→转发平面挂死，端口不 down、不重启，就是不转发流量。
- 双上行静态路由负载分担，但下一跳 ARP 超时上行网关静默、aging 清理 ARP，路由表还在，实际封装失败无报文发出。
- STP 收敛震荡、边缘端口接入混乱17:30 员工回工位插线，触发 TC 报文全网刷新 MAC，短时黑洞断流。
- QOS / 时间段 ACL 定时策略生效运维配置下班时段限速 / 封禁，精准卡点断流。
- 芯片转发表项耗尽 / 内存泄漏长期运行，晚间流量高峰触发底层转发资源不足，软转发卡死。
四、应急快速恢复操作（马上生效）
- 清 ARP + 刷新转发表
reset arp all
reset mac-address-table dynamic
- 清空日志缓存减负（CPU 高必做）
reset logbuffer
- 上行口临时风暴抑制
interface Gig1/0/X
storm-control broadcast level 30
storm-control multicast level 30
quit
- 单一出口切换测试（剥离负载）临时删除一条默认路由，单出口验证是否恢复，定位是否负载分担 HASH 异常。
五、长效根治预防
- 所有接入口配置边缘端口 + BPDU 保护
interface range Gig1/0/1 to Gig1/0/48
stp edged-port enable
bpdu-protection enable
quit
- ARP 优化：静态绑定核心网关 ARP + 缩短老化 / 防 ARP 攻击
- 核查是否存在
time-range定时策略，无用全部删除 - 查看当前版本 Bug，S7003E 老旧基线易晚间流量高峰转发卡死，升级官方稳定 V7 基线版本
- 双上行建议改用 NQA 检测静态路由，探测下一跳存活，自动联动失效切换
display ip routing-table 0.0.0.0
确认两条默认路由都活跃（Active）。
检查接口状态和计数：
display interface brief
display counters inbound interface
display counters outbound interface
确认接口无错误计数，且出方向计数有增长。
检查ARP表项：
display arp
确认下一跳地址解析正常。
检查策略路由或QoS策略：
display qos policy interface
display policy-based-route
确认无策略丢弃流量。
检查CPU和内存：
display cpu-usage
display memory
确认无异常占用。
如果以上都正常，检查是否有安全策略或ACL：
display acl all
display session statistics
确认无ACL阻断或会话数耗尽。
需要补充信息：设备具体型号（S7003E-X/XG？）、软件版本、故障时是否有告警日志（display logbuffer）。
以上检查都正常，没有配置acl、qos
以上检查都正常，没有配置acl、qos
这种情况极大概率是由风暴控制（storm-constrain）功能触发的端口临时阻塞导致的。
故障原因推测：风暴控制导致的端口“假死”
你的设备症状——“端口线路正常、流量中断、一段时间后自行恢复”，是典型的风暴控制生效的表现。
现象：当端口的广播、组播或未知单播流量在短时间内超过设定的上限阈值时，交换机会执行配置的动作（默认通常是
block，即阻塞端口），暂停转发该类报文，导致业务中断。恢复：当流量回落到低于下限阈值后，端口会自动恢复转发。这完美解释了为什么业务会自己恢复，且你没有进行任何操作。
为何业务中断：虽然风暴控制可能只阻塞了广播报文，但如果你的出口流量路径依赖于ARP等广播协议，广播被阻断会导致路由下一跳无法解析，进而引发整条链路业务中断。
立即执行以下命令进行排查
你可以登录设备，按照以下顺序执行命令来确认问题根源：
1. 查看端口是否因风暴控制被阻塞过
这是验证猜测最关键的一步。执行命令，查看在故障时间点，端口是否有因流量超标而被阻塞的记录：
GigabitEthernet 2/0/23和2/0/24这两个端口，如果Block状态被触发过，且Broadcast或Multicast计数很高，就可以确认是风暴控制的问题。2. 查看系统日志中的关键线索
风暴控制生效时，系统会记录日志。执行命令过滤故障时间段的日志：
3. 查看端口的历史统计和错误包
如果上述证据不明显，可以检查物理层是否有隐患。但根据你“端口线路正常”的描述，这步是作为补充排查。
清空并观察：先执行
reset counters interface清空历史统计，等待一段时间后再次执行display interface。检查错误：重点关注
input errors、CRC、overruns等计数是否在增长。如果有增长，说明链路确实存在不稳定因素；如果没有，则再次印证问题可能出在软件策略上。
解决方案与预防措施
确认是风暴控制导致的问题后，可以按以下优先级处理：
临时措施（最快恢复业务）：在端口下直接关闭风暴控制功能，业务会立即恢复。
undo storm-constraininterface GigabitEthernet 2/0/23长期优化（推荐）：根据实际网络环境调整风暴控制的阈值。如果网络中确实有正常的广播流量，可以适当提高上限阈值，或修改动作为
control（只阻塞超标报文，不阻塞其他报文），避免因短暂的流量尖峰导致整条链路失效。
广播包也就几个，在正常范围内。你提供这个查询命令display storm-constrain，我无法使用
广播包也就几个，在正常范围内。你提供这个查询命令display storm-constrain，我无法使用
编辑答案
亲~登录后才可以操作哦!
确定你的邮箱还未认证，请认证邮箱或绑定手机后进行当前操作
举报
×
侵犯我的权益
×
侵犯了我企业的权益
×
- 1. 您举报的内容是什么？（请在邮件中列出您举报的内容和链接地址）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
- 3. 是哪家企业？（营业执照，单位登记证明等证件）
- 4. 您与该企业的关系是？（您是企业法人或被授权人，需提供企业委托授权书）
抄袭了我的内容
×
原文链接或出处
诽谤我
×
- 1. 您举报的内容以及侵犯了您什么权益？（请在邮件中列出您举报的内容、链接地址，并给出简短的说明）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
对根叔社区有害的内容
×
不规范转载
×
举报说明