Resolución de problemas de degradación del índice de éxito de la conexión inicial en ePDG

Introducción

Este documento describe los problemas relacionados con la degradación del índice de éxito de la conexión inicial (ASR) en Evolved Packet Data Gateway (ePDG).

Overview

El ASR inicial es una métrica vital que indica la tasa de éxito del número total de intentos de configuración de sesión.

La fórmula del indicador clave de rendimiento (KPI) contiene el número total de intentos de configuración de sesión ePDG y el número total de aciertos de configuración de sesión ePDG. Si el número de intentos correctos disminuye, se degrada todo el KPI.

Comprobaciones previas básicas

Para la funcionalidad ePDG, Seguridad de protocolo de Internet (IPsec) es el proceso que se encarga de las transacciones de IPsec. Por lo tanto, para cualquier caso de ePDG, se deben seguir algunas de las comprobaciones previas antes de proceder a solucionar el problema.

1. Verifique el estado de la tarjeta DPC mientras ipsecmgr se ejecuta en estas tarjetas. Las tarjetas DPC deben estar en estado activo (excepto las tarjetas en espera).

show card table

2. Verifique el estado de los recursos para cada uno de ellos sessmgr/ipsecmgr  a fin de revisar si se observa algún patrón anormal de flujo de tráfico en términos del número de sesiones por tarjeta o si estos procesos están en estado sessmgr/ipsecmgr  de advertencia/sobre. Por ejemplo, en este resultado, verá ipsecmgr está en overestado como se muestra aquí.

[local]abc# show task resources | grep -v good Thursday January 19 19:41:15 UTC 2023 task cputime memory files sessions cpu facility inst used allc used alloc used allc used allc S status ----------------------- ----------- ------------- --------- ------------- ------ 3/0 ipsecmgr 261 0.28% 75% 383.4M 300.0M 196 1500 30 6000 - over 3/0 ipsecmgr 262 0.23% 75% 378.0M 300.0M 185 1500 28 6000 - over 3/0 ipsecmgr 263 0.46% 75% 382.7M 300.0M 197 1500 30 6000 - over 3/0 ipsecmgr 264 0.22% 75% 383.7M 300.0M 212 1500 27 6000 - over ....

A continuación se muestra un ejemplo de sessmgrs ejecución en las tarjetas 4 y 5 con distribución desigual de sesiones:

[local]xyx# show task resources max | grep -i sess Monday February 17 21:52:38 UTC 2023 task cputime memory files sessions 4/0 sessmgr 45 12% 100% 429.9M 2.00G 129 500 4260 26000 I good 4/0 sessmgr 48 12% 100% 428.8M 2.00G 129 500 4267 26000 I good 4/0 sessmgr 49 12% 100% 428.5M 2.00G 129 500 4274 26000 I good 4/0 sessmgr 52 12% 100% 428.3M 2.00G 129 500 4258 26000 I good 5/0 sessmgr 5002 2.34% 50% 87.46M 190.0M 89 500 -- -- S good 5/0 sessmgr 2 12% 100% 458.5M 2.00G 107 500 9279 26000 I good 5/0 sessmgr 3 13% 100% 459.9M 2.00G 106 500 9281 26000 I good

3. Verifique las estadísticas de cifrado si hay alguna caída en el nivel de IPSec:

show crypto managers detail     ----------------- this command shows statistics per ipsec so we can check if any drops
show crypto statistics ikev2    ----------------- this command shows overall ikev2 statistics for EPDGs for different msg flows

Nota: Las comprobaciones previas son importantes porque a veces se encuentran problemas en el nivel de la tarjeta donde el IPSec/sessmgr de una tarjeta en particular no puede tomar sesiones de usuario/tráfico y puede ver claramente caídas en el nivel de IPSec en las estadísticas mencionadas anteriormente.

Registros necesarios


Pocos puntos a pedir para resolver mejor el problema:

• Desde cuando se ve el problema (refiriéndose a la fecha y hora exactas del inicio del problema)
• ¿Se han realizado cambios en la red o en la configuración?
• Fórmulas utilizadas para ASR en ePDG
• ¿Cuántos ePDG hay en el círculo afectado y entre ellos está el problema observado en todos los ePDG o un EPD específico?

Estos son los registros que se deben recopilar:

• Mostrar detalles de compatibilidad (SSD) del nodo antes de que se inicie el problema, durante el problema y después del mismo (si el problema ya no se produce).
• Registros del sistema durante 1 semana antes del problema (para el estudio comparativo), que cubren la hora del problema y después del problema (si el problema ya no se produce).
• El protocolo simple de administración de red (SNMP) intercepta durante 1 semana antes del problema (para un estudio comparativo), cubriendo el tiempo del problema y después del problema (si el problema ya no se produce).
• Bulkstats 1 semana antes de la emisión (para el estudio comparativo), que cubre la hora de la emisión y después de la emisión (si el problema ya no se produce).
• Monsub se debe recoger según estas opciones:

monitor subscriber with options S, X, A, Y, 19, 33, 34, 35, 26, 37, 40, 50, 88, 89. Collect traces at verbosity 5 for problematic and non-problematic number.

• 3 SSD en un intervalo de 30-45 minutos para encontrar el motivo del rechazo.

Nota: los motivos de desconexión 519 a 533 son para el rechazo de sesión ePDG.

• Debe comparar las configuraciones de los nodos problemáticos y no problemáticos.

show configuration

show configuration verbose

• Necesario para depurar registros:

logging filter active facility sessmgr level <critical/error> logging filter active facility ipsec level <critical/error> logging filter active facility ikev2 level <critical/error> logging filter active facility epdg level <critical/error> logging filter active facility diameter level<critical/error> logging filter active facility egtpc level<critical/error> logging active ------------------- to enable debug logs no logging active --------------- to disable debug logs Note :: Above mentioned debug logs are taken considering debug logs at the level of critical/error but we can capture at debug level also as per need basis e.g logging filter active facility egtpc level debug

• El resultado de los comandos que pueden ser útiles para la resolución de problemas:

show epdg-service all counters   
-> View ePDG service information and statistics

show epdg-service statistics     
-> View ePDG service statistics

show epdg-service session all    
-> View ePDG service session information

show egtpc statistics interface edpg-egress debug-info    
-> View egtpc statistics for  ePD-egress

show session [ disconnect-reasons | duration | progress | setuptime | subsystem ] 
-> iew additional session statistics.

show crypto statistics ikev2     
-> View IKEv2 statistics

show diameter aaa-statistics all 
->View Diameter AAA server statistics.

show subscribers epdg-only [ [ all ] | [ callid call_id ]]   
-> View a list of ePDG subscribers currently accessing the system.

show subscribers epdg-service service_name [ [ all ] | [ callid call_id ]] 
 ->View a list of ePDG subscribers currently accessing the system per ePDG service.

show crypto managers summary ipsec-sa-stats 
---Need to collect with some iterations to check ipsec associations stats

Advertencia: Cuando se le solicita que recopile registros como los de depuración, logging monitor, mon-sub y mon pro, recopile siempre en la ventana de mantenimiento y monitoree siempre la carga en la CPU.

Análisis 

Este es el ejemplo de una fórmula para la Tasa de Éxito de Sesiones de Adhesión Inicial ePDG:

Initial Attach Sessions Success Rate ==((totsetupsuccess / totsetupattempt )*100)

En Referencia de Estadísticas y Contadores - Descripciones de Estadísticas Masivas, puede encontrar los contadores que se utilizan en la fórmula para conocer su significado.

epdg totsetup-attempt- Total number of epdg session setup attempts. Increments upon receiving IKE_AUTH (CFG_REQ) for ePDG session creation.

epdg totsetup-success Total number of epdg session setup success. Increments upon successful IPv4/IPv6/Dual Stack ePDG session call setup.                

Desde la SSD, puede ver el resultado show crash list para ver si hay algún número continuo o alto de caídas que conduzcan a la caída de KPI.

Desde la SSD, puede verificar show license info y emitirshow resource para ver si la licencia no ha caducado o si el recuento de sesiones está dentro del límite.

******** show resources ******* Wednesday December 07 16:58:25 IST 2022 EPDG Service: In Use : 1118147 Max Used : 1450339 ( Tuesday November 29 00:06:00 IST 2022 ) Limit : 1600000 License Status : Within Acceptable Limits >>>>>

A partir de la salida del comando show epdg-service statistics , se puede verificar la razón de falla que se incrementa.

******** show epdg-service statistics ******* Session Disconnect reason: Remote disconnect: 580994781 Admin disconnect: 168301 Idle timeout: 0 Absolute timeout: 0 Long duration timeout: 0 Session setup timeout: 169445470 No resource: 185148 Auth failure: 7634409 Flow add failure: 0 Invalid dest-context: 0 Source address violation: 42803 LMA Revocations(non-HO): 0 Duplicate Request: 19973167 Addr assign failure: 0 LTE/Other handoff: 1310701444 Miscellaneous reasons: 456928065 MIP-reg-timeout : 0 Invalid-APN : 0 ICSR Procedure : 0 Local PGW Res. Failed : 10424 Invalid QCI : 0 UE Redirected : 0 Roaming Mandatory : 0 Invalid IMEI : 3 

A partir de los rastros problemáticos, se puede encontrar el motivo de los rechazos y se puede comparar con el rastro no problemático de cualquier discrepancia.

Algunos de los escenarios que puede obtener de los seguimientos:

En el caso 1 (diámetro sin suscripción), después de analizar los seguimientos, se observa que se envía una solicitud EAP de diámetro al servidor AAA. Sin embargo, la respuesta recibida indica un error con el código de causa. DIAMETER_ERROR_USER_NO_APN_SUBSCRIPTION. Como resultado, Serving Packet Data Gateway (SPGW) registra el mismo error con el motivo de desconexión. diameter-no-subscription. Este comportamiento se considera normal para un usuario sin suscripción, ya que el servidor de autenticación, autorización y contabilidad (AAA) lo rechaza en el momento del proceso.

Nota: verifique la suscripción APN en AAA/HSS para el número de prueba y, si es posible, organice pruebas en línea para el mismo.

En el caso 2 (Session-setup-timeout), al analizar los seguimientos, se observa que la configuración de la sesión se rechaza con el motivo de desconexión. Session-setup-timeout. Una investigación más detallada reveló que el ePDG está enviando una EGTP_CREATE_SESSION_REQUEST a SPGW, pero no está recibiendo ninguna respuesta para el mismo. Puede observarse que se envían tres solicitudes consecutivas sin recibir respuesta alguna.

Solution : In such cases mostly need to check why SPGW is not sending any response towards EPDG because EPDG maintains this setup timer within which it needs to have the response

En el caso 3, se envía una solicitud con un nombre de punto de acceso (APN) específico al PGW, pero se rechaza junto con el código de causa  EGTP_CAUSE_USER_AUTHENTICATION_FAILED.

Solution : Here the issue can be either at HSS or EPDG itself need to check the authentication parameters being exchanged between EPDG/HSS/AAA          

Para investigar todos los casos mencionados, es necesario capturar los registros de depuración para un análisis más detallado. Estos registros se examinan de acuerdo con el estándar 3GPP y, en función de los resultados, se puede determinar un plan de acción o una solución alternativa adecuada. Es importante tener en cuenta que el curso de acción puede variar en función del escenario específico.