STP TC 问题引起的丢包问题复盘

客户网络每天凌晨2点断网，每次10分钟，并且工控网络在断网后无法自行恢复，对业务影响巨大，一个多月来无法找到原因；开始认为是防火墙做了拦截，通过查看防火墙日志，意外发现2点的时候防火墙能够看到其他主机的单播流量；发生这种情况要么说明网络当时产生了环路，要么说明MAC地址表项满了，要么说明交换机没有MAC表项（MAC地址表空了)造成的未知单播泛洪。
下图：工控防火墙上面在这个时间点看到了其他主机的单播报文，这点非常关键：

继续查找交换机日志，发现对应时间点核心交换机出现了非常多的TC报文

查看业务接口 这个queue 2 传输的是业务流量，而聚合组的2个成员端口都存在大量丢包的记录，初步怀疑是未知单播报文流量过大，超过端口带宽造成的丢包


核心交换机继续查看TC 记录 发现 产生日志的对应端口有巨量TC 报文接收，接收到报文后，在其他端口泛洪的现象，而TC报文会刷新对应交换机的MAC表项。造成未知单播泛洪。

通过dis stp brie 看到该端口role 是root 意识到根桥不在核心上面，导致了根桥的抢占行为；于是通过在核心交换机配置**stp instance 0 root primary将根桥抢占过来，除此之外，在核心上还配置了stp tc-protection threshold 2 开了TC保护。
大量的STP TC报文造成的大二层网络MAC地址表频繁刷新，再导致的端口丢包，造成的每天定时断网现象。但是我们并没有找到这个大量的TC报文产生的原因，继续分析。（理论上还需要分区域 不同区域）

通过dis stp tc /dis lldp nei list 查找TC来源发现
第一步：这台172.23.95.30的汇聚交换机的1 4 5 号端口接的接入层交换机上，分别接了人员定位基站，这个基站每天凌晨2点定时重启；发送TCN报文给汇聚交换机；汇聚交换机发送TCN 给根交换机
核心交换机此时由于配置错误，还不是根交换机，所以收到TCN报文后会向根交换机继续转发TCN报文，也就是这里Ten1/0/6接口所连的STP根交换机。

这台根交换机收到核心交换机的TCN报文后，就发送TC报文给核心交换机，不幸的是，核心交换机和这台172.23.95.46之间，使用了一个千兆光转电模块，来适配核心S6520X到S5560接入；由于软件版本BUG，每个TCN报文对应的TC报文接入交换机都会发18次，而核心交换机收到这个TC报文后，在每个端口进行转发，同时刷新自身的MAC地址表；这个TC报文就在全网进行了泛洪。导致整网在核心交换机TC防护生效之前，大概10分钟内，未知单播报文泛洪，阻塞了几乎所有端口。这样印证了上述接入端口丢包的现象。

解决方案1：将STP根桥调整到核心交换机；在指定端口启用根保护；全局启用TC保护
解决方案2：接入层交换机接入端口全部改为边缘端口，消除每天定时的TC报文
解决方案3：互联千兆光转电口关闭STP
图示:配置边缘端口
本案拓扑如下：（之前喜欢用思科PT画图 感觉特别方便）

类似的技术文件详见：https://www.ftnat.com/a/news/zhishi/128.html
PS:根桥位置修复后，为什么不怀疑中间的工控防火墙；因为之前在核心交换机S6520X和接入层交换机同时做过DEBUG
terminal debug
terminal monitor
debug stp tc
debug stp event
debug stp error
然后针对核心某个物理接口进行shut undo shut 操作模拟核心产生TCN ，然后发送TC给接入交换机；发现2个现象：
1：核心交换机发送的TC包数量和接入交换机收到的TC报文数量一致。
2：核心交换机给其他万兆光口互联的交换机对应一个TCN报文发送一个TC报文；而给这个千兆光转电口发送了18个TC报文。
图示：核心交换机正常的TC报文发送情况
核心交换机针对1/0/6接口异常的TC报文发送情况
下联的接入交换机每次收到从1/0/24收到的TC就泛洪一次