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 antes/flash/restart_file_cntr.txt 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. Modifique el cat /flash/restart_file_cntr.txt con el 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.