ASR5x00: CDR antedatados que estão sendo enviados ao CGF devido a Misconfig em APNs

Introdução

Este documento descreve a encenação específica onde os registros de dados de chamada do Gateway GPRS Support Node (GGSN) (G-CDR) são devidos colado lesar a configuração em resultados de Name(APN) do Access point no faturamento errado para assinantes e o gateway de carregamento Function(CGF) recebem os CDR antedatados que são colados no GGSN. Esta edição é relatada no 5x00 Series do Roteadores do serviço de Cisco Aggregrated (ASR).

Problema

Devido às várias razões (o mais provavelmente configurações incorretas) para algum APNs, os CDR vão ao grupo padrão. No grupo padrão, nós não temos server CGF configurados e daqui os pedidos para obter colados.

 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

Troubleshooting

Na mostra o apoio detalha a saída, verifica para ver se há 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

As mostras arquivadas 6 milhão CDR aaa acct atual são coladas em todos os aaamgrs e devido a qual nenhum CDR novo obtém processado e transferido ao CGF no modo de fluência.

Uma vez que o limite é alcançado pelo aaamgr, os CDR estão removidos e resultados na perda de CDR e na perda do rendimento ao cliente.

fora de 6 milhão CDR arquivado, você vê alguns CDR que estão 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

Estão aqui as listas de verificação dos comandos CLI de uso geral para debugar problemas relacionados 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 Procedure(MOP) para limpar os CDR que pertencem ao grupo padrão no processo do aaaproxy.

Etapa 1. Note abaixo dos CDR arquivados. Mostre que o gtpp opõe tudo

Etapa 2. Configurar o modo ao local no local do modo de armazenamento-server do gtpp do padrão do grupo do gtpp do gaggsnctx do contexto da configuração do gaggsnctx

Etapa 3. Mate por favor o aaaproxy usando este comando hidden no modo. encarregue o aaaproxy todo da facilidade da matança. (A matança da tarefa fará o modo local a ser aplicado ao grupo padrão.)

Etapa 4. Modo hidden saído

Etapa 5. As estatísticas do arquivo local do armazenamento-server do gtpp da mostra da verificação estão aumentando.

Etapa 6. Execute o gtpp da mostra opõe todos cada 30 segundos. Isto deve vir para baixo zerar dentro um período dos minutos 5.

Etapa 7. Reverta o modo ao telecontrole. telecontrole do modo de armazenamento-server do gtpp do padrão do grupo do gtpp do gaggsnctx do contexto da configuração

Etapa 8. Verifique o contador arquivado (o gtpp da mostra opõe tudo) não está aumentando e as estatísticas do arquivo local do armazenamento-server do gtpp da mostra não estão aumentando.

Etapa 9. Tome o SSD e envie-nos para trás para que a verificação certifique-se de que a configuração é intacto e todas as etapas estão seguidas.

Nota: Após conclusão da atividade, se você conhece o procedimento para remover os arquivos CDR do HDD. Vá adiante. (se não, contrate por favor o coordenador TAC para esta atividade algum outro dia)

Se o aaaproxy não faz recuperação após 1 minuto, para consultar o procedimento de recuperação.

Procedimento a recuperar do 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 às várias razões (o mais provavelmente configurações incorretas) para algum APNs, os CDR vão ao grupo padrão. No grupo padrão, você não tem server CGF configurados e daqui os pedidos para obter colado. Para o APNs para que há um grupo válido do gtpp configurado, os CDR não devem ser arquivados mas podem ir à fila do arquivo.

Da fila do arquivo você pode somente processar cinco pedidos de cada vez. Caso que se todos os cinco pedidos pertencem ao APNs que o misconfiguration cobre então cinco pedidos são livrados nunca assim obstruindo todos os CDR atrás da fila. Isto significa que os CDR gerados no mês específico estão colados lá e processados errada.

ASR5x00 tem um limite superior quantos CDR podem ser arquivados. Uma vez que o limite é cruzado os CDR arquivados obtêm removidos. Isto faz a maneira para os CDR válidos gerados em um mês específico e obtêm liberados. 

Por exemplo,

Se a fila tem cinco pedidos e o resto dos pedidos está pertencendo ao APN válido com configuração correta e quando você processo, cada vez que os cinco pedidos nunca obtêm livrados porque não há nenhum server configurado e você está colado para sempre enquanto você processa somente cinco CDR de cada vez. Contudo se um dos pedidos obtém removido, isto significa que você tem 4 pedidos que pertencem à configuração inválida APN e em seguida um é APN válido. Agora em que você processa cinco pede os quatro pedidos é colado mas um é processado fifth agora. Desta maneira, você verá que os CDR velhos enviados ao CGF como o CGF seriam o mês CDR de dezembro do processo em janeiro porque são liberados tarde pelo GGSN.

Porque os CDR para o grupo correto são enviados para arquivar a fila:  O pacote máximo que pode ser transmitido no User Datagram Protocol (UDP) é 64K que inclui o encabeçamento. Agora desde que nós configuramos MAX-CDR 255 o tempo de espera 60, está um buffer da possibilidade 64 K está completo antes que máximo 255 CDR é alcançado. O sistema verificará se o CDR novo possa caber no buffer 64K ou não. Se não o sistema po-los-á de volta à fila do arquivo. Este CDR posto de volta à fila do arquivo colada para um mês até os CDR para o grupo inválido é removido. Se haveria uma configuração correta, a seguir a fila do arquivo nunca teve os CDR para aqueles APNs que não tem server e esta edição nunca consideraria porque mesmo se o CDR participa na fila do arquivo seria processada.

Lógica

Você está matando o aaaproxy e o local em mudança do modo de armazenamento-server do gtpp, assim que os CDR colados estão empurrados para o disco duro local e evitarão remover dos CDR uma vez que os limites são alcançados pelo aaamgr. Uma vez que todos os CDR obtêm escritos ao disco duro local, você pode mudar de volta ao modo remoto que é o padrão um.