摘要

  • RFC 3446 让多个活跃 PIM-SM RP 宣告同一个 Anycast 地址，使源与接收者沿单播拓扑到达最近实例，减少对遥远单一 RP 的依赖。
  • 后台协调必须使用唯一单播地址：MSDP 对等、router ID 和 Source-Active 的来源/RPF 不能冒用共享身份；最近路由也不证明源状态同步或多播已送达。

单一映射把地理变成成本

RFC 2362 允许为同一组配置多个 RP，但同一时刻只有一项组到 RP 的映射生效。这个中心承担 Register 解封装，故障时切换可能缓慢，并会把本地流量拉向拓扑上很远的位置。RFC 3446举例说，欧洲的源与接收者可能先把流量送到美国 RP，再沿共享树返回，昂贵链路被来回使用。

运营者也可以把 224.0.0.0/4 分给多个 RP，却必须预先知道各组流量。分布变化后还要不断重配；号码切得平均，不代表工作量平均。

RFC 3446 于 2003 年 1 月以 Informational 发布。纯文本、RFC Editor 记录、Datatracker、历史、参考文献、后续引用与勘误证明机制被写下，不能证明某个骨干网的效果。

共同入口只负责选择

服务同一组范围的 RP 配置同一个 Anycast 地址，通常放在逻辑接口。组到 RP 映射指向这个地址，每台 RP 把共享 /32 注入 IGP。普通单播路由于是把源的 Register 或接收者的 Join 引向当前最短的宣告路径。

它没有发明一台全球负载均衡器，而是复用已有拓扑判断。但所有 RP 必须有一致的组映射，非 RP 路由器也要通过静态配置、Auto-RP 或后来由 RFC 5059规定的 PIMv2 Bootstrap 学到同一含义。共同地址不会自动同步配置。

后台必须知道“具体是谁”

RP 之间用 MSDP 传播活跃源知识；MSDP 后来由 RFC 3618规定。本机制不要求 MBGP，却要求 MSDP。对等会话的两端必须使用唯一单播地址。

Anycast 地址也不得成为 router ID，否则对等或邻接可能建不起来；更不能在 Source-Active 消息中充当 RP 地址，因为 peer-RPF 检查会失败。前台身份回答“哪个实例离我近”，后台身份回答“哪一个具体对等端产生了这条状态”。前者刻意隐藏副本，后者必须保留来源。

因此，共享名拿去做唯一身份，不只是日志难读，而是破坏协调算法所需的责任链。Anycast 是到达某个副本的路由方式，不是副本之间的身份系统。

多一个 RP，也多一层状态

通过 MSDP 工作会在接收者到源的路径上强制创建 (S,G) 状态；若大家一直停留在单一 RP 根的共享树，这些状态可能不存在。改变汇聚点架构，也改变内存、抖动与排障表面。

同一地址也不保证实例稳定。单播路由一旦抖动，源或接收者实际使用的 RP 就会变化。地址看似不动，服务路径却可能切换。防伪、单播路由完整性、PIM 和 MSDP 会话完整性仍需分别保护。

后来的 RFC 4601与 RFC 7761更新 PIM-SM，RFC 4610给出不用 MSDP 的 PIM Anycast-RP，RFC 4786总结一般 Anycast 运维。这些是演进背景，不证明单一因果。IANA 多播地址和 PIM 参数证明登记值，不证明树已建立或报文已到达。

“可用”需要多张收据

Heng Lu 的现实层纪律把共享地址、IGP 路由、实际实例、MSDP 源知识、PIM 转发状态、观察到的报文和接收结果分别记账。路由存在只证明一次选择，不证明 RP 健康、映射一致、对等完整或交付成功。

运行代码优先让洲际部署暴露的远端 RP 成本和静态分区失衡有资格修正抽象模型，却不让路由记录冒充服务结果。最小初始规范则支持窄边界：共享必要入口，明确副本身份，把拓扑和采用交给运营者。这是编辑解读，不是作者动机声明。

RFC 3446 留下的设计纪律是：客户端需要一个隐藏副本的稳定名，副本需要一组彼此可辨的稳定名。把两类名字混为一个，会让入口更简洁，却抹掉协调必须依赖的来源。

来源