Table des matières

Introduction

Dépannage des commandes

Analyse

Perspective StarOS

Solution de contournement

Introduction

Ce document décrit le dépannage des défaillances de chemin EGTP (Evolved-GPRS Tunneling Protocol) observées en raison d'une non-concordance dans les valeurs de compteur de redémarrage entre SGSN/MME et GGSN/Serving Gateway ou PDN Gateway (SPGW).

Dépannage des commandes

show egtpc peers interface

show egtpc peers path-failure-history

show egtpc statistics path-failure-reasons

show egtp-service all

show egtpc sessions

show egtpc statistics

egtpc test echo gtp-version 2 src-address <source node IP address>  peer-address <remote node IP address>

For more details about this commands refer this mentioned link

https://www.cisco.com/c/en/us/support/docs/wireless-mobility/gateway-gprs-support-node-ggsn/119246-technote-ggsn-00.html

Analyse

D'après les journaux et les statistiques, il est identifié que la valeur du compteur de redémarrage à l'extrémité de l'entité de gestion de mobilité (MME) est 11 et à l'extrémité de l'EPG est 12.

Vous pouvez observer les pièges comme indiqué ici :

Internal trap notification 1112 (EGTPCPathFail) context s11mme, service s11-mme, interface type mme, self address <X.X.X.X>,  peer address <Y.Y.Y.Y>, peer old restart counter 4,  peer new restart counter 4,  peer session count  240, failure reason no-response-from-peer,  path failure detection Enabled.

Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address <X.X.X.X>,  peer address <Y.Y.Y.Y>, peer old restart counter 54,  peer new restart counter 12,  peer session count  1107240, failure reason restart-counter-change

Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address <X.X.X.X>,  peer address <Y.Y.Y.Y>, peer old restart counter 12,  peer new restart counter 54,  peer session count  1107207, failure reason create-sess-restart-counter-change

Vendor Gateway (GW) rencontre un problème lors de l'acceptation de valeurs inférieures du SGSN (Serving GPRS Support Node) si le compteur de redémarrage est modifié. Si le fournisseur GW a stocké une valeur supérieure (l'ancienne) et après le rechargement du noeud si le SGSN Cisco envoie une valeur inférieure, le fournisseur GW ne l'accepte pas.

Remarque : conformément à la norme TS 29.060 :

1. Si le SGSN est en contact avec le noeud de support GPRS de passerelle (GGSN) pour la première fois ou a récemment redémarré sans indiquer la nouvelle valeur du compteur de redémarrage au GGSN, il incorpore un élément d'informations de récupération dans la demande de contexte PDP (Create Policy Decision Point). Cet élément est inclus par le SGSN si nécessaire. Le GGSN qui reçoit un élément d'information de récupération dans l'élément de message Create PDP Context Request le traite comme lorsqu'il reçoit un message de réponse d'écho. Le message Create PDP Context Request est considéré comme une demande d'activation valide pour le contexte PDP inclus dans le message.

2. Le GGSN inclut l'élément d'informations de récupération dans la réponse contextuelle Create PDP si le GGSN est en contact avec le SGSN pour la première fois ou si le GGSN a redémarré récemment et que la nouvelle valeur du compteur de redémarrage n'a pas encore été indiquée au SGSN. Le SGSN qui reçoit l'élément d'information de récupération le traite comme lorsqu'un message de réponse d'écho est reçu. Cependant, il considère que le contexte PDP en cours de création est actif si la réponse indique une activation de contexte réussie au niveau du GGSN.

3. L’interface GTP utilise un compteur de redémarrage afin de suivre le nombre de redémarrages. Conformément à la norme TS 23.060, les noeuds GTP doivent utiliser le stockage persistant afin d'assurer le suivi de leurs compteurs de redémarrage GTP locaux, de sorte que l'on s'attend à ce que ces compteurs de redémarrage continuent toujours vers le haut. Cependant, dans le cas où un noeud homologue détecte une diminution du compteur de redémarrage, le comportement du noeud GTP est élaboré dans la session '18 GTP-C based restart procedures' de TS 23.007. Supposons que la valeur d'un compteur de redémarrage précédemment stocké pour un homologue est supérieure à la valeur du compteur de redémarrage reçue dans le message de réponse d'écho ou le message GTP-C, en tenant compte de la substitution d'entier. Dans ce cas, cela indique une condition de course possible (message plus récent arrivant avant le plus ancien). La nouvelle valeur du compteur Restart reçue est ignorée et une erreur peut être consignée. En d'autres termes, lorsque le noeud GTP détecte un compteur de redémarrage inférieur d'un homologue, il n'enregistre jamais ce nouveau compteur de redémarrage.

Perspective StarOS

Du côté de StarOS, vous pouvez modifier explicitement la valeur RC dans StarOS à partir du chemin /flash/restart_file_cntr.txt qui est fait au moment de la mise à niveau.

Selon cette théorie, en la comparant à la configuration actuelle, la valeur MME RC était inférieure à la valeur Vendor GW RC. Afin de résoudre le problème, la valeur RC au noeud GW du fournisseur a été modifiée.

Maintenant, après avoir modifié la valeur RC, on voit que les échecs de chemin EGTPC se sont arrêtés, mais toujours, les sessions n'augmentent pas et les liens EGTPC sont toujours inactifs.

Voici les commandes qui ont été utilisées lors du dépannage :

show sgtp-service all | grep "restart"  ----------------- to check RC value

[local]Nodename# show egtp-service all | more

Service name                          : egtpc_sv_service

Service-Id                            : 5

Context                               : SGs

Interface Type                        : mme

Status                                : STARTED

Restart Counter                       : 11   ----------------- RC value to verify

Max Remote Restart Counter Change     : 255

Message Validation Mode               : Standard

GTPU-Context                          :

GTPC Retransmission Timeout           : 5000 (milliseconds)

GTPC Maximum Request Retransmissions  : 4

GTPC IP QOS DSCP value                : 10

GTPC Echo                             : Enabled

GTPC Echo Mode                        : Default

[local]Nodename# show egtpc peers           ------------ To check link status

Sunday February 05 15:31:00 IST 2023

+----Status:                 (I) - Inactive  (A) - Active

|

|+---GTPC Echo:              (D) - Disabled  (E) - Enabled

||

||+--Restart Counter Sent:   (S) - Sent      (N) - Not Sent

|||

|||+-Peer Restart Counter:   (K) - Known     (U) - Unknown

||||

||||+-Type of Node:          (S) - SGW       (P) - PGW

|||||                        (M) - MME       (G) - SGSN

|||||                        (L) - LGW       (E) - ePDG

|||||                        (C) - CGW       (B) - MBMS

|||||                        (U) - Unknown

|||||

|||||  Service                       Restart--------+  No. of

|||||  ID                            Counter        |  restarts

|||||   |                                           |   |   Current       Max

vvvvv   v              Peer Address                 v   v   sessions    sessions  LCI OCI

-----  --- --------------------------------------- --- --- ----------- ------------------

IDSKS  10                           X.X.X.X         91   0           0           0   X   X

IDNKS  11                           Y.Y.Y.Y          4  95           0       34005   X   X

IDNKS  11                           Z.Z.Z.Z         10 103           0       16805   X   X

IDNKS  11                           A.A.A.A        104  95           0        7250   X   X

AESKS  11                           B.B.B.B          0   0        4004       47649   X   X

AESKS  11                           C.C.C.C          0   0        4053       46571   X   X

AESKS  11                           D.D.D.D          0   0        4026       46734   X   X

ABove output peers if you see no sessions on this peer and also link are inactive

En outre, vérifiez la requête/réponse d’écho (à vérifier en mode masqué) :

egtpc test echo gtp-version 2 src-address <MME end IP> peer-address <EPG end IP>

Il s'agit de la sortie lorsque la valeur du compteur de redémarrage est corrigée et configurée de la même manière que celle de MME pour l'interface S11 pour l'homologue EGTP affecté, puis que la requête/réponse d'écho est correcte mais que la liaison est toujours inactive.

[s11mme]Nodename# egtpc test echo gtp-version 2 src-address <X.X.X.X> peer-address <Y.Y.Y.Y>

Sunday February 05 16:22:42 IST 2023

EGTPC test echo

---------------

Peer: X.X.X.X                          Tx/Rx:  1/1  RTT(ms): 1    (COMPLETE) Recovery: 10 (0x0A)

Cependant, la même chose ne fonctionne pas comme prévu sur d'autres GW affectés problématiques. Vous obtenez toujours un échec pour la requête/réponse d'écho comme mentionné ici.

[s11mme]Nodename# egtpc test echo gtp-version 2 src-address <X.X.X.X> peer-address <Y.Y.Y.Y>

Sunday February 05 16:46:11 IST 2023

EGTPC test echo

---------------

Peer: X.X.X.X                         Tx/Rx:  1/0  RTT(ms): 0    (FAILURE)

Solution de contournement

1. Afin de résoudre ce problème, prenez note du compteur de redémarrage actuel dans /flash/restart_file_cntr.txt avant la désactivation VNF. Plus tard, lorsqu'il est activé avec un nouveau logiciel, connectez-vous à CF et mettez à jour le fichier /flash/restart_file_cntr.txt avec l'ancien compteur de redémarrage. Ensuite, comme procédure de mise à niveau normale, rechargez le VNF avec la configuration day-N.

2. Modifiez le cat /flash/restart_file_cntr.txt à la valeur requise et rechargez le noeud avec la configuration actuelle.

Remarque : vous pouvez essayer avec le redémarrage SGTPC aussi bien une fois que l'étape initiale.