Solucionar Falhas de Caminho EGTP Devido a Incompatibilidade nos Valores do Contador de Reinicialização

Introdução

Este documento descreve a solução de problemas de falhas de caminho do Evolved-GPRS Tunneling Protocol (EGTP) observadas devido a uma incompatibilidade nos valores do contador de reinicialização entre SGSN/MME e GGSN/Serving Gateway ou PDN Gateway (SPGW).

Comandos para Troubleshooting

show egtpc peers interface
show egtpc peers path-failure-history
show egtpc statistics path-failure-reasons
show egtp-service all
show egtpc sessions
show egtpc statistics

egtpc test echo gtp-version 2 src-address <source node IP address>  peer-address <remote node IP address>

For more details about this commands refer this mentioned link

https://www.cisco.com/c/en/us/support/docs/wireless-mobility/gateway-gprs-support-node-ggsn/119246-technote-ggsn-00.html

Análise

A partir dos registros e estatísticas, é identificado que o valor do contador de reinicialização na extremidade do MME (Mobility Management Entity) é 11 e na extremidade do EPG é 12.

Você pode observar as armadilhas como mencionado aqui:

Internal trap notification 1112 (EGTPCPathFail) context s11mme, service s11-mme, interface type mme, self address <X.X.X.X>,  peer address <Y.Y.Y.Y>, peer old restart counter 4,  peer new restart counter 4,  peer session count  240, failure reason no-response-from-peer,  path failure detection Enabled.
Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address <X.X.X.X>,  peer address <Y.Y.Y.Y>, peer old restart counter 54,  peer new restart counter 12,  peer session count  1107240, failure reason restart-counter-change
Internal trap notification 1112 (EGTPCPathFail) context XGWin, service EGTP1, interface type pgw-ingress, self address <X.X.X.X>,  peer address <Y.Y.Y.Y>, peer old restart counter 12,  peer new restart counter 54,  peer session count  1107207, failure reason create-sess-restart-counter-change

O Gateway do Fornecedor (GW) tem um problema ao aceitar valores menores do nó de suporte do GPRS de serviço (SGSN) se o contador de reinicialização for alterado. Se o fornecedor GW tiver armazenado um valor maior (antigo) e após o recarregamento do nó se o Cisco SGSN enviar um valor menor, o Fornecedor GW não o aceitará.

Nota: Conforme TS 29.060:

1. Se o SGSN estiver em contato com o Gateway GPRS Support Node (GGSN) pela primeira vez ou tiver reiniciado recentemente sem indicar o novo valor do Contador de Reinicialização para o GGSN, ele incorporará um elemento de informações de Recuperação na Solicitação de Contexto Criar Ponto de Decisão de Política (PDP). Este elemento é incluído pela SGSN quando necessário. O GGSN que recebe um elemento de informações de Recuperação no elemento de mensagem Criar Solicitação de Contexto PDP o trata como ao receber uma mensagem de Resposta de Eco. A mensagem Create PDP Context Request é considerada uma solicitação de ativação válida para o contexto PDP incluído na mensagem.

2. O GGSN inclui o elemento de informações de Recuperação na Resposta de Criação de Contexto PDP se o GGSN estiver em contato com o SGSN pela primeira vez ou se o GGSN tiver reiniciado recentemente e o novo valor do Contador de Reinicialização ainda não tiver sido indicado ao SGSN. O SGSN que recebe o elemento de informações de Recuperação trata-o como quando uma mensagem de Resposta de Eco é recebida. No entanto, ele considera o contexto PDP que está sendo criado como ativo se a resposta indicar ativação de contexto bem-sucedida no GGSN.

3. A interface GTP usa um contador de reinicialização para rastrear o número de reinicializações. De acordo com o TS 23.060, os nós GTP devem usar armazenamento persistente para rastrear seus contadores de reinicialização GTP locais para que seja esperado que esses contadores de reinicialização continuem sempre para cima. No entanto, no caso de um nó par detectar uma diminuição no contador de reinício, o comportamento do nó GTP é elaborado na sessão '18 GTP-C based restart procedures' do TS 23.007. Suponha que o valor de um contador de reinicialização armazenado anteriormente para um par seja maior que o valor do contador de reinicialização recebido na mensagem de Resposta de Eco ou na mensagem GTP-C, levando em conta a sobreposição de inteiros. Nesse caso, isso indica uma possível condição de corrida (mensagem mais nova chegando antes da mais antiga). O novo valor do contador de Reinicialização recebido é descartado e um erro pode ser registrado. Em outras palavras, quando o nó GTP detecta um contador de reinicialização mais baixo de um peer, ele nunca registra esse novo contador de reinicialização.

Perspectiva StarOS

Na extremidade StarOS, você pode alterar explicitamente o valor RC no StarOS a partir do caminho /flash/restart_file_cntr.txt que é feito no momento da atualização.

De acordo com essa teoria, ao compará-la com a configuração atual, o valor de MME RC era inferior ao valor de Vendor GW RC. Para resolver o problema, o valor RC no nó GW do fornecedor foi modificado.

Agora, depois de alterar o valor de RC, é visto que as falhas de caminho EGTPC pararam, mas ainda assim, as sessões não estão aumentando e os links EGTPC ainda estão mostrando inativos.

Estes são os comandos que foram usados durante a solução de problemas:

show sgtp-service all | grep "restart"  ----------------- to check RC value

[local]Nodename# show egtp-service all | more
  Service name                          : egtpc_sv_service
  Service-Id                            : 5
  Context                               : SGs
  Interface Type                        : mme
  Status                                : STARTED
  Restart Counter                       : 11   ----------------- RC value to verify
  Max Remote Restart Counter Change     : 255
  Message Validation Mode               : Standard
  GTPU-Context                          :
  GTPC Retransmission Timeout           : 5000 (milliseconds)
  GTPC Maximum Request Retransmissions  : 4
  GTPC IP QOS DSCP value                : 10
  GTPC Echo                             : Enabled
  GTPC Echo Mode                        : Default


[local]Nodename# show egtpc peers           ------------ To check link status
Sunday February 05 15:31:00 IST 2023
+----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       (B) - MBMS                          
|||||                        (U) - Unknown                                       
|||||                                                                            
|||||  Service                       Restart--------+  No. of                    
|||||  ID                            Counter        |  restarts                  
|||||   |                                           |   |   Current       Max    
vvvvv   v              Peer Address                 v   v   sessions    sessions  LCI OCI
-----  --- --------------------------------------- --- --- ----------- ------------------
IDSKS  10                           X.X.X.X         91   0           0           0   X   X
IDNKS  11                           Y.Y.Y.Y          4  95           0       34005   X   X
IDNKS  11                           Z.Z.Z.Z         10 103           0       16805   X   X
IDNKS  11                           A.A.A.A        104  95           0        7250   X   X
AESKS  11                           B.B.B.B          0   0        4004       47649   X   X
AESKS  11                           C.C.C.C          0   0        4053       46571   X   X
AESKS  11                           D.D.D.D          0   0        4026       46734   X   X

ABove output peers if you see no sessions on this peer and also link are inactive

Além disso, verifique a solicitação/resposta de eco (a ser verificado no modo oculto):

egtpc test echo gtp-version 2 src-address <MME end IP> peer-address <EPG end IP> 

Esta é a saída quando o valor do contador de reinicialização é corrigido e configurado da mesma forma que o do MME para a interface S11 para o peer EGTP afetado e, em seguida, a solicitação/resposta de eco está bem, mas o link ainda está inativo.

[s11mme]Nodename# egtpc test echo gtp-version 2 src-address <X.X.X.X> peer-address <Y.Y.Y.Y>

Sunday February 05 16:22:42 IST 2023

EGTPC test echo

---------------

Peer: X.X.X.X                          Tx/Rx:  1/1  RTT(ms): 1    (COMPLETE) Recovery: 10 (0x0A)

No entanto, o mesmo não funciona como esperado em outros GWs problemáticos afetados. Você ainda recebe uma falha para solicitação/resposta de eco como mencionado aqui.

[s11mme]Nodename# egtpc test echo gtp-version 2 src-address <X.X.X.X> peer-address <Y.Y.Y.Y>




Sunday February 05 16:46:11 IST 2023

EGTPC test echo

---------------

Peer: X.X.X.X                         Tx/Rx:  1/0  RTT(ms): 0    (FAILURE)

Solução

1. Para corrigir este problema, tome nota do contador de reinício atual em /flash/restart_file_cntr.txt antes da desativação do VNF. Mais tarde, quando for ativado com o novo software, faça login no CF e atualize o arquivo /flash/restart_file_cntr.txt com o contador de reinicialização antigo. Em seguida, como um procedimento de atualização normal, recarregue o VNF com a configuração do dia N.

2. Modifique o cat /flash/restart_file_cntr.txt para o valor necessário e recarregue o nó com a configuração atual.

Observação: você pode tentar com a reinicialização de SGTPC assim como na etapa inicial.