ASR 5000-reeks Problemen oplossen met GTPC en GTPU en bijbehorende padfouten
Author: Cisco Systems, Inc.
Date: 2026-09-10T05:00:00+00:00
Description: Geschreven door Dave Damerjian, Technical Leader, Services.

Inhoud

Inleiding

Achtergrond

Relevante opdrachten
detectie van padfouten

Diverse voorbeelden van traject fail traps en uitleg

Gerelateerde Cisco Support Community-discussies

Inleiding

Dit artikel behandelt het begrijpen en oplossen van problemen Evolved General Packet Radio Service Tunneling Protocol for Control Plane (EGTPC) / GTPC (3rd Generation Partnership Project Technical Specification 29.274), GPRS Tunneling Protocol User Plane (GTPv1-U) (3GPP TS 29.281), en het meest relevant voor dit artikel, Restoration Procedures (3GPP TS 23.007) kwesties, die draaien rond concepten zoals herstarttellers, padstoringen detectie en echo-verzoeken / antwoorden. Het bevat een lijst met relevante opdrachten en wat te zoeken in de uitvoer, samen met uitleg van gerelateerde configureerbare items. Dit is zeker een gebied waarvoor veel vragen worden gesteld. Merk op dat het oplossen van specifieke problemen met oproepbesturing op zichzelf een zeer uitgebreid aandachtsgebied is, maar dit artikel vermeldt alleen hoe statistieken voor oproepbesturing kunnen worden vastgelegd - alles daarbuiten (dat wil zeggen oproepsetup-problemen) wordt niet behandeld. Echt dit artikel richt zich vooral op het oplossen van problemen en het verifiëren van de peer-verbindingen, zonder welke er geen oproepbesturing zou zijn.  Hoewel geschreven voor operators, kunnen ontwerpers / uitvoerders hier ook profiteren van de inhoud.

Voorbeelden gebruiken allemaal valse (gewijzigde) IP-adressen van het netwerk van een echte operator.

Achtergrond

Elke zijde van een GTP-verbinding (een van S5 (Serving Gateway (SGW) - Packet Data Network Gateway (PGW)), S11 ( Multimedia Management Entity (MME) - SGW), S4 ( Serving GPRS Service Node (SGSN) - Gateway GPRS Service NodeŻ (GGSN)))) onderhoudt een herstartteller die is ontworpen om de peer te waarschuwen als de oorspronkelijke node opnieuw is opgestart, zodat de peer de juiste actie kan ondernemen. Hoewel een node een unieke teller kan gebruiken voor elke peer waarmee hij praat, is het ontwerp meestal om DEZELFDE teller te gebruiken voor alle peers, omdat wanneer de node opnieuw wordt opgestart, de teller voor alle peers moet worden verhoogd, en dus het bijhouden van een afzonderlijke waarde op peer-basis geen extra voordeel oplevert, omdat ze allemaal toch met één moeten toenemen. In feite is het gebruik van dezelfde herstartteller voor alle peers nuttig bij het oplossen van een groot netwerk waar alle peers kunnen worden gecontroleerd om ervoor te zorgen dat de herstarttellers die zijn ontvangen dezelfde (enkele) waarde hebben voor de node waarmee die peers praten.

De herstartteller KAN worden opgenomen in alle soorten controleberichten, terwijl de herstartteller MOET worden opgenomen in alle echo-verzoeken en antwoorden. Zodra er een herstartteller verandert op een node, worden de verschillende peers hierover geïnformeerd via de volgende controleberichten die naar de respectievelijke peers worden verzonden. Wanneer een herstart plaatsvindt, per specificatie, heeft de ontvangende kant de mogelijkheid om de oproepen die het heeft tijdelijk tijdelijk te behouden of te laten vallen, de laatste is meestal wat het geconfigureerde gedrag is.

In het geval van het gebruik van echo-verzoeken, is de methode om de berichten te verzenden met een geconfigureerd interval, en als er geen antwoord wordt ontvangen na een geconfigureerd aantal herhalingen (elk na een geconfigureerde time-out), wordt het pad als down beschouwd en wordt de juiste actie ondernomen.  Configuratie maakt het mogelijk dat echo's optioneel worden verzonden, en dit zou ook van toepassing zijn op de peer, wiens aanpak niet noodzakelijkerwijs hetzelfde hoeft te zijn, vooral wanneer de peer van een andere leverancier en / of andere provider zou kunnen zijn. Wat de reacties van ECHO betreft, is een knooppunt alleen verplicht om te reageren op een verzoek van ECHO - of het nu echos ontvangt of niet en met welke frequentie niet significant is - het hoeft alleen maar een echorespons te sturen voor elk verzoek en actie te ondernemen als de herstartteller wijzigingen heeft ontvangen. Natuurlijk, als het ook echo-verzoeken verstuurt en niet tijdig antwoorden ontvangt, moet het ook actie ondernemen voor dat scenario.

Merk op dat de detectie van padfouten ook kan worden gedaan via de GTP-U-verbinding (gebruikersvliegtuig) via Echo, maar ALLEEN via time-out, omdat er geen herstartteller is opgenomen in GTP-U-berichten zoals er is voor GTP-C zoals eerder besproken. GTP-U kan wel of niet hetzelfde pad gebruiken als door controleberichten. Als het hetzelfde pad is, is de GTP-U-detectie mogelijk niet zo waardevol, omdat GTP-C-detectie voldoende moet zijn.

Samenvattend, hier zijn de manieren waarop padfoutdetectie kan worden gedaan:

- Opnieuw opstarten Counter Change (via MSG Req/Rsp of Echo)

- Time-out voor GTPC Echo Req

- Time-out voor GTPU Echo Req

- Control Req Message Time-out (meestal niet geconfigureerd)

Relevante opdrachten

Om problemen met het pad op te lossen, maakt u kennis met de volgende opdrachten. Hieronder volgt een uitleg van de relevante details van elk.

- [EGTPC-service | GTPU-service] Alles weergeven

- EGTPC-peers weergeven [EGTP-service <service>]

- EGTPC-test ECHO GTP-versie {1 | 2} SRC-adres <Serviceadres> Peer-adres <Peer-adres>

- EGTPC-statistieken weergeven [[[(SGW-adres | PGW-adres | MME-adres) <adres>] [alleen DEMUX]] [Alleen debug] [Verbose] | Redenen voor padfalen]

- GTPU-statistieken weergeven [peer-address <peer>]

- GTPC-statistieken weergeven [GGSN-service <service>] [SMGR-instance <instance>]

- demux-mgr statistieken weergeven <egtpinmgr | egtpegmgr | gtpumgr> all (SGW-egress | GGSN/ PGW,/SGW ingress | GTPU)

- EGTPCPathFail[Wissen], EGTPUPathFail[Wissen] SNMP-traps

- Redenen voor het verbreken van de sessie weergeven - GTPC-path-failure, GTPU-path-failure, path-failure

Andere opdrachten voor het tellen van abonnees met betrekking tot GTP:

Suboverzicht weergeven GGSN-service <service>

Subservice [Samenvatting] GTPU-service <Service> weergeven

EGTPC-sessies weergeven [EGTP-service <service>]

De basisopdracht om de status en configuratie van alle EGTP-services te controleren, is "show egtpc-service". Het grootste deel van de uitvoer moet zijn wat al bekend is via de configuratie, evenals de status moet worden GESTART. Het unieke stukje informatie dat is verzameld, is de "Restart Counter" die nergens anders te vinden is. De bijbehorende opdracht "show gtpu-service all" retourneert configureerbare items voor de GTPU-service(s) die zijn gekoppeld aan de EGTPC-services.

"Laat EGTPC-peers zien" is erg handig bij het identificeren van alle peers, inclusief statussen, herstarttellers en het aantal huidige/maximale abonnees.

- Merk op dat dit commando zowel SGW- als SGSN-peers omvat, terwijl er in het verleden een afzonderlijk commando was voor SGSN / GGSN.

- Aangezien deze opdracht alle peer-typen omvat, kan het peer-type worden gefilterd via de servicenaam (hoewel het trefwoord egtpc-service bedrieglijk ook een GGSN-servicenaam neemt).

- Als er geen abonnees zijn met de peer, is de status Inactief en is GTPC Echo uitgeschakeld. In die staat KUNNEN er voor EGTPC enkele peers zijn waarvoor de Restart-teller wordt gerapporteerd, terwijl de meeste 0 kunnen zijn. Dit gebeurt in situaties waarin de peer actief echoverzoeken verzendt waarop ASR5K zou moeten reageren. De herstartteller kan worden bepaald door de EGTPC-testopdracht uit te voeren (hieronder besproken), hoewel de teller in de inactieve staat niet wordt bijgewerkt in "show egtpc peers", ook al is deze ontvangen.   Ondertussen wordt voor GGSN de herstartteller nooit vergeten.

[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

Let op een paar leeftijdsgenoten hieronder die veel hoger tellen dan de andere leeftijdsgenoten. Deze zijn voor SGW's die fysiek op dezelfde locatie of de zustersite van de PGW zijn gevestigd waarnaar de MME het meest belt.

[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

Merk op dat het uitvoeren van deze opdracht op een Inter-Chassis Service Redundancy (ICSR) standby node alleen relevant is voor actieve peers, in welk geval de nummers dicht moeten zijn, bijvoorbeeld in het volgende paar:

PGW> egtpc-peers weergeven ... 20:51:52 (ACTIEF) | | PGW-ICSR> toon egtpc-peers ... 20:51:51 (STANDBY)
| peer | RC | Aantal sessies | Max Sess | peer | RC | Aantal sessies | Max Sess
AESKS | 192.0.2.5 | 2 | 31 | 443 | ADSKS | 192.0.2.5 | 2 | 31 | 443
AESKS | 192.0.2.24 | 3 | 117 | 123 | DRANKJE | 192.0.2.24 | 3 | 117 | 123
AESKS | 192.0.2.36 | 15 | 4223 | 6889 | ADSKS | 192.0.2.36 | 15 | 4223 | 6889
AESKS | 192.0.2.44 | 7 | 119 | 331 | ADSKS | 192.0.2.44 | 7 | 119 | 331
AESKS | 192.0.2.68 | 34 | 6174 | 9798 | ADSKS | 192.0.2.68 | 34 | 6171 | 9797
AESKS | 192.0.2.69 | 7 | 2311 | 5027 | ADSKS | 192.0.2.69 | 7 | 2311 | 5027
AESKS | 192.0.2.88 | 17 | 3914 | 8880 | ADSKS | 192.0.2.88 | 17 | 3913 | 8874
AESKS | 192.0.2.164 | 16 | 833705 | 1298070 | ADSKS | 192.0.2.164 | 16 | 832037 | 1294412
AESKS | 192.0.2.184 | 3 | 1438418 | 2153317 | ADSKS | 192.0.2.184 | 3 | 1435461 | 2147280
AESKS | 192.0.2.193 | 21 | 11447 | 26577 | ADSKS | 192.0.2.193 | 21 | 11443 | 26568
AESKS | 192.0.2.195 | 5 | 48 | 162 | ADSKS | 192.0.2.195 | 5 | 48 | 162
AESKS | 192.0.2.226 | 21 | 1962 | 3931 | ADSKS | 192.0.2.226 | 21 | 1962 | 3931
AESKS | 192.0.2.227 | 6 | 4465 | 9332 | ADSKS | 192.0.2.227 | 6 | 4466 | 9332

"EGTPC Test ECHO" wordt gebruikt om een specifieke peer te controleren om te zien of deze bereikbaar is of niet en moet worden uitgevoerd in de context waarin de service is gedefinieerd.

- Gebruik gtp-versie 1 voor GGSN-SGSN-verbindingen

- Het gebruik van ping-commando is geen geldige test, maar als het succesvol is, is het bekend dat er een bepaald niveau van bereikbaarheid is.

- De peer restart counter (Recovery) wordt weergegeven.

- Als u deze opdracht uitvoert, worden de Tx echo request / Rx Echo response counters verhoogd in "egtpc-statistieken weergeven"

- De herstartteller van de peer wordt gerapporteerd na het gereserveerde woord Recovery (11 in het voorbeeld hieronder)

- Waarschuwing: hoewel dit niet zou moeten gebeuren in normale omstandigheden, als een test echo wordt uitgevoerd op een peer en het time-out om welke reden dan ook (als alles werkt dan moet het niet time-out), zouden alle oproepen vallen (ook al dingen waren prima werken tot het punt van het doen van de 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" is voor EGTPC (v2) en rapporteert over het succes/falen van veel EGTPC-controleberichten (Request/Response, Tx/Rx), waaronder Create Session, Modify Bearer, Delete Session, Downlink Data Notify, Release Access Bearer, Create Bearer, Update Bearer, Modify Bearer, Suspend, etc., en de bijbehorende reacties. Het bevat alle tellers voor padbeheer voor Echo Request/Response Tx/Rx, en op basis van de timers kan de groei van deze timers worden voorspeld en worden gebruikt om problemen op te lossen als deze niet toenemen zoals verwacht.

In het volgende voorbeeld worden echo's en reacties van beide kanten geïnitieerd en beantwoord. Merk op dat de SGW is geconfigureerd om één keer per minuut te verzenden, terwijl de PGW is geconfigureerd voor één keer elke drie minuten (beide zijden hoeven niet dezelfde instelling te hebben) en dus elke drie minuten zijn er twee keer het aantal pakketten (6: 16: 33, 6: 19: 33). Houd er rekening mee dat hoewel beide zijden zich in dit voorbeeld op dezelfde "cyclus" bevinden, ze niet onafhankelijk van elkaar hoeven te zijn en kunnen draaien.  De herstarttellers zijn ook vastgelegd in een kolom. Merk op dat de herstartteller van 11 uit de echorespons van de SGW overeenkomt met de waarde van de reactie op de PGW-testecho van bovenaf (de test werd op een ander tijdstip uitgevoerd dan de pakketopname, maar voor hetzelfde peer-paar).

De optie alleen demux bevat alle tellers voor padbeheer (echoverzoeken/antwoorden) en controleberichten die nooit een sessie bereiken, wat meestal Sessieverzoek/antwoord aanmaken is. Demux-procesetpinmgr die op de Demux-kaart aanwezig is, is verantwoordelijk voor de afhandeling van alle echo-verzoeken/antwoorden en de eerste afhandeling van alle oproepcontroleberichten voordat deze worden verspreid naar de juiste sessiemakers (willekeurig voor nieuwe oproepen, en specifiek voor bestaande oproepen die op een specifieke sessiemgr zijn verankerd). De optie alleen voor sessmgr telt daarentegen alleen berichten die door sessmgr's worden afgehandeld, maar bevat GEEN tellers voor padbeheer. Geen van beide kwalificaties opgeven is de standaard voor het tellen van alle waarden.

"show gtpc statistics" is de overeenkomstige opdracht voor SGSN/GGSN-services (GTPC v1) (CPC, Update PDP Context, enz.)

"show gtpu statistics" rapporteert statistieken over het gebruikersvliegtuigverkeer dat wordt afgehandeld door de GTP-U-service(s) die zijn gekoppeld aan de EGTPC-service(s). Een interessante teller is Error Indication Tx / Rx die zou worden verzonden wanneer de ontvangende node heeft geen record van de abonnee die moet worden gekoppeld aan de Terminal Endpoint Identifier (TEID) van het pakket in kwestie, die kan gebeuren om een aantal redenen (Het bulkstats schema / variabele is GTPU1 / err-ind-tx). Als de MME/SGW niet op de hoogte is gesteld dat de PGW niet langer bindend is voor de abonnee, moeten oproepen mogelijk handmatig worden gewist op de MME/SGW (of wachten tot ze een time-out hebben) om een dergelijk probleem van verweesde oproepen volledig op te lossen.

De peer-specifieke versies van de bovenstaande stat-opdrachten zijn nodig bij het oplossen van specifieke peers, wat vaak het geval is.

detectie van padfouten

De EGTPCPathFail-trap is de sleutel om te weten wanneer een padfout is opgetreden. Onder een aantal basiswaarden die men al zou aannemen, meldt het het aantal geannuleerde oproepen, de oude en nieuwe herstarttellers en de reden voor het falen. Daarnaast wordt de reden voor het verbreken van de sessie gtpc-path-failure verhoogd.

De trap EGTPCPathFailClear geeft de herstartteller aan, samen met de reden voor het wissen van het pad. De meest recente StarOS v17 is beter geformuleerd om te zeggen "duidelijke reden" in plaats van "reden van falen" (het gewist, niet gefaald!) om verwarring te voorkomen.

Het volgende zijn het aantal mislukte paden dat wordt gerapporteerd vanuit "show egtpc stat path-failure-reasons"

[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

Opmerkingen:

- Controlebericht herstart teller bij sessmgr kan elk type controlebericht zijn (niet alle hier vermeld)

- Gewijzigde herstartteller van de SGSN via de volgende Create PDP Context Request na die wijziging (cpc-restart-counter-change)

- Gewijzigde herstartteller van de SGSN via de volgende Update PDP Context Request na die wijziging (die een overdracht van een andere SGSN zou zijn) (upc-herstart-tegenverandering)

- Pad duidelijk falen reden sessies-add is een bedrieglijke term - het is geen mislukking, maar een succes, en het geeft aan dat een nieuwe sessie is gekomen om de verbinding tot stand te brengen

- Als de waarden die zijn gerapporteerd voor herstarttellers en sessietellingen voor de traps PathFail en PathClear niet op één lijn lijken te staan, opent u een ticket met Cisco voor verdere uitleg.

Het is belangrijk om te begrijpen hoe EGTPC/GTPC en in mindere mate EGTPU/GTPU (aangezien de detectie van storingen in het gebruikersvlak niet altijd is geconfigureerd) wordt geïmplementeerd om de verbinding tussen een GGSN of PGW en de verschillende peer-SGSN en SGW's te bewaken. Normaal gesproken zijn de verbindingen binnen een serviceproviders netwerk redelijk stabiel, in welk geval pad storingen zijn zeldzaam. Aan de andere kant heeft de ervaring geleerd dat GTPC-paden tussen roamende SGSN's die verbinding maken met GGSN's mogelijk niet zo stabiel zijn, en dus met slechte verbindingen is het resultaat dat padstoringen op een vrij frequente basis plaatsvinden.

De volgende configuratie heeft betrekking op timers en transmissiefrequentie voor besturings- en echoberichten die kunnen worden gebruikt om padstoringen te detecteren. Hetzelfde concept geldt voor GGSN-, SGW-, MME- en EGTP-diensten:

ggsn-service GGSN1

tijdpad voor doorgifte 20

Voor GTP-controleberichten (versus de echoberichten)

Max. hertransmissie 5

voor ZOWEL GTP-besturings- als echoberichten – hoe vaak opnieuw moet worden verzonden voordat de detectie van padfouten wordt geactiveerd

echo-interval 120

Een echo wordt elke 2 minuten (120 seconden) verzonden.

echo-retransmission-timeout 5

Voor Echos, als er geen reactie is, wordt het elke 5 seconden opnieuw verzonden

detectiebeleid voor padstoringen-gtp echo

Padfout detectie is mogelijk via gtp echo (versus het niet gebruiken van deze als een methode voor het detecteren van padfout (maar nog steeds het verzenden van echo's).

associate gtpu-service GGSN1_gtpu

Koppelt de genoemde GTPU-service GGSN1_gtpu aan deze GGSN-service

Binding IPv4-adres 209.165.201.2

De IP-adressen van de gebruiker en het controlevlak zijn hetzelfde in de volgende voorbeeldconfiguraties, maar hoeven niet noodzakelijkerwijs als zodanig te worden geconfigureerd met andere implementaties van serviceproviders.

[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

Opmerkingen:

- Aangezien de tijd 0 is wanneer een Echo-aanvraagcyclus start (elke 2 minuten), mislukt het pad als er na een TOTAAL van 30 seconden (6 pogingen) geen reacties zijn (0 + 5 sec + (5 * 5 sec))

- Process egtpinmgr (gtpcmgr afgeschreven sinds v14) draait op de demux kaart is verantwoordelijk voor de verwerking van de echo pakketten

- "toon gtp-statistieken", sectie "Berichten voor padbeheer" bevat statistieken voor de echo-verzoeken/antwoorden voor het controlepad in BEIDE richtingen:

[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

Een andere methode voor paddetectie bevindt zich in het gebruikersvlak in plaats van in het controlevlak, en dit wordt geregeld door de volgende configuratie.

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

Opmerkingen:

- "no echo-interval" schakelt het verzenden van echo-verzoeken voor gebruikersvlak uit en daarom heeft CLI "path-failure detection-policy gtp echo" geen relevantie – er wordt GEEN detectie van padfouten uitgevoerd op GTPU

- GGSN reageert echter nog steeds op echo-verzoeken van de SGSN

- "Show GTPU STAT" en "Show DEMUX-MGR STAT GTPUMGR" leggen echostatistieken vast

[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

Diverse voorbeelden van traject fail traps en uitleg

Meestal zal de peer restart teller met één toenemen wanneer er een herstart is. In dit geval zorgde een bug in PGW ervoor dat het de herstartteller overschrijfde ten opzichte van de waarde van de RC van een andere peer (eerste val), en dus toen het volgende pakket over de verbinding arriveerde, behandelde het het als een herstart (tweede val) denkend dat de RC was veranderd. Het pad wordt vervolgens op elk opeenvolgend pakket (derde val) gewist. Het punt hier is niet om te weten over een specifieke bug, maar eerder om te proberen op de hoogte te zijn van eventuele tegenveranderingen die niet kunnen worden verklaard.

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

Dit voorbeeld is van een GGSN waar de peer SGSN zijn RC heeft gewijzigd van 66 naar 67 via een Create PDP Context Request:

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

Dit voorbeeld is van een PGW waarbij de peer-ePDG zijn RC heeft gewijzigd van 69 naar 70 via een Sessieverzoek aanmaken:

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

In dit voorbeeld laten de uitvoer van verschillende PGW-knooppunten die allemaal met dezelfde SGW zijn verbonden, zien dat de SGW niet meer bereikbaar is vanaf de PGW's per EGTPCPathFail-val bij de verschillende PGW's binnen een kort tijdsbestek van elkaar. Merk op dat alle tonen dezelfde oude herstart teller als eerder werd besproken dat normaal gesproken een knooppunt gebruikt dezelfde teller voor al zijn collega's. In het geval dat er geen reactie is, wordt de nieuwe herstartteller weergegeven op 9, maar de nieuwe teller kan beter als ongedefinieerd worden afgedrukt, omdat de verbinding is uitgeschakeld vanaf het moment dat de trap wordt geactiveerd en dus heeft een herstartteller geen zin.

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

Het volgende voorbeeld toont een padfout en dezelfde nieuwe herstartteller als in het vorige voorbeeld, maar een half uur later wordt weergegeven wanneer de peer weer omhoog komt en de teller met één is gestegen van 15 naar 16. Na verloop van tijd neemt het aantal toe voor die peer:

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)

In dit voorbeeld wordt een fout in het herhalingspad weergegeven als gevolg van het opnieuw opstarten van de CPC voor drie specifieke SGSN-peers met de GGSN. De output hieronder toont slechts een van de peers 209.165.200.225, maar ze hebben allemaal hetzelfde probleem. Herhaalde run van "show egtpc peers" en "show gtpc stat sgsn-address" toont ook de wisselende waarden. "show gtpc stat" bevestigt geen probleem met connectiviteit met betrekking tot echo-verzoeken en antwoorden, die in dit geval alleen worden geïnitieerd door de GGSN (aanvaardbaar zoals eerder besproken). Een zijbalk punt om hier te worden gemaakt is dat er vaak meerdere stukken van gegevens die kunnen worden verzameld die allemaal bevestigen aan dezelfde conclusie - men kan ervoor kiezen om de gegevens die het meest overtuigend met de minimale hoeveelheid inspanning te verzamelen.

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

Kijkend naar andere peers in het subnet, ze tonen allemaal een RC = 132 de hele tijd, terwijl de gebroken peers afwisselen tussen 129 en 132 zoals zojuist getoond, wat wijst op deze SGSN-peers als mogelijk het passeren van de verkeerde RC in de gebroken scenario's:

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

Herinner je van eerder, een andere benadering van kwesties als deze is om andere GGSN's (of PGW's voor LTE) te controleren om te zien of ze hetzelfde probleem hebben met die schijnbaar problematische SGSN-collega's, en in dit geval doen ze dat ook. Voor GGSN3 toonde de eerste run van het commando waarden 132 voor beide peers, maar een andere run toonde 129 voor een van de peers. Meerdere runs (hier niet weergegeven voor de beknoptheid) zouden alle GGSN's laten zien die in de loop van de tijd tussen de twee RC's voor die leeftijdsgenoten stuiteren:

[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

Tot slot om het probleem te bevestigen is de SGSN het wijzigen van de RC, monitor abonnee menu optie door SGSN peer toont veranderende RC's. Wanneer het wel verandert, worden alle oproepen losgekoppeld van padstoring als de reden voor het loskoppelen. Een screenshot van een pakketopname laat dit ook zien:

[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

Dit voorbeeld toont een padfout waarbij het probleem zich daadwerkelijk in het pad bevond en niet de PGW of SGW. Als gevolg daarvan blijft de RC hetzelfde wanneer het pad opnieuw wordt ingesteld. In het tweede peer-voorbeeld is het duidelijke een resultaat van de oprichting van een echo-verzoek:

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

Dit voorbeeld toont een andere anomalie waarbij herhaaldelijk nadat de oude herstartteller is gereset naar 2, deze op de een of andere manier weer op 0 eindigt wanneer het pad faalt. Dit bleek een bug te zijn. Nogmaals, de les hier is dat als iets vreemd lijkt, het moet worden gemeld.

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