zhiliao_Gixe
三段
排查步骤：
1. 确认STP状态：在汇聚和接入交换机上执行 `display stp brief`，检查异常流量的接口是否为指定端口（DESI）或根端口（ROOT），并确认根桥位置正确。
2. 检查TC报文来源：在汇聚交换机上执行 `display stp tc` 或抓包确认TC报文的源MAC地址，定位频繁触发拓扑变化的设备。
3. 检查无线侧配置：
* 在接入交换机连接AP的接口执行 `display interface brief`，查看接口是否有频繁Up/Down记录。
* 确认AP及其连接的用户VLAN配置正确，无环路。
* 检查AP模式（如FIT AP）及隧道转发配置是否正常。
4. 检查ARP表项：在汇聚和核心交换机上对无线用户VLAN执行 `display arp | include <VLAN接口IP>`，观察ARP表项是否频繁刷新或不稳定。
5. 流量分析：在汇聚交换机异常接口下使用 `qos car` 进行流量限速并镜像，或使用 `display qos queue statistics interface` 查看队列情况，分析具体流量类型。
可能原因及处理：
无线侧链路震荡或AP异常：导致STP频繁计算，产生大量TC报文，引发MAC地址表项刷新和广播风暴（表现为单播流量激增）。需稳定无线侧链路。
存在环路：无线用户侧可能存在物理或逻辑环路（如错误接线、终端开启网桥功能），触发TC。需排查终端和AP配置。
配置问题：接入交换机连接AP的端口未正确配置为 `stp edged-port` 或未启用BPDU保护。
补充信息需求：
1. 网络拓扑结构（尤其是无线部分）。
2. 接入交换机连接AP的端口STP及端口安全配置。
3. 无线控制器（如有）的相关告警日志。
操作前请备份配置。
1. 确认STP状态：在汇聚和接入交换机上执行 `display stp brief`，检查异常流量的接口是否为指定端口（DESI）或根端口（ROOT），并确认根桥位置正确。
2. 检查TC报文来源：在汇聚交换机上执行 `display stp tc` 或抓包确认TC报文的源MAC地址，定位频繁触发拓扑变化的设备。
3. 检查无线侧配置：
* 在接入交换机连接AP的接口执行 `display interface brief`，查看接口是否有频繁Up/Down记录。
* 确认AP及其连接的用户VLAN配置正确，无环路。
* 检查AP模式（如FIT AP）及隧道转发配置是否正常。
4. 检查ARP表项：在汇聚和核心交换机上对无线用户VLAN执行 `display arp | include <VLAN接口IP>`，观察ARP表项是否频繁刷新或不稳定。
5. 流量分析：在汇聚交换机异常接口下使用 `qos car` 进行流量限速并镜像，或使用 `display qos queue statistics interface` 查看队列情况，分析具体流量类型。
可能原因及处理：
无线侧链路震荡或AP异常：导致STP频繁计算，产生大量TC报文，引发MAC地址表项刷新和广播风暴（表现为单播流量激增）。需稳定无线侧链路。
存在环路：无线用户侧可能存在物理或逻辑环路（如错误接线、终端开启网桥功能），触发TC。需排查终端和AP配置。
配置问题：接入交换机连接AP的端口未正确配置为 `stp edged-port` 或未启用BPDU保护。
补充信息需求：
1. 网络拓扑结构（尤其是无线部分）。
2. 接入交换机连接AP的端口STP及端口安全配置。
3. 无线控制器（如有）的相关告警日志。
操作前请备份配置。
这是一起典型的由STP TC（拓扑变更）报文泛洪引发的未知单播流量风暴问题。
问题根因分析
1. TC报文导致MAC地址表频繁刷新
STP协议中，当网络拓扑发生变化时（如端口Up/Down），设备会发送TC（Topology Change）报文通知全网。收到TC报文的交换机会将MAC地址表的老化时间从默认的300秒缩短到15秒。
后果：
MAC地址表被频繁清空或快速老化
交换机无法有效学习终端MAC地址与端口的对应关系
2. 未知单播泛洪
当交换机不知道目的MAC对应的出端口时（MAC表老化或被清空），会将发往该MAC的报文向所有端口广播（未知单播泛洪）。
你的情况：
无线业务流量从AC/核心发往AP时，汇聚交换机因MAC表被频繁刷新，不知道AP的MAC在哪个端口
于是将这些单播报文向所有端口泛洪
这就解释了为什么你看到的是单播报文占比高，而不是广播/组播
3. 流量占比持续增长的原因
随着TC报文持续产生，MAC地址表反复老化，未知单播泛洪的范围和持续时间都在扩大，导致端口流量占比不断攀升，从25%逐渐上升到80%以上。
排查步骤
第一步：定位TC报文的源头
在汇聚交换机上执行：
display stp tc
查看哪个端口收到的TC报文数量在持续增长。
第二步：定位TC产生的原因
找到源头接口后，检查该接口为什么频繁产生TC：
| 可能原因 | 排查方法 |
|---|---|
| 终端设备频繁上下线 | 接口连接的是用户PC、打印机、摄像头等终端 |
| 物理链路不稳定 | 检查端口CRC错误计数、光模块光功率 |
| 交换机/AP重启 | 查看设备运行时间，确认是否有定时重启机制 |
| 环路导致端口震荡 | 检查是否有冗余链路未正确阻塞 |
关键命令：
display interface GigabitEthernet x/x/x # 查看端口错误计数
解决方案
方案一：配置边缘端口（最有效、最常用）
将所有连接终端的端口（包括连接AP的端口）配置为边缘端口。这样这些端口的Up/Down不会触发STP TC报文。
配置示例：
interface GigabitEthernet x/x/x
方案二：开启TC保护
在根桥或关键交换机上开启TC保护，限制单位时间内处理TC报文的次数，超过阈值后不再处理。
stp tc-protection enable
方案三：调整根桥位置
确认根桥是否是核心交换机。如果根桥在接入层，网络稳定性会受终端设备影响。
将核心交换机配置为根桥：
stp root primary
方案四：排查并修复物理层问题
如果源头端口存在CRC错误或光衰问题，需要：
更换网线/光纤
检查光模块收发光功率
清洁光纤接口
方案五：检查是否存在软件版本Bug
参考网络案例，某些交换机软件版本存在TC报文放大Bug——收到1个TCN会发送18个TC报文。
建议：联系设备厂商确认当前版本是否存在此类问题，必要时升级固件。
暂无评论
故障根因定位 + 排查思路（贴合你现场：无线汇聚下行涨流量、高单播、大量 STP TC 报文）
一、核心结论
整网频繁 STP TC 拓扑变更 → MAC 地址表极速漂移刷新 → 交换机大量泛洪未知单播 → 接入 & 汇聚下行带宽被无效单播占满（25%→80% 暴涨）有线稳定、无线侧出问题：无线 VLAN 域内频繁环路 / 端口频繁 UP/DOWN（AP 掉线、终端频繁上下线、网线环路） 触发持续 TC 报文风暴。
二、现象对应原理
- STP TC 报文作用设备收到 TC = 清空 MAC 地址表、重新学习；MAC 表不稳定后，大量单播帧查不到出接口 → 向所有端口泛洪。
- 你现场特征匹配：
- 汇聚抓大量 TC → STP 拓扑秒级震荡
- 下行端口流量持续走高、主流是异常泛洪单播
- 有线业务隔离 / 链路稳定无震荡，仅无线接入链路上爆流量
- AC+AP 瘦架构、终端密集、漫游频繁极易放大此问题
三、快速定位故障点（逐行排查）
1. 先确认全局 STP 震荡证据（核心 / 汇聚）
bash
运行
# 查看TC计数是否疯狂增长
display stp tc-bpdu statistics
# 查看哪些端口在触发TC
display stp brief
display logbuffer | include TC
只要TC 计数持续秒涨，100% 是拓扑抖动源头。
2. 高频诱因（无线场景 TOP 问题）
1）接入层网线自环 / 下级傻瓜交换机环路（AP 接桌面小交换机、弱电串线）2）无线 POE 端口频繁 Up/Down：AP 供电不稳、网线水晶头劣质、PoE 功率不足3）终端大量快速漫游、断电重连+ 边缘端口未固化 STP4）VLAN50 无线业务 VLAN 透传乱、边缘端口没开 Edge 端口 (STP)
四、紧急止血配置（立刻降流量、停 TC 风暴，H3C V7/V9 通用）
1. 所有无线接入下联 AP / 终端端口 → 配置边缘端口 + 防抖动
plaintext
interface GigabitEthernet 1/0/1 to 1/0/24
stp edged-port enable
stp bpdu-protection
port-security # 可选防非法接入震荡
quit
边缘端口 = 不参与 STP 计算，终端 / AP 上下线不再触发 TC 报文。
2. 抑制 STP TC 全局震荡（核心 / 汇聚）
plaintext
stp tc-protection
# 限制单位时间TC处理次数，防全网MAC表乱刷新
stp tc-protection threshold 10
3. 无线 VLAN 优化 + 端口抑制泛洪（关键降单播流量）
plaintext
interface 汇聚下行互联口
unicast-suppression 50 # 抑制未知单播风暴，阈值按需调
broadcast-suppression
quit
4. 检查是否私接二层傻瓜交换机（大忌）
无线点位私接非管理交换机，极易物理环路，逐台下线点位定位环路端口。
五、复盘核查命令（确认恢复正常）
plaintext
display interface brief # 看下行带宽回落正常
display stp tc-bpdu statistics # TC不再新增
display mac-address table dynamic # MAC表稳定无极速刷新
六、补充优化建议（无线经典组网根治）
- AC + 瘦 AP 场景：所有接 AP 接入口强制 edge 边缘端口，标准工程必配；
- 无线、核心有线做分层优化，必要时无线独立汇聚，不与高密有线混压同一核心转发；
- 老旧网线 / 弱电一体化线路重做水晶头，解决 PoE AP 反复断电 up-down；
暂无评论
编辑答案
➤
✖
亲~登录后才可以操作哦!
确定
✖
✖
你的邮箱还未认证，请认证邮箱或绑定手机后进行当前操作
✖
举报
×
侵犯我的权益
>
对根叔社区有害的内容
>
辱骂、歧视、挑衅等（不友善）
侵犯我的权益
×
侵犯了我企业的权益
>
抄袭了我的内容
>
诽谤我
>
辱骂、歧视、挑衅等（不友善）
骚扰我
侵犯了我企业的权益
×
您好，当您发现根叔知了上有关于您企业的造谣与诽谤、商业侵权等内容时，您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到 pub.zhiliao@h3c.com 邮箱，我们会在审核后尽快给您答复。
- 1. 您举报的内容是什么？（请在邮件中列出您举报的内容和链接地址）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
- 3. 是哪家企业？（营业执照，单位登记证明等证件）
- 4. 您与该企业的关系是？（您是企业法人或被授权人，需提供企业委托授权书）
我们认为知名企业应该坦然接受公众讨论，对于答案中不准确的部分，我们欢迎您以正式或非正式身份在根叔知了上进行澄清。
抄袭了我的内容
×
原文链接或出处
诽谤我
×
您好，当您发现根叔知了上有诽谤您的内容时，您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到pub.zhiliao@h3c.com 邮箱，我们会尽快处理。
- 1. 您举报的内容以及侵犯了您什么权益？（请在邮件中列出您举报的内容、链接地址，并给出简短的说明）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
我们认为知名企业应该坦然接受公众讨论，对于答案中不准确的部分，我们欢迎您以正式或非正式身份在根叔知了上进行澄清。
对根叔社区有害的内容
×
垃圾广告信息
色情、暴力、血腥等违反法律法规的内容
政治敏感
不规范转载
>
辱骂、歧视、挑衅等（不友善）
骚扰我
诱导投票
不规范转载
×
举报说明
暂无评论