ASR5x00:由于APN中配置错误而正在发送到CGF的已备份CDR

下载选项

  • PDF     (175.5 KB)
    在各种设备上使用 Adobe Reader 查看
  • ePub     (81.0 KB)
    在 iPhone、iPad、Android、Sony Reader 或 Windows Phone 上使用各种应用查看
  • Mobi (Kindle)     (67.9 KB)
    在 Kindle 设备上查看或在多个设备上使用 Kindle 应用查看
已更新: 2016 年 9 月 14 日
文档 ID:200659

非歧视性语言

此产品的文档集力求使用非歧视性语言。在本文档集中，非歧视性语言是指不隐含针对年龄、残障、性别、种族身份、族群身份、性取向、社会经济地位和交叉性的歧视的语言。由于产品软件的用户界面中使用的硬编码语言、基于 RFP 文档使用的语言或引用的第三方产品使用的语言，文档中可能无法确保完全使用非歧视性语言。 深入了解思科如何使用包容性语言。

关于此翻译

思科采用人工翻译与机器翻译相结合的方式将此文档翻译成不同语言，希望全球的用户都能通过各自的语言得到支持性的内容。 请注意：即使是最好的机器翻译，其准确度也不及专业翻译人员的水平。 Cisco Systems, Inc. 对于翻译的准确性不承担任何责任，并建议您总是参考英文原始文档（已提供链接）。

简介

本文描述网关 — GPRS支持节点(GGSN)呼叫数据记录(G-CDR)因接入点名称(APN)中的错误配置导致用户计费错误以及计费网关功能(CGF)接收GGSN中卡住的回溯CDR的特定场景。此问题在思科集成多业务路由器(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 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存档显示，600万CDR被困在所有aamgr中，因此没有新的CDR在流模式下被处理并传输到CGF。

达到每个amgr的限制后，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

解决方案

过程方法(MOP)，用于清除aaproxy进程中属于默认组的CDR。

步骤1.记下存档的CDR显示gtpp计数器全部

步骤2.在gaggsnctx config context gaggsnctx gtpp group默认gtpp storage-server mode local中将模式配置为本地模式

步骤3.请在隐藏模式下使用此命令终止aaaproxy。任务终止设施aaproxy all。（任务终止将使本地模式应用于默认组。）

步骤4.退出隐藏模式

步骤5.检查show gtpp storage-server local file statistics is greanged。

步骤6.每30秒运行一次show gtpp计数器。在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不应存档，但它们可以进入存档队列。

从存档队列，您一次只能处理五个请求。如果所有五个请求都属于配置错误的APN，则前五个请求永远不会被释放，从而阻止队列后面的所有CDR。这意味着在特定月份生成的CDR被困在那里并且处理错误。

ASR5x00对可存档的CDR数量有上限。超过限制后，存档的CDR将被清除。这为特定月份生成的有效CDR让路，并释放它们。 

例如，

如果队列有五个请求，其余请求属于配置正确的有效APN，并且在您处理时，每次五个请求从未释放，因为没有配置服务器，并且您将永远停滞，因为您每次只处理五个CDR。但是，如果其中一个请求被清除，这意味着您有4个请求属于无效配置APN，下一个请求是有效APN。现在，当您处理五个请求时，四个请求会停滞，而第五个请求现在会处理。这样，您将看到发送到CGF的旧CDR，如CGF，将在1月处理12月的CDR，因为GGSN会延迟发布这些CDR。

为什么将正确组的CDR发送到存档队列：  在用户数据报协议(UDP)中可以传输的最大数据包数为64K，包括报头。现在，由于我们配置了最大cdrs 255等待时间60,因此在达到最大255个CDR之前，可能有64 K缓冲区已满。系统将检查新CDR是否可以装入64K缓冲区。如果不是，系统会将其放回存档队列。此CDR将滞留的存档队列放回一个月，直到无效组的CDR被清除。如果配置正确，则存档队列从未拥有那些没有服务器的APN的CDR，并且此问题从未出现，因为即使CDR进入存档队列，它也会得到处理。

逻辑

您正在清除aaaproxy并更改gtpp存储服务器模式本地，因此滞塞的CDR将被推送到本地硬盘，并且在达到每个aaamgr的限制后将避免清除CDR。所有CDR写入本地硬盘后，您可以重新更改为远程模式（默认模式）。

TAC Authored

由思科工程师提供

  • 克里希纳Kishore DV
    思科TAC工程师
  • Saurabh古普塔
    思科TAC工程师

此文档是否有帮助?

Feedback反馈

联系我们

本文档适用于以下产品