Comment dépanner haut à DP CPU cause du IPSEC trafic

30751

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

Objective

Parfois, une quantité élevée de IPSEC trafic peut causer des problèmes de DP ressources. IPSEC Le trafic est géré différemment en fonction des plates-formes et du type de IPSEC trafic. Cet article explique comment vérifier que c’est le IPSEC problème de cause de trafic.

Procedure

Cas 1 : IPSEC Passthrough

Pour IPSEC Passthrough on PA-3000 et , le trafic finira toujours sur depuis le processeur de PA-5000 DP déchargement ne peut pas correspondre session avec les ESP paquets entrants qui ont des SPI valeurs, mais pas de ports.
Pour IPSEC Passthrough on PA-7000 , et , les PA-5200 PA-3200 processeurs de déchargement peuvent gérer ESP le trafic car ils peuvent faire correspondre les valeurs avec les flux et donc le SPI déchargement fonctionnera. Il en va de même pour GRE le AH trafic.
Pour les plates-formes où le processeur de déchargement ESP enverra du trafic à , il est facile à exécuter à pleine capacité au cas DP où il ya une grande quantité de trafic, même si la plate-forme a un processeur de déchargement à utiliser.
Dans de tels cas, les sessions port 20033 peut-être très longue durée de vie et peut donc ne pas apparaître dans les journaux de trafic et peut donc échapper à l’avis de l’administrateur du réseau qui tente d’évaluer ACC les rapports pour déterminer les applications les plus utilisées.
Nous devrions vérifier les sessions avec une longue durée de vie ou un grand nombre d’octets:

> session d’exposition tous les filtres min-kb 1000000 (pour vérifier les sessions avec des données de 100m)

Affaire 2: IPSEC Terminé à Palo Alto

Dans ce cas, les IPSEC sessions auront toujours des numéros de port dérivés de SPI et tous les paquets viendront de toute façon à depuis le DP cryptage, décryptage doit être effectué.
En outre, vous n’obtiendrez pas toujours des journaux de trafic pour IPSEC-ESP les sessions.
Dans le cas où la quantité de trafic IPSEC à travers les tunnels est élevé, puis son facile à courir dans les problèmes de capacité. Veuillez consulter les fiches de données pour connaître les différents numéros de capacité. Ex: Fiches techniques
Comme dans le cas 1 journaux de trafic et ACC peut ne pas être très utile puisque ces journaux ne sont générés qu’une fois une session se termine, IPSEC et les tunnels peuvent avoir une longue durée de vie. Par exemple, jetez un oeil à ACC l’instantané suivant, où le trafic maximum est affiché SSL comme et tunnel crypté ne s’affiche comme une petite quantité de trafic comparativement.

Dans ce cas, nous pouvons voir CPU est d’environ 60%:

2018-09-19 16:14:40.823 +1000 --- panio
:
:Données d’échantillonnage de suivi des ressources (par seconde):
: échantillonnage de charge par groupe :
CPU
: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%: charge

CPU (%) au cours des 15 dernières secondes:
:core 0 1 2 3 4 5
: 0 48 59 59 58
: 0 48 59 60 59 59
: 0 54 64 64 64 64 6 4
: 0 57 67 67 67 67
: 0 53 63 64 64
: 0 49 61 62 61 61
: 0 46 60 60 60 60 6
Tél. : 0 39 53 54 53 53
: 0 43 55 55 55
: 0 49 60 60 60 60
: 0 49 61 60 60 60
Tél. : 0 44 57 57 57 57
: 0 38 53 52 52
: 0 39 54 54 54 54
: 0 45 59 59 59 59

La façon la plus simple de le savoir est de vérifier la sortie de « débog dataplane pow performance » qui indique un résumé de quelle fonction consomme combien de cycles et quel est le temps de CPU traitement moyen. Dans ce cas, regardez la sortie à partir d’un cas :

:func max. proc nous ave. proc nous compter
:d fa_match 0 0
0 :p olicy_lookup 21343 15 2605518:user_group_policy
5639 1 876821:get_gid
5038 0 1257441:regex_lookup
ecdhe_key_gen 3215 10 4028529
:regex_postfpga 462 6 827546
:reg_expr_match 0 0
:sml_vm 199 < Related to Layer 7    4 44650282
: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:rsa_operation_priv_enc 0 0
0:rsa_operation_priv_dec 8282 8179
56:rsa_key_gen 0 0:rsa_RSA_sign
0 0
0:rsa_RSA_verify 0 0 ecdhe_key_gen
0 0
:ecdhe_key_gen_mul 00
0:ecdhe_key_compute_mul 0
0:ecdhe_key_compute 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
:d he_gen_para 0 0 0
:d he_gen_key 0 0 0
:d he_key_compute 0 0 0
:bn_mod_exp 8252 8151 56
:cipher_enc 51 4 211819
:zip_deflate 36 1 164908
:p ktlog_log 13 12 2
:p ktlog_send 0 0 0
:tunnel_encap 67 10 14498723 < Related to tunnel
:tunnel_decap 605 28 < Related to tunnel    10978906
:tunnel_esp 51 2 8831828
:tunnel_esp_decap 587 13 10705421 < Related to tunnel
:tunnel_ah_decap 0 0
0:tunnel_ah 61 4 8978189 < Related to tunnel
:tunnel_fwd 17 2 6426
:tunnel_prepare 44 1 9010166 < Related to tunnel
:tunnel_post 51 1 8905132:appid_result
0 0 00
:ctd_token 16291 79 3910573
:d os_update 0 0 399222
:urlcache_update 10010 225 411
:urlcache_lookup 2433 89 100202:urlcache_insert
0 0 0:urlcache_delete
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:age_arp
15 3 600:age_pbf_ret_mac
1 0 600:stack_trace
0 0:ctd_pw_check
0 0:ctd_pw_md4
0 0 0 0:ctd_pw_extract
0:ctd_pw_extract 0 0
:p rl_rewrite 0 0 0
:p kt_rewrite 0 0
0:vpn_send_to_client 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

De là, nous pouvons avoir une idée que les CPU cycles maximum vont dans la manipulation du tunnel avec la couche 7.
Lors d’une vérification plus complète, il a été constaté que la majorité SSL du trafic pour cette affaire, allait dans les IPSEC tunnels, il suffirait donc de compter la quantité de trafic d’application allant dans le tunnel, puis comparer avec les numéros de capacité.

> session afficher tous les filtres au nombre de proxys oui < proxy here is the name of zone for tunnel interfaces in this case. Filtre peut différer selon le
nombre requis de sessions qui correspondent filtre: 42118

> afficher la session tous lesfiltres comptent oui Nombre de sessions
qui correspondent filtre: 53523

Nous pouvons voir ci-dessus qu’environ 80% du total des sessions passaient par IPSEC .
Débit tel que vérifié à partir de « afficher les informations de session »

:target-dp: *.dp0
:-------------------------------------------------------------------------------- :Nombre de sessions prises en
charge: 524286 :Nombre de
sessions allouées: 57011 :Nombre de
sessions TCP actives: 51355
:Nombre de sessions UDP actives: 3736
:Nombre de sessions ICMP actives: 111:Nombre
de sessions GTPc actives: 0
:Nombre de sessions GTPu actives: 0
:Nombre de sessions GTPu en attente: 0
:Nombre de sessions BCAST
actives: 0:Nombre de MCAST sessions
actives: 0:Nombre de sessions de prévision actives: 317:Utilisation
de la table de session: 10% :Nombre de sessions créées
depuis le démarrage: 178684165
:P l’utilisation de la table de session: 93096/s
:Débit: 703278 kbps < i.e. around 700 mbps
:Nouvelle connexion établir le taux: 542 cps

Depuis ~ 80% sessions sont via IPSEC , nous pouvons nous rapprocher que d’environ 500 à 550 mbps données peut-être passer par IPSEC .Si nous comparons avec PA-3060 les nombres IPSEC VPN de capacité, le débit est d’environ 500 mbps.
Dans ce cas, il ya l’inspection de la couche 7 et d’autres processus sont également en cours.

Additional Information

Lire Traitement du trafic IPSec pass-through sur les réseaux de Palo Alto firewall et Que représentent les numéros de port dans une IPSEC-ESP session ?

Comment dépanner haut à DP CPU cause du IPSEC trafic

Objective

Procedure

Additional Information

Other users also viewed: