二层组播+STP切换时丢包

现网中用的是pvst，如果断了一条线后，生成树重新收敛，但是上面的另一台汇聚交换机的之前连接接入的交换机接口是block，所以美瑶IGMP成员，此时丢包。此时应该选择配置设备在链路拓扑发生变化时立即发送IGMP普遍组查询报文，还是在端口状态发生变化时立即发送IGMP普遍组查询报文？

正常工作时，汇聚交换机通过 IGMP Snooping 监听下方接入交换机发来的 IGMP Report 报文，从而建立组播转发表项，明确哪些端口下存在组播接收者。汇聚交换机 A 作为主链路，其端口处于 Forwarding 状态，能够正常学习 IGMP Report，表项完整，组播数据转发正常。当主链路发生故障时，STP 协议首先感知到拓扑变化，开始重新计算，将汇聚交换机 B 的端口从 Blocking 状态迁移为 Forwarding 状态，此时流量被切换到汇聚交换机 B。然而问题的关键在于，汇聚交换机 B 的端口此前一直处于 Blocking 状态，在 Blocking 状态下，交换机不会学习 IGMP Report 报文，因此汇聚交换机 B 的组播转发表中没有任何关于该端口下方接收者的表项。当流量切过来时，汇聚交换机 B 查表发现表项为空，便判定下方没有接收者，于是将组播数据全部丢弃，导致业务中断。此后需要等待 IGMP 普遍组查询周期到达，通常默认间隔为六十秒，汇聚交换机 B 发送 Query 后，接入交换机回复 Report，汇聚交换机 B 才能学到表项并恢复转发。这个从 STP 收敛完成到 IGMP 表项重建的间隙，就是造成丢包的根本原因，即存在一个表项真空期。

文档中提供了两种方案，分别是端口链路状态变化触发和拓扑链路变化触发。端口链路状态变化触发是监控物理端口的 UP 和 DOWN 事件，一旦链路断开就立即发送 IGMP 普遍组查询。但这种方式存在明显的盲区，在单通、光模块故障、对端设备挂死或链路严重误码等场景下，端口可能依然显示为 UP 状态，触发机制便不会生效，汇聚交换机 B 依然没有表项，流量切换后依然丢包。而拓扑链路变化触发是基于 STP 的 TC 报文来触发的，STP 通过 BPDU 保活机制持续探测邻居连通性，无论故障是物理断线还是对端设备逻辑失效，只要 BPDU 无法正常交互，STP 都会判定拓扑发生改变，继而发送 TC 报文。以 TC 报文作为 IGMP 重新学习的触发信号，能够覆盖所有故障场景，不会出现 STP 已经切换而 IGMP 尚未反应的脱节问题。因此，选用拓扑链路变化触发是更可靠、更稳妥的方案。

解决方法：在汇聚交换机 A 和汇聚交换机 B 上同时启用基于 STP 拓扑变化触发 IGMP 普遍组查询的功能。在 IGMP Snooping 视图下配置相关命令，使设备在收到 STP 的 TC 报文时，立刻向所有端口发送 IGMP General Query 报文。配置完成后，当主链路再次发生故障时，工作流程将变为：STP 感知拓扑变化并发送 TC 报文，汇聚交换机 B 收到 TC 报文后立即触发 IGMP 普遍组查询，向所有端口发送 Query，接入交换机收到 Query 后立即回复 IGMP Report 报告成员信息，汇聚交换机 B 据此建立组播转发表项，此时表项已经就绪，之后 STP 完成收敛、汇聚交换机 B 端口变为 Forwarding，流量切换过来时，汇聚交换机 B 查表发现表项已存在，直接正常转发，业务不再中断。