概要
シングルフローが Cisco Firepower アプライアンスの全体の定格 スループットをなぜ消費する場合がないかこの資料に記述されています。
背景説明
Webサイトを、かあらゆる帯域幅測定単位ツールの出力は（たとえば、iperf）テストするあらゆる帯域幅速度の結果 Cisco Firepower アプライアンスのアドバタイズされたスループット 定格を表わさないかもしれません。 同様に、あらゆる転送 プロトコル上の非常に大きいファイルの転送は Firepower アプライアンスのアドバタイズされたスループット 定格を示しません。 それは最大スループットを判別するために Firepower サービスが単一のネットワーク フローを使用しないので発生します。
Snort によるプロセス トラフィック
Firepower サービスの根本的な検出 テクノロジーは Snort です。 Cisco Firepower アプライアンスの Snort の実装はシングル スレッド プロセス トラフィックを処理するためにです。 アプライアンスはアプライアンスを通過するすべてのフローの総スループットに基づいて特定の定格のために評価されます。 アプライアンスが社内ネットワークで配置されることがボーダー エッジの近くで、通常期待され、接続の桁を使用します。
アプライアンスの各 CPU で動作する 1 Snort プロセスのいくつかの別の Snort プロセスへのトラフィックの Firepower サービス 使用 ロード バランシング。 理想的には、システム 負荷は Snort プロセスすべてを渡ってトラフィックの均等にバランスをとります。 Snort は次世代ファイアウォール（NGFW）、侵入防御システム（IPS）および Advanced Malware Protection （AMP）インスペクション用の適切な文脈上分析を提供できる必要があります。 Snort を確認することは最も有効、シングルフローからのすべてのトラフィックです 1 つの snort 例にバランスをとられる負荷です。 シングルフローからすべてのトラフィックが単一 snort 例にバランスをとられなかった場合、システムは避けることができ、Snort ルールが一致するまずないかもしれませんか、またはファイルのピースが AMP インスペクション用の隣接 しないようにトラフィックはこぼされて。 従って、ロード バランシング アルゴリズムはある特定の接続を識別できる接続 情報に基づいています。
Firepower サービスを用いる ASA の 2 タプル バーチャル アルゴリズムおよび NGIPS
Firepower サービスプラットフォームとので適応型セキュリティ アプライアンス（ASA）ソフトウェア（ASA）次世代侵入防御システム（NGIPS） （NGIPS）バーチャル、トラフィックは 2 タプル アルゴリズムの使用と鼻を鳴らすためにバランスをとられる負荷であり。 このアルゴリズムのための datapoints は次のとおりです:
ソフトウェア バージョン 5.3 の 3 タプル アルゴリズムか Firepower および FTD アプライアンスの下部の
すべての以前のバージョンで（5.3 または下部の）、トラフィックは鼻を鳴らすためにバランスをとられる 3 タプル アルゴリズムを使用する負荷です。 このアルゴリズムのための datapoints は次のとおりです:
同じのどのトラフィックでも出典、宛先および IP プロトコル Snort の同じ インスタンスにバランスをとられる負荷です。
Firepower および FTD アプライアンスのソフトウェア バージョン 5.4、6.0、およびより大きいの 5 タプル アルゴリズム
バージョン 5.4、6.0 またはより大きいで、トラフィックは 5 タプル アルゴリズムと鼻を鳴らすために balaned ロードです。 考慮に入れられる datapoints は次のとおりです:
- 送信元 IP
- 送信元ポート
- 宛先 IP
- 宛先ポート
- IP プロトコル
アルゴリズムにポートを追加する目的はトラフィックの大きい部分を占める特定の送信元および宛先ペアがあるときトラフィックのもっと均等にバランスをとることです。 ポートの付加によって、高位はかない送信元ポートはフローごとに異なり異なる snort 例にトラフィックのバランスをとる追加エントロピーをもっと均等に追加する必要があります。
総スループット
アプライアンスの総スループットは豊富な可能性にはたらくすべての snort 例の総スループットに基づいていました測定されます。 業界標準推奨事項はさまざまなオブジェクトのサイズの複数の HTTP 接続のためスループットを測定するためにです。 たとえば、NSS NGFW テストの手順は 44k、21k、10k、4.4k および 1.7k オブジェクトが付いているデバイスの総スループットを測定します。 これらは平均パケットサイズからののまわりで 1k 及び HTTP 接続に関連する他のパケットが理由でバイトへの 128 バイトの範囲に変換します。
個々の Snort 例のパフォーマンス評価を推定できます。 アプライアンスの定格 スループットを奪取 し、動作する Snort 例の数それを分けて下さい。 たとえばアプライアンスが 1k バイトの平均パケットサイズの IPS のための 10Gbps で評価されれば、およびそのアプライアンス Snort の 20 の例を、シングル インスタンスのためのおおよそ最大スループットです Snort ごとの 500 Mbps 持っています。 トラフィックの異なる型は、ネットワーク プロトコル、全面的なセキュリティポリシーの違いと共にパケットのサイズすべての影響デバイスの観察されたスループットできます。
サード パーティ ツール テスト結果
あらゆる速度テスト Webサイト、か帯域幅測定単位ツールによって、のような、iperf、1 大きい単一 ストリーム TCP フロー テストするとき生成されます。 大きい TCP フローのこの型はエレファント フローと呼ばれます。 エレファント フローは単一 セッション、帯域幅の大きいですか不均衡な量を消費する比較的長期ネットワーク接続です。 フローのこの型は 1 つの Snort 例に割り当てられます、従ってテスト結果は単一 snort 例のスループットを、アプライアンスのない総スループット 定格表示します。
観察された現象
観察された高い CPU
エレファント フローの別の目に見える効果は snort 例高い CPU である場合もあります。 これは示しますシェル「上」ツールとの非対称多重処理システム Inspect dp snort」を、またはを経て「見られる場合があります。
> show asp inspect-dp snort
SNORT Inspect Instance Status Info
Id Pid Cpu-Usage Conns Segs/Pkts Status tot (usr | sys)
-- ---- --------- ----- -------- ----------
0 48500 30% ( 28%| 1%) 12.4 K 0 READY
1 48474 24% ( 22%| 1%) 12.4 K 0 READY
2 48475 34% ( 33%| 1%) 12.5 K 1 READY
3 48476 29% ( 28%| 0%) 12.4 K 0 READY
4 48477 32% ( 30%| 1%) 12.5 K 0 READY
5 48478 31% ( 29%| 1%) 12.3 K 0 READY
6 48479 29% ( 27%| 1%) 12.3 K 0 READY
7 48480 23% ( 23%| 0%) 12.2 K 0 READY
8 48501 27% ( 26%| 0%) 12.6 K 1 READY
9 48497 28% ( 27%| 0%) 12.6 K 0 READY
10 48482 28% ( 27%| 1%) 12.3 K 0 READY
11 48481 31% ( 30%| 1%) 12.5 K 0 READY
12 48483 36% ( 36%| 1%) 12.6 K 0 READY
13 48484 30% ( 29%| 1%) 12.4 K 0 READY
14 48485 33% ( 31%| 1%) 12.6 K 0 READY
15 48486 38% ( 37%| 0%) 12.4 K 0 READY
16 48487 31% ( 30%| 1%) 12.4 K 1 READY
17 48488 37% ( 35%| 1%) 12.7 K 0 READY
18 48489 34% ( 33%| 1%) 12.6 K 0 READY
19 48490 27% ( 26%| 1%) 12.7 K 0 READY
20 48491 24% ( 23%| 0%) 12.6 K 0 READY
21 48492 24% ( 23%| 0%) 12.6 K 0 READY
22 48493 28% ( 27%| 1%) 12.4 K 1 READY
23 48494 27% ( 27%| 0%) 12.2 K 0 READY
24 48495 29% ( 28%| 0%) 12.5 K 0 READY
25 48496 30% ( 30%| 0%) 12.4 K 0 READY
26 48498 29% ( 27%| 1%) 12.6 K 0 READY
27 48517 24% ( 23%| 1%) 12.6 K 0 READY
28 48499 22% ( 21%| 0%) 12.3 K 1 READY
29 48518 31% ( 29%| 1%) 12.4 K 2 READY
30 48502 33% ( 32%| 0%) 12.5 K 0 READY
31 48514 80% ( 80%| 0%) 12.7 K 0 READY <<< CPU 31 is much busier than the rest, and will stay busy for while with elephant flow.
32 48503 49% ( 48%| 0%) 12.4 K 0 READY
33 48507 27% ( 25%| 1%) 12.5 K 0 READY
34 48513 27% ( 25%| 1%) 12.5 K 0 READY
35 48508 32% ( 31%| 1%) 12.4 K 0 READY
36 48512 31% ( 29%| 1%) 12.4 K 0 READY
$ top
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
69470 root 1 -19 9088m 1.0g 96m R 80 0.4 135:33.51 snort <<<< one snort very busy, rest below 50%
69468 root 1 -19 9089m 1.0g 99m R 49 0.4 116:08.69 snort
69467 root 1 -19 9078m 1.0g 97m S 47 0.4 118:30.02 snort
69492 root 1 -19 9118m 1.1g 97m R 47 0.4 116:40.15 snort
69469 root 1 -19 9083m 1.0g 96m S 39 0.4 117:13.27 snort
69459 root 1 -19 9228m 1.2g 97m R 37 0.5 107:13.00 snort
69473 root 1 -19 9087m 1.0g 96m R 37 0.4 108:48.32 snort
69475 root 1 -19 9076m 1.0g 96m R 37 0.4 109:01.31 snort
69488 root 1 -19 9089m 1.0g 97m R 37 0.4 105:41.73 snort
69474 root 1 -19 9123m 1.1g 96m S 35 0.4 107:29.65 snort
69462 root 1 -19 9065m 1.0g 99m R 34 0.4 103:09.42 snort
69484 root 1 -19 9050m 1.0g 96m S 34 0.4 104:15.79 snort
69457 root 1 -19 9067m 1.0g 96m S 32 0.4 104:12.92 snort
69460 root 1 -19 9085m 1.0g 97m R 32 0.4 104:16.34 snort
上述されていて 5 タプル アルゴリズムが長く住まれていたフローは同じ snort 例に常に送信 されます。 snort でアクティブな広範な AVC、IPS、ファイル、等ポリシーがあれば CPU は一定期間については snort 例で（>80%）高く見られる場合があります。 SSL ポリシーを追加してなお一層の増加 CPU使用は SSL 復号化の計算的に高い性質にします。
多くのの少数の高い CPU は snort CPU 重要なアラームのための原因ではないです。 それはフローに強度のパケット インスペクションの実行の NGFW システムの動作であり、これは自然に CPU の大きい部分を使用できます。 一般的なガイドラインとして、NGFW は重要な CPU 飢餓状況に snort CPU のほとんどが 95% にあり、95% に残り、パケットがドロップ見られているまでありません。
下記の治療はエレファント フローによる高い CPU 状況で助けます。
治療
インテリジェント な アプリケーション バイパス（IAB）
ソフトウェア バージョン 6.0 は IAB と呼ばれる新しい機能を導入します。 Firepower アプライアンスがあらかじめ定義されたパフォーマンスしきい値に達するとき、IAB 機能はインテリジェントにバイパスするために特定の条件を満たすフローを探します 検出エンジンの負荷を軽減する。
ヒント： IAB の設定に関する詳細はここに見つけることができます。
大きいフローを識別し、信頼して下さい
大きいフローは頻繁に高い使用低いインスペクション値トラフィックたとえば、バックアップ、データベース複製、先祖などと関連しています これらのアプリケーションの多数はインスペクションから寄与することができません。 大きいフローにおいての問題を避けるために、大きいフローを識別し、それらのためのアクセスコントロール信頼ルールを作成できます。 これらのルールは大きいフローを識別できましたりそれらのフローが uninspected 渡し、単一 snort 例 動作によって制限されないようにします。
注: 信頼ルールのための大きいフローを識別するために、Cisco Firepower TAC に連絡して下さい。
関連情報
フィードバック