Einleitung
In diesem Dokument wird die Fehlerbehebung bei EGTP-Pfadfehlern (Evolved-GPRS Tunneling Protocol) beschrieben, die aufgrund einer Diskrepanz bei den Neustartzählerwerten zwischen SGSN/MME und GGSN/Serving Gateway oder PDN Gateway (SPGW) aufgetreten sind.
Befehle für die Fehlerbehebung
show egtpc peers interface
show egtpc peers path-failure-history
show egtpc statistics path-failure-reasons
show egtp-service all
show egtpc sessions
show egtpc statistics
egtpc test echo gtp-version 2 src-address <source node IP address> peer-address <remote node IP address>
For more details about this commands refer this mentioned link
https://www.cisco.com/c/en/us/support/docs/wireless-mobility/gateway-gprs-support-node-ggsn/119246-technote-ggsn-00.html
Analyse
Aus den Protokollen und Statistiken wird erkannt, dass der Zählerwert für den Neustart am MME-Ende 11 und am EPG-Ende 12 beträgt.
Sie können die Fallen wie hier erwähnt beobachten:
Internal trap notification 1112 (EGTPCPathFail) context s11mme, service s11-mme, interface type mme, self address <X.X.X.X>, peer address <Y.Y.Y.Y>, peer old restart counter 4, peer new restart counter 4, peer session count 240, failure reason no-response-from-peer, path failure detection Enabled.
Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address <X.X.X.X>, peer address <Y.Y.Y.Y>, peer old restart counter 54, peer new restart counter 12, peer session count 1107240, failure reason restart-counter-change
Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address <X.X.X.X>, peer address <Y.Y.Y.Y>, peer old restart counter 12, peer new restart counter 54, peer session count 1107207, failure reason create-sess-restart-counter-change
Beim Vendor Gateway (GW) ist es problematisch, kleinere Werte vom Serving GPRS Support Node (SGSN) zu akzeptieren, wenn der Zähler für den Neustart geändert wird. Wenn der Vendor GW einen höheren (alten) Wert gespeichert hat und wenn der Knoten einen niedrigeren Wert vom Cisco SGSN sendet, akzeptiert der Vendor GW diesen nicht.
Hinweis: Gemäß TS 29.060:
1. Wenn der SGSN zum ersten Mal mit dem Gateway GPRS Support Node (GGSN) in Verbindung steht oder kürzlich neu gestartet wurde, ohne den neuen Wert für den Zähler für den Neustart für den GGSN anzugeben, enthält er ein Wiederherstellungsinformationselement in der Kontextanforderung für den Create Policy Decision Point (PDP). Dieses Element wird bei Bedarf vom SGSN bereitgestellt. Der GGSN, der ein Wiederherstellungsinformationselement im Create PDP Context Request-Nachrichtenelement empfängt, behandelt es wie beim Empfang einer Echo Response-Nachricht. Die Nachricht Create PDP Context Request (PDP-Kontextanforderung erstellen) gilt als gültige Aktivierungsanforderung für den in der Nachricht enthaltenen PDP-Kontext.
2. Der GGSN enthält das Element Wiederherstellungsinformationen in die Create PDP Context Response (PDP-Kontextantwort erstellen), wenn der GGSN zum ersten Mal mit dem SGSN in Kontakt steht oder der GGSN vor kurzem neu gestartet wurde und der neue Wert für den Zähler für den Neustart noch nicht für den SGSN angegeben wurde. Das SGSN, das das Wiederherstellungsinformationselement empfängt, behandelt dies wie den Empfang einer Echo-Antwortnachricht. Er betrachtet jedoch den erstellten PDP-Kontext als aktiv, wenn die Antwort auf eine erfolgreiche Kontextaktivierung beim GGSN hinweist.
3. Die GTP-Schnittstelle verwendet einen Neustartzähler, um die Anzahl der Neustarts zu verfolgen. Gemäß TS 23.060 müssen GTP-Knoten einen permanenten Speicher verwenden, um ihre lokalen GTP-Neustart-Zähler zu verfolgen. Daher wird erwartet, dass diese Neustart-Zähler immer nach oben fortfahren. Sollte jedoch ein Peer-Knoten eine Abnahme des Neustartzählers erkennen, wird das GTP-Knotenverhalten in Session '18 GTP-C based restart procedures' von TS 23.007 ausgeführt. Angenommen, der Wert eines Neustartzählers, der zuvor für einen Peer gespeichert wurde, ist größer als der Wert des Neustartzählers, der in der Echo-Antwort-Nachricht oder der GTP-C-Nachricht empfangen wurde, wobei der Ganzzahlrollover berücksichtigt wird. In diesem Fall weist dies auf eine mögliche Race Condition hin (neuere Nachricht, die vor der älteren ankommt). Der empfangene neue Neustart-Zählerwert wird verworfen, und ein Fehler kann protokolliert werden. Mit anderen Worten: Wenn der GTP-Knoten einen niedrigeren Neustartzähler von einem Peer erkennt, zeichnet er diesen neuen Neustartzähler nie auf.
StarOS Perspektive
Von der StarOS-Seite aus können Sie den RC-Wert in StarOS explizit vom Pfad ändern, der zum Zeitpunkt des Upgrades angegeben ist/flash/restart_file_cntr.txt.
Nach dieser Theorie war der MME RC-Wert beim Vergleich mit der aktuellen Konfiguration niedriger als der GW RC-Wert des Anbieters. Um das Problem zu beheben, wurde der RC-Wert am GW-Knoten des Anbieters geändert.
Nachdem der RC-Wert geändert wurde, wird deutlich, dass die EGTPC-Pfadfehler gestoppt wurden, die Sitzungen jedoch nicht zunehmen und die EGTPC-Verbindungen weiterhin inaktiv angezeigt werden.
Folgende Befehle wurden bei der Fehlerbehebung verwendet:
show sgtp-service all | grep "restart" ----------------- to check RC value
[local]Nodename# show egtp-service all | more
Service name : egtpc_sv_service
Service-Id : 5
Context : SGs
Interface Type : mme
Status : STARTED
Restart Counter : 11 ----------------- RC value to verify
Max Remote Restart Counter Change : 255
Message Validation Mode : Standard
GTPU-Context :
GTPC Retransmission Timeout : 5000 (milliseconds)
GTPC Maximum Request Retransmissions : 4
GTPC IP QOS DSCP value : 10
GTPC Echo : Enabled
GTPC Echo Mode : Default
[local]Nodename# show egtpc peers ------------ To check link status
Sunday February 05 15:31:00 IST 2023
+----Status: (I) - Inactive (A) - Active
|
|+---GTPC Echo: (D) - Disabled (E) - Enabled
||
||+--Restart Counter Sent: (S) - Sent (N) - Not Sent
|||
|||+-Peer Restart Counter: (K) - Known (U) - Unknown
||||
||||+-Type of Node: (S) - SGW (P) - PGW
||||| (M) - MME (G) - SGSN
||||| (L) - LGW (E) - ePDG
||||| (C) - CGW (B) - MBMS
||||| (U) - Unknown
|||||
||||| Service Restart--------+ No. of
||||| ID Counter | restarts
||||| | | | Current Max
vvvvv v Peer Address v v sessions sessions LCI OCI
----- --- --------------------------------------- --- --- ----------- ------------------
IDSKS 10 X.X.X.X 91 0 0 0 X X
IDNKS 11 Y.Y.Y.Y 4 95 0 34005 X X
IDNKS 11 Z.Z.Z.Z 10 103 0 16805 X X
IDNKS 11 A.A.A.A 104 95 0 7250 X X
AESKS 11 B.B.B.B 0 0 4004 47649 X X
AESKS 11 C.C.C.C 0 0 4053 46571 X X
AESKS 11 D.D.D.D 0 0 4026 46734 X X
ABove output peers if you see no sessions on this peer and also link are inactive
Überprüfen Sie die Echo-Anfrage/-Antwort (im ausgeblendeten Modus zu prüfen):
egtpc test echo gtp-version 2 src-address <MME end IP> peer-address <EPG end IP>
Dies ist die Ausgabe, wenn der Wert für den Neustart-Zähler korrigiert und wie MME für die S11-Schnittstelle für den betroffenen EGTP-Peer konfiguriert wurde. Die Echo-Anforderung/-Antwort ist in Ordnung, die Verbindung ist jedoch weiterhin inaktiv.
[s11mme]Nodename# egtpc test echo gtp-version 2 src-address <X.X.X.X> peer-address <Y.Y.Y.Y>
Sunday February 05 16:22:42 IST 2023
EGTPC test echo
---------------
Peer: X.X.X.X Tx/Rx: 1/1 RTT(ms): 1 (COMPLETE) Recovery: 10 (0x0A)
Bei anderen problematisch betroffenen GWs funktioniert dies jedoch nicht wie erwartet. Es tritt weiterhin ein Fehler bei der Echo-Anfrage/-Antwort auf, wie hier erwähnt.
[s11mme]Nodename# egtpc test echo gtp-version 2 src-address <X.X.X.X> peer-address <Y.Y.Y.Y>
Sunday February 05 16:46:11 IST 2023
EGTPC test echo
---------------
Peer: X.X.X.X Tx/Rx: 1/0 RTT(ms): 0 (FAILURE)
Problemumgehung
1. Um dieses Problem zu beheben, notieren Sie sich den aktuellen Neustart-Zähler in vor der Deaktivierung der VNF/flash/restart_file_cntr.txt. Wenn Sie später mit neuer Software aktiviert wird, melden Sie sich bei CF an, und aktualisieren Sie die Datei /flash/restart_file_cntr.txt mit dem alten Neustartzähler. Laden Sie dann die VNF mit der Tag-N-Konfiguration wie gewohnt neu.
2. Ändern Sie den Wert cat/flash/restart_file_cntr.txt auf den erforderlichen Wert, und laden Sie den Knoten mit der aktuellen Konfiguration neu.
Hinweis: Sie können den SGTPC-Neustart auch einmal als ersten Schritt versuchen.