Solución de problemas de GTPC y GTPU de la serie ASR 5000 y fallos de ruta asociados
Contenido
Introducción
Este artículo trata sobre la comprensión y la resolución de problemas del protocolo de tunelación del servicio de radio de paquetes generales evolucionado para el plano de control (EGTPC) / GTPC (3rd Generation Partnership Project Technical Specification 29.274), el plano de usuario del protocolo de tunelación GPRS (GTPv1-U) (3GPP TS 29.281) y lo más relevante de este artículo, Procedimientos de restauración (3GPP TS 23.007), que giran en torno a conceptos como contadores de reinicio, fallos de ruta, detección y detección de fallos, 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. Este es sin duda un área para la 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 amplia, pero este artículo solo 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 la verificación de las conexiones de peer, sin las cuales no habría control de llamadas. Mientras que escrito para los operadores, diseñadores / implementadores también podrían beneficiarse del contenido aquí.
Todos los ejemplos utilizan direcciones IP falsas (modificadas) de la red de un operador real.
Background
Cada lado de una conexión GTP (uno de los lados S5 (Serving Gateway (SGW) - Packet Data Network Gateway (PGW)), S11 (Multimedia Management Entity (MME) - SGW), S4 (Serving GPRS Service Node (SGSN) - Gateway GPRS Service Node (GGSN)) mantiene un contador de reinicio diseñado para alertar al peer si el nodo de origen se ha reiniciado para que el peer 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 mismo contador para todos los pares, ya que cuando el nodo se reinicia, el contador necesita ser incrementado para todos los pares, y por lo tanto el seguimiento de un valor separado sobre una base par no sirve 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 pares es útil para resolver problemas de una red grande donde todos los pares se pueden verificar para asegurarse de que los contadores de reinicio recibidos tengan el mismo (único) valor para el nodo con el que esos pares están hablando.
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 en el contador de reinicio en un nodo, se informa a los diversos pares a través de los siguientes mensajes de control enviados a los pares respectivos. Cuando se produce un reinicio, según la especificación, el lado receptor tiene la opción de mantener temporalmente las llamadas que tiene por un tiempo corto o en descartarlas, este último que es típicamente lo que es el comportamiento configurado.
En el caso de usar solicitudes de eco, el método es enviar los mensajes en un intervalo configurado, y si no se recibe respuesta después de un número configurado de reintentos (cada uno después de un tiempo de espera configurado), la trayectoria se considera inactiva y se toma la acción apropiada. La configuración permite que se envíen ecos de manera opcional, y esto también se aplicaría al peer, cuyo enfoque no necesariamente tiene que ser el mismo, especialmente cuando el peer podría ser de un proveedor diferente y/o un operador diferente. De hecho, con respecto a las respuestas de eco, un nodo solo está obligado a responder a una solicitud de eco, tanto si recibe ecos como si no y con qué frecuencia no es significativa, solo necesita enviar una respuesta de eco para cada solicitud, y tomar medidas si el contador de reinicio recibió cambios. Por supuesto, como ya se mencionó, 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 hay contador de reinicio incluido en los mensajes GTP-U como lo hay para GTP-C como se mencionó anteriormente. GTP-U puede o no utilizar la misma ruta que la de los mensajes de control. Si es la misma trayectoria, entonces la detección GTP-U puede no ser tan valiosa ya que la detección GTP-C debería ser suficiente.
En resumen, estas son las maneras en que se puede realizar la detección de fallas de trayectoria:
- Reiniciar cambio de contador (a través del mensaje de control Req/Rsp o Echo)
- Req. tiempo de espera de eco GTPC
- GTPU Echo Req Time out
- Tiempo de espera del mensaje de solicitud de control (normalmente no está configurado)
Comandos relevantes
Para resolver cualquier tipo de problema de trayectoria, familiarícese con los siguientes comandos. A continuación se explican los detalles pertinentes de cada una de ellas.
- 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] Capturas SNMP
- show session disconnect-reason - 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 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 información única 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 configurables para los servicios GTPU asociados con los servicios EGTPC.
"show egtpc peers" es muy útil para identificar todos los peers, incluidos los estados, los contadores de reinicio y los recuentos de suscriptores actuales/máximos.
- Tenga en cuenta que este comando cubre los pares SGW y 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 engañosamente también toma un nombre de servicio GGSN).
- Si no hay suscriptores con el par, el estado es Inactivo y Eco GTPC inhabilitado. En ese estado, para EGTPC PUEDE haber algunos peers para los cuales se informa el contador de reinicio, 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 responder. El contador de reinicio se puede determinar ejecutando el comando de prueba EGTPC (discutido 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 un par de pares a continuación que tienen recuentos mucho más altos que los otros pares. Estos son para los SGW que están físicamente ubicados en el mismo sitio o el sitio hermano del PGW al que el 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) solo es relevante para los peers activos, en cuyo caso los números deben estar cerca, por ejemplo en el siguiente par:
| PGW> show egtpc peers ... 20:51:52 (ACTIVE) | PGW-ICSR> show egtpc peers ... 20:51:51 (STANDBY) | |||||||||
| 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 | |
"eco de prueba egtpc" se utiliza para verificar un peer específico para ver si es alcanzable o no y se debe ejecutar en el contexto donde se define el servicio.
- Utilice gtp-version 1 para conexiones GGSN-SGSN
- El uso del comando ping no es una prueba válida, aunque si es exitosa, se sabe que hay cierto nivel de disponibilidad.
- Se muestra el contador de reinicio del par (Recuperación).
- La ejecución de este comando incrementará 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 a continuación)
- Advertencia: aunque esto no debería ocurrir en circunstancias normales, si se realiza un eco de prueba en un peer y se agota el tiempo de espera por cualquier motivo (si todo está funcionando, entonces no debería agotarse el tiempo de espera), todas las llamadas se interrumpirían (aunque las cosas estaban funcionando 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/fracaso de muchos mensajes de control de EGTPC (Solicitud/Respuesta, Tx/Rx) incluyendo Crear Sesión, Modificar Portador, Eliminar Sesión, Notificar Datos de Enlace Descendente, Liberar Portador de Acceso, Crear Portador, Actualizar Portador, Modificar Portador, Suspender, etc., y las respuestas asociadas. Incluye todos los contadores de administración de rutas para Echo Request/Response Tx/Rx, y según los temporizadores, el crecimiento de estos temporizadores se puede predecir y usar para resolver problemas si no aumenta según lo esperado.
El siguiente ejemplo muestra ecos y respuestas que se están iniciando y respondiendo desde ambos lados. Observe que el SGW se ha configurado para enviar una vez por minuto mientras que el PGW se ha configurado para una vez cada tres minutos (ambos lados no necesitan tener el mismo ajuste) y por lo tanto cada tres minutos hay el doble de paquetes (6:16:33, 6:19:33). Tenga en cuenta que aunque ambos lados están en el mismo "ciclo" en este ejemplo, no tienen que estar y pueden funcionar independientemente el uno del otro. Los contadores de reinicio también se han capturado en una columna. Observe que el contador Restart de 11 de la respuesta de eco del SGW coincide con el valor de su respuesta al eco de prueba del PGW de arriba (la prueba se realizó en un momento diferente a la captura de paquetes pero para el mismo par de pares).
La opción demux-only captura todos los contadores de administración de trayectorias (solicitudes/respuestas de eco) así como los mensajes de control que nunca llegan a un sessmgr, que generalmente es Create Session Request/Response. El etpinmgr del proceso de Demux que reside en la tarjeta Demux es responsable de gestionar todas las solicitudes/respuestas de eco y la gestión inicial de todos los mensajes de control de llamadas antes de distribuirlos a los sessmgr adecuados (aleatoriamente para las llamadas nuevas y específicamente para las llamadas existentes ancladas en un sessmgr específico). La opción sessmgr-only por el contrario sólo cuenta los mensajes que son manejados por sessmgr, que NO incluye contadores de administración de 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, Actualizar contexto PDP, etc.)
"show gtpu statistics" informa de las estadísticas del tráfico del plano de usuario gestionado por los servicios GTP-U asociados con los servicios EGTPC. Un contador interesante es el Tx/Rx de indicación de error que se enviaría cuando el nodo receptor no tiene ningún registro del suscriptor que debería estar asociado con el identificador de terminal (TEID) del paquete en cuestión, lo que podría ocurrir por varias razones (el esquema/variable de bulkstats es GTPU1/ err-ind-tx). Si el MME/SGW no ha sido informado de que el PGW ya no tiene un enlace con el suscriptor, es posible que las llamadas deban ser borradas manualmente en el MME/SGW (o esperar a que se agote el tiempo de espera) para resolver completamente un problema de este tipo de llamadas huérfanas.
Las versiones específicas de peer de los comandos stat anteriores son necesarias para solucionar problemas de peers específicos, lo que suele suceder.
Detección de fallos de ruta
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 caídas, los contadores de reinicio antiguos y nuevos, y la razón de la falla. Además, se incrementará la razón de desconexión de la sesión gtpc-path-failure.
La trampa EGTPCPathFailClear indicará el contador de reinicio junto con el motivo de la limpieza 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 fallo" (¡aclaró, no falló!) para evitar confusiones.
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 los enumerados aquí)
- El contador de reinicio cambiado desde el SGSN a través de la siguiente solicitud de contexto de creación de PDP después de ese cambio (cpc-restart-counter-change)
- Contador de reinicio cambiado desde el SGSN a través de la siguiente solicitud de contexto de actualización PDP 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 fracaso sino un éxito, e indica que ha entrado 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 entender cómo se implementa la detección de fallas de trayectoria de EGTPC/GTPC y, en menor grado, de EGTPC/GTPC (ya que la detección de fallas en el plano del usuario no siempre está configurada) para monitorear la conexión entre un GGSN o PGW y los diversos SGSN y SGW pares. Normalmente, las conexiones dentro de una red de proveedores de servicios son bastante estables, en cuyo caso las fallas de trayectoria son infrecuentes. Por otro lado, la experiencia ha demostrado que las trayectorias GTPC entre los SGSN en roaming que se conectan a los GGSN pueden no ser tan estables, y por lo tanto 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
|
retransmission-timeout 20
|
Para mensajes de control GTP (frente a mensajes de eco)
|
|
max-retransmissions 5
|
para el control GTP y los mensajes de eco: cuántas veces se debe retransmitir antes de que se active la detección de falla de trayecto
|
|
echo-interval 120
|
Se envía un eco cada 2 minutos (120 segundos).
|
|
echo-retransmission-timeout 5
|
Para Echos, si no hay respuesta, se retransmite cada 5 segundos
|
|
path-failure detection-policy gtp echo
|
La detección de falla de trayecto es posible a través del eco gtp (en lugar de no usar esto como un método para detectar falla de trayecto (pero aún enviando ecos).
|
|
associate gtpu-service GGSN1_gtpu
|
Asocia el servicio GGSN1_gtpu con nombre a este servicio GGSN
|
|
bind ipv4-address 209.165.201.2
|
El usuario y las direcciones IP de enlace del plano de control son los mismos en los siguientes ejemplos de configuración, 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 + 5 seg + (5 * 5 seg))
- El proceso egtpinmgr (gtpcmgr obsoleto 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 trayectoria se encuentra en el plano de usuario en lugar del plano de control, y esto 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, CLI "path-failure detection-policy gtp echo" no tiene relevancia - NO Path failure detection is done on GTPU
- GGSN aún responde a las solicitudes de eco del SGSN
- "show gtpu stat" y "show demux-mgr stat gtpumgr" capture echo stats
[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
Varios ejemplos de trampas de falla de trayecto y explicaciones
Por lo general, el contador de reinicio del par aumentará en uno cuando haya un reinicio. En este caso, un error en PGW hizo que invalidara el contador de reinicio con el valor del RC de otro par (primera trampa), y así cuando el siguiente paquete llegó a través de la conexión, lo trató como un reinicio (segunda trampa) pensando que el RC había cambiado. El trayecto se borra en cualquier paquete sucesivo (tercera trampa). El punto aquí no es saber acerca de un error específico, sino más bien intentar y estar al tanto de cualquier cambio de contador que no pueda ser explicado.
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 es de un GGSN donde el peer SGSN ha cambiado su RC de 66 a 67 a través de una solicitud de contexto de creación de 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 es de un PGW donde el peer ePDG ha cambiado su RC de 69 a 70 a través de una Create Session Request:
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 conectados todos al mismo SGW muestra que el SGW dejó de ser alcanzable desde los PGW por una trampa EGTPCPathFail en los diversos PGW en un corto intervalo de tiempo entre sí. Tenga en cuenta que todos muestran el mismo contador de reinicio anterior del que se habló anteriormente que normalmente un nodo utiliza el mismo contador para todos sus pares. Si no hay respuesta, el nuevo contador de reinicio que se muestra es 9, pero es mejor que el nuevo contador se imprima como indefinido ya que la conexión está inactiva cuando se activa la trampa y, por lo tanto, tener un contador de reinicio no tiene 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 una media hora más tarde muestra cuando el par vuelve a estar activo y el contador ha aumentado en uno de 15 a 16. Con el tiempo, el conteo 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 solo están siendo iniciadas por el GGSN (aceptable como se mencionó anteriormente). Un punto en la barra lateral que se debe hacer aquí es que a menudo hay múltiples piezas de datos que se pueden recopilar que todos corroboran a la misma conclusión - uno puede elegir recopilar los datos que son los más concluyentes con la mínima cantidad de 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 observamos 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 apunta a estos peers SGSN como que potencialmente pasan 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
Recordemos que antes, otro enfoque para problemas como este es revisar otros GGSN (o PGW para LTE) para ver si tienen el mismo problema con esos pares 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 peers, pero otra ejecución mostró 129 para uno de los peers. Múltiples ejecuciones (no mostradas aquí por brevedad) mostrarían todos los GGSNs rebotando entre los dos RCs para esos peers 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 que el SGSN cambia el RC, la opción de menú monitor subscriber por el peer SGSN muestra el cambio de RC. Cuando cambie, todas las llamadas se desconectarán con falla de trayectoria como motivo de desconexión. Una captura de pantalla de una captura de paquetes también muestra lo siguiente:
[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, el RC permanece igual cuando se restablece el trayecto. En el segundo ejemplo de peer, clear es el resultado del establecimiento de la 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 repetidamente después de que el contador de reinicio antiguo se haya reiniciado a 2, de alguna manera termina en 0 nuevamente cuando se borra la trayectoria fallida. Esto resultó ser un error. Una vez más, la lección aquí es que si algo parece extraño, debe ser informado.
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
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)