高値のトラブルシューティング方法DP CPUなぜならIPSEC渋滞

高値のトラブルシューティング方法DP CPUなぜならIPSEC渋滞

30757
Created On 12/13/18 08:58 AM - Last Modified 03/02/23 02:32 AM


Objective


時には多額のIPSECトラフィックが引き起こす可能性がありますDPリソースの問題。 IPSEC トラフィックは、プラットフォームとタイプに基づいて異なる方法で処理されますIPSEC渋滞。 この記事では、IPSEC問題を引き起こすトラフィック。

Procedure


ケース 1:IPSECパススルー
  1. ためにIPSECパススルーオンPA-3000とPA-5000、トラフィックは常に終了しますDPオフロード プロセッサはセッションを着信と一致させることができないためESP持っているパケットSPI値はありますが、ポートはありません。
  2. ためにIPSECパススルーオンPA-7000、PA-5200とPA-3200、オフロード プロセッサが処理できるESP一致するトラフィックSPIフローを伴う値、したがってオフロードは機能します。 同じことが当てはまりますGREとAH渋滞。
  3. オフロード プロセッサが送信するプラットフォームの場合ESPへのトラフィックDPプラットフォームに使用するオフロード プロセッサがある場合でも、大量のトラフィックがある場合は、キャパシティで簡単に実行できます。
  4. このような場合、ポート 20033 のセッションは非常に長く存続している可能性があるため、トラフィック ログに表示されず、評価しようとしているネットワーク管理者の通知を逃れる可能性があります。ACC使用頻度の高いアプリケーションを特定するためのレポート。
  5. 寿命が長いか、バイト数が膨大なセッションをチェックする必要があります。
> セッションを表示 すべてのフィルタ min-kb 100000 (100m データでセッションを確認するため)


ケース 2:IPSECパロアルトで終了
  1. この場合、IPSECセッションには常に SPI から派生したポート番号があり、すべてのパケットはいずれにせよDP暗号化されているため、復号化を実行する必要があります。
  2. さらに、常にトラフィック ログを取得できるとは限りません。IPSEC-ESPセッション。
  3. 通過するトラフィック量の場合IPSECトンネルが高いため、容量の問題が発生しやすくなります。 さまざまな容量の数値については、データシートを参照してください。 例えば:データシート
  4. ケース 1 のトラフィック ログと同様に、ACCこれらのログはセッションが終了したときにのみ生成されるため、あまり役に立たない可能性があります。IPSECトンネルの寿命は長いかもしれません。 たとえば、次を見てください。ACC最大トラフィックが次のように表示されるスナップショットSSL暗号化されたトンネルは、比較的少量のトラフィックとしてのみ表示されます。
ユーザーが追加した画像
  1. この場合、私たちは見ることができますCPUは約 60% です。
2018-09-19 16:14:40.823 +1000 --- パニオ
:
:リソース監視サンプリングデータ(1秒あたり):
:
:CPUグループごとの負荷サンプリング:
:flow_lookup: 60%
:flow_fastpath: 58%
:flow_slowpath: 60%
:flow_forwarding: 60%
:flow_mgmt : 49%
:flow_ctrl: 49%
:nac_result: 60%
:flow_np: 58%
:dfa_result: 60%
:module_internal: 60%
:aho_result : 60%
:zip_result: 60%
:pktlog_forwarding: 59%
:lwm: 0%
:flow_host: 57%
:
:CPU最後の 15 秒間の負荷 (%):
:コア 0 1 2 3 4 5
: 0 48 59 59 59 58
: 0 48 59 60 59 59
: 0 54 64 64 64 64
: 0 57 67 67 67 67
: 0 53 63 64 64 64
: 0 49 61 62 61 61
: 0 46 60 60 60 60
: 0 39 53 54 53 53
: 0 43 55 55 55 55
: 0 49 60 60 60 60
: 0 49 61 60 60 60
: 0 44 57 57 57 57
: 0 38 53 52 52 52
: 0 39 54 54 54 54
: 0 45 59 59 59 59
 
  1. 見つける最も簡単な方法は、「debug dataplane pow performance」の出力をチェックすることです。CPUサイクルと平均処理時間。 この場合、1 つのインスタンスからの出力を見てください。
:関数最大proc us ave. proc us count
:dfa_match 0 0 0
:policy_lookup 21343 15 2605518
:user_group_policy 5639 1 876821
:get_gid 5038 0 1257441
:regex_lookup 3215 10 4028529
:regex_postfpga 462 6 827546
:reg_expr_match 0 0 0
:sml_vm 199 4 44650282 <<<<<<<<<<< レイヤー 7 関連
:detector_run_p1 1203 13 1336837
:detector_run_p2 11610 19 1369137
:ssl_proxy_proc 8512 17 158104
:ssl_encode 76 27 98267
:rsa_operation_pub_enc 0 0 0
:rsa_operation_pub_dec 0 0 0
:rsa_operation_priv_enc 0 0 0
:rsa_operation_priv_dec 8282 8179 56
:rsa_key_gen 0 0 0
:rsa_RSA_sign 0 0 0
:rsa_RSA_verify 0 0 0
:ecdhe_key_gen 0 0 0
:ecdhe_key_gen_mul 0 0 0
:ecdhe_key_compute_mul 0 0 0
:ecdhe_key_compute 0 0 0
:ecdhe_generate_xchg_key 0 0 0
:ecdhe_gen_key_exchange_msg 0 0 0
:ecdhe_get_key_exchange_msg 0 0 0
:ecdhe_parse_server_key_exchange_msg 0 0 0
:ecdhe_gen_server_key_exchange_msg 0 0 0
:dhe_gen_para 0 0 0
:dhe_gen_key 0 0 0
:dhe_key_compute 0 0 0
:bn_mod_exp 8252 8151 56
:cipher_enc 51 4 211819
:zip_deflate 36 1 164908
:pktlog_log 13 12 2
:pktlog_send 0 0 0
:tunnel_encap 67 10 14498723 <<<<<<<<<<< トンネル関連
:tunnel_decap 605 28 10978906 <<<<<<<<<<< トンネル関連

:tunnel_esp 51 2 8831828
:tunnel_esp_decap 587 13 10705421 <<<<<<<<<<< トンネル関連
:tunnel_ah_decap 0 0 0
:tunnel_ah 61 4 8978189 <<<<<<<<<<< トンネル関連
:tunnel_fwd 17 2 6426
:tunnel_prepare 44 1 9010166 <<<<<<<<<<< トンネル関連
:tunnel_post 51 1 8905132
:appid_result 0 0 0
:ctd_token 16291 79 3910573
:dos_update 0 0 399222
:urlcache_update 10010 225 411
:urlcache_lookup 2433 89 100202
:urlcache_insert 0 0 0
:urlcache_delete 0 0 0
:urlcache_lru 0 0 0
:session_install 53 6 399309
:session_age 39 0 1639088
:session_delete 64 9 399215
:session_purge 47 3 395786
:inline_switch 0 0 0
:age_arp 15 3 600
:age_pbf_ret_mac 1 0 600
:stack_trace 0 0 0
:ctd_pw_check 0 0 0
:ctd_pw_md4 0 0 0
:ctd_pw_extract 0 0 0
:prl_rewrite 0 0 0
:pkt_rewrite 0 0 0
:vpn_send_to_client 0 0 0
:vpn_cookie_response 0 0 0
:raven_match 39 3 16839
:raven_match_header 7 3 2272
:raven_match_body 8 3 32
:raven_sig_get_action 0 0 0
:age_mfib 1 0 600

  1. ここから、最大のアイデアを得ることができますCPUサイクルは、レイヤ 7 とともにトンネル処理に入ります。
  2. さらに確認したところ、大多数のSSLこのケースのトラフィックはIPSECしたがって、トンネルに入るアプリケーション トラフィックの量を数えて、容量の数値と比較するだけで十分です。

>プロキシ カウントへのすべてのフィルターをセッションに表示するはい<<<<<< proxy ここで、この場合のトンネル インターフェイスのゾーンの名前です。 フィルターは必要に応じて異なる場合があります
フィルターに一致するセッションの数: 42118

> セッションのすべてのフィルター数を表示するはい
フィルターに一致するセッションの数: 53523
  1. 合計セッションの約 80% が経由していたことがわかります。IPSEC .
  2. 「show session info」で確認したスループット

:ターゲット-dp: *.dp0
:---------------------------------------------------------------- -------------------------------
:サポートされているセッション数: 524286
:割り当てられたセッションの数: 57011
:アクティブ数TCPセッション: 51355
:アクティブ数UDPセッション: 3736
:アクティブ数ICMPセッション: 111
:アクティブな GTPc セッションの数: 0
:アクティブな GTPu セッションの数: 0
:保留中の GTPu セッションの数: 0
:アクティブ数BCASTセッション: 0
:アクティブ数MCASTセッション: 0
:アクティブな予測セッションの数: 317
:セッション テーブル使用率: 10%
:起動後に作成されたセッションの数: 178684165
:パケットレート: 93096/s
:スループット: 703278 kbps <<<<<<< つまり、約 700 mbps
:新規接続確立レート: 542 cps
  1. 約 80% のセッションが経由しているためIPSEC、約 500 ~ 550 mbps のデータがおそらく経由していると概算できますIPSEC.と比較するとPA-3060容量番号IPSEC VPNスループットは約 500 mbps です。
  2. この場合、レイヤ 7 インスペクションとその他の処理も進行中です。


Additional Information


読むPalo Alto Networks での IPSec パススルー トラフィックの処理firewallポート番号は何ですかIPSEC-ESPセッション代表?

Actions
  • Print
  • Copy Link

    https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000CmQvCAK&lang=ja&refURL=http%3A%2F%2Fknowledgebase.paloaltonetworks.com%2FKCSArticleDetail

Choose Language