Solución de problemas de GTPC y GTPU de la serie ASR 5000 y fallas de ruta asociadas

Opciones de descarga

ePub (112.0 KB)
Visualice en diferentes aplicaciones en iPhone, iPad, Android, Sony Reader o Windows Phone
Mobi (Kindle) (283.3 KB)
Visualice en dispositivo Kindle o aplicación Kindle en múltiples dispositivos

Actualizado:23 de julio de 2015

ID del documento:200026

Lenguaje no discriminatorio

El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.

Acerca de esta traducción

Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).

Contenido

Introducción

Background

Comandos relevantes

Detección de falla de trayecto

Diversos ejemplos de trampas y explicaciones de falla de trayecto

Conversaciones relacionadas de la comunidad de soporte de Cisco

Introducción

Este artículo trata sobre la comprensión y resolución de problemas del protocolo general evolucionado de tunelización de servicios de radio de paquetes para el plano de control (EGTPC) / GTPC (Especificación técnica del proyecto de asociación de tercera generación 29.274), el plano de usuario del protocolo de tunelación GPRS (GTPv1-U) (3GPP TS 29.2811) y lo más importante para esto artículo, Procedimientos de Restauración (3GPP TS 23.007) , que gira en torno a conceptos tales como contadores de reinicio, detección de fallas de trayectoria y solicitudes/respuestas de eco. Incluye una lista de comandos relevantes y qué buscar en el resultado, junto con una explicación de los configurables relacionados. Ciertamente, se trata de un ámbito en el que se plantean muchas preguntas. Tenga en cuenta que la resolución de problemas específicos de control de llamadas es en sí misma un área de interés muy extensa, pero este artículo sólo menciona cómo capturar estadísticas para el control de llamadas; cualquier cosa más allá de eso (es decir, problemas de configuración de llamadas) no está cubierta. En realidad este artículo se centra principalmente en la resolución de problemas y verificación de las conexiones de peer, sin las cuales no habría control de llamadas. Aunque está escrito para operadores, los diseñadores/implementadores también podrían beneficiarse del contenido aquí.

Por ejemplo, todos utilizan direcciones IP falsas (cambiadas) de la red de un operador real.

Background

Cada lado de una conexión GTP (uno de S5 (Serving Gateway (SGW) - Packet Data Network Gateway (PGW)), S11 ( Multimedia Management Entity (MME) - SGW), S4 ( Serving GPRS Service Node (SGSN) - GPRS Service Node (GGPRS) SN)) mantiene un contador de reinicio que está diseñado para alertar al par si el nodo de origen se ha reiniciado para que ese par pueda tomar la acción apropiada. Mientras que un nodo puede utilizar un contador único para cada par con el que habla, el diseño tiende a ser utilizar el contador MISMO para todos los peers, ya que cuando se reinicia el nodo, el contador debe incrementarse para todos los peers, por lo que el seguimiento de un valor independiente sobre la base de peer no ofrece ninguna ventaja adicional, ya que todos necesitan aumentar en uno de todos modos. De hecho, el uso del mismo contador de reinicio para todos los peers es útil para solucionar problemas de una red grande donde todos los peers pueden ser verificados para asegurarse de que los contadores de reinicio recibidos tengan el mismo valor (único) para el nodo con el que están hablando esos peers.

El contador de reinicio PUEDE incluirse en todos los tipos de mensajes de control, mientras que el contador de reinicio DEBE incluirse en todas las solicitudes y respuestas de eco. Tan pronto como se produce un cambio de contador de reinicio en un nodo, se informa a los diversos pares sobre él a través de los siguientes mensajes de control enviados a los pares respectivos. Cuando se produce un reinicio, por especificación, el lado receptor tiene la opción de mantener temporalmente las llamadas que tiene durante un breve tiempo o de descartarlas, esta última, que es normalmente la que se configura.

En el caso de utilizar solicitudes de eco, el método es enviar los mensajes en un intervalo configurado y, si no se recibe ninguna respuesta después de un número configurado de reintentos (cada uno después de un tiempo de espera configurado), se considera que la trayectoria está inactiva y se realiza la acción apropiada. La configuración permite el envío opcional de ecos, y esto también se aplicaría al par, cuyo enfoque no necesariamente tiene que ser el mismo, especialmente cuando el par podría ser de un proveedor diferente y/o portador diferente. De hecho con respecto a las respuestas de eco, un nodo sólo está obligado a responder a una solicitud de eco -ya sea que recibe ecos o no y con qué frecuencia no es significativa- solamente necesita enviar una respuesta de eco para cada solicitud, y tomar acción si el contador de reinicio recibe cambios. Por supuesto, como ya se ha mencionado, SI también está enviando solicitudes de eco y no recibe respuestas oportunas, también debe tomar medidas para ese escenario.

Tenga en cuenta que la detección de fallas de trayectoria también se puede realizar a través de la conexión GTP-U (plano de usuario) a través de Echo, pero SOLAMENTE a través del tiempo de espera, ya que no se incluye un contador de reinicio en los mensajes GTP-U como existe para GTP-C como se ha discutido anteriormente. GTP-U puede o no estar utilizando la misma trayectoria que los mensajes de control. Si es la misma ruta, la detección de GTP-U puede no ser tan valiosa, ya que la detección de GTP-C debe ser suficiente.

En resumen, estas son las maneras en que se puede realizar la detección de fallas de trayecto:

Reiniciar cambio de contador (mediante el control msg Req/Rsp o Echo)
Tiempo de espera de solicitud de eco GTPC
Tiempo de espera de solicitud de eco GTPU
Tiempo de espera del mensaje de solicitud de control (normalmente no configurado)

Comandos relevantes

Para resolver cualquier tipo de problema de trayectoria, familiarice con los siguientes comandos. A continuación figura una explicación de los detalles pertinentes de cada uno.

show [egtpc-service | gtpu-service] all
show egtpc peers [egtp-service <service>]
egtpc test echo gtp-version {1 | 2} src-address <service address> peer-address <peer address>
show egtpc statistics [[ (sgw-address) | pgw-address | mme-address) <address>] [demux-only]] [debug-only] [verbose] | path-failure-reason]
show gtpu statistics [peer-address <peer>]
show gtpc statistics [ggsn-service <service>] [smgr-instance <instance>]
show demux-mgr statistics <egtpinmgr | egtpegmgr | gtpumgr> all (SGW-egress | Entrada GGSN/PGW/SGW | GTPU
EGTPCPathFail[Clear], EGTPUPathFail[Clear] SNMP traps
show session disconnect-RAS - gtpc-path-failure, gtpu-path-failure, path-failure

Otros comandos para contar suscriptores relacionados con GTP:

show sub [summary] ggsn-service <service>

show sub [summary] gtpu-service <service>

show egtpc sessions [egtp-service <service>]

El comando básico para verificar el estado y la configuración de todos los servicios de EGTP es "show egtpc-service". La mayor parte del resultado debe ser lo que ya se conoce a través de la configuración, así como el estado debe ser INICIADO. La única información que se obtiene es el "Contador de reinicio", que no se puede encontrar en ningún otro lugar. El comando relacionado "show gtpu-service all" devuelve los valores configurables para los servicios GTPU que están asociados con los servicios EGTPC.

"show egtpc peers" es muy útil para identificar todos los peers, incluidos estados, contadores de reinicio y recuentos de suscriptores actual/máximo.

Tenga en cuenta que este comando abarca tanto a los pares SGW como SGSN, mientras que en el pasado había un comando separado para SGSN/GGSN.
Dado que este comando incluye todos los tipos de peer, el tipo de peer se puede filtrar a través del nombre de servicio (aunque la palabra clave egtpc-service también toma un nombre de servicio GGSN engañosamente).
Si no hay suscriptores con el par, el estado es Inactivo y GTPC Echo inhabilitado. En ese estado, para EGTPC PUEDE haber algunos pares para los que se informa del contador Restart, mientras que la mayoría puede ser 0. Esto ocurre en situaciones en las que el par está enviando activamente solicitudes de eco a las que ASR5K debería estar respondiendo. El contador de reinicio se puede determinar ejecutando el comando de prueba EGTPC (que se analiza a continuación), aunque en el estado inactivo, el contador no se actualizará en "show egtpc peers" aunque se haya recibido. Mientras tanto para GGSN, el contador de reinicio nunca se olvida.

[local]PGW-GGSN> show egtpc peers egtp-service GGSN1
|||||  Service                       Restart--+   No. of
|||||  ID                            Counter  |  restarts 
|||||   |                                     |     |     Current   Max
vvvvv   v              Peer Address           v     v     sessions sessions
-----  --- -------------------------------- --- --- ----------- -- ---------

IDNKG   6                   203.0.113.69    165     0           0           1
IDNKG   6                   203.0.113.70     25     0           0           1
IDNKG   6                   203.0.113.71    165     0           0           1
IDNKG   6                   203.0.113.72     25     0           0           1
IDNKG   6                   203.0.113.73     53     0           0           1
IDNKG   6                   203.0.113.74     53     0           0           1

IDNKG   6                   192.0.2.9        46     0           0           2
IDNKG   6                   192.0.2.10       44     0           0           1
IDNKG   6                   192.0.2.11       47     0           0           2
IDNKG   6                   192.0.2.12       44     0           0           2
IDNKG   6                   192.0.2.13       54     0           0           1
IDNKG   6                   192.0.2.14       47     0           0           1

IDNKG   6                   209.165.200.225  35     1           0           3
IDNKG   6                   209.165.200.226  35     3           0           3

IDNK   6                    198.51.100.204  156     0           0           1
IDNK   6                    198.51.100.205  158     0           0           1
IDNK   6                    198.51.100.211   54     0           0           1
IDNK   6                    198.51.100.212   54     0           0           1
IDNK   6                    198.51.100.213   56     0           0           1
IDNK   6                    198.51.100.214   56     0           0           1
IDNK   6                    198.51.100.215   54     0           0           1

Observe que a continuación hay un par de peers que tienen un número mucho mayor que los otros peers. Éstos son para SGW que se encuentran físicamente en el mismo sitio o en el sitio hermano de PGW al que MME canaliza la mayoría de las llamadas.

[local]PGW> show egtpc peers
Monday March 30 20:10:26 UTC 2015

+----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
|||||                        (U) - Unknown 
|||||  Service                       Restart--------+  No. of 
|||||  ID                            Counter        |  restarts
|||||   |                                           |   |   Current       Max
vvvvv   v              Peer Address                 v   v   sessions    sessions
-----  --- --------------------------------------- --- --- ----------- ----------
IDNUS   5                            198.51.100.4   0   0           0           1
IDNKS   5                           198.51.100.33  75   0           0           1
IDNUS   5                           198.51.100.35   0   0           0           2
IDNUS   5                           198.51.100.65   0   0           0           1
IDNUS   5                           198.51.100.67   0   0           0           2
IDNUS   5                           198.51.100.68   0   0           0           2
IDNUS   5                           198.51.100.98   0   0           0           2
IDNUS   5                          198.51.100.100   0   0           0           1
IDNUS   5                          198.51.100.129   0   0           0           2
IDNUS   5                          198.51.100.130   0   0           0           2
IDNUS   5                          198.51.100.161   0   0           0           2
IDNUS   5                          198.51.100.194   0   0           0           2
IDNUS   5                          198.51.100.196   0   0           0           1
IDNUS   5                          198.51.100.225   0   0           0           5
IDNUS   5                          198.51.100.226   0   0           0           2
IDNUS   5                          198.51.100.228   0   0           0           1
IDNUS   5                            198.51.100.3   0   0           0           2
IDNUS   5                           198.51.100.36   0   0           0           1
IDNUS   5                           198.51.100.64   0   0           0           4
IDNUS   5                           198.51.100.66   0   0           0           2
IDNUS   5                          198.51.100.130   0   0           0           2
IDNKS   5                           198.51.100.24   2   0           0           2
AESKS   5                           198.51.100.56   3   0           1           5
IDNKS   5                           198.51.100.99  18   0           0           2
AESKS   5                          198.51.100.100   7   0           1           3
IDNKS   5                          198.51.100.131  46   0           0           2
IDNKS   5                          198.51.100.132  18   0           0           2
IDNKS   5                          198.51.100.163  41   0           0           3
IDNKS   5                          198.51.100.164   6   0           0           2
AESKS   5                          198.51.100.184  11   0           1           2
IDNKS   5                          198.51.100.216   7   0           0           2
AESKS   5                            203.0.113.24   5   0           3           8
IDNKS   5                            203.0.113.56   3   1           0          13
IDNKS   5                            203.0.113.88   2   0           0          18
IDNKS   5                           203.0.113.120   6   0           0           3
IDNKS   5                           203.0.113.152   3   0           0           4
AESKS   5                           203.0.113.184   2   0           1           9
IDNKS   5                           203.0.113.216   4   0           0           2
IDNKS   5                           203.0.113.248  10   0           0           1
IDNUS   5                             203.0.113.4   0   0           0           2
IDNUS   5                            203.0.113.33   0   0           0           4
IDNUS   5                            203.0.113.65   0   0           0           2
IDNKS   5                           203.0.113.121   5   0           0           3
IDNKS   5                           203.0.113.153   6   0           0           5
IDNUS   5                           203.0.113.162   0   0           0           3
IDNUS   5                            203.0.113.32   0   0           0           5
AESKS   5                            203.0.113.35   5   1           6          37
IDNUS   5                            203.0.113.64   0   0           0           1
IDNUS   5                            203.0.113.66   0   0           0           4
IDNUS   5                            203.0.113.97   0   0           0           1
AESKS   5                            203.0.113.98   4   0           1           4
IDNUS   5                           203.0.113.161   0   0           0           4
IDNUS   5                           203.0.113.193   0   0           0          10
IDNUS   5                           203.0.113.228   0   0           0          12
IDNUS   5                           203.0.113.233   0   0           0           4
AESKS   5                               192.0.2.4   9   0           3          10
AESKS   5                              192.0.2.24   6   0          10          19
AESKS   5                              192.0.2.32   8   0          83         116
AESKS   5                              192.0.2.33  55   0          14          21
AESKS   5                              192.0.2.65  18   0           1        2747
AESKS   5                              192.0.2.66   4   0           3        1639
AESKS   5                              192.0.2.97  44  39          33        1826
AESKS   5                              192.0.2.98   5   1           6        2075
IDNKS   5                             192.0.2.195   8   0           0           7
AESKS   5                               192.0.2.3  46   0        3230        5346
AESKS   5                               192.0.2.5  12   0          84         202
AESKS   5                               192.0.2.7   2   0          31         443
AESKS   5                              192.0.2.24   3   0         116         117
AESKS   5                              192.0.2.36  15   0        4194        6889
AESKS   5                              192.0.2.44   7   0         112         331
AESKS   5                              192.0.2.68  34   0        6104        9798
AESKS   5                              192.0.2.69   7   0        2259        5027
AESKS   5                              192.0.2.88  17   0        3899        8880
AESKS   5                             192.0.2.164  16   0      833131     1298070
AESKS   5                             192.0.2.184   3   0     1437053     2153317
AESKS   5                             192.0.2.193  21   0       11364       26577
AESKS   5                             192.0.2.195   5   0          50         162
AESKS   5                             192.0.2.226  21   0        1950        3931
AESKS   5                             192.0.2.227   6   0        4348        9332

Tenga en cuenta que la ejecución de este comando en un nodo en espera de redundancia de servicio entre chasis (ICSR) sólo es relevante para los pares activos, en cuyo caso los números deben cerrarse, por ejemplo en el par siguiente:

PGW> show egtpc peers ... 20:51:52 (ACTIVO)						PGW-ICSR> show egtpc peers ... 20:51:51 (EN ESPERA)
	Entidad par	RC	Nº de sesiones	Max Sess	Entidad par	RC	Nº de sesiones	Max Sess
AESKS	192.0.2.5	2	31	443	ADSKS	192.0.2.5	2	31	443
AESKS	192.0.2.24	3	117	123	ADNKS	192.0.2.24	3	117	123
AESKS	192.0.2.36	15	4223	6889	ADSKS	192.0.2.36	15	4223	6889
AESKS	192.0.2.44	7	119	331	ADSKS	192.0.2.44	7	119	331
AESKS	192.0.2.68	34	6174	9798	ADSKS	192.0.2.68	34	6171	9797
AESKS	192.0.2.69	7	2311	5027	ADSKS	192.0.2.69	7	2311	5027
AESKS	192.0.2.88	17	3914	8880	ADSKS	192.0.2.88	17	3913	8874
AESKS	192.0.2.164	16	833705	1298070	ADSKS	192.0.2.164	16	832037	1294412
AESKS	192.0.2.184	3	1438418	2153317	ADSKS	192.0.2.184	3	1435461	2147280
AESKS	192.0.2.193	21	11447	26577	ADSKS	192.0.2.193	21	11443	26568
AESKS	192.0.2.195	5	48	162	ADSKS	192.0.2.195	5	48	162
AESKS	192.0.2.226	21	1962	3931	ADSKS	192.0.2.226	21	1962	3931
AESKS	192.0.2.227	6	4465	9332	ADSKS	192.0.2.227	6	4466	9332

"egtpc test echo" se utiliza para verificar un peer específico para ver si es alcanzable o no y debe ejecutarse en el contexto donde se define el servicio.

Utilice gtp-version 1 para conexiones GSN-SGSN
El uso del comando ping no es una prueba válida, aunque si es exitosa, se sabe que hay cierto nivel de alcance.
Se muestra el contador de reinicio del par (Recuperación).
Al ejecutar este comando, se incrementarán los contadores de solicitud de eco Tx / respuesta de eco Rx en "show egtpc statistics"
El contador de reinicio del par se informa después de la palabra clave Recovery (11 en el ejemplo siguiente)
Advertencia: aunque esto no debería ocurrir en circunstancias normales, si se realiza un eco de prueba en un par y se agota el tiempo por cualquier razón (si todo funciona entonces no debería agotarse el tiempo), todas las llamadas se descartarían (aunque las cosas funcionaban bien hasta el punto de hacer la prueba).

[Ingress]PGW> egtpc test echo gtp-version 2 src-address  209.165.201.1 peer-address 198.51.100.35 
Monday November 03 15:08:12 UTC 2014
EGTPC test echo
---------------
Peer: 198.51.100.35   Tx/Rx:  1/1  RTT(ms): 1    (COMPLETE) Recovery: 11 (0x0B)

"show egtpc statistics" es para EGTPC (v2) e informa sobre el éxito o los fallos de muchos mensajes de control de EGTPC (solicitud/respuesta, Tx/Rx), incluidos Crear sesión, Modificar portador, Eliminar sesión, Notificar datos de enlace descendente, Portador de acceso de lanzamiento, Crear portador de actualizaciones, Modificar portador, Suspender, etc., y las respuestas asociadas. Incluye todos los contadores de administración de trayectoria para Echo Request/Response Tx/Rx, y en función de los temporizadores, se puede predecir el crecimiento de estos temporizadores y utilizarlos para resolver problemas si no se incrementan según lo esperado.

El siguiente ejemplo muestra ecos y respuestas iniciadas y respondidas desde ambos lados. Tenga en cuenta que el SGW se ha configurado para enviar una vez por minuto mientras que el PGW se ha configurado una vez cada tres minutos (ambos lados no necesitan tener la misma configuración) y por lo tanto cada tres minutos hay el doble de paquetes (6:16:33, 6:19:33). Tenga en cuenta que aunque ambas partes están en el mismo "ciclo" en este ejemplo, no tienen que ser y pueden funcionar independientemente unas de otras. Los contadores de reinicio también se han capturado en una columna. Observe que el contador Restart de 11 de la respuesta de eco de SGW coincide con el valor de su respuesta al eco de prueba de PGW de arriba (la prueba se realizó en un momento diferente al de la captura de paquetes pero para el mismo par de pares).

La opción demux-only captura todos los contadores de administración de la trayectoria (solicitudes/respuestas de eco) así como los mensajes de control que nunca alcanzan un sessmgr, que generalmente es Create Session Request/Response. Demux process etpinmgr que reside en la tarjeta Demux es responsable de manejar todas las solicitudes/respuestas de eco y el manejo inicial de todos los mensajes de control de llamadas antes de distribuirlos a los sessmgrs apropiados (aleatoriamente para las llamadas nuevas y específicamente para las llamadas existentes ancladas en un sessmgr específico). La opción sessmgr-only sólo cuenta a la inversa los mensajes que son manejados por sessmgrs, que NO incluye los contadores de administración de la trayectoria. No especificar ninguno de los calificadores es el valor predeterminado para contar todos los valores.

"show gtpc statistics" es el comando análogo para los servicios SGSN/GGSN (GTPC v1) (CPC, Update PDP Context, etc.)

"show gtpu statistics" informa estadísticas sobre el tráfico del plano de usuario manejado por los servicios GTP-U que están asociados con los servicios EGTPC. Un contador interesante es la indicación de error Tx/Rx que se enviaría cuando el nodo receptor no tiene registro del suscriptor que debería estar asociado con el Identificador de terminal (TEID) del paquete en cuestión que podría ocurrir por varias razones (el esquema/variable de bulkstats es GTPU1/ err-ind-tx). Si no se ha informado al MME/SGW de que el PGW ya no tiene un enlace al suscriptor, es posible que las llamadas deban eliminarse manualmente en el MME/SGW (o esperarse a que se agote el tiempo de espera) para resolver por completo tal problema de llamadas huérfanas.

Las versiones específicas de peer de los comandos stat anteriores son necesarias cuando se solucionan problemas de peers específicos, lo que a menudo sucede.

Detección de falla de trayecto

La trampa EGTPCPathFail es la clave para saber cuándo se ha producido una falla de trayectoria. Entre algunos valores básicos que uno ya asumiría, informa el número de llamadas perdidas, los contadores de reinicio antiguos y nuevos y el motivo del error. Además, la razón de desconexión de la sesión se incrementará gtpc-path-failure.

La trampa EGTPCPathFailClear indicará el contador de reinicio junto con el motivo de la eliminación de la trayectoria. La versión más reciente de StarOS v17 está mejor redactada para decir "razón clara" en lugar de "razón de fracaso" (se despejó, ¡no falló!) para evitar la confusión.

A continuación se muestran los recuentos de fallas de trayectoria que se informan desde "show egtpc stat path-failure-reason"

[local]PGW> show egtpc statistics path-failure-reasons
Reasons for path failure at EGTPC:
 Echo Request  restart counter change:                3  
 Echo Response restart counter change:                0   echo-rsp-restart-counter-change
 No Echo Response received:                           0   no-response-from-peer
 Control message restart counter change at   demux:  23   Create Session Req Restart Counter changed or create-sess-restart-counter-change
 Control message restart counter change at sessmgr:   0   cpc-restart-counter-change or upc-restart-counter-change
 Total path failures detected:                       26

Notas:

El contador de reinicio de mensajes de control en sessmgr puede ser cualquier tipo de mensaje de control (no todos se enumeran aquí)
Se ha cambiado el contador de reinicio desde el SGSN a través de la siguiente solicitud de contexto Create PDP tras ese cambio (cpc-restart-counter-change)

Se ha cambiado el contador de reinicio desde el SGSN a través de la siguiente solicitud de contexto PDP de actualización después de ese cambio (que sería una transferencia desde otro SGSN) (upc-restart-counter-change)

Path clear failure reason sessions-add es un término engañoso: no es un error sino un éxito, e indica que se ha iniciado una nueva sesión para establecer la conexión

Si los valores notificados para los contadores de reinicio y los recuentos de sesiones para las trampas PathFail y PathClear no parecen estar alineados, abra un ticket con Cisco para obtener más información.

Es importante comprender cómo se implementa la detección de fallas de ruta de EGTPC/GTPC y, en menor grado, de EGTPU/GTPU (ya que la detección de fallas de plano de usuario no siempre está configurada) para monitorear la conexión entre un GGSN o PGW y los diversos SGSN y SGW de peer. Normalmente, las conexiones dentro de una red de proveedores de servicios son bastante estables, en cuyo caso las fallas de trayectoria son infrecuentes. Por otra parte, la experiencia ha demostrado que las rutas GTPC entre los SGSN de roaming que se conectan a GGSN pueden no ser tan estables, por lo que con conexiones deficientes el resultado es que las fallas de trayectoria ocurren con bastante frecuencia.

La siguiente configuración cubre los temporizadores y la frecuencia de transmisión para los mensajes de control y eco que se pueden utilizar para detectar fallas de trayectoria. El mismo concepto se aplica a los servicios GGSN, SGW, MME y EGTP:

    ggsn-service GGSN1

retransmisión-tiempo de espera 20

Para mensajes de control GTP (frente a los mensajes de eco)

max-retransmission 5

tanto para el control GTP como para los mensajes de eco: cuántas veces se debe retransmitir antes del disparador de detección de fallas de trayecto

eco-interval 120

Se envía un eco cada 2 minutos (120 segundos).

echo-retransmit-timeout 5

Para Echos, si no hay respuesta, retransmite cada 5 segundos

path-failure detection-policy gtp echo

La detección de fallas de trayecto es posible a través del eco gtp (frente a no usar esto como un método para detectar fallas de trayectoria (pero aún enviando ecos)).

asociar gtpu-service GGSN1_gtpu

Asocia el servicio GGSN1_gtpu de GTPU con este servicio GGSN

bind ipv4-address 209.165.201.2

Las direcciones IP de enlace del plano de control y del usuario son las mismas en las siguientes configuraciones de ejemplo, pero no se pueden configurar necesariamente como tales con otras implementaciones del proveedor de servicios.

[local]GGSN> show ggsn-service name GGSN1 Service name: GGSN1 Context: XGWin Bind: Done Local IPv4 Address: 209.165.201.2 Local IP Port: 2123 Retransmission Timeout: 20 (secs) Max Retransmissions: 5 Restart Counter: 41 Echo Interval: 120 (secs) GTPC Echo Mode : Default GTPC Echo Retransmission Timeout : 5 Guard Interval: 100 (secs) Path Failure Detection on gtp msgs: Echo

Notas:

Dado que el tiempo 0 es cuando se inicia un ciclo de solicitud de eco (cada 2 minutos), si no hay respuestas después de un TOTAL de 30 segundos (6 intentos), la trayectoria falla (0 + 5sec + (5 * 5seg))

El proceso egtpinmgr (gtpcmgr desaprobado desde v14) que se ejecuta en la tarjeta demux es responsable del procesamiento de los paquetes de eco

"show gtp statistics", sección "Path Management Messages" tiene estadísticas para las solicitudes/respuestas de eco para la trayectoria de control en AMBAS direcciones:

[Ingress]GGSN> show gtpc statistics Monday October 27 23:02:07 UTC 2014 Path Management Messages: Echo Request RX: 169951248 Echo Response TX: 169951248 Echo Request TX: 40838432 Echo Response RX: 40784820

Otro método de detección de ruta se encuentra en el plano de usuario en lugar del plano de control, y se rige por la siguiente configuración.

gtpu-service GGSN1_gtpu no echo-interval max-retransmissions 4 echo-retransmission-timeout 5 path-failure detection-policy gtp echo no path-failure clear-trap gtp echo bind ipv4-address 209.165.201.2 exit

Notas:

"no echo-interval" inhabilita el envío de solicitudes de eco para el plano de usuario y, por lo tanto, el "path-failure detection-policy gtp echo" de CLI no tiene relevancia - NO Path Failure detection se realiza en GTPU

GGSN todavía responde a las solicitudes de eco de SGSN aunque

"show gtpu stat" y "show demux-mgr stat gtpumgr" captura estadísticas de eco

[local]PGW-GGSN> show gtpu statistics Wednesday October 29 23:43:22 UTC 2014 Path Management Messages: Echo Request Rx: 84690303 Echo Response Rx: 0 Echo Request Tx: 0 Echo Response Tx: 84690043 [local]PGW-GGSN> show demux-mgr statistics gtpumgr Wednesday October 29 23:42:04 UTC 2014 Echo stats: Echo Req Rcvd: 84690303 Echo Rsp Sent: 84690043

Diversos ejemplos de trampas y explicaciones de falla de trayecto

Por lo general, el contador de reinicio de peer aumentará en uno cuando hay un reinicio. En este caso, un error de funcionamiento en PGW hizo que invalidara el contador de reinicio al valor del RC de otro par (primera trampa), y así cuando el siguiente paquete llegó sobre la conexión, lo trató como un reinicio (segunda trampa) pensando que el RC había cambiado. A continuación, la ruta se borra en cualquier paquete sucesivo (tercera trampa). El punto aquí no es saber sobre un bug específico, sino más bien tratar de estar al tanto de cualquier cambio de contador que no se pueda explicar.

Wed Jan 14 05:22:07 2015 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.1, peer address 198.51.100.1, peer old restart counter 54, peer new restart counter 12, peer session count 1107240, failure reason restart-counter-change
Wed Jan 14 05:22:07 2015 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.1, peer address 198.51.100.1, peer old restart counter 12, peer new restart counter 54, peer session count 1107207, failure reason create-sess-restart-counter-change
Wed Jan 14 05:22:07 2015 Internal trap notification 1113 (EGTPCPathFailClear) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.1, peer address 198.51.100.1, peer restart counter 54, peer session count 1107199, failure reason sessions-add

Este ejemplo proviene de un GGSN donde el peer SGSN ha cambiado su RC de 66 a 67 a través de una solicitud de contexto Create PDP:

Mon Oct 27 11:48:54 2014 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service GGSN1, interface type ggsn, self address 209.165.201.2, peer address 209.165.200.225, peer old restart counter 66, peer new restart counter 67, peer session count 0, failure reason cpc-restart-counter-change Mon Oct 27 11:48:54 2014 Internal trap notification 1113 (EGTPCPathFailClear) context XGWin, service GGSN1, interface type ggsn, self address 209.165.201.2, peer address 209.165.200.225, peer restart counter 67, peer session count 1, failure reason sessions-add

Este ejemplo proviene de un PGW donde el par ePDG ha cambiado su RC de 69 a 70 a través de una solicitud de creación de sesión:

Fri Jun 12 05:21:54 2015 Internal trap notification 1112 (EGTPCPathFail) context PGWin, service EGTP1, interface type pgw-ingress, self address 2001:5555:8000:fff0:132:200::, peer address 2001:5555:8000:ffe0:123:20f::, peer old restart counter 69, peer new restart counter 70, peer session count 0, failure reason create-sess-restart-counter-change Fri Jun 12 05:21:55 2015 Internal trap notification 1113 (EGTPCPathFailClear) context PGWin, service EGTP1, interface type pgw-ingress, self address 2001:5555:8000:fff0:132:200::, peer address 2001:5555:8000:ffe0:123:20f::, peer restart counter 70, peer session count 1, clear reason sessions-add

En este ejemplo, la salida de varios nodos PGW todos conectados al mismo SGW muestra que el SGW dejó de ser accesible desde los PGW por una trampa EGTPCPathFail en los diversos PGW dentro de un breve período de tiempo entre sí. Tenga en cuenta que todos muestran el mismo contador de reinicio antiguo que se mencionó anteriormente que normalmente un nodo utiliza el mismo contador para todos sus pares. En el caso de no recibir respuesta, el nuevo contador de reinicio que se muestra es 9, pero el nuevo contador podría imprimirse mejor como no definido, ya que la conexión está inactiva desde el momento en que se activa la trampa y, por lo tanto, tener un contador de reinicio no tiene realmente sentido.

Mon Dec 22 09:07:29 2014 Internal trap notification 1112 (EGTPCPathFail) context PGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.4, peer address 198.51.100.162, peer old restart counter 9, peer new restart counter 9, peer session count 151, failure reason no-response-from-peer Mon Dec 22 09:08:54 2014 Internal trap notification 1112 (EGTPCPathFail) context PGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.5, peer address 198.51.100.162, peer old restart counter 9, peer new restart counter 9, peer session count 634, failure reason no-response-from-peer Mon Dec 22 09:09:00 2014 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.6, peer address 198.51.100.162, peer old restart counter 9, peer new restart counter 9, peer session count 22, failure reason no-response-from-peer Mon Dec 22 09:07:42 2014 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.7, peer address 198.51.100.162, peer old restart counter 9, peer new restart counter 9, peer session count 33, failure reason no-response-from-peer Mon Dec 22 09:08:06 2014 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.8, peer address 198.51.100.162, peer old restart counter 9, peer new restart counter 9, peer session count 1, failure reason no-response-from-peer Mon Dec 22 09:07:34 2014 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.9, peer address 198.51.100.162, peer old restart counter 9, peer new restart counter 9, peer session count 725, failure reason no-response-from-peer Mon Dec 22 09:08:20 2014 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.10, peer address 198.51.100.162, peer old restart counter 9, peer new restart counter 9, peer session count 279978, failure reason no-response-from-peer Mon Dec 22 09:06:37 2014 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.11, peer address 198.51.100.162, peer old restart counter 9, peer new restart counter 9, peer session count 23, failure reason no-response-from-peer Mon Dec 22 09:07:29 2014 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.12, peer address 198.51.100.162, peer old restart counter 9, peer new restart counter 9, peer session count 6, failure reason no-response-from-peer Mon Dec 22 09:07:01 2014 Internal trap notification 1112 (EGTPCPathFail) context PGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.13, peer address 198.51.100.162, peer old restart counter 9, peer new restart counter 9, peer session count 5, failure reason no-response-from-peer

El siguiente ejemplo muestra una falla de trayectoria y el mismo contador de reinicio nuevo que en el ejemplo anterior, pero luego media hora después se muestra cuando el par vuelve a activarse y el contador ha aumentado uno de 15 a 16. Con el tiempo, el recuento aumenta para ese par:

Wed Jul 22 05:07:08 2015 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.13, peer address 198.51.100.162, peer old restart counter 15, peer new restart counter 15, peer session count 34, failure reason no-response-from-peer
Wed Jul 22 05:38:00 2015 Internal trap notification 1113 (EGTPCPathFailClear) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.13, peer address 198.51.100.162, peer restart counter 16, peer session count 1, clear reason sessions-update

[local]PGW> show egtpc peers
Wednesday July 22 10:04:30 UTC 2015

||||| Service           Restart--------+ No. of
||||| ID                Counter        | restarts
|||||   |                               |   |   Current       Max
vvvvv   v              Peer Address     v   v   sessions    sessions
----- --- --------------------------------------- --- --- -----------
AESKS   5               198.51.100.162 16   1        1157        2186

[XGWin]PGW> egtpc test echo gtp-version 2 src-address 209.165.201.13 peer-address 198.51.100.162
Wednesday July 22 10:52:41 UTC 2015
EGTPC test echo
---------------
Peer: 198.51.100.162                          Tx/Rx: 1/1 RTT(ms): 51   (COMPLETE) Recovery: 16 (0x10)

Este ejemplo muestra una falla de trayectoria repetida debido al reinicio de CPC para 3 pares SGSN específicos al GGSN. El resultado a continuación muestra sólo uno de los pares 209.165.200.225, pero todos tienen el mismo problema. La ejecución repetida de "show egtpc peers" y "show gtpc stat sgsn-address" también muestra los valores alternos. "show gtpc stat" no confirma ningún problema con la conectividad con respecto a las solicitudes y respuestas de eco, que en este caso solamente están siendo iniciadas por el GGSN (aceptable como se discutió anteriormente). Un punto de la barra lateral que se debe hacer aquí es el de que con frecuencia se pueden recopilar múltiples datos que corroboran la misma conclusión: se puede optar por recopilar los datos más concluyentes con el mínimo esfuerzo.

show snmp trap history verbose | grep -E "209.165.201.31|209.165.200.225|209.165.200.246"

Mon Jun 22 22:20:51 2015 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service GGSN1, interface type ggsn, self address 209.165.202.129, peer address 209.165.200.225, peer old restart counter 129, peer new restart counter 132, peer session count 3, failure reason cpc-restart-counter-change
Mon Jun 22 22:20:51 2015 Internal trap notification 1113 (EGTPCPathFailClear) context XGWin, service GGSN1, interface type ggsn, self address 209.165.202.129, peer address 209.165.200.225, peer restart counter 132,   peer session count 4, clear reason sessions-add
Mon Jun 22 22:20:55 2015 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service GGSN1, interface type ggsn, self address 209.165.202.129, peer address 209.165.200.225, peer old restart counter 132, peer new restart counter 129, peer session count 3, failure reason cpc-restart-counter-change
Mon Jun 22 22:20:55 2015 Internal trap notification 1113 (EGTPCPathFailClear) context XGWin, service GGSN1, interface type ggsn, self address 209.165.202.129, peer address 209.165.200.225, peer restart counter 129,   peer session count 4, clear reason sessions-add
Mon Jun 22 22:20:58 2015 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service GGSN1, interface type ggsn, self address 209.165.202.129, peer address 209.165.200.225, peer old restart counter 129, peer new restart counter 132, peer session count 3, failure reason cpc-restart-counter-change
Mon Jun 22 22:20:58 2015 Internal trap notification 1113 (EGTPCPathFailClear) context XGWin, service GGSN1, interface type ggsn, self address 209.165.202.129, peer address 209.165.200.225, peer restart counter 132,   peer session count 4, clear reason sessions-add
Mon Jun 22 22:21:02 2015 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service GGSN1, interface type ggsn, self address 209.165.202.129, peer address 209.165.200.225, peer old restart counter 132, peer new restart counter 129, peer session count 2, failure reason cpc-restart-counter-change
Mon Jun 22 22:21:02 2015 Internal trap notification 1113 (EGTPCPathFailClear) context XGWin, service GGSN1, interface type ggsn, self address 209.165.202.129, peer address 209.165.200.225, peer restart counter 129,   peer session count 3, clear reason sessions-add
Mon Jun 22 22:21:03 2015 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service GGSN1, interface type ggsn, self address 209.165.202.129, peer address 209.165.200.225, peer old restart counter 129, peer new restart counter 132, peer session count 4, failure reason echo-rsp-restart-counter-change
Mon Jun 22 22:21:03 2015 Internal trap notification 1113 (EGTPCPathFailClear) context XGWin, service GGSN1, interface type ggsn, self address 209.165.202.129, peer address 209.165.200.225, peer restart counter 132,   peer session count 5, clear reason sessions-add
Mon Jun 22 22:21:06 2015 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service GGSN1, interface type ggsn, self address 209.165.202.129, peer address 209.165.200.225, peer old restart counter 132, peer new restart counter 129, peer session count 2, failure reason cpc-restart-counter-change
Mon Jun 22 22:21:06 2015 Internal trap notification 1113 (EGTPCPathFailClear) context XGWin, service GGSN1, interface type ggsn, self address 209.165.202.129, peer address 209.165.200.225, peer restart counter 129,   peer session count 3, clear reason sessions-add

[XGWin]GGSN> show egtpc peers | grep 209.165.200.225
||||| Service                      Restart No. of
||||| ID                           Counter restarts
|||||   |                             |     |       Current Max
vvvvv   v              Peer Address   |     |       sessions    sessions
| | |
v v v
Monday June 22 23:09:26 UTC 2015
AESKG   6             209.165.200.225 129 86339           2          57

[XGWin]GGSN> show egtpc peers | grep 209.165.200.225
Monday June 22 23:09:28 UTC 2015
AESKG   6             209.165.200.225 129 86341           3          57

[XGWin]GGSN> show egtpc peers | grep 209.165.200.225
Monday June 22 23:09:29 UTC 2015
AESKG   6             209.165.200.225 132 86342           7          57

[XGWin]GGSN> show egtpc peers | grep 209.165.200.225
Monday June 22 23:09:30 UTC 2015
AESKG   6             209.165.200.225 132 86344           9          57

[XGWin]GGSN> show egtpc peers | grep 209.165.200.225
Monday June 22 23:09:31 UTC 2015
AESKG   6             209.165.200.225 129 86345          11          57

[XGWin]GGSN> show egtpc peers | grep 209.165.200.225
Monday June 22 23:09:32 UTC 2015
AESKG   6             209.165.200.225 129 86345           7          57

[XGWin]GGSN> show gtpc statistics sgsn-address 209.165.200.225
Monday June 22 23:07:36 UTC 2015
SGSN Address:    209.165.200.225    Status:          Active
Total Restarts: 86287             Restart Counter: 129

Session Stats:
Total Current:                  2   S6b Assume Positive:             0
...

Path Management Messages:
Echo Request RX:                0   Echo Response TX:                0
Echo Request TX:            22919   Echo Response RX:            22917

Si miramos a otros peers en la subred, todos muestran un RC = 132 todo el tiempo, mientras que los peers rotos alternan entre 129 y 132 como se muestra, lo que señala a estos peers SGSN como potencialmente pasando el RC incorrecto en los escenarios rotos:

Restart
Counter
AESKG 6 209.165.200.225 129 85115 8 57 <== IDNKG 6 209.165.200.226 132 21 0 3 AESKG 6 209.165.200.227 132 60 47 92 AESKG 6 209.165.200.228 132 53 24 59 AESKG 6 209.165.200.229 132 69 92 126 AESKG 6 209.165.200.232 132 66 21 30 AESKG 6 209.165.200.236 132 43 8 21 AESKG 6 209.165.200.238 132 49 18 32 AESKG 6 209.165.200.239 132 39 1 6 AENKG 6 209.165.200.240 132 17 1 5 AESKG 6 209.165.200.241 132 67 6 43 AESKG 6 209.165.200.242 132 56 22 29 AENKG 6 209.165.200.243 132 40 2 9 AENKG 6 209.165.200.246 129 17713 3 24 <== AESKG 6 209.165.200.247 132 64 29 45 AESKG 6 209.165.200.250 132 62 42 56

Recuerden desde antes, otro enfoque de temas como este es verificar otros GGSN (o PGWs para LTE) para ver si tienen el mismo problema con los peers SGSN aparentemente problemáticos, y en este caso también lo tienen. Para GGSN3, la primera ejecución del comando mostró valores 132 para ambos pares, pero otra ejecución mostró 129 para uno de los pares. Múltiples ejecuciones (no se muestran aquí para la brevedad) mostrarían todos los GGSN que rebotan entre los dos RC para esos pares a lo largo del tiempo:

[local]GGSN1> show egtpc peers | grep -E "209.165.200.246|209.165.200.225" Tuesday June 23 11:37:23 UTC 2015 AENKG 7 209.165.200.246 129 20147 1 29 AESKG 7 209.165.200.225 129 92853 2 51 [local]GGSN2> show egtpc peers | grep -E "209.165.200.246|209.165.200.225" Tuesday June 23 11:37:23 UTC 2015 AENKG 6 209.165.200.246 129 20450 4 17 AESKG 6 209.165.200.225 129 94021 3 54 [local]GGSN3> show egtpc peers | grep -E "209.165.200.246|209.165.200.225" Tuesday June 23 11:37:26 UTC 2015 AENKG 6 209.165.200.246 132 20211 1 39 AESKG 6 209.165.200.225 132 91996 3 59 [local]GGSN4> show egtpc peers | grep -E "209.165.200.246|209.165.200.225" Tuesday June 23 11:37:25 UTC 2015 AENKG 6 209.165.200.246 129 20309 1 24 AESKG 6 209.165.200.225 132 92694 9 57 [local]GGSN3> show egtpc peers | grep -E "209.165.200.246|209.165.200.225" Tuesday June 23 11:44:35 UTC 2015 AENKG 6 209.165.200.246 129 20242 3 39 AESKG 6 209.165.200.225 132 92224 1 59

Finalmente para confirmar el problema es el SGSN cambiando el RC, monitorear la opción de menú del suscriptor por el peer SGSN muestra los cambios de los RC. Cuando cambia, todas las llamadas se desconectarán con falla de trayectoria como razón de desconexión. Una captura de pantalla de una captura de paquetes también muestra esto:

[XGWin]GGSN> mon sub Monday June 22 23:34:22 UTC 2015 y) By SGSN IP Address IP Address: [209.165.200.225 ] INBOUND>>>>> 23:35:32:688 Eventid:47000(3) GTPC Rx PDU, from 209.165.200.225:2123 to 209.165.202.129:2123 (176) TEID: 0x00000000, Message type: GTP_CREATE_PDP_CONTEXT_REQ_MSG (0x10) Sequence Number:: 0x1DB8 (7608) ...
                       IMSI: 300420078559902 Recovery: 0x81 (129) ... ***CONTROL*** 23:36:00:363 Eventid:10285 Disconnect Reason: path-failure INBOUND>>>>> 23:36:48:414 Eventid:47000(3) GTPC Rx PDU, from 209.165.200.225:2123 to 209.165.202.129:2123 (176) TEID: 0x00000000, Message type: GTP_CREATE_PDP_CONTEXT_REQ_MSG (0x10) Sequence Number:: 0x3E2D (15917) ... IMSI: 300420125984926 Recovery: 0x84 (132) ... INBOUND>>>>> 23:37:28:337 Eventid:47000(3) GTPC Rx PDU, from 209.165.200.225:2123 to 209.165.202.129:2123 (176) TEID: 0x00000000, Message type: GTP_CREATE_PDP_CONTEXT_REQ_MSG (0x10) Sequence Number:: 0x3517 (13591) ... IMSI: 300420094205377 Recovery: 0x84 (132)
... Monday June 22 2015 INBOUND>>>>> 23:37:40:559 Eventid:47000(3) GTPC Rx PDU, from 209.165.200.225:2123 to 209.165.202.129:2123 (176) TEID: 0x00000000, Message type: GTP_CREATE_PDP_CONTEXT_REQ_MSG (0x10) Sequence Number:: 0x4E47 (20039) ... IMSI: 300420194755472 Recovery: 0x81 (129)
... ***CONTROL*** 23:37:40:755 Eventid:10285 Disconnect Reason: path-failure

Este ejemplo muestra una falla de trayectoria donde el problema estaba realmente en la trayectoria y no en el PGW o SGW. Como resultado, la RC sigue siendo la misma cuando se restablece la ruta. En el segundo ejemplo de peer, clear es el resultado del establecimiento de solicitud de eco:

Thu May 28 20:47:47 2015 Internal trap notification 1112 (EGTPCPathFail) context PGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.1, peer address 198.51.100.196, peer old restart counter 5, peer new restart counter 5, peer session count 549697, failure reason no-response-from-peer Thu May 28 20:49:36 2015 Internal trap notification 1113 (EGTPCPathFailClear) context PGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.1, peer address 198.51.100.196, peer restart counter 5, peer session count 1, clear reason sessions-add Thu May 28 20:49:06 2015 Internal trap notification 1112 (EGTPCPathFail) context PGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.1, peer address 203.0.113.98, peer old restart counter 4, peer new restart counter 4, peer session count 3, failure reason no-response-from-peer Thu May 28 20:50:49 2015 Internal trap notification 1113 (EGTPCPathFailClear) context PGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.1, peer address 203.0.113.98, peer restart counter 4, peer session count 0, clear reason echo-req

Este ejemplo muestra otra anomalía en la que una vez que el contador de reinicio antiguo se ha restablecido a 2, de alguna manera termina en 0 nuevamente cuando se borra la trayectoria. Esto resultó ser un error. Una vez más, la lección aquí es que si algo parece extraño, debería informarse.

Fri Mar 27 03:13:36 2015 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.1, peer address 192.0.2.5, peer old restart counter 0, peer new restart counter 2, peer session count 1, failure reason create-sess-restart-counter-change Fri Mar 27 03:13:37 2015 Internal trap notification 1113 (EGTPCPathFailClear) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.1, peer address 192.0.2.5, peer restart counter 0, peer session count 1, failure reason sessions-add Sat Mar 28 02:20:45 2015 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.1, peer address 192.0.2.5, peer old restart counter 0, peer new restart counter 2, peer session count 1, failure reason create-sess-restart-counter-change Sat Mar 28 02:20:47 2015 Internal trap notification 1113 (EGTPCPathFailClear) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.1, peer address 192.0.2.5, peer restart counter 0, peer session count 1, failure reason sessions-add Sat Mar 28 17:14:06 2015 Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.1, peer address 192.0.2.5, peer old restart counter 0, peer new restart counter 2, peer session count 1, failure reason create-sess-restart-counter-change Sat Mar 28 17:14:06 2015 Internal trap notification 1113 (EGTPCPathFailClear) context XGWin, service EGTP1, interface type pgw-ingress, self address 209.165.201.1, peer address 192.0.2.5, peer restart counter 0, peer session count 1, failure reason sessions-add

Con la colaboración de ingenieros de Cisco

Dave Damerjian
Servicios técnicos de Cisco

retransmisión-tiempo de espera 20	Para mensajes de control GTP (frente a los mensajes de eco)
max-retransmission 5	tanto para el control GTP como para los mensajes de eco: cuántas veces se debe retransmitir antes del disparador de detección de fallas de trayecto
eco-interval 120	Se envía un eco cada 2 minutos (120 segundos).
echo-retransmit-timeout 5	Para Echos, si no hay respuesta, retransmite cada 5 segundos
path-failure detection-policy gtp echo	La detección de fallas de trayecto es posible a través del eco gtp (frente a no usar esto como un método para detectar fallas de trayectoria (pero aún enviando ecos)).
asociar gtpu-service GGSN1_gtpu	Asocia el servicio GGSN1_gtpu de GTPU con este servicio GGSN
bind ipv4-address 209.165.201.2	Las direcciones IP de enlace del plano de control y del usuario son las mismas en las siguientes configuraciones de ejemplo, pero no se pueden configurar necesariamente como tales con otras implementaciones del proveedor de servicios.

Solución de problemas de GTPC y GTPU de la serie ASR 5000 y fallas de ruta asociadas

Opciones de descarga

Lenguaje no discriminatorio

Acerca de esta traducción

Contenido

Introducción

Background

Comandos relevantes

Detección de falla de trayecto

Diversos ejemplos de trampas y explicaciones de falla de trayecto

Con la colaboración de ingenieros de Cisco

¿Resultó útil este documento?

Contacte a Cisco

Este documento se aplica a estos productos