Contents

Introduction

Background

Comandos relevantes

Detecção de falha de caminho

Vários exemplos de armadilhas de falha de caminho e explicações

Discussões relacionadas da comunidade de suporte da Cisco

Introduction

Este artigo abrange a compreensão e a solução de problemas do Evolved General Packet Radio Service Tunneling Protocol for Control Plane (EGTPC) / GTPC (3rd Generation Partnership Project Technical Specification 29.274), GPRS Tunneling protocol User Plane (GTPv1-U) (3GPP TS 29.281) e é mais relevante para este artigo, Procedimentos de restauração (3GPP TS 23.007) problemas que giram em torno de conceitos como contadores de reinicialização, detecção de falhas de caminho e solicitações/respostas de eco. Ele inclui uma lista de comandos relevantes e o que procurar na saída, juntamente com a explicação dos configuráveis relacionados. Trata-se, sem dúvida, de um domínio para o qual são levantadas muitas questões. Observe que a solução de problemas específicos de controle de chamadas é, por si só, uma área de interesse muito extensa, mas este artigo apenas menciona como capturar estatísticas para controle de chamadas - qualquer coisa além disso (ou seja, problemas de configuração de chamadas) não é abordada. Na verdade, este artigo concentra-se principalmente na solução de problemas e na verificação de conexões de mesmo nível, sem as quais não haveria controle de chamadas.  Embora escritos para operadores, designers/implementadores também podem se beneficiar do conteúdo aqui.

Exemplos todos usam endereços IP falsos (alterados) da rede de um operador real.

Background

Cada lado de uma conexão GTP (um de 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 (GPRS) SN) mantém um contador de reinicialização projetado para alertar o peer se o nó de origem tiver sido reiniciado para que esse peer possa tomar a ação apropriada. Embora um nó possa usar um contador exclusivo para cada peer com o qual ele se comunica, o design tende a ser usar o MESMO contador para todos os peers, já que quando o nó é reiniciado, o contador precisa ser incrementado para todos os peers e, portanto, rastrear um valor separado em uma base de peer não serve nenhum benefício extra, uma vez que todos precisam aumentar em um de qualquer forma. Na verdade, o uso do mesmo contador de reinicialização para todos os peers é útil na solução de problemas de uma rede grande onde todos os peers podem ser verificados para garantir que os contadores de reinicialização recebidos tenham o mesmo valor (único) para o nó com o qual esses peers estão se comunicando.

O contador de reinicialização PODE ser incluído em todos os tipos de mensagens de controle, enquanto o contador de reinicialização DEVE ser incluído em todas as solicitações de eco e respostas. Assim que uma alteração de contador de reinicialização ocorre em um nó, os vários peers são informados sobre ela por meio das próximas mensagens de controle enviadas aos respectivos peers. Quando ocorre uma reinicialização, por especificação, o lado receptor tem a opção de manter temporariamente as chamadas que possui por um curto período ou descartá-las, o último que normalmente é o comportamento configurado.

Em caso de uso de solicitações de eco, o método é enviar as mensagens em um intervalo configurado e, se nenhuma resposta for recebida após um número configurado de novas tentativas (cada uma após um tempo limite configurado), o caminho será considerado inativo e a ação apropriada será tomada.  A configuração permite que echos sejam opcionalmente enviados, e isso se aplica também ao peer, cuja abordagem não precisa necessariamente ser a mesma, especialmente quando o peer pode ser de um fornecedor diferente e/ou portadora diferente. De fato, no que diz respeito às respostas de eco, um nó só é obrigado a responder a uma solicitação de eco - seja ele recebe echos ou não e com que frequência não é significativa - ele só precisa enviar uma resposta de eco para cada solicitação e agir se o contador de reinicialização recebeu alterações. Claro que, como já foi mencionado, se ele também está enviando solicitações de eco e não recebe respostas oportunas, ele precisa agir para esse cenário também.

Observe que a detecção de falha de caminho também pode ser feita através da conexão GTP-U (plano do usuário) via Echo, mas SOMENTE através de timeout, já que não há contador de reinicialização incluído nas mensagens GTP-U como há para GTP-C como discutido anteriormente. O GTP-U pode ou não estar usando o mesmo caminho das mensagens de controle. Se for o mesmo caminho, a detecção de GTP-U pode não ser tão valiosa, já que a detecção de GTP-C deve ser suficiente.

Em resumo, aqui estão as maneiras pelas quais a detecção de falha de caminho pode ser feita:

- Reiniciar alteração de contador (por meio de msg de controle Req/Rsp ou Echo)

- Tempo limite de solicitação de eco GTPC

- Tempo limite de solicitação de eco GTPU

- Tempo limite da mensagem de solicitação de controle (geralmente não configurado)

Comandos relevantes

Para solucionar qualquer tipo de problema de caminho, familiarize-se com os seguintes comandos. Veja a seguir uma explicação dos detalhes relevantes de cada um.

- 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] | caminho-falha-razões]

- show gtpu statistics [peer-address <peer>]

- show gtpc statistics [ggsn-service <service>] [smgr-instance <instance>]

- show demux-mgr statistics <egtpinmgr | egtpegmgr | gtbomgr> all (SGW-egress | GGSN/PGW/entrada SGW | GTPU)

- EGTPCPathFail[Clear], EGTPUPathFail[Clear] armadilhas SNMP

- show session disconnect-reason - gtpc-path-failure, gtpu-path-failure, path-failure

Outros comandos para a contagem de assinantes relacionados ao GTP:

show sub [summary] ggsn-service <service>

show sub [summary] gtpu-service <service>

show egtpc sessions [egtp-service <service>]

O comando básico para verificar o status e a configuração de todos os serviços EGTP é "show egtpc-service". A maior parte da saída deve ser o que já é conhecido pela configuração, assim como o status deve ser INICIADO. As informações exclusivas obtidas são o "Contador de reinicialização", que não pode ser encontrado em nenhum outro lugar. O comando relacionado "show gtpu-service all" retorna configuráveis para o(s) serviço(s) GTPU associado(s) aos serviços EGTPC.

"show egtpc peers" é muito útil para identificar todos os peers, incluindo status, contadores de reinicialização e contagens atuais/máximas de assinantes.

- Observe que esse comando cobre os pares SGW e SGSN, enquanto no passado havia um comando separado para SGSN/GGSN.

- Como esse comando inclui todos os tipos de peer, o tipo de peer pode ser filtrado por meio do nome do serviço (mesmo que a palavra-chave egtpc-service enganosamente também tome um nome de serviço GGSN).

- Se não houver assinantes com o peer, o status será Inativo e Eco GTPC desativado. Nesse estado, para o EGTPC, PODE haver alguns pares para os quais o contador de reinicialização é relatado, enquanto a maioria pode ser 0.  Isso ocorre em situações em que o peer está enviando ativamente solicitações de eco às quais o ASR5K deve responder. O contador de reinicialização pode ser determinado executando-se o comando de teste EGTPC (discutido a seguir), embora no estado inativo, o contador não será atualizado em "show egtpc peers" mesmo que tenha sido recebido.   Entretanto, para a GGSN, o contador de reinício nunca é esquecido.

[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 alguns pares abaixo que têm contagens muito maiores que os outros pares. Eles são para SGWs fisicamente localizados no mesmo site ou no site da irmã do PGW para o qual o MME direciona a maioria das chamadas.

[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

Observe que a execução desse comando em um nó de standby de Redundância de Serviço entre Chassis (ICSR - Inter-Chassis Service Redundancy) é relevante apenas para os peers ativos, caso em que os números devem ser fechados, por exemplo, no seguinte par:

PGW> show egtpc peers ... 20:51:52 (ATIVO)

PGW-ICSR> show egtpc peers ... 20:51:51 (STANDBY)

Correspondente

RC

Nº de sessões

Max Sess

Correspondente

RC

Nº de sessões

Max Sess

ÁREAS

192.0.2.5

2

31

443

ADSKS

192.0.2.5

2

31

443

ÁREAS

192.0.2.24

3

117

123

ADNKS

192.0.2.24

3

117

123

ÁREAS

192.0.2.36

15

4223

6889

ADSKS

192.0.2.36

15

4223

6889

ÁREAS

192.0.2.44

7

119

331

ADSKS

192.0.2.44

7

119

331

ÁREAS

192.0.2.68

34

6174

9798

ADSKS

192.0.2.68

34

6171

9797

ÁREAS

192.0.2.69

7

2311

5027

ADSKS

192.0.2.69

7

2311

5027

ÁREAS

192.0.2.88

17

3914

8880

ADSKS

192.0.2.88

17

3913

8874

ÁREAS

192.0.2.164

16

833705

1298070

ADSKS

192.0.2.164

16

832037

1294412

ÁREAS

192.0.2.184

3

1438418

2153317

ADSKS

192.0.2.184

3

1435461

2147280

ÁREAS

192.0.2.193

21

11447

26577

ADSKS

192.0.2.193

21

11443

26568

ÁREAS

192.0.2.195

5

48

162

ADSKS

192.0.2.195

5

48

162

ÁREAS

192.0.2.226

21

1962

3931

ADSKS

192.0.2.226

21

1962

3931

ÁREAS

192.0.2.227

6

4465

9332

ADSKS

192.0.2.227

6

4466

9332

"egtpc test echo" é usado para verificar um peer específico para ver se ele pode ser alcançado ou não e deve ser executado no contexto em que o serviço é definido.

- Usar o gtp-version 1 para conexões GGSN-SGSN

- O uso do comando ping não é um teste válido, embora, se for bem-sucedido, se saiba que há algum nível de alcance.

- O contador de reinicialização de peer (Recuperação) é exibido.

- A execução desse comando incrementará os contadores de solicitação de eco Tx / resposta de eco Rx em "show egtpc statistics"

- O contador de reinicialização do peer é relatado após a palavra-chave Recovery (11 no exemplo abaixo)

- aviso: embora isso não deva acontecer em circunstâncias normais, se um eco de teste é executado em um peer e ele expira por qualquer motivo (se tudo estiver funcionando então não deve expirar), todas as chamadas serão perdidas (mesmo que as coisas estejam funcionando bem até o ponto de fazer o teste).

[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" é para EGTPC (v2) e relatórios sobre o sucesso/falhas de muitas mensagens de controle EGTPC (Request/Response, Tx/Rx) incluindo Criar sessão, Modificar portador, Excluir sessão, Desligar notificação de dados, Liberar portador de acesso, Criar portador, Atualizar portador, Modificar portador, Suspender etc. e as respostas associadas. Ele inclui todos os contadores de gerenciamento de caminho para Echo Request/Response Tx/Rx e, com base nos temporizadores, o crescimento desses temporizadores pode ser previsto e usado para solucionar problemas, se não incrementando conforme esperado.

O exemplo a seguir mostra ecos e respostas sendo iniciadas e respondidas de ambos os lados. Observe que o SGW foi configurado para enviar uma vez por minuto enquanto o PGW foi configurado para uma vez a cada três minutos (ambos os lados não precisam ter a mesma configuração) e, portanto, a cada três minutos, há o dobro do número de pacotes (6:16:33, 6:19:33). Lembre-se de que, embora ambos os lados estejam no mesmo "ciclo" neste exemplo, eles não precisam ser e podem ser executados independentemente um do outro.  Os contadores de reinicialização também foram capturados em uma coluna. Observe que o contador de reinicialização de 11 da resposta de eco do SGW corresponde ao valor de sua resposta ao eco de teste do PGW de cima (o teste foi feito em um momento diferente da captura de pacote, mas para o mesmo par de pares).

A opção demux-only captura todos os contadores de gerenciamento de caminhos (solicitações/respostas de eco) assim como mensagens de controle que nunca alcançam um sessmgr, que geralmente é Create Session Request/Response (Criar solicitação/resposta da sessão). O Demux process etpinmgr residindo na placa Demux é responsável por tratar todas as solicitações/respostas de eco e tratamento inicial de todas as mensagens de controle de chamadas antes de distribuí-las para os programas apropriados (aleatoriamente para novas chamadas, e especificamente para as chamadas existentes ancoradas em um gerente de avaliação específico). A opção sessmgr-only conta somente mensagens que são tratadas por sessmgrs, que NÃO incluem contadores de gerenciamento de caminho. Não especificar nenhum dos qualificadores é o padrão para contar todos os valores.

"show gtpc statistics" é o comando análogo para serviços SGSN/GGSN (GTPC v1) (CPC, Update PDP Context, etc.)

"show gtpu statistics" relata estatísticas sobre o tráfego do plano do usuário manipulado pelos serviços GTP-U associados aos serviços EGTPC. Um contador interessante é o Tx/Rx de Indicação de Erro que seria enviado quando o nó receptor não tem registro do assinante que deve ser associado ao Identificador de Ponto Final de Terminal (TEID - Terminal Endpoint Identifier) do pacote em questão, o que poderia acontecer por várias razões (O esquema/variável de bulkstats é GTPU1/ err-ind-tx). Se o MME/SGW não tiver sido informado de que o PGW não tem mais um vínculo com o assinante, as chamadas podem precisar ser manualmente limpas no MME/SGW (ou esperar que o tempo limite seja excedido) para resolver totalmente esse problema de chamadas órfãs.

As versões específicas do peer dos comandos stat acima são necessárias ao Troubleshoot peers específicos, que geralmente é o caso.

Detecção de falha de caminho

A armadilha EGTPCPathFail é a chave para saber quando ocorreu uma falha de caminho. Entre alguns valores básicos que já se supunha, ele relata o número de chamadas descartadas, os contadores de reinicialização antigos e novos e o motivo da falha. Além disso, o motivo da desconexão da sessão gtpc-path-failure será incrementado.

A armadilha EGTPCPathFailClear indicará o contador de reinicialização juntamente com o motivo da limpeza do caminho. A versão mais recente do StarOS v17 é melhor redigida para dizer "razão clara" em vez de "razão da falha" (apagou, não falhou!) para evitar confusão.

A seguir estão as contagens de falhas de caminho que são relatadas de "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:

- O contador de reinicialização da mensagem de controle no sessmgr pode ser qualquer tipo de mensagem de controle (nem todos listados aqui)

- Alterado o contador de reinicialização do SGSN através da próxima solicitação de contexto do PDP após essa alteração (cpc-restart-counter-change)

- Alterado o contador de reinicialização do SGSN através da próxima solicitação de contexto do PDP de atualização após essa alteração (que seria uma transferência de outro SGSN) (upc-restart-counter-change)

- Sessões de razão de falha clara de caminho - adicionar é um termo enganador - não é uma falha, mas um sucesso, e indica que uma nova sessão entrou para estabelecer a conexão

- Se os valores relatados para contadores de reinicialização e contagens de sessão para as armadilhas PathFail e PathClear não parecerem estar alinhados, abra um tíquete com a Cisco para obter mais explicações.

É importante entender como o EGTPC/GTPC e, em menor grau, o EGTPU/GTPU (como a detecção de falha do plano do usuário nem sempre está configurada) a detecção de falha de caminho é implementada para monitorar a conexão entre um GSN ou PGW e os vários SGSN e SGWs de peer. Normalmente, as conexões em uma rede de provedores de serviços são bastante estáveis, caso em que falhas de caminho são raras. No lado inverso, a experiência mostrou que os caminhos GTPC entre SGSNs em roaming conectados a GGSNs podem não ser tão estáveis, e portanto com conexões deficientes, o resultado é que falhas de caminho ocorrem com bastante frequência.

A configuração a seguir abrange temporizadores e frequência de transmissão para mensagens de controle e de eco que podem ser usadas para detectar falhas de caminho. O mesmo conceito se aplica aos serviços GGSN, SGW, MME e EGTP:

ggsn-service GGSN1

retransmission-timeout 20

Para mensagens de controle GTP (versus mensagens de eco)

max-retransmissions 5

para mensagens de controle e de eco de GTP - quantas vezes retransmitir antes do disparador de detecção de falha de caminho

echo-interval 120

Um eco é enviado a cada 2 minutos (120 segundos).

echo-retransmission-timeout 5

Para Echos, se não houver resposta, ele retransmite a cada 5 segundos

path-failure detection-policy gtp echo

A detecção de falha de caminho é possível através do eco gtp (em vez de não usar isso como um método de detecção de falha de caminho (mas ainda enviar echos).

associar gtpu-service GGSN1_gtpu

Associa o serviço GGSN1_gtpu nomeado GTPU a este serviço GGSN

bind ipv4-address 209.165.201.2

Os endereços IP de associação do plano de controle e do usuário são os mesmos no exemplo a seguir configura, mas podem não ser necessariamente configurados como tal com outras implementações do provedor de serviços.

[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 o tempo 0 sendo quando um ciclo de solicitação de Eco é iniciado (a cada 2 minutos), se não houver respostas após um TOTAL de 30 segundos (6 tentativas), o caminho falha (0 + 5 seg + (5 * 5 seg))

- O processo egtpinmgr (gtpcmgr desaprovado desde v14) em execução na placa demux é responsável pelo processamento dos pacotes de eco

- "show gtp statistics", seção "Path Management Messages" tem estatísticas para solicitações/respostas de eco para o caminho de controle em AMBAS as direções:

[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

Outro método de detecção de caminho está no plano do usuário em vez do plano de controle, e isso é regido pela seguinte configuração.

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" desabilita o envio de solicitações de eco para o plano do usuário e, portanto, a CLI "path-failure detection-policy gtp echo" não tem relevância - NÃO há detecção de falha de caminho em GTPU

- A GGSN ainda responde às solicitações de eco da SGSN, embora

- "show gtpu stat" e "show demux-mgr stat gtbomgr" capturam estatí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

Vários exemplos de armadilhas de falha de caminho e explicações

Geralmente, o contador de reinicialização de peer aumentará em uma quando houver uma reinicialização. Nesse caso, um bug no PGW fez com que ele substituísse o contador de reinicialização pelo valor do RC de outro peer (primeira armadilha) e, assim, quando o próximo pacote chegou pela conexão, ele o tratou como uma reinicialização (segunda armadilha) pensando que o RC havia mudado. Em seguida, o caminho é limpo em qualquer pacote sucessivo (terceira armadilha). O objetivo aqui é não saber sobre um bug específico, mas tentar e estar ciente de qualquer alteração de contador que não possa ser explicada.

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 exemplo é de uma GGSN em que o peer SGSN mudou seu RC de 66 para 67 por meio de uma solicitação de contexto de criação 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 exemplo é de um PGW em que o peer ePDG mudou seu RC de 69 para 70 por meio de uma solicitação de criação de sessão:

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

Neste exemplo, a saída de vários nós de PGW todos conectados ao mesmo SGW mostra que o SGW parou de se tornar alcançável dos PGWs por uma armadilha EGTPCPathFail nos vários PGWs em um curto período de tempo de cada um. Observe que todos mostram o mesmo contador de reinicialização antigo como discutido anteriormente que normalmente um nó usa o mesmo contador para todos os seus pares. No caso de não haver resposta, o novo contador de reinicialização exibido é 9, mas o novo contador pode ser impresso como indefinido, pois a conexão está inativa a partir de quando a armadilha é disparada e, portanto, ter um contador de reinicialização não faz 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

O exemplo a seguir mostra uma falha de caminho e o mesmo contador de reinicialização como no exemplo anterior, mas, em seguida, meia hora depois mostra quando o peer volta a funcionar novamente e o contador aumentou de 15 para 16. Com o tempo, a contagem aumenta para esse peer:

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 exemplo mostra uma falha repetida no caminho devido à reinicialização do CPC para 3 pares SGSN específicos para o GGSN. A saída abaixo mostra apenas um dos pares 209.165.200.225, mas todos têm o mesmo problema. A execução repetida de "show egtpc peers" e "show gtpc stat sgsn-address" também mostra os valores alternados. "show gtpc stat" não confirma nenhum problema de conectividade com relação a solicitações e respostas de eco, que nesse caso só estão sendo iniciadas pela GGSN (aceitável como discutido anteriormente). Um ponto da barra lateral a ser feito aqui é que muitas vezes há vários dados que podem ser coletados que corroboram até a mesma conclusão - pode-se escolher coletar os dados mais conclusivos com o mínimo de esforço.

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

Olhando para outros pares na sub-rede, todos eles mostram um RC = 132 o tempo todo, enquanto os pares quebrados alternam entre 129 e 132 como mostrado, o que aponta para esses pares SGSN como possivelmente passando o RC errado nos cenários quebrados:

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

Lembre-se de que outra abordagem para questões como essa é verificar outros GGSNs (ou PGWs for LTE) para ver se eles têm o mesmo problema com os pares de SGSN aparentemente problemáticos, e nesse caso também têm. Para GGSN3, a primeira execução do comando mostrou valores 132 para ambos os pares, mas outra execução mostrou 129 para um dos pares. Múltiplas execuções (não mostradas aqui para brevidade) mostrariam todos os GGSNs que oscilam entre os dois RCs para esses peers ao longo do tempo:

[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 o problema está na SGSN alterando o RC, monitore a opção de menu do assinante por programas de peer SGSN alterando os RCs. Quando ele muda, todas as chamadas são desconectadas com falha de caminho como o motivo da desconexão. Uma captura de tela de uma captura de pacote também mostra o seguinte:

[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 exemplo mostra uma falha de caminho em que o problema estava realmente no caminho e não no PGW ou SGW. Como resultado, o RC permanece o mesmo quando o caminho é restabelecido. No segundo exemplo de peer, o clear é um resultado do estabelecimento de solicitação 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 exemplo mostra outra anomalia onde, repetidamente, depois que o contador de reinicialização antigo é redefinido para 2, ele de alguma forma termina em 0 novamente quando o caminho falha é limpo. Isto acabou sendo um bug. Novamente, a lição aqui é que se algo parecer estranho, deve ser reportado.

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