Inhalt

Einleitung

Befehle für die Fehlerbehebung

Analyse

StarOS Perspektive

Problemumgehung

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.