Scrutinizer

NetFlowとは?

NetFlowとは、1996年にシスコシステムズによって開発された、IPトラフィック情報を収集するためのネットワーク・プロトコルです。
NetFlowは、トラフィック監視の業界基準となり、様々なプラットフォームで使用されています。

プロトコルについて

NetFlowとはNetFlow機能を持つルータやスイッチは、NetFlowを有効にした全てのインタフェイスのIPトラフィック統計を収集し、NetFlow情報としてエクスポートすることができます。 少なくともNetFlowコレクターは、実際にトラフィック解析をする為の典型的なサーバとなります。

ネットワークフロー

ネットワークフローは様々な方法で定義されます。Cisco基準のNetFlowバージョン5では、フローについて次の7つの要素(フローキー)を全て共有するパケットの一方向シーケンスとして定義しています。

1. 入力インタフェイス (SNMP ifIndex)
2. 送信元 IPアドレス
3. 宛先(送信先) IPアドレス
4. IPプロトコル(レイヤー3プロトコル)
5. 送信元UDP/TCPポート番号、 (0は、他のプロトコル)
6. 宛先(送信先) UDP/TCPポート番号、 (ICMPタイプ/コード、 または0は、他のプロトコル)
7. IP ToS(DSCP)

エグレスインタフェース、IPネクストホップ、または BGPネクストホップ(フローキー)が全て同一の場合は、同一のキーとして認識されます。キーの一部が、フロー終了前にルートを変更、または、負荷バランスがパケット毎に完了すると、別のフローとして認識されて異なるフローキーとして作成されます。
このフロー定義は、IPv6でも使用され、また類似する定義は、MPLSやイーサネットフローでも使用されています。
詳細なNetFlow、またはCisco Flexible NetFlowのようなIPFIX実装は、ユーザ定義のフローのキーを許可します。

NetFlowレコードのエクスポート

ルータは、通信が終了したことを認識すると、フローレコードを出力します。
これはフローの期限切れによるものです。
ルータが既存フローでの新しいトラフィックを確認すると、エイジングカウンターをリセットします。また、TCPフロー内の終了は、ルータがフローを失効する原因となります。
たとえフローが継続していても、ルータが一定のインターバルでフローレコードを出力するように設定することも可能です。

エクスポートするタイミングは以下の4つがあります。
・TCPのRSTまたはFINを検出してTCPセッションが終了したとき(通常の通信終了時)
・インアクティブタイマーが設定時間を経過したとき(デフォルト値:15秒)
・アクティブタイマーが設定時間を経過したとき(デフォルト値:30分)
・NetFlowのキャッシュテーブルが一杯になったとき

NetFlowパケットトランスポートプロトコル

一般的には、NetFlowレコードをユーザデータグラムプロトコル (UDP)で出力、またはNetFlowコレクターで収集していました。
NetFlowコレクターのIPアドレスと宛先(送信先) UDPポートは、送信元ルータ上で設定する必要があります。
一般的には、UDPポート2055ですが、9555や9995、9025、9026のような他のポートを使用する場合があります。

効率的な理由から、通常、ルータは、 既にエクスポートされたフローレコードのトラックを保持しないのNetFlowパケットがネットワーク遅延やパケット破損により中断されると、全てのフローレコードは二度と戻りません。

UDPプロトコル は、データが破損した場合、パケットを再送信しません。
このことは、特に多くのパケットや、シングルレコードへのフローを収集することができるNetFlow v8または、v9では、大きな問題となります。シングルUDPパケットロスは、いくつかのフロー統計に大きな影響を及ぼします。

そのため、現在のNetFlow実装は、パケットロスを制御するために、パケットエクスポートには、ストリーム制御転送プロトコル(SCTP) を使用します。
また、NetFlow v9のテンプレートは、関連するレコードがエクスポートされる前に受信されます。TCPは、正確なパケット指令が過度のバッファリングや遅延を起こすので、NetFlowには、適していません。

SCTPの問題は、SCTPが各NetFlowコレクターと各NetFlowをエクスポートしているルータ間の相互作用を要することです。
もし、ルータが多くのNetFlowコレクターに対応しなければならない、または、故障やメンテナンスのために使用できないルータに、NetFlowコレクターが対応せざるを得ない場合には、パフォーマンスに限界が生じるでしょう。

NetFlowをいくつかの独立したコレクターにエクスポートしなければならない場合、それらは、いつダウンするかもわからないテストサーバである可能性もあるので、SCTPは適さないでしょう。
UDPでは、単純なNetFlowパケットの反復にネットワークタップやL2/L3を使用することが可能です。
シンプルなステイトレス機器は、必要に応じて、フィルタし、UDPパケットの宛先(送信先)アドレスを変更することもできます。

NetFlowエクスポートは、おおよそ基幹ネットワークリンクのみを使用するので、パケットロスは、ほとんど起こりません。もし発生した場合は、おそらく、ネットワークとNetFlowコレクター間のリンク上の問題となります。

NetFlowパケットヘッダー

バージョン依存のヘッダーがある全てのNetFlowパケットは、少なくとも以下のものを含みます。

 ●バージョンナンバー(v5、 v8、 v9、 v10)
 ●ロスやダブリを見つけるシークエンスナンバー
 ●システム動作可能時間や絶対時間のようなエクスポート時のタイムスタンプ
 ●レコードナンバー (v5 or v8) 、または、テンプレートリストとレコード(v9)

NetFlowレコード

NetFlowレコードは、与えられたフロー内のトラフィックに関する幅広い情報を含むことが可能です。
NetFlowバージョン 5 (バージョン9の次に一般的に使われているバージョンのうちの一つ)は、
次のものを含みます。

 ●SNMP (IF-MIB 内のifIndex)で使用している入力インタフェースインデックス
 ●出力インタフェースインデックス、または、パケットが溢れた際には0(ゼロ)
 ●最後の起動から1/1000秒後に、フローの開始/終了時間のタイムスタンプ
 ●フローで測定されるバイトとパケット数
 ● Layer 3ヘッダー:
  -発信元と宛先(送信先) IPアドレス
  -発信元と宛先(送信先) TCP/UDP/SCTPポート番号
  -ICMP タイプとコード
  -IPプロトコル
  -Type of Service (ToS) の値
 ●TCPフローの場合は、全てのTCPフラグの結合は、フローの期限をチェック
 ● Layer 3 ルーティング情報:
  - 宛先(送信先)へのルートに沿った緊急ネクストホップ (BGP ネクストホップではない)IPアドレス
  -発信元と宛先(送信先) IPマスク (CIDR記録のプレフィックス範囲)

ICMPフローの場合、発信元ポートはゼロ、および、宛先(送信先)ポート番号フィールドコード ICMPメッセージタイプとコード (ポート= ICMPタイプ * 256 + ICMP-コード)となります。

発信元と宛先(送信先) 自律システム (AS) ナンバーフィールドは、ルータ設定によって、宛先(送信先) AS (ASパスの最後のAS)、またはすぐ隣のAS(ASパスの最初のAS)をレポートすることができます。
しかし、AS機能がサポートされていない、ルートが不明、もしくはBGPによる案内がない、またはローカルASの場合には、ASナンバーは、ゼロと表示されます。
それらを見分ける明白な方法はありません。
NetFlowバージョン9 は、それらのフィールドをすべて含むことができ、マルチプロトコルラベルスイッチング (MPLS) ラベルとIPv6アドレス/ポートのような追加情報も追加可能です。

フローデータを分析することにより、ネットワーク内のトラフィックフローの図面やトラフィック量を可視化することができます。
NetFlowレコードフォーマットは、バージョンナンバーを含んでいるので、時間とともに進展しています。
Ciscoは、異なるバージョンナンバーの詳細や各バージョンのパケットレイアウトを保存しています。

NetFlowインターフェイス

NetFlowは、通常、NetFlowを含むルータ構成の負荷やエクスポートされたNetFlowレコードの量を制限するために、インターフェイス毎に有効にします。

NetFlowは、通常、イングレスIPアドレスによって受信した全てのパケットをキャプチャしますが、パケットがNetFlowによって、監視可能な場合には、いくつかのNetFlow実装には、IPフィルタを使用します。
いくつかのNetFlow実装は、エグレスIPインターフェイス上でパケット監視も可能です。

しかし、使用時は注意が必要となります。
NetFlowが有効な任意のイングレスインターフェイスから、NetFlowが有効な任意のインターフェイスへの全フローは、2重でカウントされてしまいます。

その為、フローコレクターによっては、実際の通信量よりも多い値を表示してしまう場合があります。

NetFlowサンプリング

通常のNetFlowは、インターフェイス上で全てのIPパケットを処理するように設計されていました。

しかし、いくつかの環境、例えば、インターネットの基幹ルータでは、各パケットや同時発生する大量なフロー毎に追加処理を必要とされるため、ルータのCPU負荷やNDE量が膨大なものになります。

そのため、Ciscoは、Cisco12000上でサンプリングしたNetFlowを導入しました。
そして、それは今ではNetFlowを実装している全ての高性能ルータで使用されています。

ルータ設定によりn (サンプル率)が決まる場合、nからの一つの送信パケットのみが処理されます。
正確な選択プロセスは、実装によります。

 ●Cisco12000で使用されているnパケット(確定的なNetFlow)毎の1パケット
 ●現在のCiscoルータで使用されている任意選択されたnパケット(ランダムサンプルのNetFlow)間隔の1パケット Cisco Catalystsでのフロー毎のサンプリングのような、いくつかの実装では、パケットサンプル方法がより複雑になります。

全てのインターフェイスにおいて、サンプル率は通常同じですが、ルータのインターフェイス毎に変更することができます。
NetFlowサンプリングが使用されているときには、NetFlowレコードは、サンプリング効果に応じてNetFlowレコードを調節しなければなりません。
特に現在、トラフィック量は、実際に測定したフロー量よりも推量として使用されています。
サンプリング率は、NetFlowバージョン5 (全インターフェイスで同じサンプリング率)のヘッダーフィールド、もしくはNetFlowバージョン9 (インターフェイス毎のサンプリング率)のオプションレコード内に表示されます。

バージョン


バージョン
説明
1
初期のバージョン、今では旧式、IPv4(IPmask とAS Numberなし)に限定
2
Cisco内部バージョン、発売なし
3
Cisco内部バージョン、発売なし
4
Cisco内部バージョン、発売なし
5
最も一般的なバージョン、異なるブランドの多くのルータで使用可能(2011年現在)。
ただし、IPv4に限定
6
Ciscoからのサポート終了、カプセル化情報
7
バージョン 5とほぼ同一だが、ソースルータフィールド(TCPフラグ,ToS情報)は含まない。
Cisco Catalyst スイッチ 6500、Cisco 7600 のみで使用
8
集合フォーム、 但し、バージョン 5 レコードで既にあった情報のみ(リソースの有効活用のため)
9
テンプレートベース、 現在のいくつかのルータで使用(2009年現在)、 多くは、IPv6、 MPLS、マルチキャスト、BGPネクストホップのあるIPv4のようなフローをレポートするのに使用
IPFIX(v10)
別名IPFIX、 エンタープライズ確定フィールドタイプのようないくつかの拡張つきIETF標準化NetFlow 9と変数レングス フィールドから構成される


NetFlowとIPFIX

NetFlowは、当初Ciscoによって実装され、その後RFC 3954(CiscoシステムズNetFlowサービスエクスポートバージョン9)に記述されました。

NetFlowプロトコル自身は、インターネットプロトコルフロー情報エクスポート(IPFIX)にその座を奪われました。NetFlowバージョン 9の実装に基づくと、IPFIXは、2008年に出版された RFC 5101、 RFC 5102等のあるIETFスタンダード トラック(標準化過程)です。

参照

 ●IP Flow Information Export (IPFIX) - IETF はNetFlow version 9に基づくフローエクスポートをスタンダード化
 するために機能しています。
 ●sFlow - ネットフローの代替(義務的なサンプリング, フローキャッシュメモリ・テンプレートなし)


NetFlowと類似したもの

Cisco以外のベンダーは、ベンダー毎のルータやスイッチでNetFlowと同等の技術を提供しています。
しかしNetFlowは、Ciscoの商標だと考えられているので、その技術には別の名称が使われることがあります。
(実際には、2012年3月よりCiscoの商標リストから外れています。)

 ●Jflow または cflowd / Juniper Networks
 ●NetStream / 3Com/HP
 ●NetStream / Huawei Technologies
 ●Cflowd / Alcatel-Lucent
 ●Rflow / Ericsson
 ●AppFlow Citrix
 ●sFlow は以下のベンダーに含まれます。
  Alaxala、 Alcatel Lucent、 Allied Telesis、 Arista Networks、 Brocade、 Cisco、 Dell、 D-Link、 Enterasys、 Extreme、 Fortinet、 Hewlett-Packard、 Hitachi、 Huawei、 IBM、 Juniper、 LG-Ericsson、 Mellanox、 MRV、 NEC、 Netgear、 Proxim Wireless、 Quanta Computer、 Vyatta、 ZTE とZyXEL

NetFlow サポート


ベンダー

方法

NetFlowバージョン

実装

コメント

Cisco IOS-XR ルータ

CRS、 ASR9000 旧 12000

v5、 v8、 v9

Line card CPU上でソフトウェアを稼働

IPv6とMPLSの包括サポート

Cisco IOSルータ

10000、 7200、 old 7500

v5、 v8、 v9

ルートプロセッサ上でソフトウェアを稼働

IPv6 または 現モデルを要するMPLSとIOSのサポート

Cisco Catalyst スイッチ

7600、 6500、 4500

v5、 v8、 v9

ACLsにも使用されている、専用のハードウェア TCAM

高性能モデル RSP720 と Sup720のIPv6サポート、但し、最大128K または 256Kフロー/各PCF card.

Cisco Nexus スイッチ

7018、 7010

v5、 v9

ACLsにも使用されている、専用のハードウェア TCAM、最大512Kフローまで。IPv4/IPv6/L2をサポート

MPLSはサポートしていない

Juniper legacy ルータ

M-series、 T-series、 DPC のあるMX-series

v5、 v8

ソフトウェア jflowと呼ばれるルーティングエンジンでソフトウェアを稼働

IPv6とMPLS はサポートしていない

Juniper legacy ルータ

M-series、 T-series、 DPC のあるMX-series

v5、 v8、 v9

ハードウェア jflowまたはsampledとよばれサービスPICでソフトウェアを稼働

MS-DPC、MultiService-PIC、AS-PIC2でIPv6 または MPLSをサポート

Juniper ルータ

MPC-3D のあるMX-series、T4000の 後継FPC5

v5、 IPFIX

inline jflowと呼ばれるハードウェア (trio chipset)

JUNOS 11.4R2 (バックポートターゲット)を要するIPv6、MPLSのサポート不明、 12.3まではMPC3Eは含まれていない

Alcatel-Lucent ルータ

7750SR

v5、 v8、 v9、 IPFIX

セントラルプロセッサモジュールでソフトウェアを稼働

IPv6 または IOM3 line card、もしくはそれ以上を使用しているMPLS

Huawei ルータ

NE5000E NE40E/X NE80E

v5、 v9

service cardでソフトウェアを稼働

IPv6をサポート、MPLSは不明

Enterasys スイッチ

S-Series
N-Series

v5、 v9

専用のハードウェア

IPv6 サポートは不明

INVEA-TECH 調査

FlowMon Probe 1000、 2000、 4000、 6000、 10000、 20000

v5、 v9、 IPFIX

ソフトウェアまたは加速されたハードウェア

IPv6とMPLS、wire-speed包括サポート

Nまたはtel スイッチ

イーサネット ルーティング Switch 5500 Series (ERS5510、 5520 と 5530) と 8600 (Chassis-based)

v5、 v9、 IPFIX

Line card CPUでソフトウェアを稼働

IPv6包括サポート

PC と サーバ

Linux FreeBSD NetBSD OpenBSD

v5、 v9、 IPFIX

fprobeやipt-netflowまたはpflowのようなソフトウェア

使用されているソフトウェアによってIPv6サポート

VMware サーバs

vSphere 5.x

v5

ソフトウェア

IPv6サポートは不明

Mikro Tik ルータOS

ルータOS 3.x、 4.x、 5.x

v1、 v5、 v9

ソフトウェア と RouterBoardハードウェア

IPv6サポートは不明

Cisco NetFlowセキュリティイベントロギング (NSEL)

Cisco ASA 5580製品の立ち上げで導入されたNetFlowセキュリティイベントログ(NSEL)は 、高機能環境において、効率的にセキュリティ遠隔測定をするためにNetFlow v9フィールドとテンプレートを使用します。
NetFlowセキュリティイベントログ(NSEL)測定は、同等レベルでの詳細やログイベントでの粒度を提供している間は、Syslogよりもよりも優れています。

NSELは3つのFlow Statusに基づきFlowを生成します。
-flow creation、teardown 及び denial
※重複するSyslogはdesableを推奨
-NSELトラフィックはMPF(Modular Policy Framework)でフィルタリング可能

Cisco Network Based Application Recognition (NBAR)

2009年10月にCIscoは、NBAR(Network Based Application Recognition)というNetFlowを利用した新しい機能をリリースしました。
NBARはアプリケーションIDを利用して詳細のレポートを作成できます。たとえば「H.323、Telnet、RTP、Skype」などのアプリケーションを認識してNetFlow v9フィールドのテンプレートを利用してレポート化します。

スタンドアロンプローブでのNetFlow監視


スタンドアロンNetFlowプローブを使用したNetFlowの収集は、ルータとスイッチからフローを収集する選択肢のひとつです。
このアプローチは、ルータに基づくNetFlow監視のいくつかの限界を打開します。そのプローブは、TAPやSPANポート機器を使用している受動アプライアンスとして、ユーザに気が付かれずに、監視リンクに接続されます。
歴史的には、NetFlow監視は、ルータ内よりは専用のプローブ内で実行する方が簡単です。
しかし、このアプローチには、いくつかの欠点があります。

 ●プローブは、追加ハードウェア、セットアップやメンテナンスコストの原因を調査すべき全てのリンク上に設置しなければなりません。
 ●プローブは、ルータのようにインターフェイス情報を入力、出力を分けてレポートしません。
 ●プローブは、 ルータと全く同じルーティング情報を使わないので、ASナンバー、または IPマークのようなルーティングに関連するNetFlowフィールドのレポートには、確実性がない場合があります。

上記のような問題に対して最も簡単に対処する方法は、ルータの前にあるパケットキャプチャアプライアンスを使用し、ルータからの全NetFlowをキャプチャすることです。
この方法は、大量のNetFlowデータ(一般的には、長年におよぶ貴重なデータ)を蓄積することができ、そして、ネットワーク再設定をする必要もありません。

専用プローブのNetFlow収集は、犯罪やハッキングなどのトラフィック監視に大変適しています。
一方で、ルータのNetFlowは、ネットワークの帯域のレポート化や計算、パフォーマンス監視やセキュリティのために使うことができるトラフィックネットワークの見える化を提供します。


NetFlowの歴史

NetFlowは、元々CiscoルータのCiscoパケット交換技術で、1990年ごろIOS 11.xに実装されていました。
当初は、Cisco7000、7200と7500にソフトウェア実装され、当時最新のCisco高速交換の改善だと考えられていました。
そのアイデアは、フローの最初のパケットがNetFlow交換レコードを作成するだろうというものでした。

このレコードは、その後、フローが完了するまで、同じフローの全パケットに使用されていました。
フローの最初のパケットだけは、仕様マッチングルートを探すようルートテーブルに調査要求をします。
これは、特に転送情報ベース(FIB)のない旧式では、ソフトウェア実装の高価なオペレーションとなります。
NetFlow交換レコードは、実際、ルートキャッシュレコードのようなもので、IOSの旧バージョンは、現在もip ルート-キャッシュとしてNetFlowキャッシュを参照しています。

この技術は、ローカルネットワークには好都合でした。ACLがフローの最初パケットのみを評価しなければならなかったように、ACLがいくつかのトラフィックをフィルタしなければならなかった場合には、特に当てはまりました。

NetFlow交換は、すぐに大きなルータ、特に、基幹インターネットルータには適さなくなりました。
一方で、同時フロー数は、ローカルネットワーク上のものよりも重要でした。
そして、いくつかのトラフィックは、 ドメイン名システム (DNS)が要求するように、多くの短命フローを起こします。(セキュリティ理由のためにソースポートは、ランダムです)

フローは、交換技術として、1995年ごろにCisco Express Forwardingに取って代わりました。
最初は、Cisco 12000 ルータに載り、のちに Cisco 7200とCisco 7500の詳細なIOS上で、NetFlow交換の後継となりました。

2012年時点で、 NetFlow交換に類似する技術は、現在でも、ほとんどのファイアウォールやソフトウェアベースのIPルータで使用されています。

例えば、LinuxでNetfilter構成のconntrack機能を使用していました。

  • 評価版ダウンロード / まずは試してみたい

お客様が在って我々の商売が成り立っております。貴重なご意見お願い致します。

このホームページに

コメント:

TOP
株式会社ロジックべイン

〒216-0004
神奈川県川崎市宮前区鷺沼3-2-6 鷺沼センタービル3F
TEL:044-852-4200

  • MOODY INTERNATIONAL ISO9001:2008 認証取得
  • たいせつにしますプライバシー 10823826(02)
  • Norton SECURED powerd by VeriSign
  • I love SNMP