So beheben Sie hohe DP CPU Fehler aufgrund des IPSEC Datenverkehrs

30749

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

Objective

Manchmal kann ein hoher IPSEC Datenverkehr DP zu Ressourcenproblemen führen. IPSEC Der Datenverkehr wird je nach Plattform und Der Art des Datenverkehrs unterschiedlich IPSEC gehandhabt. In diesem Artikel wird erläutert, wie Sie überprüfen, ob es sich um das Problem handelt, das den IPSEC Datenverkehr verursacht.

Procedure

Fall 1: IPSEC Passthrough

Bei IPSEC Passthrough on PA-3000 und wird der Datenverkehr immer PA-5000 eingeschaltet, da der DP Offload-Prozessor die Sitzung nicht mit den eingehenden Paketen übereinstimmen kann, die ESP SPI Werte, aber keine Ports haben.
Bei IPSEC Passthrough on PA-7000 und können PA-5200 die PA-3200 Abladeprozessoren Datenverkehr verarbeiten, ESP da sie Werte mit den Flows abgleichen SPI können, und somit funktioniert die Auslagerung. Gleiches gilt für GRE und AH Verkehr.
Für Plattformen, auf denen der Offload-Prozessor ESP Datenverkehr an DP sendet, ist es einfach, an der Kapazität zu laufen, falls es einen hohen Datenverkehr gibt, obwohl die Plattform über einen Offload-Prozessor verfügt.
In solchen Fällen, die Port 20033 Sitzungen vielleicht sehr lange gelebt und daher möglicherweise nicht in Datenverkehrsprotokollen erscheinen und kann daher die Benachrichtigung von Netzwerk-Admin, die versucht, Berichte für die Bestimmung der am besten verwendeten Anwendungen zu bewerten ACC entnehmen.
Wir sollten nach Sitzungen mit langer Lebensdauer oder einer großen Anzahl von Bytes suchen:

> alle Filter min-kb 100000 anzeigen (um Sitzungen mit 100m Daten zu überprüfen)

Fall 2: IPSEC Beendet auf Palo Alto

In diesem Fall werden die IPSEC Sitzungen immer Portnummern von SPIs abgeleitet haben und alle Pakete werden sowieso kommen, DP da die Verschlüsselung, Entschlüsselung muss durchgeführt werden.
Darüber hinaus erhalten Sie nicht immer Datenverkehrsprotokolle für IPSEC-ESP Sitzungen.
Falls der Verkehr durch IPSEC Tunnel hoch ist, dann ist es einfach, in Kapazitätsprobleme zu laufen. Bitte beachten Sie die Datenblätter, um verschiedene Kapazitätsnummern zu kennen. z.B.: Datenblätter
Wie in Fall 1 ist der Datenverkehr ACC möglicherweise nicht sehr hilfreich, da diese Protokolle erst nach Ende einer Sitzung generiert werden und IPSEC Tunnel möglicherweise eine lange Lebensdauer haben. Sehen Sie sich beispielsweise den folgenden ACC Snapshot an, in dem maximaler Datenverkehr als angezeigt wird SSL und der verschlüsselte Tunnel nur als kleine Menge an Datenverkehr im Vergleich angezeigt wird.

In diesem Fall können wir CPU sehen, ist etwa 60%:

2018-09-19 16:14:40.823 +1000 --- panio
:
:Ressourcenüberwachung Stichprobendaten (pro Sekunde):
: :
CPU Lastprobenahme nach Gruppen:
:flow_lookup : 60%
:flow_fastpath : 58%
:flow_slowpath : 60%
:flow_forwarding : 60%
:flow_mgmt : 4 9%
:flow_ctrl : 49%
:nac_result : 60%
:flow_np : 58%
:d fa_result : 60%
:module_internal : 60%
:aho_result : 60%
:zip_result : 60%
:p ktlog_forwarding : 59%
:lwm : 0%
:flow_host : 57%
: : Last
CPU (%) während der letzten 15 Sekunden:
:core 0 1 2 3 4 5
: 0 48 59 59 58
: 0 48 59 60 59 59
: 0 54 64 64 64
: 0 57 67 67 67 67 67
67 67 : 0 53 63 64 64
: 0 49 61 62 61 61
: 0 46 60 60 60 60 60
: 0 39 53 54 53 53
: 0 43 55 55
55 : 0 49 60 60 60 60
60 : 0 49 61 60 60 60
: 0 44 57 57 57
: 0 38 53 52 52
: 0 39 54 54 54 54
54 : 0 45 59 59 59 59 59

Der einfachste Weg, um herauszufinden, ist die Ausgabe von "debug dataplane pow performance" zu überprüfen, die eine Zusammenfassung der Funktion sagt, die wie viele Zyklen verbraucht CPU und was die durchschnittliche Verarbeitungszeit ist. Sehen Sie sich in diesem Fall die Ausgabe einer Instanz an:

:func max. proc us ave. proc uns zählen
:d fa_match 0 0
0 :p olicy_lookup 21343 15 2605518
:user_group_policy 5639 1 876821
:get_gid 5038 0 12574 41
:regex_lookup 3215 10 4028529
:regex_postfpga 462 6 827546
:reg_expr_match 0 0
0 0 :sml_vm 199 4 44650282 < Related to Layer 7
:d etector_run_P1 1203 13 1336837
:d etector_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 0
:rsa_operation_priv_dec 8282 8179 56
:rsa_key_gen 0 0 0 0
:rsa_RSA_sign 0 0 0
:rsa_RSA_verify 0 0 0 0
:ecdhe_key_gen 0 0 0 0
:ecdhe_key_gen_mul 0 0
0 0 :ecdhe_key_compute_mul 0 0
0 0 :ecdhe_key_compute 0 0 0
:ecdhe_generate_xchg_key 0 0 ecdhe_gen_key_exchange_msg 0
0 0 0
:ecdhe_get_key_exchange_msg 0 0
:ecdhe_parse_server_key_exchange_msg 0 0 0 0
:ecdhe_gen_server_key_exchange_msg 0 0 0
:d he_gen_para 0 0
0 0 :d he_gen_key 0 0 0
0 :d he_key_compute 0 0 0
0 0 :bn_mod_exp 8252 8151 56
:cipher_enc 51 4 2118 19
:zip_deflate 36 1 164908
:p ktlog_log 13 12 2
:p ktlog_senden 0 0
0 :tunnel_encap 67 10 14498723 < Related to tunnel
:tunnel_decap 605 28 10978906 < Related to tunnel
:tunnel_esp 51 2 8831828
:tunnel_esp_decap 587 13 10705421 < Related to tunnel
:tunnel_ah_decap 0 0
0 0 :tunnel_ah 61 < Related to tunnel    4 8978189
:tunnel_fwd 17 2 6426
:tunnel_prepare 44 1 9010166 < Related to tunnel
:tunnel_post 51 1 8905132
:appid_result 0 0 0 0
:ctd_token 16291 79 3910573
:d os_update 0 0 399222
:urlcache_update 10010 225 411
:urlcache_lookup 2433 89 10 0202
:urlcache_insert 0 0 0
:urlcache_delete 0 0 0 0
:urlcache_lru 0 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 0
:age_arp 15 3 600
:age_pbf_ret_mac 1 0 600
:stack_trace 0 0 ctd_pw_check 0 0 0 0
0 0 0 0 0 0 ctd_pw_md4 0 0 0 0 0 0 0 0

ctd_pw_extract
0 0 :p rl_rewrite 0 0
0 :p kt_rewrite 0 0
0 :vpn_send_to_client 0 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 0
:age_mfib 1 0 600

Von hier aus können wir eine Vorstellung davon bekommen, dass maximale Zyklen zusammen mit Layer 7 in die CPU Tunnelhandhabung gehen.
Bei der weiteren Überprüfung wurde festgestellt, dass der größte Teil des SSL Verkehrs für diesen Fall in Tunnel geleitet wurde, so dass es ausreichen IPSEC würde, die Menge des Anwendungsverkehrs, der in den Tunnel fließt, zu zählen und dann mit den Kapazitätsnummern zu vergleichen.

> zeigen Sitzung alle Filter, um Proxy-Anzahl ja < proxy here is the name of zone for tunnel interfaces in this case. Filter kann je nach Bedarf abweichen
Anzahl der Sitzungen, die mit Filter übereinstimmen: 42118

> zeigen Sitzung alle Filteranzahl ja Anzahl der Sitzungen, die Filter
entsprechen: 53523

Wir können oben sehen, dass etwa 80% der gesamten Sitzungen über IPSEC gingen.
Durchsatz wie aus "Show-Sitzungsinfo" geprüft

:target-dp: *.dp0
:--------------------------------------------------------------------------------
:Anzahl der unterstützten Sitzungen: 524286
:Anzahl der zugewiesenen Sitzungen: 57011
:Anzahl der TCP aktiven Sitzungen: 51355
:Anzahl der aktiven UDP Sitzungen: 3736
:Anzahl der aktiven ICMP Sitzungen: 111
:Anzahl der aktiven GTPc-Sitzungen: 0
:Anzahl der aktiven GTPu-Sitzungen: 0
:Anzahl der ausstehenden GTPu-Sitzungen: 0
:Anzahl der aktiven BCAST Sitzungen: 0
:Anzahl der aktiven MCAST Sitzungen: 0
:Anzahl der aktiven Vorhersagesitzungen: 317
:Sitzungstabellenauslastung: 10% :Anzahl der seit dem
Booten erstellten Sitzungen: 178684165
:P acket Rate: 93096/s
:Durchsatz: 703278 kbps < i.e. around 700 mbps
:Neue Verbindungs-Establish-Rate: 542 cps

Da 80 % der Sitzungen über IPSEC sind, können wir ungefähr nähern, dass etwa 500 bis 550 Mbit/s Daten möglicherweise über IPSEC gehen.Wenn wir mit PA-3060 Kapazitätszahlen vergleichen, beträgt der IPSEC VPN Durchsatz etwa 500 Mbit/s.
In diesem Fall wird Die Inspektion der Schicht 7 und eine andere Verarbeitung durchgeführt.

Additional Information

Lesen Sie Verarbeitung von IPSec-Passthrough-Datenverkehr in den Palo Alto-Netzwerken firewall und Was stellen die Portnummern in einer IPSEC-ESP Sitzung dar?

So beheben Sie hohe DP CPU Fehler aufgrund des IPSEC Datenverkehrs

Objective

Procedure

Additional Information

Other users also viewed: