Cisco IPICS Release 4.0(2) 用のソリューション リファレンス ネットワーク デザイン(SRND)
Cisco IPICS 配置モデル
Cisco IPICS 配置モデル
発行日;2012/01/12 | 英語版ドキュメント(2011/01/21 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 5MB) | フィードバック

目次

Cisco IPICS 配置モデル

単一サイト モデル

単一サイト モデルの利点

単一サイト モデルのベスト プラクティス

複数サイト モデル

マルチキャスト VPN での MPLS

MPLS の用語

MVPN の基本概念

VPN マルチキャスト ルーティング

MVPN 用のプロバイダー ネットワークの構成

MVPN 用のプロバイダー ネットワークの確認

トラフィック転送の最適化:データ MDT

正しい MDT 動作の確認

マルチキャスト アイランド

GRE 経由のマルチキャスト

M1:U12:M2 接続トランク

マルチキャストの特異点

Cisco IPICS 配置モデル

この章では、Cisco IPICS 配置モデルについて説明します。これらのモデルは、Cisco IPICS 環境を設計する際にガイドとして使用できます。

この章は、次の項で構成されています。

「単一サイト モデル」

「複数サイト モデル」

単一サイト モデル

Cisco IPICS 単一サイト モデルは、単一のマルチキャスト ドメインの配置を表しています。Cisco IPICS コンポーネントは、1 つのマルチキャスト使用可能サイトまたはキャンパスに配置され、IP WAN を介して Cisco IPICS マルチキャスト サービスは提供されません。一般に、単一サイト モデルは、LAN または Metropolitan Area Network(MAN; メトロポリタン エリア ネットワーク)を介して配置され、どちらかによってマルチキャスト音声トラフィックが伝送されます。LAN または MAN を越えるコールでは、Cisco IPICS リモート機能を使用して、SIP ベースのユニキャスト コールを介して Cisco IPICS ドメインに接続します。

単一サイト モデルの設計上の特長は、次のとおりです。

Cisco IPICS サーバ

RMS

IDC

Cisco Unified IP Phone

LMR ゲートウェイ(オプション)

PIM スパース モードを使用するマルチキャスト使用可能ネットワーク。

会議とトランスコーディング用の RMS Digital Signal Processor(DSP; デジタル シグナル プロセッサ)

図 7-1 に、Cisco IPICS 単一サイト モデルを示します。

図 7-1 単一サイト モデル

 

単一サイト モデルの利点

単一インフラストラクチャによる集中型ネットワーク ソリューションによって、大幅な費用対効果の低減が期待できます。また、Cisco IPICS は、企業内で IP ベースのアプリケーションを利用できます。さらに、単一サイト配置では、サイトを完全に分離することも可能です。IP WAN に対する依存関係がないため、WAN 障害または帯域幅の不足によって Cisco IPICS サービスや機能が失われることはありません。

単一サイト モデルのベスト プラクティス

Cisco IPICS 単一サイト モデルを実装する場合には、次のガイドラインに従ってください。

可用性が高く、フォールトトレラントなインフラストラクチャを提供する。Cisco IPICS の設置には、インフラストラクチャを適切に構築することが重要です。また、インフラストラクチャを適切に構築すると、マルチサイト配置への変更を選択する場合、変更が簡単になります。

すべてのローカル エンドポイントに G.711 コーデックを使用する。この方法では、トランスコーディング用の DSP リソースの消費が減少します。

ハイ アベイラビリティ、電話機用の接続オプション(インライン パワー)、QoS メカニズム、マルチキャストおよびセキュリティ用の推奨ネットワーク インフラストラクチャを実装する(詳細については、 第 4 章「Cisco IPICS インフラストラクチャの考慮事項」 を参照してください)。

複数サイト モデル

Cisco IPICS 複数サイト モデルは、2 つ以上のサイトにサービスを提供し、IP WAN を使用してサイト間でマルチキャスト IP 音声トラフィックを転送する単一の Cisco IPICS サーバで構成されています。IP WAN は、中央サイトとリモート サイト間のコール制御シグナリングも伝送します。

サイト間でマルチキャストを有効にできますが、必須ではありません。マルチキャストが有効な WAN によって接続された複数のサイトは、1 つの マルチキャスト ドメインしか存在しないため、実際にはトポロジ上は別のケースの単一サイト モデルとなります。複数サイト モデルの配置との主な違いは、接続するコア ネットワークが、Multiprotocol Label Switching(MPLS; マルチプロトコル ラベル スイッチング)を採用したサービス プロバイダー ネットワークかどうかという点です。その場合には、マルチキャスト VPN を使用する MPLS を採用すると、サイト間に単一のマルチキャスト ドメインが作成されます。サイト間にネイティブのマルチキャスト サポートが存在しない複数サイトでは、サイト間で Generic Routing Encapsulation(GRE; 総称ルーティング カプセル化)を介したマルチキャストまたは M1:U12:M2 接続トランクを採用できます。また、サイト間で IPSec VPN を設定して、サイト間のトラフィックの安全性を確保することもできます。

図 7-2 は、中央サイトに Cisco IPICS サーバが存在し、すべてのサイトを IP WAN で接続する、一般的な Cisco IPICS 複数サイト配置を示しています。

図 7-2 複数サイト モデル

 

複数サイト モデルでは、IP WAN の接続オプションには、以下が含まれます。

専用回線

フレーム リレー

Asynchronous Transfer Mode(ATM; 非同期転送モード)

ATM とフレーム リレーの Service Inter-Working(SIW; サービス インターワーキング)

MPLS バーチャル プライベート ネットワーク

音声およびビデオ対応 IP セキュリティ プロトコル VPN(IPSec VPN(V3PN))

WAN エッジに置かれているルータには、プライオリティ キューイングやトラフィック シェーピングなどの QoS メカニズムが装備されていて、WAN の帯域幅が恒常的に不足している場合に、データ トラフィックから音声トラフィックを保護しています。

この項では、次の項目について説明します。

「マルチキャスト VPN での MPLS」

「マルチキャスト アイランド」

マルチキャスト VPN での MPLS

MPLS は、MPLS VPN 内のネイティブ マルチキャストをサポートしません。この項では、MPLS コアにわたってマルチキャストを有効にする技法について説明します。この項では、ユニキャスト MPLS コアと VPN が設定され、正常に動作していることを想定しています。また、ユーザが IP マルチキャストと MPLS に精通していることを想定しています。これらのトピックの詳細については、次の URL でマニュアルを参照してください。

http://www.cisco.com/en/US/products/ps6552/products_ios_technology_home.html

図 7-3 に、この項で説明するトポロジを示します。

図 7-3 マルチキャスト VPN での MPLS

 

MPLS の用語

MPLS では、次の用語が使用されます。

Customer Edge(CE; カスタマー エッジ)ルータ:ネットワークのエッジに配備され、少なくとも 1 つの Provider Edge(PE; プロバイダー エッジ)ルータとインターフェイスを持つルータ

Data Multicast Distribution Tree(MDT; マルチキャスト配信ツリー):ネットワーク内にアクティブ ソースが存在することにより動的に作成され、別の PE ルータの背後に存在するアクティブなレシーバーに送信されるツリー。データ MDT は、アクティブなソースを持つか、またはアクティブなソースからのトラフィックのレシーバーを持つ CE ルータに接続された PE ルータ、またはトラフィックのアクティブなソースまたはレシーバーに直接接続された PE ルータにのみ接続されます。

デフォルト MDT:Multicast Virtual Private Network(MVPN; マルチキャスト バーチャル プライベート ネットワーク)構成によって作成されたツリー。デフォルト MDT は、カスタマー コントロール プレーンおよび低レート データ プレーンのトラフィック用に使用されます。ルーティングおよびフォワーディング(MVRF)を使用して、特定の Multicast Domain(MD; マルチキャスト ドメイン)内のすべての PE ルータに接続します。それぞれのカスタマー ネットワークにアクティブ ソースが存在するかどうかに関係なく、すべての MD 内にデフォルト MD が 1 つ存在します。

リーフ:マルチキャスト データの受信者を示します。ソースはルート、宛先はリーフと解釈されます。

Multicast domain(MD; マルチキャスト ドメイン):マルチキャスト トラフィックを交換できる MVRF の収集

Multicast Virtual Route Forwarding(MVRF; マルチキャスト仮想ルート フォワーディング):MPLS をまたいでマルチキャスト トラフィックを転送する方法を決定するために、PE ルータが使用

Provider(P; プロバイダー)ルータ:他の P ルータおよび他の PE ルータのみにインターフェイスを持つ、プロバイダー ネットワークのコア内のルータ

Provider Edge(PE; プロバイダー エッジ)ルータ:P ルータおよび PE ルータにインターフェイスを持ち、さらに少なくとも 1 つの CE ルータにインターフェイスを持つ、プロバイダー ネットワークのエッジのルータ

PIM-SSM:PIM ソースに固有のマルチキャスト

MVPN の基本概念

MVPN を理解するためには、次の基本概念が重要です。

サービス プロバイダーは、一意の IP マルチキャスト ドメインを持つ IP ネットワークを持っています(P ネットワーク)。

MVPN カスタマーは、一意の IP マルチキャスト ドメインを持つ IP ネットワークを持っています(C ネットワーク)。

サービス プロバイダー MVPN ネットワークは、カスタマー IP マルチキャスト データをリモート カスタマー サイトに転送します。そのために、サービス プロバイダーは、サービス プロバイダー PE でカスタマー トラフィック(C パケット)を P パケット内にカプセル化します。次に、カプセル化された P パケットが、P ネットワーク内のネイティブ マルチキャストとして、リモート PE サイトに転送されます

カプセル化された P パケットを転送している間、P ネットワークは、C ネットワーク トラフィックに関する情報を持っていません。PE は、両方のネットワークに参加するデバイスです(PE ごとに複数のカスタマー ネットワークが存在する可能性があります)。

VPN マルチキャスト ルーティング

MVPN ネットワーク内の PE ルータは、複数のルーティング テーブルを持っています。グローバル ユニキャスト/マルチキャスト ルーティング テーブルが 1 つ存在し、直接接続された各 MVRF に対してユニキャスト/マルチキャスト ルーティング テーブルが 1 つ存在します。

マルチキャスト ドメインは、VPN からのマルチキャスト パケットを、コア内でルーティングされるマルチキャスト パケットにカプセル化する原則に基づいています。マルチキャストはコア ネットワーク内で使用されるため、PIM をコア内で設定する必要があります。PIM-SM、PIM-SSM、および PIM-BIDIR は、MVPN 用のプロバイダー コア内でサポートされます。PIM-BIDIR はすべてのプラットフォームでサポートされるとは限らないので、プロバイダー コア内の推奨 PIM オプションは PIM-SM または PIM-SSM となります。PIM-SM、PIM-SSM、PIM-BIDIR、および PIM-DENSE-MODE は、MVPN 内でサポートされます。MVPN は、Multicast Distribution Tree(MDT; マルチキャスト配信ツリー)を利用します。MDT は PE ルータによって発信され、マルチキャスト宛先アドレスを持ちます。同じ MVPN 用にサイトを持つ複数の PE ルータがデフォルト MDT に発信し、またデフォルト MDT 上のトラフィックを受信するために結合します。

さらに、デフォルト MDT は常時接続で、PIM 制御トラフィック、デンス モード トラフィック、および RP ツリー(*,G)トラフィックを転送するツリーです。同じデフォルトの MDT で設定されたすべての PE ルータが、このトラフィックを受信します。

データ MDT は、オンデマンドで作成されるツリーであり、そのトラフィックを受信しようとするレシーバーを持つ PE ルータによってのみ結合されます。データ MDT は、トラフィック レートしきい値または送信元グループ ペアのいずれかによって作成されます。デフォルト MDT は、MVPN を構成するすべての VPN Routing and Forwarding(VRF; VPN ルーティングおよび転送)用に同じグループ アドレスを持つ必要があります。PIM-SSM を使用する場合には、複数のデータ MDT が同じグループ アドレスを持つ場合があります。同じアドレスを提供すると PE ルータが不要なトラフィックを受信する可能性があるため、PIM-SM を使用する場合には異なるグループ アドレスを持つ必要があります。

MVPN 用のプロバイダー ネットワークの構成

この項では、MVPN 用にプロバイダー ネットワークを構成する方法の例を示します。

プロバイダー ネットワーク内で MVPN を有効にするために必要な手順については、図 7-3のトポロジの説明を参照してください。この手順では、カスタマー VPN は「ipics」と呼ばれています。

手順


ステップ 1 プロバイダー ネットワーク用に PIM モードを選択します。

シスコは、コア内のプロトコルとして PIM-SSM を推奨しています。送信元検出属性では、追加の送信元検出 BGP 設定は必要ありません。Route Distinguisher(RD; ルート識別子)タイプを使用して、MDT の送信元に MDT グループ アドレスをアドバタイズします。PIM-SM は、最も広く配置されているマルチキャスト プロトコルであり、またスパースおよびデンスに入力されるアプリケーション要件の両方で使用されています。PIM SSM は、PIM SM に基づいています。初期共有ツリーおよび最短パス ツリーに対する後続のカットオーバーがない場合、PIM SSM または PIM SM がデフォルトの MDT に適しています。

すべての関連ハードウェア上で双方向 PIM サポートが使用可能な場合、これがデフォルトの MDT に対する推奨事項となります。データ MDT に対しては、PIM SM または PIM SSM が適しています。PIM SSM は、PIM SM よりも簡単に配備できます。ランデブー ポイントを必要とせず、またプロバイダー ネットワークが既知であり、安定したマルチキャスト デバイスのグループです。シスコは、プロバイダー コア配備には PIM SSM の使用を推奨しています。この設定例では、コアに PIM-SSM を使用しています。

ステップ 2 プロバイダー ネットワーク内で使用される VPN グループ アドレスを選択します。

デフォルトの PIM-SSM の範囲は 232/8 です。ただし、このアドレス範囲は、インターネットでグローバルに使用するよう設定されています。プライベート ドメイン内で使用する場合には、(RFC2365 の推奨に従って)この管理用スコープ マルチキャスト範囲の外側のアドレスを使用する必要があります。プライベート アドレス範囲を使用すると、境界ルータ上でのフィルタが簡単になります。2 番目のオクテットで 232 を使用することにより、この範囲のアドレスはプライベート アドレスおよび SSM アドレスとして簡単に認識できるため、シスコは、239.232/16 の使用を推奨しています。このマニュアルで説明する設計では、この範囲は、デフォルト MDT とデータ MDT に分割されています(データ MDT については、 「VPN マルチキャスト ルーティング」 の該当する説明を参照してください)。デフォルト MDT は 239.232.0.0-239.232.0.255 を使用し、データ MDT は 239.232.1.0-239.232.1.255 を使用します。このアドレス範囲では、PE ルータごとに最大 255 この MVRF がサポートされます。

ステップ 3 PIM-SSM 用にプロバイダー ネットワークを設定します。

次のコマンドは、基本的な PIM-SSM サービスを有効にします。

すべての P ルータおよび PE ルータ上で、次のコマンドをグローバルに設定します。

ip multicast-routing
ip pim ssm range multicast_ssm_range
ip access-list standard multicast_ssm_range
permit 239.232.0.0 0.0.1.255
 

コアに対する P インターフェイスおよび PE インターフェイス上で、次のコマンドを設定します。

ip pim sparse-mode
 

各 PE ルータで、BGP セッションへの送信に使用されるループバック インターフェイス上で次のコマンドを設定します。

ip pim sparse-mode
 

ステップ 4 VRF 上で MDT を設定します。

VRF 上でマルチキャスト ルーティングを設定するには、VRF IPICS に関してすべての PE ルータ上で次のコマンドを設定します。

ip vrf ipics
mdt default 239.232.0.0
 

VRF に対してマルチキャストを有効にするには、次のコマンドを設定します。

ip multicast-routing vrf ipics
 

ステップ 5 VPN 内で PIM モードを設定します。

VPN 内の PIM モードは、VPN カスタマーが使用している PIM のタイプによって異なります。シスコは、Auto-RP または Boot Strap Router(BSR; ブート ストラップ ルータ)を介して VPN 内で使用されるグループ モードの自動検出を行います。この場合、追加の設定は必要ありません。オプションで、プロバイダーは、PE ルータを VPN 内の RP として設定することにより、カスタマーに RP を提供するよう選択できます。この項で説明するトポロジでは、VPN カスタマーが RP サービスを提供し、PE ルータは、Auto-RP を介してグループからの Rendezvous Point(RP; ランデブー ポイント)を自動的に学習します。

PE と CE 間のすべてのインターフェイスをスパース/デンス モードで設定します。これにより、Auto-RP または BSR メッセージが受信され、転送されることが保証され、また PE が VPN 内のグループからの Rendezvous Point(RP; ランデブー ポイント)を学習できます。このためには、カスタマーに対するすべてのインターフェイスに次の設定を行います。

ip pim sparse-mode
 


 

MVPN 用のプロバイダー ネットワークの確認

「MVPN 用のプロバイダー ネットワークの構成」で示したように設定を完了した後、次の手順を使用して、設定が正しく行われたことを確認します。

手順


ステップ 1 BGP の更新を確認します。

SSM が使用されている場合、BGP は BGP-MDT 更新と呼ばれる送信元の検出を行います。PE ルータに、すべての BGP-MDT 更新が正しく受信されているかを確認するには、次のいずれかの操作を行います。

次の show ip pim mdt bgp コマンドを使用します。

PE1#show ip pim mdt bgp
Peer (Route Distinguisher + IPv4) Next Hop
MDT group 239.232.0.0
2:65019:1:10.32.73.248 10.32.73.248 (PE-2 Loopback)
2:65019:1:10.32.73.250 10.32.73.250 (PE-3 Loopback)
 

2:65019:1 は、この更新に関連付けられた RD タイプ(2)と RD(65019:1)を示します。

残りの出力は、BGP セッションの発信に使用されるアドレスです。

次の show ip bgp vpnv4 all コマンドを使用します。

PE1#show ip bgp vpnv4 all
BGP table version is 204, local router ID is 10.32.73.247
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: 65019:1 (default for vrf ipics)
*>i10.32.72.48/28 10.32.73.248 0 100 0 ?
... (output omitted)
Route Distinguisher: 2:65019:1
*> 10.32.73.247/32 0.0.0.0 0 ?
*>i10.32.73.248/32 10.32.73.248 0 100 0 ?
*>i10.32.73.250/32 10.32.73.250 0 100 0 ?
 

ステップ 2 グローバル mroute テーブルを確認します。

show ip mroute mdt-group-address コマンドを使用して、各 PE ルータに(送信元、グループ)エントリがあることを確認します。PIM-SSM が使用されているので、送信元は BGP セッションを発信するためのループバック アドレスであり、グループは設定した MDT アドレスです。トラフィックがない場合、デフォルトの MDT エントリのみ表示されます。

PE1#show ip mroute 239.232.0.0
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
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
 
(10.32.73.247, 239.232.0.0), 1w0d/00:03:26, flags: sTZ
Incoming interface: Loopback0, RPF nbr 0.0.0.0
Outgoing interface list:
FastEthernet0/0, Forward/Sparse, 1w0d/00:02:47
 
(10.32.73.248, 239.232.0.0), 1w0d/00:02:56, flags: sTIZ
Incoming interface: FastEthernet0/0, RPF nbr 10.32.73.2
Outgoing interface list:
MVRF ipics, Forward/Sparse, 1w0d/00:01:30
 
(10.32.73.250, 239.232.0.0), 1w0d/00:02:55, flags: sTIZ
Incoming interface: FastEthernet0/0, RPF nbr 10.32.73.2
Outgoing interface list:
MVRF ipics, Forward/Sparse, 1w0d/00:01:29
 

各(S,G)エントリに s フラグが設定されていることを確認します。これは、このグループが ssm モードで使用されることを示します。z フラグが設定されていることを確認します。これは、この PE ルータがマルチキャスト トンネルのリーフであることを示します。ルータがマルチキャスト トンネルのリーフの場合、基本的にはこのトラフィックの受信側になるので、このトラフィックをどの MVRF に転送するか判断するために追加の検索を行う必要があります。リモート PE(S,G)エントリに、 I フラグが設定されていることを確認します。このフラグは、ルータが SSM グループへの参加を認識していることを示します。これは、IGMPv3 ホストが、その特定チャネルへの参加を要求しているかのように取り扱われます。

ステップ 3 グローバル テーブル内の PIM ネイバーを確認します。

すべての PE ルータと P ルータに対して show ip pim neighbors コマンドを使用して、PIM ネイバーがグローバル テーブル内で適切に設定されていることを確認します。

PE1#show ip pim neighbor
PIM Neighbor Table
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
10.32.73.2 FastEthernet0/0 1w4d/00:01:21 v2 1 / DR
10.32.73.70 Serial0/2 1w4d/00:01:29 v2 1 / S
 

ステップ 4 VPN 内の PIM ネイバーを確認します。

すべての PE ルータに対して show ip pim vrf ipics neighbors コマンドを使用して、CE ルータが PIM ネイバーとして認識されていること、およびリモート PE ルータがトンネルを通して PIM ネイバーとして認識されていることを確認します。

PE1#show ip pim vrf ipics neighbor
PIM Neighbor Table
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
10.32.73.66 Serial0/0 1w3d/00:01:18 v2 1 / S
10.32.73.248 Tunnel0 3d17h/00:01:43 v2 1 / S
10.32.73.250 Tunnel0 1w0d/00:01:42 v2 1 / DR S
 

ステップ 5 VPN グループからの Rendezvous Point(RP; ランデブー ポイント)を確認します。

メイン カスタマー サイトは、VPN 内で auto-rp を使用するように設定されています。VPN IPICS は、チャネルと VTG に対して、239.192.21.64 ~ 79 の範囲のマルチキャストを使用しています。

ip pim send-rp-announce Loopback0 scope 16 group-list multicast_range
ip pim send-rp-discovery scope 16
ip access-list standard multicast_range
permit 239.192.21.64 0.0.0.15
 

show ip pim vrf ipics rp mapping コマンドを使用して、PE ルータが VPN からの RP マッピング情報を正確に学習したことを確認します。

PE1#show ip pim vrf ipics rp map
PIM Group-to-RP Mappings
 
Group(s) 239.192.21.64/28
RP 10.32.72.248 (?), v2v1
Info source: 10.32.73.62 (?), elected via Auto-RP
Uptime: 1w3d, expires: 00:02:54
 

この出力は、PE ルータが、VPN 内で使用されるグループからの Rendezvous Point(RP; ランデブー ポイント)を正確に学習したことを示します。デフォルト MDT は、マルチキャスト複製が実行される提供側ネットワークのコア内で、すべての PE ルータに到達します。デフォルト MDT のみ設定されている場合、トラフィックを受信したいかどうかにかかわらず、すべての PE ルータにトラフィックが転送されます。


 

トラフィック転送の最適化:データ MDT

データ MDT は、トラフィック転送を最適化するように設計されています。データ MDT は、オンデマンドで構築されるマルチキャスト ツリーです。データ MDT を作成する条件は、kbps で測定されるトラフィック負荷しきい値、または VPN 内の特定のソースを指定するアクセス リストに基づいています。データ MDT は、自分のサイトに接続された送信元を持つ、PE によってのみ作成されます。データ MDT の条件を設定する必要はありません。しかし、VPN 内の各(S,G)に対して条件が設定されていない場合、データ MDT が作成されます。このデータ MDT にはルータからのリソースが必要なので、送信元が存在するという理由のみでデータ MDT を作成しないことを推奨します。この値は、アクティブな送信元に対してデータ MDT の作成をトリガーするように要求するため、ゼロ以外のしきい値を推奨します。Multi-VPN Routing/Forwarding(MVRF; マルチ VPN ルーティング/転送)エントリの最大数は 256 です。

VRF 下でデータ MDT を設定するには、「MVPN 用のプロバイダー ネットワークの構成」ステップ 2 に説明されている範囲の 1 つを使用します。VRF ごとに、最大 256 のアドレスが許容されます。この制限は実装で決定されるものであり、プロトコルによる制限ではありません。SSM が使用されているため、データ MDT のアドレス範囲は、同じ VPN に関してすべての PE ルータ上で同じになる可能性があります。次のコマンドに示すように、逆マスクを使用してデータ MDT 用に使用されるアドレス数を指定します。

ip vrf ipics
mdt data 239.232.1.0 0.0.0.255 threshold 1
 

正しい MDT 動作の確認

データ MDT は、グローバル テーブル内に mroute エントリを作成します。また、PE ルータの送信と受信の機能を確認する特定のコマンドが存在します。データ MDT の動作を確認するには、設定されたしきい値を超えるサイト間にマルチキャスト トラフィックが存在する必要があります。次の例に示すように、データ MDT をテストする簡単な方法は、1 つのサイト内でマルチキャスト グループを静的に結合して、次に、別のサイトからそのグループに ping を行うことです。

CE1

interface Loopback0
ip address 10.32.72.248 255.255.255.255
ip pim sparse-mode
ip igmp join-group 239.192.21.68
 

CE2

ping 239.192.21.68 size 500 repeat 100
 

データ MDT の動作を確認するには、次の手順を実行します。


ステップ 1 送信側の PE ルータを確認します。

送信側の PE ルータ(PE2)上で show ip pim vrf ipics mdt send コマンドを使用して、データ MDT の設定を確認します。

PE2#show ip pim vrf ipics mdt send
MDT-data send list for VRF: ipics
(source, group) MDT-data group ref_count
(10.32.72.244, 239.192.21.68) 239.232.1.0 1
(10.32.73.74, 239.192.21.68) 239.232.1.1 1
 

ステップ 2 受信側の PE ルータを確認します。

受信側の PE(PE1)ルータ上で show ip pim vrf ipics mdt receive detail コマンドを使用して、データ MDT 上でこのルータが受信していることを確認します。

PE1#show ip pim vrf ipics mdt receive
 
Joined MDT-data [group : source] for VRF: ipics
[239.232.1.0 : 10.32.73.248] ref_count: 1
[239.232.1.1 : 10.32.73.248] ref_count: 1
 

この時点では、すべてのものが正しく設定されている場合、VPN IPICS 内のサイトは、MPVN を使用してマルチキャスト トラフィックを転送でき、またすべてのサイトが同じマルチキャスト ドメイン内に存在します。したがって、Cisco IPICS サーバ上のすべてのチャネルとユーザを同じロケーションで設定できます。


 

マルチキャスト アイランド

マルチキャスト アイランドは、マルチキャストが有効化されるサイトです。マルチサイト配置は、ユニキャスト専用接続を介して相互に接続される複数のマルチキャスト アイランドで構成できます。図 7-4 を参照してください。

図 7-4 マルチキャスト アイランド

 

これらのいずれかの技法を使用して、アイランド間にマルチキャスト サポートを提供できます。

「GRE 経由のマルチキャスト」

「M1:U12:M2 接続トランク」

GRE 経由のマルチキャスト

この項では、GRE 経由でマルチキャストを設定する方法の概要を示します。図 7-5 は、GRE 経由のマルチキャストによる Cisco IPICS の配置を示しています。

図 7-5 GRE トンネル経由のマルチキャスト

 

サイト 1 内のゲートウェイとサイト 2 内のゲートウェイの間にトンネルが設定されており、それぞれの loopback0 インターフェイスから発信されています。トンネル インターフェイス上で ip pim sparse-dense mode コマンドが設定されており、またゲートウェイ ルータ上でマルチキャスト ルーティングが有効になっています。トンネル インターフェイス上で設定されたスパース/デンス モードにより、グループの RP 設定に依存して、トンネルを通してスパース モードまたはデンス モードのパケットを転送できます。

次の例は、サイト 1 とサイト 2 の間で GRE 経由のマルチキャストの実装が必要な設定を示しています。サイト 1 とサイト 3 の間、およびサイト 2 とサイト 3 の間でも同じアプローチを使用します。

 
interface loopback 0
ip address 1.1.1.1 255.255.255.255
 
interface Tunnel0
ip address 192.168.3.1 255.255.255.252
ip pim sparse-mode
tunnel source Loopback0
tunnel destination 2.2.2.2
 

サイト 2

ip multicast-routing
 
interface loopback 0
ip address 2.2.2.2 255.255.255.255
 
interface Tunnel0
ip address 192.168.3.2 255.255.255.252
ip pim sparse-mode
tunnel source Loopback0
tunnel destination 1.1.1.1
 

トンネルを通して PIM スパース モードを設定する場合、次のガイドラインに確実に従ってください。

RP から共有ツリー(*,G)を通してフローするマルチキャスト トラフィックの RPF 検証が成功するためには、トンネル インターフェイスを指す RP アドレスに対して ip mroute rp-address nexthop コマンドを設定します。

たとえば、サイト 1 が RP(RP アドレス 10.1.1.254)を持つと仮定します。この場合、サイト 2 内のゲートウェイに対する mroute は ip mroute 10.1.1.254 255.255.255.255 tunnel 0 コマンドとなり、共有ツリーを通してフローするトラフィックに対する RPF チェックの成功が保証されます。

Shortest Path Tree(SPT)を通してフローするマルチキャスト(S,G)トラフィックの RPF 検証が成功するためには、各ゲートウェイ ルータ上のトンネル インターフェイスを指すマルチキャスト送信元に対して ip mroute source-address nexthop コマンドを設定します。

この場合、SPT トラフィックがトンネル インターフェイスを通してフローするときに、サイト 2 ゲートウェイに対して ip mroute 10.1.1.0 255.255.255.0 tunnel 0 コマンドを設定し、サイト 1 ゲートウェイに対して ip mroute 10.1.2.0 255.255.255.0 tunnel 0 コマンドを設定します。この設定により、Tu0 インターフェイスを通して着信するマルチキャスト パケットに対する RPF 検証の成功が保証されます。

GRE 経由のマルチキャストを使用する際の帯域幅に関する考慮事項

Cisco IPICS は、G.711 コーデックまたは G.729 コーデックのいずれかで動作します。 表 7-1 に、使用するコーデック、ペイロード サイズ、および cRTP、VAD、またはその両方が設定されているかどうかに基づいて、ユニキャスト接続トランクを通した音声コールの帯域幅要件の一覧を示します。

 

表 7-1 ユニキャスト接続トランクに関する帯域幅の考慮事項

圧縮方法
ペイロード サイズ(バイト)
フル レート帯域幅(kbps)
cRTP での帯域幅(kbps)
VAD での帯域幅(kbps)
cRTP および VAD での帯域幅(kbps)

G.711

240

76

66

50

43

G.711

160

83

68

54

44

G.729

40

17.2

9.6

11.2

6.3

G.729

29

26.4

11.2

17.2

7.3

トンネル経由の帯域幅使用量は、サイト間で通信を行うアクティブなチャネル数、VTG 数、IDC ユーザ数によって異なります。

次に、トンネル経由の帯域幅使用量を計算する方法の例を示します。

ケース 1:サイト 1 とサイト 2 のアクティブなチャネル

サイト 1 のすべてのユーザが 1 つのチャネルを使用し、サイト 2 のすべてのユーザはもう 1 つチャネルを使用しています。トンネルを介してフローするマルチキャスト音声はありません。

ケース 2:サイト 1 で n ユーザがアクティブ チャネルを使用し、サイト 2 で m ユーザがアクティブ チャネルを使用します。

次の例では、コール帯域幅は表 4-2からの帯域幅の値です。

帯域幅 1 = コール帯域幅 * n(サイト 1 からサイト 2 にフロー)

帯域幅 2 = コール帯域幅 * m(サイト 2 からサイト 1 にフロー)

合計帯域幅 = 帯域幅 1 + 帯域幅 2

(コール帯域幅は表 3-1 の値です)

アクティブなチャネル数、チャネルごとのアクティブなユーザ数、チャネルが複数のサイトにまたがっているかどうかによって、帯域幅の使用状況は大幅に異なります。

IPSec VPN

IPSec VPN は、マルチキャスト GRE トンネル経由で実装できます。図 7-6 を参照してください。

図 7-6 マルチキャスト GRE トンネル経由の IPSec

 

GRE トンネル経由の IPSec は、数多くの方法で設定できます。該当するシスコ製品マニュアルを参照してください。

M1:U12:M2 接続トランク

M1:U12:M2 接続トランクは、Cisco IPICS アイランド間のリアルタイム マルチキャスト音声トラフィックの転送に関して、GRE トンネルを通したマルチキャストの代替機能を提供します。たとえば、図 7-7 に示す状況について考えてみます。

図 7-7 ユニキャスト専用サイト間接続

 

この例では、Stocks and Bonds 社がシカゴとニューヨークにオフィスを持っています。各ロケーションには、Cisco IPICS サーバに設定されている 2 つのチャネルがあります。シカゴとニューヨーク間にはマルチキャスト サポートが存在しないため、このシナリオでは、それぞれ RP を持つマルチキャスト ドメインを区切る必要があります。Cisco IPICS サーバに設定されたロケーションは、シカゴとニューヨークという 2 つのマルチキャスト ドメインを表します。シカゴのチャネルと RMS は、ロケーション シカゴで設定する必要があり、ニューヨークのチャネルと RMS は、ロケーション ニューヨークで設定する必要があります。

シカゴのユーザは、Chicago Bonds チャネルまたは Chicago Stocks チャネルを使用して、互いに通信できます。ニューヨークのユーザは、New York Bonds チャネルまたは New York Stocks チャネルを使用して、互いに通信できます。

Chicago Stocks および Chicago Bonds は、VTG に配置できます。これら両チャネルのロケーションはシカゴなので、Cisco IPICS サーバはシカゴ内の RMS を使用して、これらのチャネルを混合します。同様に、New York Stocks および New York Bonds も、VTG に配置できます。これら両チャネルのロケーションはニューヨークなので、Cisco IPICS サーバはニューヨーク内の RMS を使用して、これらのチャネルを混合します。

ドメイン間 VTG は作成できません。VTG は自動的にロケーション All を持ちますが、VTG 内のすべてのチャネルとユーザは、同じマルチキャスト ドメイン内にあることが前提になります。図 7-8 に示すように、M1:U12:M2 接続トランクを使用することで、この制限に対処できます。

図 7-8 M1:U12:M2 接続トランク

 

この例では、Chicago Bonds および New York Bonds で構成される VTG が必要であるとします。M1:U12:M2 接続トランクは、ユニキャスト VoIP ネットワークを通してこのトラフィックを転送するために、New York Bonds チャネル(M1)からユニキャスト アドレス(U1)にマルチキャスト トラフィックをマップします。Chicago RMS によって受信されたユニキャスト トラフィックは、マルチキャスト アドレス M2 にマップされます。M2 マルチキャスト アドレスは、シカゴの New York Bonds プロキシ チャネルに割り当てられ、Chicago Bonds チャネルと共に VTG に配置されます。M2 には、シカゴ マルチキャスト ドメインで、有効なマルチキャスト アドレスを割り当てる必要があります。競合を回避するために、マルチキャスト プールの一部であるアドレスや、その他のチャネルで使用されるアドレスを割り当てないでください。

ほとんどの配置では、チャネルの使用に割り当てられるアドレスの範囲があります。次に、アドレスの範囲に対する一般的なアプローチの一覧を示します。

239.192.21.1 ~ 16:チャネル アドレス

239.192.21.17 ~ 32:VTG アドレス

また、次のアドレスが割り当てられているとします。

239.192.21.1:Chicago Bonds

239.192.21.2:Chicago Stocks

239.192.21.3:New York Bonds

239.192.21.4:New York Stocks

ここで、その次の空きアドレス 239.192.21.5 が、M2 に使用されるとします。VTG は、チャネルまたはユーザまたはその両方を含みます。作成された VTG は、Chicago Bonds チャネルを含みますが、New York Bonds を表すチャネルも含める必要があります。New York Bonds チャネルは、シカゴ内の RMS によって到達可能なマルチキャストではないので、VTG に配置できません。したがって、シカゴのロケーション内で New York Bonds チャネルを表すための、プロキシ チャネルが必要です。

New York Bonds プロキシ

239.192.21.5:ロケーション シカゴ

図 7-9 に、シカゴ内で New York Bonds チャネルをプロキシする方法を示します。

図 7-9 プロキシ チャネル

 

Cisco IPICS サーバに Chicago New York Bonds という VTG を作成する場合、VTG は Chicago Bonds と New York Bonds プロキシの 2 つのチャネルを含みます。Cisco IPICS サーバは、シカゴ内に RMS を設定し(両チャネルにロケーション シカゴがある)、VTG に 2 つのチャネルを混合します。Cisco IPICS は、VTG 用に 239.192.21.17 というマルチキャスト アドレスを使用するとします。チャネルを VTG に、そして VTG をチャネルに混合するためには、Chicago RMS に 2 つの DS0 のペアが必要です。図 7-10 に、VTG Chicago New York Bonds の Cisco IPICS サーバによって実行される Chicago RMS の設定を示します。この RMS 設定は、2 チャネル VTG の標準です。

図 7-10 Cisco IPICS サーバによって実行される VTG 設定

 

M1:U12:M2 接続トランクを実装するには、RMS を手動で設定する必要があります。この設定は、New York Bonds から VTG に、および VTG から New York Bonds に、トラフィックを転送するために必要です。図 7-11 を参照してください。

図 7-11 M1:U12:M2 トランク設定

 

図 7-12 に、ニューヨークから VTG へのトラフィック フローを示します。この例では、ニューヨークのユーザが LMR ゲートウェイに接続されている IDC、Cisco Unified IP Phone、または無線のいずれかを使用して、New York Bonds チャネル上で通話しています。Cisco IPICS サーバ上でチャネルが設定されている場合、宛先アドレスは、チャネルに割り当てられたマルチキャスト アドレスです。このトラフィックが New York RMS に到達すると、接続トランクを通して、ユニキャストとして Chicago RMS に送信されます。Chicago RMS は、ニューヨークからのユニキャスト トラフィックを New York Bonds プロキシ チャネルにマップし、それが VTG にマップされ、さらに Chicago Bonds チャネルにマップされます。VTG チャネルまたは Chicago Bonds チャネルのいずれかでリッスンしているすべてのユーザが、トラフィックを受信します。

図 7-12 New York Bonds から VTG および Chicago Bonds

 

図 7-13 に、VTG から New York Bonds へのトラフィック フローを示します。この例では、VTG チャネル上で通話しているシカゴのユーザが、マルチキャスト グループ 239.192.21.17 にトラフィックを送信します。このトラフィックは、Chicago RMS に到達すると、New York Bonds プロキシ チャネルと Chicago Bonds チャネルの両方に混合されます。New York Bonds プロキシ チャネルにマップされたトラフィックは、ニューヨークへの接続トランクを通してユニキャストとして送信され、New York Bonds チャネルに混合されます。

図 7-13 VTG から Chicago Bonds および New York Bonds

 

図 7-14 に、Chicago Bonds から New York Bonds へのトラフィック フローを示します。

図 7-14 Chicago Bonds から VTG および New York Bonds

 

トラフィックが VTG(図 7-13)から送られてくるか、または Chicago Bonds(図 7-14)から送られてくるかは、VTG の設定によって異なります。VTG は、チャネルまたはユーザまたはその両方を含む場合があります。VTG がチャネルのみ(Chicago Bonds と New York Bonds プロキシ)で作成されている場合、シカゴのユーザには、IDC または Cisco Unified IP Phone 上に VTG チャネルが表示されません。さらに、Chicago Bonds チャネル上のシカゴのユーザ、または New York Bonds チャネル上のニューヨークのユーザは、自分が VTG 内にいることを認識しません。シカゴのユーザは、Chicago Bonds チャネルで送受信を行い、ニューヨークのユーザは、New York Bonds チャネルで送受信を行います。VTG チャネルから送受信するトラフィックのみ、Chicago RMS の内部になります。

Chicago Bonds チャネルに関連付けられたユーザが VTG 内に配置される場合、VTG が、その IDC または Cisco Unified IP Phone に表示されます。次にユーザは、Chicago Bonds チャネルまたは VTG チャネルのいずれかをアクティブ化します。VTG チャネルをアクティブ化すると、そのトラフィックは VTG マルチキャスト アドレスに送信され、Chicago RMS 上で Chicago Bonds および New York Bonds プロキシ チャネルに混合されます。New York Bonds に関連付けられたユーザはニューヨーク ロケーションに存在し、VTG がシカゴの RMS 上で混合されるため、New York Bonds に関連付けられたユーザが VTG に配置されることはありません。

このソリューションは対称型です。VTG は、ニューヨークのロケーションで New York Bonds チャネルを使用して、Chicago Bonds プロキシで作成することもできます。このケースでは、Cisco IPICS は、Chicago RMS の代わりに New York RMS を使用し、その動作は前に示した例と同じになります。

ユニキャスト接続トランクの設定

ここでは、ユニキャスト接続トランクで M1:U12:M2 Chicago および New York Stocks と Bonds のシナリオを有効にするのに必要な、手動 RMS 設定について説明します。

図 7-15 は、シカゴとニューヨーク間で設定する必要のあるユニキャスト接続トランクのコンポーネントを示しています。

図 7-15 ユニキャスト接続トランクのコンポーネント

 

ダイヤル番号(LMR、IDC、または Cisco Unified IP Phone からのもの)は存在しないため、 connection trunk digits コマンドを使用して、ダイヤル番号を内部的に生成し、また VoIP ダイヤル ピアと一致させます。また、 connection trunk コマンドは、RMS ルータ間で固定 VoIP コールを設定します。次の設定例では、RMS 上で T1 リソースを使用することを想定し、また T1 ポートが次のように設定されていると想定しています。

controller T1 0/0
framing esf
clock source internal
linecode b8zs
cablelength short 133
ds0-group 0 timeslots 24 type e&m-lmr
ds0-group 1 timeslots 1 type e&m-lmr
...
ds0-group 23 timeslots 23 type e&m-lmr
 

RMS 上で T1 リソースを使用している場合、Cisco IPICS は、接続トランクで使用される DS0 を使用しないように設定する必要があります。

次の設定例では、0/0 および 0/1 上で RMS T1 ループ バックからの DS0 リソースを使用するため、音声ポートを明示的にブロックして、Cisco IPICS サーバによって動的に割り当てられるのを防止する必要があります。DS0 をブロックするには、Cisco IPICS 管理コンソールを使用して、Chicago RMS 内でポート 0/0:2 を無効にし、また New York RMS 内でポート 0/0:0 を無効にします(手順については、『 Cisco IPICS Server Administration Guide, Release 4.0(2) 』の「Viewing and Configuring Loopbacks」の項を参照してください)。DS0 が予約済みの状態の場合、RMS は、それらを動的に割り当てようとしません。


) RMS を手動で設定する前に、RMS DS0 リソースが無効になっていることを確認してください。無効になっていない場合には、RMS が手動の設定を上書きする可能性があります。


次の表は、Chicago RMS および New York RMS コンポーネント内の接続トランクの U1 部分と U2 部分を設定するのに必要な手動設定について説明しています。Session Target フィールドで、RMS 名の代わりにそれぞれの RMS Loopback0 IP アドレスを使用します。

 

次の表は、M1:U12:M2 接続トランクの M1 の部分を有効にするために、New York RMS で音声ポートとダイヤル ピアのエントリを設定するのに必要な手動コマンドを示しています。

 

ニューヨーク マルチキャスト音声ポート

voice-port 0/1:0
voice-class permanent 1
auto-cut-through
lmr m-lead audio-gate-in
lmr e-lead voice
no echo-cancel enable
no comfort-noise
timeouts call-disconnect 3
timing hookflash-in 0
timing hangover 80
connection trunk 2001

ニューヨーク マルチキャスト ダイヤル ピア M1

dial-peer voice 3 voip
destination-pattern 2001
session protocol multicast
session target ipv4:239.192.21.3:21000
(New York Bonds M1)
codec g711ulaw
voice-class permanent 1

次の表は、M1:U12:M2 接続トランクの M2 の部分を有効にするために、Chicago RMS で音声ポートとダイヤル ピアのエントリを設定するのに必要な手動コマンドを示しています。

 

シカゴ マルチキャスト音声ポート

voice-port 0/0:2
voice-class permanent 1
auto-cut-through
lmr m-lead audio-gate-in
lmr e-lead voice
no echo-cancel enable
no comfort-noise
timeouts call-disconnect 3
timing hookflash-in 0
timing hangover 80
connection trunk 1001

シカゴ マルチキャスト ダイヤル ピア M2

dial-peer voice 3 voip
destination-pattern 1001
session protocol multicast
session target ipv4:239.192.21.5:21000
(New York Bonds Proxy M2)
codec g711ulaw
voice-class permanent 1

接続トランクの検証

次の出力は、RMS 内で接続トランクのステータスの確認に使用できる Cisco IOS コマンドを示しています。この出力例では、使用されているダイヤル ピアが示されており、またトランク接続が接続状態であることが示されています。

New York#show voice call status
CallID CID ccVdb Port DSP/Ch Called # Codec Dial-peers
0xF 11F0 0x6772A350 0/0:0.24 0/13:1 2000 g729r8 2/1
0x11 11F3 0x67729198 0/1:0.24 0/13:3 2001 g711ulaw 0/3
2 active calls found
 
Chicago#show voice call summary | i TRUNKED
0/1:2.24 g729r8 y S_CONNECT S_TRUNKED
0/0:2:0.24 g711ulaw y S_CONNECT S_TRUNKED

ユニキャスト接続トランクに関する帯域幅の考慮事項

Hoot & Holler 混合アルゴリズムについては 第 2 章「Cisco IPICS コンポーネントの考慮事項」 に、帯域幅に関する考慮事項については 第 4 章「Cisco IPICS インフラストラクチャの考慮事項」 に、それぞれ説明があります。1 つのユニキャスト接続トランクに必要な帯域幅の要件を決定するには、1 つの音声ストリームの帯域幅要件について、表 4-2 を参照してください。

たとえば、G.729 コーデックを使用すると、ペイロード サイズ 20 バイト、VAD での cRTP では、7.3 kbps が必要になります。

この計算は、1 つの接続トランクの帯域幅に対するものです。複数の接続トランクを使用する場合、この数にトランクス数を乗算します。

マルチキャストの特異点

マルチキャストの特異点は、マルチキャスト アイランド シナリオの限定的なケースです。サイト間では、マルチキャスト ルーティングが有効になっていません。サイト内では、マルチキャストは、Cisco IPICS 固有のデバイスである RMS、LMR ゲートウェイ、IDC、および Cisco Unified IP Phone でのみ有効になっています。これらの Cisco IPICS デバイスは、図 7-16 に示すように、マルチキャストの特異点に存在します。

図 7-16 マルチキャストの特異点

 

特異点は、GRE トンネル経由のマルチキャスト(図 7-17 に示す)を使用するか、または M1:U12:M2 接続トランク(図 7-18 に示す)を使用して接続できます。

図 7-17 GRE トンネルでのマルチキャスト特異点

 

図 7-18 M1:U12:M2 接続トランクでのマルチキャスト特異点

 

GRE トンネル経由のマルチキャストは、マルチキャスト アイランドのシナリオと同じですが、ゲートウェイ ルータがマルチキャスト用に有効ではないため、ゲートウェイ ルータの間ではなく RMS ルータ間でトンネルを設定しなければならない点が異なります。

M1:U12:M2 接続トランクの設定は、マルチキャスト アイランドのシナリオと同じです。いずれの場合でも、RMS ルータ間でトランクを設定する必要があります。

マルチキャスト特異点には、次のルールが適用されます。

1. すべての RMS ゲートウェイと LMR ゲートウェイが、マルチキャスト特異点内に存在しければならない。つまり、これらのデバイスは、直接接続されたマルチキャスト対応 LAN 上になければならない。

2. マルチキャスト特異点内のすべてのユーザは、マルチキャストが有効なゾーン内に存在するため、IDC または Cisco Unified IP Phone を使用できる。

3. マルチキャスト特異点の外側にいるユーザは、ロケーションとしてリモートを使用して接続する場合には、IDC を使用できる。

4. Cisco Unified IP Phone はマルチキャストのみをサポートするため、マルチキャスト特異点の外側にいるユーザは、Cisco Unified IP Phone を使用できない。

同じサイト内に複数のマルチキャスト特異点を持つことができます。そして、これらの特異点は、GRE トンネル経由のマルチキャストで接続できます。このソリューションは、構成のポリシーによって異なります。