What is CGF in telecommunications

introduction

This document describes a specific scenario in which Gateway-GPRS Support Node (GGSN) Call Data Records (G-CDRs) are blocked due to incorrect configuration in the Access Point Name (APN), which leads to incorrect billing for subscribers and charging Gateway Function (CGF) receives obsolete CDRs that are in GGSN. This problem has been reported on Cisco 5x00 Series Aggregated Service Routers (ASR).

problem

For various reasons (mostly misconfigurations) for some APNs, CDRs go to the default group. No CGF servers are configured in the standard group, and the requests are therefore stuck.

Example:

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 bla ckberry.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

Troubleshooting

Look under Show support details output (View support details) after the command has been issued.

******** show session subsystem data-info verbose ******* 647274 Total gtpp acct requests 1 Current gtpp acct requests 0 Total gtpp acct canceled 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 248 2018515 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

Currently archived AAA accounts show that there are 6 million CDRs in all rooms and therefore no new CDRs are processed and in the Streaming mode transferred to CGF.

As soon as the limit per agent is reached, CDRs are deleted and lead to the loss of CDRs and loss of revenue for the customer.

Of 6 million archived CDRs, you will see some CDRs being erased.

******** 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 canceled 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 canceled 0 Current prepaid online purged

The following are the checklists of the CLI commands that are commonly used to debug CDR-related problems.

- show gtpp accounting servers - show gtpp accounting servers group name - 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

solution

Method of Procedure (MOP) to clean up the CDRs that belong to the Default group in aProxy process

Step 1: Make a note of the archived CDRs. Show GTPP counters for everyone

Step 2: Configure the mode in gaggsnctx config context gaggsnctx gtpp group default gtpp storage-server mode local.

Step 3: Use this command to exit aaproxy in hidden mode. Task kill facility aaaproxy all. (Task kill causes local mode to be applied to the default group.)

Step 4: out of hidden mode

Step 5: check show gtpp storage-server local file statistics is increase.

Step 6: run all 30 seconds show gtpp counter off. This should go to zero within 5 minutes.

Step 7: reverse the mode in remote. config context gaggsnctx gtpp group default gtpp storage-server mode remote

Step 8: Verify That the Archived Meter (show gtpp counter all) does not increase and the local file statistics of the gtpp storage server does not increase.

Step 9: Take the SSD and send it back for inspection to make sure the configuration is intact and all steps are followed.

Note: After completing the activity, if you know the procedure to remove CDR files from HDD. Go on. (If not, call another day's TAC technician for this activity.)

If a proxy does not recover after 1 minute, refer to the recovery procedure.

Procedure to restore 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

Technical explanation

For various reasons (mostly misconfigurations) for some APNs CDRs go to Default-Group. In the Standard group no CGF servers are configured so that the requests are no longer processed. For the APNs for which a valid gtpp group is configured, CDRs should not be archived, but can be placed in the archive queue.

You can only process five requests at a time from the archive queue. If all five requests are among the APNs that are misconfigured, the five most frequent requests will never be released, so all CDRs behind the queue will be blocked. This means that the CDRs generated in a given month are stuck there and processed incorrectly.

ASR5x00 has an upper limit on the number of CDRs that can be archived. As soon as the limit is exceeded, the archived CDRs are deleted. This will replace and release the valid CDRs generated for a given month.

Example:

If there are five requests in the queue and the rest of the requests, with the correct configuration, belong to the valid APN, the five requests will be released whenever no server is configured and you are stuck forever because you only process five CDRs at a time. However, if one of the requests is deleted, it means that you have 4 requests that belong to the invalid configuration of APN and that the next one is a valid APN. If you now process five requests, the four requests are blocked, but the fifth is now being processed. This is how old CDRs are sent to CGF the way CGF would process CDRs in the Dec month of January as they are late released by GGSN.

Why the CDRs for the correct group are sent to the archive queue: The maximum packet transmitted in User Datagram Protocol (UDP) is 64K including headers. Since we max-cdrs 255 waiting times 60 configured, a 64 K buffer is full before a maximum of 255 CDRs are reached. The system checks whether new CDRs fit in the 64K buffer. If not, the system puts them back in the archive queue. This CDR is put in the archive queue for a month until the CDRs for invalid groups are deleted. Had it been configured correctly, the archive queue would never have received the CDRs for those APNs that did not have servers, and this problem would never have occurred because CDRs would have been placed in the archive queue even if they had been processed.

logic

You kill aaproxy and change that gtpp storage server mode local, so that the CDRs get stuck on the local hard drive and avoid deleting the CDRs as soon as the limit values ​​per AMAGR are reached. Once all CDRs have been written to the local hard drive, you can go back to the Remote mode which is the default mode.