Probleemoplossing voor EGTP-padfouten als gevolg van mismatch in waarden van herstartteller

Inleiding

Dit document beschrijft de probleemoplossing bij fouten in het opstarttegenwaarden van het Evolved-GPRS Tunneling Protocol (EGTP)-pad die zijn waargenomen als gevolg van een slechte combinatie van SGSN/MME en GGSN/Serving Gateway of PDN Gateway (SPGW).

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 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

Uit de logboeken en statistieken blijkt dat de starttegenwaarde op het einde van de Mobility Management Entity (MME) 11 is en op het einde van de EPG 12.

U kunt de vallen zoals hier vermeld waarnemen:

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

Vendor Gateway (GW) heeft een probleem bij het accepteren van lagere waarden van het Serving GPRS Support Node (SGSN) als de herstartteller wordt gewijzigd. Als leverancier GW een hogere waarde (oude) heeft opgeslagen en na het opnieuw laden van de knooppunt als Cisco SGSN een lagere waarde verzendt, accepteert leverancier GW deze niet.

Opmerking: Zoals in TS 29.060:

1. Als het SGSN voor het eerst contact opneemt met het GPRS-ondersteuningsknooppunt (GGSN) van de gateway of onlangs opnieuw is gestart zonder de nieuwe herstarttegenwaarde voor het GGSN aan te geven, neemt het een informatie-element voor herstel op in het PDP-contextverzoek (Create Policy Decision Point). Dit element wordt indien nodig door het SGSN opgenomen. De GGSN die een herstelinformatie-element ontvangt in het Create PDP Context request-bericht behandelt het als bij het ontvangen van een Echo Response-bericht. Het bericht PDP-contextverzoek maken wordt beschouwd als een geldig activeringsverzoek voor de PDP-context die in het bericht is opgenomen.

2. De GGSN omvat het herstelinformatie-element in de Create PDP Context Response als de GGSN voor het eerst in contact komt met de SGSN of de GGSN onlangs opnieuw is gestart en de nieuwe Reststart Counter Value nog niet aan de SGSN is aangegeven. Het SGSN dat het herstelinformatie-element ontvangt, behandelt dit als wanneer een Echo Response-bericht wordt ontvangen. Het beschouwt de PDP-context echter als actief als de respons wijst op succesvolle contextactivering bij de GGSN.

3. De GTP-interface gebruikt een herstartteller om het aantal herstart te volgen. In overeenstemming met TS 23.060 moeten GTP-knooppunten gebruik maken van permanente opslag om hun lokale GTP-herstarttellers bij te houden, zodat men verwacht dat deze herstarttellers altijd naar boven zullen gaan. Echter, in het geval dat een peer knooppunt een daling in de herstartteller detecteert, wordt het GTP knoopgedrag uitgewerkt in sessie '18 GTP-C gebaseerde herstartprocedures' van TS 23.007. Stel dat de waarde van een herstartteller die eerder is opgeslagen voor een peer groter is dan de herstartteller die is ontvangen in het Echo Response-bericht of het GTP-C-bericht, waarbij rekening wordt gehouden met het gehele omvergooien. In dat geval geeft dit aan dat er mogelijk sprake is van een race-omstandigheid (een nieuwer bericht komt voor de oudere). De ontvangen nieuwe waarde van de herstartteller wordt genegeerd en een fout kan worden vastgelegd. Met andere woorden, wanneer de GTP-knooppunt een lagere herstartteller van een peer detecteert, neemt het nooit die nieuwe herstartteller op.

StarOS-perspectief

Vanaf het StarOS-uiteinde kunt u de RC-waarde in de StarOS expliciet wijzigen van het pad /flash/restart_file_cntr.txt dat ten tijde van de upgrade wordt uitgevoerd.

Volgens deze theorie was bij vergelijking met de huidige configuratie de MME RC-waarde lager dan de GW RC-waarde van de leverancier. Om dit probleem op te lossen is de RC-waarde in het GW-knooppunt van de leverancier gewijzigd.

Nu na het veranderen van de RC waarde, wordt gezien dat de mislukkingen van het EGTPC-pad gestopt maar nog steeds, sessies niet toenemen en EGTPC-koppelingen nog steeds inactief.

Dit zijn de opdrachten die tijdens probleemoplossing zijn gebruikt:

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

Verdere controle echo verzoek/antwoord (te controleren in verborgen modus):

egtpc test echo gtp-version 2 src-address <MME end IP> peer-address <EPG end IP> 

Dit is de output wanneer de waarde van de Teller van de Herstart wordt verbeterd en het zelfde als dat van MME voor de interface S11 voor de beïnvloede peer van EGTP en dan is het verzoek/de reactie van de Echo fijn maar de verbinding is nog inactief gevormd.

[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)

Bij andere problematische GW’s werkt dit echter niet zoals verwacht. Je krijgt nog steeds een fout voor echo verzoek/antwoord zoals hier vermeld.

[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)

Tijdelijke oplossing

1. Neem om dit probleem op te lossen kennis van de huidige herstartteller in /flash/restart_file_cntr.txt voordat de VNF wordt gedeactiveerd. Later, wanneer het wordt geactiveerd met nieuwe software, log in bij CF en update het bestand /flash/restart_file_cntr.txt met de oude start teller. Vervolgens, als een normale upgrade procedure, herladen van de VNF met day-N configuratie.

2. Wijzig de kat /flash/restart_file_cntr.txt in de gewenste waarde en herlaad het knooppunt met de huidige configuratie.

Opmerking: u kunt het opnieuw proberen met SGTPC opnieuw starten als de eerste stap.