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>