Cómo solucionar problemas altos debido al DP CPU IPSEC tráfico

Cómo solucionar problemas altos debido al DP CPU IPSEC tráfico

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


Objective


A veces, la alta cantidad de IPSEC tráfico puede causar un problema de DP recursos. IPSEC El tráfico se maneja de manera diferente en función de las plataformas y del tipo de IPSEC tráfico. En este artículo se explica cómo comprobar que es el problema de causante del IPSEC tráfico.

Procedure


Caso 1: IPSEC Passthrough
 
  1. Para IPSEC passthrough on PA-3000 y , el tráfico siempre terminará encendido puesto que el procesador de descarga no puede hacer juego PA-5000 la sesión con los paquetes DP ESP entrantes que tienen valores pero no SPI puertos.
  2. Para IPSEC Passthrough on PA-7000 y , los PA-5200 PA-3200 procesadores de descarga pueden controlar el ESP tráfico, ya que pueden hacer coincidir Valores SPI con los flujos y, por lo tanto, la descarga funcionará. Lo mismo se aplica para GRE y AH el tráfico.
  3. Para las plataformas donde el procesador de descarga enviará ESP tráfico a , es fácil de ejecutar a su capacidad en caso de que haya una alta cantidad DP de tráfico a pesar de que la plataforma tiene un procesador de descarga para utilizar.
  4. En tales casos, las sesiones del puerto 20033 tal vez muy larga vida y por lo tanto pueden no aparecer en los registros de tráfico y por lo tanto puede eludir el aviso del administrador de red que está tratando de evaluar ACC los informes para determinar las aplicaciones más utilizadas.
  5. Debemos comprobar si hay sesiones con larga vida útil o un gran número de bytes:
> mostrar sesión todo filtro min-kb 100000 (para comprobar sesiones con datos de 100m)


Caso 2: IPSEC Terminado en Palo Alto
 
  1. En este caso, las IPSEC sesiones siempre tendrán números de puerto derivados de las API y todos los paquetes llegarán de todos modos DP ya que el cifrado, el descifrado necesita ser realizado.
  2. Además, no siempre obtendrá registros de tráfico para IPSEC-ESP las sesiones.
  3. En caso de que la cantidad de tráfico a través de IPSEC túneles es alta, entonces su fácil de correr en los problemas de capacidad. Consulte las hojas de datos para conocer varios números de capacidad. Ej: Hojas de datos
  4. Como en el caso 1, los registros de tráfico y ACC pueden no ser muy útiles puesto que estos registros se generan solamente una vez que termina una sesión, y los IPSEC túneles pueden tener una larga vida útil. Por ejemplo, eche un vistazo a la siguiente ACC instantánea, donde el tráfico máximo se muestra como SSL y el túnel cifrado se muestra solamente como una pequeña cantidad de tráfico comparativamente.
Imagen de usuario añadido
  1. En este caso podemos ver CPU que es alrededor del 60%:
2018-09-19 16:14:40.823 +1000 --- panio
:
:Datos de muestreo de monitoreo de recursos (por segundo):
: :
CPU muestreo de carga por grupo:
:flow_lookup : 60%
:flow_fastpath : 58%
:flow_slowpath : 60%
:flow_forwarding : 60%
:flow_mgmt : 49%
: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%
: load
CPU (%) durante los últimos 15 segundos:
:core 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
: 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. La forma más fácil de averiguarlo es comprobar la salida del "rendimiento pow del plan de datos de depuración", que indica un resumen de qué función está consumiendo cuántos ciclos y cuál es el tiempo medio de CPU procesamiento. En este caso, mire la salida de una instancia:
:func max. proc nosotros ave. proc nosotros contamos
: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 3215 10 4028529
:regex_postfpga 462 6 827546
:reg_expr_match 0 0 0
:sml_vm < Related to Layer 7        199 4 44650282
:d etector_run_p1 1203 120313 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 :rsa_operation_priv_dec 8282 8179 56
:rsa_key_gen 0 0 0
:rsa_RSA_sign 0 0
:rsa_RSA_verify 0 0 0
:ecdhe_key_gen 0 0
:ecdhe_key_gen_mul 0 0 0
:ecdhe_key_compute_mul 0 0
:ecdhe_key_compute 0 0 0
:ecdhe_generate_xchg_key 0 0
:ecdhe_gen_key_exchange_msg 0 0 0
:ecdhe_get_key_exchange_msg 0 0
:ecdhe_parse_server_key_exchange_msg 0 0 0
:ecdhe_gen_server_key_exchange_msg 0 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 156
:cipher_enc 51 4 211819
:zip_deflate 36 1 164908
:p ktlog_log 13 12 2
:p ktlog_send 0 0 0
:tunnel_encap 6710 14498723 < Related to tunnel
:tunnel_decap 605 28 10978906 < Related to tunnel     

:tunnel_esp 51 2 8831828
:tunnel_esp_decap < Related to tunnel  587 13 10705421
: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 0 00
:ctd_token 16291 79 3910573
:d os_update 0 0 0 399222
:urlcache_update 10010 225 411
:urlcache_lookup 2433 89 100202
:urlcache_insert 0 00 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
:ctd_pw_md4 0 0 0
:ctd_pw_extract 0 0 0
:p rl_rewrite 0 0 0
:p kt_rewrite 0 0 0
:vpn_send_to_client 0 0 0
:vpn_cookie_response 0 0 0
:raven_match 39 03 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. Desde aquí podemos tener la idea de que los ciclos máximos CPU están entrando en el manejo del túnel junto con la capa 7.
  2. En la comprobación posterior se encontró que la mayoría del SSL tráfico para este caso, estaba entrando en IPSEC túneles, por lo que sería suficiente contar la cantidad de tráfico de aplicación que entra en el túnel y luego comparar con los números de capacidad.

> mostrar sesión todo el filtro al recuento de proxy sí    < proxy here is the name of zone for tunnel interfaces in this case. El filtro puede diferir como número requerido
de sesiones que coinciden con el filtro: 42118

> mostrar sesión todo el recuento de filtros sí Número de sesiones que coinciden con el
filtro: 53523
  1. Podemos ver arriba que alrededor del 80% del total de sesiones se estaban llevando a través IPSEC de .
  2. Rendimiento según lo comprobado desde "mostrar información de la sesión"

:target-dp: *.dp0
:--------------------------------------------------------------------------------
:Número de sesiones admitidas: 524286
:Número de sesiones asignadas: 57011
:Número de TCP sesiones activas: 51355
:Número de sesiones UDP activas: 3736
:Número de sesiones ICMP activas: 111
:Número de sesiones GTPc activas: 0
:Número de sesiones GTPu activas: 0
:Número de sesiones GTPu pendientes:0
:Número de sesiones BCAST activas: 0
:Número de sesiones MCAST activas: 0
:Número de sesiones de predicción activas: 317 :Utilización de
la tabla de sesiones: 10%
:Número de sesiones creadas desde el arranque: 178684165
:P acket velocidad: 93096/s
:Rendimiento: 703278 kbps < i.e. around 700 mbps
:Nueva velocidad de establecimiento de conexión: 542 cps
  1. Dado ~ 80% sesiones son a través IPSEC de, podemos aproximar que alrededor de 500 a 550 mbps datos tal vez van a través de IPSEC .Si comparamos con PA-3060 los números IPSEC VPN de capacidad, el rendimiento es de alrededor de 500 mbps.
  2. En este caso hay inspección de la capa 7 y otro procesamiento también en curso.


Additional Information


Lea Procesamiento de tráfico de paso IPSec en Palo Alto Networks firewall y ¿Qué representan los números de puerto en una IPSEC-ESP sesión?

Actions
  • Print
  • Copy Link

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

Choose Language