ASR5x00：APNsの設定ミスが原因でCGFに送信される古いCDR

概要

このドキュメントでは、アクセスポイント名(APN)の誤った設定が原因でGateway-Gprs Support Node(GGSN)のコールデータレコード(G-CDR)がスタックし、サブスクライバの課金が誤り、Charging Gateway Function(CGF)がGSNでにこの問題は、Cisco Aggregated Service(ASR)5x00シリーズで報告されています。

問題

一部のAPNの原因（ほとんどの場合の設定ミス）が異なるため、CDRはデフォルトグループに移動します。デフォルトグループでは、CGFサーバが設定されていないため、要求がスタックします。

 たとえば、次のコマンドを入力します。

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

トラブルシュート

Show support detailsの出力で、コマンドの出力を確認します

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

現在のaaa acct archivedは、600万個のCDRがすべてのaamgrsにスタックし、そのため新しいCDRは処理されず、ストリーミングモードでCGFに転送されません。

アラームごとに制限に達すると、CDRが消去され、CDRが失われ、お客様の収益が失われます。

アーカイブされた600万件のCDRのうち、一部のCDRがパージされています

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

CDR関連の問題のデバッグに一般的に使用されるCLIコマンドのチェックリストを次に示します。

- 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

解決方法

aaaproxyプロセスでデフォルトグループに属するCDRをクリーンアップするためのMethod of Procedure(MOP)。

ステップ1：アーカイブされたCDRをメモします。Show gtpp counters all

ステップ2:gaggsnctx config context gaggsnctx gtpp group default gtpp storage-server mode localでモードをlocalに設定します

ステップ3：隠しモードでこのコマンドを使用してaaproxyを強制終了してください。task kill facility aaaproxy all。（タスクの強制終了により、ローカルモードがデフォルトグループに適用されます）。

ステップ4：非表示モードを終了する

ステップ5:show gtpp storage-server local file statistics is increasingを確認します。

ステップ6:30秒ごとにshow gtpp countersを実行します。これは5分間の間にゼロに下がります。

ステップ7：モードをリモートに戻します。config context gaggsnctx gtpp group default gtpp storage-server mode remote

ステップ8：アーカイブされたカウンタ(show gtpp counters all)が増加していないこと、およびshow gtpp storage-server local file statisticsが増加していないことを確認します。

ステップ9:SSDを取り出して確認のために私たちに送り返し、設定が正常で、すべてのステップが実行されていることを確認します。

注：課題が完了したら、HDDからCDRファイルを削除する手順がわかっている場合。どうぞ。（そうでない場合は、このアクティビティに関してTACエンジニアに連絡してください）

aaaproxyが1分後に回復しない場合は、回復手順を参照してください。

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

技術的な説明

いくつかのAPNの原因（ほとんどの場合、設定ミス）により、CDRはデフォルトグループに移動します。デフォルトグループでは、CGFサーバが設定されていないため、要求がスタックします。有効なgtppグループが設定されているAPNの場合、CDRはアーカイブされませんが、アーカイブキューに移動する場合があります。

アーカイブキューから一度に処理できる要求は5つだけです。設定が誤っているAPNに5つの要求すべてが属している場合、上位5つの要求が解放されないため、キューの背後にあるすべてのCDRがブロックされます。これは、特定の月に生成されたCDRがそこに留まり、誤って処理されることを意味します。

ASR5x00には、アーカイブ可能なCDRの数に上限があります。制限を超えると、アーカイブされたCDRがパージされます。これにより、特定の月に生成された有効なCDRが有効になり、リリースされます。 

たとえば、

キューに5つの要求があり、残りの要求が正しい設定で有効なAPNに属している場合、および処理するたびに、サーバが設定されていないため、5つの要求が解放されず、一度に5つのCDRしか処理しないため、永久に停止します。ただし、いずれかの要求がパージされた場合、無効な構成APNに属する4つの要求があり、次の1つは有効なAPNであることを意味します。5つの要求を処理すると、4つの要求はスタックしますが、5番目の要求は処理されます。このようにして、CGFがGGSNによって遅れてリリースされるため、1月にCGFがプロセスDec月のCDRのようにCGFに送信された古いCDRが表示されます。

正しいグループのCDRがアーカイブキューに送信される理由：  ユーザデータグラムプロトコル(UDP)で送信できる最大パケットは、ヘッダーを含む64Kです。max-cdr 255 wait-time 60を設定したため、最大255個のCDRに達する前に64 Kバッファがいっぱいになる可能性があります。システムは、新しいCDRが64Kバッファに収まるかどうかを確認します。そうでない場合、システムはアーカイブ・キューに戻します。このCDRは、無効なグループのCDRが消去されるまで1か月間、アーカイブキューに戻されます。設定が正しい場合、アーカイブキューにはサーバのないAPNのCDRがなく、この問題は発生しません。これは、CDRがアーカイブキューに入っても処理されるからです。

ロジック

aaaproxyを強制終了し、gtpp storage-server mode localを変更するため、CDRがローカルハードディスクにプッシュされ、aaamgrごとに制限に達するとCDRの消去が回避されます。すべてのCDRがローカルのハードディスク(HDD)に書き込まれると、デフォルトのリモートモードに戻ることができます。