Dépannage de la gamme ASR 5000 GTPC et GTPU et défaillances de chemin associées
Contenu
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
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)