Contenu

Introduction

Fond

Commandes pertinentes

Détection des pannes de chemin

Divers exemples de pièges de chemins et d'explications

Discussions connexes de la communauté d’assistance Cisco

Introduction

Cet article traite de la compréhension et du dépannage du protocole GTPC/GTPC (3e génération Partnership Project Technical Specification 29.274), GPRS Tunneling Protocol User Plane (GTPv1-U) (3GPP TS 29.281), en rapport avec cet article, Restoration Procedures (3GPP TS 23.007) , qui s'articule autour de concepts tels que les compteurs de redémarrage, la détection des pannes de chemin et les requêtes/réponses d'écho. Il inclut une liste des commandes pertinentes et des éléments à rechercher dans le résultat, ainsi qu'une explication des paramètres configurables associés. C'est certainement un domaine pour lequel beaucoup de questions sont soulevées. Notez que le dépannage de problèmes spécifiques de contrôle des appels est en soi un domaine d'intérêt très étendu, mais cet article ne mentionne que la capture de statistiques pour le contrôle des appels - tout ce qui est en dehors de cela (c'est-à-dire les problèmes de configuration des appels) n'est pas couvert. En réalité, cet article se concentre principalement sur le dépannage et la vérification des connexions homologues, sans lesquelles il n'y aurait pas de contrôle d'appel.  Bien qu'il soit écrit pour les opérateurs, les concepteurs / les implémenteurs pourraient également bénéficier du contenu ici.

Tous les exemples utilisent des adresses IP falsifiées (modifiées) à partir du réseau d'un opérateur réel.

Fond

Chaque côté d'une connexion GTP (l'une des versions S5 (passerelle de service (SGW) - passerelle de réseau de données de paquets (PGW))), S11 ( entité de gestion multimédia (SGW)), S4 ( noeud de service GPRS de service (SGSN) - noeud de service GPRS de passerelle))) gère un compteur de redémarrage conçu pour alerter l'homologue si le noeud d'origine a redémarré afin que cet homologue puisse prendre les mesures appropriées. Bien qu'un noeud puisse utiliser un compteur unique pour chaque homologue auquel il parle, la conception tend à être d'utiliser le compteur MÊME pour tous les homologues, puisque lorsque le noeud redémarre, le compteur doit être incrémenté pour tous les homologues, et donc le suivi d'une valeur distincte sur une base homologue ne présente aucun avantage supplémentaire car ils ont tous besoin d'augmenter de une de toutes façons. En fait, l'utilisation du même compteur de redémarrage pour tous les homologues est utile pour dépanner un grand réseau où tous les homologues peuvent être vérifiés pour s'assurer que les compteurs de redémarrage reçus ont la même valeur (unique) pour le noeud auquel ces homologues parlent.

Le compteur de redémarrage PEUT être inclus dans tous les types de messages de contrôle, tandis que le compteur de redémarrage DOIT être inclus dans toutes les requêtes et réponses d'écho. Dès qu'un changement de compteur de redémarrage se produit sur un noeud, les différents homologues en sont informés via les messages de contrôle suivants envoyés aux homologues respectifs. Lorsqu'un redémarrage se produit, par spécification, le côté récepteur a la possibilité de maintenir temporairement les appels pendant un court laps de temps ou de les abandonner, ce dernier étant généralement le comportement configuré.

Dans le cas de l'utilisation de requêtes d'écho, la méthode consiste à envoyer les messages sur un intervalle configuré, et si aucune réponse n'est reçue après un nombre configuré de nouvelles tentatives (chacune après un délai configuré), le chemin est considéré comme arrêté et l'action appropriée est prise.  La configuration permet l'envoi d'échos en option, et cela s'appliquerait également à l'homologue, dont l'approche n'a pas nécessairement besoin d'être la même, en particulier lorsque l'homologue peut provenir d'un fournisseur différent et/ou d'un opérateur différent. En fait, en ce qui concerne les réponses Echo, un noeud n’est tenu que de répondre à une requête Echo - qu’il reçoive des échos ou non et avec quelle fréquence n’est pas significative - il doit simplement envoyer une réponse d’écho pour chaque requête, et prendre des mesures si le compteur de redémarrage a reçu des modifications. Bien sûr, comme nous l'avons déjà mentionné, si elle envoie également des demandes d'écho et ne reçoit pas de réponses en temps opportun, elle doit également prendre des mesures pour ce scénario.

Notez que la détection des pannes de chemin peut également être effectuée via la connexion GTP-U (plan utilisateur) via Echo, mais UNIQUEMENT via le délai d'attente, puisqu'il n'y a pas de compteur de redémarrage inclus dans les messages GTP-U comme il y en a pour GTP-C comme indiqué précédemment. GTP-U peut ou non utiliser le même chemin que par les messages de contrôle. S'il s'agit du même chemin, alors la détection GTP-U peut ne pas être aussi utile puisque la détection GTP-C doit être suffisante.

En résumé, voici comment la détection des pannes de chemin peut être effectuée :

- Redémarrer la modification du compteur (via le contrôle msg Req/Rsp ou Echo)

- Délai d'attente des demandes d'écho GTPC

- Délai d'attente des demandes d'écho GTPU

- Délai d'attente des messages requis pour le contrôle (généralement non configuré)

Commandes pertinentes

Afin de dépanner tout type de problème de chemin, familiarisez-vous avec les commandes suivantes. Vous trouverez ci-après une explication des détails pertinents de chacun.

- show [egtpc-service | gtpu-service] all

- show egtpc peers [egtp-service <service>]

- egtpc test echo gtp version {1 | 2} adresse-src <adresse-service> adresse-homologue <adresse-homologue>

- show egtpc statistics [[ (sgw-address) | pgw-address | mme-address) <adresse>] [demux-only] [debug-only] [verbose] | raisons de la défaillance du chemin]

- show gtpu statistics [peer-address <peer>]

- show gtpc statistics [ggsn-service <service>] [instance smgr <instance>]

- show demux-mgr statistics <egtpinmgr | egtpegmgr | gtpumgr> all (sortie SGW) | GGSN/ PGW,/entrée SGW | GTPU

- EGTPCPathFail[Clear], EGTPUPathFail[Clear] déroutements SNMP

- show session disconnect-raisons - gtpc-path-fail, gtpu-path-fail, path-fail

Autres commandes de comptage des abonnés liés au protocole GTP :

show sub [summary] ggsn-service <service>

show sub [summary] gtpu-service <service>

show egtpc sessions [egtp-service <service>]

La commande de base pour vérifier l'état et la configuration de tous les services EGTP est « show egtpc-service ». La plupart des résultats doivent être connus par le biais de la configuration, ainsi que l'état doit être DÉMARRÉ. L'information unique glanée est le « Redémarrer le compteur » qui ne se trouve nulle part ailleurs. La commande associée « show gtpu-service all » retourne des paramètres configurables pour les services GTPU associés aux services EGTPC.

« show egtpc peers » est très utile pour identifier tous les homologues, y compris les états, les compteurs de redémarrage et le nombre d'abonnés actuels/max..

- Notez que cette commande couvre à la fois les homologues SGW et SGSN, alors que dans le passé il y avait une commande distincte pour SGSN/GGSN.

- Puisque cette commande inclut tous les types d'homologue, le type d'homologue peut être filtré via le nom de service (même si le mot clé egtpc-service prend de manière trompeuse également un nom de service GGSN).

- S'il n'y a aucun abonné avec l'homologue, l'état est Inactif et l'écho GTPC désactivé. Dans cet état, pour EGTPC, il peut y avoir des homologues pour lesquels le compteur Restart est signalé, alors que la plupart peut être 0.  Cela se produit dans les situations où l'homologue envoie activement des demandes d'écho auxquelles ASR5K doit répondre. Le compteur de redémarrage peut être déterminé en exécutant la commande de test EGTPC (discuté ci-après), mais dans l'état inactif, le compteur ne sera pas mis à jour dans « show egtpc peers » même s'il a été reçu.   Pendant ce temps pour GGSN, le compteur de redémarrage n'est jamais oublié.

[local]PGW-GGSN> show egtpc peers egtp-service GGSN1

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

|||||  ID                            Counter  |  restarts

|||||   |                                     |     |     Current   Max

vvvvv   v              Peer Address           v     v     sessions sessions

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

IDNKG   6                   203.0.113.69    165     0           0           1

IDNKG   6                   203.0.113.70     25     0           0           1

IDNKG   6                   203.0.113.71    165     0           0           1

IDNKG   6                   203.0.113.72     25     0           0           1

IDNKG   6                   203.0.113.73     53     0           0           1

IDNKG   6                   203.0.113.74     53     0           0           1

IDNKG   6                   192.0.2.9        46     0           0           2

IDNKG   6                   192.0.2.10       44     0           0           1

IDNKG   6                   192.0.2.11       47     0           0           2

IDNKG   6                   192.0.2.12       44     0           0           2

IDNKG   6                   192.0.2.13       54     0           0           1

IDNKG   6                   192.0.2.14       47     0           0           1

IDNKG   6                   209.165.200.225  35     1           0           3

IDNKG   6                   209.165.200.226  35     3           0           3

IDNK   6                    198.51.100.204  156     0           0           1

IDNK   6                    198.51.100.205  158     0           0           1

IDNK   6                    198.51.100.211   54     0           0           1

IDNK   6                    198.51.100.212   54     0           0           1

IDNK   6                    198.51.100.213   56     0           0           1

IDNK   6                    198.51.100.214   56     0           0           1

IDNK   6                    198.51.100.215   54     0           0           1

Notez quelques homologues ci-dessous qui comptent beaucoup plus que les autres homologues. Il s'agit des SGW qui se trouvent physiquement sur le même site ou sur le site jumeau du PGW auquel le MME achemine le plus d'appels.

[local]PGW> show egtpc peers

Monday March 30 20:10:26 UTC 2015

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

|||||                        (U) - Unknown

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

|||||  ID                            Counter        |  restarts

|||||   |                                           |   |   Current       Max

vvvvv   v              Peer Address                 v   v   sessions    sessions

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

IDNUS   5                            198.51.100.4   0   0           0           1

IDNKS   5                           198.51.100.33  75   0           0           1

IDNUS   5                           198.51.100.35   0   0           0           2

IDNUS   5                           198.51.100.65   0   0           0           1

IDNUS   5                           198.51.100.67   0   0           0           2

IDNUS   5                           198.51.100.68   0   0           0           2

IDNUS   5                           198.51.100.98   0   0           0           2

IDNUS   5                          198.51.100.100   0   0           0           1

IDNUS   5                          198.51.100.129   0   0           0           2

IDNUS   5                          198.51.100.130   0   0           0           2

IDNUS   5                          198.51.100.161   0   0           0           2

IDNUS   5                          198.51.100.194   0   0           0           2

IDNUS   5                          198.51.100.196   0   0           0           1

IDNUS   5                          198.51.100.225   0   0           0           5

IDNUS   5                          198.51.100.226   0   0           0           2

IDNUS   5                          198.51.100.228   0   0           0           1

IDNUS   5                            198.51.100.3   0   0           0           2

IDNUS   5                           198.51.100.36   0   0           0           1

IDNUS   5                           198.51.100.64   0   0           0           4

IDNUS   5                           198.51.100.66   0   0           0           2

IDNUS   5                          198.51.100.130   0   0           0           2

IDNKS   5                           198.51.100.24   2   0           0           2

AESKS   5                           198.51.100.56   3   0           1           5

IDNKS   5                           198.51.100.99  18   0           0           2

AESKS   5                          198.51.100.100   7   0           1           3

IDNKS   5                          198.51.100.131  46   0           0           2

IDNKS   5                          198.51.100.132  18   0           0           2

IDNKS   5                          198.51.100.163  41   0           0           3

IDNKS   5                          198.51.100.164   6   0           0           2

AESKS   5                          198.51.100.184  11   0           1           2

IDNKS   5                          198.51.100.216   7   0           0           2

AESKS   5                            203.0.113.24   5   0           3           8

IDNKS   5                            203.0.113.56   3   1           0          13

IDNKS   5                            203.0.113.88   2   0           0          18

IDNKS   5                           203.0.113.120   6   0           0           3

IDNKS   5                           203.0.113.152   3   0           0           4

AESKS   5                           203.0.113.184   2   0           1           9

IDNKS   5                           203.0.113.216   4   0           0           2

IDNKS   5                           203.0.113.248  10   0           0           1

IDNUS   5                             203.0.113.4   0   0           0           2

IDNUS   5                            203.0.113.33   0   0           0           4

IDNUS   5                            203.0.113.65   0   0           0           2

IDNKS   5                           203.0.113.121   5   0           0           3

IDNKS   5                           203.0.113.153   6   0           0           5

IDNUS   5                           203.0.113.162   0   0           0           3

IDNUS   5                            203.0.113.32   0   0           0           5

AESKS   5                            203.0.113.35   5   1           6          37

IDNUS   5                            203.0.113.64   0   0           0           1

IDNUS   5                            203.0.113.66   0   0           0           4

IDNUS   5                            203.0.113.97   0   0           0           1

AESKS   5                            203.0.113.98   4   0           1           4

IDNUS   5                           203.0.113.161   0   0           0           4

IDNUS   5                           203.0.113.193   0   0           0          10

IDNUS   5                           203.0.113.228   0   0           0          12

IDNUS   5                           203.0.113.233   0   0           0           4

AESKS   5                               192.0.2.4   9   0           3          10

AESKS   5                              192.0.2.24   6   0          10          19

AESKS   5                              192.0.2.32   8   0          83         116

AESKS   5                              192.0.2.33  55   0          14          21

AESKS   5                              192.0.2.65  18   0           1        2747

AESKS   5                              192.0.2.66   4   0           3        1639

AESKS   5                              192.0.2.97  44  39          33        1826

AESKS   5                              192.0.2.98   5   1           6        2075

IDNKS   5                             192.0.2.195   8   0           0           7

AESKS   5                               192.0.2.3  46   0        3230        5346

AESKS   5                               192.0.2.5  12   0          84         202

AESKS   5                               192.0.2.7   2   0          31         443

AESKS   5                              192.0.2.24   3   0         116         117

AESKS   5                              192.0.2.36  15   0        4194        6889

AESKS   5                              192.0.2.44   7   0         112         331

AESKS   5                              192.0.2.68  34   0        6104        9798

AESKS   5                              192.0.2.69   7   0        2259        5027

AESKS   5                              192.0.2.88  17   0        3899        8880

AESKS   5                             192.0.2.164  16   0      833131     1298070

AESKS   5                             192.0.2.184   3   0     1437053     2153317

AESKS   5                             192.0.2.193  21   0       11364       26577

AESKS   5                             192.0.2.195   5   0          50         162

AESKS   5                             192.0.2.226  21   0        1950        3931

AESKS   5                             192.0.2.227   6   0        4348        9332

Notez que l'exécution de cette commande sur un noeud de secours ICSR (Inter-Chassis Service Redundancy) n'est pertinente que pour les homologues actifs, auquel cas les numéros doivent être proches, par exemple dans la paire suivante :

PGW> show egtpc peers ... 20:51:52 (ACTIF)

PGW-ICSR> show egtpc peers ... 20:51:51 (EN ATTENTE)

Homologue

RC

Nombre de sessions

Nombre max.

Homologue

RC

Nombre de sessions

Nombre max.

AÉROS

192.0.2.5

2

31

443

ADSQUES

192.0.2.5

2

31

443

AÉROS

192.0.2.24

3

117

123

ADNERS

192.0.2.24

3

117

123

AÉROS

192.0.2.36

15

4223

6889

ADSQUES

192.0.2.36

15

4223

6889

AÉROS

192.0.2.44

7

119

331

ADSQUES

192.0.2.44

7

119

331

AÉROS

192.0.2.68

34

6174

9798

ADSQUES

192.0.2.68

34

6171

9797

AÉROS

192.0.2.69

7

2311

5027

ADSQUES

192.0.2.69

7

2311

5027

AÉROS

192.0.2.88

17

3914

8880

ADSQUES

192.0.2.88

17

3913

8874

AÉROS

192.0.2.164

16

833705

1298070

ADSQUES

192.0.2.164

16

832037

1294412

AÉROS

192.0.2.184

3

1438418

2153317

ADSQUES

192.0.2.184

3

1435461

2147280

AÉROS

192.0.2.193

21

11447

26577

ADSQUES

192.0.2.193

21

11443

26568

AÉROS

192.0.2.195

5

48

162

ADSQUES

192.0.2.195

5

48

162

AÉROS

192.0.2.226

21

1962

3931

ADSQUES

192.0.2.226

21

1962

3931

AÉROS

192.0.2.227

6

4465

9332

ADSQUES

192.0.2.227

6

4466

9332

« echo test egtpc » est utilisé pour vérifier un homologue spécifique pour voir s'il est accessible ou non et doit être exécuté dans le contexte où le service est défini.

- Utiliser gtp-version 1 pour les connexions GGSN-SGSN

- L'utilisation de la commande ping n'est pas un test valide, mais si elle réussit, il est connu qu'il existe un certain niveau d'accessibilité.

- Le compteur de redémarrage homologue (Récupération) s'affiche.

- L'exécution de cette commande incrémente les compteurs de réponse d'écho Tx / Echo Rx dans « show egtpc statistics »

- Le compteur de redémarrage de l'homologue est signalé après le mot clé Recovery (11 dans l'exemple ci-dessous)

- Avertissement : même si cela ne devrait pas se produire dans des circonstances normales, si un écho de test est effectué sur un homologue et qu'il expire pour une raison quelconque (si tout fonctionne alors il ne devrait pas expirer), tous les appels seraient abandonnés (même si les choses fonctionnaient tout à fait jusqu'au point de faire le test).

[Ingress]PGW> egtpc test echo gtp-version 2 src-address  209.165.201.1 peer-address 198.51.100.35

Monday November 03 15:08:12 UTC 2014

EGTPC test echo

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

Peer: 198.51.100.35   Tx/Rx:  1/1  RTT(ms): 1    (COMPLETE) Recovery: 11 (0x0B)

« show egtpc statistics » est destiné à EGTPC (v2) et signale le succès/les échecs de nombreux messages de contrôle EGTPC (Request/Response, Tx/Rx), notamment Create Session, Modify Bearer, Delete Session, Downlink Data Notify, Release Access Bearer, Create Bearer, Update Bearer, Modify Bearer, Suspend, etc., et les réponses associées. Il inclut tous les compteurs de gestion de chemin pour les Tx/Rx de requête/réponse d'écho et, en fonction des compteurs, la croissance de ces compteurs peut être prédite et utilisée pour le dépannage si elle n'augmente pas comme prévu.

L'exemple suivant montre les échos et les réponses initiés et auxquels les deux parties ont répondu. Notez que le SGW a été configuré pour envoyer une fois par minute alors que le PGW a été configuré une fois toutes les trois minutes (les deux côtés n'ont pas besoin d'avoir le même paramètre) et donc toutes les trois minutes il y a deux fois plus de paquets (6:16:33, 6:19:33). N'oubliez pas que même si les deux côtés sont sur le même « cycle » dans cet exemple, ils n'ont pas besoin d'être et peuvent courir indépendamment l'un de l'autre.  Les compteurs de redémarrage ont également été capturés dans une colonne. Notez que le compteur Restart de 11 de la réponse d'écho de SGW correspond à la valeur de sa réponse à l'écho de test de PGW du dessus (le test a été effectué à un moment différent de la capture de paquets mais pour la même paire d'homologues).

L'option demux uniquement capture tous les compteurs de gestion de chemin (requêtes/réponses d'écho) ainsi que les messages de contrôle qui n'atteignent jamais un sessmgr, qui est généralement Créer une requête/réponse de session. Demux process etpinmgr résidant sur la carte Demux est responsable du traitement de toutes les demandes/réponses d'écho et du traitement initial de tous les messages de contrôle d'appel avant de les distribuer aux sessions appropriées (aléatoirement pour les nouveaux appels, et spécifiquement pour les appels existants ancrés sur un sessmgr spécifique). L'option sessmgr uniquement compte inversement uniquement les messages qui sont traités par les sessions, ce qui n'inclut PAS les compteurs de gestion de chemin. Ne pas spécifier un qualificateur est la valeur par défaut du comptage de toutes les valeurs.

« show gtpc statistics » est la commande analogue pour les services SGSN/GGSN (GTPC v1) (CPC, Update PDP Context, etc.)

« show gtpu statistics » signale les statistiques sur le trafic du plan utilisateur géré par les services GTP-U associés au(x) service(s) EGTPC. Un compteur intéressant est Error Indication Tx/Rx qui serait envoyé lorsque le noeud récepteur n'a aucun enregistrement de l'abonné qui devrait être associé à l'identificateur de terminal (TEID) du paquet en question qui pourrait se produire pour plusieurs raisons (le schéma/variable bulkstats est GTPU1/ err-ind-tx). Si le MME/SGW n'a pas été informé que le PGW n'a plus de liaison avec l'abonné, les appels devront peut-être être effacés manuellement sur le MME/SGW (ou attendre qu'ils expirent) pour résoudre complètement un tel problème d'appels orphelins.

Les versions spécifiques aux homologues des commandes stat ci-dessus sont nécessaires pour dépanner des homologues spécifiques, ce qui est souvent le cas.

Détection des pannes de chemin

Le déroutement EGTPCPathFail est la clé pour savoir quand une défaillance de chemin s'est produite. Parmi certaines valeurs de base que l'on peut déjà supposer, il indique le nombre d'appels abandonnés, les compteurs de redémarrage anciens et nouveaux, et la raison de l'échec. En outre, la raison de déconnexion de session gtpc-path-fail sera incrémentée.

Le déroutement EGTPCPathFailClear indiquera le compteur de redémarrage ainsi que la raison du déroutement du chemin. La version la plus récente de StarOS v17 est mieux libellée pour dire « raison claire » plutôt que « raison d'échec » (il a effacé, pas échoué !) pour éviter la confusion.

Voici les nombres d'échecs de chemin qui sont signalés à partir de « show egtpc stat path-fail-raisons »

[local]PGW> show egtpc statistics path-failure-reasons

Reasons for path failure at EGTPC:

Echo Request  restart counter change:                3

Echo Response restart counter change:                0   echo-rsp-restart-counter-change

No Echo Response received:                           0   no-response-from-peer

Control message restart counter change at   demux:  23   Create Session Req Restart Counter changed or create-sess-restart-counter-change

Control message restart counter change at sessmgr:   0   cpc-restart-counter-change or upc-restart-counter-change

Total path failures detected:                       26

Remarques :

- Le compteur de redémarrage du message de contrôle à sessmgr peut être n'importe quel type de message de contrôle (tous ne sont pas répertoriés ici)

- Compteur de redémarrage modifié du SGSN via la prochaine demande de contexte Create PDP après cette modification (pcc-restart-counter-change)

- Compteur de redémarrage modifié à partir du SGSN via la prochaine requête de contexte PDP de mise à jour après cette modification (qui serait une remise à partir d'un autre SGSN) (upc-restart-counter-change)

- Raison d'échec claire du chemin sessions-add est un terme trompeur - il ne s'agit pas d'un échec mais d'un succès, et il indique qu'une nouvelle session est arrivée pour établir la connexion

- Si les valeurs signalées pour les compteurs de redémarrage et le nombre de sessions pour les pièges PathFail et PathClear ne semblent pas correspondre, ouvrez un ticket avec Cisco pour plus d'explications.

Il est important de comprendre comment la détection des pannes de chemin EGTPC/GTPC et, dans une moindre mesure, EGTPU/GTPU (car la détection des pannes du plan utilisateur n'est pas toujours configurée) est mise en oeuvre pour surveiller la connexion entre un GGSN ou un PGW et les différents SGSN et SGW homologues. Normalement, les connexions au sein d’un réseau de fournisseurs de services sont assez stables, auquel cas les pannes de chemin sont peu fréquentes. En revanche, l'expérience a montré que les chemins GTPC parmi les SGSN itinérants se connectant aux GGSN ne sont peut-être pas si stables. Par conséquent, avec de faibles connexions, les échecs de chemin se produisent assez fréquemment.

La configuration suivante couvre les compteurs et la fréquence de transmission des messages de contrôle et d’écho qui peuvent être utilisés pour détecter les pannes de chemin. Le même concept s'applique aux services GGSN, SGW, MME et EGTP :

gsn-service GGSN1

retransmission-timeout 20

Pour les messages de contrôle GTP (par rapport aux messages d'écho)

max-retransmissions 5

pour les deux messages de contrôle et d'écho GTP : combien de fois retransmettent avant le déclenchement de la détection d'échec de chemin

echo-interval 120

Un écho est envoyé toutes les 2 minutes (120 secondes).

echo-retransmission-timeout 5

Pour Echos, si aucune réponse n'est obtenue, il retransmet toutes les 5 secondes

path-fail detection-policy gtp echo

La détection des pannes de chemin est possible via l'écho gtp (plutôt que de ne pas l'utiliser comme méthode de détection des pannes de chemin (mais toujours en envoyant des échos).

associer gtpu-service GGSN1_gtpu

Associe le service GTPU nommé GGSN1_gtpu à ce service GGSN

lier adresse ipv4 209.165.201.2

Les adresses IP de liaison utilisateur et plan de contrôle sont les mêmes dans les exemples de configuration suivants, mais ne peuvent pas nécessairement être configurées comme telles avec d'autres implémentations de fournisseur de services.

[local]GGSN> show ggsn-service name GGSN1

Service name:           GGSN1

Context:                XGWin

Bind:                   Done

Local IPv4 Address:     209.165.201.2     Local IP Port: 2123

Retransmission Timeout: 20 (secs)

Max Retransmissions:    5

Restart Counter:        41

Echo Interval:          120 (secs)

GTPC Echo Mode                        : Default

GTPC Echo Retransmission Timeout      : 5

Guard Interval:         100 (secs)

Path Failure Detection on gtp msgs: Echo

Remarques :

- La durée 0 étant donnée au démarrage d'un cycle de demande d'écho (toutes les 2 minutes), s'il n'y a aucune réponse après un TOTAL de 30 secondes (6 tentatives), le chemin échoue (0 + 5 secondes + (5 * 5 secondes))

- Le processus egtpinmgr (gtpcmgr déconseillé depuis v14) exécuté sur la carte de démultiplexage est responsable du traitement des paquets d'écho

- “ show gtp statistics ”, section “ Path Management Messages ” contient des statistiques pour les requêtes/réponses d'écho pour le chemin de contrôle dans LES DEUX directions :

[Ingress]GGSN> show gtpc statistics

Monday October 27 23:02:07 UTC 2014

Path Management Messages:

Echo Request RX:        169951248   Echo Response TX:        169951248

Echo Request TX:         40838432   Echo Response RX:         40784820

Une autre méthode de détection de chemin se trouve sur le plan utilisateur au lieu du plan de contrôle, et ceci est régi par la configuration suivante.

gtpu-service GGSN1_gtpu

no echo-interval

max-retransmissions 4

echo-retransmission-timeout 5

path-failure detection-policy gtp echo

no path-failure clear-trap gtp echo

bind ipv4-address 209.165.201.2

exit

Remarques :

- “ aucun ” d'intervalle d'écho désactive l'envoi de demandes d'écho pour le plan utilisateur et par conséquent, l'interface de ligne de commande “ détection d'échec de chemin-stratégie d'écho gtp ” n'a aucune pertinence - AUCUNE détection d'échec de chemin n'est effectuée sur GTPU

- GGSN répond toujours aux requêtes d'écho du SGSN, mais

- “ show gtpu stat ” et “ show demux-mgr stat gtpumgr ” capture echo stats stats

[local]PGW-GGSN> show gtpu statistics

Wednesday October 29 23:43:22 UTC 2014

Path Management Messages:

Echo Request Rx:           84690303  Echo Response Rx:            0

Echo Request Tx:                  0  Echo Response Tx:     84690043

[local]PGW-GGSN> show demux-mgr statistics gtpumgr

Wednesday October 29 23:42:04 UTC 2014

Echo stats:

Echo Req Rcvd:               84690303

Echo Rsp Sent:               84690043

Divers exemples de pièges de chemins et d'explications

Généralement, le compteur de redémarrage homologue augmente de un en cas de redémarrage. Dans ce cas, un bogue dans PGW l'a amené à remplacer le compteur de redémarrage par la valeur de RC d'un autre homologue (premier déroutement), et donc quand le paquet suivant est arrivé sur la connexion, il l'a traité comme un redémarrage (deuxième déroutement) pensant que le RC avait changé. Le chemin s’efface ensuite sur tout paquet successif (troisième déroutement). Le but ici n'est pas de connaître un bogue spécifique, mais plutôt d'essayer d'être conscient de tout changement de compteur qui ne peut pas être expliqué.

Wed Jan 14 05:22:07 2015 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.1,  peer address 198.51.100.1, peer old restart counter 54,  peer new restart counter 12,  peer session count  1107240, failure reason restart-counter-change

Wed Jan 14 05:22:07 2015 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.1,  peer address 198.51.100.1, peer old restart counter 12,  peer new restart counter 54,  peer session count  1107207, failure reason create-sess-restart-counter-change

Wed Jan 14 05:22:07 2015 Internal trap notification 1113 (EGTPCPathFailClear) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.1,  peer address 198.51.100.1, peer restart counter 54,   peer session count  1107199, failure reason sessions-add

Cet exemple provient d'un GGSN où l'homologue SGSN a modifié sa RC de 66 à 67 via une demande de contexte Create PDP :

Mon Oct 27 11:48:54 2014 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service GGSN1, interface type ggsn, self address 209.165.201.2,  peer address 209.165.200.225, peer old restart counter 66,  peer new restart counter 67,  peer session count  0, failure reason cpc-restart-counter-change

Mon Oct 27 11:48:54 2014 Internal trap notification 1113 (EGTPCPathFailClear) context XGWin, service GGSN1, interface type ggsn, self address 209.165.201.2,  peer address 209.165.200.225, peer restart counter 67,   peer session count  1, failure reason sessions-add

Cet exemple provient d'un PGW où l'homologue ePDG a modifié sa RC de 69 à 70 via une demande de création de session :

Fri Jun 12 05:21:54 2015 Internal trap notification 1112 (EGTPCPathFail) context PGWin, service EGTP1, interface type pgw-ingress, self address 2001:5555:8000:fff0:132:200::,  peer address 2001:5555:8000:ffe0:123:20f::, peer old restart counter 69,  peer new restart counter 70,  peer session count  0, failure reason create-sess-restart-counter-change

Fri Jun 12 05:21:55 2015 Internal trap notification 1113 (EGTPCPathFailClear) context PGWin, service EGTP1, interface type pgw-ingress, self address 2001:5555:8000:fff0:132:200::,  peer address 2001:5555:8000:ffe0:123:20f::, peer restart counter 70,   peer session count  1, clear reason sessions-add

Dans cet exemple, la sortie de différents noeuds PGW tous connectés au même SGW montre que le SGW a cessé d'être accessible à partir des PGW par un piège EGTPCPathFail sur les différents PGW dans un court laps de temps les uns des autres. Notez que tous affichent le même ancien compteur de redémarrage que celui qui a été discuté précédemment, qu'un noeud utilise normalement le même compteur pour tous ses homologues. Dans le cas d'une absence de réponse, le nouveau compteur de redémarrage affiché est 9, mais le nouveau compteur pourrait être imprimé comme non défini car la connexion est arrêtée à partir du moment où le déroutement est déclenché et donc avoir un compteur de redémarrage n'a pas vraiment de sens.

Mon Dec 22 09:07:29 2014 Internal trap notification 1112 (EGTPCPathFail) context PGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.4,  peer address 198.51.100.162, peer old restart counter 9,  peer new restart counter 9,  peer session count  151, failure reason no-response-from-peer

Mon Dec 22 09:08:54 2014 Internal trap notification 1112 (EGTPCPathFail) context PGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.5,  peer address 198.51.100.162, peer old restart counter 9,  peer new restart counter 9,  peer session count  634, failure reason no-response-from-peer

Mon Dec 22 09:09:00 2014 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.6,  peer address 198.51.100.162, peer old restart counter 9,  peer new restart counter 9,  peer session count  22, failure reason no-response-from-peer

Mon Dec 22 09:07:42 2014 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.7,  peer address 198.51.100.162, peer old restart counter 9,  peer new restart counter 9,  peer session count  33, failure reason no-response-from-peer

Mon Dec 22 09:08:06 2014 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.8,  peer address 198.51.100.162, peer old restart counter 9,  peer new restart counter 9,  peer session count  1, failure reason no-response-from-peer

Mon Dec 22 09:07:34 2014 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.9,  peer address 198.51.100.162, peer old restart counter 9,  peer new restart counter 9,  peer session count  725, failure reason no-response-from-peer

Mon Dec 22 09:08:20 2014 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.10,  peer address 198.51.100.162, peer old restart counter 9,  peer new restart counter 9,  peer session count  279978, failure reason no-response-from-peer

Mon Dec 22 09:06:37 2014 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.11,  peer address 198.51.100.162, peer old restart counter 9,  peer new restart counter 9,  peer session count  23, failure reason no-response-from-peer

Mon Dec 22 09:07:29 2014 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.12,  peer address 198.51.100.162, peer old restart counter 9,  peer new restart counter 9,  peer session count  6, failure reason no-response-from-peer

Mon Dec 22 09:07:01 2014 Internal trap notification 1112 (EGTPCPathFail) context PGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.13,  peer address 198.51.100.162, peer old restart counter 9,  peer new restart counter 9,  peer session count  5, failure reason no-response-from-peer

L'exemple suivant montre une défaillance de chemin et le même nouveau compteur de redémarrage que dans l'exemple précédent, mais une demi-heure plus tard montre quand l'homologue se réactive et que le compteur a augmenté de 15 à 16. Au fil du temps, le nombre augmente pour cet homologue :

Wed Jul 22 05:07:08 2015 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.13,  peer address 198.51.100.162, peer old restart counter 15,  peer new restart counter 15,  peer session count  34, failure reason no-response-from-peer

Wed Jul 22 05:38:00 2015 Internal trap notification 1113 (EGTPCPathFailClear) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.13,  peer address 198.51.100.162, peer restart counter 16,   peer session count  1, clear reason sessions-update

[local]PGW> show egtpc peers

Wednesday July 22 10:04:30 UTC 2015

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

|||||  ID                Counter        |   restarts

|||||   |                               |    |   Current       Max

vvvvv   v              Peer Address     v    v   sessions    sessions

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

AESKS   5               198.51.100.162  16   1        1157        2186

[XGWin]PGW> egtpc test echo gtp-version 2 src-address 209.165.201.13 peer-address 198.51.100.162

Wednesday July 22 10:52:41 UTC 2015

EGTPC test echo

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

Peer: 198.51.100.162                          Tx/Rx:  1/1  RTT(ms): 51   (COMPLETE) Recovery: 16 (0x10)

Cet exemple montre une défaillance de chemin répétitif due au redémarrage de CPC pour 3 homologues SGSN spécifiques au GGSN. Le résultat ci-dessous ne montre qu'un des homologues 209.165.200.225, mais ils ont tous le même problème. L'exécution répétée de « show egtpc peers » et « show gtpc stat sgsn-address » montre également les valeurs alternatives. « show gtpc stat » ne confirme aucun problème de connectivité en ce qui concerne les requêtes et les réponses d'écho, qui dans ce cas ne sont lancées que par le GGSN (acceptable comme discuté précédemment). Un point latéral à souligner ici est qu'il existe souvent plusieurs éléments de données qui peuvent être collectés et qui corroborent toutes la même conclusion - on peut choisir de collecter les données les plus concluantes avec le minimum d'efforts.

show snmp trap history verbose | grep -E "209.165.201.31|209.165.200.225|209.165.200.246"

Mon Jun 22 22:20:51 2015 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service GGSN1, interface type ggsn, self address 209.165.202.129,  peer address 209.165.200.225, peer old restart counter 129,  peer new restart counter 132,  peer session count  3, failure reason cpc-restart-counter-change

Mon Jun 22 22:20:51 2015 Internal trap notification 1113 (EGTPCPathFailClear) context XGWin, service GGSN1, interface type ggsn, self address 209.165.202.129,  peer address 209.165.200.225, peer restart counter 132,   peer session count  4, clear reason sessions-add

Mon Jun 22 22:20:55 2015 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service GGSN1, interface type ggsn, self address 209.165.202.129,  peer address 209.165.200.225, peer old restart counter 132,  peer new restart counter 129,  peer session count  3, failure reason cpc-restart-counter-change

Mon Jun 22 22:20:55 2015 Internal trap notification 1113 (EGTPCPathFailClear) context XGWin, service GGSN1, interface type ggsn, self address 209.165.202.129,  peer address 209.165.200.225, peer restart counter 129,   peer session count  4, clear reason sessions-add

Mon Jun 22 22:20:58 2015 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service GGSN1, interface type ggsn, self address 209.165.202.129,  peer address 209.165.200.225, peer old restart counter 129,  peer new restart counter 132,  peer session count  3, failure reason cpc-restart-counter-change

Mon Jun 22 22:20:58 2015 Internal trap notification 1113 (EGTPCPathFailClear) context XGWin, service GGSN1, interface type ggsn, self address 209.165.202.129,  peer address 209.165.200.225, peer restart counter 132,   peer session count  4, clear reason sessions-add

Mon Jun 22 22:21:02 2015 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service GGSN1, interface type ggsn, self address 209.165.202.129,  peer address 209.165.200.225, peer old restart counter 132,  peer new restart counter 129,  peer session count  2, failure reason cpc-restart-counter-change

Mon Jun 22 22:21:02 2015 Internal trap notification 1113 (EGTPCPathFailClear) context XGWin, service GGSN1, interface type ggsn, self address 209.165.202.129,  peer address 209.165.200.225, peer restart counter 129,   peer session count  3, clear reason sessions-add

Mon Jun 22 22:21:03 2015 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service GGSN1, interface type ggsn, self address 209.165.202.129,  peer address 209.165.200.225, peer old restart counter 129,  peer new restart counter 132,  peer session count  4, failure reason echo-rsp-restart-counter-change

Mon Jun 22 22:21:03 2015 Internal trap notification 1113 (EGTPCPathFailClear) context XGWin, service GGSN1, interface type ggsn, self address 209.165.202.129,  peer address 209.165.200.225, peer restart counter 132,   peer session count  5, clear reason sessions-add

Mon Jun 22 22:21:06 2015 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service GGSN1, interface type ggsn, self address 209.165.202.129,  peer address 209.165.200.225, peer old restart counter 132,  peer new restart counter 129,  peer session count  2, failure reason cpc-restart-counter-change

Mon Jun 22 22:21:06 2015 Internal trap notification 1113 (EGTPCPathFailClear) context XGWin, service GGSN1, interface type ggsn, self address 209.165.202.129,  peer address 209.165.200.225, peer restart counter 129,   peer session count  3, clear reason sessions-add

[XGWin]GGSN> show egtpc peers | grep 209.165.200.225

|||||  Service                      Restart No. of

|||||  ID                           Counter restarts

|||||   |                              |     |        Current      Max

vvvvv   v              Peer Address    |     |       sessions    sessions

|     |            |

v     v            v

Monday June 22 23:09:26 UTC 2015

AESKG   6             209.165.200.225 129 86339           2          57

[XGWin]GGSN> show egtpc peers | grep 209.165.200.225

Monday June 22 23:09:28 UTC 2015

AESKG   6             209.165.200.225 129 86341           3          57

[XGWin]GGSN> show egtpc peers | grep 209.165.200.225

Monday June 22 23:09:29 UTC 2015

AESKG   6             209.165.200.225 132 86342           7          57

[XGWin]GGSN> show egtpc peers | grep 209.165.200.225

Monday June 22 23:09:30 UTC 2015

AESKG   6             209.165.200.225 132 86344           9          57

[XGWin]GGSN> show egtpc peers | grep 209.165.200.225

Monday June 22 23:09:31 UTC 2015

AESKG   6             209.165.200.225 129 86345          11          57

[XGWin]GGSN> show egtpc peers | grep 209.165.200.225

Monday June 22 23:09:32 UTC 2015

AESKG   6             209.165.200.225 129 86345           7          57

[XGWin]GGSN> show gtpc statistics sgsn-address 209.165.200.225

Monday June 22 23:07:36 UTC 2015

SGSN Address:    209.165.200.225    Status:          Active

Total Restarts:  86287             Restart Counter: 129

Session Stats:

Total Current:                  2   S6b Assume Positive:             0

...

Path Management Messages:

Echo Request RX:                0   Echo Response TX:                0

Echo Request TX:            22919   Echo Response RX:            22917

En regardant d'autres homologues dans le sous-réseau, ils montrent tous un RC = 132 tout le temps, tandis que les homologues brisés alternent entre 129 et 132 comme indiqué ci-dessus, ce qui indique que ces homologues SGSN risquent de passer le mauvais RC dans les scénarios rompus :

Restart

Counter

AESKG   6        209.165.200.225 129 85115  8          57  <==

IDNKG   6        209.165.200.226 132  21           0           3

AESKG   6        209.165.200.227 132  60          47          92

AESKG   6        209.165.200.228 132  53          24          59

AESKG   6        209.165.200.229 132  69          92         126

AESKG   6        209.165.200.232 132  66          21          30

AESKG   6        209.165.200.236 132  43           8          21

AESKG   6        209.165.200.238 132  49          18          32

AESKG   6        209.165.200.239 132  39           1           6

AENKG   6        209.165.200.240 132  17           1           5

AESKG   6        209.165.200.241 132  67           6          43

AESKG   6        209.165.200.242 132  56          22          29

AENKG   6        209.165.200.243 132  40           2           9

AENKG   6        209.165.200.246 129 17713  3          24  <==

AESKG   6        209.165.200.247 132  64          29          45

AESKG   6        209.165.200.250 132  62          42          56

Rappelez-vous qu'une autre approche des problèmes comme celui-ci est de vérifier d'autres GGSN (ou PGW pour LTE) pour voir s'ils ont le même problème avec ces homologues SGSN apparemment problématiques, et dans ce cas ils le font aussi. Pour GGSN3, la première exécution de la commande a montré des valeurs 132 pour les deux homologues, mais une autre exécution a montré 129 pour l'un des homologues. Plusieurs exécutions (non présentées ici pour plus de concision) montreraient tous les GGSN qui rebondissent entre les deux RC pour ces homologues au fil du temps :

[local]GGSN1> show egtpc peers | grep -E "209.165.200.246|209.165.200.225"

Tuesday June 23 11:37:23 UTC 2015

AENKG   7               209.165.200.246 129 20147           1          29

AESKG   7               209.165.200.225 129 92853           2          51

[local]GGSN2> show egtpc peers | grep -E "209.165.200.246|209.165.200.225"

Tuesday June 23 11:37:23 UTC 2015

AENKG   6               209.165.200.246 129 20450           4          17

AESKG   6               209.165.200.225 129 94021           3          54

[local]GGSN3> show egtpc peers | grep -E "209.165.200.246|209.165.200.225"

Tuesday June 23 11:37:26 UTC 2015

AENKG   6               209.165.200.246 132 20211           1          39

AESKG   6               209.165.200.225 132 91996           3          59

[local]GGSN4> show egtpc peers | grep -E "209.165.200.246|209.165.200.225"

Tuesday June 23 11:37:25 UTC 2015

AENKG   6               209.165.200.246 129 20309           1          24

AESKG   6               209.165.200.225 132 92694           9          57

[local]GGSN3> show egtpc peers | grep -E "209.165.200.246|209.165.200.225"

Tuesday June 23 11:44:35 UTC 2015

AENKG   6                209.165.200.246 129 20242           3          39

AESKG   6                209.165.200.225 132 92224           1          59

Enfin, pour confirmer le problème est le SGSN qui change le RC, surveiller l'option de menu d'abonné par l'homologue SGSN montre les changements de RC. Lorsqu'il change, tous les appels sont déconnectés avec path-fail comme motif de déconnexion. Une capture d'écran d'une capture de paquets montre également ceci :

[XGWin]GGSN> mon sub

Monday June 22 23:34:22 UTC 2015

y) By SGSN IP Address

IP Address: [209.165.200.225   ]

INBOUND>>>>>  23:35:32:688 Eventid:47000(3)

GTPC Rx PDU, from 209.165.200.225:2123 to 209.165.202.129:2123 (176)

TEID: 0x00000000, Message type: GTP_CREATE_PDP_CONTEXT_REQ_MSG (0x10)

Sequence Number:: 0x1DB8 (7608)

...

IMSI: 300420078559902

Recovery: 0x81 (129)

...

***CONTROL*** 23:36:00:363 Eventid:10285

Disconnect Reason: path-failure

INBOUND>>>>>  23:36:48:414 Eventid:47000(3)

GTPC Rx PDU, from 209.165.200.225:2123 to 209.165.202.129:2123 (176)

TEID: 0x00000000, Message type: GTP_CREATE_PDP_CONTEXT_REQ_MSG (0x10)

Sequence Number:: 0x3E2D (15917)

...

IMSI: 300420125984926

Recovery: 0x84 (132)

...

INBOUND>>>>>  23:37:28:337 Eventid:47000(3)

GTPC Rx PDU, from 209.165.200.225:2123 to 209.165.202.129:2123 (176)

TEID: 0x00000000, Message type: GTP_CREATE_PDP_CONTEXT_REQ_MSG (0x10)

Sequence Number:: 0x3517 (13591)

...

IMSI: 300420094205377

Recovery: 0x84 (132)

...

Monday June 22 2015

INBOUND>>>>>  23:37:40:559 Eventid:47000(3)

GTPC Rx PDU, from 209.165.200.225:2123 to 209.165.202.129:2123 (176)

TEID: 0x00000000, Message type: GTP_CREATE_PDP_CONTEXT_REQ_MSG (0x10)

Sequence Number:: 0x4E47 (20039)

...

IMSI: 300420194755472

Recovery: 0x81 (129)

...

***CONTROL*** 23:37:40:755 Eventid:10285

Disconnect Reason: path-failure

Cet exemple montre une défaillance de chemin où le problème se trouvait dans le chemin et non dans PGW ou SGW. En conséquence, le RC reste le même lorsque le chemin est rétabli. Dans le deuxième exemple d'homologue, la commande clear est le résultat de l'établissement de la demande d'écho :

Thu May 28 20:47:47 2015 Internal trap notification 1112 (EGTPCPathFail) context PGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.1,  peer address 198.51.100.196, peer old restart counter 5,  peer new restart counter 5,  peer session count  549697, failure reason no-response-from-peer

Thu May 28 20:49:36 2015 Internal trap notification 1113 (EGTPCPathFailClear) context PGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.1,  peer address 198.51.100.196, peer restart counter 5,   peer session count  1, clear reason sessions-add

Thu May 28 20:49:06 2015 Internal trap notification 1112 (EGTPCPathFail) context PGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.1,  peer address 203.0.113.98, peer old restart counter 4,  peer new restart counter 4,  peer session count  3, failure reason no-response-from-peer

Thu May 28 20:50:49 2015 Internal trap notification 1113 (EGTPCPathFailClear) context PGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.1,  peer address 203.0.113.98, peer restart counter 4,   peer session count  0, clear reason echo-req

Cet exemple montre une autre anomalie où, à plusieurs reprises après la réinitialisation de l'ancien compteur de redémarrage à 2, il finit en quelque sorte à 0 à nouveau lorsque le chemin échoue. Ça s'est avéré être un bug. Là encore, la leçon est que si quelque chose semble bizarre, il faut le signaler.

Fri Mar 27 03:13:36 2015 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.1,  peer address 192.0.2.5, peer old restart counter 0,  peer new restart counter 2,  peer session count  1, failure reason create-sess-restart-counter-change

Fri Mar 27 03:13:37 2015 Internal trap notification 1113 (EGTPCPathFailClear) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.1,  peer address 192.0.2.5, peer restart counter 0,   peer session count  1, failure reason sessions-add

Sat Mar 28 02:20:45 2015 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.1,  peer address 192.0.2.5, peer old restart counter 0,  peer new restart counter 2,  peer session count  1, failure reason create-sess-restart-counter-change

Sat Mar 28 02:20:47 2015 Internal trap notification 1113 (EGTPCPathFailClear) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.1,  peer address 192.0.2.5, peer restart counter 0,   peer session count  1, failure reason sessions-add

Sat Mar 28 17:14:06 2015 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.1,  peer address 192.0.2.5, peer old restart counter 0,  peer new restart counter 2,  peer session count  1, failure reason create-sess-restart-counter-change

Sat Mar 28 17:14:06 2015 Internal trap notification 1113 (EGTPCPathFailClear) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.1,  peer address 192.0.2.5, peer restart counter 0,   peer session count  1, failure reason sessions-add