Solucionar problemas de errores de ruta de EGTP debido a discordancia en los valores de contador de reinicio

Introducción

Este documento describe la solución de problemas de fallas de trayectoria del Protocolo de tunelización Evolved-GPRS (EGTP) observadas debido a una discordancia en los valores del contador de reinicio entre SGSN/MME y GGSN/Serving Gateway o PDN Gateway (SPGW).

Comandos para resolución de problemas

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

Análisis

A partir de los registros y las estadísticas, se identifica que el valor del contador de reinicio en el extremo de la entidad de administración de movilidad (MME) es 11 y en el extremo de EPG es 12.

Puede observar las trampas como se menciona aquí:

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

La puerta de enlace del proveedor (GW) tiene un problema al aceptar valores menores del nodo de soporte de GPRS de servicio (SGSN) si se cambia el contador de reinicio. Si el proveedor GW ha almacenado un valor mayor (el anterior) y después de la recarga del nodo si Cisco SGSN envía un valor menor, el proveedor GW no lo acepta.

Nota: Según TS 29.060:

1. Si el SGSN está en contacto con el GPRS Support Node (GGSN) de la puerta de enlace por primera vez o se ha reiniciado recientemente sin indicar el nuevo valor del contador de reinicio al GGSN, incorpora un elemento de información de recuperación en la solicitud de contexto de creación de punto de decisión de política (PDP). Este elemento lo incluye el SGSN cuando es necesario. El GGSN que recibe un elemento de información de recuperación en el elemento de mensaje Create PDP Context Request lo maneja como cuando recibe un mensaje de respuesta de eco. El mensaje Create PDP Context Request se considera una solicitud de activación válida para el contexto PDP incluido en el mensaje.

2. El GGSN incluye el elemento de información de recuperación en la respuesta de contexto Create PDP si el GGSN está en contacto con el SGSN por primera vez o el GGSN se ha reiniciado recientemente y el nuevo valor de contador de reinicio aún no se ha indicado al SGSN. El SGSN que recibe el elemento de información de recuperación lo maneja como cuando se recibe un mensaje de respuesta de eco. Sin embargo, considera que el contexto PDP que se está creando es activo si la respuesta indica una activación exitosa del contexto en el GGSN.

3. La interfaz GTP utiliza un contador de reinicio para realizar un seguimiento del número de reinicios. Según TS 23.060, los nodos GTP deben utilizar almacenamiento persistente para realizar un seguimiento de sus contadores de reinicio GTP locales, de modo que se espera que estos contadores de reinicio continúen siempre hacia arriba. Sin embargo, en caso de que un nodo de peer detecte una disminución en el contador de reinicio, el comportamiento del nodo GTP se desarrolla en la sesión '18 GTP-C based restart procedures' de TS 23.007. Supongamos que el valor de un contador de reinicio almacenado previamente para un par es mayor que el valor del contador de reinicio recibido en el mensaje de respuesta de eco o el mensaje GTP-C, teniendo en cuenta el rollover de enteros. En ese caso, esto indica una posible condición de carrera (mensaje más reciente que llega antes que el más antiguo). El nuevo valor del contador de reinicio recibido se descarta y se puede registrar un error. En otras palabras, cuando el nodo GTP detecta un contador de reinicio inferior de un par, nunca registra ese nuevo contador de reinicio.

Perspectiva de StarOS

Desde el extremo de StarOS, puede cambiar explícitamente el valor RC en StarOS de la trayectoria /flash/restart_file_cntr.txt que se realiza en el momento de la actualización.

Según esta teoría, al compararlo con la configuración actual, el valor de MME RC era inferior al valor de proveedor GW RC. Para solucionar el problema, se modificó el valor RC en el nodo GW del proveedor.

Ahora, después de cambiar el valor de RC, se ve que las fallas de trayectoria de EGTPC se detuvieron, pero aún así, las sesiones no están aumentando y los links de EGTPC siguen mostrándose inactivos.

Estos son los comandos que se utilizaron durante la resolución de problemas:

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

Además. verifique la solicitud/respuesta de eco (para ser verificada en modo oculto):

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

Este es el resultado cuando el valor del contador de reinicio se corrige y configura igual que el de MME para la interfaz S11 para el peer EGTP afectado y luego la solicitud/respuesta de eco está bien pero el link sigue inactivo.

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

Sin embargo, lo mismo no funciona como se esperaba en otros bienes y servicios problemáticos afectados. Aún se obtiene una falla para la solicitud/respuesta de eco como se menciona aquí.

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

Solución Aternativa

1. Para solucionar este problema, tome nota del contador de reinicio actual en /flash/restart_file_cntr.txt antes de la desactivación de VNF. Más tarde, cuando se active con el nuevo software, inicie sesión en CF y actualice el archivo /flash/restart_file_cntr.txt con el contador de reinicio antiguo. A continuación, como procedimiento de actualización normal, vuelva a cargar el VNF con la configuración de día N.

2. Modificar el gato /flash/restart_file_cntr.txt al valor necesario y vuelva a cargar el nodo con la configuración actual.

Nota: Puede probar con el reinicio de SGTPC, así como una vez como paso inicial.