ASR5x00: CDR atrasados enviados a CGF debido a configuración incorrecta en APN

Introducción

Este documento describe un escenario específico en el que los registros de datos de llamadas (G-CDR) del nodo de soporte de GGprs (GGSN) se atascan debido a una configuración incorrecta en el nombre del punto de acceso (APN), lo que da lugar a una facturación incorrecta para los suscriptores y la función de gateway de carga (CGF) recibe CDR atrasados que se atascan en GGSN. Este problema se informa en los routers de servicios agregados (ASR) de Cisco serie 5x00.

Problema

Debido a varias razones (muy probablemente configuraciones erróneas) para algunos APN , los CDR van al grupo predeterminado. En el grupo predeterminado, no tenemos servidores CGF configurados y, por lo tanto, las solicitudes se atascan.

 por ejemplo:

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

En la salida Mostrar detalles de soporte, verifique la salida del 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

La cuenta aaa actual archivada muestra que 6 millones de CDR están atascados en todos los mapeos y debido a lo cual no se procesan nuevos CDR y se transfieren a CGF en modo de transmisión.

Una vez que se alcanza el límite por administrador, se depuran los CDR y se produce la pérdida de los CDR y la pérdida de ingresos para el cliente.

de los 6 millones de CDR archivados , verá algunos CDR purgados

******** 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

Estas son las listas de verificación de los comandos CLI que se utilizan habitualmente para depurar problemas relacionados con 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

Solución

Método de procedimiento (MOP) para limpiar los CDR que pertenecen al grupo Predeterminado en un proceso proxy.

Paso 1. Anote los CDR archivados. Show gtpp counters all

Paso 2. Configure el modo a local en gaggsnctx config context gaggsnctx gtpp group default gtpp storage-server mode local

Paso 3. Por favor, elimine un proxy utilizando este comando en modo oculto. función kill feature aaaproxy all. (La eliminación de tareas hará que el modo local se aplique al grupo predeterminado.)

Paso 4. Salir del modo oculto

Paso 5. Verifique que show gtpp storage-server local file statistics esté aumentando.

Paso 6. Ejecute show gtpp counters all cada 30 segundos. Esto debe reducirse a cero en un lapso de 5 minutos.

Paso 7. Revertir el modo a remoto. config context gaggsnctx gtpp group default gtpp storage-server mode remote

Paso 8. Verifique que el contador archivado (show gtpp counters all) no esté aumentando y show gtpp storage-server local file statistics no está aumentando.

Paso 9. Tome la SSD y envíelo de vuelta para verificarlo para asegurarse de que la configuración está intacta y se siguen todos los pasos.

Nota: Una vez finalizada la actividad, si conoce el procedimiento para quitar los archivos CDR de HDD. Adelante. (si no es así, póngase en contacto con el ingeniero del TAC para realizar esta actividad algún otro día)

Si un proxy no se recupera después de 1 minuto, consulte el procedimiento de recuperación.

Procedimiento para recuperar un proxy

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

Explicación técnica

Debido a varias razones (muy probablemente configuraciones erróneas) para algunos APN , los CDR van al grupo predeterminado. En el grupo predeterminado, no tiene servidores CGF configurados y, por lo tanto, las solicitudes se atascan. Para los APN para los que hay un grupo gtpp válido configurado , los CDR no deben ser archivados, pero pueden ir a la cola de archiving.

Desde la cola de archivo sólo puede procesar cinco solicitudes a la vez. En el caso de que las cinco solicitudes pertenezcan a las APN cuya configuración incorrecta, las cinco solicitudes principales nunca se liberan, bloqueando así todos los CDR detrás de la cola. Esto significa que los CDR generados en un mes específico se atascan ahí y se procesan erróneamente.

ASR5x00 tiene un límite superior a la cantidad de CDR que se pueden archivar. Una vez que se supera el límite, se depuran los CDR archivados. Esto da paso a los CDR válidos generados en un mes específico y se liberan. 

Por ejemplo,

Si la cola tiene cinco solicitudes y el resto de ellas pertenecen al APN válido con la configuración correcta y cuando procesa, cada vez que las cinco solicitudes nunca se liberan, ya que no hay ningún servidor configurado y está atascado para siempre mientras procesa sólo cinco CDR a la vez. Sin embargo, si se depura una de las solicitudes, esto significa que tiene 4 solicitudes que pertenecen a la configuración APN no válida y la siguiente es una APN válida. Ahora, cuando procesa cinco solicitudes, las cuatro se atascan, pero la quinta se procesa ahora. De esta manera, verá los CDR antiguos enviados a CGF como CGF serían CDR del mes de diciembre en enero porque GGSN los libera tarde.

Por qué se envían los CDR para el grupo correcto a la cola de archivo: el paquete máximo que se puede transmitir en el protocolo de datagramas de usuario (UDP) es de 64K incluyendo el encabezado. Ahora que configuramos max-cdrs 255 wait-time 60, existe la posibilidad de que el búfer de 64 K esté lleno antes de alcanzar el máximo de 255 CDR. El sistema comprobará si el nuevo CDR puede caber en el búfer de 64K o no. Si no, el sistema los pondrá de nuevo en la cola de almacenamiento. Este CDR vuelve a poner en la cola de archivo durante un mes hasta que se depuren los CDR para el grupo no válido. Si hubiera habido una configuración correcta, entonces la cola de archivo nunca tuvo los CDR para esas APN que no tienen servidores y este problema nunca se habría visto porque, incluso si CDR ingresa en la cola de archivo, se habría procesado.

Lógica

Está eliminando un proxy y cambiando el modo de servidor de almacenamiento gtpp local, de modo que los CDRs atascados se transfieren al disco duro local y evitarán la purga de los CDR una vez que se alcancen los límites por amgr. Una vez que todos los CDR se escriben en el disco duro local , puede volver al modo remoto que es el predeterminado.