VoIPやビデオのようなアプリケーションのネットワークを通じて、QoSno優先順位を決めようと、多くの企業がDiffServ ドメインを設定しています。サービスが標準にならない時、この会社はよくトラブル解決ルーティーンの一つとしてネットフローAnalysisに転向します。もし これらの頭文字が分からなければ、Tos, DSCP やネットフロー…. 「What the DiffServ」  に関する私の5つのパートのブログがあなたの助けになってくれるでしょう。

QoSサービスを話している時多くの人はDSCPと呼ばれるToSフィールドの6ビットの一部について話しています。下がその例です。

赤い四角でECTという文字と囲ってある上記のものに注意して下さい。これはDSCPを使用している時、残り8ビットToSフィールドを作っているExplicit Congestion Notification 2ビットです。このフィールドはそれらを実行するビジネスアプリケーションスタートとしてとても重要になってきてきます。

Wikipedia: “TCPは送信する情報を減らすために送信者に信号を送るTCPヘッダーの中で二つのフラッグを使用しています。これは下記で説明するECN-echo (ECE) とCongestion Window Reduced (CWR) ビットです。 とにかく上のスクリーンキャプチャーのDSCPバリューの一つに関して掘り下げてみましょう。そして約2ダースレポートから選択しましょう。

  BTW: 各レポートは追加レポートコンビネーションを持っています。

DSCP 0 ECT (00000010) フィルターが通ったか分かる上の赤い枠を参照して下さい。さらに勧めていき、DSCPトラフィックのしきい値を設定するためにフローAnalyticsを使いましょう。しきい値が私たちに教えてくれます。

上記野しきい値に追加のフィルターを使うことができます。

•異なるルータ・スイッチでのインタフェース 

• 特定のIPアドレスかサブネット（それらを除外していても）

• TCP フラッグ
• 追加DSCPバリューをプラス
• など

かなりクールです。Scrutinizerがもう一つのレベルにToS レポートするのを考えるのが好きです。多くの企業が今日のネットワークメディアアプリケーショントラブル解決のためにレポートの精度を要求しています。

 マルチメディアマルチキャストアプリケーション使用とbandwidth消費の上昇によって、それらのリンクやトラッフィクタイプを監視することはとても重要になってきています。

しかし、マルチキャストトラフィックがカウントされずに、ネットフローｖ5を実行させているかどうか知っていましたか。

ｖ5でルータはマルチキャストパケットが複製されている時間をカウントしませんし、ｖ5はegress監視をサポートしていないので複製後、ユニークアウトバウンドIPに記録もしません。

その結果多くのマルチキャストトラフィックを失うことになります。

これを解決するためにはネットフローｖ9とegress/ingress監視機能を使用する必要があります。

まず初めに、マルチキャストトラフィックをサポートするルータを有効にします。

有効になったら、マルチキャストパターンへのフロー監視を有効にする二つの設定がでてきます。

・       ip multicast netflow output-counters

・       ip multicast netflow rpf-failure

はじめのip multicast netflow output-countersコマンドはマルチキャストパケット転送とバイトの数を計上します。

２つめのip multicast netflow rpf-failureコマンドはRPFチェックを失敗したマルチキャストパケットのトラックを保存します。

この二つのコマンドを有効にしたら、次の二つのうちどちらか選択してマルチキャスト計上するためにどちらのインタフェースが良いかを特定することができます。

・       ip multicast netflow ingress

・       ip multicast netflow egress　　　　ふたつの違いはなんでしょう。

ip multicast netflow ingressアカウントは各パケットが何回複製されているかカウントするフローレコードを作成します。ip multicast netflow egressは外に出て行くインタフェースのための新しいレコードを作成します。

注意として、たくさんのマルチキャストトラフィックを作成するとして、egressコマンドを使用したらigressの監視とは対象的にたくさんのフローレコードを作成します。

あなたのネットフローへの試みの助けになりますように！

Scan の監視

インターネットでのSYN, XMAS, RST/ACK, FIN,等の監視は主に驚くべきものになります。あなたのインターネットコネクションの３アタックタイプのボリュームは頻繁に行われ（1時間ごと）本当のセキュリティ脅威よりももっと迷惑なものです。なぜ、私は彼らを‘迷惑なもの’と呼んでこのインターネットスキャンを減らすのでしょう。これらのコネクションのコンスタントな一斉攻撃を止めるのは不可能だからです。それらを追跡し止めるのは不可能ですが、あなたたちは6から10以上に匹敵するものを止めることはできます。ほとんどの会社において、それらをブロックすることでシンプルにスキャンを取り扱っています。

上記スキャンの監視は確実に内部で行われる必要があります。例えば内部にSYNスキャンを検出することは悪い物に感染する原因をつくります。悪いものとはソフトウェアダウンロードか内部でないマシン使用を通してネットワークの中に入ってきます。 おそらくパソコンが自宅で感染し会社に持ち込まれるのです。　これはどんなときでも起こります。

侵害されたインターネットホスト
その他のセキュリティー実行は内部ホストがインターネットで通信している監視に関わっています。もしbadリストに並んでいるホストでトラフィックを交換したら、イベントはアクションを引き起こします（通信ブロックなど）。なぜならその‘リスト’はインターネットに影響を及ぼします。インターネットルータでのみ行われるこのタイプのトラフィックやネットフローエクスポート、ｓフローエクスポートの準備費を調べたりするものです。I

False Positive Alarmsはどうなのか
自然なビジネスアプリケーションのせいでfalseアラームが全てのソリューションで起こります。しかし、すばらしくデザインされたセキュリティーシステムはセレクトルータ、スイッチとエンドシステムを可能にします。エンドシステムとは各異常検出アルゴリズムから排除されるためのものです。システムヘルプの期間は様々な活動を獲得し、システムの精密さをよりよく認識させ予期せぬトラフィックパターンに警告を与えてくれます。それぞれのアルゴリズムにルータとスイッチを選択してください：

選択されたアルゴリズムから特定のホストを排除します：

フローAnalyticsに検出された様々なトラフィック異常の部分的なリストはマニュアル１４ページにあります。このブログのパート2では特定の活動パターンのアラームと同様に通信とフロー活動について論じます。

Michael Patterson
Scrutinizer Product Manager
Follow Me on Twitter

Scrutinizerのスケール
私は、先週政府のお客様と一緒に仕事をしました。結合した1736のインターフェイスで440ルータからネットフローを受信している、彼のScrutinizer上の重要部分を調べてみてください。あなたはたびたび、私がとても大きなボリュームのルータと比較的軽い集合体のネットフローボリュームを見ることに驚かれることでしょう。あなたがご覧になった通り、Scrutinizerは、休みなく音を立てて進んでいました。

見守るべきこと
200UDPを超えるネットフローのデータグラム（毎秒毎に約6,000フロー）を送っているルータは、データベースにとても大きなテーブルを作っています。個別のテーブルが大きくなり過ぎると、初期段階のレポートの際に、低速応答を引き起こす可能性があります。このことは、エッジルータに関するレポートが早い理由であり、そして、コア・ルータの報告では、更に数秒要する可能性があります。Scrutinizerは、フローボリュームのブレークダウンによって、この板ばさみ状態の手がかりとなります:

• コレクター毎
• リスニングポート毎（例えば、2055)
• ルータ毎

私たちは、同じ種類においてフローが抜け落ちることにも注意を払っています。有能なネットフローの報告ツールは、この情報もまた提供するはすです。このことについては、おってブログに乗せます。今は、上記のスクリーンキャプチャでのMFSN傾向に注意しておいてください。

概要
私は、一度、二つのcatalystスイッチだけを持つお客様と一組のScrutinizerのコピーを持つ200を超えるインターフェイスを見たことがあります。今や、私たち個有のライセンス供与により、払ったお金に見合うだけのものを得ます。Scrutinizerは、世界のいくつかの大きなネットワークと比例し、変化します。

Michael Patterson
Scrutinizer Product Manager

個人的に、私は、ほとんどの場合、YouTubeに発表しているいくつかの事柄を偏向しています。

このwebcastは、Scrutinizer　v6.Xを使用し、記録されていますが、もしあなた方の質問がnetwork traffic analysisのためのsFlowとNetFlow Collectionの違いに関するものだとしたら、その内容は、まだ非常に有益であると考えています。

ご自由にPlixerのYouTubeをご覧ください。

Brad Reeseの助言により私たちは、NetworkWorldに “NetFlowよりsFlowの方がよいということをよく見よ”と言う記事を公表しました。これは、技術的洞察にとても良いと思います。

TechWiseTVのJimmy-Ray事務長が一度Network Worldのブログに書かれていたコメントによると、「両方をインストールし、両方を弄り回して、データを抽出してみて、NetFlowをより好む理由は、

＊    より多くの設定オプションがある。

＊    よりフル装備の無料コレクターがある。

＊    他のapplication off systemにより,自分のものにすることができる詳細でエクスポート可能な記録がある。

＊    MPLSに関して、NetFlowが優れている

＊    NetFlowは、より進化すると思われる。sFlowは、いくつかバージョンがアップグレードしているが、マルチな設定オプションは、ない。

私は、誰もがJimmy-Ray事務長とRobb　Boydを好きだと思います。彼らの表現は素晴しいです。彼らは、Ciscoに偏見をもった数少ないベンダーですが、しかしその反面、Ciscoは、とても手強い相手であるということを覚えておいてください。

Enterasys の両サポート　

Enterasysの人々は、彼らのNシリーズのスウィッチでNetFlowを、CシリーズでsFlowを実行しています。両方の実行は、ハードウェアにて行われています。どちらがいいのでしょうか？最も公平な意見を彼らから得ることができるでしょう。

Jon　Mills

Marketing　＆　Public　Relation　Manager

最近発売された彼らのNetFlow分析で、Plixerは、NBARの報告を含む、いくつかの新しい報告を紹介しています。Cisco’のNBAR テクノロジーは、ホストによって使用されたアプリケーションを分類するルータを通じて、トラフィックの移動を詳しくパケット診断をします。例えば、H323, Telnet, RTP, ExchangeとSkypeは、NetFlowで分類されて、エクスポートされています。

“適応性のあるNetFlowは、標準NetFlowによって報告された情報基準において、大いに拡張する可能性があると私たちは感じ、そして同時に感じていました。“とPlixer CTOのMarc Bilodeau は、言っています。“ScrutinizerのNetFlowとsFLow分析バージョン7.3で、Plixerは、適応性のあるNetFlowの導入のみならず、重要な利点の実行においても、NetFlowのその他のバージョンよりも群を抜いています。

“伝統的に、ソースとディスティネーションポートだけは、NetFlowv5とv9の中でエクスポートされていました（例えば、TCPポート80）。適応性のあるNetFlowは、NetFlowv9において、適切なファームウェアのアップデートによって、NBARをエクスポート可能にすることが改善されています。フロー分析論のあるScrutinizerは、NBARフローが使用しているほとんどのコンビネーションフィールドにおいて、閾値とアラームをセットすることが可能です。”

Plixerのネットワークトラフィック分析の最新バージョンは、NBARサポートに加え、フローボリューム、フロー接続、ホストボリューム、ペアボリュームなど他にも、いくつか多くのトラフィック監視報告タイプを加えています。

フロー分析論と呼ばれる、主力製品を強化するScrutinizerのネットワーク動作分析(NBA)は、例えば、進入違反、DNS違反、悪質な活動違反、不完全なフロー違反など、今後の悪質なトラフィックを探知するため、新しいアルゴリズムが加えられました。

価格と供給
Scrutinizer NetFlowとsFLow分析v7.3は、現在ダウンロード可能です。
Scrutinizerは、NetFlow分析ツールは完全に無料ですが、24時間以上保存された過去のデータと追加トラフィックの診断上の特徴、フロー分析モジュールは、$1,995から可能です。

Scrutinizerの製品価格に関する詳しい情報は、のページをご参照ください。

Jon Mills
Marketing & Public Relations Manager

　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フローは送信先インターフェイスを示し,複数のフローがエクスポートされる（インターフェイスごとに）

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