大型BGP网络中的路由反射器工作原理之路由环路篇

本篇继续聊BGP协议组网环境中的路由反射器的工作原理以及相关机制实现等话题，但笔者今天所聊的与RR相关的话题其内容更多与路由环路相关......

那我们就开始进入话题吧~~~

文字的开篇笔者引入一条与RR在通告路由时的特性，如下：

证明一下给我看吧，好的，请看如下拓扑：

如上图所示，BGP ASN 123中4台BGP路由器（R1、R3、R5和R6）分别各自建立IBGP邻居关系（其实这种拓扑可以不用部署RR，但为了证明RR在反射路由时不修改路由属性这一特性，笔者指定R6为R5的RR-CLIENT，R5和R1为R3的RR-CLIENT）。现在R6上引入（network）一条172.16.60.0/24路由，该BGP路由笔者人为给它加了AS_PATH（8、8、8、8）、COMMUNITY（888:888和no-export）和LOCAL_PREF（LP=888）属性。R6会将该BGP路由通告给它的IBGP邻居R5，R5为RR，因此，它从它的CLIENT收到一条BGP路由，它当然会将此路由反射给R3（人家R3还是它的RR呢，就算R3是台普通的IBGP路由器R5根据RR路由反射规则也会反射），之后，R3也会将此路由反射给其CLIENT设备R1，至此，4台路由器的BGP数据库中都会有172.16.60.0/24这条BGP路由。好了，那我们接下来要做的事就是到R5、R3和R1的BGP数据库中去查看，对比验证一下这3台路由器的BGP路由表中的该路由是否有被RR反射时改动过，验证结果如下：

不急，一条一条看......

先看R6

再看R5

接着看R3

最后看R1

如我们所见，RR在反射172.16.60.0/24这条BGP路由时，确实没有动（修改）任何的路由属性。

事实上，RR在反射路由时不修改其路由属性这个也不难理解，BGP路由中的每个PA都有其用处的，BGP路由器默认情况下当然不会加以改动了，改得不好万一出现环路了咋整？不信是吧，那笔者就拿个案例出来看看吧。

如上图所示，3台BGP路由器（R1、R2和R3）运行在ASN 123中，R3与R1和R2分别建立了IBGP会话（注意了，R3与R2之间并没有实际的物理链路相连），R1与R2之间建立IBGP会话。笔者将R1配置成R2的RR-CLIENT，因此，R1与R2就工作在CLUSTER 2中。

正常情况下，这种拓扑配置得当是不会出现路由环路的（最基础的BGP配置，笔者在此就不作相关配置展示了，各位小伙伴们可以自己搭环境观察一下各设备的BGP相关表项）。

本文的前面文字中不是说“RR在反射路由时不会修改其路由属性”吗，这是RR的默认行为，现笔者就来试着改变RR的这种默认行为，在R2这台RR上笔者将其反射给R1的关于172.16.30.0/24这条BGP路由的NEXT_HOP属性修改成R2自己的Gig0/0/0接口的物理IP地址12.1.1.2，配置如下：

按照上述配置在R2上做完之后，笔者想看一下R2上的BGP路由表，如下：

R1它选择了R2反射过来的那条路由作为最优路径，那数据包会不会走R2呢？笔者有些迫切想看一下R1上的关于172.16.30.0/24这条路由的最终出向（出接口），如下：

根据R1它路由表中的IBGP路由指示，因为IBGP路由的NEXT_HOP为R2（2.2.2.2），所以这个NEXT_HOP再递归一下很容易就找到了出接口Gig0/0/0，而Gig0/0/0物理直连R2，嘿嘿~

接着我们就可以观看环路上演了......

由此，环路便产生了，当然了，这个环路是笔者强行加在此拓扑中的，因为我们改变了R3（RR）在反射给其CLIENT（R2）关于172.16.30.0/24这条路由的NEXT_HOP属性，从而导致了路由环路。

通过上述案例，我们也见识（明白）了RR在反射路由时为什么不能修改其路由属性（当然，我们在打开“reflect change-path-attribute”开关之后可以通过工具人为修改PA，但是设备的默认行为不会）。

上述案例既然说到环路，那接下来我们就来聊聊在部署了路由反射器的环境中RR的环路避免机制吧。

我们知道，在AS与AS之间，BGP路由器依靠AS_PATH信息，可以很容易地检测到路由环路（生成路由更新的AS，其边界路由器会检查AS_PATH列表，丢弃试图重返本AS的路由更新）。

随着路由反射器的部署，在大型且有冗余路径的AS内也增大了AS内部路由环路的可能性。离开RR集群的路由更新，可能会重返该集群。由于BGP路由更新没有携带源AS_PATH签名，传统的AS_PATH己然没有办法检测到AS内部的路由环路。因此，在部署路由反射器时，BGP提供了2种额外的属性，用来防止AS内部的路由环路，这2种在RR环境中才有的属性分别是：ORIGINATOR_ID和CLUSTER_LIST。

接下来我们用案例来验证说明（这才是关键，对吧，哈哈）

我们所使用到的组网拓扑如上，6台BGP路由器运行在ASN 123中，其中3个RR（R3、R4和R5）相互连成一个倒三角，现笔者将R3配置成R4的RR-CLIENT，R5被配置成R3的RR-CLIENT，R4被配置成R5的RR-CLIENT（其它环境见组网拓扑上的标注）。

当R5从R6（R6为R5的RR-CLIENT）接收到前缀172.16.60.0/24后，它会向R3和R4反射该路由前缀。该路由前缀又被R4反射到R3。

好，我们现在将目光定焦在R3上，R3它现在去往172.16.60.0/24其BGP路由表中就会有两条路径：一条来自R5，另一条来自R4。

根据BGP路径决策进程，R3会优选Cluster list短的路径，R4通告过来的路由Cluster list为“4.4.4.4, 5.5.5.5”，R5通告过来的路由的Cluster list为“5.5.5.5”，很显然，R4通告的路由比不赢（not preferred for Cluster List），因此R3通过R5的路径是最佳路径，我们可以去R3上的BGP路由表中看看，如下：

现在笔者做个策略调整，改变R3的最佳路径选择条件

将R3上默认的Preferred-Value值被改成100让其优选R4（根据BGP路径决策进程，R3会优选具有更高的PV值的路径，因此通过R4的路径是最佳路径）。当策略生效之后，R3的BGP路由表中关于172.16.60.0/24这条路由的变化如下：

这会使R3撤回己发送给R4的路由并向R5和R1再通告新的最佳路径，因此R5从R3接收到和它之前通告给R4的相同的路由。由于没有环路防止机制（我们假设没有ORIGINATOR_ID和CLUSTER_LIST这2种AS内的BGP防环PA），这样R5接收了这条路由并把它安装到BGP-RIB中，如此，路由环路便产生了。笔者在R5上打开调试开关，方便各位能看到BGP路由器对路由的后台处理机制（“内心世界”）

调试命令所输出的信息讲得很清楚：

Error identified while receiving UPDATE message from the peer 3.3.3.3 and ignored//在接收R3通告过来的更新时因检测到了错误因而忽略掉了R3通告过来的此UPDATE，

Received CLUSTERLIST Value greater than allowed loop count of ClusterID of the speaker//忽略原因是我R5接收到的CLUSTERLIST值大于允许的BGP Cluster_ID的环数计数，这个loop count of ClusterID其实就是检测到了相同的Cluster_ID嘛

routes in update message need to be processed as withdrawn message due to reason mentioned above//那么由于上述原因，UPDATE消息中的路由需要作为撤回（withdrawn）消息进行处理。

基于此，在RR的环境中为了防止路由环路，我们的工程师们就专门设计构造了2个BGP路径属性：ORIGINATOR_ID和CLUSTER_LIST。

但是呢，其实上述笔者分析的这种环路是不会出现的，因为在RR部署环境中有“ORIGINATOR_ID”和“CLUSTER_LIST”这2种路径属性。

关于RR组网环境中的路由环路以及2个PA属性的话题我们就暂时聊到这吧，接下来的文字笔者应该会跟各位聊有关RR的组网设计方案相关的话题了。

在码字的过程中，难免会有一些小的笔误，如有，欢迎小伙伴们及时地提出来，便于笔者重新校对，纠正，感谢！

如果有什么学习上的疑问，可以在笔者的公众号中留言

也可以加笔者的个人WX帐号（ jacky_luojun）

-------------------------

ONE NETWORKS

开放 | 创新 | 协作 | 分享