摘要

  • RGMP 用路由器周期刷新每个组的需求，替代交换机向路由器端口无差别泛洪，但前提是每个启用端口只直连一台启用路由器。
  • 两台路由器共用端口时，一台发出的 Leave 会切断另一台仍需要的流量。RFC 3488 认为这种低流量、可见的失败胜过隐藏错误的泛洪。

IGMP Snooping 能听见主机加入哪个组，却听不见路由器为了继续转发而需要哪些组。交换机因此只能把组播流量泛洪到路由器端口。在以高速路由器为主的交换骨干中，这不只是带宽浪费；每台路由器还要接收并丢弃本不需要的数据。

RFC 3488 记录的 RGMP 试图补上这块空白。只有路由器发送 RGMP 消息，交换机消费它们，路由器忽略收到的 RGMP。Hello 让端口进入启用状态并启动五倍 Hello 间隔的定时器；Join 为一个组建立需求并需周期刷新；Leave 撤销需求；Bye 或定时器到期则恢复端口原来的转发行为。

这种简洁依赖一个物理不变量：一个 RGMP 交换机端口只直连一台启用 RGMP 的路由器。这不是部署手册里的软建议，而是状态模型成立的前提。交换机可以记录 Hello 与 Bye 的 IPv4 来源，在一个端口出现多个来源时报警，但它无法只凭端口级状态安全地区分两台路由器的独立意图。

假设两台路由器共用一端口，也都需要组 G。后来其中一台发送 Leave，另一台仍保持加入。交换机只知道“这个端口”的组状态，于是可能停止向整个端口发送 G。仍然需要流量的那台路由器及其下游用户便遭遇间歇黑洞。

RFC 对这个故障的评价十分少见：实际用户很容易察觉，而且失败时产生的流量更少，而不是更多。交换机可以提供关闭 RGMP、退回 IPv4 组播泛洪的配置项，但规范称其“可能危险”。泛洪会让可达性看似恢复，同时把 RGMP 原本要提供的流量约束完全取消。

假恢复还改变因果关系的时间距离。端口误接发生在安装或变更时；泛洪可能让它长期不暴露，直到流量增长、端口拥塞或路由器丢弃负担上升。届时，故障已经与起因隔着数天、多个变更和一条平滑增长曲线。“现在还能收到包”不能证明拓扑正确。

Join 也不是硬件交付收据。部分链路本地组与 Cisco 发现组必须始终转发。路由器收到不想要的组时可以发送数据触发 Leave，但应限速。如果一个需要的组与不需要的组映射到相同以太网目的 MAC，路由器可能抑制 Leave，交换机硬件也可能无法选择性停止其中一个。

并行过滤机制又增加一层。RGMP 与 IGMP Snooping 或其他二层机制同时运行时，只要任一机制要求某组，交换机就必须保留转发；只有全部机制都不再需要时才可移除。因此，抓到 Leave 不证明转发表已经删除，看到数据仍在流动也不一定证明 RGMP 忽略了 Leave。

交换机之间的链路同样不受 RGMP 完整约束。交换机不转发 RGMP 消息，跨交换机链路可能依靠 PIM Hello 或人工配置而继续泛洪。不支持 RGMP 的路由器仍会收到全部组。一个边缘端口受控，不等于整张局域网都受控。

协议的简单性还限定了路由模式。PIM Dense Mode 与 DVMRP 需要接收显式 Join 模型可能拦下的流量。Bidir-PIM 的 DF 不应在该网络启用 RGMP。PIM-SM 中，直连源所对应的 DR 需要无条件接收流量以触发注册，而 PIM-SSM 又有不同条件。功能可用不等于角色兼容。

安全也建立在单系统端口上。伪造 Hello 可让原本不支持 RGMP 的路由器端口被限制；伪造 Leave 可切断特定组；伪造 Bye 或 Join 则可恢复不需要的流量，使按照“会被抑制”假设配置容量的端口过载。攻击既可把流量推向过少，也可推向过多。

重建事实要从控制消息之前开始。先确认物理端口和其后的所有系统，保存 Hello/Bye 来源、端口状态定时器、组地址、Join 刷新与 Leave 顺序；再拼接 MAC 映射、并行过滤状态和真实硬件转发表。最后才看包计数、路由器丢弃、端口利用率与下游接收，区分正常抑制、意外黑洞与隐藏泛洪。

按照 Heng Lu 对现实层的要求，RFC 3488 的严厉默认值有其价值：显性失败迫使物理拓扑面对协议前提，泛洪则保护表象，却把成本转移到带宽、路由器算力与未来诊断。它选择的不是“永远可达”，而是一个仍能找到位置的故障。

来源