摘要

  • RFC 2260 让接入 N 家 ISP 的企业从每家获得一个提供商分配前缀；稳态下，每个边界只向直接上游宣告该上游分配的前缀，从而保留聚合。
  • 故障恢复会把成本重新放置：自动注入更具体路由增加无默认路由区的状态，非直连 EBGP 与封装把状态移入提供商协作和隧道，而更优路径又可能要求受限传播附加路由。
  • 这些是设计选择，不是部署收据。文档不证明提供商接受路由、策略一致、地址可携带、全球表实际缩小或任何一次通信普遍可达。

多宿主首先是一项状态分配决定

RFC 2260 于 1998 年 1 月以 Informational RFC 发布。它没有制定一项互联网标准，也没有提交某次网络测量。它处理的是一个结构性问题：企业为了可靠性、负载分配或更合适的地理路径接入多家 ISP 时，如何避免让全球无默认路由区永久保存每一家多宿主企业的独立路由。

文档的起点不是“一个地址、很多出口”，而是每个上游各自借出一个地址前缀。接入 N 家 ISP 的企业得到 N 个前缀。企业可以按照主机靠近哪个互联点来分配地址，也可以让一台主机拥有来自多个前缀的地址。这样做把地址和上游拓扑联系起来：从哪一个前缀取地址，会影响入站流量自然落在哪个连接上；更换提供商时，使用其地址块的部分网络也需要重新编号。

这与可携带性相反。提供商分配的前缀能进入该提供商的大聚合，并不因此成为企业离开该提供商后仍可自由使用的财产。RFC 2260 提到 NAT 可能改变编号问题，但明确把多宿主 NAT 排除在自己的范围之外。

安静的稳态依赖故障时的例外

RFC 2260 的基本规则很克制：连接 ISP-A 的企业边界路由器，稳态只向 ISP-A 宣告 ISP-A 分配的 Pref-A。连接 ISP-B 的边界同样只宣告 Pref-B。这样，企业前缀可以隐藏在各自提供商的大聚合内，不必作为企业专属路由传播到整个无默认路由区。

故障改变这项安排。如果企业判断通过 ISP-B 的互联网连接已经中断，仍然存活的 A 侧可以开始向 ISP-A 宣告 Pref-B。此时全球系统获得了一条额外的更具体路由，让原本指向 B 的流量有机会经 A 抵达企业。B 恢复后，这条额外宣告应当撤回。

文档建议通过企业边界间的 IBGP 观察两侧可达路由集合是否仍有交集。对庞大路由集合计算交集可能昂贵，因此也可以监视一个或几个代表 ISP 骨干的前缀：如果 A 侧不再经 IBGP 看到 B 的代表前缀，就触发 Pref-B 的自动注入。

这一步容易被误读成“故障切换已经完成”。事实上，它只形成了一份新的控制面声明。其他 ISP 可能按前缀长度过滤该路由，RFC 2260 自己承认由此可能得不到完整的互联网范围可达性。即使路由被接收，也仍需分别证明传播、最佳路径选择、转发、返回路径和应用交付。

RFC 2260 预期所有多宿主企业不会同时故障，因此平均附加路由数量只占企业总数的一小部分。那是一项建模假设，不是对真实全球路由表的观测结果。自动注入还会把一次企业连接变化传播给无默认路由区中的大量路由器；链路抖动时，附加路由必须保持到原连接稳定，才能避免反复放大变化。

不把路由放进全球表，就要把机制放到别处

文档的第二种安排使用非直连 EBGP。企业边界除了与直接相连的 ISP 路由器建立 EBGP，还与另一侧 ISP 内的路由器建立跨越多跳的会话。企业仍然只向每家 ISP 宣告该 ISP 分配的前缀；双方都优先选择直接会话学到的路径，非直连路径只在直接路径失效时接手。

经非直连路径转发时使用封装。若 B 侧接入链路断开，发往 Pref-B 的流量仍先到 ISP-B，再由 ISP-B 封装送往企业仍存活的 A 侧边界，解封后进入企业网络。RFC 2260 因而可以说，这种安排不需要把企业故障生成的额外路由放进全球无默认路由区，也不会受外部更具体前缀长度过滤的同一种影响。

但状态并未消失。非直连 EBGP 会话、路由偏好、隧道终点、认证、故障检测和解封装能力必须由有关网络掌握。文档要求多跳 EBGP 使用合适的对等认证，却把 IBGP 和单跳 EBGP 的安全问题留在范围之外。它也没有提供任何提供商已经同意、部署或正确运行这一安排的证据。

更短的路径会重新召回更多路由

非直连 EBGP 在故障时可能造成绕行。即使没有故障，只向直接上游宣告其本家前缀，也可能让同一 ISP 的其他客户前往企业另一提供商前缀时走一条较差路径。若企业希望改善入站路径，可以把其他提供商分配的前缀也向某个上游宣告。

这又把路由状态带了回来。RFC 2260 建议用 BGP Community 等手段限制附加宣告的传播范围，也可以把非直连方案与受限的自动注入结合。边界因此十分清楚：更广的可见性可能改善路径和故障恢复，但失控的传播会增加全球状态；严格聚合可以保护路由规模，却要接受地址依赖、运营协调、隧道或次优路径。

提供商无关地址则把另一种成本写得更直接。企业拥有一个不依附某家 ISP 的前缀，内部编号和外部连接可以分离；但这条企业路由不能并入某家提供商的聚合。RFC 2260 把其无默认路由区成本描述为随多宿主企业数量 O(N) 增长。选择单一提供商前缀、再让其他 ISP 选择性传播，也需要代理聚合、额外跨 ISP 协调和更复杂配置。

所以 RFC 2260 没有找到“免费多宿主”。它给出的是一张成本转移图：地址与提供商绑定、故障时的全球更具体路由、非直连会话与封装、受限的附加状态、或较差路径。后来的 RFC 2519、RFC 4116 和 RFC 8678 延续了同一纪律：聚合能减少表项和抖动范围，PA 多宿主也能避免 PI 路由扩张，但主机、路由器和上游仍需处理源地址、出口、恢复与会话连续性。

来源与证据限度

下列官方资料支持 RFC 2260 的状态、机制、历史引用及后来的官方比较。它们不提供命名部署、路由采集器数据、提供商接受记录、全球表改善测量或用户结果。