Free NetFlow Resources

これはToSフィールド（例：IPフレームのDifferentiated Servicesフィールド）の４パートからなるシリーズのパート5です。４パートのブログにパート５をつけるなんて冗談です。
 
パート１から４を読んでおいてください。
もう一度、わたしの最初のブログからWireShark キャプチャを書きます。
※    図
上の図のDifferentiated Servicesフィールドの一部である２つのECN (Explicit Congestion Notification) ビットに注意してください。それらはブログ３で1998年に書かれたRFC2474からの“現在は使われていない”ビットです。“現在は使われていない”（普通は:) 二つのビットはRFC3168で1998年に定義されました。
 
二つのECNビットは混雑状態を示すためにホストかルータに使われています。

ECN-Capable Transport (ECT) = 10 or 01
Not-ECN-Capable Transport (Not-ECT) = 00
Congestion Experienced (CE) = 11NOTE: Routers treat the ECT(0) and ECT(1) codepoints as equivalent. Senders are free to use either the ECT(0) or the ECT(1) codepoint to indicate ECT, on a packet-by-packet basis.

TCPとECNの操作
Wikipediaには書いてないのでいくつかの文を貼り付けておきます。
＜貼り付け開始＞
IPヘッダーのECNビットによると、TCPはTCPヘッダーで送信者が送る情報を減らすために送信者に信号を送るTCPヘッダーで二つのフラッグを使用します。これはECNエコーと下記で説明するCongestion Window Reduced (CWR)です。
TCPコネクションでのECNの使用はオプションです。ECNが使われるにはSYNとSYN－ACKセグメントの最適なオプションを取り入れることにより作られるコネクションで交する必要がある。ECNがTCPコネクションに関して取り決められると送信者はECN-capableコードポイントで全てのデータセグメントに印を付けます。これから起こる混在状態を検出するルータはECN-capableパケットに完全に落とすというよりもCongestion　Experienced [...]

ネットフローを使用しているQoSのレポートは最も基本的なネットフローレポートツールにとってもとても基本のレポートです。レポートの名前はベンダーによって違いますが、IP図表の同一8ビットToSについて、私たちは話しています。時には誤ってDSCPとみなされることがあり、この1バイトの価値はQoSフローをセレクトビジネスアプリケーションにどうにか保証するために使われます。 
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の監視とは対象的にたくさんのフローレコードを作成します。
あなたのネットフローへの試みの助けになりますように！

多くの会社が第一にインターネットセキュリティ脅威のことを考えています。セキュリティ脅威の大半は内部で発生すると思います。Forrester Researchによると、セキュリティー侵害の大半は85％の可能性で内部従業員が関係しています。私が今日主張したいことは、内部脅威だけを気にするだけでなく、かれらを外部脅威とは少し違う扱い方をする必要があると思います。
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

私たちの多くのお得意様にとって、スキャンする事ができるネットフローコレクターは、とても重要です。500近いお客様は、CiscoのNetFlowまたは、100以上のデバイスからなるsFlowを収集しています。調整することが可能なNetFlow分析の解決策は、とても重要であるということを理解しています。
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

Huawei-3Com Co., Ltd (H3C)　によって開発されましたPlixer　InternationalからのScrutinizer　NetFlow と sFlow Analyzerは、NetStream パケットをサポートすることができます。
Huawei-3Com Co., Ltd (H3C) は、2003年11月にHuawei と 3Com の共同事業として、運営を開始しました。 2006年に3Comは、HuaweiのH3Cの株を買い取ることによって、彼らは、正式に別々の方向性に進みました。H3Cは、中国にある3Comのように、Huawei が合意した非競合協定が終了するまで繁栄し続けていました。
しかしながら、NetStream パケットは、共同事業とともに進んでいました。NetStreamパケットは、多くのNetFlow analyzers に支えられて、容易に3型を作り、現在、NetFlow パケットの型v5/v8/v9に似た、　v5/v8/v9の3型があります。
しかし、NetStream パケットの解説情報のインターフェイスは、スタンダードMIB II を使用せずに、彼らの所有するインターフェースMIBを使用しています。
Huaweiのスイッチやルーターを使用しているトルコの顧客と密接に働いて、Huawei のインターフェイスインデックスにアクセスするコードを開発し、NetStreamパケットのための正しいインターフェイス情報を報告することができました。
もしあなたがHuaweiか、またはNetStream をサポートしている3Com のネットワーク機器を使用し、あなたのネットワークをモニタリングするツールのためにScrutinizerを使用したいとお考えなら、たならば、詳しくは、Plixer Technical Supportまでご連絡をお願いいたします。
- Joanne

Scrutinizer　v7.2の発売において、Scrutinizer　v6を稼動しているお客様にアップグレード/移動経路を提案していました。私は、何人かのお客様から「なぜ、アップグレードする必要があるのですか？」や「私たちが現在持っていないもので、Scrutinizerから何を得ることができますか？」と聞かれました。
先週、Plixerのネットワークトラフィック分析論のアップグレードされた発売により、これらの質問の答えは、非常に明確になりました。
Scrutinizer v7.3によって、Plixer International は、なぜNetFlowとsFlowトラフィック分析論において、リーダーなのかを表しています。NBARサポート、新しい報告フィルターの数、そして新しい分析ツールの数の全てによって、あなたのネットワーク上で何が起きているのか、より簡単に分析します。
不正な動きのアルゴリズムは、多くのホストを通過している点滅したポートをスキャンする人々を捕まえるために設計されています。
このことは、通常、攻撃に通用するサービスがあるかどうか確認するために、ホストは、ホストIPごとに、1回フローを送るということを意味します。
この図表は、同じサブネット上で、ひとつのホストが複数のホストへパケットを送っていることを表しています。このケースでは、80ポートのウェブサービスを監視しています。
ひとつのサーバーだけが応答しました。このことは、“インターネットの悪者”が1x.1.1.1で更なる攻撃をするであろうと言うことを示しています。
このアルゴリズムの閾値は、以下によって設定可能です:
Admin Tab -> Settings -> Flow Analytics
不正な動きの閾値は、固有の起点/機器の数が比率の中のTCPフローが侵害する必要のある送り先にセットされています。
不正な動きの比率は、起点アドレス、例えば、10：1あたりのフローごとのパケット比率です。1：1のような低い比率は、通常、不正な動きを表しています。
疑わしげに見えたトラフィックを偶然見つけることは、遠い過去のことになってしまいました。Scrutinizer v7.3 とフロー分析論によって、今、あなたは、ネットワーク上で警報を出すことが可能になります。
私は、Scrutinizer v7.3の全ての新しい特徴と報告を近日中にブログに書きますので、確認してみてください。
-Scott

明らかに、多くのＷＡＮ最適化ソリューションを提供する会社はフローボリュームに基づいて機器の価格をつけています。フローボリュームとは何でしょう？フローボリュームとは、決められた時間の全インタフェースか特定のインタフェースの1点に集まるフローの数のことです。例えばWebページをダウンロードすると、いくつかのフローが作られます。何かにPingを打つと、同じようにフローを生み出します。実際、Syslog, SNMPトラップなども全てフローを生み出します。 TCPはICMPやUDPフローより長く残るフローを生み出す傾向があります。これはＷＡＮ最適化にどのような手助けとなるのでしょう。 WＡＮ最適化サイジングのためにScrutinizerを使用している顧客に指摘しました。「どうやってそんなことをするんですか」と私は尋ねました。「フローボリュームレポートは決まった時間にTCPフローがいくつリンクしているかをお知らせしてくれます」と彼は答えました。これは本当のことで、Scrutinizerのフリーレポートの一つは1分ごと（必要なら1秒ごと）のフローボリュームを表示します。秒ごとので割合とインターバルごとのトータルを得ることができます。ＷＡＮ最適化ベンダーの請求はより細かくフローカウントをベースにしていたと顧客は言っていました。Scrutinizerがあれば、ネットフローデータグラムのあらゆるフィールドを取り入れたり出したりするために簡単にフィルターを加えることができます。このScrutinizerレポートがあるので、不必要な準備に時間をかけずに最適なハードウェアを購入することが可能です。 ＷＡＮ最適化ベンダー • BlueCoat • Cisco WAAS • Expand • Riverbed • Silver Peak フローに注意しましょう　購入する前に、その機器がネットフローをサポートしているか？完全なegressフローでネットフローv9をサポートしているか確認して下さい。なぜそうする必要があるのか？　 Best Practices for Cisco WAAS Reporting using NetFlowに関する短いブログを見てください。全てのベンダーに対応しています。

こんにちは！
私たちは、登場すると宣言し、今、実現しました。
最新のPlixer自身のNetFlow監視アプリケーション　を搭載している、新しいマイグレーション機能の効能によって、私たちは、いま、以前よりもスムーズにScrutinizer NetFlow & sFlow Analyzer v6 からv7 変換することができます。
現在、あなたは、この新しいツールのアシスタントによって、あなたのが去に使用したNetFlow データと複雑なフラッシュマップを正しく、新たにインストールすることができるでしょう。
このNetFlowデータのマイグレーション過程には、少し制限があることをご承知おきください。もしあなたがネットワークトラフィックの分析のために今なおScrutinizer version 6をお使いで、それらについてより詳しくお知りになりたい場合には、contact Plixer support　にご連絡をお願いいたします。また、もし、その他の新しい特徴や最新版で修正可能かどうかご興味があるようでしたら、Scrutinizer version 7.2 release notes.をご覧ください。
もしあなたが市場に出ているもっとも画期的な Windows NetFlow コレクターの稼動を心待ちにしているならば、 私たちのサポートチームへご連絡ください。私たちは、あなたがマイグレーション開始するのをお手伝いいたします！
Plixer Support
(207) 324-8805 ext: 4