MPLS VPN

MPLS VPN中部署组播的基本原理是在PE上将客户VPN中的组播数据通过GRE封装起来，通过运营商MPLS BACKBONE上的组播网络转发到其他的PE。运营商和客户的组播是分离的，互不知情。二者通过PE上的隧道接口MTI实现转接。

下面用一个实验来解释相关的概念和部署方法。看本实验的读者应该拥有mpls 和pim sm的相关知识，不然先去补课。

实验拓扑如下：

R1、R6、R8为CE，R2、R5、R7为PE，R3、R4为P。路由器之间的连接全部使用快速以太网子接口，如r1和r2间连接使用f0/0.12，ip地址为12.0.0.1/24和12.0.0.2/24，r2、r3间连接使用f0/0.23，ip地址为23.0.0.2/24和23.0.0.3/24。各自Loopback 0的地址为路由器号，即1.1.1.1、2.2.2.2等。Mpls 已建好，共3个站点。

此主题相关图片如下：

按此查看图片详细信息

第一部分：实施步骤

因为运营商网络和客户网络的组播分离，我们先在BACKBONE和VPN中分别部署自己的组播协议。

一、在运营商BACKBONE中启用组播，使用pim sparse-mode。为简化配置，使用静态Rp，地址是r4的loopback 0地址4.4.4.4。

在r2、r3、r4、r5和r7上作如下配置：

ip multicast-routing （全局启用组播路由）

ip pim rp-address 4.4.4.4 （手工指定rp）

int f0/0.23 （在接口上启用pim sm，P网内所 ip pim sparse-mode 有互连接口都要启用）

在R4上查看： show ip mroute

可以看到组播路由表已经有了，里面有一个条目(*, 224.0.1.40)，这是cisco的auto-rp用来发现rp用的，不用去管它。

二、在站点内启用组播，使用pim sparse-mode。Rp是r1的loopback 0地址1.1.1.1。 在r1、r6、r8上作如下配置： ip multicast-routing ip pim rp-address 1.1.1.1

int f0/0.12 （在ce和pe连接的接口启用pim sm） ip pim sparse-mode

三、在PE的VRF中启用组播，这一步是常规的组播中没有的。Vrf中启用组播后，就成为了mVRF。

在R2、R5、R7上配置：

ip multicast-routing vrf abc （vrf中启用组播）

ip pim vrf abc rp-address 1.1.1.1 （指定vrf的rp地址，跟ce一致） interface FastEthernet0/0.12 （连接ce的接口上启用pim sm） encapsulation dot1Q 12 ip vrf forwarding abc

ip address 12.0.0.2 255.255.255.0 ip pim sparse-mode

ip vrf abc

rd 100:1 route-target export 100:1 route-target import 100:1

mdt default 239.100.0.1 (指定缺省mdt使用的组地址，最好为239网段) int lo 0

ip pim sparse-mode （在所有PE的loopback0口启用pim sm）

四、至此，M应该就已经算完成了。下面我们来验证一下。 以R8作为接收者，R1作为组播源看看能不能通组播。在R8上配置： int lo0

ip pim sparse-mode （作为接收者的接口一定要启用pim sm） ip igmp join-group 238.0.0.1 (加入组238.0.0.1)

在r1上ping 238.0.0.1可通

r1#ping 238.0.0.1

Type escape sequence to abort.

Sending 1, 100-byte ICMP Echos to 238.0.0.1, timeout is 2 seconds:

Reply to request 0 from 78.0.0.8, 520 ms Reply to request 0 from 78.0.0.8, 520 ms

因为R1上的f0/0.12和loopback0都启用了pim sm，所以这两个ip地址都发出了icmp 包，收到2个回应。

再以R6为源试试看：

r6#ping 238.0.0.1 Type escape sequence to abort. Sending 1, 100-byte ICMP Echos to 238.0.0.1, timeout is 2 seconds:

Reply to request 0 from 78.0.0.8, 304 ms

也通了。R6上只有f0/0.56接口启用了pim sm，所以只发了1个icmp包。

第二部分：技术讲解

实验已经做通了，但其中的技术细节还要仔细研究一下。整个mVPN的运作以及结构是怎样的呢。下面来说说。

一、MTI和default MDT

在配置过程中，对PE的配置有两点是需要关注的，一是在loopback0上启用了pim sm，二是在vrf中配置了mdt default 239.100.0.1。

以PE R7为例，在没有配置上面两条命令之前，其pim邻居是这样的： 一种是P网络全局pim邻居

r7#sh ip pim nei PIM Neighbor Table

Neighbor Interface Uptime/Expires Ver DR Address Prio/Mode 37.0.0.3 FastEthernet0/0.37 00:52:49/00:01:39 v2 1 / S 47.0.0.4 FastEthernet0/0.47 00:52:49/00:01:40 v2 1 / S

另一种是客户VPN内pim邻居

r7#sh ip pim vrf abc nei PIM Neighbor Table

Neighbor Interface Uptime/Expires Ver DR Address Prio/Mode 78.0.0.8 FastEthernet0/0.78 00:52:45/00:01:44 v2 1 / DR S

一旦敲入了mdt default 239.100.0.1，R7上马上就会出现信息：

*Mar 1 00:56:52.547: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up

生成了一个tunnel 0接口，ip 地址使用的是loopback0的地址7.7.7.7。这个tunnel接口叫做MTI（multicast tunnel interface），位于VRF中。

看一下tunnel0的资料： r7#sh int tun 0

Tunnel0 is up, line protocol is up Hardware is Tunnel Interface is unnumbered. Using address of Loopback0 (7.7.7.7)

MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation TUNNEL, loopback not set Keepalive not set

Tunnel source 7.7.7.7 (Loopback0), destination 239.100.0.1

Tunnel protocol/transport GRE/IP Multicast, key disabled, sequencing disabled

显示这个tunnel是GRE tunnel，传送ip组播数据。 然后再敲入

r7(config)#int lo0

ip pim sparse-mode

（这个loopback0是MP-iBGP建邻居所用的地址，所以要启用PIM SM，而且它将成为MDT的根） 出现信息如下:

*Mar 1 01:02:33.791: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 7.7.7.7 on interface Loopback0 (vrf default)

*Mar 1 01:02:45.7: %PIM-5-NBRCHG: neighbor 5.5.5.5 UP on interface Tunnel0 (vrf abc) *Mar 1 01:02:45.975: %PIM-5-NBRCHG: neighbor 2.2.2.2 UP on interface Tunnel0 (vrf abc)

R7跟其他PE建立了pim邻居，使用的是MTI接口，即3个pe以MTI建成了邻居。 r7#sh ip pim vrf abc nei PIM Neighbor Table

Neighbor Interface Uptime/Expires Ver DR Address Prio/Mode 78.0.0.8 FastEthernet0/0.78 01:07:08/00:01:36 v2 1 / DR S 2.2.2.2 Tunnel0 00:04:33/00:01:37 v2 1 / S 5.5.5.5 Tunnel0 00:04:33/00:01:38 v2 1 / S

在R2上看：

r2#sh ip pim vrf abc nei PIM Neighbor Table

Neighbor Interface Uptime/Expires Ver DR

Address Prio/Mode 12.0.0.1 FastEthernet0/0.12 01:09:37/00:01:32 v2 1 / S 7.7.7.7 Tunnel0 00:06:29/00:01:39 v2 1 / DR S 5.5.5.5 Tunnel0 01:08:21/00:01:40 v2 1 / S

显示R7的tunnel0是DR。这是因为3个MTI相当于连接到了1个共享网段上，就像在一个以太网内，所以要选举DR。

MTI很关键，它是客户的pim和运营商P网络的PIM交互的中介。 此主题相关图片如下：

按此查看图片详细信息

如图，现在整网的pim邻居有这么三种。

我们现在来查看运营商的P路由器R4上的组播路由状态：

r4#sh ip mro

IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry,

X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,

U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel Y - Joined MDT-data group, y - Sending to MDT-data group Outgoing interface flags: H - Hardware switched, A - Assert winner Timers: Uptime/Expires

Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 239.100.0.1), 01:28:04/00:03:03, RP 4.4.4.4, flags: S Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list:

FastEthernet0/0.47, Forward/Sparse, 00:26:11/00:02:50 FastEthernet0/0.45, Forward/Sparse, 01:28:03/00:03:03 FastEthernet0/0.34, Forward/Sparse, 01:28:04/00:02:56

(2.2.2.2, 239.100.0.1), 01:27:49/00:03:23, flags: T Incoming interface: FastEthernet0/0.34, RPF nbr 34.0.0.3 Outgoing interface list:

FastEthernet0/0.45, Forward/Sparse, 01:27:49/00:03:03

(5.5.5.5, 239.100.0.1), 01:27:50/00:03:13, flags: T Incoming interface: FastEthernet0/0.45, RPF nbr 45.0.0.5 Outgoing interface list:

FastEthernet0/0.47, Forward/Sparse, 00:26:11/00:02:50 FastEthernet0/0.34, Forward/Sparse, 01:27:50/00:02:55

(7.7.7.7, 239.100.0.1), 00:31:52/00:03:12, flags: T Incoming interface: FastEthernet0/0.47, RPF nbr 47.0.0.7 Outgoing interface list:

FastEthernet0/0.45, Forward/Sparse, 00:31:52/00:03:02

(*, 224.0.1.40), 01:29:00/00:03:07, RP 4.4.4.4, flags: SJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list:

FastEthernet0/0.47, Forward/Sparse, 01:27:40/00:02:38 FastEthernet0/0.45, Forward/Sparse, 01:28:04/00:03:07 FastEthernet0/0.34, Forward/Sparse, 01:28:05/00:03:04 Loopback0, Forward/Sparse, 01:29:00/00:02:01

比前面所见多了4个条目，1个（*，G）和3个（S，G），分别是(*, 239.100.0.1)，(2.2.2.2, 239.100.0.1)，(5.5.5.5, 239.100.0.1)，(7.7.7.7, 239.100.0.1)。

这里的G正是前面在vrf中配置的MDT default 239.100.0.1。MDT全称是multicast distribution tree，即组播分发树。

配置239.100.0.1这个default MDT虽然是在vrf中，但是是给运营商P网络中的组播路由器来用的。P网络用这个组地址建成了1个全互连的通道供的组播使用。不管客户网络内有多少组播源和组

地址，运营商网络并不关心，也不需要知道，它只使用这一个缺省的组播分发树来转发客户组播数据。 此主题相关图片如下：

按此查看图片详细信息

所有的站点都加入到这棵树中，他们互为发送者和接收者，即既为根（root）又为叶(leaf)。

二、MP-iBGP的组播更新包

PE加入default MDT靠的是MP-iBGP消息，配置了default MDT后他们之间互发MP-iBGP更新，这种更新包与常规v4的路由更新有所不同。 r7# sh ip bgp v a

BGP table version is 24, local router ID is 7.7.7.7

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path Route Distinguisher: 100:1 (default for vrf abc)

*>i1.1.1.1/32 2.2.2.2 2 100 0 ? *>i6.6.6.6/32 5.5.5.5 2 100 0 ? *> 8.8.8.8/32 78.0.0.8 2 32768 ? *>i12.0.0.0/24 2.2.2.2 0 100 0 ? *>i56.0.0.0/24 5.5.5.5 0 100 0 ? *> 78.0.0.0/24 0.0.0.0 0 32768 ? Route Distinguisher: 2:100:1

*>i2.2.2.2/32 2.2.2.2 0 100 0 ? *>i5.5.5.5/32 5.5.5.5 0 100 0 ? *> 7.7.7.7/32 0.0.0.0 0 ?

MDT的mp-ibgp更新的RD是2:100:1而不是单播v4路由更新的100:1。这个2代表RD类型2，区别于单播v4路由的RD。而且，这种更新携带了一些别的扩展community属性。

r7# sh ip bgp v a 5.5.5.5

BGP routing table entry for 2:100:1:5.5.5.5/32, version 20

Paths: (1 available, best #1, no table, not advertised to EBGP peer) Not advertised to any peer Local

5.5.5.5 (metric 3) from 5.5.5.5 (5.5.5.5)

Origin incomplete, metric 0, localpref 100, valid, internal, mdt, no-import, best Extended Community: RT:100:1 MDT:100:239.100.0.1, mpls labels in/out nolabel/511 可以看到里面有MDT的信息。

三、端到端组播数据包转发分析：

现在以R1为源，R8为接收者分析全程组播包的转发。 1、R1 ping 238.0.0.1，包到达R2的mvrf 2、R2的mvrf中的组播路由表如下： r2#sh ip mro vrf abc

(1.1.1.1, 238.0.0.1), 00:00:08/00:03:21, flags: Incoming interface: FastEthernet0/0.12, RPF nbr 12.0.0.1

Outgoing interface list:

Tunnel0, Forward/Sparse, 00:00:08/00:03:21

出接口为tunnel0。于是MTI用GRE将组播包封装起来，源地址改为2.2.2.2，目的地址为239.100.0.1。现在要从vrf中出到全局中去了。

r2#sh ip mro

(2.2.2.2, 239.100.0.1), 02:50:31/00:03:14, flags: FTZ Incoming interface: Loopback0, RPF nbr 0.0.0.0 Outgoing interface list:

FastEthernet0/0.23, Forward/Sparse, 02:50:31/00:02:50

根据全局组播路由表，出接口为f0/0.23，送出。R3收到。

3、R3的全局组播路由表如下 r3#sh ip mro

(2.2.2.2, 239.100.0.1), 02:49:13/00:03:02, flags: T Incoming interface: FastEthernet0/0.23, RPF nbr 23.0.0.2

Outgoing interface list:

FastEthernet0/0.37, Forward/Sparse, 01:47:35/00:03:04 FastEthernet0/0.34, Forward/Sparse, 02:49:13/00:03:28, A 将包复制两份，分别从f0/0.37和f0/0.34送出，R7和R4收到。

4、R7的全局组播路由表如下 r7#sh ip mro

(2.2.2.2, 239.100.0.1), 01:59:49/00:02:57, flags: JTZ Incoming interface: FastEthernet0/0.37, RPF nbr 37.0.0.3 Outgoing interface list:

MVRF abc, Forward/Sparse, 01:54:09/00:02:57 出接口为mvrf，于是被送入vrf中。 R7的mvrf的组播路由表如下：

r7#sh ip mro vrf abc

(1.1.1.1, 238.0.0.1), 00:01:38/00:01:51, flags: Incoming interface: Tunnel0, RPF nbr 2.2.2.2 Outgoing interface list:

FastEthernet0/0.78, Forward/Sparse, 00:01:38/00:03:19 出接口为f0/0.78，送出。R8收到，到终点站。

4、另一路R4收到的包会被R5抛弃，因为R5的mvrf中无出口。 r5#sh ip mro vrf abc

(*, 238.0.0.1), 00:00:15/00:02:47, RP 1.1.1.1, flags: SP Incoming interface: Tunnel0, RPF nbr 2.2.2.2 Outgoing interface list: Null

第三部分 M的优化

至此，实验算完成了。但还有一些技术可以用来对此试验进行优化。主要有两个方面：一是使用双向树减少P网络中的组播路由表条目，二是使用data MDT减少不必要的组播数据转发。

1、使用双向树

前面看到，P网络中的路由器的组播路由表中为1个default MDT生成了4个条目，1个（*，G）和3个（S，G）。有几个站点就有几个（S，G）。当站点多的时候路由器的组播路由条目也相应的多。既然default MDT是全互连的且PE互为根叶，那么就可以用双向树来减少路由条目。

在所有P和PE上配置： ip pim bidir-enable ip pim rp-add 4.4.4.4 bidir

在Rp所在的接口，即R4的loopback0口启用ip pim sparse-mode。

然后再看P和PE路由器的组播路由表就会看到(S，G)条目已经没有了，只有（*，239.100.0.1）存在。

2、使用data MDT

default MDT类似于广播网络，一个源发出的流量会被发给所有其他PE，而不管那个PE后面有没有接

收者。这样就造成了资源浪费。

例如，当r1 ping238.0.0.1时，r8作为接收者收到了ping包，而R5背后的站点里没有接收者，但R5仍然收到ping包。这一点可以用r5#debug ip mpacket看到。

解决之道是data MDT（华为称之为switch-MDT）。当流量速率超过某个阈值的时候，一个新的组播分发树被建立起来，只有有接收者的PE才加入这个树。流量不再从default MDT上走，切换到这个新树上。没有接收者的PE不加入这棵树，所以收不到流量。

Data MDT上只跑数据，所有组播控制信息还是走在default MDT上。

另外，data MDT是由mvrf中的(S，G)条目触发的，如果中使用了双向树，则data MDT不可用，一切都走default MDT。

配置比较简单，在PE的vrf中输入 ip vrf abc

mdt data 239.100.0.15 0.0.0.31 threshold x 即可。239.100.0.15 0.0.0.31是个地址池，供建新树使用。X是阈值速率。

关于mVPN的参考资料较少，只有MPLS and VPN Architectures, Volume II讲得比较详细，再有就是只能上cisco的网站上去查了。希望这篇试验能给技术同行们一点帮助。