Dépannage de la dégradation du taux de réussite des connexions initiales dans ePDG

Introduction

Ce document décrit les problèmes liés à la dégradation du taux de réussite d'attachement initial (ASR) dans la passerelle de paquets de données évoluée (ePDG).

Aperçu

L'ASR initial est une mesure vitale qui indique le taux de réussite du nombre total de tentatives de configuration de session.

La formule de l'indicateur de performance clé contient le nombre total de tentatives de configuration de session ePDG et le nombre total de succès de configuration de session ePDG. Si le nombre de tentatives réussies diminue, l'ensemble de l'indicateur de performance clé se dégrade.

Prévérifications de base

Pour la fonctionnalité ePDG, Internet Protocol Security (IPsec) est le processus qui prend en charge les transactions IPsec. Par conséquent, pour tout cas ePDG, certaines des vérifications préalables doivent être suivies avant de procéder au dépannage du problème.

1. Vérifiez l'état de la carte DPC tel qu'il s'exécuteipsecmgr sur ces cartes. Les cartes DPC doivent être à l'état actif (à l'exception des cartes en veille).

show card table

2. Vérifiez l'état des ressources pour chaque type de carte sessmgr/ipsecmgr  afin de vérifier si un modèle anormal de flux de trafic est observé en termes de nombre de sessions par carte ou si ces processus sont dans un état sessmgr/ipsecmgr  d'avertissement/survol. Par exemple, dans cette sortie, vous voyez ipsecmgr est dans l'état dansover l'état illustré ici.

[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 ....

Voici un exemple de fonctionnement dessessmgrs cartes 4 et 5 avec une répartition inégale des sessions :

[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. Vérifiez les statistiques de chiffrement en cas de perte au niveau 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

Remarque : les prévérifications sont importantes, car il arrive que des problèmes soient détectés au niveau de la carte où IPsec/sessmgr d'une carte particulière n'est pas en mesure de prendre des sessions utilisateur/trafic et vous pouvez clairement voir des abandons au niveau IPsec dans les statistiques mentionnées précédemment.

Journaux requis 


Quelques points à poser pour mieux résoudre le problème :

• Depuis le moment où le problème est constaté (se référant à la date et l'heure exactes du début du problème)
• Des modifications ont-elles été apportées au réseau ou à la configuration ?
• Formules utilisées pour ASR dans ePDG
• Combien y a-t-il d'ePDG dans le cercle touché et parmi eux se trouve la question observée dans tous les ePDG ou un EPD spécifique

Voici les journaux à collecter :

• Afficher les détails de support (SSD) à partir du noeud avant le début du problème, pendant le problème et après le problème (si le problème ne se produit plus).
• Syslog pendant 1 semaine avant le problème (pour une étude comparative), couvrant l'heure du problème et après le problème (si le problème ne se produit plus).
• Le protocole SNMP (Simple Network Management Protocol) effectue des interceptions pendant une semaine avant le problème (pour une étude comparative), couvrant l'heure du problème et après le problème (si le problème ne se produit plus).
• Bulkstats 1 semaine avant l'émission (pour étude comparative), couvrant l'heure de l'émission et après l'émission (si l'émission ne se produit plus).
• Monsub doit être collecté selon ces options :

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 à un intervalle de 30 à 45 minutes pour trouver la raison du rejet.

Remarque : les raisons de déconnexion 519 à 533 concernent le rejet de la session ePDG.

• Vous devez comparer les configurations des noeuds problématiques et non problématiques.

show configuration

show configuration verbose

• Nécessaire pour déboguer les journaux :

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

• Le résultat des commandes qui peuvent être utiles pour le dépannage :

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

Avertissement : lorsque vous êtes invité à collecter des journaux tels que les journaux de débogage, le moniteur de journalisation, mon-sub et mon pro, collectez toujours dans la fenêtre de maintenance et surveillez toujours la charge sur le processeur.

Analyse 

Voici l'exemple d'une formule pour le taux de réussite des sessions d'attachement initiales ePDG :

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

Dans la section Statistics and Counters Reference - Bulkstatistics Descriptions, vous trouverez les compteurs utilisés dans la formule pour connaître leur signification.

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.                

À partir du SSD, vous pouvez voir le résultat show crash list pour voir s'il y a un nombre continu/élevé de pannes qui conduisent à l'écart KPI.

À partir du SSD, vous pouvez vérifier show license info et affichershow resource les résultats pour voir si la licence n'a pas expiré ou si le nombre de sessions est dans la limite autorisée.

******** 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 >>>>>

Le résultat de la commande show epdg-service statistics permet de vérifier la raison de l'échec qui est incrémentée.

******** 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 des traces problématiques, la raison des rejets peut être trouvée et peut être comparée à la trace non problématique pour toute divergence.

Certains des scénarios que vous pouvez obtenir à partir des traces :

Dans le Cas-1 (diamètre-sans-abonnement), après analyse des traces, on constate qu'une requête EAP de diamètre est envoyée au serveur AAA. Cependant, la réponse reçue indique un échec avec le code de cause. DIAMETER_ERROR_USER_NO_APN_SUBSCRIPTION. Par conséquent, la passerelle de données de paquets de service (SPGW) enregistre le même échec avec le motif de déconnexion. diameter-no-subscription. Ce comportement est considéré comme normal pour un utilisateur sans abonnement, car ils sont rejetés par le serveur d'authentification, d'autorisation et de comptabilité (AAA) au moment du processus.

Remarque : vérifiez l'abonnement APN auprès de AAA/HSS pour obtenir le numéro de test et, si possible, organisez un test en ligne pour le même numéro.

Dans le Cas 2 (Session-setup-timeout), lors de l'analyse des traces, il est observé que la configuration de session est rejetée avec le motif de déconnexion. Une Session-setup-timeout. enquête plus approfondie a révélé que l'ePDG envoie un message EGTP_CREATE_SESSION_REQUEST au SPGW, mais qu'il ne reçoit aucune réponse pour le même. On constate que trois requêtes consécutives sont envoyées sans recevoir de réponse.

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

Dans le cas numéro 3, une demande portant un nom de point d'accès (APN) spécifique est envoyée au PGW, mais elle est rejetée avec le code de cause  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          

Pour étudier tous les cas mentionnés, il est nécessaire de capturer les journaux de débogage pour une analyse plus détaillée. Ces journaux sont examinés conformément à la norme 3GPP et, sur la base des résultats, un plan d'action ou une solution de contournement approprié peut être déterminé. Il est important de noter que le plan d'action peut varier selon le scénario.