Solução de problemas do ASR 5000 Series GTPC e GTPU e falhas de caminho associadas
Contents
Introdução
Este artigo cobre compreensão e solução de problemas 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, Restoration Procedures (3GPP TS 23.007) questões , que giram em torno de conceitos como contadores de reinicialização, 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 de configuráveis relacionados. Trata-se, sem dúvida, de um domínio relativamente ao qual se levantam muitas questões. Observe que a solução de problemas específicos de controle de chamadas é, em si, uma área de interesse muito ampla, mas este artigo menciona apenas como capturar estatísticas para controle de chamadas - tudo o que for além disso (isto é, problemas de configuração de chamadas) não será abordado. Na verdade, esse artigo se concentra principalmente na solução de problemas e na verificação das conexões de peer, sem as quais não haveria controle de chamada. Embora escrito para operadores, designers / implementadores também podem se beneficiar do conteúdo aqui.
Todos os exemplos 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 (GGSN))) 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 eles precisam aumentar em um de qualquer maneira. De fato, usar o mesmo contador de reinicialização para todos os pares é útil na solução de problemas de uma rede grande, onde todos os pares podem ser verificados para garantir que os contadores de reinicialização recebidos tenham o mesmo valor (único) para o nó com o qual esses pares 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 e respostas de eco. Assim que ocorre uma alteração no contador de reinicialização em um nó, os vários peers são informados sobre isso por meio das próximas mensagens de controle enviadas aos respectivos peers. Quando uma reinicialização ocorre, por especificação, o lado receptor tem a opção de manter temporariamente as chamadas que ele tem por um curto período ou de abandoná-las, o último que é tipicamente o comportamento configurado.
No caso de usar 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 ecos sejam enviados opcionalmente, e isso se aplicaria ao peer também, cuja abordagem não precisa necessariamente ser a mesma, especialmente quando o peer pode ser de um fornecedor diferente e/ou portadora diferente. Na verdade, com relação às respostas de eco, um nó é obrigado apenas a responder a uma solicitação de eco - recebendo ecos ou não e com que frequência não é significativa - ele só precisa enviar uma resposta de eco para cada solicitação e tomar medidas se o contador de reinicialização receber alterações. É claro, como já foi mencionado, se ele também estiver enviando solicitações de eco e não receber respostas em tempo hábil, precisará tomar medidas 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 via 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 usado por 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, estas são as maneiras pelas quais a detecção de falha de caminho pode ser feita:
- Reiniciar alteração do contador (via mensagem de controle Req/Rsp ou Echo)
- Tempo Limite de Solicitação de Eco GTPC
- Tempo limite de solicitação de eco GTPU
- Tempo limite de mensagem de requisição de controle (normalmente não configurado)
Comandos relevantes
Para solucionar qualquer tipo de problema de caminho, familiarize-se com os comandos a seguir. 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] | motivos de falha de caminho]
- 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 | GGSN/PGW,/entrada SGW | GTPU)
- EGTPCPathFail[Clear], EGTPUPathFail[Clear] interceptações SNMP
- show session disconnect-reason - gtpc-path-failure, gtpu-path-failure, path-failure
Outros comandos para contagem de assinantes relacionados ao GTP:
show sub [summary] gsn-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 por meio da configuração, assim como o status deve ser INICIADO. A única informação obtida é 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 na identificação de todos os peers, incluindo status, contadores de reinicialização e contagens de assinantes atuais/máximas.
- Observe que esse comando abrange os peers 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 (embora a palavra-chave egtpc-service enganosamente também use um nome de serviço GGSN).
- Se não houver assinantes com o peer, o status será Inativo e o Eco GTPC será desabilitado. Nesse estado, para EGTPC, PODE haver alguns peers 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 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. Enquanto isso, para a GGSN, o contador de reinicialização 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 pontos abaixo que têm contagens muito maiores do que os outros pontos. Esses são para SGWs que estão fisicamente localizados no mesmo local ou no local irmão do PGW para o qual o MME envia 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ó em standby ICSR (Inter-Chassis Service Redundancy) só é relevante para peers ativos, caso em que os números devem ser próximos, por exemplo, no seguinte par:
| PGW> show egtpc peers ... 20:51:52 (ATIVE) | PGW-ICSR> show egtpc peers ... 20:51:51 (STANDBY) | |||||||||
| Correspondente | RC | Nº de sessões | Máx. de Sess | Correspondente | RC | Nº de sessões | Máx. de 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 | BANCOS | 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" é usado para verificar um peer específico para ver se ele está acessível ou não e deve ser executado no contexto em que o serviço está definido.
- Usar o gtp- version 1 para as conexões GGSN- SGSN
- O uso do comando ping não é um teste válido, embora se for bem-sucedido, saiba-se que há algum nível de acessibilidade.
- O contador de reinicialização do par (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 par é 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 for executado em um peer e ele atingir o tempo limite por qualquer razão (se tudo estiver funcionando, então não deve atingir o tempo limite), todas as chamadas seriam descartadas (mesmo que as coisas estivessem 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 sucesso/falhas de muitas mensagens de controle EGTPC (Request/Response, Tx/Rx), incluindo Criar Sessão, Modificar Portador, Excluir Sessão, Downlink Data Notify, 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 estiver aumentando como 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á duas vezes o 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 independentes 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 para o eco de teste do PGW de cima (o teste foi feito em tempo diferente da captura de pacote, mas para o mesmo par de pares).
A opção demux-only captura todos os contadores de gerenciamento de caminho (solicitações/respostas de eco), bem como mensagens de controle que nunca chegam a um sessmgr, que geralmente é Criar solicitação/resposta de sessão. O processo Demux etpinmgr residente na placa Demux é responsável por lidar com todas as solicitações/respostas de eco e tratamento inicial de todas as mensagens de controle de chamada antes de distribuí-las aos sessmgr apropriados (aleatoriamente para novas chamadas e especificamente para chamadas existentes ancoradas em um sessmgr específico). A opção sessmgr-only conta apenas as mensagens que são tratadas por sessmgs, o que NÃO inclui contadores de gerenciamento de caminho. Não especificar nenhum dos qualificadores é o padrão da contagem de todos os valores.
"show gtpc statistics" é o comando análogo para serviços SGSN/GGSN (GTPC v1) (CPC, Atualizar Contexto PDP, 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 é a Indicação de Erro Tx/Rx que seria enviada quando o nó receptor não tem registro do assinante que deve ser associado ao Identificador de Ponto Final de Terminal (TEID) do pacote em questão, o que poderia acontecer por vários motivos (O esquema/variável bulkstats é GTPU1/ err-ind-tx). Se o MME/SGW não tiver sido informado de que o PGW não tem mais uma ligação com o assinante, então as chamadas podem precisar ser apagadas manualmente no MME/SGW (ou aguardar o timeout deles) para resolver completamente tal problema de chamadas órfãs.
As versões específicas de peer dos comandos stat acima são necessárias ao Troubleshoot peers específicos, o que frequentemente é 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 alguém já assumiria, ele relata o número de chamadas perdidas, os contadores de reinicialização antigo e novo e o motivo da falha. Além disso, o motivo de desconexão da sessão gtpc-path-failure será incrementado.
A armadilha EGTPCPathFailClear indicará o contador de reinicialização junto com o motivo da limpeza do caminho. O mais recente StarOS v17 é melhor formulado para dizer "razão clara" em vez de "razão de falha" (apagado, 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 estão listados aqui)
- Alterado o contador de reinício do SGSN através da próxima solicitação Create PDP Context após essa alteração (cpc-restart-counter-change)
- Alterado o contador de reinício do SGSN por meio da próxima Solicitação de Contexto PDP de Atualização após essa alteração (que seria uma entrega de outro SGSN) (upc-restart-counter-change)
- Caminho: razão clara da falha: sessions-add é 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 interceptações PathFail e PathClear não parecerem estar alinhados, abra um tíquete com a Cisco para obter mais explicações.
É importante entender como a detecção de falha de caminho EGTPC/GTPC e, em menor grau, EGTPU/GTPU (como a detecção de falha de plano de usuário nem sempre é configurada) é implementada para monitorar a conexão entre um GGSN ou PGW e os vários pares SGSN e SGWs. Normalmente, as conexões dentro de uma rede de provedores de serviços são razoavelmente estáveis, caso em que as falhas de caminho são pouco frequentes. Por outro lado, a experiência tem mostrado que os caminhos GTPC entre SGSNs de roaming que se conectam a GGSNs podem não ser tão estáveis, e assim, com conexões ruins, o resultado são falhas de caminho que acontecem com bastante frequência.
A configuração a seguir abrange os temporizadores e a frequência de transmissão para mensagens de controle e de eco que podem ser usados para detectar falhas de caminho. O mesmo conceito se aplica aos serviços GGSN, SGW, MME e EGTP:
GSN-service GGSN1
|
retransmission-timeout 20
|
Para mensagens de controle GTP (versus as mensagens de eco)
|
|
max-retransmissions 5
|
para mensagens de eco e controle GTP - quantas vezes retransmitir antes do disparo 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 nenhuma 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 de gtp (em vez de não usar isso como um método de detecção de falha de caminho (mas ainda enviando eco)).
|
|
associate gtpu-service GGSN1_gtpu
|
Associa o serviço GTPU nomeado GGSN1_gtpu a esse serviço GGSN
|
|
bind ipv4-address 209.165.201.2
|
Os endereços IP de ligação do plano de controle e do usuário são os mesmos nas configurações de exemplo a seguir, mas não necessariamente podem ser 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 começa (a cada 2 minutos), se não houver respostas após um TOTAL de 30 segundos (6 tentativas), o caminho falhará (0 + 5seg + (5 * 5seg))
- O processo egtpinmgr (gtpcmgr preterido 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, o "path-failure detection-policy gtp echo" da CLI não tem relevância - NO Path failure detection is done on GTPU
- O GGSN ainda responde às solicitações de eco do SGSN, embora
- "show gtpu stat" e "show demux-mgr stat gtpumgr" capture echo stats
[local]PGW-GGSN> show gtpu statistics
Wednesday October 29 23:43:22 UTC 2014
Path Management Messages:
Echo Request Rx: 84690303 Echo Response Rx: 0
Echo Request Tx: 0 Echo Response Tx: 84690043
[local]PGW-GGSN> show demux-mgr statistics gtpumgr
Wednesday October 29 23:42:04 UTC 2014
Echo stats:
Echo Req Rcvd: 84690303
Echo Rsp Sent: 84690043
Vários exemplos de traps de falha de caminho e explicações
Geralmente, o contador de reinicialização do peer aumentará em um quando houver uma reinicialização. Nesse caso, um bug no PGW fez com que ele substituísse o contador de reinicialização pelo valor de RC de outro peer (primeira interceptação) e, assim, quando o próximo pacote chegasse pela conexão, ele o trataria como uma reinicialização (segunda interceptação) pensando que o RC havia sido alterado. O caminho então se apaga em qualquer pacote sucessivo (terceira interceptação). O ponto aqui não é saber sobre um bug específico, mas sim tentar e estar ciente de quaisquer alterações de contador que não possam ser explicadas.
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 um GGSN em que o peer SGSN alterou seu RC de 66 para 67 por meio de uma Solicitação de Contexto Criar 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 alterou 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 PGW conectados ao mesmo SGW mostra que o SGW parou de se tornar acessível dos PGWs por uma armadilha EGTPCPathFail nos vários PGWs dentro de um curto período de tempo entre eles. Observe que todos mostram o mesmo contador de reinicialização antigo discutido anteriormente que normalmente um nó usa o mesmo contador para todos os seus pares. Caso não haja resposta, o novo contador de reinicialização exibido é 9, mas o novo contador pode ser impresso como indefinido, já que a conexão está inativa a partir de quando a interceptação é acionada e, portanto, ter um contador de reinicialização realmente não faz 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 novo contador de reinicialização como no exemplo anterior, mas uma meia hora depois mostra quando o peer volta a funcionar e o contador aumenta 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 de caminho repetida 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" confirma que não há problemas com a conectividade em relação às solicitações e respostas de eco, que nesse caso estão sendo iniciadas apenas pelo GGSN (aceitável conforme discutido anteriormente). Um ponto da barra lateral a ser feito aqui é que muitas vezes há várias partes de dados que podem ser coletados e que corroboram a mesma conclusão - pode-se escolher coletar os dados que são 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
Observando outros peers na sub-rede, todos eles mostram um RC = 132 o tempo todo, enquanto os peers quebrados alternam entre 129 e 132 como mostrado, o que aponta para esses peers SGSN como potencialmente 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
Lembrem-se de anteriores, outra abordagem para questões como esta é verificar outros GGSNs (ou PGWs para LTE) para ver se eles têm o mesmo problema com aqueles pares SGSN aparentemente problemáticos, e neste caso eles também têm. Para GGSN3, a primeira execução do comando mostrou valores 132 para ambos os peers, mas outra execução mostrou 129 para um dos peers. Várias execuções (não mostradas aqui para resumir) mostrariam todas as GGSNs saltando entre os dois RCs para esses correspondentes 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, é o SGSN alterando o RC, a opção de menu monitorar assinante pelo par SGSN mostra a alteração de RCs. Quando ela muda, todas as chamadas são desconectadas com falha de caminho como a razão 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, 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 em que repetidamente após o contador de reinicialização antigo ter sido redefinido para 2, ele de alguma forma termina em 0 novamente quando o caminho falhar se limpa. Isso acabou sendo um bug. Novamente, a lição aqui é que, se algo parecer estranho, deve ser relatado.
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
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)