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