IOS-XEでPIM-SMを使用したマルチキャストサービスリフレクション(MSRU):マルチキャスト ツー ユニキャストへ

概要

この記事の目的は、IOS-XEプラットフォームを使用したMSR（マルチキャストサービスレプリケーション）の基本的な動作を、設定ラボガイドの形式で理解できるようにすることです。

前提条件

要件

PIM-SMの基本的な知識

使用するコンポーネント

ASR1000(R2&R4)、ISR4300(R3)、ISR2900(R1&R5)

設定

マルチキャストを変換する次のダイアグラムのシナリオに基づいて、エンドツーエンドの設定を次に示します。

ネットワーク図

設定

上の図では、ノードR1がマルチキャスト送信元からユニキャストマルチキャストデータフィードのみを取得するように想定されるレシーバとして機能します。

ノードR5は、ループバック0インターフェイスを送信元とするマルチキャストICMPトラフィックを生成するマルチキャスト送信元として機能します。

ノードR2はコンテンツプロバイダーマルチキャストコアドメインの下にあり、OSPFのアンダーレイを使用してPIM-SMを実行しています。

ノードR3は、マルチキャストサービスレプリケーションアプリケーションを実行するルータとして機能し、この場合、マルチキャストデータトラフィックの送信元が受信側に向かうユニキャストデータパケットに変換されるマルチキャストボーダールータです。OSPFとEIGRPをそれぞれコンテンツプロバイダーとISPとともに使用し、マルチキャストコアドメイン内のループバックインターフェイスにRP(Rendezvouz Point)を格納します。

ノードR4はISPのコア制御下にあり、マルチキャストは有効ではなく、アンダーレイEIGRPルーティングを使用してR3ノードに到達する方法のみを理解します。

次に、上記のトポロジ図に示されているノードに関連する設定を示します。

R1：

!
no ip domain lookup
ip cef
no ipv6 cef
!
interface GigabitEthernet0/2
 ip address 10.10.20.1 255.255.255.0
 duplex auto
 speed auto
end
!
router eigrp 100
 network 10.10.20.0 0.0.0.255
!

R2:

!
interface GigabitEthernet0/0/0
 ip address 10.10.20.2 255.255.255.0
 negotiation auto
!
interface GigabitEthernet0/0/2
 ip address 10.10.10.1 255.255.255.0
 negotiation auto
!
router eigrp 100
 network 10.10.10.0 0.0.0.255
 network 10.10.20.0 0.0.0.255
!

R3：

!
ip multicast-routing distributed
!
interface Loopback0
 ip address 192.168.2.1 255.255.255.255
 ip pim sparse-mode
 ip ospf 1 area 0
!
interface GigabitEthernet0/0/0
 ip address 192.168.30.1 255.255.255.0
 ip pim sparse-mode
 ip ospf 1 area 0
 negotiation auto
!
interface GigabitEthernet0/0/1
 ip address 10.10.10.2 255.255.255.0
 negotiation auto
!
interface Vif1
 ip address 192.169.169.1 255.255.255.0
 ip pim sparse-mode
 ip service reflect GigabitEthernet0/0/0 destination 224.1.1.0 to 10.10.20.0 mask-len 24 source 192.169.169.169 <<<< 
 ip igmp static-group 224.1.1.1
 ip ospf 1 area 0
!
router eigrp 100
 network 10.10.10.0 0.0.0.255
!
router ospf 1
!
ip pim rp-address 192.168.2.1
!

R4：

!
ip multicast-routing distributed
!
interface GigabitEthernet0/0/0
 ip address 192.168.30.2 255.255.255.0
 ip pim sparse-mode
 ip ospf 1 area 0
 negotiation auto
!
interface GigabitEthernet0/0/2
 ip address 192.168.20.1 255.255.255.0
 ip pim sparse-mode
 ip ospf 1 area 0
 negotiation auto
!
router ospf 1
!
ip pim rp-address 192.168.2.1
!

R5：

!
ip multicast-routing
ip cef
no ipv6 cef
!
interface Loopback0
 ip address 192.168.168.168 255.255.255.255
 ip pim sparse-mode
 ip ospf 1 area 0
!
interface GigabitEthernet0/2
 ip address 192.168.20.2 255.255.255.0
 ip pim sparse-mode
 ip ospf 1 area 0
 duplex auto
 speed auto
!
router ospf 1
!
ip pim rp-address 192.168.2.1
!

確認

R5ルータからマルチキャストトラフィックをシミュレートするテストpingを実行して、マルチキャストアドレス224.1.1.1宛てのループバック0インターフェイス[192.168.168.168]を使用して設定を検証できます。次に、MSRアプリケーションを実行しているノードのmrouteエントリを確認します。

R5(config)#do ping 224.1.1.1 sou lo 0 rep 10000000
Type escape sequence to abort.
Sending 10000000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.168.168
.............................

R3#sh ip mroute 224.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, c - PFP-SA cache created entry
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 224.1.1.1), 00:47:41/stopped, RP 192.168.2.1, flags: SJC
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    Vif1, Forward/Sparse, 00:46:36/00:01:23 <<<<

(192.168.168.168, 224.1.1.1), 00:00:20/00:02:43, flags: T
  Incoming interface: GigabitEthernet0/0/0, RPF nbr 192.168.30.2
  Outgoing interface list:
    Vif1, Forward/Sparse, 00:00:20/00:02:39 <<<<

R3#sh ip mroute 224.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 2938 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: 224.1.1.1, Source count: 1, Packets forwarded: 1455, Packets received: 1458 <<<<
  RP-tree: Forwarding: 1/0/100/0, Other: 1/0/0
  Source: 192.168.168.168/32, Forwarding: 1454/1/113/0, Other: 1457/3/0
R3#sh ip mroute 224.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 2938 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: 224.1.1.1, Source count: 1, Packets forwarded: 1465, Packets received: 1468 <<<<
  RP-tree: Forwarding: 1/0/100/0, Other: 1/0/0
  Source: 192.168.168.168/32, Forwarding: 1464/1/113/0, Other: 1467/3/0

また、IOS-XEルータでEPC(Embedded Packet Capture)機能を使用して、パケットが実際にR2ノードの目的のユニキャスト宛先アドレスに変換されることを確認するために、キャプチャを取得することもできます。

R2#mon cap TAC int gi 0/0/2 both match any
R2#mon cap TAC buff siz 50 circular
R2#mon cap TAC start
Started capture point : TAC
R2#
*Aug 12 06:50:40.195: %BUFCAP-6-ENABLE: Capture Point TAC enabled.
R2#sh mon cap TAC buff br | i ICMP
   6  114   10.684022   192.169.169.169  ->  10.10.20.1       0  BE   ICMP <<<<
   7  114   10.684022   192.169.169.169  ->  10.10.20.1       0  BE   ICMP <<<<
   8  114   12.683015   192.169.169.169  ->  10.10.20.1       0  BE   ICMP <<<<
   9  114   12.683015   192.169.169.169  ->  10.10.20.1       0  BE   ICMP <<<<

ここで注意すべき重要な点は、「ラボ環境」でマルチキャストICMP pingを定期的に実行する場合、通常は受信側から送信元に向かってICMPエコー応答パケットを受信すると予想されます（送信元と受信側）。 ただし、このシナリオでは、マルチキャストICMPパケットのNATされた送信元アドレス(たとえば192.169.169.169)をEIGRP経由でレシーバR1までアドバタイズしようとしても、逆NATがMSRアプリケーションノードで設定されていないため、ユニキャストICMPエコー応答はR3ルータを通過しません。これをテストするには、R3のVif 1インターフェイスのEIGRPルートアドバタイズメントをEIGRP（ISPコアルーティング）に実行します。

ISR4351(config)#router eigrp 100
ISR4351(config-router)#network 192.169.169.0 0.0.0.255 <<<<

次に、R3に送信されるICMPエコー応答のR2ノードで取得したキャプチャを確認します（ICMPエコー応答はR3に送信されます）。

R2#sh mon cap TAC buff br | i ICMP 

     
     
       249 114 317.847948 192.169.169.169 -> 10.10.20.1 0 BE ICMP 250 114 317.847948 192.169.169.169 -> 10.10.20.1 0 BE ICMP 251 114 317.847948 10.10.20.1 -> 192.169.169.169 0 BE ICMP <<<< 252 114 317.847948 10.10.20.1 -> 192.169.169.169 0 BE ICMP <<<< 253 114 319.847948 192.169.169.169 -> 10.10.20.1 0 BE ICMP 254 114 319.847948 192.169.169.169 -> 10.10.20.1 0 BE ICMP 255 114 319.848955 10.10.20.1 -> 192.169.169.169 0 BE ICMP <<<< 256 114 319.848955 10.10.20.1 -> 192.169.169.169 0 BE ICMP <<<< 259 114 321.848955 192.169.169.169 -> 10.10.20.1 0 BE ICMP 260 114 321.848955 192.169.169.169 -> 10.10.20.1 0 BE ICMP 261 114 321.848955 10.10.20.1 -> 192.169.169.169 0 BE ICMP <<<< 262 114 321.848955 10.10.20.1 -> 192.169.169.169 0 BE ICMP <<<< 
     

ただし、pingはソースR5で見られるように失敗します(PINGは送信元R5:

R5(config)#do ping 224.1.1.1 sou lo 0 rep 10000000
Type escape sequence to abort.
Sending 10000000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.168.168
......................................................................
......................................................................

     
     

発信元までずっと応答を受信できるように、extendable NAT(extendable NAT)を設定することで、MSRアプリケーションノードR3で宛先トラフィックを192.169.169.169から192.168.168.168に変換するようにNATポートフォワーディングを設定できます。

R3(config)#int gi 0/0/1
R3(config-if)#ip nat out
R3(config-if)#int gi 0/0/0
R3(config-if)#ip nat ins
R3(config-if)#exit
R3(config)#ip nat inside source static 192.168.168.168 192.169.169.169 extendable <<<<

ここで、送信元R5ノードを確認すると、応答が戻ってくるのが確認できます。

R5(config)#do ping 224.1.1.1 sou lo 0 rep 10000000
Type escape sequence to abort.
Sending 10000000, 100-byte ICMP Echos to 224.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.168.168
......................................................................

     
     
       Reply to request 716 from 10.10.20.1, 1 ms Reply to request 716 from 10.10.20.1, 1 ms Reply to request 717 from 10.10.20.1, 1 ms Reply to request 717 from 10.10.20.1, 1 ms Reply to request 718 from 10.10.20.1, 1 ms Reply to request 718 from 10.10.20.1, 1 ms 
     

上記は、パケットフローを説明し、データトラフィックとダウンストリームマルチキャストトラフィックのリバースユニキャストパス/フローを確立する方法を理解するために実行されました。通常の実稼働シナリオでは、通常、サーバ/ソース側で稼働するマルチキャストアプリケーションがユニキャスト形式でレシーバからの逆受信確認パケットを必要とするケース/インスタンスは発生しません。 

上記のテストと検証では、マルチキャストサービスレプリケーションアプリケーションをマルチキャストボーダーノードの1つで実行する方法と、上記と同じアプリケーションを大規模な展開に拡張する方法の概要を示す必要があります。