问

核心交换机H3C S7503E-M 日志信息

Flow日志

1天前提问

0关注
0收藏，36浏览

zhiliao_49159

zhiliao_49159 零段

粉丝：0人关注：0人

问题描述：

各位大神，帮分析一下，核心交换机H3C S7503E-M 日志信息，端口速率异常跳动？

组网及组网描述：

两台设备做了堆叠，Ten-GigabitEthernet2/1/0/28口是堆叠口之一，GigabitEthernet1/0/01口下接接入交换机。

4 个回答

按时间按赞数

zhiliao_Gixe

zhiliao_Gixe 三段

粉丝：2人关注：9人

检查堆叠口和业务口状态。

1. 查看堆叠口状态：`display irf link`
2. 检查端口光模块和光纤：`display transceiver diagnosis interface Ten-GigabitEthernet 2/1/0/28`
3. 检查端口错误计数：`display interface Ten-GigabitEthernet 2/1/0/28`，关注`Input/Output errors`、`CRC`、`giants`等。
4. 检查业务口状态及错误：`display interface GigabitEthernet 1/0/1`
5. 检查CPU利用率：`display cpu-usage`

速率异常通常由物理链路问题（如光模块、光纤、端口硬件）或网络环路引起。请先提供上述命令的输出。

[Core]dis irf link Member 1 IRF Port Interface Status 1 disable -- 2 Ten-GigabitEthernet1/0/0/28(MDC1) UP Ten-GigabitEthernet1/1/0/28(MDC1) UP Member 2 IRF Port Interface Status 1 Ten-GigabitEthernet2/0/0/28(MDC1) UP Ten-GigabitEthernet2/1/0/28(MDC1) UP 2 disable --

zhiliao_49159 发表时间：1天前 更多>>

zhiliao_49159 发表时间：1天前

zhiliao_sEUyB

zhiliao_sEUyB 九段

粉丝：98人关注：11人

广播包数量阈值告警，业务有没有影响。

业务有影响的话接口下限制一下广播包数量就可以。

或者抓包分析下

刘浩存

刘浩存七段

粉丝：8人关注：1人

你的日志（14:12:50 / 14:13:01 / 14:23:51 / 14:24:01 / 14:26:02 / 14:26:12）展示了一个非常重要的规律：每隔大约10秒，广播流量就会有一次骤升和骤降。这正是排查的关键突破口。

这个时间间隔指向了一个特定的配置——storm-constrain或RMON告警的统计周期。在华三交换机上，默认的流量统计间隔正是10秒。

简单来说，事情可能是这样发生的：

设备连续统计：设备持续统计端口收到的广播包数量。
突破上限，触发告警：在某一个10秒周期结束统计时，发现广播包数超过了预设的2万pps，于是记录“exceeds the threshold”告警。
自动抑制生效：同时，设备上配置的“风暴抑制”功能被触发，开始主动丢弃超出的广播包。
流量回落，再次告警：在下一个10秒统计周期，因为抑制生效，广播流量骤降至200多pps，触发了“drops below the lower threshold”告警。
形成循环：设备恢复平静，之后再次触发广播高峰，于是整个过程循环往复。

所以，你看到的“端口速率异常跳动”，很可能是风暴抑制功能正在生效，防止网络被广播风暴彻底击垮。

优先排查：接入交换机环路与STP震荡

在两个端口中，GigabitEthernet1/0/1（连接接入交换机）的问题通常是根源，堆叠口的异常往往是它的“并发症”。

物理环路：接入交换机自身的某个端口可能因为线缆接错（如两根线接回了核心）、私接小交换机/家用路由器形成了环路，导致广播帧在环里疯狂转圈，数量指数级增长。
生成树（STP）问题：
- 频繁TCN：接入交换机下联的终端频繁上下线，产生了大量TCN（拓扑变更通知）报文，迫使全网交换机频繁刷新MAC地址表，将大量已知单播流量变为未知单播流量泛洪。
- 根桥漂移：错误的STP配置（如优先级未设或过低）可能导致网络中根桥角色在两个交换机间频繁切换，引发全网拓扑震荡，消耗大量CPU并导致广播流量激增。
设备行为异常：接入交换机下连的设备（如摄像头、打印机）可能存在异常，发送大量ARP请求或进行网络扫描，造成广播泛滥。
安全攻击：局域网内有中毒主机发起ARP攻击或广播DoS攻击，对外发送大量广播包

如果核心CPU持续高企，需要马上恢复业务。

紧急限速：在核心的两个问题接口下，立即配置临时风暴抑制：
system-view
interface GigabitEthernet1/0/1 broadcast-suppression pps 10000 # 将阈值临时从2万pps降至1万pps，这是最高优先级操作，能立刻缓解对核心CPU的压力。
物理断开排查：如果限速后核心CPU没有明显下降，需要直接物理断开GigabitEthernet1/0/1这根光纤或网线，观察广播流量告警是否彻底消失。
保存配置：务必执行save命令保存配置。

在业务稳定后，再进行深度排查。

核心交换机现场诊断
- 查看详细流量与STP状态：
  display interface GigabitEthernet1/0/1 # 查看该接口详细的input/output流量、错误包统计
  display stp brief # 确认根桥是否在预期位置，端口角色状态是否稳定 display stp interface GigabitEthernet1/0/1 # 查看端口STP详细信息，检查是否有TCN计数
- 风暴控制状态检查：确认抑制是否生效：
  display storm-constrain # 查看所有端口的阈值控制状态
  display current-configuration interface GigabitEthernet1/0/1 # 确认该口当前配置
接入交换机现场诊断（核心问题源头）
- 登录排查：登录GigabitEthernet1/0/1下联的接入交换机，重复上述命令，从接入层开始排查环路。
- 用户端口检查：检查下联终端的端口，推荐配置：
  interface GigabitEthernet 1/0/2 # 假设用户端口
  stp edged-port enable # 设为边缘端口，防止TCN报文上传 broadcast-suppression 5 # 配置百分比抑制，比例不宜过高 loopback-detection enable # 开启环路检测，自动关闭有环路的口，边缘端口可防止终端波动影响全网。
- MAC漂移排查：
  display mac-address mac-move # 查看MAC地址表是否存在频繁漂移（环路典型标志）
分析与解决
根据现场诊断结果，对照下表快速定位问题：

发现的现象	可能原因	解决方法
核心接口日志里广播流量规律性起伏	风暴抑制功能生效，触发了保护机制	这是正常现象，是设备在自我保护，继续排查广播风暴的根源即可。
接入交换机下联口环路检测日志、MAC地址漂移	存在二层物理环路	立即拔掉疑似形成环路的网线，然后根据日志找到环路端口，拆除环路。
STP根桥频繁漂移，端口角色状态不正常	STP配置不当	在核心交换机上调低优先级（`stp priority 0`），确保它永远是根桥。
广播风暴只在特定时段（如上班时间）发生	环路由用户行为引发（如私接小交换机）	向用户普及规范，并加强接入层端口的安全控制。
单一端口下挂设备（如摄像头）发送大量ARP	设备行为异常或网络规模过大	优化网络设计（如细化VLAN）或联系设备厂商处理。