Dépannage de la dégradation des indicateurs de performance clés S11
Introduction
Ce document décrit comment dépanner les problèmes de dégradation des indicateurs de performance clés (KPI) S11.
Aperçu
S11 est l'interface qui connecte l'entité de gestion de la mobilité (MME) et la passerelle de service (SGW) dans un réseau LTE (Long Term Evolution). L'interface utilise le protocole Gn ou GPRS Tunneling Protocol-Control (GTP-C).
Messages de l'interface S11
- Créer une requête/réponse de session
- Modifier la demande/réponse de session
- Supprimer la requête/réponse de session
Établissement de la session EPS :
- La dégradation de l'indicateur de performance clé S11 est observée lorsque vous voyez plus de refus de création de demande de session (CSR) par rapport à ses tentatives de CSR, qui doit être la cause première.
Vous pouvez connaître la formule utilisée pour mesurer l'indicateur de performance clé, noter tous les compteurs inclus dans la formule et déterminer le compteur exact responsable de la dégradation.
S11 ASR (SPGW) = ((tun-sent-cresessrespaccept+ggsn_tun-sent-cresessrespdeniedUserAuthFailed+tun-sent-cresessrespdeniedPrefPdnTypeUnsupported+tun-sent-cresessrespdeniedCtxtNotFound)/EGTPC-ggsn_tun-recv-cresess)*100
PDN Connectivity Success Rate (MME) : ((%esmevent-pdncon-success%) + (%esm-msgtx-pdncon-rej%))*) / (%esmevent-pdncon-attempt%) *100)
Remarque : la formule peut varier en fonction de la façon dont elle est mesurée.
Journaux requis au niveau initial :
- Tendance ICP décrivant la dégradation.
- Formule ICP utilisée.
-
Les compteurs Bulkstat bruts et les tendances de cause de code dès le début du problème.
- Capturez deux instances de Show Support Details (SSD) à partir du noeud à un intervalle de 30 minutes pendant les périodes problématiques.
- Les journaux système vont de deux heures avant la dégradation jusqu'à l'heure actuelle.
mon sub/pro traces etlogging monitor msid <imsi> .
Séquence de dépannage
Séquence de dépannage-
Évaluez la tendance des indicateurs de performance clés de chaque compteur impliqué dans la formule d'indicateur de performance clé S11 en analysant les statistiques globales.
-
Comparer la tendance des indicateurs de performance clés pendant les délais problématiques avec les délais non problématiques.
-
Examinez la façon dont le compteur Bulkstat problématique identifié est défini en fonction du flux et établissez des modèles.
-
Collecter les motifs de déconnexion du noeud par itérations multiples à des intervalles de 3 à 5 minutes.
Vous pouvez analyser le delta des raisons de déconnexion entre deux disques SSD collectés à des horodatages différents. Le motif de déconnexion qui indique une augmentation significative de la valeur delta peut être considéré comme la cause de la dégradation de l'indicateur de performance clé. Pour obtenir des descriptions détaillées de toutes les raisons de déconnexion, reportez-vous au document Cisco Statistics and Counters Reference ici : https://www.cisco.com/c/en/us/td/docs/wireless/asr_5000/21-23/Stat-Count-Reference/21-23-show-comman...
show session disconnect-reasons verbose5. Vérifiez les statistiques egtp en fonction du type de noeud sur lequel elles sont prises :
--- SGW end -----
show egtpc statistics interface sgw-ingress path-failure-reasons
show egtpc statistics interface sgw-ingress summary
show egtpc statistics interface sgw-ingress verbose
show egtpc statistics interface sgw-ingress sessmgr-only
show egtpc statistics interface sgw-egress path-failure-reasons
show egtpc statistics interface sgw-egress summary
show egtpc statistics interface sgw-egress verbose
show egtpc statistics interface sgw-egress sessmgr-only
---- PGW end -----
show egtpc statistics interface pgw-ingress path-failure-reasons
show egtpc statistics interface sgw-ingress summary
show egtpc statistics interface sgw-ingress verbose
show egtpc statistics interface sgw-ingress sessmgr-only
--- MME end -----
show egtpc statistics interface mme path-failure-reasons
show egtpc statistics interface mme summary
show egtpc statistics interface mme verbose
show egtpc statistics interface mme sessmgr-only 6. Une fois que vous avez identifié le compteur spécifique à l'origine du problème, vous devez capturer les traces d'appel mon-sub/mon-pro pour analyser et identifier plus précisément le flux d'appel spécifique à l'origine de la dégradation de l'indicateur de performance clé. En outre, vous pouvez utiliser des outils externes pour obtenir des traces Wireshark pour une analyse plus détaillée.
Les commandes permettant de capturer les sous-traces Mon sont les suivantes :
monitor subscriber with options 19, 26,33, 34, 35, 49,A,S, X, Y, verbosity +5 during the issue.
mon-pro with options 19, 26,33, 34, 35, 49,A,S, X, Y, verbosity +5 during the issue if no mon-sub is present.
More options can be enabled depending on the protocol or call flow we need to capture specificallyDans les cas où la capture de traces comme mon-sub n'est pas possible en raison d'un pourcentage minimal de dégradation de KPI, vous devez capturer les journaux de débogage au niveau du système à la place. Cela implique la capture des journaux de débogage pour sessmgr et egptc, et si nécessaire, la capture des flux spécifiques à la passerelle.
logging filter active facility sessmgr level debug
logging filter active facility egtpc level debug
logging filter active facility sgw level debug
logging filter active facility pgw level debug
logging active ----------------- to enable
no logging active ------------- to disable
Note :: Debugging logs can increase CPU utilization so need to keep a watch while executing debugging logs7. Après avoir analysé les journaux de débogage, si vous déterminez la cause du problème, vous pouvez continuer à capturer le fichier de base pour cet événement spécifique où vous observez les journaux d'erreurs.
logging enable-debug facility sessmgr instance <instance-ID> eventid 11176 line-number 3219 collect-cores 1
For example :: consider we are getting below error log in debug logs which we suspect can be a cause of issue
and we don;t have any call trace
[egtpc 141027 info] [15/0/6045 <sessmgr:93> _handler_func.c:10068] [context: INLAND_PTL_MME01, contextID: 6] [software internal user syslog] [mme-egress] Sending reject response for the message EGTP_MSG_UPDATE_BEARER_REQUEST with cause EGTP_CAUSE_NO_RESOURCES_AVAILABLE to <Host:x.x.x.x, Port:31456, seq_num:82011>
So in this error event
facility :: sessmgr
event ID = 141027
line number = 10068
Avertissement : Lorsque vous demandez la collecte de journaux tels que les journaux de débogage, le moniteur de journalisation, mon-sub ou mon-pro, il est important de s'assurer que ces journaux sont collectés pendant une fenêtre de maintenance. En outre, il est essentiel de surveiller la charge du processeur pendant ce temps.
Analyse et identification des symptômes
Analyse et identification des symptômes- Tout d'abord, vérifiez si des pannes fréquentes sont observées dans le système à partir du SSD.
show crash list
- Vérifiez si des problèmes de licence ont été rencontrés. Dans certains cas, lorsque la licence de la passerelle de données de paquets de service (SPGW) est expirée, elle ne peut plus accepter de nouveaux appels, ce qui entraîne l'échec des appels et entraîne une dégradation ou une diminution de S11.
show resource info
- Vérifiez si plusieurs instances sessmgr sont dans un état d'avertissement/de dépassement en raison d'une utilisation élevée de la mémoire ou du processeur. Si de telles instances sont trouvées, vérifiez si de nouveaux appels sont rejetés en raison de ces conditions.
- À partir des journaux de débogage, vous pouvez vérifier sur quelle interface, vous obtenez les erreurs de rejet d'appel.
Si un nombre important d'erreurs de rejet d'appel se produit pour un abonné spécifique dans le contexte « sgw-egress », suivies du rejet du même abonné dans le contexte « sgw-ingress », on peut déduire que les rejets de la passerelle de données par paquets (PGW) sont envoyés à SGW-> MME dans le contexte S11. Pour confirmer et dépanner davantage à partir de l'extrémité PGW, vous pouvez maintenant prendre un mon-sub pour cet IMSI.
2022-Nov-26+00:20:51.763 [egtpc 141018 unusual] [7/0/16871 <sessmgr:579> _handler_func.c:3227] [context: gwctx, contextID: 2] [software internal user syslog] [sgw-egress] For IMSI: 427021600263284, create session request is rejected by the peer with cause EGTP_CAUSE_NO_RESOURCES_AVAILABLE
2022-Nov-26+00:20:51.763 [egtpc 141018 unusual] [7/0/16871 <sessmgr:579> _handler_func.c:2505] [context: gwctx, contextID: 2] [software internal user syslog] [sgw-ingress] For IMSI: 427021600263284, create session request is rejected by the SAP user with cause EGTPC_REASON_UNKNOWN
- Parfois, il peut y avoir plusieurs motifs de rejet pour l'écart ICP, de sorte que vous devez vérifier pour chaque motif séparément et procéder en conséquence.
Par exemple, il peut y avoir no_resource_available/user_auth_failure augmentation des erreurs pour certaines séries IMSI (International Mobile Subscriber Identity), qui est pour les abonnés en itinérance, donc ceux-ci doivent être vérifiés à partir de PGW. Il peut y avoir une raison comme remote peer not responding et créer une requête de session qui arrive à expiration au SGW et cela peut provoquer une dégradation dans l'indicateur de performance clé S11. Cette session de création peut être rejetée comme No_resource_available de SGW vers MME. Ces codes de cause de rejet peuvent être observés à partir des journaux de protocole de surveillance et vous pouvez vérifier les champs Créer une demande de session et Créer des réponses de session pour identifier les adresses IP spécifiques à partir desquelles ces codes de cause de rejet sont envoyés.
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
1.0 |
18-Jun-2023 |
Première publication |
Commentaires