レイヤー7トラフィックに基づいてサービス品質をどのように実行できますか?トラフィックをどのように分類し、積極的に監視および応答しますか(トラフィックの動的な優先順位付け)。天気図のようなものを提供するソリューションはありますか?
レイヤー7トラフィックに基づいてサービス品質をどのように実行できますか?トラフィックをどのように分類し、積極的に監視および応答しますか(トラフィックの動的な優先順位付け)。天気図のようなものを提供するソリューションはありますか?
回答:
これは、これを達成したいプラットフォームに大きく依存すると思います。たとえば、IOSは主にQoSおよびセキュリティメカニズムのために、NBARを使用して通過トラフィックを分類します。しかし、私が知る限り、NBAR QoS設定は完全に静的です。
集中監視の場合、おそらくNetFlowが最善の策です。
適切なアプリケーション認識アプライアンスが必要です。Exinda、河川敷など。CiscoとJuniperら(はい、私はWAASを含めます)はクローバーソリューションです。NBARは、特に正確なものではありません。ランダム/ダイナミックポートを使用する、より複雑なプロトコルを使用します。企業で使用する場合、環境を制御できるのでNBARは問題ありませんが、インターネットを扱う場合は、巧妙なトリッキーなプロトコルやさまざまな状況に対処することになります。
たとえば、アプリ対応のものを動的なホワイト/ブラックリストに結び付けて、httpの場合、最初の100Mのバーストを許可し、レートがXを超える場合(HD youtube lolを超えて設定する場合)、より詳細な動作を提供し、優先トラフィックが競合する場合、最初の100M。この種の動作は、ユーザーに優れたエクスペリエンスを提供し、たとえばfilelockersなどのhttp / httpsを介して大きなファイルをダウンロードしているユーザーを攻撃している間、ユーザーには透過的に見えます。そして、重要なことに、彼らはより多くのプロトコルに対処します。例えば、nbarにppliveやppsなどの中国のp2pビデオストリーミングを見つけてもらいます。
基本的なエンタープライズ使用の場合、はい、nbar /静的ポート定義に依存してから、qos分類を使用して適切にキューイングします。そのシナリオでは問題なく動作します。
Linuxを実行している場合、iptables / netfilter-moduleであるl7-filterを試すことができます。その後、通常のiptables-magicを使用してQOSを実行できます。ウェザーマップは、collectd(RRDへの書き込み)で作成し、http://www.network-weathermap.comまたはhttp://weathermap4rrd.tropicalex.net/でこれらから読み取ることができます。
監視と動的な優先順位付けを可能にするツールが用意されていません。調整されたlinux-distributionやハードウェア-ファイアウォールのようなものに投資する必要があるかもしれません。
NBARは、レイヤ7でトラフィックを分類できるシスコの機能です。
この機能により、クラスマップ内で「match protocol ...」コマンドを使用できるようになるため、DSCP値のマーキングやポリシング、一致するトラフィックなどのアクションを実行できます。
NBARはPDLM(Protocol Description Language Module)と呼ばれるものを使用します。これは基本的に、トラフィックが一致するかどうかを判断するためのロジックです。カスタムアプリケーションの場合、独自のPDLMを作成する必要があります。私はこれをやったことがないので、これがどれほど簡単か難しいかについてコメントすることはできません。IPアドレスやポートが、サポートされているトラフィックカテゴリにトラフィックを分類するのにうまく機能していることが個人的にわかりました。
監視に関しては、NetFlowが使用するのに最適な機能であるという点でJeremyに同意します。このデータを収集して報告できるさまざまな無料ツールと有料ツールがあります(ルーターはこのデータを管理ステーションにプッシュします)。Cacti(無料)は、お探しの「天気図」レポートをサポートしている場合があります。
また、監視のために、SNMPを使用してトラフィッククラスから使用状況とドロップを収集するレポートツールを調べることもできます。そのルートに行く場合、「snmp mib persist cbqos」を使用してデバイスを設定することをお勧めします(これにより、再起動後もifIndex値が静的に保たれます)。繰り返しますが、多くのツールオプションがあり、Cactiは開始するのに適した場所です。
これはあまりにも広範ですが、ここであなたが求めていると思うことに答える努力があります。以下は、上記のジェレミーの答えに関する詳細情報です。
OSIモデルはTCP / IPにもマッピングされないため、TCP / IPについて説明するときは、OSIの用語ではなく、TCP / IPの用語を使用します。 ---たとえば、最初に設計されたときとTCP / IPを使用したときの両方で、H.323がモデルにどのように適合するかを理解しようとします。
簡単な例として、他のTFTP要求よりもPXEブートのTFTP要求を優先したい場合や、あるタイプのH.323シグナリングを他より優先したい場合があります。
これを行うには、トラフィックをシェーピングしたいプロトコルを理解できるルーターなどが必要です。これらのルーターは、少なくとも必要なときにパケットを詳細に検査し、検出した内容に基づいてトラフィックをシェーピングできる必要があります。言うまでもなく、異なるアプリケーションプロトコルには異なる要件と可能性があります。
このため、プラットフォーム、プロトコル、および何を達成したいかによって異なります。さまざまなベンダーがこのためのツールキットを持っていると他の人が指摘しているように、関与するものに本当に答えるためには、あなたが持っているトラフィック、あなたが解決している問題、そしてあなたがすでに利用できるツールについてもっと多くの情報が必要です。
Ciscoデバイスがある場合は、NBARとQoSの組み合わせを使用します。
NBARは、カスタム要件に基づいてトラフィックを分類するのに役立ちます。追跡する必要があるプロトコル/アプリケーション用のカスタムNBAR PDLMを作成できます。コマンドは次のとおりです。ip nbar custom name [offset [format value]] [variable field-name field-length] [source | 宛先] [tcp | udp] [範囲開始終了| ポート番号 ]
これが完了したら、カスタムNBARアプリのQoSクラスを作成し、ポリシーを適用します。