Cisco Catalyst 6500 シリーズ

Supervisor 2T が築く次世代型マルチキャスト ネットワーク

ホワイト ペーパー





Supervisor 2T が築く次世代型マルチキャスト ネットワーク



目次

概要

マルチキャストの重要性

機能詳細

   Supervisor 2T ハードウェアの概要

   ユニファイド IPv4/IPv6 MFIB インフラストラクチャ

   新しい出力レプリケーション(EDC サーバおよびクライアント)設計

   新しいマルチキャスト LTL および MET 共有設計

   FIB-XL で最大 256 K のマルチキャスト ルーティング

   ハードウェアの PIM-SM 送信元登録サポート

   ハードウェアの PIM-SM デュアル RPF サポート

   簡素化されたグローバル L2 IGMP スヌーピング設計

   IP ベース(非 DMAC ベース)の L2 フォワーディング ルックアップ

   ハードウェアの IGMPv3 および MLDv2 スヌーピング

   新しい Optimized Multicast Flooding(OMF)設計

   マルチキャスト VPN(MVPN)出力レプリケーション サポート

   8 PIM-BIDIR ハードウェア RPDF エントリのサポート

   FIB TCAM の IPv6 マルチキャスト(*,G)および(S,G)エントリ

   新しいインフラストラクチャによるマルチキャスト HA の強化

   VPLS、H-VPLS、および EoMPLS とのハードウェア統合

   CoPP 例外ケースと詳細なマルチキャスト レート制限

   NetFlow(v9)におけるマルチキャスト用の特殊なフィールドと処理

   詳細情報

まとめ

関連情報


Cisco Catalyst 6500 IP マルチキャスト テクノロジー

図 1 このネットワーク図は、IP マルチキャスト(テクノロジー)をサポートする、多種多様なネットワーク環境およびプラットフォームを表しています。ここで Catalyst 6500 シリーズは、無数のネットワーク セグメントのコアおよびディストリビューション レイヤの基盤としての役割を果たしています。Catalyst 6500 プラットフォームは、シスコのボーダレス ネットワーク内で真のエンドツーエンド メディアネット機能を実現します。

図 1 このネットワーク図は、IP マルチキャスト(テクノロジー)をサポートする、多種多様なネットワーク環境およびプラットフォームを表しています。ここで Catalyst 6500 シリーズは、無数のネットワーク セグメントのコアおよびディストリビューション レイヤの基盤としての役割を果たしています。Catalyst 6500 プラットフォームは、シスコのボーダレス ネットワーク内で真のエンドツーエンド メディアネット機能を実現します。
※画像をクリックすると、大きな画面で表示されますpopup_icon


Catalyst 6500 + IP マルチキャスト展開のその他の例は、以下を参照してください。

http://www.cisco.com/en/US/technologies/tk648/tk828/technologies_case_study0900aecd802e2ce2.html [英語]

http://www.redorbit.com/news/technology/243889/
new_york_university_deploys_north_americas_first_native_ipv6_multicast/index.html
[英語]

http://www.cisco.com/en/US/solutions/ns341/ns898/nbc_2010_olympic_winter_games.html [英語]

概要

熟練したマルチキャスト エキスパートでも、マルチキャストを初めて導入する場合でも、新しい Catalyst 6500 Supervisor 2T は役に立ちます。

また、巨大なエンタープライズ クラスのネットワーク、小規模の会社のネットワーク、いずれの場合に対しても、新しい Supervisor 2T はマルチキャスト ソリューションを提供します。

このホワイト ペーパーは、現在 Supervisor 2T で利用可能となった、特に IP マルチキャストのために設計された、ハードウェアおよびソフトウェア両面での新機能および強化された機能を紹介します。

Supervisor 2T 機能の概要

上級者向けヒント:各機能について詳しい説明を見るには、リンクをクリックしてください。

Supervisor 2T ハードウェアの概要 Supervisor 2T で利用できる新しいハードウェア コンポーネントを紹介します。
ユニファイド IPv4/IPv6 MFIB インフラストラクチャ 最適化されたハードウェア インフラストラクチャ。L2/L3 のスケーラビリティに主眼を置いて設計されました。
新しい出力レプリケーション(EDC サーバおよびクライアント)設計 モジュール間のマルチキャスト フレーム ディストリビューションを最適化します。
新しいマルチキャスト LTL および MET 共有設計 内部フォワーディング リソースを節約して、共用パスで使用されるようにします。
FIB-XL で最大 256 K の IPv4 マルチキャスト ルーティング これまでにないハードウェアベースのマルチキャスト スケーラビリティを提供します。
ハードウェアの PIM-SM 送信元登録サポート CPU およびメモリの使用を節約し、送信元の登録時間を短縮します。
ハードウェアの PIM-SM デュアル RPF サポート CPU およびメモリの使用を節約し、SPT スイッチオーバー時間を短縮します。
簡素化されたグローバル L2 IGMP スヌーピング設計 簡素化された L2 スヌーピング構成およびクエリア冗長構成を提供します。
IP ベース(非 DMAC ベース)の L2 フォワーディング ルックアップ L2 マルチキャストに備えて IP-to-MAC アドレス オーバーラップを排除します。
ハードウェアの IGMPv3 および MLDv2 スヌーピング ホスト トラッキング 加入と脱退による IPv4/IPv6 PIM-SSM L2 ホスト テーブルの更新を高速化します。
新しい L2 Optimized Multicast Flooding(OMF)設計 「source-only」VLAN のためにフォワーディング リソースおよび帯域幅を節約します。
マルチキャスト VPN(MVPN)出力レプリケーション サポート MVPN/eMVPN フォワーディング時のスイッチ ファブリック帯域幅を節約します。
8 PIM-BIDIR ハードウェア RPDF エントリのサポート ハードウェアで同時に 8 つの RP 定義が可能です。
FIB TCAM の IPv6 マルチキャスト(*,G)および(S,G)エントリ IPv6 ハードウェアベースのフォワーディング強化により、遅延を軽減します。
新しいインフラストラクチャによるマルチキャスト HA の強化 新しいインフラストラクチャに構築されたハイ アベイラビリティにより、スイッチオーバーが最適化されます。
VPLS、H-VPLS、および EoMPLS とのハードウェア統合 高度な L2 VPN ネットワーク設計を目的として、マルチキャストをハードウェアでサポートします。
CoPP 例外ケースとより詳細なマルチキャスト レート制限 CPU に送信されるマルチキャスト トラフィックに対するコントロールプレーンの保護が強化されました。
NetFlow(v9 および FnF)におけるマルチキャスト用の特殊なフィールドと処理 マルチキャスト フローの NFv9 + Flexible NetFlow および出力 NDE サポートを一新しました。


注: このホワイト ペーパーは、以前の Catalyst 6500 世代ですでに利用可能であった既存の IP マルチキャスト機能については、改めて詳細を取り上げることはありません。

IPv4 multicast with Supervisor 720 および 12.2SX IOS の詳細については、
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/mcastv4.html [英語] を参照してください。

また、IPv6 multicast with Supervisor 720 および 12.2SX IOS の詳細については、
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/mcastv6.html [英語] を参照してください。

注: このホワイト ペーパーでは、IP マルチキャストをテクノロジーとして改めて取り上げることはありません。

Cisco IOS の IP マルチキャストの詳細については、http://www.cisco.com/go/multicast/ [英語] を参照してください。

マルチキャストの重要性

大量のデータを複数のホストに同時に配信する必要はないでしょうか。たとえば、以下のような用途です。


  • サービス プロバイダーまたはコンテンツ プロバイダー
  • 金融機関
  • 小売流通業者
  • 交通局
  • 警備会社
  • データのバックアップ

次世代の IP マルチキャスト ネットワークを構築する必要はありませんか。IP マルチキャスト ネットワーク(従来のシスコ機器またはシスコ以外の機器を使用して構築)を導入したものの、コンバージェンスの遅さ、パケット重複またはパケット損失、さらには CPU 使用率の高さに悩まされているのではないでしょうか。

ユニキャストおよびブロードキャスト形式の通信は、動作は快適ですが拡張性に欠けます。ユニキャストは、受信ノードごとに個別フローが必要な 1 対 1 フローを使用します。ブロードキャストは 1 対全のフローを使用するので、関係のないノードのネットワーク リソースが無駄になります。

IP マルチキャストは、IP ネットワーク内の複数のホストに対してデータを同時に配信する(具体的には単一の伝送)ために設計された、特殊なフォワーディング パラダイムです。データを受信するホストまたはその数を事前に知る必要がないため、受信者に応じて拡張することができます。

マルチキャストは、1 対多および多対多のディストリビューション ツリー フォワーディング モデルを使用し、リアルタイムの通信データを IP ネットワークを経由して複数の受信ノードに配信します。このモデルは、ネットワーク帯域幅を損なわずに同じデータを多くのホストに配信する必要があるアプリケーションに最適です(ブロードキャストまたは複数のユニキャスト セッションなど)。

ただし、IP ネットワーク インフラストラクチャが運用を最適化し簡素化する特別な機能をサポートしていない場合、マルチキャストは非常に複雑になり問題を抱えることになりかねません。

新しい Supervisor 2T は、ユーザのニーズを念頭に置いて構築されました。幅広く導入されている Supervisor 720 を基に設計された Supervisor 2T は、既存機能の多くを強化すると同時に新機能を加え、次世代のマルチキャスト ネットワークに備えて、スケーラビリティとコンバージェンスを強化しました。

機能詳細

テクノロジーとしての IP マルチキャストは、この数年で見違えるほど成熟しました。たとえば、PIM-SM(RFC-4601)は、一般に PIM-DM(RFC-3973)よりも柔軟で抑制されています。ただし、強化された柔軟性を発揮し、しかもネットワーク帯域幅を節約するには、2 つの異なるディストリビューション ツリー モデル(送信元ベースつまり(S,G)ベース、および Rendezvous Point(RP; ランデブー ポイント)ベースつまり(*,G)ベース))を扱うことになり、運用は非常に複雑になります。

送信元ベース ツリーは、複数の mroute ステートを消費して最短のパス フォワーディングを提供します。一方、RP べース ツリーは必要な mroute ステートは送信元ベース ツリーよりも少なく済みますが、潜在的に最適ではないルートを使用するという代償もあります。このような PIM-SM に固有な運用の複雑性により、以下の特殊な改良手段が開発されました。

  • (S,G)送信元ツリーをベースにした送信元固有マルチキャスト(RFC-4607
  • (*,G)共有または RP ツリーをベースにした双方向 PIM(RFC-5015

以下の図はこの導入の進化を示します。

図 2 PIM の進化

図 2 PIM の進化
※画像をクリックすると、大きな画面で表示されますpopup_icon


これらの異なる PIM フォワーディング モードと並んで、IP マルチキャストにはさまざまなアプリケーション固有の使用方法があり、必然的に、固有ネットワーク プラットフォームおよび設計も数多く存在します。

このように、IP マルチキャストは、多くの異なるネットワーク プラットフォームおよびベンダーのほぼすべてが最高の製品であると主張し、(一見するだけでは)同じに見えるほど技術的に成熟しています。

それでは、マルチキャスト ネットワーク エンジニアはそのすべてをどのように理解しているでしょうか。まず、次の簡単な 5 つの質問をベンダーに聞いてみてください。

  1. 機能 X をサポートしていますが、ソフトウェアとハードウェアのどちらでサポートしていますか。
  2. ハードウェアでサポートしている場合、サブ機能とオプションは何がありますか。
  3. 機能 X のハードウェア テーブルはどのくらいの規模ですか(スケーラビリティの制限はどのくらいですか)。
  4. これらすべての要素は、機能 X のパフォーマンスと遅延にどのように影響しますか。
  5. 機能 X のコンポーネントすべてのモニタとデバッグはどのくらい簡単に実行できますか。

以降のセクションでは、真の次世代型 IP マルチキャスト ネットワーク構築を可能にした、新しい Catalyst 6500 Supervisor 2T のさまざまな設計方法と、具体的な問題の解消について説明します。

このドキュメントはまず、基本的な Supervisor 2T ハードウェアの概要を取り上げ、ハードウェア レイヤ 2(L2)およびレイヤ 3(L3)IP マルチキャスト フォワーディングを可能にする重要なコンポーネントの理解を深めます。また、従来のモデルおよび競合製品のどちらとも大きく異なる、前述した重要な分野をいくつか説明します。

その後のセクションでは、Supervisor 2T でのみ使用可能な IP マルチキャストの新機能および強化機能を確認します。主要セクションはそれぞれ新機能または強化機能を 1 つ取り上げ、さらに 3 つのサブセクションに分かれています。

  • これまでの課題:Supervisor 720 以前の類似機能を説明します。
  • 現在のソリューション:Supervisor 2T の新機能、または強化機能を説明します。
  • どのように役立つか:ユーザの利点と使用例を簡単にまとめます。

このドキュメントは、読者が自分の興味のあるセクションだけを読むことができるように構成されています。

Supervisor 2T ハードウェアの概要
IP マルチキャストに未知のパフォーマンスとスケーラビリティをもたらします。

図 3 Supervisor 2T の重要な要素

図 3 Supervisor 2T の重要な要素


新しい Supervisor 2T は、次の 3 つの主要ハードウェア要素を採用しています。

  • Multilayer Switch Feature Card 5(MSFC5; マルチレイヤ スイッチ フィーチャ カード 5)
  • Policy Feature Card 4(PFC4; ポリシー フィーチャ カード 4)
  • 2 Tbps(26 チャネル)スイッチ ファブリック
図 4 Supervisor 2T の主要 3 コンポーネント

図 4 Supervisor 2T の主要 3 コンポーネント


図 5 Supervisor 2T マルチキャスト ハードウェア

図 5 Supervisor 2T マルチキャスト ハードウェア
※画像をクリックすると、大きな画面で表示されますpopup_icon


MSFC5 の概要

MSFC5 はコントロールプレーン コンポーネントです。L2 および L3 のフォワーディング情報を学習する IOS ソフトウェアを実行します。IP マルチキャストのコントロールプレーン プロセスおよびプロトコル(IP マルチキャスト ルーティング、PIM、IGMP、MLD、MSDP、その他)は、すべて MSFC 上で動作します。フォワーディング テーブルがネゴシエーションし、ソフトウェア テーブルに入力されると、この情報はハードウェアフォワーディング インフラストラクチャにプログラムされます。

表 1 MSFC5 の概要

機能 MSFC3(Supervisor 720) MSFC5(Supervisor 2T)
CPU 速度 SP CPU(600 MHz)
RP CPU(600 MHz)
デュアルコア CPU
それぞれ 1.5 GHz(3 GHz)
DRAM SP CPU - 最大 1 GB
RP CPU - 最大 1 GB
2 GB(最大 4 GB)
Connectivity Management Processor
(CMP; 接続管理プロセッサ)
なし 単一 CPU(266 MHz)
ブートフラッシュ:32 MB
システム メモリ:256 MB
USB コンソール/データ ポート 使用不可 USB RP コンソール -または-
USB 2.0 データ転送
NVRAM 2 MB 4 MB
OBFL フラッシュ なし 4 MB
ブートフラッシュ/ブートディスク SP CPU - 1 GB(CF)
RP CPU - 64 MB(フラッシュ)
1 GB(CF)


PFC/DFC4 の概要

PFC4 は、データプレーン コンポーネントであり、コントロールプレーンによって学習されプログラムされたフォワーディング情報すべてをハードウェアで実現したものです。PFC4 ASIC テーブルをプログラムすることで、すべての後続する L2 および L3 フォワーディング決定を完全にハードウェア内で実行できます。

PFC4 を利用できるタイプは、必要な L2 および L3 フォワーディング エントリ数に応じて 2 通りあります(XL および非 XL)。XL タイプは最高 1 M のハードウェア エントリをサポートしますが、非 XL は最高 256 K です。どちらの PFC4 モデルも、L2 および IPv4 L3 マルチキャストで最高 60 Mpps 、Multicast Virtual Private Network(MVPN; マルチキャスト バーチャル プライベート ネットワーク)などの IPv6 L3 およびカプセル化マルチキャストで最高 30 Mpps のフォワーディング ルックアップ レートに対応しています。

Catalyst 6500 プラットフォームはモジュール設計です。PFC4 の同じ機能とパフォーマンスはすべて、Distributed Forwarding Card(DFC4; 分散型フォワーディング カード 4)を搭載した個別の LAN モジュールに拡張できます。DFC4 は、PFC4 からフォワーディング決定をオフロードし、システム内の DFC4 の数でスケーラビリティを倍増します(最高 720 Mpps)。

表 2 PFC4 の概要

機能 PFC/DFC3 PFC/DFC4
L2(v4/v6)および IPv4 L3 のパフォーマンス 30/48 Mpps 60 Mpps
IPv6 L3 およびカプセル化のパフォーマンス 12/24 Mpps 30 Mpps
FIB(非 XL)
FIB(XL)
256 K エントリ
1 M エントリ
256 K エントリ
1 M エントリ
L2 ブリッジ ドメイン 4 K(VLAN の数) 16 K(BD)
L3 論理インターフェイス 4 K(VLAN と共有) 128 K(LIF)
L2 MAC アドレス テーブル PFC3B:64 K
PFC3C:96 K
128 K
VPN の数 4 K 16 K(IPv4)
8 K(IPv6)
RPF インターフェイス 2 16
PIM-Bidir RPDF 4 8
NetFlow エントリ 256 K(入力のみ) 512 K 入力
512 K 出力(XL デフォルト)
ネイティブ VPLS 非対応 対応
ネイティブ CTS 非対応 対応
Flexible NetFlow 非対応 対応
ACL および QoS TCAM 32 K(ACL)および 32 K(QoS) 最高 256 K(共有)
セキュリティ ACE 最高 32 K 最高 192 K(XL デフォルト)
QoS ACE 最高 32 K 最高 64 K(XL デフォルト)
ポート ACL 2 K 8 K
集約ポリサー 1 K 6 K
マイクロフロー ポリサー 63 512
レート リミッタ L3:8
L2:4
L3:32
L2:12


2T スイッチ ファブリックの概要

2 Tbps スイッチ ファブリックは、すべての マルチキャスト パケット フォワーディングおよびレプリケーションが行われる物理的なバックプレーン データ パスを提供します。20 または 40 Gbps のいずれかで動作する 26 の専用ファブリック チャネルをサポートします。

CEF720 および CEF2T シリーズの LAN モジュールは、CEF720 で合計 40 Gbps、CEF2T で合計 80 Gbps を実現するデュアル ファブリック チャネルをサポートします。さらに、2T スイッチ ファブリックは、CEF2T モジュールの冗長チャネルを提供し、Stateful Switch-Over(SSO; ステートフル スイッチオーバー)および ISSU フェールオーバーを高速化します。

表 3 2T スイッチ ファブリックの概要

機能 Supervisor 720 Supervisor 2T
合計ファブリック帯域幅 720 ギガビット/秒 2 テラビット/秒
個別のファブリック チャネル帯域幅 8 Gbps(CEF256)
20 Gbps(CEF720)
20 Gbps(CEF720)
40 Gbps(CEF2T)
ファブリック チャネルの合計数 18(Sup 720-3B)
20(Sup 720-3C)
26
冗長ファブリック 対応 対応
冗長チャネル 非対応 対応


サポートしている LAN モジュール

新しい Supervisor 2T では、以下の 4 タイプのモジュールをサポートしています。

  • 新しい WS-X6900(または CEF2T)シリーズ、DFC4 取り付け済み
  • 新しい WS-X6800(または CEF720)シリーズ、DFC4 取り付け済み
  • 既存の WS-X6700(または CEF720)シリーズ、DFC4 あり/なし
  • 一部の WS-X6100(または Classic)シリーズ モジュール

注: 一般的なフォワーディング アーキテクチャおよびこれらのさまざまなモジュール タイプの動作については、このドキュメントでは取り上げませんが、IP マルチキャストの動作のそれぞれについて簡単に復習しておくと役に立ちます。

各世代の LAN モジュールには、それぞれ異なるレベルのマルチキャスト独自の ASIC サポートと関連機能があります。最新世代のモジュールは、特別なマルチキャスト パケット レプリケーション機能と、同じく特別なパケット スケジューリングおよびバッファリング機能をサポートしています。

注: IP マルチキャスト フォワーディングに使用する LAN モジュールを選ぶ際は、従来のユニキャスト容量計画を上回る注意が必要です。

新しい WS-X6900(または CEF2T)世代は、4 つの Fabric Interface および Replication Engine(FIRE; ファブリック インターフェイスおよびレプリケーション エンジン)ASIC コンプレックスを使用して、デュアル 40 Gbps ファブリック チャネル(モジュールあたり合計 80 Gbps)をサポートしています。それぞれの FIRE ASIC は、最高 20 Gbps の L2 および L3 マルチキャスト パケット レプリケーション、つまり元のパケット数に Outgoing Interface(OIF; 発信インターフェイス)の数を掛けた容量を処理できます。このクラスの LAN モジュールは、中規模から大規模の IP マルチキャスト展開に適しています。

図 6 WS-X6900(CEF2T)+ DFC4 モジュール

図 6 WS-X6900(CEF2T)+ DFC4 モジュール
※画像をクリックすると、大きな画面で表示されますpopup_icon


現在の WS-X6700(または CEF720)世代は、2 つの FIRE ASIC コンプレックスを使用して、デュアル 20 Gbps ファブリック チャネル(モジュールあたり合計 40 Gbps)をサポートしています。CEF720 は、WS-X6700 + CFC および WS-X6800 + DFC4 の 2 タイプをサポートしています。

分散型フォワーディング カード(DFC4)を使用する CEF720 モジュールは、ローカルの L2 および L3 入力または出力マルチキャスト パケット レプリケーションと、出力ローカル最適化をサポートしており、すべてのフォワーディング決定はローカルで実行されます。現在これらのモジュールは、動作の違いから WS-X6800 シリーズと呼ばれています。このクラスの LAN モジュールは、中規模の IP マルチキャスト展開に適しています。

図 7 WS-X6800(CEF720)+ DFC4 モジュール

図 7 WS-X6800(CEF720)+ DFC4 モジュール
※画像をクリックすると、大きな画面で表示されますpopup_icon


集中型フォワーディング カード(CFC)を使用する CEF720 モジュールは、ローカルの L2 および L3 入力または出力マルチキャスト パケット レプリケーションをサポートしていますが、すべてのフォワーディング決定は集中型 PFC4 に依存する必要があります。これらのモジュールは、引き続き WS-X6700 シリーズと呼ばれます。このクラスの LAN モジュールは、小規模な IP マルチキャスト展開に十分な機能を備えていますが、規模が大きくなればアップグレードが必要です。

図 8 WS-X6700(CEF720)および CFC モジュール

図 8 WS-X6700(CEF720)および CFC モジュール
※画像をクリックすると、大きな画面で表示されますpopup_icon


従来の WS-X6100(または Classic)世代は、共有 32 Gbps データ バスへの単一のバスベース接続をサポートし、L2 および L3 マルチキャスト パケット レプリケーションは Supervisor FIRE ASIC コンプレックスに依存し、フォワーディング決定は PFC4 に依存しています。このクラスの LAN モジュールは、IP マルチキャスト展開には推奨しませんが、限定的または低い帯域幅ベースでの使用は可能です。

注: これらのモジュールは、IP 電話などのエッジ接続される Power-over-Ethernet(PoE)デバイスを主な用途としています。

図 9 WS-X6100(Classic)モジュール

図 9 WS-X6100(Classic)モジュール
※画像をクリックすると、大きな画面で表示されますpopup_icon


上級者向けヒント:Supervisor 2T アーキテクチャ の詳細については、
http://www.cisco.com/en/US/docs/ios-xml/ios/lanswitch/configuration/12-4t/
lsw-ml-sw-over.html#GUID-5D8EB2A0-341A-4FFA-8CDB-38D34286986D
[英語] を参照してください。

ユニファイド IPv4/IPv6 MFIB インフラストラクチャ
L2/L3 スケーラビリティを主眼に置いた、最適化されたハードウェア インフラストラクチャを構築します。

これまでの課題

IPv4 マルチキャスト L2/L3 マルチレイヤ スイッチングが最初に導入されたのは、2000 年代の始めの Catalyst 6500 でした。当時はあまりに独自で革新的であったため、新しい IP マルチキャスト ハードウェア固有機能の多くが単独で設計されました。

その後、開発部門により、標準ベースの Protocol Independent Multicast(PIM)および Internet Group Management Protocol(IGMP; インターネット グループ管理プロトコル)のソフトウェアベース機能を、ハードウェアベースのコード機能に具体化するまったく新しい方法が生み出されました。これは、Multicast Multi-Layer Switching(MMLS; マルチキャスト マルチレイヤ スイッチング)インフラストラクチャと呼ばれるようになります。

上級者向けヒント:MMLS の詳細については、
http://www.cisco.com/en/US/docs/ios/lanswitch/configuration/guide/lsw_ml_sw_over.html#wp1001111 [英語] を参照してください。

他の多くのシスコ プラットフォームがハードウェアベースの IP マルチキャスト機能を実装し始めると、単一で機能を問わず使用できる IP マルチキャスト ハードウェア インフラストラクチャ コードが必要なことがはっきりしてきました。

これが、Multicast Forwarding Information Base(MFIB; マルチキャスト転送情報ベース)プラットフォーム非依存型インフラストラクチャの開発につながります。MFIB は、プラットフォーム固有の情報に依存しない、標準化されたインフラストラクチャを使用して、コントロールプレーンをデータプレーンから論理的に切り離すことを目的として設計されました。

上級者向けヒント:MFIB の詳細については、
http://www.cisco.com/en/US/docs/ios/ipmulti/configuration/guide/imc_mfib_overview.html [英語] を参照してください。

注: IPv6 マルチキャストが初めて Catalyst 6500 に採用されたとき、すべての Cisco IOS プラットフォームを MFIB に移行する開発決定が行われました。結果として(Supervisor 720 も例外ではなく)、IPv6 マルチキャストで MFIB インフラストラクチャを使用することになりました。

ただし、先に述べたとおり、Catalyst 6500 IPv4 MMLS インフラストラクチャはこの時点ですでに確立されていました。シスコのお客様の多くはネットワーク運用を変更することを望まなかったため、これが問題になりました。このため、IPv6 マルチキャストは MFIB を使用するが、IPv4 マルチキャストは MMLS の使用を継続することになりました。

これは良くないことだったのでしょうか。答えは、「いいえ」です。単に、一貫性がなかっただけです。IPv4 および IPv6 両方を担当するネットワーク管理者は、両者の違いを理解し、管理する必要がありました。また、時間の経過に伴い、Catalyst 6500 IPv4 マルチキャストのコード開発は、他の Cisco IOS プラットフォームとは大きく離れていきました。

現在のソリューション

新しい Supervisor 2T および PFC/DFC4 では、MFIB を使用した新しい IOS コードが、最終的に IPv4 と IPv6 のハードウェア インフラストラクチャを統合しました。これによって、ネットワーク運用スタッフは IPv4 および IPv6 マルチキャストのいずれか、または両方を単一の一貫した CLI から操作し、デバッグできるようになります。

また、MFIB のすべての利点が IPv4 マルチキャストに適用されます。たとえば、次の利点があります。

  • コントロール/データ(フォワーディング)プレーンを根本から分離することで、全体的な IP マルチキャストの動作を簡素化します。
  • PIM、IGMP、または Multicast Listener Discovery(MLD; マルチキャスト リスナー検出)モードとは無関係に、すべてのインターフェイスを同等に扱うことができます。
  • マルチキャスト ファストスイッチングなどのデマンド キャッシング スキームに付随するルートキャッシュのメンテナンスの必要性を排除します。
  • ルータ ローカルの Group-to-RP マッピング キャッシュ内にあるグループ範囲を記述するため、(*, G/mask)エントリを導入します。
  • PIM-SM(スパース モード)の送信元登録プロセスに PIM RP トンネル インターフェイスを採用して、コントロール プレーンとフォワーディング プレーンをさらに分離します。

注: これは、Catalyst 6500 で IPv4 マルチキャストの設定、監視、デバッグを行う運用上の変更を意味します。

プラットフォームに依存しないソフトウェア コンポーネント(PIM および IGMP/MLD IOS プロセスなど)、およびそれらと関連する CLI 設定とモニタリングのコマンドはすべて変更されません。変更されないコマンドには、show ip mroute、show ip pim neighbors、show ip igmp groups などがあります。

ただし、すべてのプラットフォーム依存 IPv4 マルチキャスト CLI(以前の MMLS ベース)コマンドは、同等の機能を持つ MFIB のコマンドに変更されています。

注: このホワイト ペーパーで取り上げる CLI コマンドは多すぎるため、以下に挙げたものはごく一部の基本的な例です。

上級者向けヒント:IPv4 MFIB 検証
http://www.cisco.com/en/US/docs/ios/ios_xe/ipmulti/configuration/guide/imc_verify_mfib_xe.html [英語] を確認してください。

どのように役立つか

ユニファイド IPv4/IPv6 MFIB インフラストラクチャは、マルチキャスト ソフトウェア ルーティングをハードウェア プログラムに具体化する一貫した、プラットフォーム非依存型の基盤をユーザに提供します。

これによって、ハードウェア フォワーディング処理の一貫性と信頼性が高まると同時に、単一のコマンド ライン インターフェイスによる IPv4 および IPv6 マルチキャスト管理が実現します。

また、IP マルチキャスト ネットワーク管理者は、担当する IPv4 および IPv6 マルチキャスト環境の構成、監視、およびデバッグに対する単一の一貫したアプローチをここから会得し、使用することができます。

現在 Catalyst 6500 IPv4 マルチキャスト(ソフトウェアおよびハードウェア)導入は、他のシスコ プラットフォームと互換性があります。これにより、ネットワーク管理者は、IP マルチキャスト ネットワーク全体をカバーする単一の作業環境が利用できるようになりました。

図 10 ユニファイド MFIB インフラストラクチャ

図 10 ユニファイド MFIB インフラストラクチャ


注: 新しい MFIB インフラストラクチャを構成する他のすべての相互運用コンポーネント、Egress Distribution Component(EDC)、Multicast Expansion Table(MET)、Local Target Logic(LTL)などは、以降のセクションで詳細に説明します。

新しい出力レプリケーション(EDC サーバおよびクライアント)設計
モジュール間の内部マルチキャスト パケット ディストリビューションを最適化します。

これまでの課題

フォワーディングのスケーラビリティおよび容量が従来の集中型またはバスベース モデルを大幅に上回る、より新しい配信またはスイッチベースの内部パケットフォワーディング モデル(ファブリック接続モジュールおよび DFC を使用)が最近になって普及したことに伴い、まったく新しいマルチキャスト要件が登場しました。

この新しいスイッチベースのフォワーディング モデルには、送信元のフレームを複数の宛先モジュールに配信する新しいメカニズムが必要でした。すべてのモジュールが接続された共有バスで単純にフレームをフォワーディングするのではなく、集中型のスイッチング コンプレックスを使用します。

注: この 2 つの内部パケット フォワーディング モデルの違いは、おおよそ、「スイッチドまたはスターベース」のフォワーディング データ パケットと、「バスベース」のイーサネット ネットワークを比較した場合の、既知の長所と短所に似ています。

スイッチベースとバスベースのフォワーディング モデルのパフォーマンスと動作の違いを、以下に簡単にまとめました。

集中型バスベース フォワーディング

  • 長所:すべてのノードが同じソース データを同時に受信する、高速でシンプルなフォワーディング モデル
  • 短所:必要のあるなしにかかわらず、すべてのノードが同じソース データを受信するため、関係のない受信者も不要なパケット処理を行う

分散型スイッチベース フォワーディング

  • 長所:専用のポイントツーポイント接続で使用可能な帯域幅を確保し、スケーラビリティを高く、遅延を低くすることができる
  • 短所:同じソース データを複数のノードに転送するには特別なインテリジェンス(CPU または ASIC など)が必要。また、転送先ノードにはパケット レプリケーションが必要

Catalyst のハードウェア スイッチングでは、これらの異なるノードは個別のイーサネット スイッチング モジュールであり、ノード間の「接続」は DBUS(データバスベース)またはスイッチ ファブリック(スイッチベース)のいずれかになります。

Supervisor 2 と 256 Gbps の Switch Fabric Module(SFM; スイッチ ファブリック モジュール)の登場で、WS-X6500 シリーズのスイッチング モジュールは、単一の(専用)8 Gbps ファブリック チャネルでプロビジョニングされました。この構成では、推奨フォワーディング モデルが分散型(スイッチベース)になりました。

注: Supervisor 720 では、20 Gbps で動作する 18 の専用ファブリック チャネルをサポートできる、統合型の 720 Gbps スイッチ ファブリック ASIC コンプレックスが登場しました。

先に触れたように、新しい分散型スイッチング モデルは、送信元(つまり入力)LAN モジュールからのマルチキャスト パケットがすべての宛先(つまり出力)モジュールに単純にフラッディングされなくなったことを意味します。そのため、送信元パケットをそれぞれの宛先ファブリック チャネルにレプリケート、つまりコピーする必要があります。これが、入力レプリケーション モードの開発につながりました。

このモードには、すべての発信(つまり出力)モジュールに対して、OIF あたり、IP マルチキャスト ルート(または mroute)あたりで、1 パケット レプリケーションを実行する受信(または入力)モジュールのみが必要です。それぞれの追加 OIF(mroute あたり)で、追加のパケット レプリケーションが行われます。

注: 入力レプリケーション モードは非常に効率的ですが、すべてのレプリケートされたパケットが、スイッチ ファブリックを横断し、このとき、帯域幅およびバッファ(特に入力モジュールのファブリック チャネル)を消費します。

入力レプリケーション設計の制限を基本として使用した、新世代のファブリック スイッチングおよびレプリケーション ASIC が WS-X6700 シリーズ モジュール用に開発され、これによって新しい出力レプリケーション モードの開発が可能になりました。

出力レプリケーション モードが必要とするのは、自身のポートのレプリケーションを作成する出力モジュールのみです(ローカルの受信者が存在する場合)。次に、このモードでは追加(内部)レプリケーションが作成され、これがすべての出力モジュールに(出力 VLAN とも呼ばれる Internal Central Rewrite OIF(ICROIF)から)配信されます。各出力モジュールは、受信後にそれぞれのローカル OIF の追加レプリケーションを実行します。

注: このモデルは、スイッチ ファブリックを横断するパケットは 1 つ(mroute あたり)しか必要としないため、内部の帯域幅とバッファの節約となり、その効率はさらに向上しました。

上級者向けヒント:入力および出力レプリケーション モードの詳細については、
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/mcastv4.html#wp1076728 [英語] を参照してください。

すべての新しく革新的なテクノロジーと同じく、オリジナルの出力レプリケーション モードの実装とより新しい世代の Catalyst 6500 ハードウェアからは、一連の新たな技術的課題が生まれました(以下にまとめます)。また、個々の新たな課題により、オリジナルの実装の動作には変更が加わりました。

特に、PFC3 ベースの出力レプリケーション モデルには、次の課題があります。

  1. 全出力対応モジュールの非セッション志向配信リストを使用し、これが ICROIF(または出力 VLAN)に追加される。
  2. 出力レプリケーションおよび転送の前に、送信元マルチキャスト パケットが実際にいつ、どこで書き換えられるか。
  3. より新しい CEF720 イーサネット モジュールのデュアルファブリック チャネル(およびファブリック インターフェイスおよびレプリケーション エンジン ASIC)。
  4. 出力レプリケーション モードにハイ アベイラビリティ(SSO)を取り入れる必要性。

これらのケースが難しい理由は何でしょうか。

  1. 出力レプリケーション モードでは、特別な内部出力 VLAN を使用して、レプリケートされたマルチキャスト パケットをすべての出力(宛先)モジュールに配信します。この内部 VLAN のメンバーシップは、単に配信リスト内の全出力対応モジュールに含まれるかどうかで判断されます。その上、出力 VLAN(VRF あたり)は 1 つしか存在しません。したがって、すべてのプログラミング メッセージが(伝送後に)到着するかどうかの保証はなく、すべてのグループと関連出力モジュールが同じコンテキストを共有します。
  2. マルチキャスト グループに転送されるマルチキャスト パケットは、最初に(FIRE ASIC によって)書き換えられ、その後 OIF ごとに 1 回で合計 N 回レプリケートされます。エッジ展開では、出力ポリシー(たとえば QoS やカプセル化)を実行する必要があるのはグループ内の一部の受信者のみであり、他は必要ないため、ここに問題が発生します。
  3. より新しいデュアル ファブリック チャネル CEF720 モジュール(以前の単一のファブリック チャネル システム)の登場によって、パケットを両方のファブリック チャネルに送信する機能が必要になりました。フロントパネル ポートは 2 チャネルの 1 つのみに接続されているため、ASIC 帯域幅は他のチャネル上で無用に消費されます。この課題は、出力のローカル最適化によって部分的に解消されます。
  4. 上級者向けヒント:出力のローカル最適化の詳細については、
    http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/mcastv4.html#wp1093310 [英語] を参照してください。

  5. IP マルチキャストのハイ アベイラビリティは、SSO が使用する Redundancy Framework(RF; 冗長フレームワーク)および Checkpoint Framework(CF; チェックポイント フレームワーク)のサーバ/クライアント モデルから提供されます。アクティブ スーパーバイザが出力レプリケーション エントリをプログラムするため、出力トラフィックの転送は SSO の間一時的に中断されますが、出力エントリは新しいアクティブ スーパーバイザに再インストールされます。

これは良くないことなのでしょうか。答えは、「はい」でもあり「いいえ」でもあります。最初の 2 つの課題は、IP マルチキャスト トラフィックの転送を行う Fabric-Interface and Replication-Engine(FIRE; ファブリックインターフェイスとレプリケーションエンジン)ASIC およびスイッチ ファブリック帯域幅の浪費につながるおそれがあります。大規模に拡張した IP マルチキャスト ネットワークをまだ使用していない場合は、おそらくこのような問題は発生しないと言ってよいでしょう。

後の 2 つの課題は特殊なケースで、問題というよりは制限事項にあたります。出力機能(MVPN カプセル化など)を適用することもできますが、現行アーキテクチャではサポートされていません。過去に SSO を経験したことがある場合は、いずれにせよ損失が見込まれますが、できる限り迅速に再コンバージェンスするのも 1 つの方法です。

現在のソリューション

新しい Supervisor 2T では、ユニファイド MFIB ハードウェア インフラストラクチャの重要な部分が、新しい EDC サーバ/クライアント モデルになっています。この新しい出力レプリケーション設計は、以前の最適化をすべてサポートしているうえ、いくつかの新しい最適化も加わっているため、より効率的にハードウェア固有(たとえばリンクステート)の変更やプログラミングを処理できます。

この新しい EDC ベースの出力レプリケーション モデルは、先に述べたすべての課題を克服しています。

  1. 出力レプリケーション プログラミングは、セッション志向のサーバ/クライアント モデルを使用して、レプリケートしたパケットの送信先を判断するようになりました。
  2. 出力レプリケートされたマルチキャスト パケットは出力レプリケーションの後に書き換えられるため、出力ポリシーとカプセル化が可能になりました。
  3. デュアル ファブリック チャネル(および関連ポートとファブリック インデックス)は、個別かつ効率的に処理されるようになりました。
  4. 出力レプリケーション モードは、ハイ アベイラビリティ(SSO)と完全な互換性があります。

第 1 に、そしておそらく最も重要なこととして、EDC 設計では、すべての配信出力レプリケーション ASIC プログラミングにサーバ/クライアント モデルを使用します。これによって、一貫性があり、セッションベースで HA 互換性のあるインフラストラクチャで、さまざまな出力モジュールをプログラムすることが確実になります。

第 2 に、EDC は新しい概念を使用して、オリジナルの出力 VLAN レプリケーション モデルを置き換えます。すべてのグループと出力対応モジュールに単一の内部 VLAN を使用する代わりに、EDC はグループ単位の Egress Distribution Table(EDT)モデルを使用します。

最後に、EDC は新しい方法で(新しい MFIB ハードウェア インフラストラクチャと協調して)実際のハードウェア OIF をプログラムします。これは Egress Distribution Index(EDI)とも呼ばれます。EDI 設計は、(LTL、RBH)ペアを組み合わせて一意の EDI を識別することで、個別のポート インデックス(LTL POE)および対応するファブリック インデックス(FPOE)の使用率を最適化します。

注: LTL は、Catalyst スイッチング プラットフォーム用に開発されたポートアドレッシング スキームです。詳細は、以降のセクションで取り上げます。

LTL POE ポート インデックスは、LTL と RBH を組み合わせて一意の EDI を特定することで、1 つで複数の EDI を表すことができます。また、ソフトウェア コンポーネント(LTL マネージャ)は、EDI プログラミングを保証するコンテキスト/セッションベースのコールバック機能を提供します。これは、プログラミング メッセージの消失によるパケット損失(たとえば、ブラック ホールなど)を防ぎます。

これらを組み合わせることで、新しい EDC サーバおよびクライアント設計によって、SSO のアクティブ スーパーバイザとスタンバイ スーパーバイザ間のハードウェア マルチキャスト インフラストラクチャを完全に同期することが可能になります。これは、HA に完全に準拠し、スイッチオーバー実行中のパケット損失を最小限に抑えます。

どのように役立つか

新しい EDC サーバ/クライアント設計(ユニファイド MFIB インフラストラクチャと組み合わせる)は、かつてないハードウェア マルチキャスト スケーラビリティを持った、高い信頼性と効率を誇る出力レプリケーション モデルを提供します。

IP ネットワーク管理者は、高いスケーラビリティのある IP マルチキャスト ネットワークを構築し管理できるようになります。

  • 単一の Catalyst 6500 システムで、500 を超えるポートに対して最高 256 K mroute(2 Tbps)の拡張に対応します。
  • 単一の VSS で、最高で 1,000 を超えるポートに対して 4 Tbps で対応します。
  • 6513-E および CEF2T モジュール搭載の場合、全 13 スロットで最高 60 Mpps の配信出力レプリケーションに対応します。

この EDC 設計は、また、マルチキャスト HA と完全互換性を持った、信頼できる(セッション志向の)出力レプリケーション モデルです。

図 11 EDC および MFIB インフラストラクチャ

図 11 EDC および MFIB インフラストラクチャ


新しい EDC 設計は、以前のシステム リソースを節約し、システム内の IP マルチキャスト データ トラフィックのフォワーディングを最適化します。これは、同時に、きわめて高速でスケーラブルなシステムを保証し、現在から将来にわたるマルチキャスト トラフィックの需要に備えています。

新しいマルチキャスト LTL および MET 共有設計
内部フォワーディング リソースを節約して、共用パスで使用されるようにします。

これまでの課題

ハードウェアベースの IP マルチキャスト フォワーディングには、次の 2 つの基本要件があります。

  1. すべての有効な宛先 OIF を定義する、ポートアドレッシング スキーム。
  2. OIF の関係する「グループ」に送信元フレームをレプリケートする方法。

第 1 に、すべてのハードウェアベース スイッチング プラットフォーム(シスコまたはその他)には、フォワーディング プロトコル(ソフトウェア)によってフレームを転送する適切なインターフェイス(またはポート)を判断するために、内部ポートアドレッシング スキームが必要です。

Catalyst 6500 モジュール ハードウェア プラットフォームにも同じことが言えます。Catalyst スイッチは、Local Target Logic(LTL)と呼ぶ内部アドレッシング スキームを使用しています。これは、システム内のすべてのポート(内部および外部)をマッピングしてから、利用可能な LTL アドレス空間を物理的な Port Of Exit(POE)インデックス、論理グループ インデックス、およびブロードキャスト フラッド インデックスに分割します。

スイッチ ファブリック ASIC の登場に伴い、各ファブリック チャネルは直接物理ポート セット(ラインカードのフロントパネル上にある)に接続されるようになりました。そのため、それぞれの独自ポート(または POE)インデックス用として、対応する、または補完的な Fabric Port Of Exit(または FPOE)インデックスも生まれました。

すべてのアドレッシング スキームと同様に、アドレス自体の長さと設計、および実際の検索および適切なアドレスの検出(テーブル内)に必要な全体の処理時間(遅延)は、慎重にバランスを取ることが大切です。

注: より規模の大きなアドレス スキームは、より独自性の高いノード(たとえば、IPv6 対 IPv4)の使用が可能になりますが、追加ビットをアドレス テーブル内で検出しようとすると時間が長くなります(たとえば、IPv4 アドレスは通常 IPv6 アドレスの 1/4 の処理時間で済みます)。

図 12 IPv4 アドレッシング スキーム

図 12 IPv4 アドレッシング スキーム
※画像をクリックすると、大きな画面で表示されますpopup_icon


Catalyst LTL アドレッシング スキームは、IOS ファームウェアによって定義されます(また、ブートアップ中に各モジュールにダウンロードされます)。前述のとおり、LTL スキームは、異なる用途に利用可能な一意のインデックスを定義する、さまざまな領域に分割されます。

物理ポート(POE)インデックスは、システム内のすべてのモジュールに静的に設定され、ユニキャストおよびマルチキャスト両方のパケット フォワーディングに使用されます。基本のパケット フラッディング(従来のスイッチング動作)と比較すると、どちらも特定ポートへのパケット送信が必要です。ブロードキャスト フォワーディングでは、VLAN 内のすべてのポートに適用される、シンプルなフラッディング インデックスが使用されます。

IP マルチキャストの場合、各 mroute OIF が 1 つまたはそれ以上の一意の POE/FPOE インデックスにマッピングされ、{MAC,VLAN} ペアとして保存されます。ここで、論理グループ インデックスが必要になります。

PFC3 アーキテクチャでは、マルチキャスト(グループ)LTL 領域が 32 K インデックスに設定されます。それぞれの IP マルチキャスト mroute には関連するグループ(またはリスト)LTL インデックスがあります。このインデックスの目的は、物理 POE インデックスのリストを保持することです。続いて、マルチキャスト スケーラビリティ数が 32 K に設定されます。

第 2 に、アドレッシングによって、マルチキャスト パケットを受信する必要があるインターフェイスが決定されます。これが確立されると、ユーザも各 OIF に必要なフレーム レプリケーションを実行する必要があります。これは、レプリケーション エンジン ASIC ハードウェアの特別なジョブです。この後 Multicast Expansion Table(MET; マルチキャスト拡張テーブル)を使用して、どの物理 POE インデックスのリストまたはグループが、各 IP mroute に関連付けされるかを追跡します。

IP マルチキャストの観点から、MET を使用して、ハードウェア レプリケーションに必要な OIF セットが定義されます。この OIF セットは、MET セットと呼ばれます。この MET セットは、それぞれが MET(インデックス)ポインタによって参照され、各マルチキャスト グループ エントリの物理ポート(または LTL POE)が含まれます。

ユニキャストベースのハードウェア フォワーディング同様に、CEF FIB 宛先ルックアップ プロセスから隣接インデックスが提供されます。その名のとおり、この隣接情報は、パケットが送信される実際のネクストホップを示します。

ユニキャストベースのフォワーディングとは異なり、隣接インデックス = LTL POE インデックスの場合、マルチキャストベースの隣接には MET へのポインタが含まれます。これは単純な追加ステップであり、レプリケーション エンジンと LTL POE のリストが提供されます。

図 13 Multicast Expansion Table

図 13 Multicast Expansion Table
※画像をクリックすると、大きな画面で表示されますpopup_icon


レプリケーション エンジン ASIC は、場合によってスーパーバイザ上(従来のバスベースの場合)か、直接スイッチング モジュール自体の上に存在します。より新しいファブリックベースのモジュールでは、以前分割された Fabric-Interface and Replication-Engine(FIRE; ファブリックインターフェイスおよびレプリケーションエンジン)ハードウェアが、単体の(FIRE)ASIC コンプレックスに組み合わされています。個々の FIRE ASIC には、それぞれ固有のハードウェア MET があります。

注: 組み合わされた FIRE ASIC ハードウェアにより、Catalyst 6500 の出力レプリケーション機能は実現しました。

PFC アーキテクチャでは、MET メモリ サイズは 64 K エントリに設定されています。動作されているマルチキャスト レプリケーション モード(入力または出力モード)に応じて、これが MET のプログラム方法を定義します。

入力レプリケーション モードでは、すべての MET が対称(たとえば、すべてのレプリケーション エンジンに、単体の LTL グループ インデックス セットが 1 つ)にプログラムされる必要があります。したがって、MET エントリの合計数(システム全体で)は 64 K になります。

出力レプリケーション モードでは、MET を非対称に(たとえば、レプリケーション エンジンがローカルと見なすポートに応じて異なる内容に)プログラムすることが可能です。したがって、MET エントリの合計数は、64 K にレプリケーション エンジンの数 N を掛けた値になります。

注: その後、これは入力レプリケーションのマルチキャスト スケーラビリティ数を 64 K に、または出力レプリケーションの場合は 64 K に レプリケーション エンジンの数を掛けた値に設定します。

これは良くないことなのでしょうか。大規模に拡張された環境では、その可能性があります。現在、使用できるマルチキャスト グループ エントリの合計数が 32 K と厳密に設定されているため、通常、一意のグループ LTL インデックスの数が主な制約要因となります。反対に、少数のグループ(および少数の LTL インデックス)のみを使用することもできますが、大量の OIF があるか、入力レプリケーション モードを使用している場合は、MET エントリが不足するおそれがあります。

したがって、現在の IP マルチキャスト ネットワークが比較的小規模から中規模であれば、問題が発生することはないと予想されます。ただし、ネットワークの規模が拡大されてこれらのハードウェア制限を上回ると、ソフトウェアまたはフラッドベースのフォワーディングが発生することがあります。

現在のソリューション

新しい Supervisor 2T および PFC/DFC4 を備えた新しい IOS コードは、これらの根本的に限られた内部リソースを共有するという概念を初めて導入しました。ほとんどの IP ネットワーク システムは分散型または集約型のポイントであるため、同じ IP マルチキャスト グループの多くが共有ネットワーク パス(たとえば、アップリンク、ダウンリンク、またはインタースイッチ リンク)を通過します。

こうしたケースでは、複数のハードウェア MFIB エントリがまったく同じ OIF を使用するため、同じ LTL および MET エントリを互いの間で使用、共有することが可能です。これによって、全体的な LTL および MET リソースの使用量を、その有限な(アドレスベースの)限界をはるかに上回って拡大することができ、システム全体もその制限を超えて拡張できるようになります。

図 14 LTL 共有

図 14 LTL 共有
※画像をクリックすると、大きな画面で表示されますpopup_icon


注: Supervisor 2T および PFC/DFC4 アーキテクチャは、最高 16 K の Broadcast Domain(BD; ブロードキャスト ドメイン)、および最高 16 K の物理ポートをサポートできます。このレベルの VLAN およびポート密度では、LTL 共有というアイデアによって、同じ LTL インデックスを 1 つ以上の L2 フォワーディング テーブル エントリで使用することが可能になります。

現在の設計では、IOS コードは異なる LTL インデックスを異なる(GMAC、BD)エントリに割り当てて使用します。現実的には、ある BD の受信者が同じグループ セットに参加するケースがあります。このようなケースの代表例としては、音声/ビデオ アプリケーションの使用時、音声およびビデオのストリームが 2 つの異なるマルチキャスト グループを経由してブロードキャストされる場合があります。このケースでは、同一の受信者ポート セットを持つ多様なマルチキャスト グループのさまざまな L2(GMAC、BD)エントリ間で、同じ LTL インデックスを共有することで、LTL インデックスの使用を最適化できます。

注: 共有エントリの概念は、PFC3 上の MET に初めて導入されました。ただし、共有は L3 ルーティング インターフェイスに限定されていたので(現在も限定されています)、SVI(または VLAN)エントリでは考慮されず、以前に言及されることもありませんでした。

理論上、まったく同じ OIF(たとえば、共有ネットワーク パス)のリストを持つ複数の IP マルチキャスト フローは、同一の MET セット/ポインタを共有できます。PFC/DFC4 では、VLAN および宛先 LTL POE フィールド(MET 内)を共に使用して隣接(または L2 書き換え)ポインタを表します。

PFC/DFC3 アーキテクチャの場合、(任意の MET セットの)VLAN および宛先 LTL POE インデックス フィールドには、レプリケートされたパケットの実際の VLAN および LTL インデックスが反映されます。言い換えると、パケットはレプリケーション前に完全に書き換えられており、レプリケーション後のパケットには発信情報がすべて含まれているということです。

PFC/DFC4 アーキテクチャでは、VLAN および宛先 LTL POE インデックス フィールドは、レプリケートされたパケットの実際の VLAN および LTL POE インデックスではありません。代わりに、これらを使用して、レプリケートされたパケットに付随する隣接ポインタを生成します。

これは、入力および出力処理を両方とも可能にするために必要となります(新しい EDC ベースの出力レプリケーション モデルの場合)。ただし、マルチキャスト フォワーディング(またはレプリケーション)がいかにローカルで重要であるかを裏付けるものでもあります。レプリケーションにより、LTL および MET マネージャ ソフトウェアは動的に、効率良くインデックスを割り当てることが可能になるためです。

注: PFC/DFC3 アーキテクチャでは、SVI インターフェイスを含む共有 MET セットに関する制限があります。OIF リスト内に SVI インターフェイスがある場合、MET セットは、同じ MAC マルチキャスト グループ アドレス(特に、MAC/IP マルチキャスト アドレスの最下位 23 ビット)を持つマルチキャスト フロー間でのみ共有できます。

現在(PFC/DFC4 アーキテクチャでは)、LIF および BD の概念が L2 VLAN と L3 VLAN インターフェイス(SVI)を切り離すものであるため、この制限は適用されません。同じ SVI OIF は、IP マルチキャスト フローが異なるとしても、正確に同じ隣接ポインタを持つ必要があります。したがって、L3 ルーティングと SVI OIF の両方を持つ MET セットは、同じ OIF リストを持つ異なるマルチキャスト フロー間で常に共有可能です。

図 15 MET 共有

図 15 MET 共有


どのように役立つか

新しい LTL および MET 共有設計(ユニファイド MFIB インフラストラクチャと組み合わせて)は、大容量の L2 および L3 IP マルチキャスト ネットワーク用に設計された、スケーラビリティの高いポート のインデックス作成およびマルチキャスト レプリケーション スキームを提供します。

IP ネットワーク管理者は、次のように高度なスケーラビリティを持つ IP マルチキャスト ネットワークを構築し管理できるようになります。

  • 単一の Catalyst 6500 システムで、500 を超えるポートに対して最高 256 K mroute(2 Tbps)の拡張に対応します。
  • 単一の VSS で、最高で 1,000 を超えるポートに対して 4 Tbps で対応します。
  • 6513-E および CEF2T モジュール搭載の場合、全 13 スロットで最高 60 Mpps の配信出力レプリケーションに対応します。

ソフトウェア LTL および MET マネージャは、EDC および MFIB コンポーネントと連携して、インデックス プログラミングの信頼性を高め、マルチキャスト HA のインデックスを同期します。

図 16 LTL、MET、および MFIB のインフラストラクチャ

図 16 LTL、MET、および MFIB のインフラストラクチャ


新しい LTL および MET 共有設計は、以前のシステム リソースを節約し、IP マルチキャスト データ トラフィックのフォワーディングを最適化します。これは、現在のマルチキャスト ネットワークの成長に備え、ハードウェアベースのマルチキャスト スケーラビリティをかつてないレベルでサポートします。

FIB-XL で最大 256 K のマルチキャスト ルーティング
これまでにないハードウェアベースのマルチキャスト スケーラビリティを提供します。

これまでの課題

マルチキャスト L2/L3 マルチレイヤ スイッチングは、プロセッサに負荷がかかるルータからのマルチキャスト フォワーディングおよびレプリケーションを軽減する、Application-Specific Integrated Circuit(ASIC; 特定用途向け集積回路)を使用して、IP マルチキャスト データ フローをインターフェイス間で転送します。

注: ハードウェアでスイッチングできない IP フローは、ソフトウェアによって転送されます。

Policy Feature Card(PFC; ポリシー フィーチャ カード)は、IP マルチキャスト フローの L2/L3 ハードウェア スイッチング(およびポリシー)を提供します。このハードウェアベースのスイッチングは、ハードウェア レプリケーション テーブル(MET)、Forwarding Information Base(FIB; 転送情報ベース)、および隣接関係テーブルの使用によって可能になります。Cisco Express Forwarding(CEF)アーキテクチャは、FIB および隣接関係テーブルの入力に使用されます。従来の Catalyst ベース ハードウェア スケーラビリティには、次の 2 つの 要素による制限があります。

  • IP マルチキャストの場合(IP ユニキャストおよび MPLS で共有)、FIB TCAM のサイズ(および割り当て)
  • 特別なソフトウェア フォワーディング インデックスの数(特に、物理ポート インデックスのリスト)
  1. マルチキャスト FIB の割り当て: PFC/DFC3 FIB サイズには、次の 2 つのバージョンがあります。
  • 非 XL ベース PFC = 合計 256 K エントリ(32 K は IP マルチキャスト用)
  • FIB-XL ベース PFC = 合計 1 M エントリ(32 K は IP マルチキャスト用)

Supervisor 720 および PFC/DFC3 の場合、マルチキャストのデフォルト割り当ては 32 K エントリで、最大 120 K エントリまで設定できます。

  1. ソフトウェア インデックスの数: すべての ASIC は一貫して(システム全体で)フレームの宛先を正確に把握している必要があるため、これは初期化で設定される、システム全体に共通する数です。

Catalyst シリーズは、既知のマッピング テーブル(LTL POE/FPOE)に基づいて、内部ポートインデックス作成スキームを使用します(すべてのハードウェアベース システムについて同じです)。このテーブルから、特別なソフトウェア(またはグループ)フォワーディング インデックス用に一部が予約されます。このインデックスは、物理ポート インデックスの単なるリストです。

マルチキャストおよびその他の機能は、これらの特別なソフトウェア(またはグループ)フォワーディング インデックスを使用して、すべての受信者(OIF)が実際にフレームを受信したことを確認します。したがって、これらの予約されたインデックスの数は固定され、スケーラビリティの制限となります。

Supervisor 720 および PFC/DFC3 では、静的割り当ては 32 K エントリです。したがって、IP マルチキャストの全体的なハードウェア制限は 32 K エントリに固定されています。

注: サポートされるソフトウェア マルチキャスト フローの数は、使用可能な CPU および DRAM によってのみ制限され、一般に毎秒 10 K パケットまで対応できます。

現在のソリューション

同じく次の 2 点のスケーラビリティに関する考慮事項が、Supervisor 2T にあてはまります。

  • IP マルチキャストの場合(ユニキャストおよび MPLS で共有)、FIB TCAM のサイズ(割り当て)
  • 特別なソフトウェア フォワーディング インデックスの数(特に、物理ポート インデックスのリスト)

Supervisor 2T および PFC/DFC4 の基本 FIB TCAM サイズは PFC/DFC3 と同じですが、デフォルト割り当ては異なり、より大きくなっています(さらに設定可能です)。

  1. マルチキャスト FIB の割り当て: PFC/DFC4 FIB サイズには、以下の 2 つのバージョンがあります。
  • 非 XL= 合計 256 K(128 K は IP マルチキャスト用)
  • FIB-XL = 合計 1 M(256 K は IP マルチキャスト用)

Supervisor 2T の場合、PFC/DFC4 のデフォルト割り当ては 128 K エントリで、PFC/DFC4-XL の最高割り当ては 256 K エントリです。

  1. ソフトウェア インデックスの数: 内部ポートインデックス作成スキーム(および IP マルチキャストの割り当て)も強化されています。さらに、一般に使用されるポート インデックスを共有する、新しい LTL 共有テクニックもあります。

Supervisor 2T および PFC/DFC4 の場合、ソフトウェア割り当ては 32 K エントリに LTL 共有をプラスした数で、最高は 256 K エントリです。

どのように役立つか

現在、次世代のハードウェアベース IP マルチキャスト マルチレイヤ スイッチング容量(システムあたり)を、FIB-XL(8 倍増)を使用して最高 256,000 mroute まで拡張できるようになりました。標準 FIB(4 倍増)を使用すると、128,000 mroute に拡張できます。

これは、ハードウェアベースの IP マルチキャスト フォワーディングではかつてない、また類のないスケーラビリティ(Sup 720 および PFC/DFC3 比では最高 8 倍増)です。

図 17 基本的な MFIB ルックアップ プロセス

図 17 基本的な MFIB ルックアップ プロセス
※画像をクリックすると、大きな画面で表示されますpopup_icon


また、これによって、現在および将来の IP マルチキャスト トラフィックの負荷をこのレベルで拡張するには欠かせない、システムの全体数または個別システムの数をまとめて縮小することができます。単体の Supervisor 2T は、Supervisor 720 の 8 倍まで処理できるので、それが可能になります。

さらに、Supervisor 2T を Virtual Switching System(VSS; 仮想スイッチング システム)モードで使用すると、この単体のコントロールプレーンおよびアクティブ/アクティブなデータプレーンは、最高 256 K の mroute を 1,100 の物理ポートを経由して、4 Tbps および 60 Mpps で提供できます。

ハードウェアの PIM-SM 送信元登録サポート
CPU およびメモリの使用を抑え、送信元の登録時間を短縮します。

これまでの課題

PIM-SM では、Rendezvous Point(RP; ランデブー ポイント)という概念が重要です。名前が示すとおり、その基本的な目的は、すべての PIM ルータに対して、事前調整したマルチキャスト ディストリビューションすべての集合場所を提供することです。

注: 「rendezvous(ランデブー)」という言葉は、フランス語の「rendez」と「vous」の短縮形で、「集まる」と「あなた」で一般に「待ち合わせ」を意味します。

PIM RP は、すべてのマルチキャスト トラフィック送信元(受信者との直接接続なし)と、関係するトラフィック受信者(送信元についての直接の知識なし)が集合する場所です。具体的に言うと、RP は、送信元と受信者の接続を行う、最初の PIM ディストリビューション ツリーが構築される方法のことです。

送信元 IP サブネットに直接接続される Designated Router(DR; 指定ルータ)のジョブは、新しい送信元がオンラインになり、マルチキャスト データのフォワーディングを開始したことを RP に通知することです。これは PIM-SM 送信元登録プロセスを通して実行されます。基本的な手順を以下にまとめました。

ステップ 1. DR(FHR)が送信元 IP を登録する

  • DR から PIM RP に PIM 登録メッセージ(すべての送信元とグループの)が送信されます
  • DR は登録をユニキャスト IP データとしてカプセル化し、直接 RP アドレスに送信します

ステップ 2. RP が登録を受信し、処理する

  • 登録メッセージは RP アドレスにユニキャストされるため、宛先は MSFC になります
  • PIM RP はすべての登録メッセージのカプセル化を解除します
  • CPU 使用率が高くなるおそれがあります(レートリミットが必要)

ステップ 3. RP から DR(FHR)に登録停止が送信される

  • RP は登録を処理し、PIM 登録停止メッセージを DR に戻します

これは標準の PIM-SM 動作(RFC-2362)であり、少数の IP mroute だけが使用される場合、送信元登録プロセスはまったく変更されません。PIM RP は、単純に送信元登録メッセージを処理し、登録停止を送信し、その後も動作を続けます。

これは良くないことなのでしょうか。答えは、「いいえ」です。ただし、大規模に拡張された環境では、その可能性があります。RP が数千または数十万の IP mroute の送信元登録を処理しなければならない場合、あるいは実際に処理する場合、MSFC を宛先とするそれらすべてのユニキャストベース IP フレームによって、CPU 使用率が高くなるおそれがあります。それに続いて、さまざまな不都合が発生する可能性があります。

注: CPU 使用率が高くなる問題は、指定されたデータ レートで意図的にフレームをドロップするソフトウェアまたはハードウェアのレート リミッタの使用で、効率的に軽減することが可能です。ただし、これによって送信元登録が失敗したり、遅れたりすることもあります。

現在のソリューション

新しい Supervisor 2T では現在、PIM-SM 送信元登録プロセス全体が、PFC/DFC4 ハードウェアで処理されます。ユニキャスト登録メッセージ(およびマルチキャスト データ)および登録停止メッセージのカプセル化およびカプセル化解除は、ハードウェアで処理されます。

注: この機能のソフトウェア面も、PIM-SM 送信元登録専用のカプセル化/カプセル化解除トンネル インターフェイスを採用した、ユニファイド IPv4/IPv6 MFIB インフラストラクチャに由来します。

FHR(DR)では、最初のマルチキャスト パケットは、mroute ステートを作成するためソフトウェアにリークされます。PIM カプセル化はハードウェア内の FHR で行われ、カプセル化されたパケットは直接 RP に送信されます。

RP では、最初のパケットもステート作成のためソフトウェアにリークされます。RP では、登録パケットはハードウェアでカプセル化が解除され、共有ツリーから受信者に渡されます。一部のパケットは、登録停止を送信するためルータにリークされます。

どのように役立つか

PIM-SM を使用する場合は、PIM 送信元登録の容量を計画する必要があります。これは特に、多くのマルチキャストの送信元が(ほぼ)同時にオンラインになったり、使用する PIM RP が 1 つのみ、またはネットワークの再コンバージェンス後の場合にあてはまります。

ソフトウェアの送信元登録も有効ですが、上手く拡張できません。

送信元登録をハードウェアで実行する方が、より迅速で予測可能です。

  • このハードウェア機能を持つことで、PIM-SM ネットワークに復元力と信頼性の高い送信元登録設定プロセスを提供します。
  • Catalyst 6500 MSFC CPU を過度の使用から保護し、限りある帯域内チャネル パケット処理リソースを節約します。
  • また、送信元登録に関連する遅延を短縮し、マルチキャスト パケットの転送に必要な全体の時間を短縮します。
図 18 送信元登録プロセス

図 18 送信元登録プロセス


まとめると、この新しいハードウェア機能は、CPU とメモリの使用量を大幅に削減し、同時に PIM 送信元登録プロセスの時間/遅延(および関連の警告)を短縮します。

ハードウェアの PIM-SM デュアル RPF サポート
CPU およびメモリの使用を抑え、SPT スイッチオーバー時間を短縮します。

これまでの課題

PIM-SM 送信元登録プロセスが完了すると、送信元の DR(つまりファーストホップ ルータ)と RP の間に送信元ベースのディストリビューション ツリー(S,G)が構築されます。これは IGMP/MLD 受信者まで延びて、マルチキャスト データを要請します。

直接接続されたインターフェイスからの IGMP/MLD 加入を受信した PIM mrouter は、受信 DR(つまりラストホップ ルータ)と見なされます。この DR は、IGMP または MLD 加入を PIM(*,G)加入に変換し、それらを PIM RP に送信します。

注: PIM および IP マルチキャスト ルーティングは、Reverse Path Forwarding(RPF; リバース パス転送)メカニズムを使用して、任意の IP アドレスへの最適なパス(またはメトリック)を持つインターフェイスを判断します。

PIM RP が(*,G)PIM 加入を受信すると、受信した場所からそのリンクに沿って、RP ベースのディストリビューション ツリーが構築されます。この方法では、マルチキャスト トラフィックには、中央のランデブー ポイントを通って送信元から受信者につながる完全なリンクがあります。

この RP ベース ディストリビューションは有効ですが、ネットワークによってはトラフィックに最適ではないパスを使用する場合があります(追加遅延、帯域幅の浪費などが生じます)。受信 DR に到達したトラフィックは、送信元 IP アドレスを決定し、最良の(つまり最適な)パスを判断できます。

受信 DR は RPF(IP ルーティング テーブルから生成)を使用して最良のパスを判断し、続いて送信元 DR へ向けて新しい(S,G)PIM 加入を送信します。(S,G)加入を受信した送信元 DR は、そのインターフェイスを OIF リストに追加できます。これで、トラフィックは最適なパスを通過できます。このプロセスを、Shortest Path Tree(SPT; 最短パス ツリー)スイッチオーバーと呼びます。

プロセスの基本的な手順を以下にまとめました。

ステップ 1. 送信元から DR(FHR)へマルチキャストが送信される

  • DR は PIM RP 付きで送信元とグループを登録します。
  • RP から FHR へ送信元の(S,G)加入が送信されます。
  • トラフィックは送信元から RP に流れます。

ステップ 2. 受信者から DR(LHR)へ加入が送信される

  • DR から RP へグループの(*,G)加入が送信されます。
  • トラフィックは送信元から RP、受信者へ流れます。

ステップ 3. DR(LHR)から DR(FHR)へ加入が送信される

  • DR は送信元 IP を学習して(S,G)加入を送信します。
  • トラフィックは送信元から受信者へ流れます。

これは標準の PIM-SM 動作(RFC-2362)です。少数の IP mroute だけが使用される場合、SPT プロセスはまったく変更されません。PIM DR および RP によって単純にすべての PIM 加入が処理され、SPT スイッチオーバーが実行され、このプロセスが継続されます。

これは良くないことなのでしょうか。「いいえ」と言って差し支えないものではありますが、大規模に拡張された環境では、その可能性があります。RP および DR が数千または数十万の IP mroute の SPT スイッチオーバーを実行しなければならない場合、MSFC を宛先とするそれらすべての RPF 計算および PIM 加入フレームによって、CPU 使用率が高くなるおそれがあります。それに続いて、さまざまな不都合が発生する可能性があります。

注: CPU 使用率が高くなる問題は、指定されたデータ レートで意図的にフレームをドロップするソフトウェアまたはハードウェアのレート リミッタの使用で、効率的に軽減することが可能です。ただし、これによって SPT スイッチオーバーが失敗したり、遅れたりすることもあります。

現在のソリューション

新しい Supervisor 2T には、PFC/DFC4 ハードウェアは任意の IP アドレスの、16 の異なる(等コスト)RPF エントリを処理する機能があります。

注: 16 パス RPF 機能は、ユニキャスト RPF および CEF ベース ECMP でも利用可能です。

IP マルチキャストの場合は、ハードウェアベースの Shortest Path Tree(SPT; 最短パス ツリー)スイッチオーバーに対してデュアル RPF のサポートが可能になります。最もシンプルな形では、送信元(IP)RPF は最初の RPF インターフェイスとしてプログラムされ、RP RPF は(S,G)エントリの 2 番目の RPF インターフェイスとしてプログラムされます。

送信元パケットが最初の RPF(送信元 RPF)インターフェイスから来る場合、パケットは転送され、MFSC にコピーされるため、SPT(T)ビットを設定し、SPT へのスイッチオーバーを実行できます。

パケットが 2 番目の RPF(RP RPF)インターフェイスから来る場合は、転送されるのみで MSFC にはコピーされません。

IP マルチキャストの場合、コードによってランデブー ポイントと送信元 IP アドレス情報の両方を同時に追跡できます。この新しい機能では、RPF 計算と SPT 処理をハードウェアで実行できるうえ、従来の PIM とマルチキャスト ルーティング処理(ソフトウェア)とステート管理を引き続き維持できます。

どのように役立つか

PIM-SM を使用すると、SPT スイッチオーバー容量の計画が必要になります。これは特に、多くのマルチキャスト受信者または送信元がオンラインになった場合、またはネットワークの再コンバージェンス後にあてはまります。

SPT スイッチオーバーのソフトウェア実行は有効ですが、上手く拡張できません。ハードウェアで SPT スイッチオーバーを実行する方が、より迅速で予測可能です。

  • この機能を持つことで、PIM-SM ネットワークに復元性と信頼性の高い SPT スイッチオーバー プロセスを提供します。
  • Catalyst 6500 MSFC CPU を過度の使用から保護し、帯域内チャネル パケット処理リソースを節約します。
  • SPT スイッチオーバーに関連する遅延を削減し、最適なパスを通過するパケットのフォワーディングに必要な時間を短縮します。
  • 同時に、RP および送信元のマルチキャスト トラフィックが送信される場合、SPT スイッチオーバー中に発生するおそれのある、パケットの重複または損失を削減します。
図 19 基本的な RPF ルックアップ

図 19 基本的な RPF ルックアップ


まとめると、この新しいハードウェア機能は、CPU とメモリの使用量を大幅に削減し、同時に PIM SPT スイッチオーバーにかかる時間(および関連の警告)を短縮します。

簡素化されたグローバル L2 IGMP スヌーピング設計
簡素化された L2 スヌーピング構成およびクエリア冗長構成を提供します。

これまでの課題

MMLS と同じく、オリジナルのレイヤ 2 IGMP スヌーピング コードは、それが他のシスコ スイッチング プラットフォームに実装される前は、Catalyst 6500 専用として開発されました。本来の設計は、既存の L3 IGMP プロセスを補完し、L2 IP マルチキャストのみを処理する特別な環境に向けたものでした。

PFC/DFC3 およびそれ以前の IOS リリースでは、Catalyst 6500 IGMP スヌーピング設計は、2 つの大きな課題に直面しました。

  1. IGMP スヌーピング(処理)は、「IP マルチキャスト ルーティング」が設定されている場合、デフォルトで有効です。ただし、デフォルト以外の設定(たとえば、IGMP スヌーピング クエリア機能)はすべて、関連する SVI(または VLAN インターフェイス)上に存在する必要があります。
  2. IGMP スヌーピング クエリアは、クエリア選出をサポートしていないため、冗長性にも対応していません。別の IGMP クエリアが存在する場合(たとえば L3 mrouter)、スヌーピング クエリアは見送られ、再開されるまで指定のタイムアウトを待機します。

上級者向けヒント:IGMP スヌーピング(Sup 720 および 12.2SX IOS)の詳細については、
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/snooigmp.html [英語] を参照してください。

SVI ベース IGMP スヌーピング構成

前述のとおり(および MMLS 同様)、この設計は標準(プラットフォーム非依存)設計の決定、開発よりも前に開発されました。

この設計には、純粋な L2 機能を(それ以外の場合不要な)L3 インターフェイスに関連付けるため、直接 VLAN(または SVI)インターフェイスに適用される IGMP スヌーピング構成が必要です。これは、クエリア メッセージに IP アドレスを使用することで実行されます。

その上、L3 機能(たとえば、IP マルチキャスト ルーティング)を使用する意図がない場合でも、現在の構成モデルでは、ユーザが IP アドレス(IGMP クエリで使用したもの)を指定する必要があり、SVI をシャットダウンできます。

これは良くないことなのでしょうか。答えは、「いいえ」です。技術的な問題はありません。唯一の課題は、他のシスコ スイッチング プラットフォームの一部と互換性がないことです。

IGMP スヌーピング クエリア選出なし

前述のとおり(および MMLS 同様)、この設計は標準(プラットフォーム非依存)設計の決定、開発よりも前に開発されました。

純粋な L2 IGMP スヌーピング クエリア機能の目的(意図)は、L3 IGMP クエリア機能を模倣することであるため、本来の設計は、L3 IGMP クエリアを補完(かつ従属)することでした。

注: レイヤ 2 IGMP スヌーピング クエリア機能は、(RFC- 2236)L3 IGMP クエリアと混同しないよう注意が必要です。後者は L3 PIM インターフェイス上で自動的に有効化されます。レイヤ 3 実装では、クエリア選出はサポートされません。これは、L3 IGMP クエリア(具体的には PIM インターフェイス)がない(ゼロの)純粋な L2 マルチキャスト環境が存在する場合の導入を意味しており、(RFC の観点からは)特殊なケースと見なされていました。

結果として、同じレイヤ 2 サブネット上で別の IGMP クエリアが有効な場合、意図的にその機能を停止する(かつ再開するまでタイムアウト期間を待機する)設計になりました。また、特殊なケースであるため、(その時点では)クエリア選出に要件はありませんでした。

6504E.S720.SA.2(config)# interface vlan 1001
6504E.S720.SA.2(config-if)# ip address 101.2.1.254 255.255.255.0
6504E.S720.SA.2(config-if)# igmp snooping querier
6504E.S720.SA.2(config-if)# shutdown

これは良くないことなのでしょうか。一般的に言えば、答えは「いいえ」です。同じ IP サブネット内に複数の L3 PIM インターフェイスが存在する場合、それらは自動的に L3 IGMP クエリア機能と選出を有効にし、IGMP クエリア機能を前提とします。

レイヤ 3 IGMP クエリアの 1 つが失敗すると、選出プロセスによって別のレイヤ 3 クエリアが処理を引き継ぎます。それまでの間、構成された L2 IGMP スヌーピング クエリアはすべてサイレントのままになります。すべてのレイヤ 3 クエリアが失敗した場合、タイムアウト期間後に L2 スヌーピング クエリアがその処理を引き継ぎます。

L2 IGMP スヌーピング クエリア タイムアウト期間は、3 × GQ + 処理時間(5 分以下)となります。最後のクエリが特定の IP サブネット上に送信された時間に応じて、この結果は、1 秒(最小)から 5 分(最大)の一時的なパケット損失につながるおそれがあります。注意:この制限は、DDTS レポート CSCsk48795 で追跡されています。

また、レイヤ 3 PIM/IGMP インターフェイスがゼロの純粋な L2 マルチキャスト環境では、特殊なケースのシナリオがあります。冗長性がサポートされていないため、L2 IGMP スヌーピング クエリアが失敗すると、クエリア機能が回復するまでは、サブネット上のパケット損失(PIM GQ タイムアウト後)という結果になります。

現在のソリューション

新しい Supervisor 2T および 12.2(50)SY(およびそれ以降の)IOS コードを備えた Catalyst 6500 は、標準化されたグローバル IGMP スヌーピング モデルを実装し、他のシスコ スイッチング プラットフォームと互換性があります。

第 1 に、その名前が示すとおり、新しいモデルでは SVI ベース構成を使用しません。IGMP スヌーピング構成は、グローバル構成レベルの各 VLAN に適用されるようになりました。これにより、純粋な L2 構成がその他の L3 固有 VLAN インターフェイス(SVI)から論理的に切り離されます。

新しいグローバル IGMP スヌーピング構成の例を以下に示します。

6513E.SUP2T.SA.1(config)#vlan config 148
6513E.SUP2T.SA.1(config-vlan-config)#ip igmp snooping

第 2 に、新しいグローバル モデルも IGMP スヌーピング クエリア選出をサポートしています(RFC-2236 に準拠するため)。これによって、純粋な L2 IP マルチキャスト環境(IGMP ルータが存在しない)内のクエリア冗長性が可能になります。新しい IGMP スヌーピング クエリア構成の例を以下に示します。

6513E.SUP2T.SA.1(config)#ip igmp snoop querier
6513E.SUP2T.SA.1(config)#ip igmp snoop querier address 3.3.3.3

どのように役立つか

新しいグローバル IGMP スヌーピング モデルには、主に以下の 3 つの利点があります。

  • L2 IGMP スヌーピング構成を L3 VLAN インターフェイスから切り離します。
  • 純粋な L2 IP マルチキャスト環境での冗長性のため、IGMP スヌーピング クエリア選出が提供されます。
  • 他のシスコ スイッチング プラットフォームと同じ IGMP スヌーピング構成モデルが導入されます。
図 20 IGMP スヌーピング クエリア選出

図 20 IGMP スヌーピング クエリア選出


第 1 の利点は、L2 機能(具体的には、単一の IP サブネット上のスイッチングまたはブリッジング)と、L3 機能(具体的には、IP サブネット間のルーティング)を簡単に区別できる点です。これにより、個々の機能(同じ Catalyst 6500 上で異なる目的のために合わせて構成されることがあります)の全体的な構成とモニタリングに関して、理解と運用が容易になります。

第 2 の利点は、純粋な L2 サブネット内の IGMP クエリア冗長性が可能になる点です。これは、データ センターのアクセス環境および分散環境内では一般的ですが、L2 ベースのコア ネットワーク内でも同様です。別の例として、ファイアウォールで区切られた L2 環境が挙げられます。ここでは、L3 IGMP スヌーピング クエリア機能はサポートされていません(したがって、L2 IGMP スヌーピング クエリアが必要となります)。

これらを組み合わせることで、新しいグローバル IGMP スヌーピング モデルは、より直感的でシンプルかつ冗長性があり、他のシスコ スイッチング プラットフォームとの互換性を持つネットワーク設計を提供します。L2 IP マルチキャスト環境の全体の設定とメンテナンスがより簡単になり、信頼性を高めることができます。

IP ベース(非 DMAC ベース)の L2 フォワーディング ルックアップ
L2 マルチキャストに備えて IP-to-MAC アドレス オーバーラップを削除します。

これまでの課題

OSI モデルでレイヤ 2(L2)と言えば、文字どおり「データ リンク」または「ネットワーク インターフェイス」(たとえば NIC)レイヤを常に意味します。このレイヤは、単一の LAN 内の単一エンティティに関連する明確な MAC アドレスに依存します。これは、多くはブロードキャスト ドメインと呼ばれます。

上級者向けヒント:OSI モデルの L2 の詳細については、http://en.wikipedia.org/wiki/Data_Link_Layer [英語] を参照してください。

OSI モデルのレイヤ 3(L3)と同様に、この MAC ベース アドレスは、ユニキャスト/マルチキャスト フォワーディング モデルの概念と合わせて、またはそれなしで適用されます(ブロードキャストは L2 環境を前提とします)。一意のアドレスは、フレームの宛先を判断するためだけに必要です。

IP マルチキャストの場合は、特別な宛先アドレスを使用して、一意の宛先アドレスのセットまたはリストを表します。L3 の場合は、宛先(またはグループ)IP アドレスを使用します。L2 は、宛先 MAC アドレスになります。

ただし、IP アドレスは正確に 32 ビット(IPv4)または 128 ビット(IPv6)であり、一方で MAC アドレスは 48 ビットです。48 ビットの MAC アドレスのうち、24 ビットは Organizational Unit Identifier(OUI)またはベンダー ID に、残りの 24 ビットは一意の ID のために予約されます。

ここに、新しい課題があります。L3 マルチキャスト IP アドレスと L2 マルチキャスト MAC アドレスの間で変換を行うには、IP アドレス(L3)の下位 23 ビットを、MAC アドレス(L2)の下位 23 ビットにマッピングします。残りのビットは不明確で、オーバーラップします。

注: IPv4 の場合、L3 IP アドレスの上位 4 ビットは「1110」に固定され、「224.0.0.0」と「239.255.255.255」の間の「クラス D」マルチキャスト アドレス空間を示します。「01:00:5E」で始まる特殊な OUI マルチキャスト MAC アドレスは、「01:00:5E:00:00:00」から「01:00:5E:7F:FF:FF」の範囲を指定できます。

図 21 IPv4 から MAC のアドレス マッピング

図 21 IPv4 から MAC のアドレス マッピング


PFC/DFC3 アーキテクチャでは、IGMP/MLD スヌーピング プロセスによって、宛先グループ MAC アドレス(または DMAC)に基づいて L2 マルチキャスト転送テーブルが入力されます。したがって、2 つの個別(ゆえにそれぞれが一意の)レイヤ 3 IP マルチキャスト グループが同じ L2 MAC アドレス(たとえば、224.1.1.1 and 239.1.1.1 = 01:00:5E:01:01:01)を共有する場合、IGMP/MLD スヌーピングは同じように扱われます。

注: IPv6 の場合、マルチキャストの新しい OUI 形式があります。先頭の 2 バイトは 33:33 に設定され、続く 4 バイト/32 ビットは、128 ビット マルチキャスト アドレスの末尾 32 ビットからのアドレス マッピングに使用できます(たとえば、33:33:XX:XX:XX:XX、ここで X はアドレスの末尾 32 ビット)。

図 22 IPv6 から MAC のアドレス マッピング

図 22 IPv6 から MAC のアドレス マッピング


すべてのハードウェアベース L2 フォワーディング決定は IGMP/MLD スヌーピング テーブルに依存しており、同じ MAC アドレスが(L2 スイッチング テーブル内で)使用されているため。このアドレスのオーバーラップによって、無関係なホストへの不要なフォワーディング(同じブロードキャスト ドメイン内で)が実行されます。

上級者向けヒント:L2 マルチキャスト アドレスの詳細については、
http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a00800b0871.shtml#multi [英語] を参照してください。

これは良くないことなのでしょうか。答えは状況に応じて異なります。IP と MAC アドレスのオーバーラップが存在しない場合は問題ありません。一定のマルチキャスト アドレス(たとえば、224.0.0.X と 239.0.0.X)を慎重に避ければ、オーバーラップは発生しません。さらに、唯一の問題は、不要なマルチキャスト パケット フォワーディングが無関係なホストに対して行われることです。

ただし、アドレスが著しくオーバーラップする環境にあるか、マルチキャスト フローのオーバーラップがすべて高いレート(ビデオなど)の場合、不要な L2 フォワーディングによって、利用可能なネットワーク帯域幅がすべて消費されるおそれがあります。

現在のソリューション

新しい Supervisor 2T および PFC/DFC4 では、基本の L2 フォワーディング ルックアップは、現在 IP ベースまたは DMAC ベースのいずれかで、デフォルトは IP ベースになっています。グループ IP ベースの L2 ルックアップでは、IP:MAC のアドレス オーバーラップ問題は排除することができます。

各 Bridge Domain(BD; ブリッジ ドメイン)の L2 マルチキャスト ルックアップ モードは、ユーザが設定できます。下位互換性を維持するには(たとえば、ユーザの保存環境に静的マルチキャスト MAC アドレスがある場合)、ルックアップ モードをグループ MAC アドレス ベースに変更できます。

注: いずれのルックアップ モードでも、PFC/DFC4 は任意のマルチキャスト パケット内の MAC アドレスと IP アドレスのチェックを一貫してサポートし、L3 または L2 テーブルの矛盾を防ぎます。L2 フォワーディング テーブル内の特殊な IP ベース MAC エントリを使用してこれを行います。

これが、アドレス オーバーラップを発生させるプリセット(24 ビット)OUI であることを思い出してください。これは、フレームが IP マルチキャストとなる一意の ID に対して行われます。ただし、異なる OUI(フレームを IP マルチキャストとして一意に特定し、IP アドレス情報を含む)を使用する場合は、アドレス オーバーラップを解消できます。PFC/DFC4 は、この特別な OUI をサポートした最初のフォワーディングエンジンであり、したがって、IP ベース L2 ルックアップのサポートも最初です。

この新しい OUI フィールドには、過去に失われた 20 ビット分の IP アドレス、LIF および BD、IP バージョンなどのその他の情報が含まれます。これらの値は併せて保存され、IGMP スヌーピングを使用して L2 フォワーディング テーブルを構築できるフロー単位で一意の OUI を提供します。

図 23 PIM-SM IP ベース L2 DMAC エントリ

図 23 PIM-SM IP ベース L2 DMAC エントリ
※画像をクリックすると、大きな画面で表示されますpopup_icon


残り(つまり下位)23 ビットは前と変わらず、新しい OUI フィールドが唯一の違いです。これは、同じ L2 フォワーディング テーブル形式を使用した下位互換性(具体的には DMAC ベース)を可能にするものです。

それ以外(新しいデフォルト IP ベース設計を使用した場合)は、L2 フォワーディング テーブル内の各 L2 マルチキャスト エントリは現在完全に一意であるため、アドレス オーバーラップは発生しません。

どのように役立つか

新しい IP ベース L2 フォワーディング ルックアップ機能は、それまでの IP:MAC(または L3:L2)アドレス オーバーラップ問題を排除しました。

この機能は、ネットワークの設計と管理を大幅に簡素化し、より一貫性があり柔軟なネットワークを実現します。また、以前は使用できなかったより多くの IP マルチキャスト グループ アドレスを提供し、スケーラビリティを大幅に拡大します。

ハードウェアの IGMPv3 および MLDv2 スヌーピング
IPv4/IPv6 PIM-SSM L2 ホスト テーブル更新を高速化します。

これまでの課題

IGMPv3(RFC-3376)および MLDv2(RFC-3810)は、IGMP(IPv4)および MLD(IPv6)ホスト シグナリング プロトコルの最新バージョンです。これらは、ホスト(具体的には、受信者)によるトラフィックから受信する特定送信元リストの定義を可能にします。

低遅延(S,G)の送信元ベース フォワーディングの操作には、IGMPv3 および MLDv2 サポートが必要です。これは、PIM RP に依存しない PIM Source-Specific Multicast(SSM)mroute に基づきます。

図 24 SSM および IGMPv3(S,G)の動作

図 24 SSM および IGMPv3(S,G)の動作


これが可能なのは、ホストの加入/脱退メッセージが、目的の送信元 IP アドレス(INCLUDE)を明示的に表示し、ネットワークによる不要な送信元からのマルチキャスト パケットのドロップ(EXCLUDE)を有効化しているためです。

上級者向けヒント:PIM-SSM の詳細については、
http://www.cisco.com/en/US/partner/docs/ios/12_2/ip/configuration/guide/1cfssm.html [英語] を参照してください。

PFC/DFC3 およびそれ以前のフォワーディング エンジンがハードウェアでサポートしていたのは、IGMPv1/2 および MLDv1 スヌーピングのみでした。これは、L2 スヌーピング テーブルが(DMAC, VLAN)に基づいており、送信元固有の情報がないためです。

IGMPv3 および MLDv2(S,G)スヌーピングを可能にするには、ハイブリッドなアプローチを使用していました。具体的には、既存のハードウェアベースの IGMPv1/2 および MLDv1(*,G)スヌーピング機能を、新しいソフトウェアベースの送信元 IP トラッキング テーブルと組み合わせるという手法です。

注: PFC/DFC3 用のデフォルト(L3)IGMP インターフェイス モードは IGMPv2(デフォルト バージョン)です。ユーザは、ip igmp version 3 インターフェイス コマンドを使用して、意図的に IGMPv3 サポートを有効にする必要があります。

IGMPv3 スヌーピングを有効にすると、ソフトウェアが特定のグループについて、特定の VLAN で受信したメッセージに基づいて、IGMPv3 ステートが維持され、既存のハードウェアを使用して情報が保存されます。

上級者向けヒント:PFC/DFC3 ベース IGMPv3 スヌーピングの詳細については、
http://www.cisco.com/en/US/partner/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/
guide/snooigmp.html#wp1100551
[英語] を参照してください。

これは良くないことなのでしょうか。一般的に言えば、答えは「いいえ」です。このハイブリッド アプローチは上手く動作し、小規模から中規模の PIM-SSM 環境では、追加の処理遅延と負荷(CPU 使用率)は最小化されます。

その上、IGMP および MLD ホスト レポートは正常時の頻度が低く、これらがネットワークエッジ(またはサブネット)テクノロジーであるため、単一の IP マルチキャスト システムでは、任意の時点において、通常はそれほど多くの IGMPv3/MLDv2 レポートを処理する必要はありません。

ただし、大規模な L2 環境では、または単一システムで大量の IGMPv3/MLDv2 レポートを処理しなければならない場合は、CPU 使用負荷の増大による加入/脱退遅延の増加がホストで発生することがあります。

PIM-SSM および IGMPv3/MLDv2 は、IP マルチキャストの最短パス、低遅延のソリューションを提供することを目的としています。したがって、不要な(下手をすると、負荷のばらつきのせいで予測不可能な)遅延は逆効果と見なされます。

現在のソリューション

新しい Supervisor 2T および PFC/DFC4 では、システムは送信元固有の IP 情報をハードウェア内に保存し、トラッキングできるようになりました。これは実際のところ、新しい IP ベース L2 フォワーディング ルックアップ設計の別の機能です。

以下の図では、ホスト H1 はチャネル(S1,G)に加入し、ホスト H2 および H3 はチャネル(S2,G)に加入しています。フォワーディング エンジンは、受信するマルチキャスト フレームごとにその送信元 IP アドレスとグループ IP アドレスを検証し、パケットを転送するポート セット(LTL インデックスによって表される)を判断します。

図 25 SSM および IGMPv3 L2 の動作

図 25 SSM および IGMPv3 L2 の動作


IGMPv3 の場合、PFC/DFC4 は、グループおよび送信元 IP アドレス両方のルックアップを、1 つは L3 処理前、もう 1 つは L3 処理後の 2 ステップで、より長い時間実行します。このため、2 つの L2 エントリがインストールされます。

L3 前エントリは、IGMPv1/v2 グループ IP ベース エントリと同じです(前述のとおり)。L3 後エントリのキーは、送信元 IP アドレスでエンコードされ、L3 前エントリのアドレスも同様です(同じ送信元 IP アドレスの他エントリとの衝突を避けるため)。

たとえば、PIM-SSM グループ アドレスを 232.1.1.1、送信元アドレスを 192.168.10.10 とします。L2 フォワーディング テーブルには 2 つの個別のエントリがインストールされます。

図 26 SSM および IGMPv3 用 IP ベース L2 エントリ

図 26 SSM および IGMPv3 用 IP ベース L2 エントリ
※画像をクリックすると、大きな画面で表示されますpopup_icon


現在、(IP ベースと DMAC ベースの L2 フォワーディングを比較したセクションで説明したとおり)、同じグループ IP アドレスを持つが、送信元 IP アドレスは異なるすべての L2 エントリは、同じ L3 前ルックアップ エントリを共有できます。

たとえば、2 チャネル(192.168.10.10、232.1.1.1)および(172.16.1.1、232.1.1.1)の場合、L2 フォワーディング エントリが 3 つになります。

図 27 SSM グループ IP が同じで送信元 IP が異なる L2 エントリ

図 27 SSM グループ IP が同じで送信元 IP が異なる L2 エントリ
※画像をクリックすると、大きな画面で表示されますpopup_icon


また、IGMPv3 では、ホストから、送信元フィルタリングを指定して加入を送信できます。フィルタリングは、送信元に含めるリストまたは除外するリストを指定することで行います。以下は、3 つのホストが、異なる送信元フィルタリング リストを持つグループ 232.1.1.1 に加入する場合の例です。

  • Host1 は、192.168.10.10 からのグループ トラフィックのみを受信します。
    • INC(Host1)={192.168.10.10}.
  • Host2 は、すべての送信元からのグループ トラフィックを受信します。
    • EXC(Host2)={}.
  • Host3 は、192.168.10.10 および 172.16.1.1 以外のすべての送信元から受信します。
    • EXC(Host3)={192.168.10.10, 172.16.1.1}

この場合、同じ 3 つの L2 エントリ(上記を参照)は、(192.168.10.10、232.1.1.1)、(172.16.1.1、232.1.1.1)、および(*、232.1.1.1)の各チャネルに必要です。上記の 3 ホストのレポートに従って、各チャネルの受信者リストは次のようにリストされます。

  • OIF_LIST(192.168.10.10, 232.1.1.1) = {Host1, Host2}
  • OIF_LIST(172.16.1.1, 232.1.1.1) = {Host2}
  • OIF_LIST(*, 232.1.1.1) = {Host2, Host3}

そのため、新しい IP ベース L2 フォワーディング ルックアップ設計は、送信元 IP アドレス情報を保存し追加する機能と組み合わせることで、PFC/DFC4 によるフル IGMPv3/MLDv2 スヌーピング処理をハードウェアで実行できるようになります。

どのように役立つか

新しい Supervisor 2T および PFC/DFC4 のハードウェアベース処理による IGMPv3 および MLDv2 スヌーピングのサポートは、PIM-SSM マルチキャスト ルートのより高速で信頼性の高い更新を可能にし、一貫した低遅延ソリューションを実現しました。

また、この新しい設計は、ホスト固有の加入および脱退遅延を軽減し、L2 の動作を PIM Source Specific Multicast(SSM)の予測と一致させます。

IGMPv3 および MLDv2 には、独自の複雑な処理要件(INCLUDE および EXCLUDE フィルタリング)が数多くあり、Catalyst 6500 および Supervisor 2T ハードウェアのみがそれらの要件を満たすことができます。つまり、シスコはもとより、シスコ以外の IGMPv3 および MLDv2 設計を含め、すべての旧世代を凌ぐ大幅なパフォーマンス強化が L2 環境内で実現したといえます。

新しい Optimized Multicast Flooding(OMF)設計
「source-only」VLAN のためにフォワーディング リソースおよび帯域幅を節約します。

これまでの課題

直接接続された送信元ホストから IP マルチキャスト トラフィックを受信すると、入力ブリッジドメイン(VLAN)から学習する IGMP/MLD 受信者がない場合(または、初回設定の間などは必ず)、L2 フォワーディング ルックアップは失敗します。これは、L2 マルチキャスト スヌーピング プロセスが、L2 フォワーディング テーブルの入力を行う必要があるためです。

そのため、この L2 ルックアップの失敗は、不要なマルチキャスト フレームの、同じ(入力)ブリッジドメインの一部であるすべてのポートへのフラッディングにつながるおそれがあります。このタイプのマルチキャスト ネットワーク設計(特に、送信元が 1 つまたは複数で受信者がゼロの場合)で、結果としてフラッディング動作を起こすものは、source-only フォワーディングと呼ばれることもあります。

すべてのブリッジドメイン メンバー ポートにフラッディングする代わりに、このタイプの source-only マルチキャスト トラフィックは、L3 マルチキャスト ルータ ポート(リモート受信者にルーティングする)のみに制限する必要があります。

PFC/DFC3 およびそれ以前のフォワーディング エンジンは、トラフィックを定期的にソフトウェアにリークすることで、source-only フォワーディングを支援していました。これによって、IOS ソフトウェア プログラムに対して L2 テーブルに特別なグループ DMAC エントリを提供し、マルチキャスト ルータ ポートを受信ポートとして提供します。

この設計は上手く動作しますが、主な課題として以下の 2 つがあります。

  • mroute 1 つあたりに L2 「source-only」グループ DMAC エントリが 1 つ(1:1)
  • source-only のエージング(タイマー有効期限)および再学習による、定期的な L2 フラッディング

第 1 の課題は、L2 マルチキャスト スケーラビリティに関連しています。マルチキャスト ルートはそれぞれ個別の L2 フォワーディング テーブル エントリが必要なため、集約エントリの数は L2 フォワーディング テーブル サイズの大部分を消費する可能性があります。

第 2 の課題は、定期的なネットワーク帯域幅の浪費を引き起こし、フレームが明示的にデータを要求していないホストに対してもフラッディングされます(IP マルチキャストの目的とは逆)。

上級者向けヒント:PFC/DFC3 ベースの「source-only」エントリの詳細については、
http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a00800b0871.shtml#src_only [英語] を参照してください。

これは良くないことなのでしょうか。一般的に言えば、答えは「いいえ」です。多くの場合と同様、ネットワークの規模に応じて異なります。

エージング時間が長く設定されているか、source-only のレート制限が無効な場合、L2 フォワーディング テーブルには、source-only 処理の使用、または IGMP 加入メッセージの使用によって学習されるスイッチの未使用(古い)エントリが入力されます。

L2 フォワーディング テーブルが一杯の場合、スイッチは新しい IP マルチキャスト グループのトラフィックを受信し、パケットを同じ VLAN 内のすべてのポートにフラッディングします。この不要なフラッディングは、スイッチのパフォーマンスに影響するおそれがあります。

また、L2 DMAC ベースの source-only エントリが削除される期間(デフォルトは 5 分おき)があります。この間に、トラフィックがマルチキャスト ルータ ポートにフラッディングされます。この定期的なフラッディングは、source-only エントリが再プログラムされると止まります。

現在のソリューション

新しい Supervisor 2T および PFC/DFC4 を備えた新しい IOS コードは、Optimized Multicast Flooding(OMF)設計を採用しています。OMF は、すべてのグループへの source-only フォワーディングに対して、ブリッジドメイン(*, BD)あたりで、1 つは IPv4 トラフィック用、もう 1 つは IPv6 トラフィック用の 2 つの L2 エントリのみを必要とする、より効率的なアプローチを提供します。

Mroute あたり(VLAN あたり)1 つの L2 エントリを使用する場合と比べると、これは、L2 フォワーディング テーブルの空間を節約し、(PFC/DFC3 およびそれ以前のように、ソフトウェアに L2 エントリがインストールされる前のような)一時的なフラッディングを防ぐことができます。

注: スヌーピングが有効な限り、Optimized Multicast Flooding(OMF)も有効です。

これで(新しい IP ベース L2 フォワーディング ルックアップ プロセスと組み合わせて)、送信元 IP ホストから受信者がゼロのブリッジドメイン(FIB 損失につながる)にマルチキャスト トラフィックが送信されると、フォワーディングエンジンからは毎回 OMF インデックスが返されます。

IPv4 OMF エントリの LTL インデックス結果には、IGMP スヌーピングで検出されたマルチキャスト ルータ ポートのリストのみが含まれます。同様に、MLD スヌーピングが有効な場合、IPv6 OMF エントリは L2 フォワーディング テーブルに挿入されます。

6513E.SUP2T.SA.1#show mac address-table multicast vlan 148
 vlan    mac/ip address                          LTL           ports
+----+-----------------------------------------+------+----------------------
  148  ( *,239.1.124.1)                         0x912  Router Gi1/48 
  148  IPv4 OMF                                 0x910  Router 

6513E.SUP2T.SA.1#

どのように役立つか

新しい L2 固有の Optimized Multicast Flooding(OMF)source-only 設計は、主に以下の 2 つの機能が強化されています。

  • 必要な(IPv4/IPv6)OMF source-only エントリは 1 つのみ(ブリッジドメインあたり)なので、L2 フォワーディング テーブル エントリの合計数が劇的に削減されます。
  • 特別なハードウェアおよびソフトウェアのインタラクションは必要ないため(source-only の定期的な学習の場合)、ローカルに受信者がない、ブリッジ ドメインでの不要なマルチキャスト フラッディングが排除されます。
図 28 基本的な source-only プロセス

図 28 基本的な source-only プロセス
※画像をクリックすると、大きな画面で表示されますpopup_icon


貴重な L2 フォワーディング リソースを保護して、マルチキャスト スケーラビリティの大幅な拡大を可能にします。同時に、増大した使用負荷またはその他の関連する問題から、マルチキャスト コントロールプレーンを保護します。

マルチキャスト VPN(MVPN)出力レプリケーション サポート
MVPN/eMVPN フォワーディング時のスイッチ ファブリック帯域幅全体を節約します。

これまでの課題

仮想化された MPLS ベースの IP ネットワーキングの普及に伴い、ユーザが VPN 内のマルチキャスト データ トラフィックを伝送することが増えています。

本来の実装では、ユニキャスト(ポイントツーポイント)の GRE IP トンネルを経由したマルチキャストを使用していました。ただしリモート ロケーション間のフルメッシュ設計が必要なため、拡張性に問題がありました。また、IP マルチキャスト、具体的にはディストリビューション ツリーの目的に対して、直感的に相容れないものがありました。

図 29 P2P トンネルの拡張性の問題

図 29 P2P トンネルの拡張性の問題


仮想化された IP ネットワーキングのすべての利点と、マルチキャスト フォワーディングの基本原則を組み合わせた、新しいマルチキャスト固有の VPN ソリューションが必要です。

求められるのは、既存の VPN テクノロジーを使用しながら、受信者主導型のマルチキャスト ディストリビューション ツリーも構築する、革新的なフォワーディング インフラストラクチャです。この新しいテクノロジーは、Multicast VPN(MVPN)として知られるようになりました。

MVPN イントラネットのサポートは、PFC/DFC3B で導入されました。これは、同じ(独立した)Virtual Routing and Forwarding(VRF; 仮想ルーティングおよび転送)VPN 内にあるリモート ロケーション間に、PIM ベースのマルチキャスト ルーティング トポロジを構築する方法を提供します。

MVPN は、Multicast Distribution Trees(MDT; マルチキャスト配信ツリー)と呼ばれる特別な GRE トンネルを使用します。これは、参加するプロバイダー エッジ(PE)ルータの間に構築され、PIM コントロールプレーンを設定し、マルチキャスト トラフィックを関係する受信者に配信します。

上級者向けヒント:MVPN イントラネットの詳細については、
http://www.cisco.com/en/US/docs/ios/ipmulti/configuration/guide/imc_cfg_mc_vpn.html [英語] を参照してください。

MVPN が普及するにつれ、異なる VPN 内に受信者を含めるユーザが増えてきました。各 VPN は実質的に他とは分離されているため、この新しいタイプは Extranet MVPN(EMVPN)と呼ばれました。

EMVPN は、特別な静的 mroute エントリを使用して、「イントラネット」 VRF と「エクストラネット」 VRF 間の両方のリンクを表します。これによって、分離されているこれらの VPN でも RPF チェックが成功します。

図 30 MVPN/EMVPN 基本概要

図 30 MVPN/EMVPN 基本概要


上級者向けヒント:MVPN エクストラネットの詳細については、
http://www.cisco.com/en/US/docs/ios/ipmulti/configuration/guide/imc_mc_vpn_extranet.html [英語] を参照してください。

これらのマルチキャスト VPN テクノロジーはどちらも、最近の企業およびサービス プロバイダー両方のネットワークに、Catalyst 6500 を通して広く導入されています。ただし、このテクノロジーには、スケーラビリティとパフォーマンスに影響する重要な制限が 1 つあります。

PFC/DFC3 アーキテクチャでは、MVPN/EMVPN プロセスで GRE ヘッダーのカプセル化およびカプセル化解除(encap/decap)が必要なため、レプリケーションはすべて入力レプリケーション エンジン ASIC で実行しなければなりません。つまり、MVPN の設定により、システム全体を強制的に入力レプリケーションモードで運用するということです。

マルチキャスト フレームは、最初に完全に書き換える(FIB ルックアップを使用)必要があるため、MVPN には 2 つの PFC/DFC3 再循環が必要です(encap/decap 実行のため)。再循環および書き換えの後のみ、フレームはレプリケーションできます(ネイティブ VPN に、その後各 MVPN に 1 回ずつ)。PFC/DFC3 ベースの出力レプリケーション モードではこれは実行できません。

上級者向けヒント:MVPN および入力レプリケーション モードの詳細については、
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/mvpn.html#wp1090931 [英語] を参照してください。

これは良くないことなのでしょうか。答えは、「いいえ」です。この課題は、MVPN 自体と関わるものではなく、(PFC/DFC3 アーキテクチャにより)MVPN で入力レプリケーション モードの使用が必要なために生じるものです。

入力レプリケーション モードの有効な使用方法はさまざまで、全体的なスイッチ ファブリック帯域幅および MET スケーラビリティが問題にならない場合、このモデルは非常に上手く運用されます。

そのため、実際は入力レプリケーション モードとして知られるものと同じ制限が課せられます。マルチキャスト(パケット)レプリケーションの処理はすべて、入力レプリケーション エンジン ASIC によって実行されます。したがって、複数パケットがスイッチ ファブリックを横断し、MET はシステム間で対称にする必要があります。

小規模から中規模のマルチキャスト ネットワークでは、これによる問題は発生しません。ただし、非常に大規模に拡張されたシステムでは、さまざまなファブリック チャネルのオーバーサブスクリプションにつながるおそれがあります。

注: 出力レプリケーション モードおよび出力ローカル機能を作成した理由は、これらの入力モード制限にあります。

図 31 入力レプリケーション

図 31 入力レプリケーション


レプリケーション モードはシステム全体の設定であるため、MVPN の使用によって、MVPN とは何の関係もない場合でも、非 MVPN マルチキャスト トラフィック フローにも入力レプリケーション モードでの運用が強制されます。

現在のソリューション

新しい Supervisor 2T および PFC/DFC4 は、新しい MFIB ベース(フォワーディング)および EDC ベース(レプリケーション)インフラストラクチャを実装しました。この新しいハードウェア インフラストラクチャでは、出力レプリケーション モードで MVPN および EMVPN アーキテクチャを実行できます。

出力レプリケーション モードは、パケット レプリケーションの負荷を分散させます。入力レプリケーション エンジン ASIC が必要とするのは、すべてのローカル OIF に対するフレームのレプリケートのみです。その後、単一(追加)のパケット レプリケーションが行われ、出力対応モジュールが接続された内部ブリッジ ドメインに送信されます。スイッチ ファブリックは、最終的にすべてのローカル OIF のレプリケーションを実行する各出力レプリケーション エンジン ASIC に対して、この単一マルチキャスト フレームをレプリケートします。

それによって、スイッチ ファブリックを通過するトラフィックが劇的に削減され、各モジュールで異なる(つまり非対称な)MET を使用できます。システムは、システム内の最小の MET テーブルによって OIF の数が制限されている入力レプリケーションを使用するよりもスケーラブルになります。

注: 完全に非対称な MET テーブルを持つには、各モジュールに DFC が必要です。モジュールに DFC がない場合、その MET はスーパーバイザの MET と同期されます。

上級者向けヒント:出力レプリケーション モードの詳細については、
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/mcastv4.html#wp1076728 [英語] を参照してください。

MVPN を出力レプリケーション モードで運用可能にする、重要なイノベーションがあります。

  • 初期の MVPN 実装とは異なり、EDC 出力レプリケーション モデルはパケットが書き換えられる前にレプリケーションを実行します。
  • 新しい MFIB インフラストラクチャに伴い、PFC/DFC4 IFE/OFE 処理では、パケット カプセル化/カプセル化解除の複数の再循環が不要になりました。

上級者向けヒント:PFC/DFC4 ベースの IFE/OFE 処理については、
http://www.cisco.com/web/JP/product/hs/switches/cat6500/prodlit/white_paper_c11-676346.html を参照してください。

図 32 出力レプリケーション

図 32 出力レプリケーション
※画像をクリックすると、大きな画面で表示されますpopup_icon


注: この新しい機能は自動的に有効化され、入力のレプリケーション モードを強制しなくなります。

どのように役立つか

出力レプリケーション モードで MVPN および EMVPN を使用する機能は、スケーラビリティおよびパフォーマンスに次の利点を提供します。

  • 入力レプリケーション エンジン ASIC ハードウェアにかかる処理の負荷を削減します。
  • スイッチ ファブリックを通過するマルチキャスト トラフィックが減少し、スケーラビリティが拡大、個別のファブリック ASIC ハードウェアの輻輳が減少します。
  • MET プログラミングを非対称にすることが可能になり、エントリの合計数はシステム内の MET 数と等しくなります(64 K × N モジュール)。

8 PIM-BIDIR ハードウェア RPDF エントリのサポート
ハードウェアで同時に 8 つの RP を定義します。

これまでの課題

Bidirectional PIM(PIM-BIDIR; 双方向 PIM)は、特別な PIM フォワーディング パラダイムで、他の PIM モードとは大きく異なっています。PIM-BIDIR は、完全に RP(つまり共有パス)ベース(*,G)のディストリビューション モデルであり、個別の送信元に関する知識には一切依存しません。したがって、多対多のアプリケーションで、非常に多くの送信元を扱う場合に理想的です。

すべての PIM モードと同様に、同じマルチキャストルーティングの基本原則が数多く適用されます(たとえば、Incoming Interface(IIF; 着信インターフェイス)および Outgoing Interface(OIF)がある IP mroute、RPF チェックなど)。ただし、双方向 PIM は、名前が示すとおり、トラフィックを RPF に対して双方向に通過させる、完全に一意のフォワーディング モデルを使用します。

データ駆動型ではなく(IP mroute のステート メンテナンスが、IP マルチキャスト送信元の有無に基づかないことを意味します)、RP に根ざして事前構築されたフォワーディング トポロジを使用することで、PIM-BIDIR は独特の存在になっています。そのため、すべてのフォワーディングは PIM-BIDIR RP とのパスに沿って行われます。

PIM-BIDIR は、最良のユニキャスト ルーティング メトリックに基づいて、RP との間で事前定義されたディストリビューション ツリーを構築することで、これを達成します。初期化中、各 PIM 対応インターフェイスは(RP への最良パスに沿って)Designated Forwarder(DF)選出を受け、最良のメトリクスを持つインターフェイスが DF になります。

図 33 基本的な PIM-BIDIR RP ベース ディストリビューション

図 33 基本的な PIM-BIDIR RP ベース ディストリビューション


単一 DF は、PIM-BIDIR ドメイン内のすべてのリンク上に存在します(各 RP に対して)。マルチキャスト グループの DF は、リンク上へのダウンストリーム トラフィックのフォワーディングとリンクから RP へのアップストリーム トラフィックのフォワーディングを受け持ちます。これらのタスクは、RP の対象となっているすべての双方向グループにして実行されます。リンク上の DF は、ローカル受信者からの IGMP 加入の処理と RP への PIM 加入メッセージの発信も行います。

注: PIM-BIDIR DF は、現在の RP へのパスがリターン パスか双方向パスかを識別します。PIM-BIDIR DF は、トラフィックを(他のリモート受信者用の)RP に向けてアップストリーム方向に転送しながら、受信者への直接フォワーディング(プロキシ フォワーディング)を行うことができます。

このため、PIM-SM 送信元の登録が不要になり、サブネットごとの DR 選出も不要になるため、予測可能性とスケーラビリティの高いフォワーディング モデルを実現できます。すべての PIM ルータが RP の IP アドレス(グループ IP アドレスの各範囲)とその RP への最適な到達方法を認識している限り、ソース数の多いネットワークでは PIM-BIDIR 設計が理想的となります。

注: RP マッピングは、PIM インターフェイスの IP アドレスとクラス D マルチキャスト グループのサブセット(通常は ACL で定義されます)の間の静的または動的な関連付けです。

上級者向けヒント:双方向 PIM の詳細については、
http://www.cisco.com/en/US/docs/ios/12_2/ip/configuration/guide/1cfbipim.html [英語] を参照してください。

ハードウェア ベースのマルチレイヤ スイッチング プラットフォームの場合、このためには、ハードウェア内の PIM-BIDIR RP マッピング設定が事前にわかっていて保存されている必要があります。PFC/DFC3 ハードウェアでは、4 つの異なる PIM-BIDIR RP エントリ(関連する RP への DF パスを表すことから RPDF エントリと呼ばれます)を保存できます。このため、各システムでは、異なる PIM-BIDIR RP マッピングを 4 つだけサポートできます。

図 34 PFC/DFC ベースの PIM-BIDIR RPDF エントリ

図 34 PFC/DFC ベースの PIM-BIDIR RPDF エントリ
※画像をクリックすると、大きな画面で表示されますpopup_icon


これは良くないことなのでしょうか。答えは、「いいえ」です。課題となるのは、定義できる RP マッピングが 4 つだけに制限されるため、IP マルチキャスト ネットワークで使用できる組み合わせが限定されるという点だけです。このため、各システムで処理できる PIM-BIDIR 配布ツリーの数が 4 エントリに制限されます。

注: 5 つ以上の RP マッピングでも実際には IOS ソフトウェアで設定できますが、PFC/DFC3 ハードウェア内でアクティブになるマッピングは 4 つだけです。5 番目以降の RP マッピングは「ゾンビ」エントリと呼ばれ、ハードウェア内の既存の 4 つのマッピングのいずれかが無効になるとインストールされます。

現在のソリューション

新しい Supervisor 2T および PFC/DFC4 では、8 つの PIM-BIDIR「RPDF」エントリをハードウェアに保存できるようになり、8 つの RP マッピングを使用できるようになりました。

注: PIM-BIDIR に関連するハードウェア フォワーディング エントリには、(*,G)と(*,G/m)の 2 つがあります。

PIM-BIDIR(*,G)ハードウェア エントリは、共通 PIM スパース(*,G)エントリによく似ています。2 つのモードの主な違いは、RPF(スパース)および DF(双方向)フォワーディング チェックにあります。

(*, G/m)エントリは、PIM-BIDIR でトラフィックを source-only ネットワーク内の RP に転送するために使用されます。このようなネットワークでは、(*,G)エントリが存在しません。これは、RP へのすべてのフォワーディングをマッピングする真のマスク ベースのエントリ(RP マッピングを通じたエントリ)です。

したがって、(*, G/m)エントリは、送信元トラフィックに RP を転送する目的と、CPU へのトラフィックのパント(ソフトウェア フォワーディングのためのパント)を回避する目的のためだけにハードウェア内で作成されます。

注: RP 自体では、(*,G/m)エントリが実際には「ドロップ」エントリとなります。

(*,G/m)エントリのパケット フローとテーブル プログラミングは(*,G)エントリによく似ています。2 つのエントリの相違点は、以下のとおりです。

  • (*,G/m)の MFIB TCAM ルックアップでは、IP_DA にマスク "m" を使用します。これに対し、(*,G)エントリでは完全一致を使用します。
  • (*,G/m)エントリでは、RP の RPF インターフェイスだけを OIF として使用します。これに対し、(*,G)エントリでは、(RP の RPF インターフェイスだけでなく)他の DF インターフェイスを OIF リストに追加することもできます。
  • したがって、この違いは MET 内の OIF にも反映されます。
  • ハードウェア パケット フローおよびテーブル プログラミングに関しては、(*,G/m)と(*,G)の違いはごくわずかです。
  • (*,G/m)の場合は、特別な "s_star_priority" フィールドが FIB DRAM 内で設定され、(S/m,*)エントリより高い優先度が(*,G/m)エントリに与えられます。

注: RP マッピングが 8 つまでという新しい制限は、DF_MASK フィールド(PFC/DFC4 FIB DRAM のフィールド)が 8 ビット幅であり、各ビットが 1 つの RP を表すことによるものです。

VPN 環境では、VLAN がローカルな意味を持つため、異なる VPN 内の PIM-BIDIR RP 間で同じ RP インデックスが共有されます。これは、実際には VPN ごとに 8 つの RP を使用できることを意味します(グローバル テーブルは VPN 0)。

どのように役立つか

新しい PFC/DFC4 ハードウェアと新しい MFIB ハードウェア インフラストラクチャの組み合わせでは、8 つの RP マッピングを設定できるため、PIM-BIDIR マルチキャスト ネットワークの冗長性とスケーラビリティが向上します。

PIM-BIDIR では、システムに対する管理の影響を最小限に抑えながら、事実上台数無制限の送信元 IP ホストをサポートできる、スケーラビリティに優れた多対多の IP マルチキャスト ネットワークの作成が可能です。

個別の PIM-BIDIR スコープを 8 つまでサポートできるので、ネットワークの冗長性とスケーラビリティを向上できます。異なるスコープのそれぞれにおいて、異なるネットワーク領域をサポートしたり、(*,G)RP ベースの配布ツリーを最適化するための特別なフォワーディング パスを作成したりすることができます。

FIB TCAM の IPv6 マルチキャスト(*,G)および(S,G)エントリ
IPv6 のハードウェア ベースのフォワーディングを向上し、遅延を低減します。

これまでの課題

IPv6 マルチキャスト L2/L3 スイッチングが初めて搭載されたのは、PFC/DFC3 ハードウェアおよび 12.2(18)SXE IOS ソフトウェアを備えた Catalyst 6500 でした。これにより、ハードウェアによる IPv6 マルチキャストが実現されましたが、IP アドレス指定方式が拡張されたため、ハードウェア ベースのフォワーディングには多くの課題が生じました。

IPv6 マルチキャスト アドレスは 128 ビット長で、特別なプレフィクス FF00::/8(2 進数では 11111111)が使用されます。これは、IPv4 の 224.0.0.0/8(または「クラス D」アドレス空間)に相当します。マルチキャスト プレフィクスの直後にある 2 番目のオクテットでは、マルチキャスト アドレスの有効期間とスコープを定義します。

「固定」マルチキャスト アドレスの有効期間パラメータは 0 になり、「一時」マルチキャスト アドレスの有効期間パラメータは 1 になります。「Node」、「Link」、「Site」、「Organization」、「Global」のいずれかのスコープを持つ IPv6 マルチキャスト アドレスは、アドレス パラメータがそれぞれ FF01、FF02、FF05、FF08、FF0E になります。

図 35 128 ビットの IPv6 マルチキャスト アドレス

図 35 128 ビットの IPv6 マルチキャスト アドレス
※画像をクリックすると、大きな画面で表示されますpopup_icon


注: すべての IPv6 ノード(ホストおよびルータ)は、以下のマルチキャスト グループに加入するか、またはこれらのグループ宛てのパケットを受信する必要があります。

  • 「All-nodes」マルチキャスト グループ FF02:0:0:0:0:0:0:1(IPv4 アドレス 224.0.0.1 と同様にスコープはリンクローカル)
  • 「All-routers」マルチキャスト グループ FF02:0:0:0:0:0:0:2(IPv4 アドレス 224.0.0.2 と同様にスコープはリンクローカル)
  • 「Solicited-node」マルチキャスト グループ FF02:0:0:0:0:1:FF00:0000/104(割り当てられているユニキャストおよびエニーキャスト アドレスのそれぞれに使用される)

solicited-node マルチキャスト アドレスは、IPv6 ユニキャストまたはエニーキャスト アドレスに対応するマルチキャスト グループです。IPv6 solicited-node マルチキャストアドレスのプレフィクスは FF02:0:0:0:0:1:FF00:0000/104 となり、対応する IPv6 ユニキャストまたはエニーキャスト アドレスの下位 24 ビットがこれに連結されます。

たとえば、IPv6 アドレス 2037::01:800:200E:8C6C に対応する solicited-node マルチキャスト アドレスは FF02::1:FF0E:8C6C です。solicited-node アドレスは、IPv6 の「neighbor solicitation」メッセージで使用されます

注: IPv6 にはブロードキャスト アドレスはありません。ブロードキャスト アドレスの代わりにリンクローカル IPv6 マルチキャスト アドレスが使用されます。

サイトローカルまたはグローバル IPv6 アドレスをインターフェイスに対して設定すると、リンクローカル アドレスが自動的に設定され、そのインターフェイスに対して IPv6 がアクティブ化 されます。さらに、設定されたインターフェイスは、そのリンクの必須マルチキャスト グループに自動的に加入します。

IPv6 マルチキャスト ルーティングでは、MRIB/MFIB フォワーディング アーキテクチャを使用します。MRIB は MSFC5 上の L3 ルーティング データベースであり、MFIB は PFC4/DFC4 上の L3/L2 フォワーディング インフラストラクチャです。MRIB/MFIB データベースには主に(*,G)、(S,G)、または(*,G/m)エントリが、それらの後方に存在する IPv6 PIM インターフェイスのリストとともに格納されます。

12.2(18)SXE 以降の IOS ソフトウェアでは、以下の IPv6 プロトコルによる IPv6 マルチキャスト ルーティングの実装をサポートしています。

  • Multicast Listener Discovery(MLD): MLD は、直接接続リンク上のマルチキャスト リスナー(受信者)を IPv6 ルータで検出するときに使用されるリンクローカル プロトコルです。以下の 2 つのバージョンの MLD がサポートされます。
    1. MLD バージョン 1:IPv4 PIM-SM 用の Internet Group Management Protocol(IGMP)バージョン 2(*,G)の加入および脱退に基づいています。
    2. MLD バージョン 2:IPv4 PIM-SSM 用の IGMP バージョン 3(S,G)に基づいています。

注: Cisco IOS ソフトウェアでは、MLD バージョン 2 と MLD バージョン 1 の両方をサポートしています。MLD バージョン 2 は、MLD バージョン 1 との完全な下位互換性があります。MLD バージョン 1 のみをサポートするホストは、MLD バージョン 2 が稼動している Cisco ルータとの相互運用性があります。

  • PIM スパース モード(PIM-SM): これは、IPv4 で使用されるのと同じ、基本的なスパース ベースのフォワーディング モデルです。送信元マルチキャスト(*,G)RP ベース配布ツリー フォワーディングの場合は、常に RP による定義が必要です。最終ホップ PIM ルータは、送信元ベースの IP を学習すると、最短パス(S,G)配布ツリーを構築できるようになります。
  • PIM Source-Specific Multicast(PIM-SSM): これは、PIM-SM に似ていますが、最短パスの送信元ベース(S,G)配布ツリーに完全に基づいています。最終ホップ PIM ルータが受信者の優先送信元 IP アドレスを認識している必要があります。SSM が機能するには、MLD バージョン 2 が必須です。

PFC/DFC3 ハードウェアでは、以下の IPv6 マルチキャスト機能をサポートしています。

  • RPR および RPR+ 冗長性モード: これは、PIM および MLD プロセスを起動する必要があり、スーパーバイザ スイッチオーバー後にフォワーディング エントリが再学習されることから、コールド ハイ アベイラビリティとして知られています。

注: IPv6 マルチキャスト ハードウェア エントリは大きすぎて FIB TCAM に格納できないため、PFC/DFC3 では SSO 冗長性モードがサポートされていません。

  • Multicast Listener Discovery Version 2(MLDv2)スヌーピング: これは、L2 IPv6 サブネット上で送信元固有の MLD 加入および脱退(PIM-SSM 用)をサポートしています。

注: MLDv1 ホストとの下位互換性を適用する MLDv1 スヌーピングは、PFC/DFC3 上ではサポートされません。

  • IPv6 マルチキャスト ハードウェア レート リミッタ: これは、IPv6 マルチキャスト フレーム用の基本的なパケット マッチング機能およびしきい値ベースのドロップ機能を提供し、CPU および DRAM への処理の影響を最小化します。
  • IPv6 マルチキャスト ブートストラップ ルータ(BSR): これは、IPv6 PIM ルータへの分散 IPv6 PIM ランデブー ポイント(RP)グループに動的プロトコルを提供します。
  • IPv6 用の PIM-SSM マッピング: IPv6 SSM アドレス範囲は「FF3X::/32」です。ここで、X はスコープ ビットを表します。
  • IPv6 アクセス サービス(DHCPv6、ICMPv6 および Neighbor Discovery): これらは、ユニキャストおよびマルチキャスト IPv6 ルーティングに使用されるリンクローカル マルチキャスト機能です。

上級者向けヒント:PFC/DFC3 ベースの IPv6 マルチキャストの詳細については、
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/mcastv6.html [英語] を参照してください。

現在、ハードウェア ベースの IPv6 マルチキャスト フォワーディングでは、必要なハードウェア エントリの規模が主要な課題になっています。それぞれの一意な IPv6 アドレスが 128 ビット長であり、IP マルチキャストがハードウェア内では(Source IP, Group IP)として表されるため、アドレス空間がさらに 256 ビット必要になります。すべての PFC/DFC FIB「TCAM」(Ternary Content Addressable Memory)ハードウェア エントリが(KEY + ADDRESS + MASK)の形式になります。IP マルチキャストの場合は、(KEY + S,G + MASK)の形式になります。

注: IPv4 の場合、この割り当て設計には TCAM メモリ空間の 144 ビットが必要です。IPv6 の場合は、TCAM メモリ空間の 288 ビットが必要です。

PFC/DFC3 FIB TCAM では 288 ビットが 1 エントリに収まらないため、代用手段として、すべての IPv6 マルチキャスト HW エントリが NetFlow TCAM 内にプログラミングされています。このアプローチ自体は機能しますが、メモリ サイズが大きく、プログラミング/検索プロセスを伴うことにより、NetFlow TCAM の動作が遅くなり、ルックアップ結果を後から照合する必要があるため、追加の処理時間が必要になります。

これは良くないことなのでしょうか。答えは、「いいえ」です。以降のフォワーディング決定(NetFlow ベースのショートカット インストール後のフォワーディング決定)は CPU ベースの処理なしで PFC/DFC によって実行されるため、当然、これもハードウェア ベースの IPv6 マルチキャスト フォワーディングと見なされます。したがって、この設計は、上記のような短所があるものの、ソフトウェア ベースのフォワーディングに比べると速度とスケーラビリティが根本的に優れています。

しかしながら、NetFlow ベースの IPv6 マルチキャスト フォワーディング決定は、FIB ベースの IPv4 マルチキャスト フォワーディングに比べると、著しく遅いといえます。これは、トラフィック フローが最初に確立されるときのマルチキャスト ルーティング(配布ツリー)セットアップ レートが若干低くなることを意味します。

PFC/DFC3 では、IPv6 フォワーディングの最大ルックアップ レートが集中型(PFC ベース)の場合は約 20 Mpps、分散型(DFC ベース)の場合は約 24 Mpps で、遅延が約 10 〜 20 マイクロ秒です。

現在のソリューション

新しい Supervisor 2T および PFC/DFC4 では、特に IPv6 マルチキャスト ルーティングをサポートできるようにするために、FIB TCAM テーブル サイズが 288 ビット幅に拡張されています。このため、IPv6 MFIB インフラストラクチャで完全な(KEY + S,G + MASK)情報を TCAM メモリ内にインストールすることが可能です。

PFC/DFC4 FIB TCAM では、512 K(非 XL)または 1 M(XL)のいずれかのエントリをサポートできますが、それぞれの場合の IP マルチキャストの割り当ては IOS ソフトウェアによって 128 K および 256 K に制限されます。FIB TCAM の割り当てと同様に、隣接関係テーブルでは、統計領域と非統計領域に分割された 512 K または 1M のいずれかのエントリをサポートできます。

図 36 IPv6 MFIB ルックアップ プロセス

図 36 IPv6 MFIB ルックアップ プロセス
※画像をクリックすると、大きな画面で表示されますpopup_icon


統計領域からは、マルチキャスト隣接関係(フロー隣接関係とレプリケーション隣接関係の両方)が割り当てられます。統計領域は、さらに、Control Plane Policing(CoPP)、IFE/OFE、レプリケーションなどの各種アプリケーション用のいくつかの領域に分割されます。

512K の統計領域(テーブル サイズが 1M の場合)のうち、動的に割り当てることのできる使用可能な隣接関係の数は約 454K です。IPv6 マルチキャスト隣接関係には、フロー隣接関係(FIB DRAM 内の隣接インデックス)とレプリケーション隣接関係(MET エントリ内の隣接インデックス)の両方が含まれます。

注: 出力レプリケーション モードの場合は、それぞれのフロー隣接関係につき、2 つの隣接ノードを割り当てる必要があります(PI と非 PI にそれぞれ 1 つずつ)。

PFC/DFC4 では、IPv6 フォワーディングの最大ルックアップ レートが集中型(PFC ベース)と分散型(DFC ベース)のどちらについても 30 Mpps で、遅延が約 6 〜 10 マイクロ秒です。

どのように役立つか

IPv6 マルチキャストを FIB TCAM 内で処理できるため、L2/L3 IPv6 フォワーディング ルックアップが大幅に高速化されています。このため、IPv6 マルチキャスト トラフィック パスをより高速で確立でき、トラフィックの配信を迅速化できます。

IP マルチキャストは、複数のホストに対するミッションクリティカル IP データの同時配信に使用されます。このため、IP マルチキャスト フォワーディングでは、マルチキャスト送信元と受信者間でフローを確立する速度が最も重要な要素の 1 つとなります。

この新しいハードウェア機能では、IPv6 マルチキャストの最大フォワーディング ルックアップを(従来より 33 パーセントの高速化となる)約 30 Mpps に最適化するとともに、IPv4 および IPv6 に対して統一された MFIB ベースのフォワーディング インフラストラクチャの基盤を提供します。

新しいインフラストラクチャによるマルチキャスト HA の強化
新しいインフラストラクチャ上に構築されたハイ アベイラビリティにより、ステートフル スイッチオーバーが最適化されます。

これまでの課題

ハイ アベイラビリティ(HA)の概念は当初、冗長スーパーバイザ エンジンで採用されたものでした。一方のスーパーバイザが「アクティブ」として選出され、もう一方のスーパーバイザが「スタンバイ」になります。アクティブ スーパーバイザは、動作中に、それ自体の L2/L3 フォワーディング情報(すべてまたは一部)をスタンバイ スーパーバイザに同期します。

これにより、障害の発生したアクティブ スーパーバイザから待機中のスタンバイ スーパーバイザへのスイッチオーバーが可能になるという仕組みでした。当然、同期に複雑性が伴うため、実際に同期可能な情報とその量は、現在稼動しているハードウェアとソフトウェアによって異なります。

PFC/DFC3 アーキテクチャでは、以下の HA 動作モードがサポートされています。

  • Route Processor Redundancy(RPR): この HA モードは「コールド」モードと見なされ、IOS イメージおよび設定の基本的な同期を提供します。アクティブ スーパーバイザに障害が発生した場合は、スタンバイ スーパーバイザをブートして、すべての IOS サブシステムを(同期された IOS イメージおよび設定から)再同期し、すべてのフォワーディング エントリをスタンバイに再学習させる必要があります。
  • Route Processor Redundancy Plus(RPR+): 「ウォーム」と見なされるこの HA モード(RPR より可用性が高い)では、スーパーバイザがすでにブートされており、すべての IOS サブシステムがパッシブ(非稼動)モードになっています。アクティブ スーパーバイザに障害が発生した場合は、アクティブ スーパーバイザが単に IOS サブシステムを再初期化してフォワーディング エントリを再学習する必要があるだけです。
  • Stateful Switch-Over(SSO): 「ホット」 と見なされるこの HA モード(RPR+ より可用性が高い)では、スーパーバイザが完全にブートされており、すべての IOS サブシステムがセミパッシブ モードになっています。ハードウェア フォワーディング エントリとステート関連のソフトウェア情報はいずれも継続的に同期されます。アクティブ スーパーバイザに障害が発生した場合は、スタンバイ スーパーバイザが完全なフォワーディング機能を持ちます(スタンバイ モードからアクティブ モードへの切り替え後)。

L3 ルーティングの「Non-Stop Forwarding」(NSF)機能には、通常、SSO がハードウェア ベースのプラットフォーム上で伴います。NSF は SSO ハードウェア インフラストラクチャを利用し、アクティブ スーパーバイザに障害が発生した場合は、ルーティング トポロジの変更を報告しません。SSO では、スタンバイ スーパーバイザが古いフォワーディング エントリを使用してフレームの送信を継続できるからこそ、これが可能になっています。

注: NSF と SSO は技術的に互いに独立した機能であり、NSF は SSO の動作に必須ではありません。ただし、L3 ルーティング隣接に障害が発生した場合は、ネイバーがそれ自体のデータベースからルーティング情報を削除します。このプロセスによりハードウェア フォワーディング エントリが無効になるため、NSF と SSO が通常は併用されます。

12.2(18)SXE 以降の IOS ソフトウェアでは、デフォルト冗長性モードが SSO になっています。スタンドアロン(または単一シャーシのデュアル スーパーバイザ)Catalyst 6500 と Virtual Switching System(VSS)の両方で、これがデフォルト HA モードとなっています。「ip multicast-routing」が設定されている場合、マルチキャスト HA サポートはデフォルトで有効になります。

上級者向けヒント:PFC/DFC3 ベースの SSO/NSF の詳細については、
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/nsfsso.html [英語] を参照してください。

IP マルチキャスト HA サポートは、他のルーティング プロトコルの HA サポートと異なり、マルチキャスト ルーティング(mroute)ステートが動的(またはデータ駆動型)であり、送信元と受信者の存在に依存しています。

IP マルチキャストの場合は、ハードウェア内で SSO をサポートするために必要となる重要なコンポーネントがいくつかあります これらのコンポーネントは、通常の動作モードと一貫するもので、コントロール プレーンとデータ プレーンの機能に分けることができます。

マルチキャスト NSF/SSO: これは、RP マッピング情報、mroute(*,G)および(S,G)ステート、ハードウェア フォワーディング エントリ(例:マルチキャスト FIB および隣接、MET および LTL/FPOE インデックス)などの必要な情報が MSFC と PFC 間ですべて確実に同期(「チェックポイント」)されるようにするためのものです。

これにより、ルーティング コントロール プレーンを再コンバージェンスしながら、学習済みのフォワーディング エントリを通じて同じ物理パス上でマルチキャスト データ トラフィックを継続することができます。

マルチキャスト HA チェックポイント:

  • Auto-RP または BSR のいずれかから動的に学習されたグループと RP のマッピング(IPv4 のみ)
  • PIM Bi-dir で指定されたフォワーダ(DF)情報および PIM Bi-dir RP ルート情報(IPv4 のみ)
  • Multicast Call Admission Control(MCAC)予約情報(IPv6 のみ)
  • マルチキャスト VPN(MVPN)および MVPN エクストラネット MDT トンネル情報(IPv4 のみ)
  • PIM Register トンネル情報(IPv6 のみ)
  • データ駆動イベントによって生成されるマルチキャスト フォワーディング ステート(IPv4/IPv6)
図 37 基本的なマルチキャスト HA

図 37 基本的なマルチキャスト HA


注: PIM は基本的には NSF/SSO 対応ではありません。ただし、PIM クエリーインターバル(hello)のデフォルト値 30 秒(3 x hello = 90 秒のホールド タイム)により、PIM ネイバー関係を失うことなく NSF/SSO プロセス全体を完了させることができます。したがって、マルチキャスト HA 環境では PIM クエリーインターバルをデフォルト設定のままにしておくことが推奨されます。

PIM トリガー加入: この機能を使用すると、PIM インターフェイス上の隣接 PIM ネイバーをトリガーして、このインターフェイスを Reverse Path Forwarding(RPF)インターフェイスとして使用しているすべての(*, G)および(S, G)mroute に対して PIM 加入メッセージを送信することができます。

PIM hello には、新しい Generation ID(GenID)値が(RFC 4601 の規定に従って)追加されています。この値は、スイッチオーバー後にインクリメントされます。インクリメントされた GenID を受信した PIM ネイバーは、そのインターフェイスに関連付けられているすべての mroute に対して新しい PIM 加入メッセージをトリガーします。

GenID: GenID は、ランダムに生成される 32 ビット値であり、インターフェイス上で PIM フォワーディングが開始または再開されるたびに再生成されます。PIM hello メッセージ内の GenID 値を処理するには、RFC 4601 に準拠した Cisco IOS ソフトウェアが PIM ネイバー上で稼動している必要があります。

図 38 基本的なマルチキャスト HA

図 38 基本的なマルチキャスト HA


スーパーバイザ スイッチオーバー イベントが発生すると、PIM トリガー加入機能(GenID を使用)により、すべての PIM ルーティング ステート情報(ダウンストリーム ネイバーが認識している情報)が更新されます。同時に、マルチキャスト SSO により、ハードウェア フォワーディング エントリに変更がないことが確認されます。これにより、これまでにインストールされたすべてのトラフィック フローの送信を継続できます。コントロール プレーンの再コンバージェンスが行われると、新しいハードウェア エントリがインストールされ、古いエントリが削除されます。

スタンバイ スーパーバイザの初回のインストール時、またはシステム ブートアップ中には、マルチキャスト フォワーディング ステートの変更を伴うイベントに対応する情報がマルチキャスト HA ソフトウェアによって「一括同期」されます。通常の動作中(定常状態中)の場合、このソフトウェアは、内部データ ベース内のマルチキャスト フォワーディング ステートへの変更(例:RPF 変更、新しい RP マッピング、新しいマルチキャスト フォワーディング エントリなど)を伴うイベントにトリガーされて、「定期的同期」更新を実行します。

上級者向けヒント:PFC/DFC3 ベースのマルチキャスト SSO/NSF の詳細については、
http://www.cisco.com/en/US/docs/ios/ipmulti/configuration/guide/imc_high_availability.html [英語] を参照してください。

したがって、PFC/DFC3 ベースのマルチキャスト SSO/NSF は、ほとんどの設定において約 3 〜 6 秒でスイッチオーバー リカバリを提供します。ただし、マルチキャスト HA の全体的な複雑性のため、いくつかの重要な制限事項があります。

  • IGMP/MLD/PIM スヌーピングの NSF/SSO サポートなし。これは、特定の VLAN 内でフレームを転送するために必要となる L2 固有のステート関連情報です。これは、一時的なフォワーディング ループや加入/脱退の大幅な遅延の原因になることがあります。
  • IPv6 マルチキャストの NSF/SSO サポートなし。これは、PFC/DFC3 ベースのハイブリッド ハードウェアおよびソフトウェアのインタラクションによります。IPv6 マルチキャスト HA は RPR モードでサポートされます。

注: PFC/DFC3 ベースのマルチキャスト HA に関しては、既知の制限事項の他に、注意すべき点がいくつかあります。

Supervisor 720 および MSFC3 のハードウェア アーキテクチャでは、個別のスイッチ プロセッサ(SP)とルート プロセッサ(RP)を使用するモデルをサポートしているため、L2 の「スイッチング」機能と L3 の「ルーティング」機能が分離されます。このモデルは、(従来)物理的に分離されていた「スイッチ」と「ルータ」を単一の L2/L3+ フォワーディング プラットフォームに統合したものです。

分離アーキテクチャ モデルには、処理上のメリットがありますが、フォワーディング情報が適切に学習され、正確なフォワーディング ルックアップ結果が得られるようにするために SP と RP CPU 間の通信を増やす必要があります。必要なフォワーディング負荷が大きいほど、プロセッサ間の通信が増加します。

現在の IPv4 ハードウェア インフラストラクチャ(MMLS; マルチキャスト マルチレイヤ スイッチング)は、L2/L3 ハードウェアおよびソフトウェア コンポーネントを緊密に統合したものです。負荷が非常に大きい場合(たとえば、完全装備のシステムで多数の PIM ネイバーおよび数万の IP mroute を扱う場合)は、CPU が過負荷になる可能性があります。

CPU が非常にビジー(過負荷)になると、MMLS ソフトウェアが IP mroute のステート変化の検出やハードウェア フォワーディング エントリの適切な更新に失敗する可能性があります。これが原因となって、マルチキャスト トポロジ全体の完全な再コンバージェンスが行われるまで、一時的なパケット フォワーディング ループや一時的なパケット損失が生じることがあります。

さらに、Supervisor 720 および Supervisor 720-10GE にはスイッチ ファブリック機能が統合されているため、スーパーバイザ エンジンがスイッチオーバーされると、ファブリックも強制的にスイッチオーバーされます。ファブリックのスイッチオーバー中には、少なくとも 0.5 秒から 1.5 秒の間、データが失われます。

Catalyst 6500 「E シリーズ シャーシ」(WS-C6513-E など)に Supervisor 720 または Supervisor 720-10GE がインストールされている場合は、拡張ホット スタンバイ ファブリック スイッチオーバーと呼ばれる新しいファブリック スイッチオーバー メカニズムが IOS リリース 12.2(33)SXH 以降に搭載されています。これにより、この機能に対応したモジュールでは、データ損失の生じる時間が 50 ミリ秒から 0.5 秒の間までに短縮されます。

これは良くないことなのでしょうか。答えは、「はい」でもあり「いいえ」でもあります。小規模から中規模のマルチキャスト環境では、現在の PFC/DFC3 ベースのマルチキャスト HA 設計で SSO に完全に対応でき、トラフィックの再コンバージェンスに要する時間も、ほとんどの IP マルチキャスト アプリケーションで無視できるレベルにとどまります。

しかし、非常に大規模に拡張されたマルチキャスト環境や大規模な L2 または IPv6 マルチキャスト環境では、上記のことが原因となって、再コンバージェンスに遅延が生じることがあります。このようにコンバージェンス期間が長くなると、IP マルチキャスト アプリケーションに悪影響を与える一時的なパケット重複または損失が生じる可能性があります。

現在のソリューション

Supervisor 2T では、基本的なマルチキャスト HA 機能(SSO/NSF や PIM トリガー加入など)および関連する動作のいずれについても変更はありません。

IP マルチキャスト フォワーディングはデータ駆動型の性質を持つため、ソフトウェア テーブルとハードウェア テーブル間には、常にある程度のインタラクションがあります。新しい Supervisor 2T では、マルチキャスト コントロール プレーンとデータ プレーンの両方にさまざまな強化が加えられています。

新しい MSFC5(コントロール プレーン)では、各コアが 1.5 GHz で動作する新しいデュアル コア CPU をサポートし、新しい 1 つに結合された IOS イメージを実行します。したがって、旧製品(MSFC3 SP/RP @ 600 MHz)と比べて動作速度が倍増しており、複数の(個別の)CPU 間でのプロセッサ間通信が不要になっています。

  • これらの MSFC5 強化機能はそのいずれもがマルチキャスト コントロール プレーン上の負荷を軽減させます。IP マルチキャスト コントロール プレーンの更新、ハードウェア フォワーディング情報のプログラミング、およびアクティブ スーパーバイザとスタンバイ スーパーバイザ間の SSO/NSF 同期の実行に使用できる RP CPU のサイクルが増えました。

新しい PFC4(データ プレーン)では、IPv4、IPv6 L2(CAM)、および L3(FIB TCAM)のフォワーディング エントリの SSO 同期をハードウェア内でサポートしています。IPv4 マルチキャストフォワーディング ルックアップを約 60 Mpps で実行でき、IPv6 マルチキャスト ルックアップを約 30 Mpps で実行できます。旧製品(PFC3)のパフォーマンスが IPv4 については約 30 Mpps、IPv6 については約 20 Mpps であったことと比べると、大幅な向上となっています。

PFC4 では、フォワーディング スループットの総合的向上に加え、IPv4 および IPv6 のマルチキャスト RPF インターフェイス、IPv4 および IPv6(PIM-SM)のトンネル登録、および(PIM-BIDIR)RPDF エントリの SSO 同期をサポートしています。また、LIF/BD および LTL/FPOE ポート インデックスもサポートしています。

新しい 2 Tbps スイッチ ファブリックでは、アクティブおよびスタンバイ スーパーバイザ間の専用(back-to-back)冗長チャネルを通じて SSO をサポートしています。さらに、新しい WS-X6900(CEF2T)スイッチング モジュールでも、冗長チャネル(アクティブとスタンバイに 1 チャネルずつ)をサポートしており、ファブリックのスイッチオーバー時間が最小化されています。

また、HA の「拡張ホット スタンバイ ファブリック スイッチオーバー」機能は、Supervisor 2T および最新の IOS ソフトウェアでもサポートされています。これにより、SSO スタンバイ スイッチ ファブリックがパケット フォワーディングを開始するための所要時間が(約 50 〜 200 ミリ秒まで)最小化されています。

注: これらの強化機能により、IPv4/IPv6 MFIB ベースの統合フォワーディング インフラストラクチャおよび EDC ベースのマルチキャスト レプリケーション モデルのための基盤が確立されました。

新しい MFIB ベースのフォワーディング インフラストラクチャは、プラットフォームにもルーティング プロトコルにも依存しない IOS ライブラリ(API)を IP マルチキャスト ソフトウェアに提供します。その主な目的は、IP マルチキャスト ルーティング テーブル(MRIB)ソフトウェアでフォワーディング決定を行うときに使用される、基本的なインターフェイス情報およびステート通知をシスコ IOS に提供することにあります。

  • これは、マルチキャスト インターフェイス ステータスの処理方法を簡素化したモデルです。ソフトウェア MFIB は、すべてのマルチキャスト対応インターフェイスの動作ステータスを単純に追跡し、シンプルなインターフェイス フラグ(厳密なセマンティックに従うフラグ)を通じて、この情報を MRIB に提供します。ハードウェア MFIB では、ソフトウェア MRIB/MFIB データベースからの情報に基づいてネクストホップ L2/L3 アドレス情報を維持する必要があるだけです。
  • 分散 MFIB(dMFIB)では、MSFC5 CPU が(ソフトウェア)MFIB サーバ、PFC/DFC4 フォワーディング エンジンが MFIB クライアントとなるサーバ/クライアント モデルを採用しています。
  • dMFIB は、MFIB データベースの完全なコピーをすべてのモジュールに配信し、データ駆動のプロトコル イベントを(フラグにより)モジュールから MRIB/MFIB コントロール プレーンに中継します。マルチキャスト パケットをソフトウェアにスイッチングして(データ駆動イベントをトリガーする目的などで)、トラフィック統計情報をアップロードする機能も備えています。

ソフトウェア ベースの MRIB/MFIB とハードウェア ベースの MFIB フォワーディング インフラストラクチャがこのように統合されていることにより、ソフトウェアとハードウェアの処理負荷が大幅に軽減され、SSO および ISSU HA インフラストラクチャとの互換性の高い、簡素化されたサーバ/クライアント モデルが実現されています。

新しい EDC ベースのマルチキャスト レプリケーション モデルは、真のマルチキャストを実現したハードウェア フォワーディング コンポーネントです。IP マルチキャストでは、与えられたソース データグラムの正確なコピーを複数の受信ホストに送信することが根本的な必要条件となっています。ハードウェア内でこれを実現するには、複数のフレーム コピーを作成できる ASIC と(ソフトウェアによって管理される)配信モデルの両方が必要です。

  • MSFC5 および PFC/DFC4 では、入力および出力レプリケーション モードの両方をサポートしています。ただし、OIF のスケーラビリティを最適化し、スイッチ ファブリックの使用率を最小化するために出力レプリケーションがデフォルト モードとして選択されています。これは、これまでのハードウェア レプリケーションの原則と一貫しています。
  • 新しい EDC レプリケーション モデルでは、より一貫した出力レプリケーション モード プログラミング IOS ライブラリ(API)を使用して、マルチキャスト拡張テーブル(MET)エントリおよび LTL/FPOE ポート インデックスをプログラミングおよび同期します。
  • EDC では、このために、内部出力ブロードキャスト ドメインを(IP mroute ごとに)構築する新しい LIF/BD 機能を使用して、正しい発信(出力)モジュールへのマルチキャスト フレームの配信を最適化します。

また、EDC ベースのレプリケーション モデルでは、サーバ/クライアント モデルを採用しており、信頼性とスケーラビリティに優れた(出力レプリケーション モード)ASIC プログラミングを実現しています。これは、アーキテクチャ的に SSO および ISSU HA インフラストラクチャとの互換性が強化されたものとなります。

注: マルチキャスト HA のこれらの新機能および強化機能に加えて、Supervisor 2T および最新の IOS では、L2 IGMP/MLD/PIM スヌーピングおよび IPv6 マルチキャストに対する SSO/NSF ハードウェア サポートも提供しています。PFC/DFC4 ハードウェアはこれらのエントリをサポートする能力を有していますが、一部のソフトウェア機能は 15.0SY IOS リリースで提供が開始される予定です。

どのように役立つか

前世代のすべての既存機能を基盤して新しい機能を追加した Supervisor 2T は、最高パフォーマンスの IP マルチキャスト プラットフォームを実現すると同時に、市場で最も可用性の高いプラットフォームをも実現しています。

新しい MSFC5(コントロール プレーン)および PFC4(データ プレーン)ハードウェアと新しい MFIB ベースのフォワーディング インフラストラクチャおよび EDC ベースのレプリケーション モデルの組み合わせにより、IP マルチキャストのパフォーマンスおよびハイ アベイラビリティが新たなレベルに到達しています。

図 39 MFIB ベースのマルチキャスト HA

図 39 MFIB ベースのマルチキャスト HA


これらのすべての機能は、追加の管理オーバーヘッドを伴うことなく自動的に有効化されます。この新しいレベルのマルチキャスト HA では、スーパーバイザ エンジンの壊滅的障害という不運に見舞われても、次世代の IP マルチキャスト ネットワークの運用を維持できます。

VPLS、H-VPLS、および EoMPLS とのハードウェア統合
高度な L2 VPN ネットワーク設計に対する組み込みの IP マルチキャスト サポートを利用できます。

これまでの課題

仮想プライベート LAN サービス(VPLS)では、IP/MPLS ネットワーク上で L2 LAN をエミュレートします。VPLS では、異なるサイトからカスタマー MAC アドレスを動的に学習し、L2 カスタマー トラフィックのブリッジングに使用することも可能です。Advanced VPLS では、拡張 CLI が提供され、イーサネット疑似配線(PW)サポートが追加されています。

注: MPLS では、イーサネット疑似配線を作成するためにフロー ラベルと呼ばれる追加のラベルが付加されています。このラベルには、各仮想回線(VC)に関する情報が格納されます。

図 40 基本的な VPLS トポロジ

図 40 基本的な VPLS トポロジ


上級者向けヒント:双方向 VPLS および Advanced VPLS の詳細については、
http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/
mp_l2vpn_advvanced.html
[英語] を参照してください。

Hierarchical VPLS(H-VPLS)では、階層的な VPLS 内で、2 つのネットワーク側プロバイダー エッジ(N-PE)ルータにより、ユーザ側プロバイダー エッジに冗長性サービスを提供することができます。冗長 N-PE ルータを使用することにより、リンクおよびノードの障害に対する安定性と信頼性が向上します。

H-VPLS アーキテクチャでは、Ethernet Access Island(EAI)が VPLS ネットワークと連携して動作します(MPLS が基盤のトランスポートを担います)。EAI は、標準的なイーサネット ネットワークと同様に CE ルータ間で動作します。

EAI 内の CE デバイスからのトラフィックは、EAI 内で UPE デバイスによってローカルにスイッチングされます。このスイッチングは、計算されたスパニング ツリー パスに沿って行われます。各 UPE デバイスは、VPLS PW を使用して 1 つ以上の NPE デバイスに接続されます。UPE に対してローカルなトラフィックは、NPE デバイスに転送されません。

図 41 H-VPLS トポロジ

図 41 H-VPLS トポロジ


上級者向けヒント:H-VPLS の詳細については、
http://www.cisco.com/en/US/docs/ios/mpls/configuration/guide/mp_hvpls_npe_red.html [英語] を参照してください。

Ethernet over MPLS(EoMPLS)は、IP/MPLS ネットワーク上でイーサネット(802.3)プロトコル データをトランスポートするためのもう 1 つの方法であり、基本的な L2VPN の概念の多くが確立されています。EoMPLS は実際には、Any Transport over MPLS(AToM)のサブセットです。VPLS では、イーサネット疑似配線(PW)機能を通じて、MPLS ネットワーク上でのイーサネット フレームの基本的 L2 トランスポートが実行されます。

上級者向けヒント:EoMPLS の詳細については、
http://www.cisco.com/en/US/docs/interfaces_modules/shared_port_adapters/configuration/6500series/
76cfgeth.html#Scalable_EoMPLS
[英語] を参照してください。

注: EoMPLS がポイントツーポイント(P2P)サービスを提供するのに対し、VPLS はマルチポイントツーマルチポイント(MP2MP)またはポイントツーマルチポイント(P2MP)サービスを提供します。

L2VPN ドメインは、リモート カスタマー CE を相互接続する MPLS PE を接続している仮想回線(VC)の集まりです。これらの仮想回線は、手動での設定か、Targeted LDP セッションのいずれかにより定義されます。これらは、MPLS コアへの各カスタマー(またはカスタマー VLAN)接続を識別します。

MPLS コアでは、これらの仮想回線が、特定のカスタマー トラフィック用の特定の VC ラベルを使用してスイッチングされます。送信元 CE から発信されたトラフィックは、MPLS コア上でトランスポートされるときに、2 つのラベルを割り当てられます。外側のラベルはトンネル ラベルまたは IGP ラベルと呼ばれ、内側のラベルは VC ラベルと呼ばれます。外側のトンネル ラベルは、PE 間のトンネル(PE ルータ間でセットアップされているトンネル)を識別し、内側の VC ラベルは各エミュレート LAN を分離します。

したがって、これらの L2VPN エミュレート LAN サービスは、実際のイーサネット ベース LAN と同じ動作(MAC ベースのアドレスの学習や L2 スイッチングなど)を提供します。この仮想化ネットワーキング機能では、L2 ベースのユニキャストおよびマルチキャスト フォワーディングを IP/MPLS ネットワーク上で動作させることができます。

IP ホストの MAC アドレスが VC 上で学習されると、それ以降のパケットがその VC 上で送信されるようになります。これは、通常の L2 ベースのスイッチングと同じです。L2VPN マルチキャスト レプリケーションはユニキャストと同様に動作しますが、特殊な(MET)隣接関係を使用する点が異なります。

注: 現在、L2VPN サービスは Supervisor 720(PFC/DFC3)上で使用可能ですが、追加の SIP/SPA ハードウェアおよび 12.2(33)SXH 以降の IOS ソフトウェアを使用する必要があります。

これは良くないことなのでしょうか。答えは、「はい」でもあり「いいえ」でもあります。基本的な L2VPN テクノロジーは、顧客の IP/MPLS コアにわたってエミュレート LAN サービスを提供することを可能にします。これは、これまで用意されていなかった有用な新機能です。

現在の L2VPN テクノロジーには、二重の課題があります。第 1 に、追加のハードウェア(SIP/SPA)が必要であるため、コストと管理の負担が大きくなります。第 2 に、通常の LAN テクノロジーに付随している既知の制限(たとえば、L2 マルチキャスト フラッディング)の多くが解決されていません。

現在のソリューション

Supervisor 2T(PFC/DFC4)および最新の IOS ソフトウェアは、すべてのイーサネット ポート上で高度な L2VPN サービス(VPLS および EoMPLS)向けのネイティブなハードウェア統合を提供します。これにより、ネットワーク全体の設計(設定ポイントおよび監視ポイント)が簡素化され、運用コスト(ハードウェアの新規導入および交換)が削減されます。

PFC/DFC4 アーキテクチャでは、ハードウェア統合がもたらす明白なメリットに加えて、L2VPN マルチキャストに特化した追加の強化機能が提供されます。これらには以下が含まれます。

  • IGMP/PIM スヌーピング(VC ごと)
  • マルチキャスト source-only ブリッジング(VC ごと)
  • FIB 内のマルチキャスト エントリの順序付け(VPLS 用)

注: L2 マルチキャスト環境におけるデフォルトのスイッチング動作では、同じブリッジ ドメイン内のすべてのポートに対してトラフィックがフラッディングされます。ネットワーク帯域幅およびリソースを節約するには、L2 マルチキャスト フラッディングを抑制する(少なくとも制限する)必要があります。

IGMP スヌーピング(VC ごと)

PE ルータでは、(同じカスタマー サイトからの)着信 IGMP フレームおよび PIM パケットをスヌーピングすることにより、(同じカスタマー VPN の)グループ メンバーシップおよびマルチキャスト ルータ(mrouter)情報を動的に学習できるようになりました。

送信元 PE は、この L2 スヌーピング情報に基づいて、L2 マルチキャスト フォワーディング テーブル(VC ごと)を構築することができます。この L2 スヌーピング テーブルがいったん構築されると、接続されているカスタマー サイト内で対象となる受信者(mrouter)が存在するリモート PE に対してのみ特定のマルチキャスト フローが転送されるようになります。

注: IGMP スヌーピングが含まれていなかった従来の L2VPN 実装では、マルチキャスト トラフィックの受信者が存在するかどうかに関係なく、すべてのリモート CE デバイスに対して、送信元 CE デバイスから発信されたすべてのマルチキャスト パケットが送信(フラッディング)されます。

この最適化により、コア ネットワーク帯域幅が節減されます。IGMP スヌーピングの最適化が可能となるのは、条件を満たす学習が PE ルータで行われる場合(具体的に言うと、同じ CE デバイスからの異なる VLAN がそれぞれ異なる VPLS ドメインにマッピングされている場合)だけです。

L2 スヌーピングは VPLS VC(ドメイン)ごとに PE ルータ上で実行されるため、上記に該当しない場合、つまり 1 つの VPLS ドメインに複数のカスタマー VLAN がマッピングされている場合(条件を満たさない学習の場合)は、スヌーピングのメリットが得られません。

図 42 PFC/DFC4 L2VPN フラッディング保護

図 42 PFC/DFC4 L2VPN フラッディング保護
※画像をクリックすると、大きな画面で表示されますpopup_icon


マルチキャスト source-only ブリッジング(VC ごと)

着信マルチキャスト トラフィックの対象となる L2 受信者が存在しない場合は、入力 VLAN(BD)上で、この source-only トラフィックがすべての L3 マルチキャスト ルータ(mrouter)ポートへブリッジングされ、他の L3 OIF にルーティングできるようになります。標準的な VLAN(BD)内では、OMF(Optimized Multicast Flooding)エントリによってこのブリッジング動作が提供されます。

L2VPN コアにわたって L3 mrouter を学習することが可能になったため、類似の source-only エントリ動作を L2VPN 仮想回線ごとに提供することができます。この場合、CE デバイスからのマルチキャスト トラフィックの対象となる L2 受信者が存在しないと、L3 mrouter を学習した VC 上でのみトラフィックの転送が行われることになります。

PFC/DFC4 ハードウェア内では、この L2VPN OMF エントリが FIB の(*, *, BD)エントリとしてプログラミングされます。この FIB エントリに連動する特定の MET エントリが、マルチキャスト ルータを学習した VC を持ちます(通常の OMF MET エントリと同様)。

FIB 内のマルチキャスト エントリの順序付け(VPLS 用)

以下の図は、マルチキャスト固有の各種 VPLS FIB エントリの順序付けを示しています。順序付けは、最上部の順位が最も高く、以下、降順で順序が続きます。

(S, G, BD)が最高順位(最も明確なエントリ)となり、(*, *, BD)OMF エントリが最小順位(最も曖昧なエントリ)となります。(*, 224.0.0.x/24)エントリは、VPLS ドメイン内の VC 上でフレームのフラッディングに使用されるコントロール プレーン エントリです。

注: このコントロール プレーン エントリは、IP マルチキャスト(224.0.0.x)アドレスを使用して隣接情報を交換する L3 ルーティング プロトコル フレーム(例:OSPF)に使用されます。

図 43 VPLS エントリの特殊な FIB 順序付け

図 43 VPLS エントリの特殊な FIB 順序付け


マルチキャスト固有の L2VPN サービスには、LIF/BD ポート マッピングとの統合、LTL/MET インデックスの共有、MFIB ベースのフォワーディング ルックアップ、EDC ベースの出力レプリケーションなど、Supervisor 2T および PFC/DFC4 ハードウェアによって提供されるその他のすべての強化機能のメリットが間接的に活かされています。

これらの新しい強化機能があるため、L2VPN マルチキャスト実装では、対象となる受信者または mrouter が存在する(特定の VC 内の)PE に対してのみマルチキャスト トラフィックのレプリケーションと送信を行うことができます。これにより、トラフィックを転送する必要のない PE(および中継 P デバイス)上のネットワーク帯域幅が節約されます。

図 44 L2VPN トポロジの最適化

図 44 L2VPN トポロジの最適化
※画像をクリックすると、大きな画面で表示されますpopup_icon


どのように役立つか

ハードウェア内で L2VPN を実行できるため、ネットワーク全体の設計(構成ポイントおよび監視ポイント)が簡素化され、しかも運用コスト(ハードウェアの新規導入および交換)が削減されます。

個別の SIP モジュールと SPA インターフェイスを購入およびサポートしなくても L2VPN のメリットを活用できるようになりました。既知のテクノロジーを使用する、簡素化されたエンドツーエンドのイーサネット ベースのソリューションを構築できます。

さらに、IP マルチキャストの場合は、ハードウェア統合により L2 スヌーピングおよび特殊な MFIB プログラミングを使用できるようになったため、ネットワーク帯域幅が効率化されます。これにより、L2VPN アーキテクチャが IP マルチキャストの原則と一貫したものになります。

CoPP の例外ケースと詳細なマルチキャスト レート制限
CPU 宛のマルチキャスト トラフィックのコントロール プレーン保護を向上できます。

これまでの課題

DoS 攻撃、構成の誤り、またはソフトウェアの不具合を防止するには、一般に、CPU 宛のトラフィックを制御する(「レート制限」する)ことが運用上のベスト プラクティスとなります。これは、データ駆動型の性質を持つ IP マルチキャストの場合に特に重要となります。

特定のネットワーク システム内のデータ トラフィックの大部分は、転送中の状態(送信元から受信者へのフォワーディング パスに沿って他のネットワーク システムに転送されている状態)にあります。通常、このトラフィック(および関連するハードウェア処理)のことを「データ プレーン」といいます。

ただし、これらのネットワーク システムがデータ トラフィックの正確な送信先を認識できるようにするために、これらのデバイスは相互に通信します。通常、このフォワーディング情報(および関連するハードウェア処理)のことを「コントロール プレーン」といいます。

Supervisor 720(MSFC3)アーキテクチャでは、2 基の個別の CPU(SP と RP)を使用します。スイッチ プロセッサ(SP)はすべての L2(または MAC ベース)「スイッチング」機能を処理し、ルート プロセッサ(RP)はすべての L3+(IP/MPLS ベース)「ルーティング」機能を処理します。

L2 コントロール プレーン トラフィックの例を以下に挙げます。

  • スイッチング プロトコル パケット:STP/RSTP/MST、VTP、DTP など
  • 隣接パケット:CDP、LLDP
  • リンク管理パケット:LACP、PAGP、UDLD など
  • 認証パケット:802.1x など
  • マルチキャスト スヌーピング:IGMP、MLD、および PIM

L3 コントロール プレーン トラフィックの例を以下に挙げます。

  • ルーティング プロトコル パケット:BGP、OSPF、EIGRP、IS-IS、RIP など
  • ファーストホップ冗長性プロトコル パケット:HSRP、GLBP、および VRRP
  • 到達可能性パケット:ARP、ICM、IP-SLA プローブなど
  • 管理パケット:SNMP、SSH、Telnet、TFTP、NTP など
  • マルチキャスト ルーティング パケット:PIM、IGMP/MLD、Auto-RP、BSR など

特定のタイプのデータ プレーン トラフィックは、ソフトウェア内で CPU による処理を実際に必要とすることがあります。このタイプのトラフィックは、通常、「パント」トラフィックと呼ばれます。

ソフトウェアによって処理されるデータ プレーン パケットの例を以下に挙げます。

  • IP オプション付きパケット(例:ルータ アラート)
  • Time to Live(TTL; 存続可能時間)フィールドが 1 に設定されているパケット
  • ACL ロギングを必要とするパケット
  • フラグメンテーションが必要なパケット(例:MTU ミスマッチ)
  • ハードウェアによって分類されないパケット(例:AppleTalk、IPX、DECNET など)
  • 宛先プレフィクスが L3 ルーティング テーブル内に見つからないパケット(「FIB ミス」とも呼ばれます)
  • ハードウェアでサポートされていない機能が適用されているためハードウェア内でスイッチングできないパケット(例:マルチキャスト NAT)

したがって、ネットワークの完全性を維持するには、当然、CPU(コントロール プレーン)を DoS 攻撃や誤設定から保護する必要があります。Catalyst 6500 シリーズには、以下の 2 つの基本的なオプションが用意されています。

  • ハードウェア レート リミッタ
  • CoPP

注: Supervisor 720(PFC/DFC3)アーキテクチャでは、どちらのオプションにも長所と短所があり、通常は両方のオプションを導入すると良好な結果が得られます。

PFC/DFC3 ハードウェア レート リミッタ

PFC/DFC3 ハードウェアには、さまざまなパケット タイプに応じて使用でき、パケットのレート制限アクションを実装できる 10 個のハードウェア レジスタが組み込まれています。レート リミッタを有効化するには、CPU 宛の特定のタイプのトラフィックに対して、毎秒のパケット数(pps)しきい値を定義します。

L2 と L3 の両方のタイプのトラフィックに一致するレジスタが含まれており、L2 レート リミッタと L3 レート リミッタの両方を同時に適用できます。設定したトラフィック タイプに一致するトラフィックのうち、定義した pps しきい値(レート)に一致するトラフィックは単純にドロップされます。ドロップは PFC/DFC3 自体で行われ、ドロップされたトラフィックは CPU に到達しません。

図 45 PFC/DFC3 ベースのハードウェア レート リミッタとソフトウェア CoPP

図 45 PFC/DFC3 ベースのハードウェア レート リミッタとソフトウェア CoPP
※画像をクリックすると、大きな画面で表示されますpopup_icon


PFC/DFC3 では、以下の IP マルチキャスト用ハードウェア レート リミッタが用意されています。

表 4 PFC/DFC3 ハードウェア レート リミッタ

レート リミッタ デフォルト/しきい値 説明
Multicast Partial-SC オン
100,000 pps
特別な処理が必要な場合に、一部のマルチキャスト フローを部分的にソフトウェア スイッチングすることができます。これらのフローがマルチレイヤ スイッチング フィーチャ カード(MSFC)宛の場合は、これれらのフローをレート制限することを推奨します。
注:このレート リミッタでは、用意されている 10 個のハードウェア レジスタとは別の特殊なレジスタが使用されます。これは、フォワーディング エンジンごとに適用されるのではなく、グローバルに適用されます。
Multicast Default Adjacency オン
100,000 pps
FIB ミスがあるためソフトウェア処理が必要なマルチキャスト トラフィックを制限します(マルチキャスト宛先アドレスがハードウェア mroute テーブル内のエントリに一致しない場合など)。
Multicast Non-RPF オフ RPF チェックに失敗したマルチキャスト パケットを制限します(共有 LAN 上の非 DR など)。
注:このオプションは PFC/DFC3B および PFC/DFC3C でのみサポートされます。
Multicast IP Options オフ さらなる処理のために RP CPU へ送信されるマルチキャスト パケットのうち、IP オプション付きのパケット(IGMP ルータ アラートなど)を制限します。
注:このオプションは PFC/DFC3B および PFC/DFC3C でのみサポートされます。
TTL Failure オフ ユニキャストとマルチキャストの両方に適用されます。存続可能時間(TTL)チェック障害を理由として RP CPU へ送信されるパケットを制限します。
MTU Failure オフ ユニキャストとマルチキャストの両方に適用されます。最大伝送ユニット(MTU)障害を理由として RP CPU へ送信されるパケットを制限します。
Multicast IGMP オフ IGMP スヌーピングのために SP CPU へ送信される IGMP 制御メッセージを制限します。このレート リミッタは IGMP スヌーピングが有効化されている場合に使用する必要があります。
注:このハードウェア レジスタは L2 PDU レジスタと共有されており、いずれか一方だけを有効化できます。
注:このレート リミッタは、スイッチのファブリック スイッチング モードがトランケートの場合にはサポートされません。


Catalyst 6500 ハードウェアのレート リミッタは非常に効果的に機能しますが、非常に明示的な性質を持ちます。しきい値を低く設定しすぎると、有効なフレームもドロップされるため、別の問題が生じます。各システムに適用するレート制限しきい値は、着信フレーム本来のレート(予測されるレート)に基づいて注意深く正確に設定する必要があります。

用意されているハードウェア レジスタの数には限り(10)があることに注意してください。これらのレジスタのうち 8 つは、L3 フォワーディング エンジン内に存在し、残りの 2 つは L2 フォワーディング エンジン内に存在します。さらに、これらのレジスタのうちいくつかは、パケット タイプ間(L2 PDU と IGMP 間など)で共有されているため、両方を同時に使用することはできません。

上級者向けヒント:PFC/DFC3 ベースのハードウェア レート リミッタの詳細については、
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/dos.html [英語] を参照してください。

MSFC3 ベースの CoPP

CoPP には、ハードウェア ベースのレート リミッタより幅広いレベルの保護が用意されています。ただし、Supervisor 720 アーキテクチャでは、CoPP がルート プロセッサ(RP)のインバンド コントローラ上で実装されており、これは外部ルータの物理イーサネット インターフェイスに似ています。

CoPP には、システムへの新しい仮想インターフェイス(コントロール プレーン インターフェイス)が搭載されています。この新しいインターフェイス タイプは、ループバック インターフェイス、トンネル インターフェイス、ポート チャネル インターフェイス、VLAN インターフェイス(SVI)などの既存の仮想インターフェイスに似ています。CoPP では、Modular QoS CLI(MQC)を通じた専用のコントロール プレーン設定を使用します。

コントロール プレーン インターフェイスを有効化すると、ソフトウェア(QoS ベースの)レート リミッタ(ポリシング)の適用が可能になります。この CoPP レート制限アクションは、RP コントロール プレーン宛のトラフィックのうち、ユーザが設定した ACL によって選択されるトラフィックに適用されます。ACL でパケット タイプをマッチングすると、柔軟な対応が可能になり、グローバル レベルのコントロール プレーン攻撃への保護を向上できます。

図 46 PFC/DFC3 ベースのハードウェア レート リミッタとソフトウェア CoPP

図 46 PFC/DFC3 ベースのハードウェア レート リミッタとソフトウェア CoPP
※画像をクリックすると、大きな画面で表示されますpopup_icon


上級者向けヒント:MSFC3 ベースの CoPP の詳細については、
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/configuration/guide/copp.html [英語] を参照してください。

残念ながら、Supervisor 720 ベースの CoPP 機能は、RP インバンド コントローラ上のソフトウェアに実装されています。このため、CPU バウンド トラフィックがスイッチング バックプレーン(データ バスまたはスイッチ ファブリック)をすでに通過しており、限りあるインターフェイス リソースを消費しています。

さらに、現在の CoPP 実装では SP CPU が保護されません。通常は、L2 ハードウェア レート リミッタを実装することで、この問題を緩和できます。ただし、L2 PDU レート制限と IGMP レート制限の両方が同じレジスタを共有しています(このため、この 2 つを共存させることはできません)。

これは良くないことなのでしょうか。答えは、「いいえ」です。既存の機能の有用性が非常に高いため、従来では不可能だったレベルのコントロール プレーン保護がもたらされます。このレベルの保護には対応すらしていない競合他社もあります。

マッチングが可能なトラフィック タイプの総数が制限されており、良好なコントロール プレーン トラフィックと不正なコントロール プレーン トラフィックのバランスをとれるようにしきい値を注意深く設定する必要があることが、(PFC/DFC3)ハードウェア レート リミッタの主要な課題となります。

また、(MSFC3)CoPP は、主に RP インバンド コントローラ(SP ではなく)の機能の 1 つとして実装されているため、トラフィックがコントロール プレーンのインターフェイス上でドロップされる前に他のシステム リソースを消費することが、(MSFC3)CoPP の主要な課題となります。

これらの点を除けば、CoPP をハードウェア レート リミッタと組み合わせて使用することにより、CPU バウンド トラフィック ストームの多くに対する保護を強化できます。たとえば、「fragment」キーワードを使用する CoPP ACL と「IP options」ハードウェア レート リミッタの両方により、DoS 攻撃に使用されることの多い 2 つの異常なトラフィック タイプから RP CPU を保護することが可能です。

現在のソリューション

Supervisor 2T(MSFC5 および PFC/DFC4)ハードウェアおよび最新の IOS ソフトウェアでは、既存のコントロール プレーン保護機能にいくつかの根本的強化が加えられています。これらには以下が含まれます。

  • 単一化された(デュアル コア)RP CPU およびインバンド コントローラ
  • ハードウェア統合および CoPP 用の特殊な例外ケース
  • ハードウェア レート リミッタ用の 32 個の L3 レジスタと 12 個の L2 レジスタ

MSFC5 では、CPU およびインバンド コントローラが単一化されているため、SP および RP ベースの CoPP 実装を個別に用意する必要がなく、単一の「コントロール プレーン」インターフェイスが実現されています。

CPU コントロール プレーン インターフェイスは、システム内の他のインターフェイスと同様に扱われます。コントロール プレーン インターフェイスは、データ プレーンの外部で動作するため、中継スイッチング パフォーマンスが影響を受けません。このため、CoPP 機能は PFC/DFC4 ハードウェア内に直接実装できます(CPU コントロール プレーンを宛先として選択する任意のフォワーディング ルックアップで使用できます)。

注: PFC/DFC4 L3 フォワーディング エンジンは、分類(または QoS/ACL)TCAM を使用して CoPP ポリシーの適用を受け持つようになりました。この機能は、セキュリティ ACL および QoS が通常のデータ プレーン トラフィック フローに適用される仕組みに似ています。

コントロール プレーン保護全般に関しては、単一のコントロール プレーン インターフェイスの他に、ユニキャストとマルチキャストの両方のコントロール プレーン メッセージに対して粒度と柔軟性を向上するハードウェア強化機能が追加されています。これらは以下に示すとおりです。

PFC/DFC4 ベースのハードウェア レート リミッタ

  • パケットごとか、またはバイトごとに設定可能
  • しきい値超過時に最初のパケットをリーク可能
  • パケット ベースまたはバイト ベースのフォワーディング カウンタおよびドロップ カウンタ

PFC/DFC4 ベースの CoPP

  • TTL/MTU 障害などの出力例外に対する CoPP
  • CoPP ポリシー内で Punt 句を指定可能
  • 特定の例外を選択的に無視することが可能
  • パケットまたはバイト ベースのポリシーを柔軟に適用可能
  • フロー粒度で例外パケットをカウント可能(NetFlow を使用)
図 47 PFC/DFC4 ベースのハードウェア レート リミッタと CoPP

図 47 PFC/DFC4 ベースのハードウェア レート リミッタと CoPP


これらの原則はいずれも、ユニキャストとマルチキャストの両方のコントロール プレーンの保護にあてはまります。ただし、マルチキャスト用の特筆すべき強化機能がいくつかあります。これらには以下が含まれます。

L2 IGMP/MLD/PIM スヌーピング用の CoPP

L2 スヌーピングを有効化すると、L2 フォワーディング エンジンのリダイレクト ロジックを(PFC/DFC3 の場合と同様に)使用して IGMP/MLD/PIM パケットが CPU に L2 リダイレクトされます。L3 フォワーディング エンジン内では、これらのリダイレクトされたフレームが L3 FIB ルックアップをバイパスしますが、PACL、VACL、PVACL などの追加機能を適用するために、これらのフレームが処理されます。

これが、CoPP が実装されるポイントとなります(実装には、分類 TCAM および特殊な出力論理インターフェイス(ELIF)が使用されます)。CoPP では、リダイレクトされたコントロール プレーン宛のフレームに対して、特殊な隣接エントリを使用します。このため、最後のフォワーディング決定(パケットを CPU にコピーするかどうか)は、IGMP/MLD または PIM トラフィックのレートと設定済みの CoPP ポリシーに依存します。

フォワーディング レートが CoPP ポリシーを下回っていると、フレームが CPU フォワーディング インデックスとともに L2 フォワーディング エンジンに戻され、さらなる処理のために送信されます。フレームがしきい値を超過した場合は、フレームがドロップされます。

CoPP マルチキャスト FIB ミス例外処理

宛先 FIB エントリが存在しない場合は、CPU がマルチキャスト パケットを処理して、フォワーディング決定を行い、新しいハードウェア ショートカットをインストールする必要があります。PFC/DFC4 は、この場合、CoPP ELIF インデックスに関連付けられている特殊な FIB(*,G/m)エントリをそのまま使用します。他の場合と同様に、このフォワーディング ルックアップが行われると、CoPP ポリシーがパケットに適用され、CPU へ送信されるパケットのレートが制限されます。

CoPP PIM-SM 送信元登録処理

これまでに学習されていない(新規の)送信元のマルチキャスト トラフィックは、PIM-SM の「送信元登録」処理のために CPU に送信する必要があります。PFC/DFC4 は、この場合も、CoPP ELIF インデックスに関連付けられている特殊な FIB(*,G/m)エントリをそのまま使用します。他の場合と同様に、このフォワーディング ルックアップが行われると、CoPP ポリシーがパケットに適用され、CPU へ送信されるパケットのレートが制限されます。

注: ほとんどのケースでは、CoPP を設定すると、これまでに設定したレート リミッタがオーバーライドされます。

CoPP を適用できないケースもあります。これらのケースを以下に示します。

  • RP に到着した PIM Register パケットを CPU に送信する必要がある場合(これが通常のケースです)、転送パケットにも影響が生じることになるため、CPP による送信はできません。このため、特殊な copy_mask が ACL(このパケットを PIM Register パケットとして認識する ACL)から取得され、それ以後、レート リミッタが適用可能になります。
  • PIM Register パケットのカプセル化解除中には、ネイティブ マルチキャスト パケットの到着が開始したことをソフトウェアに伝達する必要があるため、マルチキャスト ルート エントリにヒットするカプセル化解除パケットをレート リミッタにより CPU にコピーする必要があります。これにより、以降の PIM Register メッセージに対して register-stop メッセージの送信を開始できます。

PFC/DFC4 の新しい(または強化された)IP マルチキャスト ハードウェア レート リミッタ

表 5 PFC/DFC4 の新しいハードウェア レート リミッタ

レート リミッタ デフォルト/しきい値 説明
Multicast Punt オフ シグナリングの必要な(*,G/m)パント パケットおよびラストホップ(*,G)パケットを制限します。
Multicast SPT オフ SPT スイッチオーバー中にソース ツリーからのパケットを制限します(共有ツリーへの RPF がまだプライマリ RPF である場合)。
Multicast Register オフ 送信元登録処理のためにファーストホップ指定ルータ(DR)からランデブー ポイント(RP)へ送られるパケットを制限します。
Routing Control オフ マルチキャスト ベースのルーティング プロトコル制御メッセージ(OSPF や EIGRP など)を制限します。


どのように役立つか

完全なハードウェア ベースのコントロール プレーン保護機能は、類似のスイッチング プラットフォームに対する重要な差別化要因となります。コントロール プレーンに依存するデータ プレーンよりもスイッチング コントロール プレーンの方が重要であることに疑問の余地はほとんどありません。したがって、CPU の保護が絶対的な重要性を持ちます。

企業とサービス プロバイダー(SP)のネットワークにとっては、今後も、DoS 攻撃が重大な脅威となります。これらの攻撃により、ミッションクリティカル サービスが停止し、デバイス間のデータ転送が妨げられ、全体的な生産性が低下しかねません。

Supervisor 2T は、新しい MSFC5 RP CPU および PFC/DFC4 ハードウェア ベースのハードウェア レート リミッタおよび CoPP とともに、Cisco Catalyst 6500 シリーズ スイッチ上で DoS 攻撃に対する保護を従来にないレベルまで引き上げます。

同時に、システム上の不要な負荷が軽減されるのでシステムの可用性と安定性が向上し、しかもストレス レベルが軽減されます。

NetFlow(v9)におけるマルチキャスト用の特殊なフィールドと処理
マルチキャスト フロー向けの NFv9 + Flexible NetFlow および出力 NetFlow データ エクスポート(NDE)サポートを利用できます。

これまでの課題

NetFlow アカウンティングは、ネットワーク管理者向けの強力な監視ツールです。トラフィック パターン、リンクの使用率、ユーザごとの課金などの情報を収集できます。NetFlow 機能は、Catalyst 6500 を通過する個々のパケットに関するトラフィック統計情報を収集し、NetFlow テーブルに統計情報を保存します。MSFC 上の NetFlow テーブルにはソフトウェア内でルーティングされたフローに関する統計情報がキャプチャされ、PFC(および各 DFC)上の NetFlow テーブルにはハードウェア内でルーティングされたフローに関する統計情報がキャプチャされます。

NetFlow テーブルは、いくつかの「ハードウェア アシスト」機能で使用されます。ネットワーク アドレス変換(NAT)や IPv6 マルチキャストなどの機能では、NetFlow を使用して、フォワーディング結果を変更します。他の機能(QoS マイクロフロー ポリシングなど)は、NetFlow テーブルの統計情報を使用します。

上級者向けヒント:PFC/DFC3 ベースの NetFlow の詳細については、
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/netflow.html [英語] を参照してください。

この「ネットワーク フロー」情報は、CLI または SNMP を通じてユーザに直接提供できる他、外部にエクスポートして、さまざまな用途のために分析することもできます。このプロセスのことを NetFlow データ エクスポート(NDE)といいます。NDE 機能では、統計情報を外部デバイス(NetFlow コレクター)にエクスポートできます。

NDE は、ネットワーク管理者向けの高度なトラフィック管理メカニズムです。デバイスとリンクの使用率、ネットワークのセキュリティ、トラフィック パターンなど、ネットワークの総合的な稼動状態に関する重要な統計情報を監視できます。

上級者向けヒント:NetFlow データ エクスポート(NDE)の詳細については、
http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SXF/native/configuration/guide/nde.html [英語] を参照してください。

IP マルチキャストの場合、NetFlow 機能を通じて、マルチキャスト固有のデータ(パケットとバイトの両方)を個々のマルチキャスト フローについてキャプチャできます。たとえば、特定のフローや各出力ストリームを対象としてパケット レプリケーション ファクタをキャプチャすることができます。

注: マルチキャスト NetFlow のサポートは、ネットワーク トラフィックに関する完全なエンドツーエンドの使用率情報を完全なマルチキャスト トラフィック課金ソリューション向けに提供します。

マルチキャスト NetFlow では、リバース パス フォワーディング(RPF)チェックに失敗したすべてのパケット(通常、これらはドロップされます)を NetFlow 統計情報にアカウンティングすることもできます。RPF チェックに失敗したパケットのアカウンティングにより、トラフィック統計情報およびパターンをより正確に把握できます。

さらに、マルチキャスト NetFlow では、PIM-BIDIR グループ(これら自体は個々のマルチキャスト送信元に関する情報を持たないため、それらを報告できません)に関する送信元ごとの情報をキャプチャすることも可能です。NetFlow は、この重要な情報をキャプチャできる唯一のメカニズムです。マルチキャスト送信元が数百あるいは数千も存在する場合は、トラブルシューティングおよびアカウンティングのためにこの情報が非常に重要となります。

現在のソリューション

新しい Supervisor 2T および PFC/DFC4 は、新しい IOS コードとともに、Flexible NetFlow(FNF)と呼ばれる新しい NetFlow アーキテクチャを提供します。FNF は、NetFlow のサポートを従来どおり維持しながら(すべてのバージョンの NDE を含みます)、NetFlow アカウンティングおよびエクスポートをさらに柔軟にする新しい機能を追加します。

NetFlow モジュールは、PFC/DFC4 内で、L3 フォワーディング エンジンで処理された IFE/OFE パケットに関するフロー ベースの情報の収集を受け持ちます。分類(CL)モジュールから入力を取り込み、ACL、NetFlow、および L3 ルックアップの結果をまとめて L3 フォワーディング モジュールに出力します。CL モジュールは分類ルックアップを実行し、NetFlow プロファイル ID を提供します。

キーおよびフロー マスク情報を格納する NetFlow プロファイル ID は、NetFlow エントリのルックアップに使用されます。フローはハードウェアによって動的に作成されるか、もしくは CPU またはインバンド パケットを通じてスイッチによりインストールされます。NetFlow モジュールは、NetFlow ルックアップ テーブル、NetFlow エントリ テーブル、および NetFlow 統計情報テーブルで構成されます。

NetFlow エントリ テーブル(NT)と NetFlow 統計情報テーブル(NS)は連動しています。エントリが NT テーブル内に作成されると、対応するエントリが NS テーブル内に作成されます。NT テーブルには、キー フィールドなどのフロー特性またはパターンが格納されます。NS テーブルには、パケットおよびバイト カウント、最終使用日時のタイム スタンプなど、1 対 1 のアクティブ フロー統計情報が維持されます。

NetFlow にフロー情報の収集を開始させるには、分類ロジックを適切な情報でプログラミングする必要があります。入力マルチキャスト NetFlow 設定が行われるインターフェイスに対応する LIF が ACL をポイントし、その ACL がプロファイル ID をポイントし、さらにそのプロファイル ID が NetFlow テーブルおよび統計情報をポイントします。

図 48 PFC/DFC4 NetFlow 処理

図 48 PFC/DFC4 NetFlow 処理


統計情報は、アカウンティング、課金、デバッグなど、さまざまな目的に多用されるツールの 1 つです。プロトコルの動作に統計情報が使用されることもあります。異なる要件に対応する異なるタイプの統計情報があります。

PFC4/DFC4 では以下の統計情報をサポートしています。

  • フォワーディング統計情報
  • 隣接統計情報
  • アカウンティング統計情報(ラベルから IP、IP から IP、集約ラベル)
  • NetFlow 統計情報
  • LIF 統計情報

これらとは別に、デバッグに役立つカウンタが豊富に用意されています(これらのカウンタについては、このドキュメントでは取り上げていません)。

フォワーディング統計情報:IPv4 ユニキャスト、IPv4 マルチキャスト、MPLS など、異なるパケット タイプに基づいて FIB フォワーディング パケットをカウントするためのパケット カウンタのセットです。

32 個のフォワーディング カウンタがあり、各カウンタは 32 ビット幅です。フォワーディング エンジンは、フォワーディング結果に基づいて、どのカウンタを更新するかを決定します。フォワーディング決定か、またはレート リミッタ ドロップによりパケットがドロップされた場合は、統計情報は更新されません。

これらのカウンタには、パケット タイプに基づいて、転送されたパケットのカウントが集計されます。

隣接統計情報:1 組のカウンタ ペアにより維持されます。バイトをカウントする 40 ビットのカウンタと、パケットをカウントする 31 ビットのカウンタからなるペアです。隣接統計情報テーブルには、512 K までの隣接カウンタ ペアを保持できます。これは、フォワーディング隣接関係ごとにバイト/パケット カウンタをチェックするうえで最も役立つカウンタの 1 つです。これらのカウンタは、フォワーディング処理のいずれかの結果がドロップ、レート制限、または例外になった場合には更新されません。

これらのカウンタは、特定のフローをデバッグして、隣接関係が期待どおりに使用されているかどうかをチェックするときに使用できます。さらに、この統計情報は、マルチキャストの場合に非常に重要なロールを担います。ソフトウェア マルチキャスト エントリは、特定のマルチキャスト ハードウェア フローの隣接統計情報に基づいて有効に維持されます。

アカウンティング統計情報:隣接統計情報に似ており、44 ビットのバイト カウンタと 35 ビットのパケット カウンタの両方を含みます。その名が示すとおり、これらの統計情報はアカウンティング/課金に使用できます。これらのカウンタは制限のあるリソースであり、それぞれが 4 K までのエントリを保持できます。これらの統計情報は、特定のインターフェイスおよびトラフィック パターン用の ACL によって制御されます。

NetFlow 統計情報:NetFlow テーブルと 1 対 1 で対応する 512 K の(エントリ)統計情報テーブルです。各統計情報エントリは 27 バイトで、バイトおよびパケット カウンタ、最終アクセス日時のタイムスタンプ、スティッキ TCP フラグなどが格納されます。これらの統計情報の最も重要な使用方法は NDE です。NetFlow 統計情報プロセスの詳細については、「NetFlow アーキテクチャ」のドキュメントを参照してください。

LIF 統計情報:8 つのカウンタ(LIF ごと)のセットとして形成される 128 K のエントリ テーブルであり、40 ビットのバイト カウンタと 31 ビットのパケット カウンタの両方が含まれます。これらの 8 つのカウンタ(LIF ごと)は、8 つの異なるプロトコルに固有のインターフェイス統計情報を提供します。8 つのカウンタのそれぞれは、異なるトラフィック タイプを表すようにプログラミングできます(ブリッジド ユニキャスト パケット、ブリッジド マルチキャスト パケット、ルーテッド IPv4 ユニキャスト、ルーテッド IPv6 マルチキャスト パケットなど)。エンドユーザの視点から見ると、これらの 8 つのカウンタは、各カウンタが特定の 1 タイプの統計情報を提供するように事前にプログラミングされています。

注: 上記の L3 フォワーディング エンジン統計情報(フォワーディング、隣接、アカウンティング、および NetFlow 統計情報)はいずれも特定のアプリケーション用の統計情報を提供するように事前にプログラミングされています。これらは、対応するエントリにヒットするすべてのクラスのパケットに適用されます。

一般的なルールとして、これらのカウンタを管理する個々のソフトウェア コンポーネントが存在し、マルチキャストなどのアプリケーションが適切なカウンタをフェッチすることにより、これらを使用できます。L2 フォワーディング エンジン上の LIF 統計情報は、このルールの例外であり、アプリケーション レベルのプログラミングにより、LIF ごとに 1 つずつ、計 8 つの使用可能なカウンタを選択する必要があります。

LIF 統計情報テーブルは 128 K(LIF)× 8(カウンタ)× 72 ビットのデータ構造体であり、PFC/DFC4 に装着される外部 36 MB QDR SRAM メモリ バンク 2 基に格納されます。LIF 統計情報カウンタの論理構成図を下に示します。

図 49 LIF 統計情報と NetFlow アカウンティング

図 49 LIF 統計情報と NetFlow アカウンティング


LIF 統計情報を使用すると、クリティカルな L2/L3 パケット フォワーディングのための追加の可視性とプロトコルごとの管理情報が実現されます。8 つの使用可能な LIF 統計情報を以下にまとめておきます。

  • ブリッジド ユニキャスト パケット
  • ブリッジド マルチキャスト パケット
  • ブリッジド ブロードキャスト パケット
  • ルーテッド IPv4 ユニキャスト パケット
  • ルーテッド IPv4 マルチキャスト パケット
  • ルーテッド IPv6 ユニキャスト パケット
  • ルーテッド IPv6 マルチキャスト パケット
  • その他のルーテッド パケット(MPLS など)

これにより、これまで結合されていたインターフェイス統計情報を一意なプロトコル別カテゴリに分離して管理とデバッグを容易にすることができます。これらの統計情報には、CLI および NDE を通じてアクセスできます。これは、Supervisor 2T および PFC/DFC4 ハードウェア以外では得ることのできない非常に強力な情報です。

どのように役立つか

Flexible NetFlow(FNF)の新しい機能により、お客様の企業で必要な統計情報に的を絞って(不要な統計情報は排除して)粒度と適用性を向上できるため、IP マルチキャスト トラフィック フローのアカウンティングとエクスポートが大きく改善されます。

FNF および NDE の課金の面に関心がある場合は、これにより個々のマルチキャスト フローのアカウンティングをより正確にすることができ、不要なフロー データを排除してエクスポートの処理負荷を削減することができます。

FNF と NDE のデバッグの面に関心がある場合は、Supervisor 2T および PFC/DFC4 が提供する、粒度の高い詳細情報と、従来では不可能だったレベルの新しい詳細情報が役立ちます。

FNF および NDE のトラフィック管理(またはキャパシティ プランニング)の面に関心がある場合は、Supervisor 2T および PFC/DFC4 が提供する柔軟性により、特別なケースのエクスポート レポートを作成して、ネットワーク内の異なる領域とフローに焦点を絞ることができます。

詳細情報

前述したように、本文書では、新しい Supervisor 2T 上でサポートされる IP マルチキャスト機能のうち、重要な新機能および強化機能だけを取り上げています。

あくまでこれは Catalyst 6500 上でサポートされる IP マルチキャスト機能セット全体の一部です。IP マルチキャストおよび Catalyst 6500 シリーズの詳細については、
http://www.cisco.com/en/US/products/hw/switches/ps708/prod_literature.html [英語] を参照してください。

まとめ

IP マルチキャストは、非常に多くのメリットをもたらすパケット フォワーディング モデルであり、単一の(送信元)IP データ ストリームを複数の(受信者)IP ホストに同時に効率的に配信できます。

この機能は、一般的なユニキャストまたはブロードキャスト ネットワークではコスト的に不可能なものを含め、多様な可能性をもたらします。金融市場、サービス プロバイダー、セキュリティ機関、輸送機関など、多岐にわたる業界で、マルチキャスト トラフィックを使用してネットワーク運用を強化することが可能です。

IP マルチキャストは非常に複雑な機能でもあるため、専用のマルチキャスト ソフトウェアおよびハードウェア機能が必要となります。これらは、ネットワーク プラットフォームを選択する際に検討すべき重要な詳細事項です。

既存の機能と新機能をすべて考慮すれば、Catalyst 6500 と Supervisor 2T ハードウェアの組み合わせが業界唯一の真の IP マルチキャスト向け次世代ネットワーキング プラットフォームである理由が明白になるはずです。

  • 最高レベルのパフォーマンス
  • 最高レベルの拡張性
  • 最高レベルの可用性
  • 最高レベルの柔軟性を持った(モジュラ)プラットフォーム

関連情報

Catalyst 6500 シリーズ:
http://www.cisco.com/jp/go/6500/

Catalyst 6500(Sup 720)IP マルチキャスト設定 - 12.2SX:
http://www.cisco.com/en/US/docs/ios/ipmulti/configuration/guide/12_2sx/imc_12_2sx_book.html [英語]

Catalyst 6500(Sup 720 以降)および Catalyst 4500(Sup 6E 以降)の IP マルチキャスト アーキテクチャとトラブルシューティング PPT(PDF 形式):
http://www.slideshare.net/CiscoSystems/catalyst-6500-and-4500-ip-multicast-architecture-and-troubleshooting [英語]