概要文件0
概要文件1
概要文件3
在本文的此部分中，我们将探讨在覆盖网络中从PIM到BGP替换信令的选项。
如前所述（请参阅有关BGP自动发现的文章），为了传输PIM消息的类似物，在BGP中发明了几种类型的路由，每种路由都具有某些功能。此外，路由类型比PIM中的消息类型更多。
“为什么要在地球仪上放一只猫头鹰？” -您可能会问，因为PIM也可以正常工作。而且，总的来说，您将是正确的。这种骑士运动的主要原因是可伸缩性。PIM本质上是一种软驱动协议，需要对其操作不断发送服务消息，在一定的实现规模（如果节点数量开始超过数百或数千）的情况下，PIM由于不可避免的CPU负载而引入了限制。BGP是一种硬驱动协议-即 如果说过一次，则不再重复；任何BGP更新都是由于网络变化。
今天，我们将考虑两种情况：在C-VRF中使用PIM SSM和PIM ASM。
C-PIM SSM
为了更简单地了解用于构建组播树的BGP信令，让我们从一个更简单的PIM SSM开始对话。
首先，让我们删除集合点的当前设置并禁用流量接收者：
CE4(config)#interface Loopback0
CE4(config-if)#no ip igmp join-group 231.1.1.2
CE4(config-if)#
CE15(config)#no ip pim bsr-candidate Loopback0 0
CE15(config)#no ip pim rp-candidate Loopback0 group-list 1
在所有PE上，我们将指示BGP将代替PIM用于信令。这是通过以下命令完成的：
ip vrf C-ONE
mdt overlay use-bgp
观察的起点将是没有组播流量的源和接收者的情况。BGP表中仅应存在类型1路由：
PE1#show bgp ipv4 mvpn all
BGP table version is 406, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1.1.1.1:1 (default for vrf C-ONE)
*> [1][1.1.1.1:1][1.1.1.1]/12
0.0.0.0 32768 ?
*>i [1][1.1.1.1:1][2.2.2.2]/12
2.2.2.2 0 100 0 ?
*>i [1][1.1.1.1:1][3.3.3.3]/12
3.3.3.3 0 100 0 ?
*>i [1][1.1.1.1:1][4.4.4.4]/12
4.4.4.4 0 100 0 ?
Route Distinguisher: 2.2.2.2:1
*>i [1][2.2.2.2:1][2.2.2.2]/12
2.2.2.2 0 100 0 ?
Route Distinguisher: 3.3.3.3:1
Network Next Hop Metric LocPrf Weight Path
*>i [1][3.3.3.3:1][3.3.3.3]/12
3.3.3.3 0 100 0 ?
Route Distinguisher: 4.4.4.4:1
*>i [1][4.4.4.4:1][4.4.4.4]/12
4.4.4.4 0 100 0 ?
让我们连接收件人：
CE4(config-if)#ip igmp join 230.1.1.1 source 11.11.11.11
在最近的PE上，创建第7类BGP路由-这等效于PIM（S，G）Join消息：
PE4#show bgp ipv4 mvpn all
Route Distinguisher: 1.1.1.1:1
*> [7][1.1.1.1:1][65001][11.11.11.11/32][230.1.1.1/32]/22
0.0.0.0 32768 ?
从逻辑上讲，此路由应该仅出现在PE4和PE1上（因为流量应该通过它们），而不应该出现在PE2和PE3上。让我们检查：
PE1#show bgp ipv4 mvpn all | b \[7\]
*>i [7][1.1.1.1:1][65001][11.11.11.11/32][230.1.1.1/32]/22
4.4.4.4 0 100 0 ?
PE2#show bgp ipv4 mvpn all | b \[7\]
PE2#
PE3#show bgp ipv4 mvpn all | b \[7\]
PE3#
最初在PE4上生成的路由如何仅在PE1上导入？
让我们更详细地查看BGP表中的条目：
PE4#show bgp ipv4 mvpn all route-type 7 1.1.1.1:1 65001 11.11.11.11 230.1.1.1
BGP routing table entry for [7][1.1.1.1:1][65001][11.11.11.11/32][230.1.1.1/32]/22, version 533
Paths: (1 available, best #1, table MVPNv4-BGP-Table)
Advertised to update-groups:
7
Refresh Epoch 1
Local
0.0.0.0 from 0.0.0.0 (4.4.4.4)
Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best
Extended Community: RT:1.1.1.1:1
rx pathid: 1, tx pathid: 0x0
前缀条目包含扩展的团体Route-target = 1.1.1.1:1，该扩展团体由路由器添加到vpnv4前缀中，该路由器从PE4的角度是RPF邻居：
PE1#show bgp vpnv4 unicast rd 1.1.1.1:1 11.11.11.11/32
BGP routing table entry for 1.1.1.1:1:11.11.11.11/32, version 670
Paths: (1 available, best #1, table C-ONE)
Advertised to update-groups:
1 17
Refresh Epoch 4
65011
172.1.11.11 (via vrf C-ONE) from 172.1.11.11 (11.11.11.11)
Origin IGP, metric 0, localpref 100, valid, external, best
Extended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:1.1.1.1:1
mpls labels in/out 10018/nolabel
rx pathid: 0, tx pathid: 0x0
PE1#
PE2#show bgp vpnv4 unicast rd 2.2.2.2:1 11.11.11.11/32
BGP routing table entry for 2.2.2.2:1:11.11.11.11/32, version 762
Paths: (1 available, best #1, table C-ONE)
Advertised to update-groups:
1
Refresh Epoch 152
65011, imported path from 1.1.1.1:1:11.11.11.11/32 (global)
1.1.1.1 (metric 4) (via default) from 8.8.8.8 (8.8.8.8)
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:1.1.1.1:1
Originator: 1.1.1.1, Cluster list: 8.8.8.8
Connector Attribute: count=1
type 1 len 12 value 1.1.1.1:1:1.1.1.1
mpls labels in/out nolabel/10018
rx pathid: 0, tx pathid: 0x0
让我们检查连接性：
CE1#ping 230.1.1.1 so 11.11.11.11 rep 3
Type escape sequence to abort.
Sending 3, 100-byte ICMP Echos to 230.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 11.11.11.11
Reply to request 0 from 14.14.14.14, 7 ms
Reply to request 0 from 14.14.14.14, 8 ms
Reply to request 1 from 14.14.14.14, 7 ms
Reply to request 1 from 14.14.14.14, 9 ms
Reply to request 2 from 14.14.14.14, 7 ms
Reply to request 2 from 14.14.14.14, 7 ms
C-PIM ASM
对于SSM模式下的C-PIM，一切都非常简单。为了使mVPN正常工作，创建两个其他（类型）BGP路由就足够了。
但是，如果在C-VRF中使用更复杂的ASM PIM，该怎么办？
首先，我们看到所有CE都知道有关集合点的信息：
CE2#show ip pim rp mapp
CE2#show ip pim rp mapping
Auto-RP is not enabled
PIM Group-to-RP Mappings
Group(s) 231.1.1.0/24
RP 15.15.15.15 (?), v2
Info source: 15.15.15.15 (?), via bootstrap, priority 0, holdtime 150
Uptime: 1d04h, expires: 00:02:09
CE2#
怎么样？如果我们查看BGP表，则在此处找不到任何提示：
PE1#show bgp ipv4 mvpn all
BGP table version is 682, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-compressed,
t secondary path,
Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1.1.1.1:1 (default for vrf C-ONE)
*> [1][1.1.1.1:1][1.1.1.1]/12
0.0.0.0 32768 ?
*>i [1][1.1.1.1:1][2.2.2.2]/12
2.2.2.2 0 100 0 ?
*>i [1][1.1.1.1:1][3.3.3.3]/12
3.3.3.3 0 100 0 ?
*>i [1][1.1.1.1:1][4.4.4.4]/12
4.4.4.4 0 100 0 ?
Route Distinguisher: 2.2.2.2:1
*>i [1][2.2.2.2:1][2.2.2.2]/12
2.2.2.2 0 100 0 ?
Route Distinguisher: 3.3.3.3:1
Network Next Hop Metric LocPrf Weight Path
*>i [1][3.3.3.3:1][3.3.3.3]/12
3.3.3.3 0 100 0 ?
Route Distinguisher: 4.4.4.4:1
*>i [1][4.4.4.4:1][4.4.4.4]/12
4.4.4.4 0 100 0 ?
不要忘记我们已经激活了PIM的PMSTI：
PE1#show ip pim vrf C-ONE interface
Address Interface Ver/ Nbr Query DR DR
Mode Count Intvl Prior
172.1.11.1 GigabitEthernet2.111 v2/S 1 30 1 172.1.11.11
172.1.15.1 GigabitEthernet2.115 v2/S 1 30 1 172.1.15.15
1.1.1.1 Tunnel2 v2/S 0 30 1 1.1.1.1
由此可以得出一个重要的结论-一些PIM消息（甚至带有BGP信令）也在默认MDT框架内通过骨干网传输。
想象一下一个源出现在网络上（在CE2路由器后面）。由于当前在CE2上没有mRIB条目，因此PIM指定路由器（在我们的示例中是CE2本身）将注册消息发送到集合点，从而发出网络中活动源存在的信号。
在集合点（12.12.12.12，231.1.1.1）创建一棵树：
CE5#show ip mroute | b \(
(*, 231.1.1.1), 00:00:19/stopped, RP 15.15.15.15, flags: SP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null
(12.12.12.12, 231.1.1.1), 00:00:19/00:02:40, flags: P
Incoming interface: GigabitEthernet2.115, RPF nbr 172.1.15.1
Outgoing interface list: Null
并且，由于网络上没有活动的流量接收者（没有树（*，231.1.1.1）），因此从CE5端生成了Register-Stop消息。
响应接收到Register-Stop，CE2暂停数据传输（OIL中没有接口）：
CE2#show ip mroute 231.1.1.1
(12.12.12.12, 231.1.1.1), 00:00:07/00:02:54, flags: PFT
Incoming interface: Loopback0, RPF nbr 0.0.0.0
Outgoing interface list: Null
现在，假设网络上有一个对231.1.1.1组的流量感兴趣的接收器。在PE4上，一条路由出现在C-VRF内部：
PE4#show ip mroute vrf C-ONE 231.1.1.1 | b \(
(*, 231.1.1.1), 00:00:44/00:02:45, RP 15.15.15.15, flags: Sg
Incoming interface: Tunnel0, RPF nbr 1.1.1.1
Outgoing interface list:
GigabitEthernet2.414, Forward/Sparse, 00:00:44/00:02:45
并创建了第六种类型的BGP路由，它等效于PIM Join（*，231.1.1.1）：
PE4#show bgp ipv4 mvpn all
Route Distinguisher: 1.1.1.1:1
*> [6][1.1.1.1:1][65001][15.15.15.15/32][231.1.1.1/32]/22
0.0.0.0 32768 ?
PE4#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 231.1.1.1
BGP routing table entry for [6][1.1.1.1:1][65001][15.15.15.15/32][231.1.1.1/32]/22, version 808
Paths: (1 available, best #1, table MVPNv4-BGP-Table)
Advertised to update-groups:
8
Refresh Epoch 1
Local
0.0.0.0 from 0.0.0.0 (4.4.4.4)
Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best
Extended Community: RT:1.1.1.1:1
rx pathid: 1, tx pathid: 0x0
在以上输出中，您需要注意扩展社区Route-target = 1.1.1.1:1。它是什么？它是从哪里来的？
让我们检查其他PE上是否存在此前缀：
PE2#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 231.1.1.1
% Network not in table
PE3#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 231.1.1.1
% Network not in table
PE1#show bgp ipv4 mvpn all route-type 6 1.1.1.1:1 65001 15.15.15.15 231.1.1.1
BGP routing table entry for [6][1.1.1.1:1][65001][15.15.15.15/32][231.1.1.1/32]/22, version 698
Paths: (1 available, best #1, table MVPNv4-BGP-Table)
Not advertised to any peer
Refresh Epoch 2
Local
4.4.4.4 (metric 3) from 8.8.8.8 (8.8.8.8)
Origin incomplete, metric 0, localpref 100, valid, internal, best
Extended Community: RT:1.1.1.1:1
Originator: 4.4.4.4, Cluster list: 8.8.8.8
rx pathid: 0, tx pathid: 0x0
那些。该前缀仅存在于PE1上。有趣的是，集合点（15.15.15.15）恰好位于PE1后面的位置。
知道了路由目标的目的（将路由导入到特定的VRF中），结论表明自身-RT = 1.1.1.1:1对PE1是已知的，对PE2 / PE3是未知的。也就是说，很明显，PE4生成了描述PIM共享树连接的BGP路由，使得它仅在会合点实际位于其后的PE上进行处理（实际上，这是通过RPF接口传输PIM Join的类似物）。但是，PE1和PE4如何协调路由目标值？
PE4对集合点地址进行RPF：
PE4#show ip rpf vrf C-ONE 15.15.15.15
RPF information for ? (15.15.15.15)
RPF interface: Tunnel0
RPF neighbor: ? (1.1.1.1)
RPF route/mask: 15.15.15.15/32
RPF type: unicast (bgp 65001)
Doing distance-preferred lookups across tables
BGP originator: 1.1.1.1
RPF topology: ipv4 multicast base, originated from ipv4 unicast base
PE1被视为RPF邻居。这意味着PE4必须在仅PE1会导入的Type 6路由中放置一个路由目标。要回答“ PE4怎么知道？”这个问题。-让我们首先了解一下vpn路由：
PE4#show bgp vpnv4 unicast vrf C-ONE 15.15.15.15/32
BGP routing table entry for 4.4.4.4:1:15.15.15.15/32, version 859
Paths: (1 available, best #1, table C-ONE)
Advertised to update-groups:
1
Refresh Epoch 1
65015, imported path from 1.1.1.1:1:15.15.15.15/32 (global)
1.1.1.1 (metric 3) (via default) from 8.8.8.8 (8.8.8.8)
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:1.1.1.1:1
Originator: 1.1.1.1, Cluster list: 8.8.8.8
Connector Attribute: count=1
type 1 len 12 value 1.1.1.1:1:1.1.1.1
mpls labels in/out nolabel/10013
rx pathid: 0, tx pathid: 0x0
请注意其他MVPN VRF社区：1.1.1.1：1。这不过是PE1生成的“路由导入”社区。将此值复制为多播路由内的路由目标，从而允许PE1从PE4导入接收的更新。
在PE4上处理BGP路由类型6的结果是在多播路由表中创建了一个条目：
PE4#show ip mroute vrf C-ONE
(*, 231.1.1.1), 00:23:31/00:02:33, RP 15.15.15.15, flags: Sg
Incoming interface: Tunnel0, RPF nbr 1.1.1.1
Outgoing interface list:
GigabitEthernet2.414, Forward/Sparse, 00:23:31/00:02:33
注-请注意，将Tunnel0（PMSTI）指定为输入接口。
在集合点，完成了公共树的创建：
CE5#show ip mroute | b \(
(*, 231.1.1.1), 00:25:42/00:03:22, RP 15.15.15.15, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet2.115, Forward/Sparse, 00:25:42/00:03:22
现在，如果活动的流量源再次出现在网络上，则集合点将知道如何“合并”（*，231.1.1.1）和（12.12.12.12，231.1.1.1）树。
CE5#show ip mroute | b \(
(*, 231.1.1.1), 00:47:12/stopped, RP 15.15.15.15, flags: S
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet2.115, Forward/Sparse, 00:47:12/00:02:31
(12.12.12.12, 231.1.1.1), 00:00:23/00:02:43, flags: PT
Incoming interface: GigabitEthernet2.115, RPF nbr 172.1.15.1
Outgoing interface list: Null
集合点创建一个PIM Join（12.12.12.12，231.1.1.1），并将其发送到CE2。PE1收到指定的PIM Join并创建第7种BGP路由：
PE1#show bgp ipv4 mvpn all
Route Distinguisher: 2.2.2.2:1
*> [7][2.2.2.2:1][65001][12.12.12.12/32][231.1.1.1/32]/22
0.0.0.0 32768 ?
PE1#show bgp ipv4 mvpn all route-type 7 2.2.2.2:1 65001 12.12.12.12 231.1.1.1
BGP routing table entry for [7][2.2.2.2:1][65001][12.12.12.12/32][231.1.1.1/32]/22, version 726
Paths: (1 available, best #1, table MVPNv4-BGP-Table)
Advertised to update-groups:
8
Refresh Epoch 1
Local
0.0.0.0 from 0.0.0.0 (1.1.1.1)
Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best
Extended Community: RT:2.2.2.2:1
rx pathid: 1, tx pathid: 0x0
请注意，远程VPN RD值设置为2.2.2.2:1，因为 通过PE2完成路由的RPF检查：
PE1#show ip rpf vrf C-ONE 12.12.12.12
RPF information for ? (12.12.12.12)
RPF interface: Tunnel2
RPF neighbor: ? (2.2.2.2)
RPF route/mask: 12.12.12.12/32
RPF type: unicast (bgp 65001)
Doing distance-preferred lookups across tables
BGP originator: 2.2.2.2
RPF topology: ipv4 multicast base, originated from ipv4 unicast base
RT 2.2.2.2:1已从PE2端添加到VPNv4前缀：
PE1#show bgp vpnv4 unicast vrf C-ONE 12.12.12.12
BGP routing table entry for 1.1.1.1:1:12.12.12.12/32, version 706
Paths: (1 available, best #1, table C-ONE)
Advertised to update-groups:
1
Refresh Epoch 2
65012, imported path from 2.2.2.2:1:12.12.12.12/32 (global)
2.2.2.2 (metric 4) (via default) from 8.8.8.8 (8.8.8.8)
Origin IGP, metric 0, localpref 100, valid, internal, best
Extended Community: RT:65001:1 MVPN AS:65001:0.0.0.0 MVPN VRF:2.2.2.2:1
Originator: 2.2.2.2, Cluster list: 8.8.8.8
Connector Attribute: count=1
type 1 len 12 value 2.2.2.2:1:2.2.2.2
mpls labels in/out nolabel/31
rx pathid: 0, tx pathid: 0x0
实际上，此步骤完成了在源和集合点之间的部分中树的构造（12.12.12.12、231.1.1.1）：
在接收到第7类路由后，PE2生成第5类路由，表示网络上存在活动流量源。路由由所有PE设备导入。
PE2#show bgp ipv4 mvpn all
Route Distinguisher: 2.2.2.2:1 (default for vrf C-ONE)
*> [5][2.2.2.2:1][12.12.12.12][231.1.1.1]/18
0.0.0.0 32768 ?
PE2#show bgp ipv4 mvpn all route-type 5 12.12.12.12 231.1.1.1
BGP routing table entry for [5][2.2.2.2:1][12.12.12.12][231.1.1.1]/18, version 838
Paths: (1 available, best #1, table MVPNv4-BGP-Table, not advertised to EBGP peer)
Advertised to update-groups:
8
Refresh Epoch 1
Local
0.0.0.0 from 0.0.0.0 (2.2.2.2)
Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best
Community: no-export
Extended Community: RT:65001:1
rx pathid: 0, tx pathid: 0x0
接收到路由类型5时，在接收者所在的PE4上完成多播树的创建：
PE4#show ip mroute vrf C-ONE
(12.12.12.12, 231.1.1.1), 00:22:24/00:02:51, flags: TnQ
Incoming interface: Tunnel0, RPF nbr 2.2.2.2
Outgoing interface list:
GigabitEthernet2.414, Forward/Sparse, 00:22:24/00:03:19
注-注意Q标志，该标志表示该条目是由于BGP Source-Active消息而创建的
所考虑的mVPN组织的变体的代号为“配置文件11”。其主要特点：
- 要将多播流量传输到覆盖网络，则使用默认MDT
- mGRE协议用作传输组织方法
- BGP协议用于在所施加的网络内向多播树发出信号