Scrutinizer
NetFlow機能を利用する事により、ネットワーク上を通過するトラフィックフロー情報を受動的にモニターリングすることができます。
プロトコルについて
他のベンダーでは違う名前でCiscoのルータに似たような機能を提供しています。
・Jflow or cflowd for Juniper Networks
・NetStream for 3Com/H3C
・NetStream for Huawei Technology
・Cflowd for Alcatel-Lucent
ネットフローとIPFIX
初めはCiscoによって実行されていましたが、ネットフローはＩＥＴＥスタンダード（インターネットプロトコルフロー情報エクスポート（ＩＰＦＩＸ）として浮上しています。 ネットフローバージョン9実行に基づくと、ＩＰＦＩＸはRFC5101, RFC5102などの商業スタンダードです。 ネットフローインフラベンダーはデバイスにIPFIXサポートをすでに加えています。
ネットワークフロー
ネットワークフローは様々な方法で決められます。伝統的なCisco規定は７つの要素から成るキーを使用します。
このキーは次の７つのデータの全てを共有するパケットの単一性シークエンスとしてフローが定義されるところにあります。
１．送信元IPアドレス
２．宛先(送信先) IPアドレス
３．TCP/UDP送信元ポート番号
４．TCP/UDP宛元ポート番号
５．レイヤー3プロトコル
６．ToSバイト (DSCP)
７．入力インターフェイス
フレキシブルネットフローとＩＰＦＩＸはユーザー定義フローキーをサポートしています。
ルータはフローが終了したことを認識するとフローレコードを出力します。これはフローの老朽化によるものです。
既存フローの新しいトラフィックをルータが見ると、エイジングカウンターをリセットします。
また、TCPフロー内のTCPフローセッション終了はルータがフローを失効する原因となります。
ルータはたとえフローが継続していても一定のインターバルでフローレコードを出力するよう設定することもできます。
フレキシブルネットフロー（ＦＮＦ）で管理者は実際にルータのフロープロパティを定義することができます。
ネットフローレコード
ネットフローレコードは与えられたフローのトラフィックについての幅広い情報を含むことが可能です。
ネットフローバージョン5（バージョン９の次に一般的に使われているうちの一つ）は次のものを含みます。
・バージョンナンバー
・シークエンス（連続）ナンバー
・SNMP (ifIndex in IF-MIB)が使用しているインタフェースインデクスのインプットとアウトプット.
・最後の起動からミリセカンド後（1/1000秒）後、フローのスタートと終了の時間を記録
・フローで測定されるバイトとパケットの数
・レイヤ 3 headers:
*ソース & 送信先IP アドレス
*ソース＆送信先ポートナンバー
*IPプロトコル
*サービス (ToS) データのタイプ
・TCP フローの場合, 全TCPフラグの結合はフローの寿命を調査
・Layer 3 Routing 情報:
*送信先へのルートに沿った緊急next-hop(BGP nexthop ではない)のIP アドレス
*ソース & 送信先 IP マスク (CIDR記録のプレフィックス)
ルータにはソースと送信先Autonomous System (AS) ナンバーがあるものもあります。
ルータの設定によって、緊急直近ASになることも可能です。
その情報はいつも正しいわけではなく、ローカルASは知られていないASとして同じデータ（0）で表示されます。
ネットフローバージョン9はこれら全てのフィールドを含むことができ、Multiprotocol Label Switching (MPLS) labelsやIPv6アドレスとポートのような追加情報を入れることもできます。
フローデータを分析することでネットワーク内のトラフィックフローとトラフィックボリュームの図面を構築することができます。
ネットフローレコードフォーマットは長い間発展してきているのでバージョンナンバーを含んでいます。
Ciscoは様々なバージョンのナンバー詳細や各バージョンのパケットレイアウトを保存しています。
ネットフローレコードは、より新しいソフトウェアのUDPやSCTPを通して通常は送られます。この理由で、ルータはエクスポートされた後すぐにはフローレコードを保存しません。そのため、もしネットフローレコードはネットワーク混雑のため削除されてしまい、二度と戻すことはできません。ルータがこれを再送信する方法はありません。（UDPネットフローのみ訂正されます）。ネットフローコレクターのIPアドレスとリスニングのポートは送信ルータに設定されなければなりませんが、通常は2055,9555か9995のどちらかです。ネットフローもルータのCPUの不必要な負担を避けるためにインタフェースベースごとに有効にされています。ネットフローは一般的には有効なインタフェースへのパケットインプットを基礎としています。これはルータが二重にカウントしたり保存したりするのを避けるためです。
そしてルータが破棄されたパケットのネットフローレコードをエクスポートできるようにもします。
ICMPレコードは送信ポートナンバーフィールドをICMPタイプとHEXのCODEを見分けるために使っています。
そのタイプとコードは通信の前に連結されます。ICMP不着メッセージはCODE01（301）でのTYPE3となります。
ネットフローはエクスポート時にこのデータを769のhexバリューに変換します。
サンプルネットフロー
この変形はもともとCiscoによって導入されましたがネットフローを実行している全てのhigh-end ルータに今使われています。 ネットフローデータを保存することは、ルータやルータのCPU負荷かキャパシィティが不足しているポイントへのハードウェアには高価です。 ルータのCPU負荷で引き起こる問題を回避するために、Ciscoは'サンプルネットフロー'を提供しています。 ネットフローレコードを保存するために全てのパケットを見るよりも、ルータはｎが認識される（CiscoのGSRｓに使用されているDeterministic ネットフローなどで）nthパケットを見ています。 ランダムに（他の全てのCiscoプラットフォームに使われているランダムサンプルネットフロー）インターバルを選んでいます。 サンプリングは全てのインタフェースで普通は同じですが、ルータのインタフェースごとに調整されます。 サンプルネットフローが使われる時、ネットフローレコードはサンプリング効果（トラフィックボリューム）に調整する必要があります。 トラフィックボリュームは特に現在、フローボリュームを実際に測るよりも推量に使われています。 サンプリング率はネットフローバージョン5（全インタフェースで同じサンプリング率）のヘッダーフィールドに表示されるかネットフローバージョン9（インタフェースごとのアンプリング率）の追加レコードに表示されます。
Ciscoのネットフローセキュリティイベントログ
CiscoASA5580製品の登場を紹介すると、ネットフローセキュリティイベントログはよい環境の中でセキュリティテレメトリーを効果的に送信するためにネットフローｖ9とテンプレートを使用しています。 同じレベルでのログイベントの中のセキュリティスキャン粒度や詳細を提供している間は、ネットフローセキュリティイベントログスケールはsyslogよりも優れたものです。
スタンドアロン Probesによるネットフロー監視
頻繁に使われていますが、ルータベースのアプローチはいくつかの制限があります。
・ソフトウェアベースのルータ（例Cisco7200）のネットフロー監視を有効にすることは、ルーティングパフ
ォーマンスを減らす可能性があります。
・内臓ハードウェア（CiscoのものやAlcatel/Lucent high-end routersのようなもの）や専用ハードウェア
（Juniper or Huawei high-end routersの）を使っている時でさえ、サポートパケット/秒かフロー/秒の
数は使用できるプロセスパワーやメモリー（フローcacheのためのもの）によって制限され、典型的なイ
ンターネットバックボーントラフィックのみのサンプリング命令を作成します。
・サンプルもしくはフロープロセス制限のせいで、提供される統計はビリング（測量ボリューム下の）やセ
キュリティーアプリケーション（多くのスモールパケットを処理する必要がある時のネットフロー不正確
性）にとって信頼できるのもではなくなります。
・ルータは配列を固定しているので、レイヤ3visibilityが攻撃の対象となってしまいます。
そのため、スタンドアロンネットフローprobeを使用しているネットフロー監視の新しいアプローチが大変人気になっていています。
このアプローチはルータベースのネットフロー監視のいくつかの制限を打開します。probeはTAPかSPANポート機器を使用している受信アプライアンスとして監視リンクに透過的に（ユーザが気付くことなく）接続されます。
ネットフローprobeはネットフローエクスポートのための専用リンクを使用しているので、それらは完全に監視リンクには見えないようになっています。
さらに、Deepパケット検査はルータ内よりも専用plobe内で実行する方が簡単です。
そして、ルータが提供するのに苦労する、もしくは、同じ価格ではできないパケットについての詳細をレポートするのにネットフローが使用されます。
しかしこのアプローチはいくつかの欠点があります。
・probeはセットアップやコストメンテナンスの原因の追加ハードウェア調査の必要がある全てのリンクに
配置される必要があります。
・probeはルータがするようなインプット・アウトプットインタフェース情報を分けてレポートしません。
・probeはAS NumberやIPマークのようなルーティングに関連したネットフローフィールドのレポートには
確実性がない場合があります。なぜなら、ルータと全く同じルーティング情報を使わないからです。
そのため、専門probeのネットフローは犯罪リンク観測に対応しています。一方でルータのネットフローはとても正確なトラフィックネットワークワイドビューを提供します。実際にはトラフィック観測とネットワーク計画に対してです。
バージョン
| バージョン | 説明 |
|---|---|
| 1 | 初期のバージョン、今では旧式、IPv4（IPmask とAS Numberなし）に限定 |
| 2 | Cisco内部バージョン、発売なし |
| 3 | Cisco内部バージョン、発売なし |
| 4 | Cisco内部バージョン、発売なし |
| 5 | 最も一般的なバージョン、異なるブランドの多くのルータで使用可能（2011年現在）。 ただし、IPv4に限定 |
| 6 | Ciscoからのサポート終了、カプセル化情報 |
| 7 | ソースルータフィールドでのバージョン5のようなもの。Cisco Catalystスイッチで使用される |
| 8 | 集合フォーム、バージョン5レコードですでに提供のあった情報のみ |
| 9 | テンプレートベース、現在のルータいくつかで使用可能（2009年現在）。多くはIPv6, MPLS, や even plain IPv4 with BGP nexthopのようなフローをレポートするのに使用されます。 |
| IPFIX（v10） | エンタープライズ-確定フィールドタイプのような拡張付きIETF標準化ネットフローv9と変数レングスフィールド |
参照
・IP Flow Information Export (IPFIX) - IETF はNetFlow version 9に基づくフローエクスポートをスタンダード化するために機能しています。 ・sFlow - ネットフローの代替(義務的なサンプリング, フローキャッシュメモリ・テンプレートなし)