第103篇：TC 保护与拓扑变更优化
关键词：TC 保护、Topology Change、TCN BPDU、MAC 表刷新、生成树优化、拓扑变更
一、引言
生成树协议的三种保护机制（BPDU 保护、根保护、环路保护）为网络构建了稳固的防御体系。但在网络运行过程中，拓扑变更（Topology Change, TC）事件的发生同样会带来影响。每次拓扑变更，交换机都会刷新 MAC 地址表和 ARP 表，短期内导致大量单播流量被当作未知单播泛洪，影响网络性能。当拓扑变更频繁发生时，这种影响会被放大。TC 保护机制正是为此而生。
二、核心概念
2.1 拓扑变更（TC）事件
当网络拓扑发生变化时，STP/RSTP 会触发拓扑变更事件。触发条件包括：
| 触发事件 | 说明 |
|---|---|
| 端口进入 Forwarding 状态 | 原阻塞端口变为转发 |
| 端口离开 Forwarding 状态 | 原转发端口变为阻塞/关闭 |
| 根桥变更 | 根桥选举发生变化 |
| 路径开销变更 | 到根桥的最佳路径发生变化 |
2.2 TC 传播机制
在 STP 中，TCN BPDU 沿根端口向根桥传播，根桥确认后将 TC 标志位设置在所有发出的 Configuration BPDU 中，通知全网。
在 RSTP/MSTP 中，TC 标志位直接包含在 BPDU 中，由检测到变化的交换机直接向下游扩散。
2.3 频繁拓扑变更的危害
当网络中存在不稳定链路（如质量较差的光纤、接触不良的模块）时，端口频繁 Up/Down，导致 TC 事件频发：
- MAC 地址表频繁刷新：所有交换机的 MAC 地址表老化时间被缩短为 Forward Delay（默认 15 秒），大量 MAC 地址被删除
- ARP 表项刷新：部分设备会同时刷新 ARP 缓存
- 未知单播泛洪：MAC 表项丢失后，单播帧被当作未知单播泛洪，占用大量带宽
- CPU 利用率飙升：处理大量泛洪帧和表项更新，交换机 CPU 占用率急剧上升
三、技术细节
3.1 TC 保护原理
TC 保护的核心思路是限制单位时间内处理的 TC BPDU 数量：
- 交换机记录收到 TC BPDU 的时间间隔
- 如果在设定的时间窗口内收到的 TC BPDU 超过阈值，则丢弃后续 TC BPDU
- 同时记录并上报告警
华为设备的默认配置：
| 参数 | 默认值 | 说明 |
|---|---|---|
| TC 保护时间窗口 | 10 秒 | 统计 TC 的时间窗口 |
| TC 保护阈值 | 次/窗口 | 默认每个窗口内只处理有限次 TC |
| 保护开启状态 | 默认关闭 | 需要手动 stp tc-protection enable |
3.2 RSTP/MSTP 中的 TC 传播优化
RSTP 改进了 TC 传播方式：
- STP：TCN 必须经根桥中转后才能扩散到全网，传播路径长
- RSTP：检测到变化的交换机直接在所有指定端口上发送带 TC 标志的 BPDU，快速向下游传播
3.3 TC 保护与 TCN 保护的差异
| 特性 | TC 保护 | TCN 保护 |
|---|---|---|
| 防护对象 | TC BPDU | TCN BPDU |
| 适用协议 | RSTP/MSTP | STP |
| 处理方式 | 限制 TC BPDU 处理速率 | 限制 TCN BPDU 响应速率 |
| 华为命令 | stp tc-protection enable |
STP 模式下自动关联 |
四、实战配置/案例分析
4.1 华为交换机 TC 保护配置
# 全局启用 TC 保护
[HUAWEI] stp tc-protection enable
# 配置 TC 保护参数（可选，使用默认值通常足够）
[HUAWEI] stp tc-protection max-number 3 # 每个窗口最大处理3次TC
[HUAWEI] stp tc-protection restart-interval 10 # 窗口周期10秒
# 查看 TC 保护状态
[HUAWEI] display stp tc-protection
4.2 拓扑频繁变更故障案例
场景描述：某数据中心核心交换机与汇聚交换机之间使用光纤互联，其中一条光纤因弯曲半径过小导致光衰过大，链路出现间歇性闪断。运维团队发现核心交换机 CPU 利用率持续在 70% 以上，且网络频繁出现短暂丢包。
排查过程：
- 查看 CPU 利用率：
[HUAWEI-Core] display cpu-usage
# CPU 利用率 72%，异常偏高
- 查看 STP 日志：
[HUAWEI-Core] display logbuffer | include STP
# 大量 Topology Change 日志
# %%%01STP/4/TOPONOTIFICATION(l)[0]:The topology change event has been received.
# %%%01STP/4/TOPONOTIFICATION(l)[1]:The topology change event has been received.
# ...（短时间内出现数十条）
- 查看接口状态：
[HUAWEI-Core] display interface brief
# 发现 XGigabitEthernet 0/0/1 端口状态频繁 Up/Down
- 查看光功率：
[HUAWEI-Core] display transceiver interface XGigabitEthernet 0/0/1
# 接收光功率 -28dBm，远超正常范围（正常应大于 -14dBm）
根因分析：
光纤弯曲导致接收光功率过低，链路质量极差，端口频繁 Up/Down。每次端口状态变化都触发 TC 事件，短时间内产生大量 TC BPDU，全网交换机频繁刷新 MAC 地址表，导致核心交换机 CPU 利用率飙升。
处理措施：
# 第一步：立即启用 TC 保护，限制 TC 处理速率
[HUAWEI-Core] stp tc-protection enable
# 第二步：排查并修复光纤问题
# （更换光纤，重新布线，确保弯曲半径大于 30mm）
# 第三步：验证光功率恢复正常
[HUAWEI-Core] display transceiver interface XGigabitEthernet 0/0/1
# 接收光功率 -8dBm，恢复正常
# 第四步：验证 STP 稳定
[HUAWEI-Core] display stp brief
# 所有端口状态稳定，无频繁拓扑变更
长期优化建议：
- 在所有交换机上启用 TC 保护作为基线配置
- 部署光功率监控告警，及时发现光衰问题
- 对于关键链路，配置 BFD for STP 实现快速故障检测
4.3 TC 保护配置验证
# 查看 TC 保护统计信息
[HUAWEI] display stp tc-protection
# 模拟频繁 TC（在测试环境中）
# 在接入层反复 shutdown/undo shutdown 一个端口
# 观察 TC 保护计数器是否增长
[HUAWEI] display stp statistics
# 查看 TC 报文的发送和接收统计
五、总结
| 项目 | 说明 |
|---|---|
| TC 事件触发 | 端口状态在 Forwarding/Discarding 之间切换 |
| TC 的危害 | MAC 表/ARP 表频繁刷新、未知单播泛洪、CPU 飙升 |
| TC 保护原理 | 限制单位时间内处理的 TC BPDU 数量 |
| 华为默认策略 | TC 保护默认关闭，需手动启用 |
| 典型故障根因 | 劣质光纤、光衰过大、接触不良导致端口闪断 |
| 排查命令 | display cpu-usage、display logbuffer \| include STP、display transceiver |
| 最佳实践 | TC 保护 + 根保护 + 环路保护 + BPDU 保护，四重防护 |
思考
-
TC 保护限制了 TC BPDU 的处理频率，但这是否意味着部分拓扑变更无法及时通知全网？TC 保护的副作用是什么？如何在安全与及时之间取得平衡？
-
在 RSTP 模式下，TC 传播是直接向下游扩散的。如果一个非根桥交换机启用了 TC 保护，它是否会阻止 TC 向下游传播？还是仅限制自身处理 TC 的行为？
-
除了修复物理链路问题，还有哪些方法可以减少拓扑变更事件的发生？（提示：从生成树协议参数调整角度思考）
下篇预告：第104篇：VLAN 规划原则：业务与管理分离