Risoluzione dei problemi di percorso EGTP a causa di una mancata corrispondenza nei valori del contatore di riavvio

Introduzione

In questo documento viene descritta la risoluzione dei problemi degli errori di percorso EGTP (Evolved-GPRS Tunneling Protocol) rilevati a causa di una mancata corrispondenza nei valori dei contatori di riavvio tra SGSN/MME e GSN/Serving Gateway o PDN Gateway (SPGW).

Comandi per la risoluzione dei problemi

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

Analisi

Dai registri e dalle statistiche risulta che il valore del contatore di riavvio all'estremità MME (Mobility Management Entity) è 11, mentre all'estremità EPG è 12.

È possibile osservare le trappole come indicato di seguito:

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

Problema del gateway fornitore (GW) durante l'accettazione di valori inferiori dal nodo di supporto GPRS (SGSN) del server se il contatore di riavvio viene modificato. Se il fornitore GW ha memorizzato un valore più alto (precedente) e, dopo il ricaricamento del nodo, Cisco SGSN invia un valore più basso, il fornitore GW non lo accetta.

Nota: in base a TS 29.060:

1. Se il SGSN è in contatto con il GPRS Support Node (GSN) del gateway per la prima volta o è stato riavviato di recente senza indicare il nuovo valore del contatore di riavvio nel GSN, il SGSN incorpora un elemento relativo alle informazioni sul ripristino nella richiesta di contesto Crea punto di decisione dei criteri (PDP). Questo elemento viene incluso dal SGSN quando necessario. Il GSN che riceve un elemento di informazioni Recupero nell'elemento del messaggio Crea richiesta di contesto PDP lo gestisce come quando riceve un messaggio di risposta echo. Il messaggio Crea richiesta di contesto PDP è considerato una richiesta di attivazione valida per il contesto PDP incluso nel messaggio.

2. Il GSN include l'elemento Informazioni recupero nella risposta Crea contesto PDP se il GSN è in contatto con il SGSN per la prima volta o se il GSN è stato riavviato di recente e il nuovo valore del contatore riavvio non è ancora stato indicato al SGSN. L'SGSN che riceve l'elemento di informazioni Recupero lo gestisce come quando viene ricevuto un messaggio di risposta echo. Considera tuttavia attivo il contesto PDP in fase di creazione se la risposta indica la riuscita dell'attivazione del contesto nel GSN.

3. L'interfaccia GTP utilizza un contatore di riavvio per tenere traccia del numero di riavvii. In base a TS 23.060, i nodi GTP devono utilizzare l'archiviazione persistente per tenere traccia dei contatori di riavvio GTP locali, in modo che questi contatori di riavvio procedano sempre verso l'alto. Tuttavia, nel caso in cui un nodo peer rilevi una diminuzione nel contatore di riavvio, il comportamento del nodo GTP viene elaborato nella sessione '18 GTP-C based restart procedures' di TS 23.007. Si supponga che il valore di un contatore di riavvio precedentemente archiviato per un peer sia maggiore del valore del contatore di riavvio ricevuto nel messaggio di risposta echo o nel messaggio GTP-C, tenendo conto del rollover dell'intero. In questo caso, indica una possibile condizione di razza (messaggio più recente che arriva prima del messaggio più vecchio). Il nuovo valore del contatore Restart ricevuto viene scartato ed è possibile registrare un errore. In altre parole, quando il nodo GTP rileva un contatore di riavvio inferiore da un peer, non registra mai il nuovo contatore di riavvio.

Prospettiva StarOS

Dall'estremità StarOS, è possibile modificare esplicitamente il valore RC in StarOS dal percorso /flash/restart_file_cntr.txt che viene eseguito al momento dell'aggiornamento.

In base a questa teoria, quando la si confronta con la configurazione corrente, il valore MME RC era inferiore al valore GW RC del fornitore. Per risolvere il problema, è stato modificato il valore RC nel nodo GW del fornitore.

Ora, dopo aver modificato il valore RC, si nota che gli errori del percorso EGTPC sono stati arrestati, ma le sessioni non aumentano e i collegamenti EGTPC continuano a essere inattivi.

Di seguito sono riportati i comandi utilizzati durante la risoluzione dei problemi:

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

Verificare inoltre la richiesta/risposta echo (da controllare in modalità nascosta):

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

Questo è l'output quando il valore del contatore di riavvio viene corretto e configurato come quello di MME per l'interfaccia S11 per il peer EGTP interessato e quindi la richiesta/risposta Echo è corretta, ma il collegamento è ancora inattivo.

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

Tuttavia, lo stesso non funziona come previsto su altri GW problematici. Si verifica ancora un errore nella richiesta/risposta echo, come indicato qui.

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

Soluzione alternativa

1. Per risolvere il problema, prendere nota del contatore di riavvio corrente prima della/flash/restart_file_cntr.txt disattivazione della VNF. In seguito, quando verrà attivata con il nuovo software, accedere a CF e aggiornare il file /flash/restart_file_cntr.txt con il vecchio contatore di riavvio. Quindi, come procedura di aggiornamento normale, ricaricare il VNF con la configurazione day-N.

2. Modificare il cat /flash/restart_file_cntr.txt sul valore richiesto e ricaricare il nodo con la configurazione corrente.

Nota: è possibile provare con il riavvio di SGTPC anche una volta come fase iniziale.