ASR5x00: CDR retrodatati inviati a CGF a causa di una configurazione errata nei nomi dei punti di accesso

Introduzione

In questo documento viene descritto uno scenario specifico in cui i record G-CDR (Call Data Records) del nodo di supporto GPRS del gateway sono bloccati a causa di una configurazione errata in Nome punto di accesso (APN), causando una fatturazione errata per i sottoscrittori e la funzione CGF (Charging Gateway Function) riceve i record CDR retrodatati bloccati in GSN. Il problema è segnalato nei Cisco Aggregated Service Router (ASR) serie 5x00.

Problema

A causa di vari motivi (con ogni probabilità errori di configurazione) per alcuni numeri APN, i CDR passano al gruppo predefinito. Nel gruppo predefinito non sono configurati server CGF e pertanto le richieste risultano bloccate.

 ad esempio:

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

Risoluzione dei problemi

In Show support details output, verificare la presenza dell'output 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

L'attuale account aaa archiviato mostra che 6 milioni di CDR sono bloccati in tutti gli album e a causa di questo nessun nuovo CDR viene elaborato e trasferito a CGF in modalità streaming.

Una volta raggiunto il limite per amministratore, le registrazioni CDR vengono eliminate e il cliente perde le registrazioni CDR e i ricavi.

su 6 milioni di CDR archiviati, alcuni vengono eliminati

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

Di seguito sono riportati gli elenchi di controllo dei comandi CLI comunemente utilizzati per eseguire il debug dei problemi relativi a 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

Soluzione

Metodo di procedura (MOP) per pulire i CDR appartenenti al gruppo predefinito in un processo proxy.

Passaggio 1. Annotare i CDR archiviati. Mostra tutti i contatori gtpp

Passaggio 2. Configurare la modalità su locale nel contesto di configurazione gaggsnctx gtpp gruppo gtpp predefinito modalità server di archiviazione gtpp locale

Passaggio 3. Terminare aaproxy utilizzando questo comando in modalità nascosta. task kill facility aaproxy all. La terminazione dell'attività determina l'applicazione della modalità locale al gruppo predefinito.

Passaggio 4. Uscire dalla modalità nascosta

Passaggio 5. Selezionare show gtpp storage-server local file statistics is crescent.

Passaggio 6. Eseguire show gtpp counters ogni 30 secondi. Questo valore dovrebbe scendere a zero in un intervallo di 5 minuti.

Passaggio 7. Ripristinare la modalità remota. config context gaggsnctx gtpp gruppo gtpp predefinito modalità server-archiviazione remota

Passaggio 8. Verificare che il contatore archiviato (show gtpp counters all) non sia in aumento e che le statistiche dei file locali del server di archiviazione gtpp non siano in aumento.

Passaggio 9. Portare l'SSD e inviarlo per la verifica per accertarsi che la configurazione sia intatta e che tutti i passaggi siano stati seguiti.

Nota: Dopo il completamento dell'attività, se si conosce la procedura per rimuovere i file CDR dal disco rigido. Vai avanti. (in caso contrario, rivolgersi al tecnico TAC per questa attività un giorno diverso)

Se il ripristino di un proxy non avviene dopo 1 minuto, consultare la procedura di ripristino.

Procedura di recupero di 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

Spiegazione tecnica

A causa di vari motivi (con ogni probabilità errori di configurazione) per alcuni numeri APN, i CDR passano al gruppo predefinito. Nel gruppo predefinito non sono configurati server CGF e pertanto le richieste risultano bloccate. Per i nomi APN per i quali è configurato un gruppo gtpp valido, i record CDR non devono essere archiviati, ma possono andare alla coda di archiviazione.

Dalla coda di archiviazione è possibile elaborare solo cinque richieste alla volta. Nel caso in cui tutte e cinque le richieste appartengano ai numeri APN che hanno una configurazione errata, le prime cinque richieste non vengono mai liberate, bloccando così tutti i numeri CDR dietro la coda. Ciò significa che i CDR generati in un mese specifico sono bloccati lì ed elaborati in modo errato.

ASR5x00 ha un limite superiore per il numero di CDR che possono essere archiviati. Una volta superato il limite, i CDR archiviati vengono eliminati. In questo modo viene annullata la registrazione dettagli chiamata valida generata in un mese specifico e i record vengono rilasciati. 

Ad esempio,

Se la coda ha cinque richieste e il resto delle richieste appartiene all'APN valido con la configurazione corretta e durante l'elaborazione, ogni volta che le cinque richieste non vengono mai liberate in quanto non è configurato alcun server e si rimane bloccati per sempre mentre si elaborano solo cinque CDR alla volta. Tuttavia, se una delle richieste viene eliminata, significa che sono presenti 4 richieste appartenenti all'APN di configurazione non valido e che l'APN successivo è valido. Quando si elaborano cinque richieste, le quattro richieste sono bloccate, ma la quinta viene elaborata ora. In questo modo, si vedranno i vecchi CDR inviati a CGF come CGF sarebbe elaborare i CDR del mese di dicembre in gennaio perché sono rilasciati in ritardo da GSN.

Perché i CDR per il gruppo corretto vengono inviati alla coda di archiviazione:  Il pacchetto massimo che può essere trasmesso nel protocollo UDP (User Datagram Protocol) è 64.000 (intestazione inclusa). Ora, poiché abbiamo configurato max-cdrs 255 tempo di attesa 60, è possibile che il buffer da 64 K sia pieno prima che venga raggiunto il limite massimo di 255 CDR. Il sistema verificherà se il nuovo CDR può essere inserito nel buffer a 64K. In caso contrario, il sistema li riporta nella coda di archiviazione. Questo CDR viene reinserito nella coda di archiviazione bloccata per un mese finché non vengono eliminati i CDR per i gruppi non validi. Se ci fosse stata una configurazione corretta, la coda dell'archivio non ha mai avuto i CDR per quei numeri APN che non hanno server e questo problema non si sarebbe mai visto perché anche se CDR entrasse nella coda dell'archivio sarebbe stato elaborato.

Logica

Si sta eliminando aaproxy e si sta modificando la modalità server di archiviazione gtpp locale, in modo che i CDR bloccati vengano spostati sull'hard disk locale ed eviteranno l'eliminazione dei CDR una volta raggiunti i limiti per amgr. Una volta che tutti i CDR sono stati scritti sull'hard disk locale, è possibile tornare alla modalità remota che è quella predefinita.