RFC4456：BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)，April 2006
本备忘录的状态
本文档为 Internet 团体指定了 Internet 标准跟踪协议，并请求讨论和改进建议。本协议的标准化状态和现状请参考当前版本的《互联网官方协议标准》（STD 1）。本备忘录的分发不受限制。
版权声明
版权所有 (C) 互联网协会 (2006)。
梗概
边界网关协议 (Border Gateway Protocol，BGP) 是为 TCP/IP 互联网设计的自治系统间路由协议。通常，单个 AS 内的所有 BGP 发言者必须完全连接，以便任何外部路由信息必须重新分发到该自治系统 (Autonomous System，AS) 内的所有其他路由器。这代表了一个严重的规模问题，已通过提出的几种替代方案得到充分证明。
本文档描述了一种称为“路由反射/route reflection”的方法的使用和设计，以减轻对“全互联/full mesh”内部 BGP (Internal BGP，IBGP) 的需求。
本文档已废弃 RFC 2796 和 RFC 1966。
1、 简介
通常，单个 AS 内的所有 BGP 发言者必须完全连接，并且任何外部路由信息都必须重新分发到该 AS 内的所有其他路由器。对于需要维护 n*(n-1)/2 个唯一内部 BGP (IBGP) 会话的 AS 内的 n 个 BGP 发言者。当存在大量 IBGP 发言者时，这种“全互联”要求显然无法扩展，每个发言者都交换大量路由信息，这在当今的许多网络中很常见。
这个规模问题已经有据可查，并且已经提出了许多建议来缓解这个问题[2,3]。该文件代表了另一种减轻“全互联”需求的替代方案，被称为“路由反射”。这种方法允许 BGP 发言者（称为“路由反射器”）向某些 IBGP 对等方通告 IBGP 学习路由。它代表了对 IBGP 的普遍理解概念的改变，并增加了两个新的可选非传递 BGP 属性以防止路由更新中的环路。
本文档已废弃 RFC 2796 [6] 和 RFC 1966 [4]。
2、 需求说明
本文档中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应该”、“不应”、“推荐”、“可以”和“可选”是按照 RFC 2119 [7] 中的描述进行解释。
3、 设计标准
路由反射旨在满足以下标准。
简单
任何替代方案都必须易于配置且易于理解。
轻松过渡
必须可以从全互联配置过渡而无需更改拓扑或 AS。这是[3]中提出的技术的一个不幸的管理开销。
兼容性
不合规的 IBGP 对等体必须有可能继续成为原始 AS 或域的一部分，而不会丢失任何 BGP 路由信息。
这些标准是由具有许多外部连接的非常大且拓扑丰富的网络的操作经验所激发的。
4、 路由反射
路由反射的基本思想很简单。让我们考虑下面图 1 中描述的简单示例。
图 1：全互联 IBGP
在 ASX 中，有三个 IBGP 发言者（路由器 RTR-A、RTR-B 和 RTR-C）。在现有的 BGP 模型中，如果 RTR-A 接收到外部路由并被选为最佳路径，则它必须将外部路由通告给 RTR-B 和 RTR-C。RTR-B 和 RTR-C（作为 IBGP 发言者）不会将这些 IBGP 学习路由重新通告给其他 IBGP 发言者。
如果放宽此规则并且允许 RTR-C 向 IBGP 对等体通告 IBGP 学习路由，则它可以重新通告（或反射）从 RTR-A 学习到的 IBGP 路由到 RTR-B，反之亦然。这将消除 RTR-A 和 RTR-B 之间的 IBGP 会话的需要，如下图 2 所示。
图 2：路由反射 IBGP
路由反射方案就是基于这个基本原理。
5、 术语和概念
我们使用术语“路由反射”来描述 BGP 发言者将 IBGP 获知路由通告给另一个 IBGP 对等体的操作。这样的BGP发言者被称为“路由反射器”（route reflector，RR），这样的路由被称为反射路由。
RR 的内部对等体分为两组：
1) 客户端对等体
2) 非客户端对等体
RR 反射这些组之间的路由，并且可能反射客户端对等体之间的路由。一个 RR 及其客户端对等体形成一个集群。非客户端对等体必须是完全互联的，但客户端对等体不需要完全互联。图 3 描述了一个简单的示例，使用上述术语概述了基本的 RR 组件。
图 3：RR 组件
6、 操作
当 RR 收到来自 IBGP 对等体的路由时，它会根据其路径选择规则选择最佳路径。选择最佳路径后，它必须根据从其接收最佳路径的对等方类型执行以下操作
1) 来自非客户端 IBGP 对等体的路由：
反射给所有的客户端。
2) 来自客户端对等方的路由：
反射给所有非客户端对等点以及客户端对等点。（因此客户端对等点不需要完全互联化。）
一个自治系统可以有许多 RR。RR 对待其他 RR 就像对待任何其他内部 BGP 发言者一样。一个 RR 可以配置为在客户端组或非客户端组中具有其他 RR。
在一个简单的配置中，主干可以分成许多集群。每个 RR 将与其他 RR 一起配置为非客户端对等点（因此所有 RR 都将是全互联的）。客户端将被配置为仅与集群中的 RR 保持 IBGP 会话。由于路由反射，所有的 IBGP 发言者都会收到反射的路由信息。
在自治系统中，可能有不理解路由反射器概念的 BGP 发言者（让我们称它们为传统的 BGP 发言者）。路由反射器方案允许这种传统的 BGP 发言者共存。传统的 BGP 发言者可以是非客户端组或客户端组的成员。这允许从当前的 IBGP 模型到路由反射模型的简单和渐进的迁移。可以通过将单个路由器配置为指定的 RR 并将其他 RR 及其客户端配置为普通 IBGP 对等方来开始创建集群。可以逐渐创建其他集群。
7、 冗余 RR
通常，一个客户端集群将有一个 RR。在这种情况下，集群将由 RR 的 BGP 标识符标识。然而，这代表了单点故障，因此为了在同一个集群中有多个 RR，可以为同一集群中的所有 RR 配置一个 4 字节的 CLUSTER_ID，以便 RR 可以丢弃来自同一个集群其他 RR 的路由。
8、 避免路由信息环路
当一条路由被反射时，有可能通过错误配置形成路由重分配环路。路由反射方法定义了以下属性来检测和避免路由信息环路：
ORIGINATOR_ID
ORIGINATOR_ID 是类型代码 9 的新的、可选的、非传递 BGP 属性。该属性长 4 个字节，由 RR 在反射路由时创建。该属性将携带本地AS中路由发起者的BGP Identifier。如果一个 BGP 发言者已经存在，则不应创建 ORIGINATOR_ID 属性。识别 ORIGINATOR_ID 属性的路由器应该忽略接收到的带有其 BGP 标识符作为 ORIGINATOR_ID 的路由。
CLUSTER_LIST
CLUSTER_LIST 是一个新的、可选的、类型代码为 10 的非传递 BGP 属性。它是一个 CLUSTER_ID 值序列，表示路由已通过的反射路径。
当 RR 反射路由时，它必须将本地 CLUSTER_ID 预先添加到 CLUSTER_LIST。如果 CLUSTER_LIST 为空，它必须创建一个新的。使用此属性，RR 可以识别路由信息是否由于配置错误而环回同一集群。如果在 CLUSTER_LIST 中找到本地 CLUSTER_ID，则应忽略收到的通告。
9、 对路线选择的影响
BGP 决策过程平局打破规则（第 9.1.2.2 节，[1]）修改如下：
如果路由带有 ORIGINATOR_ID 属性，那么在步骤 f) 中，ORIGINATOR_ID 应该被视为已通告该路由的 BGP 发言者的 BGP 标识符。
此外，应该在步骤 f) 和 g) 之间插入以下规则：BGP 发言者应该更喜欢具有较短 CLUSTER_LIST 长度的路由。如果路由不携带 CLUSTER_LIST 属性，则 CLUSTER_LIST 长度为零。
10、 实施注意事项
在 RR 与客户端和非客户端之间交换内部路由信息时，应注意确保上面定义的任何 BGP 路径属性都不能通过配置进行修改。他们的修改可能会导致路由环路。
此外，当一个 RR 反射一个路由时，它不应该修改以下路径属性：NEXT_HOP、AS_PATH、LOCAL_PREF 和 MED。他们的修改可能会导致路由环路。
11、 配置和部署注意事项
BGP 协议无法让客户端动态地将自己标识为 RR 的客户端。实现这一点的最简单方法是手动配置。
解决扩展问题的路由反射方法的关键组成部分之一是 RR 汇总路由信息并仅反射其最佳路径。
多出口鉴别器 (Multi-Exit Discriminators，MED) 和内部网关协议 (Interior Gateway Protocol，IGP) 指标都可能影响 BGP 路由选择。因为 MED 并不总是具有可比性，并且每个路由器的 IGP 度量可能不同，所以对于某些路由反射拓扑，路由反射方法可能不会产生与完全 IBGP 网状方法相同的路由选择结果。使路由选择与使用完整 IBGP 网状方法相同的一种方法是确保路由反射器永远不会被迫基于与其客户端的 IGP 指标显着不同的 IGP 指标执行 BGP 路由选择，或基于无与伦比的 MED。前者可以通过将集群内 IGP 指标配置为优于集群间 IGP 指标并在集群内保持全互联来实现。后者可以通过
* 在边界路由器设置路由的本地首选项以反射 MED 值，或
* 当使用 AS 路径长度作为路由选择标准时，确保来自不同 AS 的 AS 路径长度不同，或
* 配置基于团体的策略以影响路由选择。
有人可能会争辩说，后一种要求过于严格，在某些情况下可能不切实际。有人可能会进一步争辩说，只要没有路由环路，就没有令人信服的理由来强制使用路由反射器进行路由选择与使用完整 IBGP 网状方法相同。
为了防止路由环路并保持一致的路由视图，在设计路由反射拓扑时必须仔细考虑网络拓扑。一般来说，当一个前缀存在多条路径时，路由反射拓扑应该与网络拓扑一致。一种常用的方法是基于接入点（Point of Presence，POP）的反射，其中每个 POP 维护自己的路由反射器为 POP 中的客户端提供服务，并且所有路由反射器都是全互联的。此外，每个 POP 中反射器的客户端通常是全互联的，以实现最佳的 POP 内路由，并且将 POP 内 IGP 指标配置为优于 POP 间 IGP 指标。
12、 安全注意事项
对 BGP 的这种扩展不会改变现有 IBGP [1, 5] 中固有的底层安全问题。
13、 致谢
作者要感谢 Dennis Ferguson、John Scudder、Paul Traina 和 Tony Li 对这项工作的许多讨论。这个想法是从 Tony Li 和 Dimitri Haskin 之间的早期讨论中发展而来的。
此外，作者要感谢 Yakov Rekhter 对本文档的宝贵评论和建议，以及 Tony Li、Rohit Dube、John Scudder 和 Bruce Cole 的有益评论。
14、 参考文献
14.1、 规范性参考
[1] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
14.2、 参考资料
[2] Savola, P., "Reclassification of RFC 1863 to Historic", RFC 4223, October 2005. [3] Traina, P., McPherson, D., and J. Scudder, "Autonomous System Confederations for BGP", RFC 3065, February 2001. [4] Bates, T. and R. Chandra, "BGP Route Reflection An alternative to full mesh IBGP", RFC 1966, June 1996. [5] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998. [6] Bates, T., Chandra, R., and E. Chen, "BGP Route Reflection - An Alternative to Full Mesh IBGP", RFC 2796, April 2000. [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
附录 A：与 RFC 2796 的比较
增加了对路由选择的影响。
删除了 CLUSTER_LIST 属性编码的图示描述，因为该描述对 BGP 规范是多余的，并且属性长度字段无意中被描述为一个八位字节。
附录 B：与 RFC 1966 的比较
附录 A 中列出的所有更改，以及以下内容。
澄清了与路由反射相关的几个术语，并删除了对 EBGP 路由/对等方的引用。
接收器对路由信息环路（由于路由反射）的处理得到澄清并更加一致。
将 CLUSTER_ID 添加到 CLUSTER_LIST 已从“追加”更改为“前置”以反射已部署的代码。
“配置和部署注意事项”部分已扩展以解决几个操作问题。
完整的版权声明
版权所有 (C) 互联网协会 (2006)。
本文档受 BCP 78 中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
本文档和此处包含的信息按“原样”提供，贡献者、他/她代表或由（如果有）赞助的组织、互联网协会和互联网工程工作组不提供任何明示或暗示的，包括但不限于使用此处信息不会侵犯任何权利或任何暗示的适销性或特定用途适用性的保证。
知识产权
IETF 对可能声称与本文档中描述的技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或在此类权利下的任何许可可能或可能不会的程度不持任何立场能得到的;它也不表示它已做出任何独立努力来确定任何此类权利。有关 RFC 文档中权利的程序信息，请参见 BCP 78 和 BCP 79。
向 IETF 秘书处披露的 IPR 披露副本以及任何保证可用的许可，或试图获得本规范的实施者或用户使用此类专有权利的一般许可或许可的结果，可以获得来自位于 http://www.ietf.org/ipr 的 IETF 在线 IPR 存储库。
IETF 邀请任何相关方提请其注意任何版权、专利或专利申请，或可能涵盖实施该标准可能需要的技术的其他专有权利。请将信息发送至 IETF，地址为 ietf-ipr@ietf.org。
致谢
RFC Editor 功能的资金由 IETF 管理支持活动 (IASA) 提供。
