关键词：BGP、路由反射器、反射规则、Cluster_List、Originator_ID、防环机制、RR层级

第88篇：RR 反射规则与 Cluster_List 防环

一、引言

在第87篇中，我们了解了路由反射器（RR）的基本概念和部署架构。RR 通过打破 iBGP 水平分割规则来减少邻居关系数量，但这种打破必须辅以严格的反射规则和防环机制。

RR 的反射规则决定了路由在 RR 架构中如何传播，而 Originator_ID 和 Cluster_List 两个新增的 BGP 属性则确保了反射架构不会引入路由环路。深入理解这些规则和工作原理，对于正确部署和排查 RR 架构的故障至关重要。

二、核心概念

2.1 反射规则的精确描述

RR 的反射规则基于路由来源和反射目标的关系，是 RR 架构的核心逻辑：

三条规则的本质：

1. 规则1：eBGP 路由无水平分割限制，RR 将其传递给所有 iBGP Peer（Client + Non-Client）
2. 规则2：Client 的路由需要传播到全网，RR 将其反射给所有其他 Peer（Client + Non-Client）
3. 规则3：Non-Client 的路由只反射给 Client，不反射给其他 Non-Client——Non-Client 之间的路由交换仍遵循 iBGP 全互联规则

规则3 的深层含义：这是 RR 架构中最容易被误解的规则。Non-Client 之间不通过 RR 中转路由，它们之间如果需要交换路由，必须建立直接的 iBGP 会话。这条规则保证了 RR 的"反射"不是简单的"转发"，而是有选择地打破水平分割。

2.2 Originator_ID 防环机制

Originator_ID 属性记录路由的原始发布者（第一次将路由注入 iBGP 的路由器）的 Router ID：

2.3 Cluster_List 防环机制

Cluster_List 记录路由经过的所有 RR 的 Cluster ID，按经过顺序排列：

Cluster_List 示例：

原始路由: Cluster_List = (空)
RR1(CID=5.5.5.5)反射后: Cluster_List = 5.5.5.5
RR2(CID=6.6.6.6)反射后: Cluster_List = 6.6.6.6 5.5.5.5
RR3(CID=7.7.7.7)反射后: Cluster_List = 7.7.7.7 6.6.6.6 5.5.5.5

三、技术细节

3.1 多层 RR 架构

在超大规模网络中，单层 RR 可能无法管理所有 Client，需要引入多层 RR：

多层 RR 的路由传播流程：

1. C1 宣告路由 → RR_R1（Client → RR）
2. RR_R1 反射给 RR_G1（Client → Non-Client，规则2）
3. RR_G1 反射给 RR_R2（Non-Client → Client，规则3）
4. RR_R2 反射给 C3（Non-Client → Client，规则3）

Cluster_List 变化：

C1→RR_R1: Cluster_List = (空)
RR_R1反射: Cluster_List = 10.1.0.1
RR_G1反射: Cluster_List = 10.0.0.1 10.1.0.1
RR_R2反射: Cluster_List = 10.2.0.1 10.0.0.1 10.1.0.1

3.2 Originator_ID 与 Cluster_List 的对比

两种机制缺一不可的原因：

• 只有 Originator_ID：可以防止路由回到原始发布者，但无法检测 RR 之间的环路（如 RR1→RR2→RR1）
• 只有 Cluster_List：可以防止 RR Cluster 级别的环路，但 Client 自己宣告的路由被反射回来时，如果没有 Originator_ID，Client 无法识别并丢弃
• 两者配合：Originator_ID 防止"回到起点"，Cluster_List 防止"经过同一 Cluster 两次"，覆盖所有可能的环路场景

3.3 Cluster_List 长度限制

Cluster_List 是一个可变长度的属性，每经过一个 RR 增加 4 字节：

虽然 BGP Update 报文最大 4096 字节，Cluster_List 不太可能成为瓶颈，但在极端深层的 RR 架构中仍需关注。

四、实战配置/案例分析

4.1 多层 RR 配置

# ===== Tier-1 RR（全局RR）配置 =====
sysname RR_Global
interface LoopBack 0
 ip address 10.0.0.1 32

bgp 100
 router-id 10.0.0.1

 # Tier-2 RR作为Client连接到Tier-1 RR
 peer 10.1.0.1 as-number 100
 peer 10.1.0.1 connect-interface LoopBack 0
 peer 10.1.0.1 reflector-client
 peer 10.1.0.1 cluster-id 10.0.0.1

 peer 10.2.0.1 as-number 100
 peer 10.2.0.1 connect-interface LoopBack 0
 peer 10.2.0.1 reflector-client
 peer 10.2.0.1 cluster-id 10.0.0.1

# ===== Tier-2 RR（区域RR）配置 =====
sysname RR_Region_1
interface LoopBack 0
 ip address 10.1.0.1 32

bgp 100
 router-id 10.1.0.1

 # 与Tier-1 RR建立Non-Client关系
 peer 10.0.0.1 as-number 100
 peer 10.0.0.1 connect-interface LoopBack 0
 # 注意:Non-Client,不配置reflector-client

 # Client（PE路由器）
 peer 10.1.1.1 as-number 100
 peer 10.1.1.1 connect-interface LoopBack 0
 peer 10.1.1.1 reflector-client
 peer 10.1.1.1 cluster-id 10.1.0.1

4.2 案例分析：Cluster_List 防环实战

故障现象：配置双层 RR 后，部分路由在 RR 之间不断翻转，BGP 日志显示大量路由撤回和重新通告。

排查：

1. 检查 Cluster_List：

[RR_G1] display bgp routing-table 10.1.1.0 verbose
  Cluster_List: 10.1.0.1 10.0.0.1 10.1.0.1
  # Cluster ID 10.1.0.1 出现了两次!
  # 说明路由经过了 Tier-2 RR (CID=10.1.0.1) 两次

1. 分析路由传播路径：
2. Client1 → RR_R1（添加 CID=10.1.0.1）
3. RR_R1 → RR_G1（添加 CID=10.0.0.1，列表：10.0.0.1 10.1.0.1）

4. RR_G1 反射给 RR_R1（规则3：Non-Client→Client）

5. 根因：RR_G1 将路由反射回 RR_R1（作为 Client），而 RR_R1 的 Cluster_ID（10.1.0.1）已在 Cluster_List 中。但 RR_R1 应该检测到并丢弃——如果未丢弃，说明 Cluster_List 检查逻辑未生效。

6. 进一步排查发现：RR_R1 与 RR_G1 之间的关系被错误配置为 Client：

[RR_R1] display current-configuration | include peer.*10.0.0.1
 peer 10.0.0.1 as-number 100
 peer 10.0.0.1 reflector-client    # 错误!应该是Non-Client
 peer 10.0.0.1 cluster-id 10.0.0.1  # 错误!不应该使用RR_G1的CID

1. 修复：

[RR_R1] bgp 100
[RR_R1-bgp] undo peer 10.0.0.1 reflector-client
[RR_R1-bgp] undo peer 10.0.0.1 cluster-id
 # Tier-1 RR和Tier-2 RR之间应该是Non-Client关系

4.3 案例分析：Originator_ID 导致的最佳路径丢失

故障：Client1 宣告了路由 10.1.1.0/24，但该路由经过 RR 反射回来时，Client1 丢弃了它。然而 Client1 本身还从 eBGP 学到了同一条路由，且该路由通过 RR 反射回来后也被丢弃。

排查：

1. 检查路由属性：

[Client1] display bgp routing-table 10.1.1.0 verbose
  Originator_ID: 1.1.1.1      # 本路由器自身的Router ID!
  # 该路由被丢弃,因为Originator_ID匹配自身Router ID

1. 分析：这是 RR 防环机制的正常行为。Client1 宣告的路由经过 RR 反射回来时，携带 Originator_ID=1.1.1.1（Client1 自己的 Router ID），Client1 检测到后丢弃。

2. 但如果 Client1 从 eBGP 学到的同一条路由也携带了错误的 Originator_ID，则需要排查：

# 检查RR上的配置,确认eBGP路由反射时Originator_ID的设置
# eBGP路由反射时,Originator_ID应该设置为RR自身的Router ID,而非eBGP对端的Router ID

结论：Originator_ID 防环是 RR 架构的正常行为。原始发布者不需要从 RR 反射回自己的路由，因为它已经是该路由的源头。

五、总结

思考

1. Originator_ID 防止的是哪种类型的环路？如果 RR 架构中没有配置 Originator_ID 属性，会发生什么具体问题？
2. Cluster_List 的长度是否会无限增长？在实际部署中，RR 的最大合理层级深度是多少？为什么？
3. 为什么 RR 反射 Non-Client 的路由时只反射给 Client 而不反射给其他 Non-Client？如果也反射给其他 Non-Client 会导致什么问题？

下篇预告：第89篇：联邦（Confederation）解决 IBGP 扩展问题