ASR5x00: Backdated CDRs werden aufgrund von Fehlkonfigurationen in APNs an CGF gesendet

Einführung

In diesem Dokument wird ein bestimmtes Szenario beschrieben, in dem Gateway-GPRS Support Node (GGSN) Call Data Records (G-CDRs) aufgrund falscher Konfiguration im Access Point Name (APN) blockiert werden, was zu falschen Abrechnungen für Teilnehmer führt und die Charging Gateway Function (CGF) veraltete CDRs empfängt, die in GGSN stecken. Dieses Problem wird bei Cisco Aggregated Service Routern (ASR) der Serie 5x00 gemeldet.

Problem

Aus verschiedenen Gründen (meist Fehlkonfigurationen) für einige APNs gehen CDRs zur Standardgruppe. In der Standardgruppe sind keine CGF-Server konfiguriert, und die Anfragen bleiben somit hängen.

 Beispiel:

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

Fehlerbehebung

Suchen Sie unter Show support details output (Support-Details anzeigen) nach der Befehlsausgabe.

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

Aktuell archivierte AAA-Konten zeigen, dass 6 Millionen CDRs in allen Räumen stecken und deshalb keine neuen CDRs verarbeitet und im Streaming-Modus an CGF übertragen werden.

Sobald das Limit pro Agent erreicht ist, werden CDRs gelöscht und führen zum Verlust von CDRs und Umsatzverlusten für den Kunden.

von 6 Millionen archivierten CDRs sehen Sie, wie einige CDRs gelöscht werden.

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

Nachfolgend finden Sie die Checklisten der CLI-Befehle, die häufig zum Debuggen von CDR-bezogenen Problemen verwendet werden.

- 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

Lösung

Method of Procedure (MOP) to clean up the CDRs that gehören to Default group in aProxy process

Schritt 1: Notieren Sie sich die archivierten CDRs. GTPP-Zähler für alle anzeigen

Schritt 2: Konfigurieren Sie den Modus in gaggsnctx config context gaggsnctx gtpp group default gtpp storage-server mode local.

Schritt 3: Beenden Sie aaproxy mit diesem Befehl im ausgeblendeten Modus. Task kill Facility aaaproxy all. (Task kill bewirkt, dass der lokale Modus auf die Standardgruppe angewendet wird.)

Schritt 4: Aus dem versteckten Modus heraus

Schritt 5: Check show gtpp storage-server local file statistics is increase.

Schritt 6: Führen Sie alle 30 Sekunden show gtpp-Zähler aus. Dies sollte innerhalb von 5 Minuten auf Null sinken.

Schritt 7: Den Modus in Remote umkehren. config context gaggsnctx gtpp group default gtpp storage-server mode remote

Schritt 8: Überprüfen Sie, dass der archivierte Zähler (show gtpp counter all) nicht zunimmt und die lokale Dateistatistik des gtpp-Speicherservers nicht zunimmt.

Schritt 9: Nehmen Sie die SSD, und senden Sie sie zur Überprüfung zurück, um sicherzustellen, dass die Konfiguration intakt ist und alle Schritte befolgt werden.

Hinweis: Nach Abschluss der Aktivität, wenn Sie wissen, das Verfahren, um CDR-Dateien von HDD zu entfernen. Mach weiter. (Falls nicht, wenden Sie sich für diese Aktivität an den TAC-Techniker eines anderen Tages.)

Wenn ein Proxy nach 1 Minute nicht wiederhergestellt wird, verweisen Sie auf das Wiederherstellungsverfahren.

Verfahren zur Wiederherstellung von aaproxy

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

Technische Erklärung

Aus verschiedenen Gründen (meist Fehlkonfigurationen) für einige APNs gehen CDRs zur Standard-Gruppe. In der Standardgruppe sind keine CGF-Server konfiguriert, sodass die Anfragen nicht mehr bearbeitet werden. Für die APNs, für die eine gültige gtpp-Gruppe konfiguriert ist, sollten CDRs nicht archiviert werden, sondern können in die Archivwarteschlange gestellt werden.

Aus der Archivwarteschlange können Sie nur fünf Anfragen gleichzeitig bearbeiten. Wenn alle fünf Anfragen zu den APNs gehören, die falsch konfiguriert sind, werden die fünf häufigsten Anfragen niemals freigegeben, sodass alle CDRs hinter der Warteschlange blockiert werden. Dies bedeutet, dass die in einem bestimmten Monat generierten CDRs dort feststecken und falsch verarbeitet werden.

ASR5x00 hat eine Obergrenze für die Anzahl der CDRs, die archiviert werden können. Sobald die Grenze überschritten ist, werden die archivierten CDRs gelöscht. Dadurch werden die gültigen CDRs, die für einen bestimmten Monat generiert werden, ersetzt und freigegeben. 

Beispiel:

Wenn die Warteschlange fünf Anfragen umfasst und die übrigen Anforderungen mit der richtigen Konfiguration zum gültigen APN gehören, werden die fünf Anfragen immer dann freigegeben, wenn kein Server konfiguriert ist und Sie für immer festsitzen, da Sie jeweils nur fünf CDRs verarbeiten. Wenn jedoch eine der Anfragen gelöscht wird, bedeutet dies, dass Sie 4 Anfragen haben, die zur ungültigen Konfiguration von APN gehören, und dass die nächste eine gültige APN ist. Wenn Sie jetzt fünf Anfragen bearbeiten, sind die vier Anfragen blockiert, aber die fünfte wird jetzt bearbeitet. Auf diese Weise werden alte CDRs an CGF gesendet, wie CGF CDRs im Dez-Monat im Januar verarbeiten würde, da sie erst spät von GGSN veröffentlicht werden.

Warum die CDRs für die richtige Gruppe an die Archiv-Warteschlange gesendet werden: Das maximal in User Datagram Protocol (UDP) übertragene Paket beträgt 64 K einschließlich Header. Seit wir max-cdrs 255 Wartezeiten 60 konfiguriert haben, ist ein 64-K-Puffer voll, bevor maximal 255 CDRs erreicht werden. Das System prüft, ob neue CDRs in den 64K-Puffer passen. Wenn dies nicht der Fall ist, setzt das System sie wieder in die Archiv-Warteschlange. Dieser CDR wird einen Monat lang in die Archiv-Warteschlange gesteckt, bis die CDRs für ungültige Gruppen gelöscht werden. Hätte es die richtige Konfiguration gegeben, so hätte die Archivwarteschlange die CDRs für jene APNs, die keine Server haben, nie erhalten, und dieses Problem wäre nie aufgetreten, weil CDRs selbst dann in die Archivwarteschlange gestellt worden wäre, wenn sie verarbeitet worden wären.

Logik

Sie töten aaproxy und ändern den gtpp-Speicher-Server-Modus lokal, sodass die CDRs hängen bleiben auf lokale Festplatte und vermeiden das Löschen der CDRs, sobald die Grenzwerte pro AMAGR erreicht sind. Sobald alle CDRs auf lokale Festplatte geschrieben wurden, können Sie wieder in den Remote-Modus wechseln, der den Standardmodus ist.