摘要

  • MSDP 的 Source-Active 消息公开一个源地址、组地址和发起 RP；接收域只有在本地存在兴趣时，才据此发起 (S,G) Join。源的公开、接收者的需求和数据的到达是三件不同的事。
  • peer-RPF 约束消息从哪个邻居进入，缓存和计时器维持控制状态，过滤与上限控制资源消耗；这些机制都没有直接观察最终接收结果。

“知道有源”只是建树的起点

想象一个只拥有接收者的网络。它不愿把成员关系向全网公开，却希望在别的域出现感兴趣的源时收到内容。RFC 3618 给出的办法不是先公布接收者，而是让源所在域的 RP 发布 Source-Active 消息。消息包含源地址、组地址和 RP 地址，跨 MSDP 邻居传播。

当接收域的 RP 看到 SA 后，它还要查询本地是否存在对该组的兴趣。只有 (*,G) 状态具有非空出接口时，才触发面向该源的 (S,G) Join。之后由 PIM 建立源树分支，后续数据才可能抵达。

这套流程被称为 flood-and-join：先扩散源的可见性，再由需求侧决定是否加入。它巧妙地分开了供给与需求，也决定了证据必须分开保存。

SA 到达只能说明一条源声明进入控制面。没有 SA，未必没有源；可能是会话、路由、过滤或策略阻断了声明。有 SA，也未必有接收者、Join、已安装树或数据。把“Source-Active”翻译成“业务在线”，就是把协议字段提升成它没有观察过的事实。

peer-RPF 证明的是消息方向

RFC 3618 明确说，MSDP 的 peer-RPF 用于 SA 消息转发。它根据消息内的发起 RP 地址查询 MRIB，并按确定规则选择“朝向这个 RP”的邻居。消息从选中的邻居来，就被接受；从其他邻居来，就被丢弃。

这能抑制洪泛环路，也能让同一个声明有可预测的入口。但它检查的不是源地址对应的主机，不是源是否有权向组发送，也不是数据包实际走过的接口。通过 peer-RPF 的是信使路线，而不是声明内容的真实性。

RFC 4611 进一步显示，这一判断受 MBGP、IGP、会话地址和部署结构影响。某些网络使用单一邻居、直连 RP、mesh-group、IGP 或默认邻居，并可能跳过常规的 BGP 路径检查。这样的例外可以完全合理，但其权威来自显式配置，而不是自动推导。

因此，审计记录不能只写“RPF pass”。它应包含查询了哪张表、当时通往 RP 的路由、选中了谁、命中了哪条规则、是否有默认或静态例外、配置由谁批准。没有这些上下文，绿色结果只是把一个复杂判断压扁成灯号。

缓存让声明可用，也让时间变得含糊

MSDP 说话者必须缓存 SA。缓存能减少新接收者加入时的延迟，给消息发送节奏提供约束，并帮助故障诊断。发起 RP 每 60 秒周期性通告仍被视为活跃的源；会话重建后，实现还应发送全部缓存消息。

这意味着“刚收到”不一定等于“刚发现源”。一次连接恢复可以把早先缓存的声明重新送达。接收时间是新的，源观察可能不是。每个缓存项还有 SA-State 计时器，后续 SA 会重置它；到期后的处理由实现决定，通常进入删除过程。

运营系统至少要分开四个时间：源侧首次观察、SA 创建、对端接收、缓存刷新。若把它们合成“最后活跃时间”，排障人员会把控制面保鲜机制误认为数据面的持续采样。

反向推理同样危险。缓存项消失不证明源停止了。路由变化可能使消息从非选中邻居到达；过滤器可能拦截了它；状态上限可能拒绝新条目；mesh 连接可能缺失。缺席首先是一个待解释的观测结果。

一个接收者需要更长的证据链

从 SA 到业务，需要经过本地兴趣、Join、RPF 接口选择、逐跳状态安装、数据包到达和应用消费。任何一段都可能在前一段成功后失败。

接收域可能有 (*,G)，却因为 SA 过滤而不知道特定源。它可能发出 (S,G) Join，却因单播路径变化选择了不同接口。路由器可能安装状态，而上游源已经停止。数据包可能进入最后一跳，但接收应用因内容过期、格式错误或授权失败而丢弃。

RFC 3618 还允许在 SA 中封装一个 IPv4 数据包，为短促流量在树尚未建成时提供早期传递。那是一个有价值的样本，却不能证明后续树已经形成，也不能证明持续流量或应用结果。首包收据不应冒充会话收据。

完整证据应该把同一个 (S,G) 的来源观察、SA、peer-RPF 决策、缓存纪元、本地需求、Join、树状态、叶端数据和应用判定串联起来。任何缺失环节都应明确留空。

全互联假设可能把故障变成沉默

mesh-group 为了减少重复洪泛，规定成员收到来自同组成员的 SA 后，不再转发给其他组内成员。理由是发起者本应直接发送给每一个成员。这个优化成立的前提是完整全互联。

如果少了一条会话，某个 RP 可以一直不知道一个真实源。其他成员即便拥有正确缓存，也会依照抑制规则不去补发。系统没有形成环路，也没有明显格式错误；它只是出现不对称知识。

所以“属于同一个 mesh-group”不是拓扑证明。需要独立验证成员清单、会话状态、会话地址、认证策略和缓存集合。故障演练应拔掉一条边，观察声明是否按设计缺失、告警是否能指出真正原因，以及恢复后缓存是否重新收敛。

Anycast RP 把问题带入冗余场景。RFC 3446 让多个 RP 共享同一服务地址，同时通过 MSDP 同步源状态。SA 不能使用 anycast 地址作为发起 RP 地址，否则 peer-RPF 可能失败；它必须保留具体实例的可路由身份。共享入口并没有消除个体来源。

认证邻居不等于授权源

RFC 3618 要求实现支持 TCP MD5，用来保护控制消息。配置正确时，它能让双方确认会话持有预期密钥，并减少传输途中被随意修改的风险。RFC 6952 和 RFC 8916 又把密钥、认证、过滤和运维状态纳入更清晰的管理视野。

但会话身份只到邻居为止。邻居可能诚实地转发一个错误观察，远端 RP 可能配置过宽，源可能在抵达 RP 之前伪造地址。认证证明“谁通过这个连接发了消息”，不证明“消息描述的源有权存在”。

SA 过滤器与状态上限也不能提供真实性。它们的任务是把资源风险限制在本地可承受范围。通过过滤说明声明符合策略；达到上限而丢弃说明系统选择了自我保护。真实服务和恶意状态都可能落在任一侧。

因此，安全仪表盘应同时展示会话认证、路径选择、内容策略、缓存压力和数据结果，而不是合并成一个“MSDP healthy”。每个词都对应不同负责人和不同补救办法。

撤销比宣布更难

SA 会被洪泛、缓存、重放，并在接收者后来出现时触发 Join。一个过时声明可能在多个位置留下派生状态。要安全撤销它，运营者必须知道它在哪个路由纪元被接受、经过什么规则、进入哪些缓存，并衍生了哪些树分支。

二阶风险是错误的相关扩散：一个源声明可以让多个域同时消耗状态。三阶风险是证据贫困：所有设备都记录“已接受 SA”，却没有任何一个设备记录源是否持续发送或应用是否收到内容。

Heng Lu 强调，规范只应提供最低限度的共同协调，未来决策留在承担后果的本地。MSDP 正好体现这一点。RFC 定义传播机制；每个域仍需决定信任哪些邻居、允许哪些 (S,G)、付出多少状态，并用本地数据验证业务。

RFC 3618 没有承诺一条消息等于服务真相。它让源信息能够跨域行动。越是可行动的声明，越需要在行动之后寻找独立见证。

Sources