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 : ipsecmgr fonctionne 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  sessmgr/ipsecmgr  afin de vérifier si un modèle anormal de flux de trafic est observé en termes de nombre de sessions par  sessmgr/ipsecmgr  de chaque carte ou si ces processus sont à l'état d'avertissement/de fermeture. Par exemple, dans cette sortie, vous voyez  ipsecmgr est en  over  comme indiqué 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  sessmgrs  exécution sur les 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

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.

• 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 
    
    
      logging filter active facility ipsec level 
     
       logging filter active facility ikev2 level 
      
        logging filter active facility epdg level 
       
         logging filter active facility diameter level 
        
          logging filter active facility egtpc level 
         
           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

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 show resource pour voir si la licence n'a pas expiré ou si le nombre de sessions est dans la limite.

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

À partir du résultat de la commande  show epdg-service statistics , la raison de l'échec qui est incrémentée peut être vérifié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 la même défaillance avec le motif de déconnexion  diameter-no-subscription. Ce comportement est considéré comme normal pour un utilisateur sans abonnement, car il est rejeté par le serveur AAA (Authentication, Authorization, and Accounting) au moment du processus.

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  Session-setup-timeout. Une enquête plus approfondie a révélé que le PDG envoie un  EGTP_CREATE_SESSION_REQUEST  au SPGW, mais 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.