Cisco Unified Wireless のマルチキャスト設計
はじめに
この章では、Cisco Unified Wireless Network の IP マルチキャスト転送について説明し、ワイヤレス環境でのマルチキャストの展開方法に関する情報を提供します。マルチキャスト パフォーマンス機能を使用するための前提条件として、マルチキャスト対応ネットワークが、コントローラとアクセス ポイント(AP)の間のすべてのルータに設定されている必要があります。マルチキャストをサポートしないネットワークに対応するため、コントローラでは元のユニキャスト パケット転送メカニズムも引き続きサポートされます。
IP マルチキャストは、情報を宛先のグループに配信するためのプロトコルです。IP マルチキャストでは、ネットワークのそれぞれのリンク上で情報を配信する最も効率的な戦略を使用しています。ネットワークのそれぞれのホップで情報のコピーが 1 つだけ送信され、宛先へのリンクが分かれる場合にのみコピーが作成されます。通常、現在のネットワーク アプリケーションの多くはユニキャスト パケットを使用します。すなわち、1 つの送信元に 1 つの宛先が対応します。しかし、複数の受信先で同じデータが必要な場合、送信元からすべての受信先に対して個別のユニキャスト パケットとしてデータを複製すると、ネットワークの負荷が増大します。IP マルチキャストによって、動的に形成された一連の受信先に一連の送信元から効率的にデータを転送できます。
現在、受信先の大規模なグループに宛てた一方向のストリーミング メディア(ビデオなど)には、通常 IP マルチキャストが使用されています。多くのケーブル テレビ局、教育機関、および大企業では、コンテンツ配信のために IP マルチキャストが展開されています。さらに、マルチキャストを使用した音声およびビデオ会議も利用されています。その他、キャンパスおよび商用ネットワークでマルチキャストが広く使用されている例として、ファイルの配信があります。特に、オペレーティング システムのイメージおよびアップデートをリモート ホストに配信する場合などです。また、金融部門において、株価情報表示および hoot-n-holler システムなどのアプリケーションのために IP マルチキャストが展開されています。
IPv4 マルチキャスト転送の概要
Cisco Unified Wireless Network ソフトウェアのリリースでは、ワイヤレス ネットワークで効果的にマルチキャストを使用するためのサポートが強化されています。
現在の Cisco Unified Wireless マルチキャスト サポートでは、ファースト ホップ ルータに接続されている VLAN からコントローラが受信した各マルチキャスト フレームがコピーされ、アソシエートされている AP のコントローラで設定されたマルチキャスト グループに送信されます(図 6-1 を参照)。マルチキャスト パケットを含むマルチキャスト CAPWAP パケットでは、WLAN ビットマップを使用します。WLAN ビットマップからは、パケットの転送に使用する必要がある WLAN の受信側 AP が通知されます。AP が CAPWAP パケットを受信すると、AP は外部 CAPWAP カプセル化を解除し、CAPWAP WLAN ID ビットマスクで識別された(WLAN にアソシエートされているすべての無線上の)WLAN にマルチキャスト パケットを送信します。
図 6-1 マルチキャスト転送メカニズム
グローバル マルチキャスト モードを有効にすると、各アクセス ポイントにマルチキャスト パケットが配信されます。これにより、ネットワーク内のルータが標準的なマルチキャスト テクノロジーを使用して、AP に対してマルチキャスト パケットを複製および配信できるようになります。CAPWAP マルチキャスト グループの場合は、コントローラがマルチキャスト送信元になり、AP がマルチキャスト受信側になります。
(注) マルチキャスト パフォーマンス機能を使用するための前提条件として、マルチキャスト対応ネットワークが、コントローラと AP の間のすべてのルータに設定されます。マルチキャストをサポートしないネットワークに対応するため、コントローラでは元のユニキャスト パケット転送メカニズムも引き続きサポートされます。
(注) マルチキャストが有効になっていると、ファースト ホップ ルータから VLAN 上で受信されたマルチキャスト パケットはその種類にかかわらず、HSRP hello パケット、すべてのルータ、ルーティング プロトコルおよび PIM マルチキャスト パケットを含め、ワイヤレス ネットワーク経由で送信されます。
管理者がマルチキャストを有効にして(マルチキャスト モードはデフォルトで無効になっています)、CAPWAP マルチキャスト グループを設定し、IGMP スヌーピングを有効にすると、コントローラへの通常の参加プロセス中(ブート時)に、アクセス ポイントがコントローラの CAPWAP マルチキャスト グループのアドレスをダウンロードします。アクセス ポイントがコントローラに参加し、コントローラの設定をダウンロードした後、その AP はコントローラの CAPWAP マルチキャスト グループに参加するための Internet Group Management Protocol(IGMP)Join 要求を発行します。これにより、マルチキャスト対応ルータで、コントローラと AP の間のマルチキャスト ステートに関する通常のセットアップが開始されます。マルチキャスト グループの送信元 IP アドレスは、レイヤ 3 モードに使用される AP マネージャの IP アドレスではなく、コントローラの管理インターフェイスの IP アドレスです。AP がコントローラの CAPWAP マルチキャスト グループに参加すると、クライアントのマルチキャスト トラフィックのマルチキャスト アルゴリズムは次のように動作します。
マルチキャスト グループの送信元が有線 LAN 上にある場合
- コントローラでは、ファースト ホップ ルータ上の任意のクライアント VLAN からマルチキャスト パケットを受信した場合、管理インターフェイスを介して、ベスト エフォートの QoS 分類で、CAPWAP マルチキャスト グループにパケットを送信します。CAPWAP マルチキャスト パケットの QoS ビットは、最低レベルでハードコード化されており、ユーザが変更することはできません。
- マルチキャスト対応ネットワークでは、CAPWAP マルチキャスト パケットが、CAPWAP マルチキャスト グループに参加している各アクセス ポイントに配信されます。このときルータでは、マルチキャスト パケットがすべての AP に到達するように、必要に応じて配信時にパケットを複製する通常のマルチキャスト メカニズムが使用されます(図 6-1 を参照)。これにより、コントローラでは、マルチキャスト パケットを複製する必要がなくなります。
- アクセス ポイントでは他のマルチキャスト パケットを受信できますが、現在の参加先のコントローラから受信したマルチキャスト パケットだけが処理され、その他のコピーは破棄されます。元のマルチキャスト パケットの送信元である VLAN インターフェイスに複数の WLAN が関連付けられていた場合、AP は各 WLAN を使用してマルチキャスト パケットを送信します(CAPWAP ヘッダー内の WLAN ビットマップに従う)。さらに、WLAN が両方の無線(802.11g と 802.11a)上にある場合、関連付けられたクライアントがあれば、そのクライアントでマルチキャスト トラフィックを要求しなかった場合でも、両方の無線で WLAN SSID 宛てにマルチキャスト パケットが送信されます。
マルチキャスト グループの送信元がワイヤレス クライアント上にある場合
- マルチキャスト パケットは、標準のワイヤレス クライアント トラフィック同様に、AP からコントローラへの(CAPWAP カプセル化された)ユニキャストです。
- コントローラは、マルチキャスト パケットのコピーを 2 つ作成します。1 つ目のコピーは、マルチキャスト パケットを受信した WLAN に関連付けられている VLAN から送信されます。これにより、有線 LAN 上の受信先でマルチキャスト ストリームを受信できるようになり、ルータで新しいマルチキャスト グループを認識できるようになります。パケットの 2 つ目のコピーは、CAPWAP カプセル化され、ワイヤレス クライアントでマルチキャスト ストリームを受信できるように、CAPWAP マルチキャスト グループに送信されます。
ワイヤレス マルチキャスト ローミング
ワイヤレス環境のマルチキャスト クライアントでは、WLAN 内を移動するときのマルチキャスト グループ メンバーシップの維持が大きな課題となります。AP 間の移動時にワイヤレス接続でパケットがドロップすると、クライアントのマルチキャスト アプリケーションが中断する場合があります。グループ メンバーシップ情報の動的メンテナンスでは、Internet Group Management Protocol(IGMP)が重要な役割を果たします。
IGMP の基本的な知識は、クライアントのマルチキャスト セッションがネットワーク内を移動するときに何が起こっているかを理解するために重要です。レイヤ 2 ローミングの場合、適切に設定されている外部 AP であればすでにそのマルチキャスト グループに属しており、トラフィックはネットワーク上の別のアンカー ポイントにトンネリングされないため、セッションはそのまま維持されます。レイヤ 3 ローミング環境では仕組みがもう少し複雑で、コントローラに設定したトンネリング モードによって異なっており、ワイヤレス クライアントから送信された IGMP メッセージに影響します。コントローラ上のデフォルトのモビリティ トンネリング モードは非対称です。“Cisco Unified Wireless のテクノロジーおよびアーキテクチャ,”で説明したとおり、これは、クライアントへのリターン トラフィックがアンカー WLC に送信されてから、関連付けられたクライアント接続が配置されている外部 WLC に転送されることを意味します。発信パケットは、外部 WLC インターフェイスに向けて転送されます。同期モビリティ トンネリング モードでは、着信と発信の両方のトラフィックがアンカー コントローラまでトンネリングされます。モビリティ トンネリングの詳細については、Chapter2, “Cisco Unified Wireless のテクノロジーおよびアーキテクチャ”を参照してください。
非対称マルチキャスト トンネリング
非対称マルチキャスト トンネリングでは、別の WLC にアソシエートされた別のサブネット上の新しい AP にクライアントが移動すると、外部 WLC によってマルチキャスト グループ メンバーシップがクエリされ、IGMP グループ メンバーシップ レポートが送信されます。IGMP グループ メンバーシップ レポートは VLAN に割り当てられた外部 WLC 動的インターフェイスに転送され、クライアントは外部サブネットを介してマルチキャスト ストリームに再度参加します。図 6-2 では、通常のデータとマルチキャスト データのトラフィック フローを示します。
図 6-2 非対称トンネリング
(注) クライアントが移動する場合、マルチキャスト セッションにわずかな中断が生じるため、アプリケーションによっては使用に適していない場合があります。
マルチキャスト対応ネットワーク
新しいマルチキャスト パフォーマンス機能を使用するための前提条件として、マルチキャスト対応ネットワークが、コントローラと AP の間のすべてのルータに設定されます。マルチキャスト対応ネットワークでは、パケットをネットワーク上の多数のホストに効率的な方法で配信できます。IP マルチキャストは、単一の情報ストリームを企業の何千もの受信者に同時に配信することによってトラフィックを削減する技術であり、帯域幅を大量に消費します。パケットは、ネットワーク内の各レイヤ 3 ポイントで必要に応じて複製されます。コントローラと AP の間に複数のルータがある場合は、PIM などのマルチキャスト ルーティング プロトコルが必要です。マルチキャスト対応ネットワークの設定の詳細については、次の URL を参照してください。 http://www.cisco.com/go/multicast
CAPWAP マルチキャスト予約ポートおよびアドレス
コントローラは、5246、5247、および 5248 の宛先ポートを持つマルチキャスト グループに送信されたすべてのマルチキャスト パケットをブロックします。また、マルチキャスト グループ アドレスが、コントローラの CAPWAP マルチキャスト グループ アドレスと同じパケットはすべて、コントローラでブロックされます。これによって、フラグメント化された CAPWAP カプセル化パケットが、別のコントローラから再送信されることを防止できます(詳細については、フラグメンテーションと CAPWAP マルチキャスト パケットを参照)。ネットワーク上のマルチキャスト アプリケーションで、これらの予約ポートまたは CAPWAP マルチキャスト グループ アドレスを使用しないようにしてください。
コントローラでの IPv4 マルチキャスト転送の有効化
コントローラ経由の IP マルチキャスト トラフィックはデフォルトで無効になっています。マルチキャスト トラフィックが無効な場合、WLAN クライアントはマルチキャスト トラフィックを受信できません。WLAN クライアントに対してマルチキャスト トラフィックを有効にするには、次の手順に従います。
IPv4 マルチキャスト モードの有効化(GUI)
ステップ 1 [Controller] > [Multicast] の順に選択して [Multicast] ページを開きます。
ステップ 2 [Enable Global Multicast Mode] チェックボックスをオンにして、マルチキャスト パケットの送信を設定します。デフォルト値は [disabled] です。
(注) FlexConnect では、ユニキャスト モードのみがサポートされています。
ステップ 3 IGMP スヌーピングを有効にする場合は、[Enable IGMP Snooping] チェックボックスをオンにします。IGMP スヌーピングを無効にするには、チェックボックスをオフのままにします。デフォルト値は [disabled] です。
ステップ 4 IGMP タイムアウトを設定するには、30 ~ 7200 秒の範囲内の値を [IGMP Timeout] テキスト ボックスに入力します。特定のマルチキャスト グループに対してクライアントが存在するかどうかを確認するために、コントローラから、1 つのタイムアウト値につき 3 つのクエリーが timeout/3 の間隔で送信されます。クライアントから、IGMP レポートを通じて応答を受け取らなかった場合、コントローラはこのクライアントのエントリを MGID テーブルからタイムアウトします。特定のマルチキャスト グループに対するクライアントが残されていない場合、クライアントは IGMP タイムアウト値が経過するまで待ってから、コントローラから MGID エントリを削除します。一般的な IGMP クエリー(つまり、宛先アドレス 224.0.0.1)がコントローラによって必ず生成され、MGID 値 1 を使用してすべての WLAN 上で送信されます。
ステップ 5 IGMP クエリー間隔(秒数)を入力します。
IGMP スヌーピングが無効になっている場合は、次のようになります。
- コントローラは、マルチキャスト データをアクセス ポイントへ送信する際は必ずレイヤ 2 MGID を使用します。作成された各インターフェイスには、1 つのレイヤ 2 MGID が割り当てられます。たとえば、管理インターフェイスの MGID は 0 となります。また、作成された 1 つ目の動的インターフェイスに割り当てられる MGID は 8 となり、動的インターフェイスが作成されるにつれて 1 増えます。
- クライアントからの IGMP パケットはルータへ転送されます。それにより、ルータの IGMP テーブルは、最後のレポータとしてクライアントの IP アドレスで更新されます。
IGMP スヌーピングが有効になっている場合は、次のようになります。
- コントローラは、アクセス ポイントへ送信されるすべてのレイヤ 3 マルチキャスト トラフィックに必ずレイヤ 3 MGID を使用します。すべてのレイヤ 2 マルチキャスト トラフィックについては、引き続きレイヤ 2 MGID を使用します。
- ワイヤレス クライアントからの IGMP レポート パケットは、クライアントに対するクエリーを生成するコントローラによって消費または吸収されます。ルータによって IGMP クエリーが送信されると、コントローラによって IGMP レポートが送信されます。このレポートでは、コントローラのインターフェイス IP アドレスがマルチキャスト グループのリスナー IP アドレスとして設定されています。それにより、ルータの IGMP テーブルは、マルチキャスト リスナーとしてコントローラ IP アドレスで更新されます。
- マルチキャスト グループをリッスンしているクライアントが、あるコントローラから別のコントローラへローミングしたときは、リッスンしているクライアント用のすべてのマルチキャスト グループ情報が、最初のコントローラから 2 番目のコントローラへ送信されます。それにより、2 番目のコントローラは、クライアント用のマルチキャスト グループ情報をただちに作成できます。2 番目のコントローラでは、クライアントがリッスンしていた全マルチキャスト グループのネットワークに IGMP レポートが送信されます。このプロセスは、クライアントへのマルチキャスト データのシームレスな転送に役立ちます。
- リッスンしているクライアントが、別のサブネットのコントローラにローミングした場合は、マルチキャスト パケットは、Reverse Path Filtering(RPF; 逆方向パス転送)のチェックを避けるために、クライアントのアンカー コントローラへトンネリングされます。アンカーは、マルチキャスト パケットをインフラストラクチャ スイッチへ転送します。MGID はコントローラ固有です。2 つの異なるコントローラの同一 VLAN から送られて来る同一マルチキャスト グループのパケットは、2 つの異なる MGID へマップされる可能性があります。
(注) Cisco WLC の VLAN ごとにサポートされるマルチキャスト アドレス数は 100 です。
ステップ 6 マルチキャスト対応ネットワークがある場合は、[AP Multicast Mode] ドロップダウン リストから [Multicast] を選択して、ネットワークがパケットを複製する方式を使用します。
ステップ 7 マルチキャスト対応ネットワークがない場合は、[AP Multicast Mode] ドロップダウン リストから [Unicast] を選択して、コントローラがパケットを複製する方式を使用します。
ステップ 8 [AP Multicast Mode] ドロップダウン リストから [Multicast] を選択し、マルチキャスト グループ アドレスを入力します。図 6-3 にオプションを示します。
図 6-3 GUI を使用してイーサネット マルチキャスト モードを有効にするコマンド
マルチキャスト モードについて
ネットワークがパケット マルチキャストをサポートしている場合は、コントローラで使用されるマルチキャストの方法を設定できます。
コントローラは次の 2 つのモードでマルチキャストを実行します。
ユニキャスト モード:コントローラにアソシエートしているすべてのアクセス ポイントに、すべてのマルチキャスト パケットがユニキャストされます。このモードは非効率的ですが、マルチキャストをサポートしないネットワークでは必要な場合があります。
マルチキャスト モード:マルチキャスト パケットは CAPWAP マルチキャスト グループに送信されます。この方法では、コントローラ プロセッサのオーバーヘッドが軽減され、パケット レプリケーションの作業はネットワークに移されます。これは、ユニキャストを使った方法より、はるかに効率的です。
マルチキャスト モードが有効な場合に、コントローラがマルチキャスト パケットを有線 LAN から受信すると、コントローラは CAPWAP を使用してパケットをカプセル化し、CAPWAP マルチキャスト グループ アドレスへ転送します。コントローラは、必ず管理インターフェイスを使用してマルチキャスト パケットを送信します。マルチキャスト グループのアクセス ポイントはパケットを受け取り、クライアントがマルチキャスト トラフィックを受信するインターフェイスにマップされたすべての BSSID にこれを転送します。アクセス ポイントからは、マルチキャストはすべての SSID に対するブロードキャストのように見えます。
マルチキャストの展開に関する考慮事項
CAPWAP マルチキャスト アドレスを選択する際の推奨事項
注意
お勧めはしませんが、OSPF、EIGRP、PIM、HSRP、およびその他のマルチキャスト プロトコルで使用される予約済みリンク ローカル マルチキャスト アドレスを含め、任意のマルチキャスト アドレスを CAPWAP マルチキャスト グループに割り当てることができます。
シスコでは、管理用スコープのブロック 239/8 からマルチキャスト アドレスを割り当てることを推奨します。IANA では、プライベート マルチキャスト ドメインで使用するために、管理用スコープのアドレスとして 239.0.0.0 ~ 239.255.255.255 の範囲を予約しています(その他の制限については下記を参照)。これらのアドレスは、RFC 1918 で定義されている予約済みのプライベート IP ユニキャストの範囲(10.0.0.0/8 など)と事実上よく似ています。ネットワーク管理者は、インターネット上での競合を気にすることなく、管理しているドメイン内でこの範囲のマルチキャスト アドレスを自由に使用できます。この管理用またはプライベートのアドレス空間は、企業内で使用する必要があり、自律システム(AS)を出入りしないようブロックする必要があります。
(注) アドレス範囲 239.0.0.X および 239.128.0.X は使用しないでください。これらの範囲のアドレスは、リンク ローカル MAC アドレスとオーバーラップし、IGMP スヌーピングがオンの場合でも、すべてのスイッチ ポートに向けてフラッディングします。
シスコでは、企業ネットワーク管理者がこのアドレス範囲を企業ネットワーク内のさらに細かい地理上の管理用スコープに分けて、特定のマルチキャスト アプリケーションの「スコープ」を限定することを推奨します。これによって、高レートのマルチキャスト トラフィックがキャンパス(帯域幅が十分)から出て WAN リンクを混雑させることを防止できます。高帯域幅のマルチキャストを効率的にフィルタリングすることによって、高帯域幅のマルチキャストがコントローラおよびワイヤレス ネットワークに到達することも防止できます。
マルチキャスト アドレスのガイドラインの詳細については、次の URL にあるドキュメントを参照してください。
http://www.cisco.com/en/US/tech/tk828/technologies_white_paper09186a00802d4643.shtml
フラグメンテーションと CAPWAP マルチキャスト パケット
コントローラで受信されたマルチキャスト パケットは、宛先アドレスとして CAPWAP マルチキャスト グループを使用して CAPWAP 内にカプセル化され、管理インターフェイス(送信元アドレス)経由で AP に転送されます。パケットがリンクの MTU を超える場合は、コントローラによってパケットがフラグメント化され、両方のパケットが CAPWAP マルチキャスト グループに送信されます。別のコントローラが、この CAPWAP カプセル化マルチキャスト パケットを有線ネットワーク経由で受信すると、パケットが再カプセル化され、通常のマルチキャスト パケットのように処理されて、このコントローラの AP に転送されます。
これを防止するには次の 2 つのオプションがあり、いずれも単独で有効です。1 つ目は、すべてのコントローラを同じ CAPWAP マルチキャスト グループ アドレスに割り当てるオプションです。2 つ目は、標準のマルチキャスト フィルタリング技術を適用して、CAPWAP カプセル化マルチキャスト パケットが他のコントローラに送信されないようにするオプションです。すべてのコントローラが同一の CAPWAP マルチキャスト グループを保持しているか、または異なる CAPWAP マルチキャスト グループを保持しているかによって、これらの 2 つの手法には、表 6-1 に示す長所と短所があります。
表 6-1 同一のマルチキャスト グループを使用する場合と異なるグループを使用する場合の長所と短所
|
|
|
すべてのコントローラの CAPWAP マルチキャスト グループが同一である |
フラグメンテーション保護対策を施す必要がない |
各コントローラのマルチキャスト トラフィックがネットワーク全体でフラッディングする(AP で、AP のコントローラ管理インターフェイスと同じ送信元 IP アドレスを持たないマルチキャスト パケットがドロップされる) |
標準のマルチキャスト技術を使用して CAPWAP マルチキャスト フラグメントをブロックする |
アドレス範囲を使用できるため、ネットワーク全体のフラッディングを防止できる |
マルチキャスト対応コントローラに設定されているすべての VLAN 上のファースト ホップ ルータに ACL フィルタリングを適用する必要がある |
すべてのコントローラの CAPWAP マルチキャスト グループが同一である
2 つ目のコントローラからこれらの CAPWAP カプセル化パケットが再送信されないように、コントローラが CAPWAP マルチキャスト グループおよび CAPWAP 予約済みポート宛ての着信マルチキャスト パケットをブロックします。予約済みポートをブロックすることによって、コントローラはカプセル化された CAPWAP マルチキャスト パケットのフラグメント化パケットの最初の部分をブロックします。ただし、2 つ目のパケットにはポート番号が含まれていないため、マルチキャスト グループ アドレス(宛先アドレス)でフィルタするだけでブロックできます。コントローラは、コントローラに割り当てられている CAPWAP マルチキャスト グループ アドレスと宛先アドレスが同じになっているパケットをすべてブロックします。
ただし、各コントローラを同じ CAPWAP マルチキャスト グループに割り当てると、別の問題が発生します。CAPWAP マルチキャスト グループへ参加するために AP が使用する IGMP バージョン 1 および 2 は、Any Source Multicast(ASM)であるため、AP はネットワーク内のマルチキャスト グループのすべての送信元から送信されたマルチキャスト トラフィックを受信します。これは、ネットワーク上のすべてのコントローラが同一のマルチキャスト グループ アドレスで設定されている場合も、AP はすべてのコントローラからのマルチキャスト パケットを受信し、マルチキャスト境界は適用されないことを意味します。1 つのコントローラのマルチキャスト トラフィックが、ネットワーク全体のすべての AP にフラッディングし、各 AP はネットワーク全体のワイヤレス マルチキャスト クライアントから送信されているマルチキャスト トラフィックを受信します(送信元アドレスが AP のコントローラの管理アドレスとは異なる場合はドロップします)。また、ローカルで送信された HSRP、PIM、および EIGRP などのクライアント VLAN からのマルチキャスト パケットおよび OSPF マルチキャスト パケットも、ネットワーク全体でフラッディングします。
標準のマルチキャスト技術を使用した WLAN 上のマルチキャストの制御
通常の境界技術を、マルチキャスト対応ネットワークで使用する必要があります。これらの技術には、IP マルチキャスト トラフィックおよび Auto-RP メッセージをフィルタリングする ip multicast boundary インターフェイス モード コマンドの使用が含まれます。
(注) ネットワーク内の任意の場所にある有線クライアントは、CAPWAP マルチキャスト ストリームを要求して、すべての送信元からそのストリームを受信できます(マルチキャスト境界が適用されていない場合)。マルチキャスト ストリームが CAPWAP マルチキャスト パケットにカプセル化されている場合、マルチキャスト ストリームは暗号化されていません。したがって、このようなアクセスを防ぐためにマルチキャスト境界を実装することを推奨します。
これまでは、IP マルチキャスト データグラムのパケット存続時間(TTL)フィールドで、ttl-threshold コマンドを使用して、Auto-RP の管理用境界を作成していました。この作業は、IP マルチキャスト トラフィックおよび Auto-RP メッセージをフィルタリングする ip multicast boundary インターフェイス モード コマンドの使用に取って代わられています。シスコは新しいコマンドを使用することを推奨します。
その他の便利なコマンドとして、ip multicast rate-limit interface コマンドがあります。このコマンドは、ワイヤレス VLAN に低レートを強制します。このコマンドを使用しないと、ネットワーク エンジニアが高レート マルチキャスト アドレスをフィルタリングしても、低レート マルチキャスト アドレスがそのレートを超過できなくなります。
ワイヤレス クライアント VLAN の一般的な例は次のとおりです。マルチキャスト対応ネットワークに使用するその他のマルチキャスト コマンドの詳細については、 http://www.cisco.com/go/multicast を参照してください。マルチキャスト対応トラフィックでフィルタリングを実行することによって、マルチキャスト アドレスを使用した TCP および ICMP 転送に依存する特定ワーム(Sasser ワームなど)の伝搬を防ぐことができます。マルチキャスト グループ アドレスを使用してこれらのタイプのトラフィックをブロックしても、これらのアドレスでは通常、ストリーミングに UDP または TCP が使用されるため、ほとんどのアプリケーションに影響はありません。
次の例では、任意の送信元からのマルチキャスト グループ範囲 239.0.0.0 ~ 239.127.255.255 宛てのパケットのパケット レートが、128 Kbps に制限されます。この例では、下位の管理スコープ アドレスには含まれないすべてのマルチキャスト アドレスにも境界が設定されます。また、Vlan40 を使用するホストは、239.0.0.0 ~ 239.127.255.255 の下位管理用グループだけに参加できるようになります。
class-map match-all multicast_traffic
description Permit Low Rate Multicast Range of 239.0.0.0 to 239.127.0.0 match access-group 101
description Rate Limit Multicast traffic to 2.56mps with burst of 12800 bytes class multicast_traffic
police cir 2560000 bc 12800 be 12800 conform-action transmit exceed-action drop
description To Wireless Clients
ip address 10.20.40.3 255.255.255.0
ip multicast boundary 1 ip igmp access-group 30 standby 40 ip 10.20.40.1
service-policy output multicast
access-list 1 remark Permit Low Rate Multicast Range of 239.0.0.0 to 239.127.0.0 for multicast boundary
access-list 1 permit 239.0.0.0 0.127.255.255
access-list 30 remark Only Allow IGMP joins to this Multicast Group Range access-list 30 permit 239.0.0.0 0.127.255.255
access-list 101 remark Permit Low Rate Multicast Range of 239.0.0.0 to 239.127.0.0 for class-map
access-list 101 permit ip any 239.0.0.0 0.127.255.255
コントローラの配置がマルチキャスト トラフィックとローミングに与える影響
(注) 分散型と中央集中型のどちらの展開においても、マルチキャスト ストリームのレートは制限されず、ACL は適用できません。マルチキャスト トラフィックが有効になると、HSRP、EIGRP、OSPF、および PIM パケットを含むすべてのマルチキャスト トラフィックがワイヤレス LAN に転送されます。
ここでは、分散型と中央集中型の 2 つの異なる展開と、それぞれの展開がマルチキャスト クライアントのローミングに与える影響について示します。中央集中型の展開では、WLC WLAN インターフェイスは同じ VLAN/サブネットにアタッチされ、マルチキャスト クライアントがある WLC の AP から他の WLC の AP に移動する際、マルチキャスト ストリームは中断されません。中央集中型の展開では、フラットな WLC クライアント マルチキャスト ネットワークが作成されます。中央集中型の WLC がマルチキャスト ローミングに影響を与えないのは、マルチキャスト ストリームが WLAN 上の 1 つのマルチキャスト クライアントから要求されると、マルチキャスト トラフィックを要求したクライアントが 1 つもアクセス ポイントの WLAN に関連付けられていなくても、この WLAN、すべての無線(802.11g および 802.11a)およびすべての WLC に接続されているすべての AP に対してマルチキャスト ストリームが出力されるためです。VLAN に関連付けられている WLAN が複数ある場合は、AP からマルチキャスト パケットが WLAN ごとに送信されます。ユニキャスト モードとマルチキャスト モードの CAPWAP パケットには両方とも、パケットの転送で経由する必要のある WLAN を受信側 AP に伝える WLAN ビットマップが含まれます。
分散型の展開では、WLAN が同じでも、WLC が別の VLAN にアタッチされるため、このような問題はありません。このことは、マルチキャスト クライアントが新しい WLC に移動するときに、WLC がクライアントのマルチキャスト グループ メンバーシップを最初にクエリすることを意味します。この時点で、クライアントはグループ メンバーシップ レポートを返信します。このメッセージは WLC によって、ローカル VLAN に関連付けられた VLAN 経由で適切なマルチキャスト グループ アドレスに転送されます。これにより、クライアントは外部 WLC を介してマルチキャスト セッションを再開できます。
分散型展開では、WLAN SSID が同じであっても WLC は異なる VLAN にアタッチされているため、AP 上のマルチキャスト トラフィックの量が削減されます。WLAN マルチキャスト トラフィックは、WLC の VLAN のクライアント要求によって異なります。 表 6-2 で、分散型展開と中央集中型展開の長所と短所を示します。
表 6-2 中央集中型 WLC 展開および分散型 WLC 展開の長所と短所
|
|
|
中央集中型のすべての WLC WLAN が同じ VLAN(サブネット)に接続されている |
いずれのクライアント VLAN で開始したマルチキャスト トラフィックでもすべての AP に送信されるため、いずれの AP にローミングしてもクライアントはマルチキャスト ストリームを受信する |
1 つのクライアントのみがマルチキャスト トラフィックを要求した場合、すべてのコントローラにアタッチされているすべての AP がストリームを受信し、AP に関連付けられているクライアントがある場合は、それらのクライアントがマルチキャスト ストリームを要求しなかった場合でも、その AP がストリームを送信する |
異なる VLAN およびサブネットに接続されている分散型 WLC |
マルチキャスト ストリームは、コントローラにアタッチされている AP に分離される |
クライアントの移動後にマルチキャスト ストリームを確立したことによる中断が生じる |
その他の考慮事項
マルチキャスト展開におけるその他の考慮すべき 2 つの分野は、AP グループの実装時、および FlexConnect と AP の実装時です。AP グループでは、同じコントローラ上の AP は、同じ WLAN(SSID)を別の VLAN にマップできます。異なるグループの AP 間でクライアントが移動すると、マルチキャスト セッションが正しく機能しません。それは、この動作が現在サポートされていないためです。現在、WLC は WLAN で設定された VLAN に対してのみマルチキャストを転送し、AP グループで設定された VLAN については考慮しません。
FlexConnect AP を使用すると、WLAN のローカル終端が WLC ではなくネットワーク エッジで可能になり、マルチキャスト動作がそのエッジで制御されます。FlexConnect WLAN が WLC で終端し、マルチキャストがその WLC で有効になっている場合に、FlexConnect ネットワークの場所まで CAPWAP マルチキャストグループを拡張することが許可されているときは、マルチキャストは、その FlexConnect WLAN に配信されます。
CAPWAP マルチキャスト パケットがネットワークを FlexConnect AP に送信できない場合でも、これらのパケットはユニキャスト メッセージであるため、その FlexConnect AP 上の WLAN クライアントは、WLC に接続されているネットワークに IGMP Join 要求を送信できます。
802.11v およびダイレクト マルチキャストに関する情報
リリース 8.1 から、コントローラは、ワイヤレス ネットワーク管理に対するさまざまな機能拡張について記載されたワイヤレス ネットワークに関する 802.11v 改訂をサポートします。
このような機能強化の 1 つがクライアントでスリープ時間を延ばしてバッテリ寿命を改善できるようにする ネットワーク支援型電力節約 です。たとえば、多くのモバイル デバイスは、特定のアイドル期間を利用してアクセス ポイントとの接続を維持するため、ワイヤレス ネットワークで以降のタスクを実行するときにより多くの電力を消費します。
もう 1 つの機能強化は、WLAN 上で関連付けられたクライアントに要求を送信して、アドバタイズにより、適切な AP をクライアントが選択できるようにする ネットワーク支援型ローミング です。これは、ロード バランシングと、接続が不安定なクライアントの管理の両方に役立ちます。
802.11v Network Assisted Power Savings の有効化
ワイヤレス デバイスはクライアントへの接続を維持するためにさまざまな方法でバッテリを消費します。
- 定期的に起動して DTIM を含むアクセス ポイント ビーコンをリッスンする。DTIM は、アクセス ポイントがバッファされたブロードキャストとマルチキャスト トラフィックのどちらをクライアントに提供するかを示します。
- アクセス ポイントとの接続を維持するために、null フレームをキープアライブ メッセージの形式でアクセス ポイントに送信します。
- デバイスは、定期的に、ビーコンをリッスン(DTIM フィールドがない場合も)して、対応するアクセス ポイントとクロックを同期させます。
このすべてのプロセスがバッテリを消費し、その消費は特にデバイス(Apple など)に影響します。これは、これらのデバイスが保守的なセッション タイムアウト推定を使用しているために、頻繁にスリープ解除してキープアライブ メッセージを送信するためです。802.11 標準は、802.11v なしのローカル クライアントのセッション タイムアウトの無線クライアントと通信するため、コントローラまたはアクセス ポイントの機能は含まれていません。
ワイヤレス ネットワーク上の上記タスクによるクライアントの電力を節約するために、802.11v 標準の次の機能が使用されます。
- Directed Multicast Service
- Base Station Subsystem(BSS)最大アイドル期間
Directed Multicast Service
Directed Multicast Service(DMS)を使用して、クライアントは、必要なマルチキャスト パケットをユニキャスト フレームとして送信するようにアクセス ポイントに要求します。それによりクライアントは、スリープ モードで無視していたマルチキャスト パケットを受信し、またレイヤ 2 の信頼性を確保できます。また、ユニキャスト フレームができるだけ高いワイヤレス リンク レートでクライアントに送信されるため、クライアントは無線の持続期間を短縮してパケットをすばやく受信できるようになり、バッテリの電力が節約されます。ワイヤレス クライアントはマルチキャスト トラフィックを受信するために DTIM 間隔ごとにスリープ解除する必要がないため、スリープ間隔を延ばすことができます。
BSS の最大アイドル時間
BSS 最大アイドル期間は、アクセス ポイント(AP)が接続先のクライアントからフレームが受信されないという理由でそのクライアントの関連付けを解除しないタイムフレームです。これにより、クライアント デバイスがキープアライブ メッセージを頻繁に送信しないようになります。アイドル期間タイマー値は、アクセス ポイントからクライアントへのアソシエーションおよび再アソシエーション応答フレームを使用して送信されます。このアイドル時間値は、クライアントがアクセス ポイントにフレームを送信せず、アイドル状態を維持可能な最大時間を意味します。したがって、クライアントは、キープアライブ メッセージを頻繁に送信することなく、より長い間スリープ モードを維持します。これがバッテリの電力の節約につながります。
802.11v Network Assisted Power Savings(CLI)の設定
- BSS 最大アイドル期間の値を設定するには、次のコマンドを入力します。
– config wlan usertimeout wlan-id
– config wlan bssmaxidle {enable | disable} wlan-id
- DMS を設定するには、次のコマンドを入力します。
– config wlan dms {enable | disable} wlan-id
IPv6 マルチキャストの概要
マルチキャスト アドレスは、異なるノードに属する一連のインターフェイスに対応する ID です。マルチキャスト アドレスは、通常、同様のコンテンツ(ビデオなど)の受信に関心のあるインターフェイス グループを識別するために使用されます。この場合のメッセージ交換モデルは、1 対多モデルです。マルチキャスト アドレスはすべて FF00::/8 ブロックの中から割り当てられます。
また、マルチキャスト アドレスには関連付けられたスコープがあります。スコープは、ユニキャスト アドレス用に定義されたスコープとよく似ています。
- リンク ローカル:リンク ローカル マルチキャスト アドレスは、リンク上のシステムのみで使用され、ネットワーク機器によってそのリンクから転送されることはありません。この動作は、リンク ローカル ユニキャスト アドレスと同様です。
- オーガナイゼーション:オーガナイゼーション マルチキャスト アドレスは、組織内でのみ使用されます。これらのアドレスは、ユニキャストのユニーク ローカル アドレスと同様です。
- グローバル:グローバル マルチキャスト アドレスは、ユニキャストのグローバル一意アドレスと同様に、インターネット上で使用できます。
IPv6 マルチキャスト アドレス用に追加で定義されたスコープがあります。
- インターフェイス ローカル:インターフェイス ローカル マルチキャスト アドレスは、ノード内でのマルチキャストの伝送に使用されます。
- サイト ローカル:サイト ローカル マルチキャスト アドレスは、単一サイト内で使用されます。
図 6-4 は、IPv6 マルチキャスト アドレス形式を示しています。
ユニキャスト アドレス空間と同様に、いくつかの予約済みのマルチキャスト アドレスや特殊用途のマルチキャスト アドレスがあります。一般的なマルチキャスト グループとその用途を以下に示します。現在割り当てられているマルチキャスト アドレスの詳細なリストについては、次の URL を参照してください。 http://www.iana.org/assignments/ipv6-multicast-addresses
IPv6 システムで見られるより一般的なマルチキャスト アドレスには次が含まれます。
- FF02::1:リンク ローカル、すべてのノードのアドレス
- FF02::2:リンク ローカル、すべてのルータのアドレス
- FF02:0:0:0:0:1:FFXX:XXXX:リンク ローカル、要請ノード アドレス
図 6-4 マルチキャスト アドレスの形式
マルチキャスト リスナー検出(MLD)
シスコ ソフトウェアでは、IPv6 マルチキャスト ルーティングを実装するため、次のプロトコルがサポートされています。
- MLD for IPv6。MLD は、直接アタッチされているリンク上のマルチキャスト リスナー(特定のマルチキャスト アドレスを宛先としたマルチキャスト パケットを受信するために使用するノード)を検出するために IPv6 ルータとコントローラで使用されます。MLD には 2 つのバージョンがあります。MLD バージョン 1 はバージョン 2 のインターネット グループ管理プロトコル(IGMP)for IPv4 をベースとしています。MLD バージョン 2 はバージョン 3 の IGMP for IPv4 をベースとしています。シスコ ソフトウェアの IPv6 マルチキャストでは、MLD バージョン 2 と MLD バージョン 1 の両方が使用されます。
MLD バージョン 2 は、MLD バージョン 1 と完全な下位互換性があります(RFC 2710 で規定)。MLD バージョン 1 だけをサポートするホストは、MLD バージョン 2 を実行しているルータと相互運用します。MLD バージョン 1 ホストと MLD バージョン 2 ホストの両方が混在する LAN もサポートされています。
- PIM-SM は、相互に転送されるマルチキャスト パケット、および直接接続されている LAN に転送されるマルチキャスト パケットを追跡するためにルータ間で使用されます。
- PIM in Source Specific Multicast(PIM-SSM)は PIM-SM と類似していますが、IP マルチキャスト アドレスを宛先とした特定の送信元アドレス(または特定の送信元アドレスを除くすべてのアドレス)からのパケットを受信する対象をレポートする機能を別途備えています。
ワイヤレス LAN コントローラの IPv6 マルチキャスト サポート
リリース 8.0 以降では、ワイヤレス LAN コントローラが IPv6 マルチキャスト対応の MLDv1 スヌーピングをサポートしています。それによって、要求元のクライアントへのマルチキャスト フローをインテリジェントに追跡および配信できます。
(注) 以前のバージョンのリリースとは異なり、IPv6 ユニキャスト トラフィックのサポートでは、コントローラでグローバル マルチキャスト モードを有効にする必要がなくなりました。IPv6 ユニキャスト トラフィックのサポートは自動的に有効になります。
IPv6 のマルチキャストを設定するには、次の手順に従います。
ステップ 1 IPv6 マルチキャストを有効にするには、[Enable Global Multicast Mode] チェック ボックスをオンにします。
ステップ 2 [Enable MLD Snooping] チェックボックスをオンにして、IPv6 の転送先の決定をサポートします。
(注) MLD スヌーピングを有効にするには、コントローラのグローバル マルチキャスト モードを有効にする必要があります。
ステップ 3 マルチキャスト モードを設定します。
a. [MLD Timeout] テキスト ボックスで、30 ~ 7200 秒の範囲内の値を入力して MLD タイムアウトを設定します。
b. [MLD Query Interval] テキスト ボックスに、15 ~ 2400 秒の値を入力します。
c. [Apply] をクリックします。
d. [Save Configuration] をクリックします。
ステップ 4 IPv6 マルチキャスト トラフィックがスヌーピングされたことを確認するには、[Monitor] > [Multicast] に移動します。IPv4(IGMP)と IPv6(MLD)の両方のマルチキャスト グループが表示される点に注意してください。そのグループ アドレスに参加しているワイヤレス クライアントを表示するには、[MGID] をクリックします。
マルチキャスト ドメイン ネーム システム:mDNS/Bonjour
表 6-3 に、リリース 7.4 から 8.5 までの Bonjour 機能を示します。
表 6-3 フェーズ 1、2、3、および 4 のサービスの概要
|
|
|
|
- 有線およびワイヤレス サービス向けに mDNS ゲートウェイを使用する Bonjourサービス
- インターフェイス単位または WLAN 単位で適用される Bonjour サービス ポリシー
- コントローラにキャッシュされる mDNS サービス
- L2 ドメインで認識されるすべてのコントローラで使用可能な Bonjour サービス
- アンカー コントローラでサポートされる Bonjour サービス
- L2 および L3 ローミングとともにサポートされる Bonjour サービス
- 100 種類のサービスと、サービスごとに 64 のサービス プロバイダー
- セントラル モードの FlexConnect AP のサポート
|
- L3 ドメイン全体にわたる mDNS サービスのサポート
- 10 の有線 VLAN 上での Bonjour サービスのスヌーピングに対応する mDNS AP の導入
- LSS(ロケーション固有サービス)
- Bonjour サービスのプライオリティ MAC
- 起点に基づくサービス検出
- 6400 種類のサービスとサービス タイプごとのサービス プロバイダー
|
- アクセス ポリシーで制御されるサービス検出を備えた Bonjour GW
- アクセス ポリシーへのデバイス サービスのマッピング
- Bonjour グループおよび単一のアクセス ポリシーの管理
- ローカル ポリシーによる Bonjour プロファイルの制御
- Cisco Prime から特定の Bonjour サービスを管理するための Bonjour 管理者の配置
|
|
マルチキャスト ドメイン ネーム システムについて
マルチキャスト ドメイン ネーム システム(mDNS)サービス ディスカバリは、ローカル ネットワークでサービスを通知し、検出する手段を提供します。mDNS サービス検出により、ワイヤレス クライアントは、異なるレイヤ 3 ネットワークでアドバタイズされる Apple Printer や Apple TV などの Apple サービスにアクセスできます。mDNS は、IP マルチキャスト経由で DNS クエリを実行します。mDNS では設定不要の IP ネットワーキングがサポートされています。
Bonjour プロトコルはサービス アナウンスとサービス クエリによって動作し、デバイスは、次を含む特定のアプリケーションに問い合わせたり、アドバタイズしたりできます。
- 印刷サービス
- ファイル共有サービス
- リモート デスクトップ サービス
- iTunes ファイル共有
- iTunes ワイヤレス iDevice 同期(Apple iOS v5.0 以降)
- 次のストリーミング サービスを提供する AirPlay:
– iOS v4.2 以降でのミュージックのブロードキャスト
– iOS v4.3 以降でのビデオのブロードキャスト
– iOS v5.0 以降での全画面ミラーリング(iPad2、iPhone4S 以降)
各クエリまたはアドバタイズメントはサブネット上のすべてのクライアントへ配信するために、Bonjour マルチキャスト アドレスに送信されます。Apple の Bonjour プロトコルは UDP ポート 5353 で動作する mDNS に依存しており、次の予約済みグループ アドレスに送信します。
- IPv4 グループ アドレス:224.0.0.251
- IPv6 グループ アドレス:FF02::FB
Bonjour プロトコルで使用するアドレスは、リンクローカル マルチキャスト アドレスであるため、ローカル L2 ドメインにのみ転送されます。存続可能時間(TTL)が 1 に設定され、リンクローカル マルチキャストは設計によってローカルに留まることを意味しているため、ルータはマルチキャスト ルーティングを使用してトラフィックをリダイレクトすることができません。
この問題を解決するために、Cisco WLC が Bonjour ゲートウェイとして機能します。WLC は Bonjour サービスをリッスンしながら、AppleTV などのソース/ホストからの Bonjour アドバタイズメント(AirPlay や AirPrint など)をキャッシュすることによって、サービスの要求が開始されたときに Bonjour クライアントに応答します。次の図は、このプロセスを示しています。
ステップ 1 コントローラが Bonjour サービスをリッスンします。
ステップ 2 コントローラは、それらの Bonjour サービスをキャッシュします。
ステップ 3 コントローラは、クライアントのサービス クエリをリッスンします。
ステップ 4 コントローラは、Bonjour サービスのクライアント クエリに対してユニキャスト応答を送信します。
Location Specific Services(ロケーション固有サービス)
mDNS サービス アドバタイズメントおよび mDNS クエリ パケットの処理では、ロケーション固有サービス(LSS)をサポートしています。コントローラが受信するすべての有効な mDNS サービス アドバタイズメントは、新しいエントリをサービス プロバイダーのデータベースに挿入する際に、サービス プロバイダーからのサービス アドバタイズメントに関連付けられた AP の MAC アドレスにタグ付けされます。クライアント クエリに対する応答記述では、クエリ中のクライアントに関連付けられた AP の MAC アドレスを使用してサービス プロバイダー データベースのワイヤレス エントリをフィルタリングします。ワイヤレス サービス プロバイダーのデータベース エントリは、LSS がサービスに対して有効になっている場合、AP-NEIGHBOR-LIST に基づいてフィルタリングされます。LSS がサービスに対して無効になっている場合、ワイヤレス サービス プロバイダーのデータベース エントリは、そのサービスに対するワイヤレス クライアントからのクエリに応答する場合、フィルタリング対象ではありません。
LSS は、ワイヤレス サービス プロバイダーのデータベース エントリだけに適用されます。有線サービス プロバイダー デバイスのロケーションは認識されません。
LSS の状態は、ORIGIN が有線に設定されているサービスに対して有効にすることはできません。この逆も同じです。
mDNS AP
mDNS AP 機能により、コントローラは、表示されない VLAN 上の有線サービス プロバイダーの可視性を獲得できます。mDNS AP として AP を設定し、AP がコントローラに mDNS パケットを転送するようにできます。コントローラの VLAN の可視性は、AP が mDNS アドバタイズメントをコントローラに転送することで実現されます。AP とコントローラ間の mDNS パケットは、ワイヤレス クライアントからの mDNS パケットと同様に、Control and Provisioning of Wireless Access Points(CAPWAP)データ トンネルで転送されます。CAPWAP v4 のトンネルのみがサポートされます。AP をアクセス ポートまたはトランク ポートに設置して有線側からの mDNS パケットを学習し、コントローラに転送することができます。特定の AP からの mDNS パケット転送を開始または停止する際、コントローラで提供される設定可能なノブを使用できます。また、この設定を使用して、AP が有線側から mDNS アドバタイズメントをスヌープする必要のある VLAN を指定できます。AP がスヌープできる VLAN の最大数は 10 です。
AP がアクセス ポートに設置されている場合、スヌープするように AP の VLAN を設定しないでください。クエリーが送信されると、AP はタグ付けされていないパケットを送信します。mDNS アドバタイズメントが mDNS AP によって受信されると、VLAN 情報はコントローラに渡されません。mDNS AP のアクセス VLAN 経由で学習されるサービス プロバイダーの VLAN は、コントローラで 0 として保持されます。
デフォルトでは、mDNS AP はネイティブ VLAN でスヌープします。mDNS AP が有効な場合、ネイティブ VLAN のスヌーピングはデフォルトで有効になっており、VLAN 情報はネイティブ VLAN で受信したアドバタイズメントに対して 0 として渡されます。
mDNS AP 機能は、ローカル モードとモニタ モードの AP でのみサポートされます。mDNS AP 設定は、グローバル mDNs スヌーピングを無効にしてもそれぞれの mDNS AP で保持されます。mDNS AP がリセットされるか、同じコントローラまたは別のコントローラに接続している場合は、次のいずれかになります。
- グローバル スヌーピングがコントローラで無効になっている場合、ペイロードが AP に送信されて mDNS スヌーピングは無効になります。
- グローバル スヌーピングがコントローラで有効になっている場合、リセットまたはアソシエーションの手順より前の AP の設定が保持されます。
mDNS AP 機能のプロセス フローは次のとおりです。
アップリンク(有線インフラストラクチャ - AP - コントローラ)
1. 設定された VLAN で mDNS 802.3 パケットを受信します。
2. 受信した mDNS パケットをCAPWAP を介して転送します。
3. 受信した VLAN に基づいてマルチキャスト グループ ID (MGID)を入力します。
ダウンリンク(コントローラ - AP - 有線インフラストラクチャ)
1. コントローラから CAPWAP を介して mDNS クエリーを受信します。
2. 有線インフラストラクチャに 802.3 パケットとしてクエリーを転送します。
3. VLAN は専用 MGID で識別されます。
マルチキャスト DNS の設定の制限
- IPv6 を介した mDNS はサポートされません。
- ローカル側で切り替えられた WLAN およびメッシュ アクセス ポイントでは、FlexConnect モードのアクセス ポイントで mDNS はサポートされていません。
- mDNS はリモート LAN ではサポートされません。
- mDNS は Cisco AP 1240 および AP 1130 ではサポートされません。
- サードパーティの mDNS サーバまたはアプリケーションは mDNS 機能を使用する Cisco WLC ではサポートされていません。サードパーティ サーバまたはアプリケーションによってアドバタイズされるデバイスは、Cisco WLC で mDNS のサービスまたはデバイス テーブルに正しく入力されません。
- Layer2 ネットワークでは、Apple サーバとクライアントが同じサブネット内にある場合、Cisco WLC での mDNS スヌーピングは不要です。ただし、これはスイッチング ネットワークの動作に依存します。mDNS スヌーピングと予期したとおりに連動しないスイッチを使用している場合は、Cisco WLC 上で mDNS を有効にする必要があります。
- ビデオは、WMM が有効な状態の Apple iOS 6 ではサポートされていません。
- mDNS AP は同じサービスまたは VLAN に対して同じトラフィックを複製することはできません。
- DLSS フィルタリングはワイヤレス サービスのみに制限されます。
- LSS、mDNS AP、プライオリティ MAC アドレスおよび送信元ベースの検出機能は、コントローラの GUI を使用して設定できません。
- mDNS AP 機能は CAPWAP V6 ではサポートされません。
- DISE ダイナミック mDNS ポリシーのモビリティはサポートされません。
- mDNS のユーザ プロファイル モビリティは、ゲスト アンカーではサポートされません。
- iPad、iPhone などの Apple デバイスは、Bluetooth を使用して Apple TV を検出できます。このため、Apple TV がエンド ユーザに表示されることがあります。mDNS のアクセス ポリシーでは Apple TV をサポートしていないため、シスコは、Apple TV では Bluetooth を無効にすることを推奨します。
(注) mDNS モードをサポートしている AP モデルと、サポートされている mDNS AP については、WLC の最新のリリース ノートを参照してください。https://www.cisco.com/c/en/us/td/docs/wireless/controller/release/notes/crn84.html
Bonjour ポリシーと新しい要件の概要
Bonjour ゲートウェイは、VLAN 間の Bonjour サービスをスヌーピングおよびキャッシュして、定期的にサービスを更新します。WLC は、ワイヤレス デバイスおよび有線デバイスによって公開されるすべての Bonjour サービスのプロキシとして動作します。8.0 より前のリリースでは、Bonjour ゲートウェイは、クエリ中のクライアントのクレデンシャルとその場所に基づいてキャッシュされた有線またはワイヤレス サービス インスタンスをフィルタする機能が不十分でした。
リリース 8.0 の Bonjour ポリシーの導入によって、管理者は、誰がどこで Bonjour サービス インスタンスを使用しているか識別するように設定できます(これはすべて同じWLANに適用される)。Bonjour ポリシーを導入することで、管理者は、特定の WLAN で許可するサービス、または特定の WLAN で使用する必要があるサービスを選択するために複数の WLAN を作成する必要がなくなりました。ユーザ 802.1x 認証に基づいて、AAA サーバまたは ISE は「CISCO-AV-PAIR」形式で USER-ROLE または BONJOUR-PROFILE を返すように設定できます。この値は、ワイヤレス コントローラで作成されたポリシーと一貫しています。ユーザ認証に基づいて、設定されたポリシーとプロファイルを同じ WLAN 上の特定のユーザに適用されます。
上の図に示すように、Bonjour サービスに改善が加えられています。Bonjour ポリシーが導入され、サービス インスタンス(MAC アドレス)の設定ごとに、サービス インスタンスがどのように共有されるかを指定できるようになりました。次のように指定されます。
- サービス インスタンスを誰と(ユーザ ID)共有するか。
- サービス インスタンスをどのロール(クライアント ロール)と共有するか。
- サービス インスタンスへのアクセスを許可する場所(クライアントの場所)
この設定は、有線およびワイヤレス サービス インスタンスに適用でき、クエリへの応答は、各サービス インスタンスに設定されたポリシーのみに基づきます。これによって、場所、ユーザ ID、またはロールに基づいてサービス インスタンスを選択的に共有できます。ほとんどのサービス公開デバイスが有線で接続されているため、これによってワイヤレス サービス インスタンスと同等の有線サービスのフィルタリングが可能になります。クライアントに関連付けられている mDNS プロファイルが、クエリに応答する前にクエリ中のサービス タイプを確認し、その一方で、アクセス ポリシーがクエリ中のクライアントの場所、ロール、またはユーザ ID に基づいて、特定のサービス インスタンスのさらなるフィルタリングを許可します。
Bonjour アクセス ポリシーでは、クライアント クエリのフィルタリングに次の 2 つのレベルがあります。
- mDNS プロファイルを使用するサービス タイプ レベル
- サービス インスタンスに関連付けられたアクセス ポリシーを使用するサービス インスタンス レベル
WLC によって検出およびキャッシュされた単一のサービス インスタンスまたは一連のサービス インスタンスは、アクセス ポリシー フィルタに関連付けることができます。このアクセス ポリシー フィルタは、どのクライアントとどのようなクライアント コンテキスト(ロールまたはユーザ ID)がサービス インスタンスを表示およびアクセスできるかを決定するレンズのように動作します。
(注) アクセス ポリシーが設定されていないサービス インスタンスは、デフォルトでは管理者ユーザ ロールのみにサービス インスタンスの受信を許可するデフォルト アクセス ポリシーにマッピングされます。追加のユーザを設定し、デフォルト ポリシーに追加できます。
- Bonjour アクセス ポリシー フィルタは、サービスを公開しているデバイスの MAC アドレスで識別された特定のサービス インスタンスに設定できます。
- Bonjour アクセス ポリシーは、Bonjour サービスを公開しているデバイスの複数の MAC アドレスを含むサービス グループ名に関連付けられます。
- その後、サービス グループ名は、サービス インスタンスが WLC で検出され、キャッシュされると、そのサービス インスタンスにアタッチされます。
- クライアント クエリへの応答時にサービス インスタンスのリストが調査され、クエリ中のクライアントの場所、ロール、またはユーザ ID にサービス インスタンスへのアクセスが許可されているかどうかを確認するため、各サービス インスタンスが評価されます。その後、応答に同じ内容が内包されます。
複数のサービス グループに同じ MAC アドレスが設定されている場合、サービス インスタンスがこの MAC アドレスに設定されているすべてのサービス グループ名に関連付けられることを意味します。MAC アドレスのサービス グループ名に関連付けられたアクセス ポリシーはすべて、そのサービス インスタンスを含んでいると判断されるまで、評価されます。現在、単一の MAC アドレスあたり最大 5 つのサービス グループがサポートされています。サービス グループの設定は、mDNS スヌーピングが無効またはオフラインの場合でも実行でき、アクセス ポリシーはサービスが検出されるタイミングを左右します。また、スヌーピングがすでに有効な場合は、動的に実行されます。
Bonjour サービス グループ
サービス グループ名は、一連の MAC アドレスに関連付けることができます。サービス グループに設定できる MAC アドレスの最大数は、プラットフォームに応じて、検出可能なサービス インスタンスのグローバル最大数によって制限されます。
- リリース 8.0 のサービス制限は、5508、WiSM2、vWLC で 6400 サービス、7510 および 8510 UC コントローラでは 16000 サービスです。
- リリース 8.1 では、サポートされている AP ライセンス数やクライアント数に応じたサービス制限に変更されており、5508 と WiSM-2 コントローラのサービス制限が変更されました。
|
|
Bonjour キャッシュ @ 80 % スケール
|
リリース 8.0 の 5508 |
6400 |
6400 |
リリース 8.1 の 5508 |
1000 |
2400 |
リリース 8.0 の WiSM2 |
6400 |
6400 |
リリース 8.1 の WiSM2 |
2000 |
4800 |
5520、7500、8500、vWLC |
16,000 |
16,000 |
3504(8.5 リリース) |
1600 |
1600 |
2504(8.0 リリース) |
6400 |
6400 |
リリース 8.1 の 2500 |
推奨されない |
非推奨 |
2500(8.2 リリース) |
200 |
200 |
上記の表に示すように、リリース 8.1 の 5508 コントローラは、フル スケールで 1000 サービスのみに縮小されています(500 AP および 7000 クライアント)。80 % スケール(400 AP および 5400 ユーザ)では、同じ 5508 コントローラが 2400 サービスをサポートします。同様に、WiSM2 は、フル スケールで 2000 サービス(1000 AP と 15000)を、80 % スケールで 4800 サービスをサポートします。7500 と vWLC コントローラでは、Bonjour サービスの数は変更されていません。5520 および 8500 シリーズ コントローラでは、リリース 8.1 で 16,000 サービスがサポートされています。2504 コントローラでは、メモリの制限によってサービス数が大幅に低下しており、リリース 8.1 では Bonjour サービスの実行が推奨されていませんでした。したがって、2504 では Bonjour をテストや非常に限定されたサービス数についてのみ使用するように推奨されていました。リリース 8.2 では、8.2 ソフトウェアをインストールした 2504 コントローラで最大 200 の Bonjour サービスを実行できるように変更されています。
有線およびワイヤレスのロケーション固有のサービス
各 MAC アドレスには一意の名前が設定されます。この名前は、サービス インスタンス名の場合もあれば、有線およびワイヤレスの両方、またはどちらか一方の MAC アドレスの場所の場合もあります。
1. AP-NAME、AP-GROUP、または AP-LOCATION を使用した場所の設定時には柔軟性が求められるため、管理者は必要な場所のタイプを設定する必要があります。この設定は、サービスを公開しているデバイスと同じ場所からしか、クライアントがそのサービスにアクセスできないことを意味しています。MAC アドレスのグローバルな最大制限を超えない限り、サービス グループには必要な数の MAC アドレスを設定できます。
ワイヤレス サービス インスタンスの場合、デバイスの場所は変更できます。ただし、サービス インスタンスと同じ場所にあるデバイスのみが必要な場合は、このようなワイヤレス サービス プロバイダーに対してキーワード「same」を設定できます。
有線サービスの場合、有線クライアントは AP に関連付けられないため、同じ場所は適用されません。
2. 場所に対してキーワード「Any」が設定されている場合は、デバイスにアクセスしようとするクライアントを場所に基づいてフィルタリングしないことを意味します。つまり、その MAC アドレスのサービス グループに関連付けられたポリシーによってロールおよびユーザ ID クレデンシャルが許可されていれば、クライアントは任意の場所からサービスにアクセスできます。
3. キーワード「ap-name」が使用されている場合は、その AP に関連付けられているクライアントのみが、サービス インスタンスにアクセスできます。
(注) 場所の検証は暗黙的で、クライアントのロールとユーザ ID クレデンシャルが確認される前であっても、第 1 レベルのアクセス ポリシー フィルタリングとして実行されます。
表 6-4 は、AppleTV-teachers という名前のサービス グループでの考えられるポリシー設定を示しています。
表 6-4 サービス グループ名によるポリシー設定の例
|
|
|
|
|
AppleTV-teachers |
e8:b7:48:9b:f0:20 |
AppleTV-class1 |
AP-GROUP |
6-FLR |
e8:b7:48:9b:f0:21 |
AppleTV-class2 |
AP-NAME |
AP4403.a740.bc97 |
— |
— |
— |
— |
e2:34:23:11:32:eb |
AppleTV-class9 |
AP-NAME |
同じ |
— |
— |
— |
— |
e8:c7:38:9c:f1:32 |
AppleTV -class3 |
AP-GROUP |
any |
デバイス アクセス ポリシーの構造とルール
ここでは、クライアント コンテキスト属性、その構造、ポリシーを構成するルール コンポーネント、およびルールとポリシーを評価する方法という観点からアクセス ポリシーについて説明します。これは、mDNS クエリを作成したクライアントの mDNS 応答に、特定のサービス インスタンスを含める必要があるかどうかを判断するために役立ちます。さらに、複数のサービス インスタンスが同じアクセス ポリシーにマッピングされている場合、特定の mDNS クエリに関しては、特定のクエリのポリシー評価のオーバーヘッドを最適化するために、同じアクセス ポリシー マッピングを持つそれらのすべてのインスタンスに対して 1 回だけポリシーが評価されます。
mDNS ポリシーのクライアント コンテキスト属性
mDNS クエリを開始するクライアントは、クライアントのコンテキストを表す一連の属性に関連付けることができます。属性、たとえば場所は、クライアントが異なる場所に移動すると動的に変更されます。Bonjour アクセス ポリシー ルールを明確化するために、次に列挙された属性のみが使用されます。表 6-5 に、属性のリストとそれらを取得する方法について示しています。ユーザは、論理 OR 演算を使用してこれらの属性を組み合わせてルールを定式化し、そのルールをポリシーにアタッチできます。複数のルールをプロビジョニングできる場合でも、1 つのポリシーは単一のルールで構成されます。
表 6-5 属性およびそれらの使用方法
|
|
|
|
1 |
ROLE |
「teacher」や「student」などの文字列で、クライアントの DB と一貫しています。ISE または AAA によってクライアントにロールを関連付けることができます。 |
管理者は、ルールを作成するためにロール名とユーザ ID を追加する必要があります。 |
2 |
LOCATION |
クライアントの場所は文字列で、クライアントのAPの「ap-location」です。 |
これを使用してルールを設定する場合は、場所を指定する次の 3 つのいずれかを指定できます。
- ap-location
- ap-name
- ap-group name
|
3 |
USER-ID |
802.1x 認証中に、AAA または ISE によって、クライアントがクライアント DB に一貫しているかどうかが一意に識別されます。 |
ユーザは、ユーザ ID を使用してポリシーを設定する際に、まったく同じ文字列名を使用する必要があります。 |
アクセス ポリシー ルール
アクセス ポリシー サービス グループは名前で識別され、1 つのルールに関連付けられます。
ルールはロールまたはユーザ ID(カンマ区切りのリスト)を使用して定義されます。これは、mDNS クエリを作成するクライアントは、そのロールがポリシー ロールにリストされている中のいずれかであるか、またはクライアント ユーザ ID がユーザ ID リストにリストされている中のいずれかである場合に、サービス インスタンスへのアクセスが許可されることを意味しています。
ルールは、次のように定義されます。
[ROLE=teacher, student] AND [USER-ID = John, Mike]
Google Chromecast による mDNS リリース 8.2 のサポート
Chromecast は Google のメディア ストリーミング デバイスであり、高解像度ディスプレイの HDMI ポートに接続することができます。これにより、第 1 世代デバイスの 2.4 ワイヤレス接続によって、クライアント画面から大型画面(Chromecast デバイス搭載)に映写することができます。ユーザは Chrome ブラウザ(Windows7 ~ 10 または Mac ラップトップ)または Android の Chromecast アプリから、テレビ画面に音声/ビデオ コンテンツを表示させることができます。
Google は最近、新しい Chromecast と Chromecast Ultra(イーサネット ポート付き)をリリースしました。これらの製品では、2.4/5 GHz Wi-Fi サポートと内蔵適応型アンテナ システムにより、高解像度と低バッファリングが確保されています。
Chromecast には検出のための 2 つのプロトコルが実装されています。1 つは DIAL Protocol over SSDP です。これは、Google Cast の旧来の version1 で使用されているプライマリ システムです。2 番目のプロトコルでは mDNS(マルチキャスト ドメイン ネーム システム)プロトコルを使用して、ワイヤレス ネットワーク上で使用可能な Chromecast を検索します。v2 API をサポートする Chromecast を検出する方法としてはこちらがメインであり、一般的です。このドキュメントでは、Chromecast による mDNS デバイス検出に焦点を当てます。Chromecast 検出用に DIAL プロトコルを使用するデバイスについては、このドキュメントでは扱っていません。
(注) Chromecast がサポートするアプリが増えています(chromecast.com/apps)。シスコでは、Windows7 および MacBook Air クライアントで Chrome ブラウザ(Chromecast 拡張機能をインストール)をテストし、Android Samsung Galaxy S4、S6 Edge phone で Chromecast アプリをテストしました。
導入の考慮事項
mDNS プロトコルは、サービス通知やサービス クエリを受けて作動します。このためデバイスは下記のような特定のアプリケーションに対するクエリとアドバタイズを行うことができます。
- 印刷サービス
- ファイル共有サービス
- リモート デスクトップ サービス
- iTunes ファイル共有
- iTunes ワイヤレス iDevice 同期(Apple iOS v5.0 以降)
- 次のストリーミング サービスを提供する AirPlay:
– iOS v4.2 以降でのミュージックのブロードキャスト
–iOS v4.3 以降でのビデオのブロードキャスト
–全画面ミラーリング(iOS v5.0 以降(iPad2、iPhone4S 以降))
上記に加えて、次の特定のアプリケーションでは、mDNS を使用した Chromecast 検出を追加しています。
- Chromecast 拡張機能を有効にしたブラウザ(Windows7、MacBook Air)でのフルスクリーン ミラーリング
- Chromecast アプリ(Samsung Galaxy S4、Edge S6 phone)を使用した Android デバイスのミラーリング
各クエリまたはアドバタイズメントが mDNS マルチキャスト アドレスに送信されると、サブネット上のすべてのクライアントに配信されます。その場合は UDP ポート 5353 で動作する mDNS を使用して、各クエリまたはアドバタイズメントを次の予約グループ アドレスに送信します。
- IPv4 グループ アドレス – 224.0.0.251
mDNS プロトコルが使用するアドレスは、リンクローカル マルチキャスト アドレスであるため、ローカル L2 ドメインでのみ転送されます。ルータはマルチキャスト ルーティングを使用してトラフィックをリダイレクトすることはできません。これは、存続可能時間(ttl)が 1 に設定されており、リンクローカル マルチキャストは設計上ローカルであり続けるためです。これは、VLAN にセグメント化された大規模なネットワークには適していません。これより前のリリースでは、ユーザはエンドツーエンドでマルチキャストを設定し、このドキュメントで示すように VLAN 間でマルチキャスト パケットをルーティングする必要がありました。
https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/7-6/chromecastDG76/ChromecastDG76.html#pgfId-23144
mDNS を制御するには、ローカル セグメントのサイズを制限することが重要になります。
この問題を解決するために、Cisco WLC が Chromecast ゲートウェイとして機能します。WLC は Chromecast サービスをリッスンし、Chromecast サーバなどの送信元/ホストからの Chromecast アドバタイズメントをキャッシュします。サービスに対する要求が開始されると、Chrome クライアントに応答します。次にこのプロセスを示します。
1. コントローラは Chromecast サービス/アドバタイズメントをリッスンします。
2. WLC はそれらの Chromecast サービスをキャッシュします。
3. Chromecast サービスに対するクライアントのクエリをリッスンします。
4. WLC は Chromecast サービスに対するクライアント クエリにユニキャスト応答を送信します。
8.2 リリース以降、WLC は Chromecast 用 mDNS ゲートウェイ機能をサポートしています。ユーザはコントローラでマルチキャストを有効にする必要はありません。WLC は mDNS サービスのすべてのアドバタイズメントをスヌーピングし、また無線または有線ネットワークには同じものを転送しません。クライアントは、同じかまたは異なる VLAN に Chromecast サービス プロバイダーとして存在できます。mDNS AP がサポートされているため、コントローラは、コントローラから見えない VLAN 上にある有線 Chromecast サービス プロバイダーに対する可視性が得られます。
WLAN 上で UI を通じて Chromecast 用 NS ゲートウェイを設定
ステップ 1 クライアント VLAN とは 別個の VLAN にある Chromecast サービス用に、ダイナミック インターフェイスを作成し、WLC で Chromecast 機能の設定とデモンストレーションを行います。
次の例では、クライアントと Chromecast サーバ用の異なるインターフェイスと VLAN を示しています。
ステップ 2 クライアント用の WLAN を作成します。デフォルトでは、WLAN で mDNS スヌーピングが有効になっています。確認するには、[WLAN id] > [Advanced] タブを選択し、[mDNS Snooping] オプションが [Enabled] になっていることを確認します。default-mdns-profile として [mDNS Profile] を選択し、必要な mDNS サービスが特定の WLAN にアドバタイズされるようにします。[適用(Apply)] をクリックします。
Wi-Fi の考慮事項
Chromecast デバイスでは 802.1x がサポートされていないため、Chromecast 用に WPA2 PSK(Pre-Shared Key)をサポートする別個の SSID を作成することをお勧めします。