MPLS OptionC 带与不带RR 原来如此简单（一）

Guibin啊
115 阅读3分钟

最近被 MPLS VPN Option C 方案一 带/不带RR 的场景有点混乱，

于是，我打算整理下，这两者之间的区别，与异同详细分析

MPLS VPN OptionC 方案一 文档链接
https://support.huawei.com/hedex/hdx.do?docid=EDOC1100021764&id=dc_cfg_l3vpn_0157

MPLS VPN Option C 方案一基本 配置思路

image.png

简单来说就是

image.png

    1.AS 内 的 PE 与 ASBE 之间 建立 MP-IBGP 

    2.AS 间 的 PE 建立 MP-EBGP 关系

    3.ASBR 间建立 EBGP 关系

而 带 RR 的 MPLS VPN Option C 方案一建立基本思路框架

image.png

    1.PE 与 RR 与 ASBR 建立 MP-IBGP

    2.RR 之间 建立 MP-EBGP

    3.ASBR 之间建立 EBGP

区别：

image.png

看完后是不是豁然开朗，

image.png

这之间的关系，

带上 RR 的场景，并不吓人，

只是 RR 代替PE 来与对端建立 MP-EBGP 关系

那，有个问题，为什么要这么做呢？

image.png

那我们来分析一下这之间的原因吧 首先，我们得先了解MPLS VPN OptionC 方案一的基本工作原理

image.png

现在我们有个

image.png

源：9.9.9.9的要访问 10.10.10.10

于是我们从 AR9-1 出发，

当报文到达 AR1-1 时候，AR1-1 在该接口g0/0/0 收到的数据包，

发现该接口的报文属于 vpn A

image.png

于是根据目的地址 10.10.10.10/32，

查找 VRF A（Virtual Routing Forwarding table，虚拟路由转发表）看下该怎么转发

image.png

我们发现10.10.10.10/32 这条路由是通过 EBGP 协议学习到的，下一跳是6.6.6.6

我们在细看看这条路由

image.png

发现该路由打上了一层 1027的私网标签

image.png

然后，通过路由迭代，我们查找下 6.6.6.6 是从哪里来的，怎么去到6.6.6.6呢？

image.png

image.png

我们通过该路由表就可以知道我们的6.6.6.6 下一跳是 3.3.3.3，通过IBGP协议学到的

好，那我们去细看一下

image.png

哦，我们发现路由迭代到6.6.6.6 时，又打上了一层标签 1027

image.png

那我们再往下看看

image.png

哎，3.3.3.3/32 又要走隧道 0x3

再看看，再看看

image.png

迭代到这（3.3.3.3/32），我们的路由又被打上了一层标签1025

image.png

它还告诉我们，下一跳找10.1.12.2 ，出接口是 g0/0/1

哎，终于没了吧，标签怪

image.png

此时

image.png

根据标签转发表NHLFE到了 AR3

image.png

拆掉（pop）最外层标签后，根据下一层标签1027 swap为 1025

此时

image.png

到了对面(AS200)

AR4收到后，发现是标签转发，于是

image.png

发现标签转发，于是拆掉1025标签，并打上1025标签

image.png

发现还有标签，再查

到了AR5，不再赘述（同AR1到AR2，同理）

然后，秃头啦

image.png

image.png

然后AR6发现要找 10.10.10.10/32 于是查找VRF

image.png

原来下一跳是10.1.22.10，直接发给g0/0/01口就好啦

就这样AR10 收到了来自AR9 的数据包

image.png

真是老乡见老乡啊

image.png

这就是MPLS VPN OptionC 方案一的访问基本原理啦

下一期我们再继续聊，带RR 与不带RR 的区别

原文： MPLS OptionC 带与不带RR 原来如此简单（一）

image.png

avatar
文章
阅读
粉丝