ASR5x00 : CDR obsolètes envoyés à CGF en raison d'une configuration incorrecte dans les APN

Introduction

Ce document décrit un scénario spécifique dans lequel les enregistrements de données d'appel (G-CDR) du noeud de prise en charge GGSN (Gateway-Gprs Support Node) sont bloqués en raison d'une mauvaise configuration dans le nom de point d'accès (APN) entraîne une mauvaise facturation pour les abonnés et la fonction CGF (Charging Gateway Function) reçoit des CDR obsolètes qui sont bloqués dans le GGSN. Ce problème est signalé dans les routeurs à services intégrés Cisco ASR (Aggregrated Service Routers) de la gamme 5x00.

Problème

En raison de diverses raisons (probablement des erreurs de configuration) pour certains APN, les CDR passent au groupe par défaut. Dans le groupe par défaut, nous n'avons pas de serveurs CGF configurés et donc les requêtes sont bloquées.

 par exemple :

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

Dépannage

Dans la sortie Afficher les détails du support, vérifiez la sortie de la commande

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

Le compte aaa actuel archivé montre que 6 millions de CDR sont bloqués dans toutes les aaamgrs et en raison de quoi aucun nouveau CDR n'est traité et transféré à CGF en mode streaming.

Une fois la limite atteinte par aamgr, les CDR sont purgés et entraînent une perte de CDR et de revenus pour le client.

sur les 6 millions de CDR archivés, vous voyez que certains CDR sont purgés

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

Voici les listes de contrôle des commandes CLI couramment utilisées pour déboguer les problèmes liés au 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

Solution

Méthode de procédure (MOP) pour nettoyer les CDR qui appartiennent au groupe par défaut dans un processus proxy.

Étape 1. Notez les CDR archivés. Afficher tous les compteurs gtpp

Étape 2. Configurez le mode sur local dans gaggsnctx config context gaggsnctx gtpp group default gtpp storage-server mode local

Étape 3. Exécutez aaproxy à l'aide de cette commande en mode masqué. task kill installation aaproxy all. (L'arrêt de la tâche rendra le mode local à appliquer au groupe par défaut.)

Étape 4. Sortir du mode masqué

Étape 5. Cochez la case show gtpp storage-server local file statistics .

Étape 6. Exécutez show gtpp counters all all 30 sec. Cela devrait descendre à zéro en 5 minutes.

Étape 7. Rétablissez le mode à distance. config context gaggsnctx gtpp group default gtpp storage-server mode remote

Étape 8. Vérifiez que le compteur archivé (show gtpp counters all) n'augmente pas et que show gtpp storage-server local file statistics n'augmente pas.

Étape 9. Prenez le SSD et renvoyez-nous pour vérification afin de vous assurer que la configuration est intacte et que toutes les étapes sont suivies.

Note: Une fois l'exercice terminé, si vous connaissez la procédure à suivre pour supprimer des fichiers CDR du disque dur. Vas-y. (si ce n'est pas le cas, contactez l'ingénieur TAC pour cette activité un autre jour)

Si un proxy ne récupère pas après 1 minute, reportez-vous à la procédure de récupération.

Procédure de récupération d'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

Explication technique

En raison de diverses raisons (probablement des erreurs de configuration) pour certains APN, les CDR vont au groupe par défaut. Dans le groupe par défaut, vous n'avez pas de serveurs CGF configurés et par conséquent les requêtes sont bloquées. Pour les APN pour lesquels un groupe gtpp valide est configuré , les CDR ne doivent pas être archivés, mais ils peuvent aller dans la file d'attente d'archivage.

Dans la file d'attente d'archivage, vous ne pouvez traiter que cinq demandes à la fois. Si les cinq demandes appartiennent aux APN qui ne sont pas correctement configurées, les cinq principales demandes ne sont jamais libérées, bloquant ainsi tous les CDR derrière la file d'attente. Cela signifie que les CDR générés sur un mois spécifique sont bloqués et traités de manière incorrecte.

ASR5x00 a une limite supérieure pour le nombre de CDR pouvant être archivés. Une fois la limite franchie, les CDR archivés sont purgés. Cela laisse place aux CDR valides générés sur un mois spécifique et ils sont libérés. 

Exemple :

Si la file d'attente a cinq demandes et que le reste des demandes appartient à l'APN valide avec une configuration correcte et lorsque vous traitez, chaque fois que les cinq demandes ne sont jamais libérées car aucun serveur n'est configuré et que vous êtes bloqué à tout moment lorsque vous traitez seulement cinq CDR à la fois. Cependant, si une des requêtes est purgée, cela signifie que vous avez 4 requêtes appartenant à l'APN de configuration non valide et la suivante est APN valide. Maintenant, lorsque vous traitez cinq demandes, les quatre demandes sont bloquées, mais la cinquième est traitée maintenant. De cette façon, vous verrez les anciens CDR envoyés à CGF comme CGF serait le processus décembre mois CDR en janvier parce qu'ils sont publiés en retard par GGSN.

Pourquoi les CDR du groupe correct sont envoyés à la file d'attente d'archivage : le paquet maximal qui peut être transmis dans le protocole UDP (User Datagram Protocol (UDP) est de 64 K, y compris l'en-tête. Maintenant que nous avons configuré max-cdrs 255 wait-time 60, il y a une chance que la mémoire tampon de 64 K soit pleine avant que le maximum de 255 CDR soit atteint. Le système vérifiera si le nouveau CDR peut s'insérer dans la mémoire tampon 64K ou non. Si ce n'est pas le cas, le système va les remettre dans la file d'attente d'archivage. Ce CDR a été remis dans la file d'attente d'archivage bloquée pendant un mois jusqu'à ce que les CDR pour le groupe non valide soient purgés. S'il y avait eu une configuration correcte, alors la file d'attente d'archivage n'a jamais eu les CDR pour les APN qui n'ont pas de serveurs et ce problème n'aurait jamais été détecté car même si CDR entre dans la file d'attente d'archivage, il aurait été traité.

Logique

Vous supprimez un proxy et changez le mode de serveur de stockage gtpp local, donc les CDR bloqués sont poussés sur le disque dur local et éviteront de purger les CDR une fois les limites atteintes par aamgr. Une fois que tous les CDR sont écrits sur le disque dur local, vous pouvez revenir au mode distant qui est le mode par défaut.