プロファイル0
プロファイル1
プロファイル3
記事のこの部分では、オーバーレイネットワーク内のシグナリングをPIMからBGPに置き換えるオプションについて説明します。
前に説明したように（BGP自動検出に関する記事を参照）、PIMメッセージの類似物を送信するために、BGPでいくつかのタイプのルートが発明され、それぞれが特定の機能を備えています。さらに、PIMのメッセージタイプよりも多くのルートタイプがあります。
「なぜフクロウを地球に置くのですか？」-すべてがPIMでもうまく機能するので、あなたは尋ねるかもしれません。そして、一般的に、あなたは正しいでしょう。そのような騎士の動きの主な理由は拡張性です。PIMは、本質的にソフトドリブンプロトコルであるため、その作業のためにサービスメッセージを定期的にメールで送信する必要があります。これは、特定のサイズの実装（ノードの数が数百または数千を超え始めた場合）では、CPUの必然的な負荷のために制限が発生します。BGPはハードドライブプロトコルです-つまり 何かが一度言われたとしても、それは繰り返されません。BGPの更新は、ネットワークの変更のみによるものです。
今日は、C-VRF内でPIMSSMとPIMASMを使用するという2つのシナリオを検討します。
C-PIM SSM
マルチキャストツリーを構築するためのBGPシグナリングをより簡単に理解するために、より単純なPIMSSMから会話を始めましょう。
まず、ランデブーポイントの現在の設定を削除して、トラフィックの受信者を無効にします。
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
観察の出発点は、マルチキャストトラフィックの送信元と受信者が存在しない状況です。タイプ1ルートのみがBGPテーブルに存在する必要があります。
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）参加メッセージと同等です。
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が含まれています。これは、PE4のポイントからのRPFネイバーであるルーターによってvpnv4プレフィックスに追加されました。
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が正しく機能するには、2つの追加（タイプ）BGPルートを作成するだけで十分です。
しかし、より複雑なASMPIMがC-VRF内で使用されている場合はどうなるでしょうか。
まず、すべての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
そして、6番目のタイプのBGPルートが作成されます。これは、PIM結合（*、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結合送信の類似物です）。しかし、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のみがインポートするタイプ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
追加のMVPNVRFコミュニティに注意してください：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結合（12.12.12.12、231.1.1.1）を作成し、CE2に送信します。PE1は、指定されたPIM参加を受信し、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
リモートVPNRD値は2.2.2.2：1に設定されていることに注意してください。ルートのRPFチェックが完了するのはPE2を介してです。
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がVPNv4にPE2側からのプレフィックスとして追加されました。
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フラグに注意してください。これは、BGPSource-Activeメッセージのおかげでエントリが作成されたことを示します。
mVPN組織の検討対象のバリアントは、コード名「プロファイル11」です。その主な特徴：
- 重ね合わせたネットワークにマルチキャストトラフィックを送信するには、デフォルトのMDTが使用されます
- mGREプロトコルはトランスポート編成方法として使用されます
- BGPプロトコルは、課されたネットワーク内のマルチキャストツリーに信号を送るために使用されます