概要
このドキュメントでは、アグリゲーションサービスルータ(ASR)5000/ASR 5500/Virtual Packet CoreでCharging Data Records(CDR)/General Packet Radio Service(GPRS)Tunneling Protocol Prime(GTPP)アーカイブをトラブルシューティングする手順について説明します。
背景説明
ASR 5000/ASR 5500/Virtual Packet Core(VPC)は、さまざまな理由でCDRをアーカイブする可能性があります(IP接続の問題が原因でファイルを送信できない、リモートサーバがCDRを受信できない、さまざまな設定の誤りなど)。aaproxyを再起動すると、Charging Gateway Function(CGF)の問題であっても、多くの場合この問題が解決されます。たとえば、CGFが特定のタイプのメッセージ(キャンセル要求など)を受け入れることができなかった場合、aaaproxyが再起動した後、メッセージは送信されなくなります。aaaproxyの再起動によって問題が解決されるため、ASR 5000/ASR 5500/Virtual Packet Core(VPC)が原因で誤検出が発生します。外部PCAPを使用してトラフィックをキャプチャすると、原因の特定に役立ちます。この場合はCGFです。
問題
show gtpp countersは、CDRのタイプとカウンタを示します。カウンタにはアーカイブされたCDRが表示されます。次の例では、アーカイブされたゲートウェイGPRSサポートノード(GGSN)のCDR(GCDR)の数は144015です。show gtpp countersの複数の出力は、アーカイブされたCDRの数が増加しているかどうかを示します。
[local]StarOS# show gtpp counters all
Archived GCDRs: 144015
GCDRs buffered with AAAPROXY: 0
GCDRs buffered with AAAMGR: 22354
この出力は、GCDRアーカイブが安定している間のServing GPRS Support Node(SGSN)のCDR(SCDR)アーカイブの継続状況を示します。
[local]StarOS# show gtpp counters all | grep Archive
Archived GCDRs: 176703
Archived MCDRs: 0
Archived SCDRs: 2244673
Archived S-SMO-CDRs: 0
Archived S-SMT-CDRs: 0
Archived G-MB-CDRs: 0
Archived SGW CDRs: 0
Archived WLAN CDRs: 0
Archived LCS-MT CDRs: 0
[local]StarOS# show gtpp counters all | grep Archive
Archived GCDRs: 176703
Archived MCDRs: 0
Archived SCDRs: 2244864
Archived S-SMO-CDRs: 0
Archived S-SMT-CDRs: 0
Archived G-MB-CDRs: 0
Archived SGW CDRs: 0
Archived WLAN CDRs: 0
Archived LCS-MT CDRs: 0
[local]StarOS# show gtpp counters all | grep Archive
Archived GCDRs: 176703
Archived MCDRs: 0
Archived SCDRs: 2245281
Archived S-SMO-CDRs: 0
Archived S-SMT-CDRs: 0
Archived G-MB-CDRs: 0
Archived SGW CDRs: 0
Archived WLAN CDRs: 0
Archived LCS-MT CDRs: 0
syslogで「gtpp 52056」警告を確認すると、CDRのアーカイブが発生しているコンテキストとGTPPグループを特定できます。この出力は、コンテキストGTPPおよびgtppグループデフォルトのアーカイブが報告されていることを示しています。
[gtpp 52056 warning] [5/0/2399 <aaamgr:50> gr_gtpp_proxy.c:667] [context: GTPP, contextID: 6]
[software internal security system critical-info syslog] [gtpp-group default]
GTPP request with req-count 61747 retried by AAAmgr. Retry-count 3342670
解決方法
1.設定が正しくない場合、アーカイブにCDRが累積される可能性があります。CDR/GTPPレコードが意図しないGTPPグループによって生成され、このグループの設定が無効な場合、アーカイブが発生します。設定が存在するか、次の一般的な問題に対して有効であることを確認します。
- APN設定の「gtpp group default」
- GGSN、サービングゲートウェイ(SGW)、SAEGW、SGSNサービスの「アカウンティングコンテキスト」
- Charging-agent IPおよびCGFサーバIPアドレス。
2.ソケットインターフェイスが対応するコンテキストでアップしているかどうかを確認します。ソケットの作成に失敗すると、CDRアーカイブが発生する可能性があります。このような問題を特定するには、次のコマンドを使用してCGF接続をテストします。このコマンドは、gtpp groupが設定されているコンテキストで実行する必要があります。
[context]StarOS# gtpp test accounting group name <name>
3. RTD(ラウンドトリップ遅延)で、Charging GatewayがCDRを確認応答しているかどうかを確認します。「show gtpp statistics verbose」は、CGFのRTDを示します。
4.転送ネットワークをチェックして、ゲートウェイでトラフィックを処理する能力があるかどうかを確認します。ネットワークでの遅延またはパケットドロップにより、CDRがゲートウェイにアーカイブされます。パケットが廃棄された場合(ASR 5000/ASR 5500/Virtual Packet Core(VPC)からパケットが再送信され、CDRの転送レートが低下する)、アーカイブされたCDRが発生します。これは、トランスポートリンクの容量を増やすか、ネットワークにQoSを追加することで修正できます。
5.新しいソフトウェアリリースでは「debug aaamgr show archive-records instance <aaamgr_instance_id>」(シャーシで設定されたCLI test-commands passwordが必要)を使用して、aaamgrインスタンスのアクティブなレコードを確認します。特定のaaamgrのアーカイブされたレコードのCDRタイプ、コンテキスト、およびGTPPグループ名に関する情報が提供されます。この情報は、設定ミスの可能性を特定するのに役立ちます。次の出力例から、CDRがコンテキストggsnのgtpp group defaultにスタック/アーカイブされていることがわかります。これらのCDRを生成したAPNはapn wiftestです。ggsnコンテキスト内のこのデフォルトのgtppグループの設定が無効である可能性があります。
--------------------------------------------------------------------------------------
Record Type | Apn Name | Accounting Context | Group Name | Timestamp
--------------------------------------------------------------------------------------
EGCDR |wifitest |ggsn |default |Tuesday August 26 10:18:21
EGCDR |wifitest |ggsn |default |Tuesday August 26 10:23:21
EGCDR |wifitest |ggsn |default |Tuesday August 26 10:28:21
EGCDR |wifitest |ggsn |default |Tuesday August 26 10:33:22