IP : マルチキャスト

mVPN のための厳密な RPF チェック

2016 年 10 月 27 日 - 機械翻訳について
その他のバージョン: PDFpdf | 英語版 (2015 年 8 月 22 日) | フィードバック

概要

この資料は VPN (mVPN)上のマルチキャストのための厳密な予約パス転送(RPF)機能を説明していたものです。 この資料は Cisco IOS ® で例および動作を説明するために実装を使用します。

Contributed by Luc De Ghein, Cisco TAC Engineer.

背景説明

RPF は着信インターフェイスがソースの方にチェックされることを意味します。 ソースの方の正しい 1 時であることを判別するためにインターフェイスはチェックされるがそれがそのインターフェイスの正しい RPF ネイバーであることを判別することを、チェックしません。 マルチアクセス インターフェイスで、RPF できた複数のネイバがある可能性があります。 結果はルータがそのインターフェイスの同じマルチキャスト ストリームを二度受け取り、両方を転送することである可能性があります。

Protocol Independent Multicast (PIM)がマルチアクセス インターフェイスで動作するネットワークでは重複したマルチキャスト ストリームによりアサート メカニズムは動作します、1 つのマルチキャスト ストリームがもはや受け取られないので、これは問題ではないです。 場合によっては、PIM はマルチアクセス インターフェイスであるマルチキャスト配布ツリー(MDT)で動作しません。 そのような場合、Border Gateway Protocol (BGP)はオーバーレイ シグナリング プロトコルです。

区分 MDT のプロファイルでは、PIM はオーバーレイ プロトコルとして動作しても、持っていることはアサートします不可能である場合もあります。 この理由は 1 つの入力 Provider Edge (PE)が 2つ以上の入力 PE ルータのシナリオの別の入力 PE からの区分 MDT に加入しないことです。 各入力 PE ルータはマルチキャストトラフィックを見る他の入力 PE ルータなしで区分 MDT にマルチキャスト ストリームを転送できます。 2 人の異なる出力 PE ルータが各加入同じマルチキャスト ストリームのための別の入力 PE ルータの方の MDT 有効なシナリオであるというファクト: それは Anycast Source と呼ばれます。 これは異なるレシーバがマルチプロトコル ラベル スイッチング(MPLS) コアの異なるパス上の同じマルチキャスト ストリームに加入するようにします。 エニーキャスト ソースの例については図 1 参照して下さい。

図 1

2 人の入力 PE ルータがあります: PE1 および PE2。 2 人の出力 PE ルータがあります: PE3 および PE4。 各出力 PE ルータに RPF ネイバーとして別の入力 PE ルータがあります。 PE3 に RPF ネイバーとして PE1 があります。 PE4 に RPF ネイバーとして PE2 があります。 出力 PE ルータは RPF ネイバーとして最も密接な入力 PE ルータを選びます。

ストリーム(S1,G)は S1 上パス上のレシーバ 1 にと S1 から一番下パス上のレシーバ 2 に行きます。 2 つのパス上の 2 つのストリームの共通部分がありません(MPLS コアの各パスは異なる区分 MDT です)。

MDT がデフォルト MDT -デフォルト MDT プロファイルのような-これは 2 つのマルチキャスト ストリームが同じデフォルト MDT にあり、アサート メカニズムが動作するのではたらきません。 MDT がデフォルト MDT プロファイルのデータ MDT である場合、すべての入力 PE ルータは他の入力 PE ルータからのデータ MDT に加入し、そのように互いおよびアサート メカニズムからのマルチキャストトラフィックが再度動作することを見ます。 オーバーレイ プロトコルが BGP である場合、アップストリーム マルチキャスト ホップ(UMH)選択があり、1 入力 PE ルータだけフォワーダとして選択されますが、これは MDT ごとにあります。

エニーキャスト ソースは区分 MDT を実行する大きい長所の 1 つです。

問題

規則的な RPF チェックはパケットが正しい RPF インターフェイスからのルータで着くことを確認します。 パケットがそのインターフェイスの正しい RPF ネイバーから受信されることを確認するチェックがありません。

図 2 を参照してください。 重複トラフィックが区分 MDT のシナリオであくまでどこに転送されるか問題に示します。 区分 MDT の場合には規則的な RPF チェックが重複したトラフィックを避けて十分ではないことを示します。

図 2

2 台のレシーバがあります。 最初のレシーバはトラフィックをのための(S1,G)受信するためにおよび設定されます(S2,G)。 第 2 レシーバは(S2,G)ただのためのトラフィックを受信するために設定されます。 区分 MDT があり、BGP はオーバーレイ シグナリング プロトコルです。 ソース S1 が両方の PE1 および PE2 によって到達可能であることに注目して下さい。 コア ツリー プロトコルはマルチポイント ラベル配布プロトコル(mLDP)です。

各 PE ルータはタイプ 1 BGP IPv4 mVPN ルートをアドバタイズします、それは区分 MDT のルートである候補であることを示す。

PE3#show bgp ipv4 mvpn vrf one              
BGP table version is 257, local router ID is 10.100.1.3
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-pah, c RIB-compressed,
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:3 (default for vrf one)
*>i [1][1:3][10.100.1.1]/12
                      10.100.1.1               0   100     0 ?
*>i [1][1:3][10.100.1.2]/12
                       10.100.1.2               0   100     0 ?
*> [1][1:3][10.100.1.3]/12
                       0.0.0.0                           32768 ?
*>i [1][1:3][10.100.1.4]/12
                       10.100.1.4               0   100     0 ?

PE3 は S1 のための RPF ネイバーとして PE1 を後 S1 のユニキャスト ルートのためのルックアップ見つけました。

PE3#show bgp vpnv4 unicast vrf one 10.100.1.6/32
BGP routing table entry for 1:3:10.100.1.6/32, version 16
Paths: (2 available, best #2, table one)
Advertised to update-groups:
     5       
Refresh Epoch 2
65001, imported path from 1:2:10.100.1.6/32 (global)
   10.100.1.2 (metric 21) (via default) from 10.100.1.5 (10.100.1.5)
     Origin incomplete, metric 0, localpref 100, valid, internal
     Extended Community: RT:1:1 MVPN AS:1:0.0.0.0 MVPN VRF:10.100.1.2:1
     Originator: 10.100.1.2, Cluster list: 10.100.1.5
     mpls labels in/out nolabel/20
     rx pathid: 0, tx pathid: 0
Refresh Epoch 2
65001, imported path from 1:1:10.100.1.6/32 (global)
10.100.1.1 (metric 11) (via default) from 10.100.1.5 (10.100.1.5)
     Origin incomplete, metric 0, localpref 100, valid, internal, best
     Extended Community: RT:1:1 MVPN AS:1:0.0.0.0 MVPN VRF:10.100.1.1:1
     Originator: 10.100.1.1, Cluster list: 10.100.1.5
     mpls labels in/out nolabel/29
     rx pathid: 0, tx pathid: 0x0
PE3#show ip rpf vrf one 10.100.1.6
RPF information for ? (10.100.1.6)
RPF interface: Lspvif0
RPF neighbor: ? (10.100.1.1)
RPF route/mask: 10.100.1.6/32
RPF type: unicast (bgp 1)
Doing distance-preferred lookups across tables
RPF topology: ipv4 multicast base, originated from ipv4 unicast base

PE3 は RPF ネイバーとして PE1 をに(S1,G)選択し、ルートとして PE1 の区分 MDT に加入します。 PE3 は RPF ネイバーとして PE2 をに(S2,G)選択し、ルートとして PE2 の区分 MDT に加入します。

PE3#show bgp vpnv4 unicast vrf one 10.100.1.7/32
BGP routing table entry for 1:3:10.100.1.7/32, version 18
Paths: (1 available, best #1, table one)
Advertised to update-groups:
     6       
Refresh Epoch 2
65002, imported path from 1:2:10.100.1.7/32 (global)
     10.100.1.2 (metric 21) (via default) from 10.100.1.5 (10.100.1.5)
     Origin incomplete, metric 0, localpref 100, valid, internal, best
     Extended Community: RT:1:1 MVPN AS:1:0.0.0.0 MVPN VRF:10.100.1.2:1
     Originator: 10.100.1.2, Cluster list: 10.100.1.5
     mpls labels in/out nolabel/29
     rx pathid: 0, tx pathid: 0x0
PE3#show ip rpf vrf one 10.100.1.7
RPF information for ? (10.100.1.7)
RPF interface: Lspvif0
RPF neighbor: ? (10.100.1.2)
RPF route/mask: 10.100.1.7/32
RPF type: unicast (bgp 1)
Doing distance-preferred lookups across tables
RPF topology: ipv4 multicast base, originated from ipv4 unicast base

PE4 は RPF ネイバーとして PE2 をに(S1,G)選択し、ルートとして PE1 の区分 MDT に加入します。

PE4#show bgp vpnv4 unicast vrf one 10.100.1.6/32
BGP routing table entry for 1:4:10.100.1.6/32, version 138
Paths: (2 available, best #1, table one)
Advertised to update-groups:
     2       
Refresh Epoch 2
65001, imported path from 1:2:10.100.1.6/32 (global)
10.100.1.2 (metric 11) (via default) from 10.100.1.5 (10.100.1.5)
     Origin incomplete, metric 0, localpref 100, valid, internal, best
     Extended Community: RT:1:1 MVPN AS:1:0.0.0.0 MVPN VRF:10.100.1.2:1
     Originator: 10.100.1.2, Cluster list: 10.100.1.5
     mpls labels in/out nolabel/20
     rx pathid: 0, tx pathid: 0x0
Refresh Epoch 2
65001, imported path from 1:1:10.100.1.6/32 (global)
   10.100.1.1 (metric 21) (via default) from 10.100.1.5 (10.100.1.5)
     Origin incomplete, metric 0, localpref 100, valid, internal
     Extended Community: RT:1:1 MVPN AS:1:0.0.0.0 MVPN VRF:10.100.1.1:1
     Originator: 10.100.1.1, Cluster list: 10.100.1.5
     mpls labels in/out nolabel/29
     rx pathid: 0, tx pathid: 0
PE4#show ip rpf vrf one 10.100.1.6
RPF information for ? (10.100.1.6)
RPF interface: Lspvif0
RPF neighbor: ? (10.100.1.2)
RPF route/mask: 10.100.1.6/32
RPF type: unicast (bgp 1)
Doing distance-preferred lookups across tables
RPF topology: ipv4 multicast base, originated from ipv4 unicast base

RPF インターフェイスが両方のための Lspvif0 S1 であることに注意して下さい(10.100.1.6)および S2 (10.100.1.7)。

PE3 は PE2 からの区分 MDT にのための(S2,G)加入し、PE4 は PE2 からの区分 MDT にのための加入します(S1,G)。 PE1 は PE1 からの区分 MDT にのための加入します(S1,G)。 PE1 および PE2 で受け取った型 7 BGP IPv4 mVPN ルーティングによってこれを表示できます。

PE1#show bgp ipv4 mvpn vrf one
BGP table version is 302, local router ID is 10.100.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,
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 (default for vrf one)
*>i [7][1:1][1][10.100.1.6/32][232.1.1.1/32]/22
                       10.100.1.3               0   100     0 ?
PE2#show bgp ipv4 mvpn vrf one
BGP table version is 329, local router ID is 10.100.1.2
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,
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:2 (default for vrf one)
*>i [7][1:2][1][10.100.1.6/32][232.1.1.1/32]/22
                       10.100.1.4               0   100     0 ?
*>i [7][1:2][1][10.100.1.7/32][232.1.1.1/32]/22
                       10.100.1.3               0   100     0 ?

PE3 および PE4 のマルチキャストエントリ:

PE3#show ip mroute vrf one 232.1.1.1
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, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group,
       G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
       N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
       Q - Received BGP S-A Route, q - Sent BGP S-A Route,
       V - RD & Vector, v - Vector, p - PIM Joins on route,
       x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(10.100.1.7, 232.1.1.1), 21:18:24/00:02:46, flags: sTg
Incoming interface: Lspvif0, RPF nbr 10.100.1.2
Outgoing interface list:
   Ethernet0/0, Forward/Sparse, 00:11:48/00:02:46

(10.100.1.6, 232.1.1.1), 21:18:27/00:03:17, flags: sTg
Incoming interface: Lspvif0, RPF nbr 10.100.1.1
Outgoing interface list:
   Ethernet0/0, Forward/Sparse, 00:11:48/00:03:17
PE4#show ip mroute vrf one 232.1.1.1
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, E - Extranet,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report,
       Z - Multicast Tunnel, z - MDT-data group sender,
       Y - Joined MDT-data group, y - Sending to MDT-data group,
       G - Received BGP C-Mroute, g - Sent BGP C-Mroute,
       N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed,
       Q - Received BGP S-A Route, q - Sent BGP S-A Route,
       V - RD & Vector, v - Vector, p - PIM Joins on route,
       x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(10.100.1.6, 232.1.1.1), 20:50:13/00:02:37, flags: sTg
Incoming interface: Lspvif0, RPF nbr 10.100.1.2
Outgoing interface list:
   Ethernet0/0, Forward/Sparse, 20:50:13/00:02:37

これは PE3 が PE1 で定着する(P2MP)ポイント マルチポイント間ツリーおよび PE2 で定着するまたツリーに加入することを示します:

PE3#show mpls mldp database
* Indicates MLDP recursive forwarding is enabled

LSM ID : A   Type: P2MP   Uptime : 00:18:40
FEC Root           : 10.100.1.1
Opaque decoded     : [gid 65536 (0x00010000)]
Opaque length     : 4 bytes
Opaque value       : 01 0004 00010000
Upstream client(s) :
   10.100.1.1:0   [Active]
     Expires       : Never         Path Set ID : A
     Out Label (U) : None         Interface   : Ethernet5/0*
     Local Label (D): 29           Next Hop     : 10.1.5.1
Replication client(s):
   MDT (VRF one)
     Uptime         : 00:18:40     Path Set ID : None
     Interface     : Lspvif0      

LSM ID : B   Type: P2MP   Uptime : 00:18:40
FEC Root           : 10.100.1.2
Opaque decoded     : [gid 65536 (0x00010000)]
Opaque length     : 4 bytes
Opaque value       : 01 0004 00010000
Upstream client(s) :
   10.100.1.5:0  [Active]
     Expires       : Never         Path Set ID : B
     Out Label (U) : None         Interface   : Ethernet6/0*
     Local Label (D): 30           Next Hop     : 10.1.3.5
Replication client(s):
   MDT (VRF one)
     Uptime       : 00:18:40     Path Set ID : None
     Interface     : Lspvif0      

これは PE4 が PE2 で定着する P2MP ツリーに加入することを示します:

PE4#show mpls mldp database      
* Indicates MLDP recursive forwarding is enabled

LSM ID : 3   Type: P2MP   Uptime : 21:17:06
FEC Root           : 10.100.1.2
Opaque decoded     : [gid 65536 (0x00010000)]

Opaque value       : 01 0004 00010000
Upstream client(s) :
   10.100.1.2:0   [Active]
     Expires       : Never         Path Set ID : 3
     Out Label (U) : None         Interface   : Ethernet5/0*
     Local Label (D): 29           Next Hop     : 10.1.6.2
Replication client(s):
   MDT (VRF one)
     Uptime         : 21:17:06     Path Set ID : None
     Interface     : Lspvif0      

S1 および S2 は 10 pps のグループ 232.1.1.1 のために流れます。 PE3 および PE4 でストリームを表示できます。 ただし、PE3 で、20 pps として比率をについては(S1,G)表示できます。

PE3#show ip mroute vrf one 232.1.1.1 count
Use "show ip mfib count" to get better response time for a large number of mroutes.

IP Multicast Statistics
3 routes using 1692 bytes of memory
2 groups, 1.00 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)

Group: 232.1.1.1, Source count: 2, Packets forwarded: 1399687, Packets received:
2071455
Source: 10.100.1.7/32, Forwarding: 691517/10/28/2, Other: 691517/0/0
Source: 10.100.1.6/32, Forwarding: 708170/20/28/4, Other: 1379938/671768/0
PE4#show ip mroute vrf one 232.1.1.1 count
Use "show ip mfib count" to get better response time for a large number of mroutes.

IP Multicast Statistics
2 routes using 1246 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)

Group: 232.1.1.1, Source count: 1, Packets forwarded: 688820, Packets received:
688820
Source: 10.100.1.6/32, Forwarding: 688820/10/28/2, Other: 688820/0/0
PE3#show interfaces ethernet0/0 | include rate
Queueing strategy: fifo
30 second input rate 0 bits/sec, 0 packets/sec
30 second output rate 9000 bits/sec, 30 packets/sec

重複したストリームがあります。 この重複は PE1 からの区分 MDT と PE2 からの区分 MDT のストリーム(S1,G)の存在の結果です。 この秒区分 MDT は、PE2 から PE3 によって、ストリーム(S2,G)を得るために加入されました。 しかし PE4 が得るために PE2 からの区分 MDT に(S1,G)加入したので、(S1,G) PE2 からの区分 MDT にまた現在です。 それ故に、PE3 は両方からストリーム(S1,G)を加入した区分 MDTs 受け取ります。

PE3 は(S1,G)それのためのパケットの間で PE1 および PE2 から受け取ります区別できません。 ストリームは両方とも正しい RPF インターフェイスで受け取られます: Lspvif0.

PE3#show ip multicast vrf one mpls vif

Interface   Next-hop            Application     Ref-Count   Table / VRF name   Flags
Lspvif0     0.0.0.0             MDT               N/A       1   (vrf one) 0x1

パケットは PE3 または同じインターフェイスの異なる着信 物理インターフェイスに着く可能性があります。 いずれにしても、異なるストリームからのパケットはのための(S1,G) PE3 で別の MPLS ラベルと着きます:

PE3#show mpls forwarding-table vrf one
Local     Outgoing   Prefix           Bytes Label   Outgoing   Next Hop 
Label     Label     or Tunnel Id     Switched     interface           
29   [T] No Label   [gid 65536 (0x00010000)][V]   \
                                       768684       aggregate/one
30   [T] No Label   [gid 65536 (0x00010000)][V]   \
                                       1535940       aggregate/one

[T]     Forwarding through a LSP tunnel.
       View additional labelling info with the 'detail' option

解決策

ソリューションはより厳密な RPF を持つことです。 厳密な RPF を使うと、ルータはどのネイバーをパケットが RPF インターフェイスでから受け取られるかチェックします。 厳密な RPF なしで、唯一のチェックは着信インターフェイスが RPF インターフェイスだった、ないパケットがそのインターフェイスの正しい RPF ネイバーから受信されればかどうか確認することです。

Cisco IOS に関するメモ

Cisco IOS との RPF についてのいくつかの注記はここにあります。

  • 厳密な RPF モードに出入して、変更するとき区分 MDT をまたはオフ BGP を設定する前にそれ設定して下さい。 厳密な RPF コマンドだけを設定する場合、Lspvif 別のインターフェイスをすぐに作成しません。

  • 厳密な RPF は Cisco IOS でデフォルトで有効に なりません。

  • デフォルト MDT プロファイルの厳密 rpf コマンドがあることをサポートしません。

設定

バーチャルルーティングおよびフォワーディング(VRF)のための PE3 の厳密な RPF を設定できます。

vrf definition one
rd 1:3
!
address-family ipv4
mdt auto-discovery mldp
mdt strict-rpf interface
mdt partitioned mldp p2mp
mdt overlay use-bgp
route-target export 1:1
route-target import 1:1
exit-address-family
!

RPF 情報は変わりました:

PE3#show ip rpf vrf one 10.100.1.6
RPF information for ? (10.100.1.6)
RPF interface: Lspvif0
Strict-RPF interface: Lspvif1
RPF neighbor: ? (10.100.1.1)
RPF route/mask: 10.100.1.6/32
RPF type: unicast (bgp 1)
Doing distance-preferred lookups across tables
RPF topology: ipv4 multicast base, originated from ipv4 unicast base
PE3#show ip rpf vrf one 10.100.1.7
RPF information for ? (10.100.1.7)
RPF interface: Lspvif0
Strict-RPF interface: Lspvif2
RPF neighbor: ? (10.100.1.2)
RPF route/mask: 10.100.1.7/32
RPF type: unicast (bgp 1)
Doing distance-preferred lookups across tables
RPF topology: ipv4 multicast base, originated from ipv4 unicast base

PE3 は入力 PE ごとの Lspvif インターフェイスを作成しました。 Lspvif インターフェイスは入力 PE、アドレス ファミリー(AF)、および VRF ごとに作成されます。 10.100.1.6 のための RPF は今 Lspvif1 をインターフェイスさせるために指し、Lspvif2 をインターフェイスさせるために 10.100.1.7 のための RPF は今指します。

PE3#show ip multicast vrf one mpls vif

Interface   Next-hop           Application     Ref-Count   Table / VRF name   Flags
Lspvif0     0.0.0.0             MDT               N/A       1   (vrf one) 0x1
Lspvif1     10.100.1.1           MDT               N/A       1   (vrf one) 0x1
Lspvif2     10.100.1.2           MDT               N/A       1   (vrf one) 0x1

この場合、PE1 からのパケット(S1,G)のための RPF チェックは RPF インターフェイス Lspvif1 に対してチェックされます。 これらのパケットは MPLS ラベル 29 と入ります。 PE2 からのパケット(S2,G)のための RPF チェックは RPF インターフェイス Lspvif2 に対してチェックされます。 これらのパケットは MPLS ラベル 30 と入ります。 ストリームは異なる着信インターフェイスを通って PE3 に着きます、これはまた同じインターフェイスである可能性があります。 ただし、mLDP が決して Penultimate Hop Popping (PHP)を使用しないというファクトが原因で、マルチキャスト パケットの上に規則的な MPLS ラベルが常にあります。 従って PE1 と PE2 から着く(S1,G)パケットは 2 区分 MDTs にあり、別の MPLS ラベルがあります。 それ故に、PE2 から来る(S1,G)ストリームおよび PE1 から来る PE3 は(S1,G)ストリームの間で区別できます。 このように、パケットは PE3 によって別保存され、RPF は異なる入力 PE ルータに対して実行されたことができます。

PE3 の mLDP データベースは今入力 PE ごとの Lspvif 異なるインターフェイスを示します。

PE3#show mpls mldp database
* Indicates MLDP recursive forwarding is enabled

LSM ID : C   Type: P2MP   Uptime : 00:05:58
FEC Root           : 10.100.1.1
Opaque decoded     : [gid 65536 (0x00010000)]
Opaque length     : 4 bytes
Opaque value       : 01 0004 00010000
Upstream client(s) :
   10.100.1.1:0   [Active]
     Expires       : Never         Path Set ID : C
     Out Label (U) : None         Interface   : Ethernet5/0*
     Local Label (D): 29           Next Hop     : 10.1.5.1
Replication client(s):
   MDT (VRF one)
     Uptime         : 00:05:58     Path Set ID : None
     Interface     : Lspvif1      

LSM ID : D   Type: P2MP   Uptime : 00:05:58
FEC Root           : 10.100.1.2
Opaque decoded     : [gid 65536 (0x00010000)]
Opaque length     : 4 bytes
Opaque value       : 01 0004 00010000
Upstream client(s) :
   10.100.1.5:0   [Active]
     Expires       : Never         Path Set ID : D
     Out Label (U) : None         Interface   : Ethernet6/0*
     Local Label (D): 30           Next Hop     : 10.1.3.5
Replication client(s):
   MDT (VRF one)
     Uptime         : 00:05:58     Path Set ID : None
     Interface     : Lspvif2      

マルチキャスト ストリームが入力 PE ごとの別の MPLS ラベルの入力 PE に入るというファクトによる入力 PE 作業ごとの厳密な RPF か RPF:

PE3#show mpls forwarding-table vrf one
Local     Outgoing   Prefix           Bytes Label   Outgoing   Next Hop 
Label     Label     or Tunnel Id     Switched     interface           
29   [T] No Label   [gid 65536 (0x00010000)][V]   \
                                       162708       aggregate/one
30   [T] No Label   [gid 65536 (0x00010000)][V]   \
                                       162750       aggregate/one

[T]     Forwarding through a LSP tunnel.
       View additional labelling info with the 'detail' option

厳密な RPF がはたらかせる証明はもはや PE3 で転送される重複したストリーム(S1,G)がないことです。 重複したストリームはまだ PE3 に着きますが、RPF障害が廃棄された原因です。 RPF障害カウンターは 10 pps のレートで 676255 および増加に絶えずあります。

PE3#show ip mroute vrf one 232.1.1.1 count
Use "show ip mfib count" to get better response time for a large number of mroutes.

IP Multicast Statistics
3 routes using 1692 bytes of memory
2 groups, 1.00 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)

Group: 232.1.1.1, Source count: 2, Packets forwarded: 1443260, Packets received:
2119515
Source: 10.100.1.7/32, Forwarding: 707523/10/28/2, Other: 707523/0/0
Source: 10.100.1.6/32, Forwarding: 735737/10/28/2, Other: 1411992/676255/0

このとき各ストリーム(S1,G)のための 10 pps およびの PE3 の出力レートは 20 pps です、(S2,G):

PE3#show interfaces ethernet0/0 | include rate
Queueing strategy: fifo
30 second input rate 0 bits/sec, 0 packets/sec
30 second output rate 6000 bits/sec, 20 packets/sec

結論

厳密な RPF チェックは区分 MDT を使用する mVPN 配置 モ デルに使用する必要があります。

事柄は区分 MDT で mVPN 配置 モ デルのための厳密な RPF チェックを設定しなくてもはたらくようであるかもしれません: マルチキャスト ストリームはレシーバに渡されます。 ただし、ソースが複数の入力 PE ルータに接続されるとき重複したマルチキャストトラフィックがあるという可能性があります。 これはネットワークの帯域幅の無駄の原因となり、不利にレシーバのマルチキャストアプリケ− ションに影響を与える場合があります。 それ故に、mVPN 配置 モ デルのための厳密な RPF チェックを設定する区分 MDT を使用するのは絶対必要です。



Document ID: 118677