简介
本文描述网关GPRS支持节点(GGSN)呼叫数据的特定方案(G CDR)卡住归结于在接入点Name(APN)的错误配置导致用户的错误的计费，并且正在充电网关Function(CGF)接收在GGSN被滞留的被追溯的CDR。此问题在Cisco Aggregrated 5x00系列服务的路由器(ASR)报告。
由于多种原因(很可能误配置)某APNs的， 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 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账户在所有aaamgrs显示6百万CDR被滞留和由于哪些新的CDR不得到处理和转接对流式模式的CGF。
一旦限制每aaamgr达到， CDR清除并且导致CDR损耗和收入损耗给客户。
从6归档的百万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的Procedure(MOP)方法。
步骤1:注意在归档的CDR下。显示gtpp抵抗所有
步骤2.配置模式对本地在gaggsnctx设置上下文gaggsnctx gtpp组默认gtpp存储设备服务器模式本地
第三步：使用此in命令隐藏的模式，请杀害aaaproxy。分派任务杀害设备aaaproxy全部。(任务杀害将做本地传送方式将应用对默认组。)
步骤4.从出来的隐藏的模式
第五步：检查显示gtpp存储设备服务器本地文件统计信息增加。
步骤6.运行显示gtpp抵抗所有每30秒。这在5分钟间距应该下来调零。
步骤7.恢复模式到远程。配置上下文gaggsnctx gtpp组默认gtpp存储设备服务器模式远程
步骤 8检查归档的计数器(请显示gtpp抵抗所有)不增加并且显示gtpp存储设备服务器本地文件统计信息不增加。
步骤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
技术说明
由于多种原因(很可能误配置)某APNs的， CDR去默认组。在默认组中，您不安排CGF服务器配置并且请求获得卡住。对于有配置的一有效gtpp组的APNs，不应该归档CDR，但是他们可能去存档队列。
从存档队列您能每次只处理五请求。万一，如果全部五请求属于然后误配置名列前茅五请求因而从未被释放的APNs阻塞在队列后的所有CDR。这意味着在特定月生成的CDR被滞留得那里并且错误处理。
ASR5x00有一个上限可以归档多少CDR。一旦限制交叉归档的CDR请获得清除。这在一个特定月做生成的有效CDR的方式，并且他们获得发布。
例如，
如果队列有五请求，并且请求的其余属于与正确设置的有效APN，并且，当您进程，在五请求从未获得释放时候，尽管没有服务器配置的和您被滞留得永久，当您每次只处理五CDR。然而，如果清除的其中一请求获得，这含义您有属于无效设置APN的4请求和其次一是有效APN。现在，当您处理五请求四请求卡住时，但是第五一个当前处理。这样，您看到旧有CDR发送对CGF类似CGF是进程十二月在一月的月CDR，因为他们由GGSN后发布。
正确组的CDR为什么发送归档队列： 在用户数据报协议(UDP)可以传送的最大信息包是64K包括报头。现在，因为我们配置麦斯CDR 255等待时间60，有机会64 K缓冲区全双工，在最大255 CDR前被到达。系统证实是否新的CDR能适合到64K缓冲区。如果不是系统将放置他们回到存档队列。此CDR放置回到直到CDR的一个月滞留的存档队列无效组的清除。如果将有正确配置，则存档队列未曾有那些的CDR没有服务器，并且此问题不会看到，因为的APNs，即使CDR回车到存档队列里它将处理。
逻辑
您杀害aaaproxy并且更改gtpp存储设备服务器模式本地，因此被滞留的CDR推送到本地光盘，并且避免清除CDR，一旦限额每aaamgr达到。一旦所有CDR获得写入对本地光盘，您能更改回到是默认一的远程模式。
反餽