ASR5x00:由於APN中的配置錯誤而向CGF傳送追溯的CDR

下載選項

  • PDF     (222.8 KB)
    在多種裝置上使用 Adobe Reader 檢視
  • ePub     (81.2 KB)
    在 iPhone、iPad、Android、Sony Reader 或 Windows Phone 上的各種應用程式中檢視
  • Mobi (Kindle)     (68.0 KB)
    在 Kindle 裝置或多部裝置的 Kindle 應用程式上檢視
已更新: 2016 年 9 月 14 日
文件 ID:200659

無偏見用語

本產品的文件集力求使用無偏見用語。針對本文件集的目的，無偏見係定義為未根據年齡、身心障礙、性別、種族身分、民族身分、性別傾向、社會經濟地位及交織性表示歧視的用語。由於本產品軟體使用者介面中硬式編碼的語言、根據 RFP 文件使用的語言，或引用第三方產品的語言，因此本文件中可能會出現例外狀況。深入瞭解思科如何使用包容性用語。

關於此翻譯

思科已使用電腦和人工技術翻譯本文件，讓全世界的使用者能夠以自己的語言理解支援內容。請注意，即使是最佳機器翻譯，也不如專業譯者翻譯的內容準確。Cisco Systems, Inc. 對這些翻譯的準確度概不負責，並建議一律查看原始英文文件（提供連結）。

簡介

本文描述了由於接入點名稱(APN)中的錯誤配置而導致使用者計費錯誤而導致網關 — GPRS支援節點(GGSN)呼叫資料記錄(G-CDR)卡住的具體場景，計費網關功能(CGF)接收卡住在GGSN中的已回退CDR。此問題在Cisco聚合服務路由器(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存檔顯示，600萬個CDR停滯在所有快取中，因此，沒有新的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

解決方案

Method of Procedure(MOP)，用於清理代理進程中屬於預設組的CDR。

步驟1.記下歸檔的CDR。Show gtpp counters all

步驟2.在gaggsnctx config context gaggsnctx gtpp group default gtpp storage-server mode local中將模式配置為本地

步驟3.請在隱藏模式下使用此命令終止aproxy。任務kill facility aaproxy all。（任務終止將使本地模式應用於預設組。）

步驟4.退出隱藏模式

步驟5.檢查show gtpp storage-server local file statistics is increasing。

步驟6.每30秒運行show gtpp計數器。這應該在5分鐘內降為零。

步驟7.將模式恢復為遠端。config context gaggsnctx gtpp group預設gtpp storage-server mode remote

步驟8.檢查存檔計數器(show gtpp counters all)未增加，show gtpp storage-server local file statistics未增加。

步驟9.取出SSD並傳送回我們進行驗證，以確保配置完整無缺，且所有步驟均得到執行。

附註：練習完成後，如果您知道從HDD刪除CDR檔案的過程。去吧。（如果不是，請于某天聯絡TAC工程師參與本練習）

如果aproxy在1分鐘後未恢復，請參閱恢復過程。

恢復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

技術說明

由於某些APN的各種原因（最可能是配置錯誤），CDR會進入預設組。在default組中，您沒有配置CGF伺服器，因此請求會停滯。對於配置了有效gtpp組的APN，不應存檔CDR，但它們可以進入存檔隊列。

在存檔隊列中，一次只能處理五個請求。如果所有五個請求都屬於配置錯誤的APN，則從不會釋放前五個請求，從而阻止隊列後面的所有CDR。這意味著在特定月生成的CDR會滯留並錯誤處理。

ASR5x00有一個上限，可以存檔多少個CDR。一旦超過限制，就會清除存檔的CDR。這為特定月份生成的有效CDR創造了條件，並釋放它們。 

例如，

如果隊列有5個請求，並且其餘請求屬於具有正確配置的有效APN，則每次處理時，這5個請求都不會被釋放，因為沒有配置伺服器，並且您每次只處理5個CDR時將永遠停滯不前。但是，如果其中一個請求被清除，則意味著您有4個屬於無效配置APN的請求，下一個是有效的APN。現在，當您處理5個請求時，這4個請求會停滯，但第5個請求現在會被處理。這樣，您將會看到像傳送至CGF的舊CDR一樣，CGF將於一月處理十二月一個月的CDR，因為它們由GGSN延遲發佈。

正確組的CDR被傳送到存檔隊列的原因：  使用者資料包通訊協定(UDP)中可傳輸的最大封包為64K（包括標頭）。現在，由於我們配置了max-cdr 255 wait-time 60，在達到最大255 CDR之前，可能64 K緩衝區已滿。系統將檢查新的CDR是否可以容納在64K緩衝區中。如果沒有，系統會將其放回存檔隊列。此CDR將返回到存檔隊列停滯一個月，直到清除無效組的CDR。如果存在正確的配置，則歸檔隊列從未擁有那些沒有伺服器的APN的CDR，並且此問題永遠不會出現，因為即使CDR進入歸檔隊列，也會對其進行處理。

邏輯

您正在終止aaproxy並更改gtpp storage-server mode local，因此，停滯的CDR被推送到本地硬碟，並且將在達到每個aamgr的限制後避免清除CDR。所有CDR寫入本地硬碟後，即可切換回遠端模式（預設模式）。

TAC Authored

由思科工程師貢獻

  • Krishna Kishore DV
    Cisco TAC工程師
  • Saurabh Gupta
    Cisco TAC工程師

這份文件是否有所幫助？

Feedback意見

讓思科協助您

本文件適用於這些產品