Troubleshooting de GTPC e GTPU ASR 5000 Series e falhas de caminho associadas
Contents
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
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)