ASR5x00: CDRs atrasados sendo enviados para CGF devido a configuração incorreta em APNs

Introduction

Este documento descreve um cenário específico em que os registros de dados de chamada (G-CDRs) do Gateway-Gprs Support Node (GGSN) estão travados devido à configuração incorreta no Access Point Name(APN), resultando em cobrança incorreta para os assinantes e o Charging Gateway Function(CGF) recebe CDRs atrasados que estão presos no GGSN. Esse problema é relatado nos Cisco Aggregated Service routers (ASR) 5x00 Series.

Problema

Devido a vários motivos (provavelmente configurações incorretas) para alguns APNs , os CDRs vão para o grupo padrão. No grupo padrão, não temos servidores CGF configurados e, portanto, as solicitações ficam travadas.

 por exemplo:

apn blackberry.net.40413pre

     selection-mode subscribed sent-by-ms chosen-by-sgsn

     accounting-mode none

     timeout idle 10800

     ip access-group ECS in

     ip access-group ECS out

     ip address pool name blackberry

     credit-control-group GY_LIVE_PRE

     active-charging rulebase test_prepaid

   exit

   apn blackberry.net.40443pre

     selection-mode subscribed sent-by-ms chosen-by-sgsn

     accounting-mode none

     timeout idle 10800

     ip access-group ECS in

     ip access-group ECS out

     ip address pool name blackberry

     credit-control-group GY_LIVE_PRE

     active-charging rulebase test_prepaid

   exit

   apn blackberry.net.40446pre

     selection-mode subscribed sent-by-ms chosen-by-sgsn

     accounting-mode none

     timeout idle 10800

     ip access-group ECS in

     ip access-group ECS out

     ip address pool name blackberry

     credit-control-group GY_LIVE_PRE

     active-charging rulebase test_prepaid

   exit

   apn blackberry.net.40484pre

     selection-mode subscribed sent-by-ms chosen-by-sgsn

     accounting-mode none

     timeout idle 10800

     ip access-group ECS in

     ip access-group ECS out

     ip address pool name blackberry

     credit-control-group GY_LIVE_PRE

     active-charging rulebase test_prepaid

   exit

   apn blackberry.net.40486pre

     selection-mode subscribed sent-by-ms chosen-by-sgsn

     accounting-mode none

     timeout idle 10800

     ip access-group ECS in

     ip access-group ECS out

     ip address pool name blackberry

     credit-control-group GY_LIVE_PRE

     active-charging rulebase test_prepaid

   exit

   aaa group default

   #exit

   gtpp group default

Troubleshoot

Na saída Show support details, verifique a saída do comando

******** show session subsystem data-info verbose *******

647274 Total gtpp acct requests           1 Current gtpp acct requests

       0 Total gtpp acct cancelled          0 Total gtpp acct purged

       0 Total gtpp sec acct requests       0 Total gtpp sec acct purged

     248 Total null acct requests           0 Current null acct requests

2482018515 Total aaa acct sessions       265064 Current aaa acct sessions

14529031 Total aaa acct archived       6518761 Current aaa acct archived

265064 Current recovery archives     259073 Current valid recovery records

   1108 Total aaa sockets opened         932 Current aaa sockets opened

A conta atual arquivada mostra que 6 milhões de CDRs estão presos em todos os aaamgrs e devido aos quais nenhum CDR novo é processado e transferido para CGF no modo de transmissão.

Quando o limite é atingido por aaamgr, os CDRs são limpos e resultam em perda de CDRs e perda de receita para o cliente.

dos 6 milhões de CDRs arquivados , você vê alguns CDRs sendo removidos

******** show session subsystem data-info verbose *******

1228764750 Total gtpp charg              6534523 Current gtpp charg
1221919009 Total gtpp charg success       311218 Total gtpp charg failure
       0 Total gtpp charg cancelled     311218 Total gtpp charg purged
       0 Total gtpp sec charg                0 Total gtpp sec charg purged
       0 Total prepaid online requests       0 Current prepaid online requests
       0 Total prepaid online success        0 Current prepaid online failure
       0 Total prepaid online retried        0 Total prepaid online cancelled
       0 Current prepaid online purged

Aqui estão as listas de verificação dos comandos CLI comumente usados para depurar problemas relacionados ao CDR.

- show gtpp accounting servers
- show gtpp accounting servers group name <CGF>
- show gtpp counters all
- show gtpp counters cgf-address 172.16.10.11
- show gtpp counters cgf-address 172.16.10.11 gcdrs
- show gtpp counters group name CGF
- show gtpp counters group name CGF gcdrs
 
- show gtpp group all
- show gtpp group name CGF
 
- show gtpp statistics
- show gtpp statistics cgf-address 172.16.10.11
- show gtpp statistics group name CGF
 
- show gtpp storage-server streaming file counters all
- show gtpp storage-server streaming file counters group name CGF
 
- show gtpp storage-server streaming file statistics
- show gtpp storage-server streaming file statistics group name CGF

Solução

Método de Procedimento (MOP) para limpar os CDRs que pertencem ao grupo padrão no processo aaaproxy.

Etapa 1. Anote os CDRs arquivados. Mostrar todos os contadores gtpp

Etapa 2. Configurar o modo para local em gaggsnctx config context gaggsnctx gtpp group default gtpp storage-server mode local

Etapa 3. Por favor, mate aaaproxy usando este comando no modo oculto. task kill facility aaaproxy all. (A tarefa de eliminação fará com que o modo local seja aplicado ao grupo predefinido.)

Etapa 4. Saia do modo oculto

Etapa 5. Marque show gtpp storage-server local file statistics está aumentando.

Etapa 6. Execute show gtpp counters todos a cada 30 segundos. Isso deve descer para zero em 5 minutos.

Passo 7. Reverta o modo para remoto. config context gaggsnctx gtpp group default gtpp storage-server mode remote

Etapa 8. Verifique se o contador arquivado (show gtpp counters all) não está aumentando e show gtpp storage-server local file statistics não está aumentando.

Etapa 9. Pegue a SSD e envie-a de volta para nós para verificar se a configuração está intacta e se todas as etapas foram seguidas.

Note: Após a conclusão da atividade, se você souber o procedimento para remover arquivos CDR do HDD. Vá em frente. (caso contrário, entre em contato com o engenheiro do TAC para esta atividade em outro dia)

Se aaaproxy não recuperar após 1 minuto, consulte o procedimento de recuperação.

Procedimento de recuperação de aaaproxy

a. Issue the command to check which controller takes care of aaaproxy task
show task table | grep aaaproxy


       task                           Parent
cpu facility   inst   pid pri   facility      inst pid
---- --------------- --------      -------       ---- ---
4/0 aaaproxy  1 6721  0  sessctrl      0 10565



b. Please execute the below commands and look out for instance of sessctrl on Active SMC

#Show task table | grep sessctrl

     Task                     parent
cpu facility inst pid pri facility inst pid
---- ------------------------------- --- ----------------------------
8/0 sessctrl 0 10565 -4 sitparent 80 2812

c. Issue the sessctrl instance kill command
Task kill facility sessctrl instance <>.

d. After the execution of command, wait for 30 secs and issue the commands to check state of sessctrl and aaaproxy

1. Show task table | grep "8/0 sessctrl"
2. Show task resources | grep aaaproxy

Explicação técnica

Devido a vários motivos (provavelmente configurações incorretas) para alguns APNs , os CDRs vão para o grupo padrão. No grupo padrão, você não tem servidores CGF configurados e, portanto, as solicitações ficam travadas. Para os APNs para os quais há um grupo gtpp válido configurado , os CDRs não devem ser arquivados, mas podem ir para a fila de arquivamento.

Na fila de arquivamento, você pode processar apenas cinco solicitações de cada vez. Caso todas as cinco solicitações pertençam aos APNs que apresentam erro de configuração, as cinco principais solicitações nunca são liberadas, bloqueando assim todos os CDRs atrás da fila. Isso significa que os CDRs gerados em um mês específico estão presos e processados incorretamente.

O ASR5x00 tem um limite superior de quantos CDRs podem ser arquivados. Quando o limite é ultrapassado, os CDRs arquivados são eliminados. Isso abre caminho para os CDRs válidos gerados em um mês específico e eles são liberados. 

Por exemplo,

Se a fila tiver cinco solicitações e o restante das solicitações pertencer ao APN válido com a configuração correta e quando você processar, todas as vezes que as cinco solicitações nunca forem liberadas, pois não há servidor configurado e você fica preso para sempre, pois processa apenas cinco CDRs de cada vez. No entanto, se uma das solicitações for removida, isso significa que você tem 4 solicitações pertencentes ao APN de configuração inválida e a próxima é um APN válido. Agora, quando você processa cinco solicitações, as quatro estão travadas, mas a quinta está processada agora. Dessa forma, você verá CDRs antigos enviados para o CGF como CGF processariam CDRs do mês de dezembro em janeiro, porque eles são lançados tarde pela GGSN.

Por que os CDRs para o grupo correto são enviados para a fila de arquivamento: o pacote máximo que pode ser transmitido no User Datagram Protocol (UDP) é 64K incluindo o cabeçalho. Agora, como configuramos max-cdrs 255 wait-time 60, há uma chance de o buffer de 64 K estar cheio antes de o máximo de 255 CDRs ser alcançado. O sistema verificará se o novo CDR pode caber no Buffer de 64K ou não. Caso contrário, o sistema os colocará de volta na fila de arquivamento. Este CDR recolocou na fila de arquivamento presa por um mês até que os CDRs para grupo inválido sejam eliminados. Se houvesse uma configuração correta, a fila de arquivamento nunca tinha os CDRs para os APNs que não têm servidores e esse problema nunca teria sido visto porque mesmo que o CDR entre na fila de arquivamento ele teria sido processado.

Lógica

Você está matando aaaproxy e alterando o modo local do servidor de armazenamento gtpp, de modo que os CDRs travados sejam enviados para o disco rígido local e evitarão a limpeza dos CDRs quando os limites forem alcançados por aaamgr. Quando todos os CDRs forem gravados no disco rígido local, você poderá voltar para o modo remoto, que é o padrão.