Fehlerbehebung bei EGTP-Pfadfehlern

Einleitung

In diesem Dokument wird die Fehlerbehebung bei Problemen mit dem EGTP-Pfad beschrieben.

Überblick

EGTP-Pfadfehler (Evolved GPRS Tunneling Protocol) beziehen sich auf Probleme mit dem Kommunikationspfad zwischen den GTP-Knoten in einem mobilen Netzwerk. GTP ist ein Protokoll, das für den Transport von Nutzdaten und Signalisierungsnachrichten zwischen verschiedenen Netzwerkelementen verwendet wird.

Mögliche Gründe für EGTP-Pfadfehler

1. Erreichbarkeitsproblem - Probleme mit der Netzwerkverbindung

2. Zählerwertänderungen neu starten

3. Große Anforderung von eingehendem Datenverkehr - Netzwerküberlastung

4. Konfigurationsproblem mit DSCP/QoS usw.

5. Keine Teilnehmer/Sitzungen auf dem EGTPC-Link

Erforderliche Protokolle

1. SSD/Syslogs rund um problematische Zeit deckt den Zeitrahmen mindestens zwei Stunden vor Beginn der Ausgabe bis zur aktuellen Zeit.

2. Erreichbarkeitsbestätigung mit Protokollen, d. h. Ping und Traceroute für den Pfad, für den Pfadfehler festgestellt werden.

3. Konfigurationsprüfung zwischen problematischen und unproblematischen Knoten.

4. Muss bestätigen, wenn eine plötzliche Zunahme des Datenverkehrs oder eine Erhöhung der Ablehnung auf dem gleichen Pfad.

5. Bulkstats während problematischer Zeiten, die den Zeitrahmen mindestens 2-3 Tage vor der Ausgabe abdecken.

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 related to above command refer doc as mentioned below

https://www.cisco.com/c/en/us/support/docs/wireless-mobility/gateway-gprs-support-node-ggsn/119246-technote-ggsn-00.html

SNMP-Traps:

Sun Feb 05 03:00:20 2023 Internal trap notification 1112 (EGTPCPathFail) context s11mme, service s11-mme, interface type mme, self address x.x.x.x.,  peer address 10.0.219.57, peer old restart counter 4,  peer new restart counter 4,  peer session count  240, failure reason no-response-from-peer,  path failure detection Enabled

Tue Jul 09 18:41:36 2019 Internal trap notification 1112 (EGTPCPathFail) context pgw, service s5-s8-sgw-egtp, interface type sgw-egress, self address x.x.x.x,  peer address x.x.x.x, peer old restart counter 27,  peer new restart counter 27,  peer session count  1, failure reason no-response-from-peer,  path failure detection Enabled

Szenario/Gründe in Kürze

Erreichbarkeitsproblem - Probleme mit der Netzwerkverbindung

Erreichbarkeitsprobleme treten auf, wenn ein Problem im Routing-Pfad auf dem Router-Ende oder der Firewall zwischen SGSN/MME und SPGW/GGSN auftreten kann.

ping <destination IP>

traceroute <destination IP> src <source IP>

Neustarten von Zählerwertänderungen

Über den EGTP-Pfad werden die Neustartzähler an beiden Enden des Pfads zwischen SGSN/MME und GGSN/SPGW beibehalten.

Unter dem Link https://www.cisco.com/c/en/us/support/docs/wireless/asr-5000-series/200026-ASR-5000-Series-Troubleshooting-GTPC-and.html finden Sie weitere Informationen zu dieser Art von Problem.

Enorme Anforderung von eingehendem Datenverkehr - Netzwerküberlastung

Bei plötzlichen Transaktionen mit hohem Datenverkehr besteht die Chance, dass EGTP-Pakete vom Typ Tx und Rx verworfen werden. Grundlegende Prüfungen zur Bestätigung dieses Szenarios:

1. Sie müssen überprüfen, ob eine hohe CPU-Auslastung für egtpinmgr vorliegt.

Mar 25 14:30:48 10.224.240.132 evlogd: [local-60sec48.142] [resmgr 14907 debug] [6/0/10088 <rmmgr:60> _resource_log.c:1391] [software internal system critical-info syslog] RM-60: rmmgr_collect_cpustats_coproc_done: ahm cpustats logged for egtpinmgr instance 2 in cpu warn state file <cpustats-5e7b40db-06-00-egtpinmgr-2-6192>
Mar 25 14:31:05 10.224.240.132 evlogd: [local-60sec5.707] [resmgr 14907 debug] [6/0/10088 <rmmgr:60> _resource_log.c:1391] [software internal system critical-info syslog] RM-60: rmmgr_collect_cpustats_coproc_done: ahm cpustats logged for egtpinmgr instance 2 in cpu warn state file <cpustats-5e7b40f9-06-00-egtpinmgr-2-6192>

2. Überprüfen Sie, ob die Echoanfrage/-antwort fehlschlägt (zuvor freigegebener Befehl).

3. Kann überprüfen, ob Pakete von der Demux-Karte verloren gehen.

Der gesamte eingehende EGTP-Datenverkehr muss über denselben egtpmgr erfolgen. Wenn bei einem Knoten Pfadausfälle festgestellt werden, steigt das Volumen des eingehenden Verkehrs wahrscheinlich an. Außerdem können Sie einen Datenverkehrsverlust auf Ebene des egtpmgr-Prozesses feststellen. Selbst der am selben Standort durchgeführte Prozess muss dieselbe egtpmgr-Warteschlange durchlaufen, um sich auszuwirken.

Im Folgenden wird der Schritt zum Überprüfen von Paketverlusten beschrieben, die mit mehreren Iterationen durchgeführt werden müssen.

debug shell card <> cpu 0

cat /proc/net/boxer



******** card1-cpu0 /proc/net/boxer *******
Wednesday March 25 17:34:54 AST 2020
what                   total_used next    refills     hungry  exhausted  system_rate_kbps      system_credits    max_bhn
bdp_rld           4167990936249KB  094   51064441        292          1  3557021/65000000 7825602KB/7934570KB   793457KB
what                 bhn local            remote                   ver         rx    rx_drop         tx    tx_drop    no_dest     no_src
total cpu 34         *   *                *                          *    3274522         59         60          0    1307242          0
total cpu 35         *   *                *                          *    6330639         46        121          0    1086591          0
total cpu 46         *   *                *                          *    5076520         27      15524          0     786982          0
total cpu 47         *   *                *                          * 4163101019      83922  133540922          0     886241          0

4. Muss die Ausgabe des egtpinmgr CPU Profilers erfassen, wenn Sie eine hohe CPU für egtpinmgr sehen.

Wenn alle oben genannten Bedingungen gültig sind, können Sie nach der genannten möglichen Lösung suchen.

Lösung

1. Vergrößerung des EGTP-Echo-Timeouts: Wenn 5 Sekunden nicht helfen, können Sie 15 oder 25 versuchen. Sie können dies mit Ihrem AS-Team besprechen, um dies abzustimmen.

2. Verringern Sie den Timeout für Peer-Bergung - Je niedriger der Timeout-Wert, desto weniger inaktive Peers. Sie können den Zeitwert daher mit dem folgenden Befehl ändern:

gtpc peer-salvation min-peers 2000 timeout 24

3. Überlastungsschutz - Überlastungsschutzoptimierung kann basierend auf dem Datenverkehrstrend durchgeführt werden, da ohne die genaue Eingangsverkehrsrate zu kennen, bevor egpinmgr auf das Problem trifft, es schwierig ist, dies anzupassen. Außerdem kann eine falsche Feinabstimmung zu zusätzlichem Signalisierungsverkehr führen, da es zu unbeaufsichtigten Unterbrechungen kommt.

Um den Überlastungsschutz zu optimieren, können Sie also, wie bereits erwähnt, einige Paketverluste von der Demux-Karte für egtpinmgr- und CPU-Profiler-Ausgaben sammeln.

4. Keine Abonnenten/Sitzungen auf dem EGTPC-Link - Wenn keine Sitzungen über einen bestimmten Tunnel vorhanden sind, wird die GTP-Echo-Funktion gestoppt. Wenn kein angeschlossener Teilnehmer vorhanden ist, darf kein GTPC-Echo gesendet werden.

Wenn die Echo-Funktion beendet wird, werden folgende Fehler angezeigt:

2019-Jul-26+08:41:51.261 [egtpmgr 143047 debug] [1/0/4626 <egtpinmgr:2> egtpmgr_pm.c:798] [context: EPC, contextID: 2]  [software internal system syslog] service : S5-S8-PGW - GTP-C Periodic ECHO timer stopped for peer address 10.2.1.51
2019-Jul-26+08:41:51.261 [egtpmgr 143048 debug] [1/0/4626 <egtpinmgr:2> egtpmgr_pm.c:818] [context: EPC, contextID: 2]  [software internal system syslog] service : S5-S8-PGW - GTP-C ECHO stopped towards peer 10.2.1.51

Problemumgehung

Sie können versuchen, die Aufgabe egtpinmgr neu zu starten, um sich zu erholen. Der Neustart des egtpinmgr kann jedoch kurzfristige Auswirkungen haben, die für den Endbenutzer nicht bemerkbar sind, während die NPU-Flows bei der neuen Aufgabe neu installiert werden.

Dieser Vorgang muss weniger als 1 Sekunde in Anspruch nehmen.

1. Deaktivieren Sie die Pfadausfallerkennung:

    egtp-service S5-PGW

       no gtpc path-failure detection-policy

2. Beenden Sie die Aufgabe egtpinmgr:

task kill facility egtpinmgr  all

3. Aktivieren Sie die Pfadfehlererkennung:

    egtp-service S5-PGW

       gtpc path-failure detection-policy

Konfigurationsänderungen

Die Konfiguration hinsichtlich der DSCP-/QOS-/EGTP-IP-Pfad-/Service-Zuordnung kann überprüft werden.

Debugging-Protokolle

(Falls erforderlich)

logging filter active facility egtpc level<critical/error/debug>
logging filter active facility egtpmgr level<critical/error/debug>
logging filter active facility egtpinmgr level<critical/error/debug>