Inhoud

Inleiding

Overzicht

Mogelijke redenen voor EGTP-padfouten

Vastlegging vereist

Opdrachten voor troubleshooting

Scenario/redenen in het kort

Problemen met bereikbaarheid - Problemen met netwerkconnectiviteit

Veranderingen in tellerwaarden opnieuw starten

Enorme aanvraag voor inkomend verkeer - netwerkcongestie

Oplossing

Tijdelijke oplossing

Wijzigingen in configuratie

Debugging logboeken

Inleiding

In dit document wordt beschreven hoe u problemen met de uitval van EGTP-pad kunt oplossen.

Overzicht

Geëvolueerde GPRS Tunneling Protocol (EGTP)-padfouten verwijzen naar problemen met het communicatiepad tussen de GTP-knooppunten in een mobiel netwerk. GTP is een protocol dat wordt gebruikt bij het transport van gebruikersgegevens en signaleringsberichten tussen verschillende netwerkelementen.

Mogelijke redenen voor EGTP-padfouten

1. Problemen met bereikbaarheid - Problemen met netwerkconnectiviteit

2. Wijzigingen in teller opnieuw starten

3. Enorme vraag naar inkomend verkeer - netwerkcongestie

4. Configuratie-probleem in termen van DSCP/QOS enzovoort

5. Geen abonnees/sessies op de EGTP-link

Vastlegging vereist

1. SSD's/syslogs rond problematische tijd die het tijdsbestek beslaat ten minste twee uur voordat het probleem tot de huidige tijd is begonnen.

2. Bevestiging van bereikbaarheid met logs, dat wil zeggen, ping en traceroute voor het pad waarvoor padfouten worden gezien.

3. Configuratie tussen problematische en niet-problematische knooppunten.

4. Noodzaak om te bevestigen of er sprake is van een plotselinge toename van het verkeer of een toename van de afwijzing op hetzelfde pad.

5. Bulkstaten in moeilijke tijden die ten minste twee tot drie dagen vóór de afgifte van de vergunning het tijdsbestek beslaan.

Opmerking: afhankelijk van het type probleem kunnen de eerder genoemde logbestanden vereist zijn. Niet alle logbestanden worden elke keer vereist.

Opdrachten voor troubleshooting

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

Scenario/redenen in het kort

Problemen met bereikbaarheid - Problemen met netwerkconnectiviteit

Problemen met de bereikbaarheid treden op wanneer een probleem in het routepad zich op het routeruiteinde of de firewall tussen SGSN/MME en SPGW/GGSN kan voordoen.

ping <destination IP>

traceroute <destination IP> src <source IP>

Opmerking: zowel de opdrachten om de bereikbaarheid te controleren moeten worden gecontroleerd vanuit de inhoud waar de EGTP-service wordt uitgevoerd.

Veranderingen in tellerwaarden opnieuw starten

EGTP-pad behoudt de herstarttellers aan beide uiteinden van het pad tussen SGSN/MME en GGSN/SPGW.

Raadpleeg de link https://www.cisco.com/c/en/us/support/docs/wireless/asr-5000-series/200026-ASR-5000-Series-Troubleshooting-GTPC-and.html om dit soort problemen in detail te begrijpen.

Enorme aanvraag voor inkomend verkeer - netwerkcongestie

Wanneer er plotselinge transacties met veel verkeer zijn, is er een kans op EGTP- en Rx-pakketdruppels. Basiscontroles om dit scenario te bevestigen:

1. U moet controleren of er een hoog CPU-gebruik is voor egtpinmgr.

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. Controleer of het echoverzoek/de echoreactie mislukt (opdracht eerder gedeeld).

3. Kan controleren of er pakketdruppels zijn van de demux-kaart.

Al het EGTP-inkomende verkeer moet via hetzelfde egtpmgr. Als bij één knooppunt padfouten worden waargenomen, gaat het volume van inkomend verkeer waarschijnlijk omhoog. En, kunt u een verkeersdaling op het egtpmgr procesniveau ervaren. Zelfs het gezamenlijk gesitueerde proces moet door dezelfde egtpmgr-wachtrij gaan en geraakt worden.

Hier is de stap om pakketverlies te controleren die met meerdere herhalingen moet worden genomen

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. Moet egtpinmgr CPU profiler output opnemen als u hoge CPU voor egtpinmgr ziet.

Als alle bovenstaande voorwaarden geldig zijn, kunt u de vermelde mogelijke oplossing controleren.

Oplossing

1. Verhoging van de EGTP echo-timeout - Als 5 seconden niet helpen, kunt u 15 of 25 proberen. Je kunt dit bespreken met je AS team om dit te tunen.

2. Verminder de time-out bij peer-redding - Hoe lager de waarde bij time-out, hoe minder het aantal inactieve peers, dus u kunt de tijdwaarde met deze opdracht wijzigen:

gtpc peer-salvation min-peers 2000 timeout 24

3. overbelastingsbeveiliging - overbelastingsbeveiliging kan worden geoptimaliseerd op basis van de verkeerstrend omdat zonder de exacte inkomende verkeerssnelheid te kennen voordat egpinmgr het probleem raakt, het moeilijk is om dit te tunen. Verkeerde afstemming kan ook leiden tot extra signaleringsverkeer door stille dalingen.

Zo, voor de optimalisering van de overbelastingsbescherming, kunt u sommige pakketdalingen van de demux kaart voor egtpinmgr en CPU profileroutput verzamelen zoals eerder vermeld.

4. Geen abonnees/sessies op de EGTP-link - als er geen sessies via een specifieke tunnel worden uitgevoerd, wordt de GTP-echofunctionaliteit gestopt. Als er geen/geen verbonden abonnee is, mag GTPC echo niet worden verzonden.

Hier zijn de fouten die u ziet wanneer de echofunctionaliteit wordt tegengehouden:

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

Tijdelijke oplossing

U kunt proberen om de egtpinmgr taak opnieuw te starten om te herstellen. Maar het herstarten van de egtpinmgr kan een kortetermijneffect hebben, onmerkbaar voor de eindgebruiker, terwijl de NPU-stromen opnieuw worden geïnstalleerd in de nieuwe taak.

Het moet minder dan 1 seconde duren om deze bewerking te voltooien.

1. Schakel de detectie van padfouten uit:

egtp-service S5-PGW

no gtpc path-failure detection-policy

2. Vermoord egtpinmgr taak:

task kill facility egtpinmgr  all

3. Schakel de detectie van padfouten in:

egtp-service S5-PGW

gtpc path-failure detection-policy

Opmerking: deze tijdelijke oplossing moet alleen in MW worden geïmplementeerd, omdat dit enige impact kan hebben.

Wijzigingen in configuratie

De configuratie in termen van DSCP/QOS/EGTP IP-pad/servicetoewijzing kan worden gecontroleerd.

Opmerking: dit zijn de belangrijkste redenen die bijdragen aan EGTP-padfouten, maar in het geval dat geen van de scenario's worden gevonden, kunt u enkele sporen en debugging logboeken verder verzamelen.

Debugging logboeken

(Indien vereist)

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>