Cisco Catalyst 6500 シリーズ

Cisco Catalyst 6500 Supervisor Engine 2T:NetFlow の機能拡張

ホワイト ペーパー





Cisco Catalyst 6500 Supervisor Engine 2T:NetFlow の機能拡張





概要


Cisco Catalyst 6500 シリーズ スイッチには、その登場以来、NetFlow が搭載されてきました。当初はトラフィックの転送メカニズムとして使用されていましたが、NetFlow はトラフィック転送を処理するシスコ エクスプレス フォワーディング(CEF)とともに、モニタリングおよび機能のアクセラレーション テクノロジーに発展しました。

Cisco Catalyst 6500 シリーズ スイッチへの Supervisor Engine 2T の導入により、NetFlow の機能は進化し続けています。高度に拡大し続けるシスコのお客様のネットワーク インフラストラクチャにおいて、やり取りされるトラフィックが増加するとともに種類を増すにつれ、フロー情報に対する要求が高まっています。IT 組織は、容量計画、アプリケーション分析、セキュリティ、IP アカウンティング、および幅広い他の目的でこれらを支援するために、ネットワーク トラフィック情報を収集する必要があります。

このホワイト ペーパーでは、ポリシー フィーチャ カード 4(PFC4)を搭載した Supervisor Engine 2T がシスコのお客様のニーズをサポートするさまざまな NetFlow 拡張機能をサポートする仕組みについて解説します。特に、NetFlow の次の側面について説明します。

  • NetFlow の概要
  • Sup2T で向上した NetFlow のスケーラビリティ
  • Egress NetFlow
  • Sampled NetFlow
  • Flexible NetFlow
  • Yielding NetFlow データ エクスポート
  • NetFlow と Embedded Event Manager

注: このホワイト ペーパー全体で、「Supervisor Engine 2T」という用語が使われます。この用語が特長や機能の参照に使用される場合は、PFC4 を搭載した Supervisor Engine 2T によってサポートされている特長や機能、および Distributed Feature Card 4(DFC4)を備えたラインカードと解釈してください。「Supervisor Engine 32」、「Supervisor Engine 720」、「Supervisors 32 および 720」という用語は、PFC3 および DFC3 によってサポートされている特長や機能と解釈してください。

NetFlow の概要


NetFlow のより高度なトピックについて解説する前に、Cisco Catalyst 6500 シリーズ スイッチでの基本的な NetFlow 運用を簡単に説明します。

NetFlow とは NetFlow とは、スイッチを通るトラフィック フローに関する情報を収集するために設計されたプロセスです。NetFlow レコードの収集は、ハードウェアベースのプロセスであり、トラフィック フローやパフォーマンスには影響を及ぼしません。NetFlow レコードの外部コレクタへのエクスポートは、コントロール プレーンのプロセスであり、スーパーバイザ エンジン上のルート プロセッサ、またはラインカード上のプロセッサによって実行されます。

現在は、WS-X6908-10G-2T/2TXL、WS-X6816-10G-2T/2TXL、WS-X6816-10T-2T/2TXL、DFC4/DFC4XL 搭載の WS-X6716-10G、DFC4/DFC4XL 搭載の WS-X6716-10T のラインカードで、Supervisor Engine 2T ベースのシステムにおける NetFlow レコードのエクスポートを実行できます。今後、すべての 6900 シリーズ モジュールがこの機能を同様にサポートする予定です。図 1 に、NetFlow のレコード収集とエクスポートの処理の概要を示します。

図 1 NetFlow の収集とエクスポートの動作の概要

図 1 NetFlow の収集とエクスポートの動作の概要


トラフィックがスイッチを通るときには転送処理が行われ、フローの宛先の判定、Quality of Service(QoS)や Access Control List(ACL)の適用、および NetFlow 情報の収集が実行されます。Cisco Catalyst 6500 シリーズ スイッチの場合、これらの動作は、スーパーバイザ エンジン上のポリシー フィーチャ カード 4(PFC4)またはラインカード上の分散型フォワーディング カード 4(DFC4)によって実行されます。PFC4 または DFC4 が転送処理を実行するかどうかにかかわらず、同じプロセスになります。

ここまで、NetFlow が何かを見てきましたが、NetFlow を使用する理由は何でしょうか。

NetFlow レコードは、ネットワーク インフラストラクチャでやり取りされるフローの数、タイプに関する豊富な情報を提供します。この情報は、容量計画、アプリケーションのアセスメント、ネットワークのトラブルシューティング、およびセキュリティ運用の支援に使用されます。シスコは、NetFlow 情報を使用して、ネットワークを監視、保護する強力なサービスを提供する、次のベンダーと協力しています。

  • Arbor Networks:Distributed Denial of Service(DDoS; 分散型サービス拒否)攻撃の防止を専門に扱っています。
  • Computer Associates NetQoS:パフォーマンス管理を専門に扱っています。
  • Lancope:セキュリティ、ネットワーク、アプリケーション パフォーマンスを専門に扱っています。
  • Plixer:パフォーマンスと信頼性を専門に扱っています。

また、NetFlow は、重要な情報をネットワーク エンジニアに提供できる、トラブルシューティング ツールでもあります。CEF は送信先プレフィクスをベースにしておりフローを把握していないため、NetFlow を使用すると、ユーザはフロー情報をエクスポートせずに CLI からフロー情報を確認することができます。これにより、発生した問題をユーザが解決できるようサポートします。

さらに、NetFlow は、他のプラットフォームでは従来ソフトウェアでのみ実装されていた他の機能に対するハードウェア アシストとして使用することもできます。Web Cache Communications Protocol(WCCP; Web キャッシュ コミュニケーション プロトコル)、ネットワーク アドレス変換(NAT)、およびマイクロフロー ポリシングは、どれも、パフォーマンス強化を達成する目的で NetFlow インフラストラクチャを使用する機能の例です。

Supervisor Engine 2T が NetFlow ルックアップ動作を実行する仕組み 図 2 に、PFC4 または DFC4 によって実行されるルックアップ動作の例と、各ステップの説明を示します。

図 2 PFC4/DFC4 NetFlow ルックアップ動作

図 2 PFC4/DFC4 NetFlow ルックアップ動作


ステップ 1:パケット ヘッダーの情報に基づいて、フロー キーが生成されます (フロー キーの詳細については、本ホワイト ペーパーのセクション「Flexible NetFlow」を参照してください)。

ステップ 2:フロー キーの情報は、ハッシュ関数に入れられます。ハッシュ関数とは、大規模な可変サイズ量のデータを、インデックスとして利用可能な小規模なデータに変換する数学的関数です。この場合、フロー キー内の情報は、ルックアップ キー(インデックス)とデータ キーに変換され、これらは NetFlow ルックアップ テーブルへのポインタとして使用されます。

ステップ 3:ステップ 2 のハッシュ関数で生成されたルックアップ キーを使用して、NetFlow ルックアップ テーブルで適切な行が決定されます。

ステップ 4:ステップ 2 のハッシュ関数で生成されたデータ キーを使用して、このキーが存在するかを確認するために、すべてのページで比較が実行されます。データ キーがすでに存在する場合、これはヒットと見なされ、NetFlow データ テーブルへのインデックスが取得されます。この行にデータ キーが存在しない場合、データ キーが自動的に入力され、NetFlow データ テーブルへのインデックスがこのフローのために確立されます。

ステップ 5 と 6:ステップ 4 で取得されたインデックスを使用して、フロー キーと NetFlow データ テーブルの情報との比較が実行されます。同様のフローがすでに存在する場合、学習する必要はありません。既存のフローが存在しない場合、フローがテーブルに自動的に入力されます。

ステップ 7:既存のフローの場合、NetFlow 統計テーブル内のフロー統計が更新されます。新しいフローの場合、NetFlow 統計テーブル内のエントリが確立されます。NetFlow は、これらの統計を増加して、そのフロー内の後続パケットに使用します。

すべてのプラットフォームで同じように NetFlow 操作が実行されるわけではないという点は重要です。ここで記載した内容は、Supervisor Engine 2T を搭載した Cisco Catalyst 6500 シリーズ スイッチの場合のみ当てはまります。また、すべての NetFlow 操作は、Egress NetFlow の収集が行われているかどうかにかかわらず、入力フォワーディング エンジン(PFC4 および DFC4 はフォワーディング エンジンです)で実行されます。

テーブルまたはテーブルの行がフルであるために自動的に入力できないフローにはどのような影響があるのでしょうか。基盤となるトラフィックには影響ありませんが、自動的に入力できないフローの統計は収集されません。フローのすべてのパケットはこの同じフォワーディング操作が行われますが、行エントリはトラフィック フローの途中で開きます。この場合、フロー エントリが作成され、フローのリマインダの統計が収集されます。

Sup2T で向上した NetFlow のスケーラビリティ


現在、ネットワークを通過するトラフィックのフローとタイプの数が増え続けているため、IT 組織が自らのインフラストラクチャのフローの内容を理解することがこれまでより重要になっています。Cisco Catalyst 6500 シリーズ スイッチの Supervisor Engine 2T は、これまでにないレベルでの単一システムの NetFlow データ収集をサポートしており、IT 組織が環境を高い信頼性レベルで環境を監視および制御できるようにします。表 1 に、Cisco Catalyst 6500 シリーズ スイッチでサポートされているさまざまなスーパーバイザ エンジンの NetFlow データ収集機能の進化を示します。

表 1 スーパーバイザによる NetFlow Data 収集機能

スーパーバイザ モデル NetFlow テーブルのサイズ ハッシュ効率1 最小入力
Supervisor 2 128K2 フロー エントリ 25% 32K フロー エントリ
Supervisor 720-3A 128K フロー エントリ 50% 64K フロー エントリ
Supervisor 720-3B 128K フロー エントリ 90% 115K フロー エントリ
Supervisor 720-3BXL 256K フロー エントリ 90% 230K フロー エントリ
Supervisor 720-10G-3C 128K フロー エントリ 90% 115K フロー エントリ
Supervisor 720-10G-3CXL 256K フロー エントリ 90% 230K フロー エントリ
Supervisor 32(すべてのバージョン) 128K フロー エントリ 90% 115K フロー エントリ
Supervisor 2T 512K フロー エントリ 99% 507K フロー エントリ
Supervisor 2TXL 1M フロー エントリ3 99% 1015K フロー エントリ

1 ハッシュ関数に関する情報については、このホワイト ペーパーのセクション「NetFlow の概要」を参照してください。
2 1K = 1,024
3 これは、最大 512K の出力エントリと最大 512K の出力エントリに分割されます。


PFC4 ベースの Supervisor Engine 2T では、NetFlow テーブルのサイズが PFC3 ベースのスーパーバイザの 4 倍に増加していることに注意してください。DFC4 は同等グレードの PFC4 と同じサイズの NetFlow テーブルを伝送します。これは、すべて DFC4 を備えたラインカードで構成されたシステムは数百万個の NetFlow エントリを達成し、フロー負荷が非常に高い環境にも対応できることを意味します。

DFC3 と DFC4 のいずれの場合も、DFC を備えたモジュールを展開する利点の 1 つは、各 DFC が独自の固有の NetFlow テーブルを保持することです。Forwarding Information Base(FIB; 転送情報ベース)、Access Control List(ACL; アクセス コントロール リスト)、QoS、MAC テーブルなどの他のテーブルとは異なり、PFC と DFC の間で同期状態は保持され、NetFlow テーブルは単一システム内のすべてのフォワーディング エンジンとの間では同期されません。このため、DFC を備えた各モジュールは独自の NetFlow 統計をそのモジュール上のシステムに入力されるフローのためだけに収集することができます。これは、Supervisor Engine 2TXL およびすべて DFC4XL を備えたモジュールが使用されている場合、13 スロット 6513-E シャーシがシステム全体で最大 1,300 万のフロー エントリをサポートできることを意味します。図 3 に、これが達成できる仕組みを示します。

図 3 6513-E により 1,300 万個のフロー エントリを達成

図 3 6513-E により 1,300 万個のフロー エントリを達成


このようなスケーラビリティの高い要件では、多くの使用例があります。大規模な NetFlow 機能を必要とするお客様の例としては、インターネット サービス プロバイダー、オンライン ストア、オンライン ニュース配信組織、大手製造企業などがあります。

たとえば、大規模にテレビ放送されるスポーツ イベントの期間中に新製品を発売する自動車メーカーを想定します。このメーカーの Web サイトでは、その新製品に関する問い合わせが短期的に数百万件ヒットすることが考えられます。メーカーがインフラストラクチャにある通常のフローだけでなく、これらの新しいフロー(IP アカウンティング、セキュリティ、容量、または他の目的)を確認できるようにするには、非常に大規模な NetFlow 容量が必要となります。

他の例としては、つい先ほど発生した主要なニュースに対処する国際的な報道機関があります。この機関の Web サイトのニュースに関する情報には、ニュースの種類によって異なりますが、おそらく数日間で、数百万人がアクセスすることが考えられます。このようなボリュームの増加には、多数の NetFlow エントリが必要です。

表 1 に戻りますが、前世代のスーパーバイザと比較して、Supervisor Engine 2T ではハッシュ効率が変更されている点にも留意することが重要です。99% まで効率が向上しているということは、NetFlow テーブルほぼ全体へのデータ入力を保証することが可能であることを意味します。つまり、テーブルがすでにフルになってしまってフローの統計が収集されない(「衝突」と呼びます)事象の発生頻度が減少します。NetFlow テーブルの現在の利用状況を確認するには、show platform hardware capacity NetFlow コマンドを実行します。システム内の各 PFC4 または DFC4 の情報が表示されます。

Supervisor Engine 2T でサポートされる、向上した NetFlow スケーラビリティは、環境において非常に多くのフローをトラッキングする組織にとって理想的な選択肢です。

Egress NetFlow


Supervisor Engine 2T が導入されるまで、Cisco Catalyst 6500 シリーズ スイッチのすべてのスーパーバイザでは、Ingress NetFlow しかサポートされていませんでした。つまり、NetFlow 情報は、フローの最終宛先がわかる前にのみ収集されていました。Supervisor Engine 2T は、Egress NetFlow を実行する機能をサポートしています。2 サイクル ルックアップ プロセスであるため、1 サイクル ルックアップを実行していた前世代の Supervisor Engine 32 や Supervisor Engine 720 とは異なります。2 サイクル ルックアップ プロセスにより、フローの最終宛先がわかった後に NetFlow 情報を収集することができます。

システム内のすべてのフォワーディング エンジン(PFC4 および DFC4)で NetFlow ルックアップを実行できますが、Egress NetFlow の場合でも、すべてのルックアップは入力フォワーディング エンジンで実行されることを覚えることが重要です。図 4 で構成されているシステムを想定します。

図 4 PFC4、DFC4、および CFC を備えた 6506-E システム

図 4 PFC4、DFC4、および CFC を備えた 6506-E システム


図 4 を見ながら、トラフィックがスロット 2 からスロット 1 に向かう場合とスロット 1 からスロット 3 に向かう場合の 2 つのケースを考えます。どちらの場合も、Egress NetFlow はアウトバウンド インターフェイスで構成されています。

最初のケースでは、トラフィックはシステム上の集中型フォワーディング カード(CFC)を備えたラインカードから入ります。CFC はどのようなルックアップも実行できないため、これらはスロット 6 の Supervisor Engine 2T 上の PFC4 によって実行されます。このルックアップ プロセスの一部には、Ingress NetFlow ルックアップおよび Egress NetFlow ルックアップが含まれます。宛先がスロット 1 のポートに決定されると、結果がスロット 2 に返送され、パケットがスロット 1 へのスイッチ ファブリック経由で送信されます。パケットはその後適切なポートに転送されます。フローのすべてのパケットで同じプロセスが行われます。

2 番目のケースでは、トラフィックは DFC4 を備えたラインカード上のシステムに入ります。DFC4 はルックアップを実行できるため、このトラフィックのすべてのルックアップを行います。Egress NetFlow ルックアップはルックアップ プロセスの一部として実行されます。宛先がスロット 3 のポートに決定されると、パケットはスロット 3 のスイッチ ファブリック経由で送信されます。パケットはその後適切なポートに転送されます。フローのすべてのパケットで同じプロセスが行われます。

どちらの場合も、出力ラインカードは DFC4 を備えていますが、Egress NetFlow ルックアップは入力フォワーディング エンジン上で実行します。DFC4 は NetFlow ルックアップを実行する機能がありますが、ルックアップのために出力モジュール上で DFC4 が使用されることはありません。

Egress NetFlow が利点を提供できるケースはいくつかあります。図 5 の状況を想定します。ここでは、トラフィックがシステムを離れる前に、お客様が Differentiated Services Code Point(DSCP)のマーキングを行っています。

図 5 Egress NetFlow による QoS マーキングの監視

図 5 Egress NetFlow による QoS マーキングの監視


お客様が QoS 操作に Ingress NetFlow を使用した場合、レコードでは DSCP = 40 を持つトラフィックしか見えません。これは、NetFlow 情報が DSCP 再マーキング操作が行われる前に収集されるためです。QoS の監視で、再マーキングが正常に行われていることを確認したい場合、Egress NetFlow を使用します。Egress NetFlow では、DSCP が 45 に変更された後で NetFlow 情報の収集が行われます。

Egress NetFlow が組織に大きな利益をもたらすその他のケースとしては、ネットワーク運用の分野があります。図 6 のセットアップを想定します。ここでは、多数のアクセス レイヤ スイッチが 1 つのディストリビューション レイヤ スイッチに集約され、コア スイッチに接続されています。

図 6 Egress NetFlow によるネットワーク操作の簡素化

図 6 Egress NetFlow によるネットワーク操作の簡素化


ディストリビューション レイヤで、Ingress NetFlow を使用してアクセス レイヤのスイッチへのすべてのインターフェイスを構成することは可能です。ただし、ディストリビューションからコアへのリンクで Egress NetFlow を構成するほうが、必要な構成がはるかに少なくてすむため、非常に容易です。対象がユーザ アクセス スイッチの場合、トラフィックはほぼすべてがコアまたはデータ センターに転送されるため、コアへのアップリンクでのみ Engress NetFlow を有効にしてもフローを見逃すことはありません。

Egress NetFlow の 3 番目の用途として、Multi-Protocol Label Switching(MPLS)Egress NetFlow があります。前世代の Supervisor Engine 720 はこの機能を Cisco IOS 12.2(33)SXI4 以降でサポートしていますが、MPLS タグが削除された後、フレームを再循環させる必要があります。これは、全体のトラフィック パフォーマンスに影響を及ぼします。Supervisor Engine 2T では、再循環を行わずに MPLS Egress NetFlow が実行され、トラフィック パフォーマンスには影響を与えません。

Supervisor Engine 2T は Egress NetFlow をサポートしているため、IT 組織はより容易に NetFlow インフラストラクチャを管理でき、フォワーディング決定がなされた後の可視性が向上します。

注: Egress NetFlow 構成については、このホワイト ペーパーの「Flexible NetFlow」の部分で説明します。

Sampled NetFlow


Cisco Catalyst 6500 シリーズ スイッチ用の Supervisor Engine 2T は、ハードウェアでの NetFlow サンプリング機能をサポートしています。Supervisor Engine 2T が導入される前、Cisco Catalyst 6500 シリーズ スイッチのすべての PFC3 ベースのスーパーバイザはソフトウェア上で、NetFlow テーブルへの入力を制限せずに NetFlow サンプリングを行っていました。サンプリングの概念は限られたリソースで NetFlow テーブルの利用をより効率化することであるため、PFC3 ベースのスーパーバイザの機能では必要な効率性を提供することができませんでした。

図 7 と 8 に、PFC3 ベースのスーパーバイザでのサンプリングとの違いを示します。

図 7 PFC3 ベースのスーパーバイザでの NetFlow サンプリング

図 7 PFC3 ベースのスーパーバイザでの NetFlow サンプリング


図 8 PFC4 ベースのスーパーバイザでの NetFlow サンプリング

図 8 PFC4 ベースのスーパーバイザでの NetFlow サンプリング


図 7 と 8 では、NetFlow テーブルの入力量に違いがあることに注意してください。PFC3 ベースのサンプリング方法では、サンプリングをオンにした場合でも NetFlow テーブルが一杯になる可能性がまだあります。CPU で NDE プロセスが行われるまで、サンプリングは実行されず、PFC3 によって NetFlow ルックアップが実行されフローが NetFlow テーブルに自動入力された後に実行されます。

Supervisor Engine 2T では、サンプリングが PFC4 による NetFlow のルックアップ時に行われ、サンプリングされた情報のみが NetFlow テーブルに自動入力されるようにします。Supervisor Engine 2T(12.2(50)SY)のコードの最初のバージョンでは、図 8 に示す 1/N サンプリングがサポートされます。これは、プール内のすべての N パケットから 1 パケットをサンプリングするようシステムを構成できることを意味します(図 8 では 1/5)。今後のバージョンでは、時間ベースのサンプリングと、全体のプール N から M パケットをサンプリングする M/N サンプリングができるようになる予定です。

Supervisor Engine 2T では、サンプリングの開始点がそれぞれの間隔内で変化する、ランダム方式のサンプリングがサポートされています。これは図 8 に示されています。

サンプリングを使用するのはどのような場合でしょうか。最もわかりやすい使用例は、システムによってサポートされている NetFlow エントリの数を大幅に超過している環境です。このような場合、サンプリングにより、より多様なデータを含んだ結果をプールできます。

注: サンプリング構成については、このホワイトペーパーの「Flexible NetFlow」の部分で説明します。

Flexible NetFlow


Supervisor Engine 2T により Cisco Catalyst 6500 シリーズ スイッチに Flexible NetFlow のサポートが導入されます。Flexible NetFlow は、複数の NetFlow アプリケーションを同時にトラッキングできる NetFlow アーキテクチャを提供します。たとえば、ユーザは、セキュリティ分析やトラフィック分析のために同時および個別の Flow Monitor を作成することができます。Cisco Catalyst 6500 シリーズ スイッチ用の前世代のスーパーバイザは、このレベルの柔軟性を提供することができませんでした。

Supervisor Engine 2T Flexible NetFlow は、フィールドの NetFlow バージョン 9 をサポートしており、フィールドの集合で構成されるテンプレートを使用します。テンプレートを使用することにより、次の利点がもたらされます。

  • 柔軟性:レコード形式の構造を変更せずに、新しいフィールドをテンプレートに追加することができる
  • 再利用性:コレクタはフィールドのセマンティックを理解できないため、構造情報によりフロー レコードを解釈できるようにする
  • 効率性:柔軟性の高いテンプレートにより、必須フィールドのみをフローから収集、およびエクスポートできる

Flexible NetFlow には、3 つの重要なコンポーネントがあります。

  • Flow Record
  • Flow Monitor
  • Flow Exporter

Flow Record

Flow Record は、NetFlow がトラックする、および Cisco IOS ソフトウェアで利用可能なユーザ定義または事前定義のスキームとなる可能性がある情報を定義します。各 Flow Record がキー フィールドおよび非キー フィールドとして定義されます。キー フィールドは match ステートメントを使用して定義され、値が変化するたびに NetFlow での新しいフロー エントリの作成をトリガーします。非キー フィールドは、collect ステートメントで定義され、キー フィールドによってインデックス化されたデータであり、新しいフロー エントリの作成には使用されません。表 2 に、Supervisor Engine 2T のコードの最初のバージョンでサポートされているキー フィールドおよび非キー フィールドを示します。

表 2 Flexible NetFlow のキー フィールドおよび非キー フィールドのサポート

フィールド名 キー フィールド名 キー フィールド名 キー
datalink vlan input flow direction ipv6 source address
ipv4 tos flow cts source group-tag ipv6 source prefix ×
ipv4 precedence flow cts destination group-tag ipv6 source mask ×
ipv4 protocol interface input (snmp) × ipv6 destination address
ipv4 source address interface output (snmp) × ipv6 destination prefix ×
ipv4 source prefix × routing destination as × ipv6 destination mask ×
ipv4 source mask × routing forwarding-status transport source-port
ipv4 destination address routing next-hop address ipv4 (bgp) transport tcp flags ×
ipv4 destination prefix × routing next-hop address ipv6 (bgp) counter Byte ×
ipv4 destination mask × routing source as × counter packet ×
ipv6 traffic-class routing vrf input timestamp sys-uptime first ×
ipv6 protocol transport destination-port timestamp sys-uptime last ×
input Interface output Interface input physical interface


Flexible NetFlow では、ユーザがフローを定義するキー フィールドおよび非キー フィールドを選択することができます。この機能は、ユーザに、従来の NetFlow を超える柔軟性、アグリゲーション、スケーラビリティを提供します。

Flow Monitor

Flow Monitor は本質的に NetFlow キャッシュです。Flow Monitor には 2 つの主要なコンポーネントである Flow Record と Flow Exporter があります。Flow Monitor は入力と出力の両方の情報をトラックできます。Flow Record には、NetFlow によって追跡される情報が含まれています(IP アドレス、ポート、プロトコルなど)。Flow Exporter は NetFlow エクスポートを記述します。

IPv4、IPv6、マルチキャスト、ユニキャスト、MPLS、およびブリッジド トラフィックのトラックに使用できます。複数の Flow Monitor を作成し、特定の物理インターフェイス、論理インターフェイスに接続できます。また、Flow Monitor には、必要に応じてパケット サンプリング情報を含めることができます。

Flow Exporter

Flow Exporter は、レポート サーバまたは NetFlow コレクタに送信される NetFlow エクスポートに関する情報を記述します。NetFlow Exporter には、レポート サーバ、Universal Datagram Protocol(UDP)や Stream Control Transmission Protocol(SCTP)などの転送のタイプ、エクスポート形式(たとえば、Version 9)の宛先アドレスが含まれます。Flow Monitor ごとに複数の Exporter を存在させることができ、エクスポートは QoS に対応しています。エクスポート ストリームは、サービスのクラスまたは DSCP 値に基づき、他のトラフィックによって優先度が設定されます。

Flexible NetFlow の重要なコンポーネントについておわかりいただけたところで、Supervisor Engine 2T を備えた Flexible NetFlow を構成する方法について説明します。

Supervisor Engine 2T で Flexible NetFlow を構成する最初のステップは、Flow Record を構成することです。図 9 に、「SAMPLE-FLOW」と呼ばれる Flow Record の構成を示します。

図 9 Flow Record の構成

図 9 Flow Record の構成


Flow Record にはキー フィールドと非キー フィールドが含まれることに注意してください。図 9 で、定義されているキー フィールドは次のとおりです。

  • ipv4 source address
  • ipv4 destination address
  • transport source-port
  • transport destination-port flow direction

定義されている非キー フィールドは次のとおりです。

  • counter bytes
  • counter packets
  • timestamp sys-uptime first
  • timestamp sys-uptime last

NetFlow テーブルでの新しいフローを定義するのはキー フィールドであることに注意してください。Flow Record の情報を表示するには、show flow record <name> コマンドを使用します。

Flow Record を構成したら、次に Flow Exporter を構成します。図 10 に、2 つの Flow Exporter の構成を示します。

図 10 Flow Exporter の構成

図 10 Flow Exporter の構成


仮想化インフラストラクチャが展開されている場合、異なる VRF 複数の Flow Exporter を異なる VRF の宛先で構成することができます。デフォルトでは、Flexible NetFlow は他のエクスポート形式が指定されていない場合は、NetFlow V9 エクスポート形式を使用します。Flow Exporter に関する情報を表示するには、show flow record <name> コマンドを使用します。Exporter に使用するテンプレートに関する情報を表示するには、show flow record <name> templates コマンドを使用します。このコマンドによって表示されたテーブルには、フィールド名やタイプ ID、レコードの開始からのオフセット、フィールド長などの詳細が表示されます。詳細については、RFC 3954 『Cisco Systems NetFlow Services Export Version』を参照してください。

Flow Record と Exporter を構成したら、次に Flow Monitor を構成します。図 11 に、「SAMPLE-MONITOR」と呼ばれる Flow Monitor の構成を示します。

図 11 Flow Monitor の構成

図 11 Flow Monitor の構成


Flexible NetFlow Flow Monitor は、NetFlow テーブルに格納された情報を示します。Flow Monitor には、NetFlow テーブル内のキーフィールドおよび非キー フィールドを含む Flow Record があります。また、Flow Monitor の一部である Flow Exporter には、NetFlow コレクタの宛先アドレスを持つ NetFlow 情報のエクスポートに関する情報が含まれます。Flow Monitor には、エクスポートのタイマー、キャッシュのサイズ、パケット サンプリング レートなど、さまざまな特徴があります。Flow Monitor に関する情報を表示するには、show flow monitor <name> コマンドを使用します。

最後に、Flexible NetFlow が Flow Monitor をインターフェイスに適用するように構成します。図 12 に、Flow Monitor を適用したインターフェイス構成を示します。

図 12 Flexible NetFlow のインターフェイス構成

図 12 Flexible NetFlow のインターフェイス構成


インターフェイス上では、同じ Flow Monitor をいずれかの方向、双方向に同時に適用することができます。キーワード「input」は Ingress NetFlow、キーワード「output」は Egress NetFlow を指定します。モニタのキーフィールドがオーバーラップしない限り、異なる方向の異なるモニタを同じインターフェイス上でサポートすることができます。

ここまで Flexible NetFlow とその構成方法について見てきましたが、このテクノロジーの 2 つの使用例である Application Tracking と Security Detection について説明します。Flexible NetFlow では、従来の NetFlow とは異なり、ユーザが特定のネットワーク情報をカスタマイズし、フォーカスすることができます。NetFlow 分析のスケーラビリティが最適化され、Flexible NetFlow は組織の重要な情報をトラッキングする機会を提供します。特定の情報を対象とすることにより、情報量およびエクスポートされるフローの数が削減され、強化されたスケーラビリティおよびアグリゲーションが実現します。

たとえば、ユーザが TCP アプリケーション分析に関心を持っている場合、ユーザは NetFlow フィールドの送信元および宛先 IP アドレス、TCP 送信元、宛先ポートのトラッキングを構成します。この情報は、各アプリケーション ポート上でトラフィックを送信および受信しているユーザを効率的に示します。

従来の NetFlow では、フローの作成にパケット情報が使用されていました。しかし、この情報は固定されており、ユーザが構成することはできません。さらに、集約を行った場合は情報の一部が失われます。一方、Flexible NetFlow では、ユーザは実際に複数の情報を追跡し、ネットワーク内のすべてのフロー情報が効率的にキャプチャされていることが確認できます。前述の例では、アプリケーションの使用状況をトラックするために使用している NetFlow フィールドは 4 つのみですが、従来の NetFlow では 7 つのフィールドが必要でした。従来の NetFlow では、ユーザは 7 つのキー フィールドを追跡する必要があり、しかも、追跡するトラックが増えればそれだけフロー数も増加していました。

セキュリティ分析の場合、Flexible NetFlow は IPv4 ヘッダーのすべてを追跡し、この情報をフローに特徴付ける機能を備えた優れた攻撃検出ツールです。侵入検知と防御システムが NetFlow データをリッスンし、ネットワーク上で問題を見つけると、特定の情報をトラックするように構成された仮想バケットまたは仮想キャッシュを作成し、攻撃パターンやワーム伝播の詳細を取得することが期待されます。Flexible NetFlow は、特定の情報と入力フィルタリング(すべてのフローを特定の宛先にフィルタリングするなど)を組み合わせてキャッシュをすばやく作成できるため、現行のフローのテクノロジーよりも優れたセキュリティ検知ツールとなり得ます。ワーム ターゲットの検出およびワーム伝播などの一般的な攻撃は、Flexible NetFlow でトラックすることが期待されます。

同期(SYN)フラッド攻撃などの、宛先サーバへの TCP の確立リクエストをフラッディングするために TCP フラグが使用されている、一般的な攻撃について説明します。攻撃デバイスは、TCP SYN のストリームを特定の宛先アドレスに送信しますが、TCP 3 方式のハンドシェイクの一部としてサーバ SYN-ACK に応答する確認通知(ACK)を送信しません。セキュリティ モニタリングに必要なフロー情報では、宛先アドレスかサブネット、TCP フラグ、およびパケット カウントの 3 つの重要なフィールドが必須です。セキュリティ デバイスは一般的な NetFlow 情報を監視し、このデータが特定の攻撃の詳細ビューをトリガーします。詳細な Flow Monitor には、NetFlow テーブルに表示するトラフィックを制限する入力フィルタに加え、TCP ベースの攻撃を診断する特定情報のトラッキングが含まれます。この場合、ユーザはすべてのフロー情報をサーバの宛先アドレスやサブネットをフィルタリングし、セキュリティ サーバが評価に必要な情報の量を制限することができます。Security Detection サーバがこの攻撃を理解できると判断すると、ペイロード情報またはパケットのセクションをエクスポートしてパケット内の署名を詳しく確認するために、別の仮想キャッシュやバケットがプログラムされます。

Yielding NetFlow データ エクスポート


Supervisor Engine 2T で導入された新しい機能に、Yielding NetFlow データ エクスポート(Yielding NDE)があります。これにより、ユーザは NetFlow レコードがコレクタにエクスポートされる時に NetFlow Data Export 処理によって使用される CPU を制御することができます。NetFlow 統計収集はハードウェアで実行され、転送のパフォーマンスには影響を及ぼさないことに注意してください。NDE 処理は、PFC4 上の CPU によって、またはラインカードが NDE をサポートしている場合はラインカードの CPU によって実行されます(この機能をサポートするラインカードについては、このホワイト ペーパーのセクション「NetFlow の概要」を参照してください)。図 13 に、NDE プロセスを示します。

図 13 NDE プロセス

図 13 NDE プロセス


DFC4 を備えているが、ダイレクト NDE を実行できないモジュールでは、NetFlow データが Ethernet Out of Band Channel(EOBC)経由でスーパーバイザに送信されます(ダイレクト NDE をサポートしているモジュールについては、セクション「NetFlow の概要」を参照してください)。EOBC は、スーパーバイザによって使用される通信チャネルであり、定期的なヘルス チェックを実行、フォワーディング テーブルの更新の受信、NetFlow データの受信および他のタスクの実行を行うためにすべてのラインカードと通信を行います。ここで重要なのは、このチャネルは通常のデータパスの一部ではないため、NDE 情報は、もしデータ輻輳が発生したとしてもその影響を受けないということです。

システムによって収集可能な NetFlow データの量は、Supervisor Engine 2T によって大幅に増加するため、NDE プロセスを制御するメカニズムを実装し、CPU が実行する他のタスクに影響を与えないようにすることが重要です。CPU は、レイヤ 3 およびレイヤ 2 プロトコル、システムの管理、SNMP のポーリングの提供を処理し、システム構成に使用できる必要があります。Yielding NDE 機能は、非常に大規模な NDE 要件のイベントにおけるこれらの他のタスクで CPU リソースが常に使用可能にすることを保証するために作成されました。

Yielding NDE 機能により、ユーザは Supervisor Engine 2T やラインカードによって使用される CPU の上限を指定することができます。この制限を超えると、NetFlow データ エクスポート プロセスは、NDE を低減さらにはカットオフすることによって、エクスポート処理を停止または一時停止します。CPU 使用率が低減すると、NDE は徐々に通常のレベルに戻ります。図 14 に、Yielding NDE の動作を図示します。

図 14 Yielding NDE の動作

図 14 Yielding NDE の動作


この例では、flow hardware export threshold 70 コマンドを使用して Yielding NDE のしきい値が CPU 使用率 70% に設定されています。NDE プロセスが実行されると、システムは現在の CPU 使用率と構成された NDE しきい値に基づいて、エクスポート レートをどの程度向上できるかを計算します。たいていは、システムはしきい値に近い値になるまで、1 秒あたり 500 エントリのレートで向上します。しきい値を超えると、レートはすぐに低下します。システムは 5 秒間レートを変更しませんが、CPU 使用率が NDE しきい値の 10% 内でない限り、レートの向上を再開します。しきい値に達しない場合、システムは NDE プロセスが完了するまでレートをステップアップし続けます。

Yielding NDE 機能は、ダイレクト NDE をサポートするラインカードにも適用することができます。ラインカード上の Yielding NDE しきい値を設定するには、flow hardware export threshold <25-90> linecard <25-90> コマンドを使用します。機能は、ステップ ダウンした後、レートを向上させるかどうかを判断する際、CPU 使用率がラインカード NDE しきい値の 25% でない限りレートを向上させる点を除き、スーパーバイザ上での CPU の動作と同じです。

Supervisor Engine 2T によって導入された Yielding NDE 機能により、ユーザは NDE プロセスが他のプロセスの CPU リソースを停止するしきい値を設定することができます。これは、レイヤ 2 プロトコル、レイヤ 3 プロトコル、または他のシステムの管理プロセスなどの NDE プロセスが他の機能を受けないようにするために役立ちます。

NetFlow と Embedded Event Manager(EEM)


Cisco IOS® Embedded Event Manager(EEM)は、Cisco IOS ソフトウェア内の固有のサブシステムです。この強力で柔軟なツールは、タスクを自動化し、Cisco IOS ソフトウェアの動作とデバイスの動作をカスタマイズします。お客様は EEM を使用して、ルータまたはスイッチ上でプログラムやスクリプトを直接作成することができます。スクリプトは EEM ポリシーと呼ばれ、簡易 CLI ベースのインターフェイスを使用したり、Tool Command Language(TCL)と呼ばれるスクリプト言語を使用してプログラミングできます。EEM により、お客様は Cisco IOS ソフトウェアによって検出された条件に基づいて、リアルタイム イベントへの応答、タスクの自動化、カスタム コマンドの作成、およびローカル自動アクションを行うように Cisco IOS ソフトウェア内の高度なインテリジェンスを活用できます。

Cisco IOS EEM は、一連の Event Detector、EEM Server、およびインターフェイスで構成される、製品に依存しないソフトウェア機能で、ポリシーと呼ばれるアクション ルーチンを起動できるようにします。また、EEM サブシステムを活用するための、他の Cisco IOS サブシステムの内部アプリケーション プログラミング インターフェイスも用意されています。図 15 に、EEM コンポーネントを図示します。

図 15 EEM アーキテクチャ

図 15 EEM アーキテクチャ


EEM ポリシーには 2 つのタイプがあることに注意してください。

  • アプレット ポリシー:構成 CLI を使用して定義される使いやすいインターフェイス
  • TCL ポリシー:TCL プログラミング言語を使用して定義される、より柔軟性が高く、豊富な機能です。

1 つ以上のポリシーが定義されると、各ポリシーによって定義された条件と一致する条件を Event Detector ソフトウェアが監視します。条件が発生すると、イベントが Event Manager サーバに渡されます。サーバは、その特定のイベントに登録されたポリシーを呼び出します。その後、ポリシーで定義されたアクションが実行されます。

Supervisor Engine 2T には、Cisco Catalyst 6500 シリーズ スイッチ用のいくつかの新しい EEM Event Detector が導入されています。1 つは、Flexible NetFlow Event Detector で、特定の基準に合致するフローの検出に基づいてポリシーをトリガーします。これには、特定の宛先 IP アドレスとポート番号で新しいフローが見つかった場合、または定義されたいくつかのしきい値を新しいフロー エントリのレートが超えた場合が含まれます。これにより、リアルタイムなネットワーク アクティビティを検出して対応するトリガーの強力なセットが提供されます。表 3 に、EEM スクリプトのトリガーに使用できる NetFlow フィールドの一覧を示します。

表 3 EEM のトリガーに使用される NetFlow フィールド

フィールド
Counter Bytes、Packets
Datalink Dot1Q、MAC
Flow Direction、Sampler
Interface Input、Output
IPv4 Field-Type
IPv6 Field-Type
Routing Routing-attribute
Timestamp Sysuptime First、Last
Transport Field-Type


Flexible NetFlow と EEM がどのようにやり取りできるのかがわかったところで、使用例をいくつか見ていきましょう。図 16 と 17 に、これらの 2 つの機能が連携して不正なパケットや異常なトラフィックをチェックする方法を示します。

図 16 EEM と FNF による不正なパケットの検出

図 16 EEM と FNF による不正なパケットの検出
※画像をクリックすると、大きな画面で表示されますpopup_icon


図 17 EEM と FNF による異常なトラフィックからの保護

図 17 EEM と FNF による異常なトラフィックからの保護
※画像をクリックすると、大きな画面で表示されますpopup_icon


図 16 は、TTL=0 パケットが NetFlow で検出されるとトリガーされるように構成されている Flexible NetFlow Event Detector を示しています。このパケットが検出されると、このようなフロー レコードが検出されたことをネットワーク運用チームに通知する Syslog メッセージが生成されます。

図 17 は、インターフェイスでフロー レートが 1Mbps を超えるとトリガーされるように構成されている Flexible NetFlow Event Detector を示します。この場合は、ユーザが問題となっているインターフェイスをシャットダウンし、そのアクションのネットワーク運用チームに通知する Syslog メッセージを生成することを選択しています。

EEM と Flexible NetFlow の機能を組み合わせることにより、Cisco Catalyst 6500 シリーズ スイッチの Supervisor Engine 2T は、ユーザがネットワークの監視、保護、管理を行うことができる強力なツールを提供します。

まとめ


Supervisor Engine 2T には複数の新しい NetFlow 機能が採用されており、Cisco Catalyst 6500 シリーズ スイッチの NetFlow ポートフォリオを飛躍的に強化します。

  • 向上した NetFlow リソースのスケーラビリティは、前世代よりも大きい NetFlow 容量が必要な組織にとってメリットがある
  • Egress NetFlow、Sampled NetFlow、および Flexible NetFlow など、より柔軟な情報収集機能によって、収集する情報および収集する場所を決定する多数のオプションが組織に提供される
  • EEM との統合により、ネットワークの管理の自動化するより優れた方法がネットワーク運用グループに提供される

これらすべての強化により、Supervisor Engine 2T ベースのシステムは、環境に展開されている多様化したネットワークを監視、管理、保護する最新の NetFlow の活用を望んでいる組織にとって最適です。

付録 A:Supervisor Engine 2T と Supervisor Engine 720 の比較


次の表では、Supervisor Engine 2T と Supervisor Engine 720 の NetFlow 機能を比較しています。

機能 Supervisor 720-10G-3C/3CXL Supervisor 2T/2TXL
NetFlow テーブル サイズ 128K/256K 512K/1M
NetFlow ハッシュ効率 90% 99%
最大フロー エントリ(6513-E) 3,328M 13M
Egress NetFlow ×
Sampled NetFlow ○(ソフトウェア) ○(ハードウェア)
Flexible NetFlow ×
TCP フラグ ×
Yielding NDE ×
EEM の統合 ×