V8.2.1を実行しているASAは双方向ネットフローをエクスポートしています。これは私たちが目にしてきたものとは違うようです。ほとんどのネットフローｖ5、ｖ9、IPFIXエクスポートでは、フローは一方向にエクスポートされ(すなわちA→B、その後B→Aのフローに分けられる)。これはingressと egressフローにとっての真実です。例えば、A→Bが200キロバイトのフローを作りだし、それに対してB→Aは40キロバイトのセカンドフローを作り出すとしましょう。そして、ASAの開発者は二つのフローを一緒に加え、A→Bを240キロバイトエクスポートしました。この二つをあわせたフローのことを双方向フローと呼びます。

これにより、私たちが二つ一緒になった全部のネットフロ－（SNMPではない）使用率を計算する時、ステータスタブにインバウンド・アウトバウンド使用率を入力します。私たちはCiscoと、型にはまらないエクスポート方法について話し合ってるところです。

注意：ASAもアクティブタイムアウトはサポートしていません。アクティブタイムアウトとは、グラフの中で巨大なスパイクを引き起こすので、１分おきにトラフィックが起こる時トラフィック分析をいくらか複雑にさせてしまいます。

もしASAやNSELで異様な結果を目にしたら、上記のような理由になります。とにかく、ステータスバーにデータを入力できないときはMikeを責めて下さい。

ここに私たちのASAの写真を載せておきました。

　　　＊写真

ASAからのネットフローエクスポート設定でお困りですか。

CiscoASDMを使えばネットフローエクスポートがセットアップできます。CiscoASA とネットフロートレーニングビデオを見て下さい。

____________________________________
Jim Dougherty aka “Jimmy D”

Ciscoの競合企業はネットフローを有効にすることはルータやスイッチを自由に動かせると思ってほしいと考えています。

Ｓフローの創始者はこのことをあなたに信じてほしいと思っています。私たちはＳフローサポーターですが、事実をはっきりさせる機会を持ちたいと考えました。

一般的には、ほとんどの利用者はネットフローが有効になる時のルータのＣＰＵの微増（2～3%）しか見ていません。わたしはこのトピックをさらに調べることにしました。この下にネットフローがパフォーマンスに与える影響についてCiscoが皆様に伝えることを挙げます。（スライド74と75を見てください）。

・    ネットフローバージョン５を約15％（プラットフォームによって最大20％）有効にすることとＣＰＵ使用増加のエクスポート

・    ネットフローバージョン8を有効にすることは2から5％（複数集約のための6%の使用可能な数による？）ＣＰＵ利用を増加させます

・    ネットフローは cat6000 supervisor と 12000 Engine 3 Line Cardsにあるハードウェアで実行されます。

Ｓフロースイッチのように、Enterasys スイッチはＣＰＵに影響がないハードウェアを使用しているネットフローエクスポートを実行している。いくつかのベンダーはハードウェアパフォーマンスにネットフローが常に影響していると私たちに思ってほしいらしいが、それは真実ではない。

Micheal Patterson

Scrutinizer　製品　マネージャー

私はこの問題を最近考えていて、ネットフロートラフィック分析の中のフローを見る方法に効果的だと想像できるので、話す価値があると思います。

 NetFlow v5 packetには、あらゆる通信のためにインバウンド・アウトバウンドインターフェイスを明確にする二つの行が存在します。これらのインターフェイスの数はちょうどあなたのルータによって割り当てられるifindex インターフェイス IDのことです。

インバウンド・アウトバウンドインターフェイス領域は、あなたのトラフィックの流れがどこに向かっているか計算するのに重要です。

いくつかの画面ショットを見てみましょう。

＊    画面の映像

この画面ショットはワイヤシャークを使用しているＳフローのパケットキャプチャーの例をあなたに提示してくれます。

Input Interface index と Output Interface Index領域に注意してください。

このパケットキャプチャーを見てみると、この特別なサンプルされた通信は初めはインターフェイス１となりました。その後はインターフェイス・・0に出ていきました？

インターフェイス0もしくは”Null”は次のシナリオのときに起こります。

・    multicastトラフィック

・    ACLルールによる通信拒否

・    パケットがルータそれ自体になっている

・    QoSによる通信ダウン

・    ルータ間違い設定

・    IOSバグ

これらはこの種にトラフィックパターンを引き起こす可能性がある広く知れ渡った設定のいくつかです。これは、あなたが通信帯域幅使用を監視している際、どのようにScrutinizerがこのデータを与えるのかに影響するので、設定を知ることはとても重要です。例えば、あなたがシリアル0/1インターフェイス（インターフェイスID1）に入ってきて、シリアル0/2（インターフェイスID2）に出て行くmulticast トラフィック を持っていることを想像して下さい。multicast トラフィックはネットフローレコードの中でアウトバウンドインターフェイス0を与えることを覚えておいてください。

あなたのネットフローコレクターは、ネットフローレコードが0と記録する時、2つのifindex ID とシリアル0/2インターフェイスとアウトバウンドmulticast トラフィックを結びつけることをどのようにして知るのでしょう。それはingressフローとではありませんが、もしmulticast egress フローを有効にすれば、あなたは予想通りに書き込まれるアウトバウンドインターフェイスを見ることができます。

このシナリオはネットフローdynamicを初めて使用する通常ユーザーにとっては混乱を招くかもしれません。

ネットフローアナライザーがアウトバウンドインターフェイス0でのネットフローレコードを見ているとき、トラフィックは通過する可能性のあるインターフェイスとそのレコードは正確に連結できないでしょう。

この問題の論争の助けとしては、Scrutinizerは何も教えてはくれません。たぶんあなたはあなたのデバイスに並んだインターフェイス0に気付いていますね。このインターフェイスは本物のインターフェイスではありません。これは現存するどのインターフェイスにも関係していない全てのトラフィックをまとめたものです。捨てるより見せた方が良いですよね。

もし、上に挙げたコンディションでいくつかを実行していると思ったら、ここに電話してください。

私たちは、あなたが見ている全てのものを検証するネットフローパケットのコンテンツを見ることができるFlow View と呼ばれるScrutinizerにすばらしいツールを作成しました。

Nate

返信

2009/11/7  Mike@plixer.com

Multicast トラフィックでは次のことを覚えておいてください。

＊   ingress フローは送信先インターフェイス0”null”があり、シングルフローがエクスポートされる

＊   egressフローは送信先インターフェイスを示し,複数のフローがエクスポートされる（インターフェイスごとに）

＊   もし本当に必要とするなら両方のタイプのフローをエクスポートすることをお勧めします。

私はよくこの質問をいただくので、こう思います。　クイックブログを書いたらどうですか。

Flow AnalyticsとScrutinizerｖ７はすばらしく共生する関係を持っているので、Flow Analyticsのライセンスコピーを手に入れるためにフリーバージョンをアップグレードする7つの理由について考えてみましょう。

１．           可能な設定におけるセーブされたレポートのための限界値アラーム

顧客の利用限界値をインタフェイスに設定したいですか。限界値を超えたときに警告したいですか。Flow Analyticsはツールはこの機能を提供します。

２．           port scans, DoS attacks, ICMP issues、P2Pファイル共有アプリケーション検出、不法IPアドレス、過度のmulticast トラフィック、ブラックリストにのったインターネットホストとなどへの通信へのアラーム

　これは間違いなく全ての機能の中で私が一番好きなものです。それがポートスキャン、ワーム、BitTorrentもしくはネットワークで192.168を刻むLinksysルータであっても、フローAnalyticsはネットフロートラフィックの流れを監視する活動や特異なトラフィックパターンの詳細な発信源をあなたに提供することによって何時間もの時間を記録します。

３．           過度のアラームを引き起こすホストへの固有のインデックス。インデックスが大きくなるにつれて、固有のアラームがさらに妨害しています。

簡単に言えば、有害で不正な機械があるということです。フローAnlyticsは追跡し、それらが関係しているたくさんの不正な活動のマシーンアカウントをランク付けします。

４．           多くのレポートに関する記録タイムを早める自動DNSリゾリューション

手入力でのIPアドレス分析の変わりに、”Easy Mode”を使うことをお勧めします。

５．           月曜から金曜までの午前8時から午後5時(アメリカ時間)の間のテクニカルサポートへのアクセス

自慢するつもりはありませんが、私たちは本当に優秀なサポートクルーがいます。私たちの現存するカスタマーは非常にすばらしいサポートを受けられることを私は保証します。

６．           Scrutinizer提供のフリーソフトの２４時間の枠を越えた全てのデータ情報記録が可能

この機能は自明の理です。長期間情報記録で、高価なネットワークをアップグレードさせるために必要性（もしくは欠落）を証明できるレポートへのアクセスをします。あなたが先週作成したHTTPいくらか知っていますか。

７．           一流の通信、一流のアプリケーション、一流のサブネットトラフィックへのサブネットやたくさんのフローエクスポートデバイスを通して全てのものが測定したさらに多くのビュー

あなたのデバイスの一つのTop Talker を知ることは素敵なことですが、どのデバイスが全体的にTop通信をしているか知りたいと思ったことがありますか。これらのツールはあなたのネットワーク全てのデバイスを通した活動の全体ビューにとても良いです。

Nate

ネットフロー事象を誘因する3つの最も有名な事象のタイプは：

                                            * フロー作成
                                            * フロー喪失
                                            * フロー分解

精通しているネットワーク管理者によると、あなたのASAファイアウォールからのNSEL ネットフローを有効にするために必要な全ての段階を踏んでいます。しかしあなたのファイアウォールを通じてあなたのトラフィック量がどのくらいなのか、これ以上知る必要はありません。あなたのネットワークに誰がアクセスしようとしているのかと彼らがそれを成し得た時に何が起こったのかを知る必要があります。Scrutinizer v7を使用すると、トラフィックフローのみならず、その事象が起こった場所を特定する独特の機能があります。

NSELのテンプレートは、一般的なネットフローv9フォーマットに付随していますが、事象が起こった場所によって独特のテンプレートコンテンツがあります。ですから、事象の配置を正確に報告するために、あなたがお使いのネットフロー分析は、情報が送られたことを認識することが可能でなければなりません。Scrutinizer v7は、まさしく可能にしています。

今日の市場における多くのネットフロー分析は、ネットフローv9を完璧に処理をする能力を持ち合わせていません。結果的に、ネットフロー v9 テンプレートを受け取ったときのみ、それらは、ネットフロー v5とv9でシェアしている共有のフィールドで報告ができます。多くのフィールドでしばしば処分/無視されているので、報告が発生した時に、報告データを得られるのは、ユーザーに限られます。

 しかしながら、Scrutinizer v7は、独特で、なぜならば、ネットフロー v9 記録を処理することができ、したがって集約されたNSELテンプレートの様々な種類を識別し、それらのテンプレートにある発生した各事象の正確な報告の全てのデータを使用しています。

www.plixer.com を見てみてください、そしてお見逃しなくScrutinizer v7の最新版をダウンロードしてください。.

Share and Enjoy: