CSG2 Rel5

Cisco Content Services Gateway 2nd Generation Release 5.
0 Installation and Configuration Guide

Cisco IOS Release 12.4(24)MDA4 June 2, 2011
Americas Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA http://www.cisco.com Tel: 408 526-4000 800 553-NETS (6387) Fax: 408 527-0883
Text Part Number: OL-22840-05
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS. THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY. The following information is for FCC compliance of Class A devices: This equipment has been tested and found to comply with the limits for a Class A digital device, pursuant to part 15 of the FCC rules. These limits are designed to provide reasonable protection against harmful interference when the equipment is operated in a commercial environment. This equipment generates, uses, and can radiate radio-frequency energy and, if not installed and used in accordance with the instruction manual, may cause harmful interference to radio communications. Operation of this equipment in a residential area is likely to cause harmful interference, in which case users will be required to correct the interference at their own expense. The following information is for FCC compliance of Class B devices: The equipment described in this manual generates and may radiate radio-frequency energy. If it is not installed in accordance with Ciscos installation instructions, it may cause interference with radio and television reception. This equipment has been tested and found to comply with the limits for a Class B digital device in accordance with the specifications in part 15 of the FCC rules. These specifications are designed to provide reasonable protection against such interference in a residential installation. However, there is no guarantee that interference will not occur in a particular installation. Modifying the equipment without Ciscos written authorization may result in the equipment no longer complying with FCC requirements for Class A or Class B digital devices. In that event, your right to use the equipment may be limited by FCC regulations, and you may be required to correct any interference to radio or television communications at your own expense. You can determine whether your equipment is causing interference by turning it off. If the interference stops, it was probably caused by the Cisco equipment or one of its peripheral devices. If the equipment causes interference to radio or television reception, try to correct the interference by using one or more of the following measures: Turn the television or radio antenna until the interference stops. Move the equipment to one side or the other of the television or radio. Move the equipment farther away from the television or radio. Plug the equipment into an outlet that is on a different circuit from the television or radio. (That is, make certain the equipment and the television or radio are on circuits controlled by different circuit breakers or fuses.) Modifications to this product not authorized by Cisco Systems, Inc. could void the FCC approval and negate your authority to operate the product. The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCBs public domain version of the UNIX operating system. All rights reserved. Copyright 1981, Regents of the University of California. NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED AS IS WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE. IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R) Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental. Cisco Content Services Gateway - 2nd Generation Release 5.0 Installation and Configuration Guide, Cisco IOS Release 12.4(24)MDA4 Copyright 2011 Cisco Systems, Inc. All rights reserved.
CONTENTS
About This Book
1
xix
CHAPTER
Overview
1-1 1-1
Whats New
CSG2 Features 1-3 Comparison of CSG1 and CSG2 Hardware Architectures 1-5 MIB Support 1-6 CSG2 Billing Criteria 1-7 CSG2 Interactions with External Entities 1-7 CDR Support 1-8 Fixed CDR Support for HTTP, IMAP, RTSP, and WAP 1-8 Single CDR Support for HTTP and WAP Connectionless 1-8 Service-Level CDR Summarization 1-9 Prepaid and Postpaid Envelope Information Support for SMTP 1-9 Fixed Attribute CDRs for WAP 1-9 CDR Suppression for Unestablished TCP Connections 1-9 Conditional CDR Blocking 1-10 Byte Counting 1-10 Byte Counting Overview 1-10 HTTP Byte Counting 1-12 WAP Byte and Packet Counting 1-13 IMAP Byte Counting 1-14 FTP and RTSP Byte Counting 1-15 SIP Byte Counting 1-15 POP3 and SMTP Byte Counting 1-15 Byte and Packet Counting After a Failover 1-15 Flexible Accounting for Retransmitted TCP Segments 1-15 CSG2 User Table 1-15 IPv6 Bearer Support and Dual-Stack 1-16 IPv6 and Dual-Stack Addresses in the CSG2 User Table 1-16 IPv6 and Dual-Stack Feature Limitations and Exceptions 1-17 CSG2 Interface Awareness 1-18 Billing Plan Features 1-19 BMA Features 1-19 Quota Server Features 1-20
Cisco Content Services Gateway - 2nd Generation Release 5.0 Installation and Configuration Guide OL-22840-05
iii
Contents
Service Features 1-20 IPC Features 1-21 PSD Features 1-21 iSCSI Features 1-22 RADIUS Features 1-22 Gx Features 1-23 Mobile PCC Features 1-24 HTTP Features 1-24 HTTP Pipelining and Chunked Transfer Encoding 1-25 Support for Multipart HTTP 1-25 HTTP Header Insertion 1-25 HTTP 1.0 Content Billing 1-25 HTTP 1.1 Content Billing 1-25 HTTP Records Reporting Flexibility 1-26 HTTP Error Code Reporting 1-26 Out-of-Order Forwarding of HTTP Packets 1-26 Relative URI Matching 1-26 Learning Client IP Addresses Using Inspection of HTTP X-Forwarded-For Headers Restrictions for HTTP 1-27 SIP Features 1-28 WAP Features 1-28 WAP Traffic 1-28 WAP 2.0 1-29 Support for WAP Segmentation and Reassembly (SAR) 1-30 RTSP Features 1-30 RTSP Billing 1-31 Per-Click Authorization 1-31 RTSP TEARDOWN Reply Delay 1-31 URL Maps for Interleaved RTSP 1-31 Correlation 1-32 DNS Support 1-35 POP3 Support 1-35 SMTP and POP3 Billing 1-36 SMTP CDR Header Removal 1-37 FTP Billing 1-37 Attribute, Header, Method, and URL Mapping 1-37 Configurable Regex Memory 1-37 Configurable URL Map Normalization 1-37 Service Duration Billing 1-38 Charging for Service Duration Billing 1-38
Cisco Content Services Gateway - 2nd Generation Release 5.0 Installation and Configuration Guide
1-27
iv
OL-22840-05
Contents
Calculating Usage for Service Duration Billing 1-39 Configuring Activity-Based Time Billing 1-42 Reporting Quadrans to the Quota Server and to the BMA 1-43 Handling Out-of-Quota Conditions 1-43 Connection Duration Billing 1-43 Postpaid Service Tagging 1-44 Stateful Redundancy and Failover 1-44 Default Policy 1-45 Tariff Switch 1-46 Prepaid Error Reimbursement 1-46 Postpaid Billing 1-47 Prepaid Content Billing and Accounting 1-47 Dual Quota Support 1-49 Quality of Service (QoS) Support 1-49 NBAR Protocol Support 1-50 License-Exceeded Notifications 1-53 User Logoff Notifications 1-53 Obtaining User IDs 1-53 Filtering Accounting 1-53 Intermediate CDRs 1-54 Accelerated Sessions 1-54 Packet Forwarding 1-55 Per-User Uplink Next-Hop Support 1-55 URL-Redirect 1-56 Supplemental Usage Reports 1-56 Enhanced Interoperability with Cisco Service-Aware GGSN 1-56 Miscellaneous Features 1-56 IP Fragment Support for All Protocols 1-57 Out-of-Order Packet Support for All Protocols 1-57 Enhanced Adaptability for Network-Generated Out-of-Order TCP Packets for Layer 4 Flows Billing Chain Failure Notification 1-57 Asynchronous Service Stop 1-57 Support for Port Number Ranges 1-57 Service Rule Scaling 1-58 Packet Counts 1-58 Negative Quadrans 1-58 CSG2 Prerequisites CSG2 Restrictions
1-58 1-58
1-57
Contents
CHAPTER
Configuring the CSG2
2-1 2-1
Preparing to Install the CSG2 Software Installing the CSG2 Software Upgrading the CSG2 Software
2-3 2-7
Saving and Restoring CSG2 Configurations
2-7
Configuring the CSG2 Features 2-8 Configuring the User Database 2-9 Configuring the CSG2 User Table 2-9 Configuring the Fragment Database 2-11 Configuring the Session Table 2-11 Configuring URL-Redirect 2-12 Configuring Policies and Traffic Types 2-13 Configuring a Content Billing Service 2-14 Configuring a Billing Plan 2-14 Offline Billing Control 2-15 Assigning a Default Billing Plan 2-15 Displaying Billing Plan User Counts 2-16 Configuring Content 2-16 Setting a Session Acceleration Rate for Contents 2-19 Configuring DNS Support 2-19 Enabling DNS Global Domain Mining 2-20 Defining DNS Domain Groups 2-20 Populating the DNS IP Map Table 2-21 Defining a DNS Catchall Content 2-22 Updating DNS Domain Groups 2-23 Implementing Virtual Contents 2-23 Enabling DNS Refunding 2-23 DNS Feature Support and Restrictions 2-24 Sample DNS Configurations 2-24 Configuring Header Insertion 2-25 Configuring a Header 2-26 Configuring a Header Group 2-27 Enabling Header Insertion 2-28 Including and Excluding Headers for Insertion 2-29 Configuring 3DEA Keys for Header Data Encryption 2-30 Configuring Single-TP Mode 2-30 Configuring Fixed, Variable, or Combined Format CDR Support 2-30 Fixed CDR Support for HTTP and WAP 2-31 Fixed CDR Support for IMAP 2-31
vi
OL-22840-05
Contents
Fixed CDR Support for RTSP 2-32 Single CDR Support for HTTP and WAP 2-32 Specifying the CDR Format 2-32 Configuring a Refund Policy on the CSG2 2-32 Configuring Quality of Service (QoS) 2-33 Configuring NBAR Protocol Support 2-35 Configuring 8-Byte TLVs 2-38 Configuring HTTP Header Reporting 2-38 Configuring SMTP CDR Header Removal 2-39 Configuring Supplemental Usage Reporting 2-40 Configuring Actual PDU Reporting for WAP 2-40 Configuring CDR Suppression for Unestablished TCP Connections 2-40 Configuring Conditional CDR Blocking 2-41 Configuring Content Name Reporting 2-41 Configuring Policy Name Reporting 2-41 Configuring Flexible TCP Packet Counting 2-42 Configuring Maps for Pattern-Matching 2-43 Configuring Connection Redundancy 2-44 Configuring High Availability 2-44 Components That Provide HA 2-45 Enabling HA 2-46 Configuring a Secondary IP Address for HA 2-46 Synchronizing Clocks for HA 2-46 Modifying an HA Configuration 2-47 Distributed Crash Data Collection 2-47 Configuring HA for CSG2s in Different Chassis 2-48 Configuring the CSG2 for HA Peer Connectivity 2-48 Classifying Data Traffic 2-49 Configuring a CSG2 Subscriber Interface 2-49 Configuring Case Sensitivity 2-49 Configuring WAP and WSP Support 2-50 Counting Bytes and Packets 2-50 Incomplete WAP Transactions 2-50 Multimedia Messaging Service 2-50 Blocking Ports 2-51 Configuring SNMP Timers 2-51 Configuring the Interval for Protocol Transaction Statistics 2-52 Configuring the Cisco SAMI Bit Rate Limit 2-52 Configuring the SNMP Notification Types 2-52 Configuring the Subscriber Threshold for License-Exceeded Notifications
2-52
vii
Contents
Configuring Packet Logging and Reporting 2-53 Trouble-Shooting a Problem Using Packet Logging 2-55 Configuring a Packet Filter 2-55 Defining the Size of the Packet Buffer 2-56 Enabling and Disabling Packet Logging 2-56 Displaying the Contents of the Packet Buffer 2-56 Setting Up Packet Logging for NBAR 2-57 Changing the Order of Next-Hop IP Address Selection 2-57 CSG2 Configuration Examples 2-58 Sample Configuration for Subscriber-to-Subscriber Traffic 2-58 Configuring Next-Hop for a Subscriber-to-Subscriber Content 2-59 Configuring Prepaid Subscriber-to-Subscriber Contents for a Service Sample Configuration for HTTP X-Forwarded-For 2-60 Sample Configuration for High Availability 2-61 HA Configuration on the Active CSG2 2-61 HA Configuration on the Standby CSG2 2-62 Sample Configuration for HA Peer Connectivity 2-62 Sample Configuration for Supervisor Engine Side 1 2-63 Sample Configuration for CSG2 Side 1 2-63 Sample Configuration for Supervisor Engine Side 2 2-64 Sample Configuration for CSG2 Side 2 2-64 Displaying Port-Channel Information for One Side 2-65 Configuring CSG2 Network/Subscriber Traffic 2-66 Sample Configuration for HTTP Header Insertion 2-66 Sample Configuration for IPv4- and IPv6-Aware VRF 2-68
3
2-60
CHAPTER
Configuring BMA Support Configuring a BMA

3-2
3-1 3-1
Configuring the BMA Local Port
Configuring the BMA Keepalive Time Configuring the BMA Retransmit Time Configuring the BMA Retry Number Configuring the BMA Window Size Configuring BMA Load Sharing
3-5
3-2 3-3
Configuring the BMA GTP Message Buffer

3-3 3-4 3-4
Reporting the Billing Plan ID to the BMA
3-5
viii
OL-22840-05
Contents
CHAPTER
Configuring Quota Server Support Configuring a Quota Server

4-2
4-1 4-2
Configuring the Quota Server Local Port
Configuring the Quota Server Keepalive Time Configuring the Quota Server Retransmit Time Configuring the Quota Server Retry Number Configuring the Quota Server Window Size Configuring Quota Server Load Sharing
4-5
4-2 4-3
Configuring the Quota Server GTP Message Buffer

4-3 4-4 4-4
Reassigning Subscribers to a New Quota Server Sending User Profile Requests to Quota Servers Quota Push
4-6 4-6 4-7
4-5 4-6
Replacing Quota Balance Asynchronous Quota Return
Delaying Quota Reauthorization

4-7
Reporting the Billing Plan ID to the Quota Server Pricing by Quota Server Configuration Example Differentiating Prices Configuration Example
4-8
4-7 4-8
Reducing the Number of Services Configuration Example

5
4-9
CHAPTER
Configuring Service Support
5-1 5-2 5-2
Configuring a Basic Content Billing Service Configuring the Billing Basis for a Service Specifying a Service Owner Specifying a Service Class
5-3 5-3 5-4 5-4
Configuring a Service Idle Time Configuring a Service Lifetime
Configuring Advice of Charge 5-4 Enabling AoC URL-Rewriting 5-6 Configuring an AoC Token 5-6 Configuring AoC URL-Appending 5-7 Redirect Flexibility 5-8 Configuring Service Verification 5-8 Enabling Service Verification URL-Rewriting 5-8 Configuring a Service Verification Token 5-9 Enabling Service-Level CDR Summarization
5-9
ix
Contents
Support for eG-CDRs with GGSN
5-11 5-12
Configuring Passthrough Mode and the Default Quota Flagging of Messages 5-12 User Profile Requests 5-12 Quota Server Recovery 5-13
Configuring Metering 5-13 Configuring an Initial Quota for Metering 5-13 Configuring a Minimum Quota for Metering 5-14 Configuring a Debit Increment for Metering 5-14 Excluding RTSP PAUSE from Metering 5-15 Including IMAP Bytes in Metering 5-15 Excluding MMS from Metering 5-17 Excluding the Final Service Idle from Metering 5-18 Configuring the Quota Reauthorization Threshold Configuring the Quota Reauthorization Timeout Final Unit Indication
5-19 5-20 5-20 5-18 5-19
Enabling a Refund Policy for a Service Configuring Content Access Control

6
CHAPTER
Configuring IPC Support
6-1 6-1 6-1 6-2 6-2
Configuring the IPC Keepalive Time Configuring the IPC Retransmit Time Configuring the IPC Retry Number Changing the IPC Crash Dump Setting
7
CHAPTER
Configuring PSD Support Configuring the PSD

7-2
7-1 7-2
Configuring the PSD Local Port
Configuring the PSD Packet Drain Settings Configuring the PSD Keepalive Time Configuring the PSD Retransmit Time Configuring the PSD Retry Number Configuring the PSD Window Size
8
7-5 7-3
7-2
Configuring the PSD GTP Message Buffer

7-4 7-4
7-3
CHAPTER
Configuring iSCSI Support iSCSI Overview

8-1
8-1
OL-22840-05
Contents
Configuring an iSCSI Target Interface Profile on the CSG2 Associating an iSCSI Target Interface Profile with the CSG2 Configuring the iSCSI Packet Drain Settings Verifying the iSCSI Session
9
8-4 8-4
8-2 8-3
CHAPTER
Configuring RADIUS Support Configuring RADIUS Proxy Configuring RADIUS Handoff Configuring RADIUS Endpoint
9-1 9-2 9-3 9-4 9-4 9-6
Configuring RADIUS Packet of Disconnect Configuring RADIUS Monitor

9-6
Configuring RADIUS Change of Authorization
RADIUS Attributes and VSA Subattributes 9-7 RADIUS Attributes Required for CSG2 User Table 9-7 Parsing RADIUS VSA Subattributes for Header Insertion Inclusion and Exclusion Specifying Binary RADIUS Attributes and VSA Subattributes 9-8 Deleting Entries from the CSG2 User Table 9-8 Reporting RADIUS Attributes and VSA Subattributes 9-9 Enabling RADIUS Roaming Service Control Enabling RADIUS Geo-Redundancy RADIUS Subscriber Cleanup
9-13 9-14 9-15 9-12 9-12 9-11
9-8
Retrieving the Billing Plan ID from RADIUS RADIUS Error Acknowledgment RADIUS Correlation Processing
10
CHAPTER
Configuring Gx Support
10-1 10-3 10-3 10-5
Enabling Gx on the CSG2 Configuring a User Profile
Support for the Cisco eGGSN for Cisco GGSN Release 10.0 and the Single IP Feature Support for Single IP GGSN 10-5 RADIUS VSA Subattributes for Single IP Support 10-5 Route Injection 10-6 Dynamic Redirection
10-6 10-7
Cisco 7600 LTE Integration
Preloading Policies 10-8 Preloaded Billing Plans 10-9 Preloaded Contents 10-9
xi
Contents
Preloaded Domain Groups 10-9 Preloaded Headers 10-9 Preloaded Header Groups 10-10 Preloaded Maps 10-10 Preloaded Policies 10-10 Preloaded Services 10-10 Support for Gx TCP Signature Reporting
10-11 10-11 10-12
Dynamic Provisioning of 3GPP Per-User DGRs Dynamic Provisioning of Cisco Per-User DGRs Gx Event Triggers
10-13 10-14
Volume and Duration Triggers Service Flow Detection Triggers
Per-Subscriber Volume and Time Thresholds

10-15 10-15
10-14
Gx Event Trigger Usage Reporting Gx Service Groups

10-16
Billing Plan Assignment and Modification PDP Context QoS Signaling

10-16 10-17
10-16
Secondary PDP Context Activation PCRF Failure Handling Restrictions for Gx

12
10-17
PCRF-Specified Service-Level and User-Level QoS User Session Continuation After PCRF Timeout
10-18
10-17
10-17
CHAPTER
Configuring Prepaid Support
12-1 12-1 12-2
Configuring a Prepaid Billing Plan Configuring Virtual Prepaid Mode Prepaid WAP Support
12-3
Configuring a Postpaid Service for a Prepaid Billing Plan

11
12-3
CHAPTER
Configuring Mobile PCC Support Per-User PCC

11-1
11-1
Policy Preloading 11-1 Policy Preload Timer 11-2 Session ID Format for Policy Preloading PCRF Load Balancing
11-2 11-3
11-2
Handling Redundancy in PCC
xii
OL-22840-05
Contents
Handling Response Codes in PCC 11-3 Response Code for CCA 11-3 Response Code for RAA 11-4 Per-User RAAs 11-4 Preload RAAs 11-4 Mobile PCC Configuration Examples 11-5 Diameter Configuration Example 11-5 Diameter Redundancy Configuration Example Active Device Configuration 11-7 Standby Device Configuration 11-7 Mobile PCC Configuration Example 11-7
A
11-6
APPENDIX
CSG2 Command Reference
A-1
APPENDIX
Field Descriptions for CSG2 Statistics CSG Replication Statistics CSG Clear Statistics IPC PPC Statistics
B-3 B-3 B-2
B-1
CSG Distributed Configuration Statistics CSG Distributed Show Statistics CSG Clock Statistics (CP) CSG Clock Statistics (TP) CSG Regex Statistics
B-10 B-10 B-8
B-8
CSG Background Configuration Statistics

B-11 B-12 B-16
B-10
CSG Load Management Statistics CSG Buffer Management Statistics CSG User Database Statistics CSG Session Layer 4 Statistics CSG Fragment Statistics CSG Packet Statistics CSG User Statistics CSG ACCEL Statistics CSG LogGen Statistics
B-21 B-22
B-17 B-18
CSG IPv6 Fragment Statistics

B-22
CSG Distributed User Table Statistics

B-26 B-28 B-29 B-32
B-24
CSG Session Statistics
GTP Application: CSG IPC, Local Port: 0
B-33
xiii
Contents
GTP Application: CSG Billing Agent, Local Port: 16000 GTP Application: CSG Quota Server, Local Port: 16001 GTP Application: CSG PSD, Local Port: 0 CSG RADIUS Statistics CSG OTHER Statistics CSG HTTP Statistics CSG RTSP Statistics CSG SIP Statistics CSG WAP Statistics CSG Mail Statistics CSG FTP Statistics CSG NBAR Statistics CSG QoS Statistics
B-37 B-40 B-40 B-42 B-44 B-47 B-48 B-49 B-51 B-52 B-53 B-56 B-57 B-36
B-34 B-35
CSG Quota Server Statistics CSG Gx Handler Statistics CSG Policy Preload Statistics Timer Statistics DNS Stats
B-60 B-59
DNS IP Map Table Stats

C
B-61
APPENDIX
CSG2 Command HistoryCSG1 R7 to CSG2 R1 Unchanged Commands New Commands Deleted Commands Changed Commands
C-2 C-3 C-5 C-1
C-1
Changes to Module CSG Configuration Mode Changes to Accounting Configuration Mode Changes to Billing Configuration Mode Changes to Block Configuration Mode Changes to Content Configuration Mode Changes to Map Configuration Mode Changes to Policy Configuration Mode Changes to Refund Configuration Mode Changes to Ruleset Configuration Mode Changes to Service Configuration Mode
C-12 C-12 C-12
C-10 C-10
Changes to Module CSG VLAN Configuration Mode

C-11
C-13 C-13 C-14 C-14 C-14
xiv
OL-22840-05
Contents
Changes to SNMP Timer Configuration Mode Changes to Transport-Type Configuration Mode Changes to User Group Configuration Mode Changes to Weight Configuration Mode
D
C-17
C-15 C-15
C-16
APPENDIX
CSG2 Command HistoryCSG2 R1 to CSG2 R2 New Commands Deleted Commands Changed Commands
D-1 D-2 D-2
D-1
APPENDIX
E-1 E-2 E-2
E-1
APPENDIX
CSG2 Command HistoryCSG2 R3 to CSG2 R3.5 New Commands Deleted Commands Changed Commands
F-1 F-3 F-3
F-1
APPENDIX
CSG2 Command HistoryCSG2 R3.5 to CSG2 R4 New Commands Deleted Commands Changed Commands
G-1 G-3 G-3
G-1
APPENDIX
H-1 H-1 H-2
H-1
APPENDIX
Protocol Compliance Statements for the CSG2 Layer 4 Inspection (parse protocol=other)
I-1
I-1
Layer 7 Inspection (parse protocol=specific protocol)

J
I-1
APPENDIX
CSG2 System Messages CSG2 System Messages
J-1 J-1
xv
Contents
Message: Configuration download error: %s J-1 Message: %s J-2 Message: Startup configuration completed. J-2 Message: Configuration Sync error: %s J-2 Message: %s J-2 Message: %s packet drop: queue size %d reached, record storage %s is currently %s J-3 Message: GTP error: %s J-3 Message: GTP received reject cause code %d from %i:%u J-3 Message: GTP state change: %s J-4 Message: IPC is link failed to processor %u, state = %u, software reloading card now. J-4 Message: %s J-4 Message: iSCSI device %i:%u is full J-5 Message: ISCSI state change: %s J-5 Message: %s transaction discarded due to high load. J-5 Message: Failed to set %s local port. Either there are no IP addresses configured or port %u is in use. J-6 Message: Lock depth %u has crossed threshold. J-6 Message: CSG NTP synchronization is complete J-6 Message: Error: %s J-7 Message: PSD device %i:%u is full J-7 Message: CSG replicate condition: %s J-7 Message: Error: %s J-8 Message: Unexpected condition: %s J-8 Cisco SAMI System Messages J-8 Message: Nvram CRC Failure: %d\n J-8 Message: Nvram Erase Failure: handle 0x%x, offset 0x%x, error %s J-9 Message: Nvram Init Failure of flash device at %d:%s J-9 Message: Nvram Init Failure: %s J-9 Message: Nvram Magic Corrupt: Present %d Expected %d\n J-9 Message: Nvram Write Failure: handle 0x%x, offset 0x%x, numbytes 0x%x error %s Message: Nvram Write Config Failure: \n J-10 Message: Unexpected condition: %s J-10 Message: Unexpected condition: %s J-10 iSCSI System Messages J-11 Message: Error: %s J-11 Message: Error: %s J-11 Message: Warning: %s J-11
J-10
xvi
OL-22840-05
Contents
APPENDIX
Monitoring Notifications
K-1
SNMP Overview K-1 MIB Description K-2 SNMP Notifications K-2 SNMP Versions K-3 SNMPv1 and SNMPv2c K-3 SNMPv3 K-4 SNMP Security Models and Levels K-4 Requests for Comments K-4 Object Identifiers K-5 Related Information and Useful Links K-5 TAC Information and FAQs K-5 SNMP Configuration Information K-5 Configuring MIB Support K-6 Determining MIBs Included for Cisco IOS Releases Downloading and Compiling MIBs K-6 Considerations for Working with MIBs K-7 Downloading MIBs K-8 Compiling MIBs K-8 Enabling SNMP Support
K-8 K-6
Enabling and Disabling SNMP Notifications K-9 Enabling and Disabling CSG2 Notifications via the CLI K-9 Enabling and Disabling CSG2 SNMP Notifications via SNMP
K-10
xvii
Contents
xviii
OL-22840-05
About This Book

This preface describes who should read the Cisco Content Services Gateway - 2nd Generation Release 5.0 Installation and Configuration Guide, Cisco IOS Release 12.4(24)MDA4, how it is organized, and its document conventions. This publication does not contain instructions for installing the Cisco 7600 series router. For information on installing the router, see the Installation Guide that came with your router.
Document Revision History

The following table lists the major changes made to this document each release, with the most recent changes listed first. Revision OL-22840-05 Date February 1, 2011 Change Summary Added the following features:
Regular Expression Match Capacity Increase for ContentsFor maps, the CSG2 supports:
Up to 1408 match patterns per map Up to 1408 total match patterns per policy Up to 1408 total match patterns per content Up to 8192 total match patterns per CSG2 (assuming there is enough
memory available) OL-22840-04 OL-22840-03 January 3, 2011 October 6, 2010 Added the following features:
Configuring a Service Lifetime, page 5-4 Accelerated Sessions, page 1-54FTP, RTSP, and SIP Support Configuring Packet Logging and Reporting, page 2-53Support for IPv6 and Dual-Stack Addresses HTTP Header Insertion, page 1-25Support for IPv6 and Dual-Stack Addresses
Added the following features:

xix
About This Book
Revision OL-22840-02
Date May 24, 2010
Change Summary Added the following features:

Accelerated Sessions, page 1-54Accelerated Virtual Prepaid Configurable Regex Memory, page 1-37 Configurable URL Map Normalization, page 1-37 Configuring RADIUS Proxy, page 9-2Reuse of Idle RADUS Proxy Ports RTSP TEARDOWN Reply Delay, page 1-31 User Session Continuation After PCRF Timeout, page 10-17
OL-22840-01
May 24, 2010
First publication.
Audience
This publication is designed for network administrators and other people who are responsible for setting up, installing, configuring, and operating the CSG2. Only trained and qualified service personnel (as defined in IEC 60950 and AS/NZS3260) should install, replace, or service the equipment described in this publication.
Organization
This publication is organized as follows: Chapter Chapter 1, Overview Chapter 2, Configuring the CSG2 Chapter 3, Configuring BMA Support Chapter 4, Configuring Quota Server Support Chapter 5, Configuring Service Support Chapter 6, Configuring IPC Support Chapter 7, Configuring PSD Support Chapter 8, Configuring iSCSI Support Chapter 9, Configuring RADIUS Support Chapter 10, Configuring Gx Support Description Presents an overview of the Cisco Content Services Gateway 2 (CSG2). Describes how to configure VLANs, virtual servers, billing, and other configuration tasks on the CSG2. Describes Billing Mediation Agent (BMA) features and configuration details. Describes quota server features and configuration details. Describes content billing service features and configuration details. Describes Interprocessor Communication (IPC) features and configuration details. Describes Cisco Persistent Storage Device (PSD) features and configuration details. Describes Internet Small Computer Systems Interface (iSCSI) features and configuration details. Describes RADIUS features and configuration details. Describes Gx features and configuration details.
Chapter 11, Configuring Mobile PCC Support Describes Mobile Policy Control & Charging (PCC) features and configuration details. Chapter 12, Configuring Prepaid Support Describes prepaid features and configuration details.
xx
OL-22840-05
About This Book
Chapter Appendix A, CSG2 Command Reference Appendix B, Field Descriptions for CSG2 Statistics Appendix C, CSG2 Command HistoryCSG1 R7 to CSG2 R1 Appendix D, CSG2 Command HistoryCSG2 R1 to CSG2 R2 Appendix E, CSG2 Command HistoryCSG2 R2 to CSG2 R3 Appendix F, CSG2 Command HistoryCSG2 R3 to CSG2 R3.5 Appendix G, CSG2 Command HistoryCSG2 R3.5 to CSG2 R4 Appendix H, CSG2 Command HistoryCSG2 R4 to CSG2 R5 Appendix I, Protocol Compliance Statements for the CSG2 Appendix J, CSG2 System Messages Appendix K, Monitoring Notifications
Description Describes the commands that allow you to set up and monitor content billing on the CSG2. Describes each of the fields in the output of the show ip csg stats command. Describes the changes to commands between the CSG1 and the CSG2 Release 1. Describes the changes to commands between the CSG2 Release 1 and the CSG2 Release 2. Describes the changes to commands between the CSG2 Release 2 and the CSG2 Release 3. Describes the changes to commands between the CSG2 Release 3 and the CSG2 Release 3.5. Describes the changes to commands between the CSG2 Release 3.5 and the CSG2 Release 4. Describes the changes to commands between the CSG2 Release 4 and the CSG2 Release 5. Provides protocol compliance statements for the CSG2. Lists and describes Cisco CSG2, Cisco SAMI, and iSCSI system messages. Describes enabling and monitoring CSG2 SNMP notifications in order to manage CSG2-related issues.
Conventions
This publication uses the following conventions: Convention boldface font italic font [ ] {x | y | z} [x | y | z] string Description Commands and keywords are in boldface. Arguments for which you supply values are in italics. Elements in square brackets are optional. Alternative keywords are grouped in braces and separated by vertical bars. Optional alternative keywords are grouped in brackets and separated by vertical bars. A nonquoted set of characters. Do not use quotation marks around the string or the string will include the quotation marks. font Terminal sessions and information that the system displays are in screen font. Information that you must enter is in boldface screen font.
screen
boldface screen
font
xxi
About This Book
Convention
italic screen
Description Arguments for which you supply values are in italic screen font. The symbol ^ represents the key labeled Controlfor example, the key combination ^D in a screen display means hold down the Control key while you press the D key. Nonprinting characters, such as passwords are in angle brackets.
font
< >
Notes use the following conventions:
Note
Means reader take note. Notes contain helpful suggestions or references to material not covered in the publication. Tips use the following conventions:
Tip
Means the following information will help you solve a problem. The tips information might not be troubleshooting or even an action, but could be useful information. Cautions use the following conventions:
Caution
Means reader be careful. In this situation, you might do something that could result in equipment damage or loss of data.
Related Documentation
For more detailed installation and configuration information, see the following publications:

Release Notes for Cisco Content Services Gateway - 2nd Generation Release 5, Cisco IOS Release 12.4(24)MD1 Service and Application Module for IP User Guide Diameter Credit Control Application feature guide: http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/ht_diam.html Cisco IOS Security Command Reference, Cisco IOS 12.4 Cisco Mobile Policy Control & Charging Infrastructure for Mobile Gateways Cisco IOS Network Management Configuration Guide Release Notes for Cisco IOS Release 12.2SR for the Cisco 7600 Series Routers Cisco 7600 Series Cisco IOS Software Configuration Guide Cisco 7600 Series Cisco IOS Command Reference Cisco IOS Quality of Service Solutions Configuration Guide, Cisco IOS Release 12.4 For information about MIBs, see:
xxii
OL-22840-05
About This Book
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
Cisco IOS Configuration Guides and Command References, Release 12.2Use these publications to help you configure the Cisco IOS software that runs on the MSFC and on the MSM and ATM modules.
Obtaining Documentation and Submitting a Service Request

For information on obtaining documentation, submitting a service request, and gathering additional information, see the monthly Whats New in Cisco Product Documentation, which also lists all new and revised Cisco technical documentation, at: http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html Subscribe to the Whats New in Cisco Product Documentation as a Really Simple Syndication (RSS) feed and set content to be delivered directly to your desktop using a reader application. The RSS feeds are a free service and Cisco currently supports RSS version 2.0.
xxiii
About This Book
xxiv
OL-22840-05
CH A P T E R
Overview
The Cisco Content Services Gateway - 2nd Generation, more commonly known as the Content Services Gateway 2 or CSG2, is an application that runs on the Cisco Service and Application Module for IP (SAMI), a high-speed processing module. The CSG2 provides content-aware billing, service control, traffic analysis, and data mining in a highly scalable, fault-tolerant package. The CSG2 provides the software required by mobile wireless operating companies and other billing, applications, and service customers. The CSG2 runs on the Cisco SAMI, a new-generation high performance service module for the Cisco 7600 series router platforms. The CSG2 is typically located at the edge of a network in an Internet service provider (ISP) point of presence (POP), or Regional Data Center. In addition to performing standard IP flow accounting, the CSG2 also examines various protocol requestse-mail, Domain Name System (DNS), HTTP, FTP, Real Time Streaming Protocol (RTSP), Session Initiation Protocol (SIP), wireless application protocol 1.x and 2.0 (WAP 1.x and WAP 2.0)to gather URLs and other header information for accounting purposes. Additionally, the CSG2 gathers information on subscriber names and usage statistics, and enables differentiated billing for individual transactions based on hostname, on the directory accessed, or on individual files. The CSG2 inspects IP traffic at levels deeper than typical routers. When doing so, the CSG2 behaves partly as a proxy server. Therefore, design your network security strategy to protect the CSG2 as you would any proxy or server. This section includes the following information:

Whats New, page 1-1 CSG2 Features, page 1-3 CSG2 Prerequisites, page 1-58 CSG2 Restrictions, page 1-58
Whats New
The CSG2 R5 includes the following new features for Cisco IOS Release 12.4(24)MDA4:
Regular Expression Match Capacity Increase for ContentsFor maps, the CSG2 supports:
Up to 1408 match patterns per map Up to 1408 total match patterns per policy Up to 1408 total match patterns per content Up to 8192 total match patterns per CSG2 (assuming there is enough memory available)
1-1
Chapter 1 Whats New
Overview
Configuring a Service Lifetime, page 5-4 Accelerated Sessions, page 1-54FTP, RTSP, and SIP Support Configuring Packet Logging and Reporting, page 2-53Support for IPv6 and Dual-Stack Addresses HTTP Header Insertion, page 1-25Support for IPv6 and Dual-Stack Addresses Accelerated Sessions, page 1-54Accelerated Virtual Prepaid Configurable Regex Memory, page 1-37 Configurable URL Map Normalization, page 1-37 Configuring RADIUS Proxy, page 9-2Reuse of Idle RADUS Proxy Ports RTSP TEARDOWN Reply Delay, page 1-31 User Session Continuation After PCRF Timeout, page 10-17 Accelerated Sessions, page 1-54 Cisco 7600 LTE Integration, page 10-7 Conditional CDR Blocking, page 1-10 Configuring RADIUS Proxy, page 9-2Reuse of Idle RADIUS Proxy Ports Gx Event Trigger Usage Reporting, page 10-15 Gx Service Groups, page 10-16 IPv6 Bearer Support and Dual-Stack, page 1-16 MIB Support, page 1-6Support for the following MIBs was added:
CISCO-CONFIG-MAN-MIB CISCO-ENTITY-ASSET-MIB CISCO-ENTITY-FRU-CONTROL-MIB CISCO-HSRP-EXT-MIB CISCO-HSRP-MIB CISCO-IP-STAT-MIB CISCO-MEMORY-POOL-MIB CISCO-QUEUE-MIB CISCO-RTTMON-MIB CISCO-VLAN-IFTABLE-RELATIONSHIP-MIB ETHERLIKE-MIB RSVP-MIB


The CSG2 R5 includes the following new features for Cisco IOS Release 12.4(24)MDA:

NBAR Protocol Support, page 1-50Support for Google Talk, MSN Messenger (Voice), Yahoo! Messenger (Voice)
1-2
OL-22840-05
Chapter 1
Overview CSG2 Features
CSG2 Features
The CSG2 Release 12.4(11)MD provides the following basic features and functionality:

Comparison of CSG1 and CSG2 Hardware Architectures, page 1-5 MIB Support, page 1-6 CSG2 Billing Criteria, page 1-7 CSG2 Interactions with External Entities, page 1-7 CDR Support, page 1-8 Byte Counting, page 1-10 CSG2 User Table, page 1-15 CSG2 Interface Awareness, page 1-18 Billing Plan Features, page 1-19 BMA Features, page 1-19 Quota Server Features, page 1-20 Service Features, page 1-20 IPC Features, page 1-21 PSD Features, page 1-21 iSCSI Features, page 1-22 RADIUS Features, page 1-22 Gx Features, page 1-23 Mobile PCC Features, page 1-24 HTTP Features, page 1-24 SIP Features, page 1-28 WAP Features, page 1-28 RTSP Features, page 1-30 DNS Support, page 1-35 POP3 Support, page 1-35 SMTP and POP3 Billing, page 1-36 SMTP CDR Header Removal, page 1-37 FTP Billing, page 1-37 Attribute, Header, Method, and URL Mapping, page 1-37 Configurable Regex Memory, page 1-37 Configurable URL Map Normalization, page 1-37 Service Duration Billing, page 1-38 Connection Duration Billing, page 1-43 Postpaid Service Tagging, page 1-44 Stateful Redundancy and Failover, page 1-44 Default Policy, page 1-45
1-3
Chapter 1 CSG2 Features
Overview
Tariff Switch, page 1-46 Prepaid Error Reimbursement, page 1-46 Postpaid Billing, page 1-47 Prepaid Content Billing and Accounting, page 1-47 Dual Quota Support, page 1-49 Quality of Service (QoS) Support, page 1-49 NBAR Protocol Support, page 1-50 License-Exceeded Notifications, page 1-53 User Logoff Notifications, page 1-53 Obtaining User IDs, page 1-53 Filtering Accounting, page 1-53 Intermediate CDRs, page 1-54 Accelerated Sessions, page 1-54 Packet Forwarding, page 1-55 Per-User Uplink Next-Hop Support, page 1-55 URL-Redirect, page 1-56 Supplemental Usage Reports, page 1-56 Enhanced Interoperability with Cisco Service-Aware GGSN, page 1-56 Miscellaneous Features, page 1-56
1-4
OL-22840-05
Chapter 1
Comparison of CSG1 and CSG2 Hardware Architectures

Figure 1-1 illustrates the key differences between the CSG1 hardware architecture and the CSG2 hardware architecture.
Figure 1-1 Comparison of CSG1 and CSG2 Hardware Architectures
CSG1
Pipelined Architecture Optimized for fast processors with limited memory space.
CSG2
Parallel Architecture Optimized for newer (faster) processors with expanded memory space. Control CPU SC8548
Inspection Path WAP 10, email, RTSP control, FTP control
Control CPU PPC405GP Traffic distribution
Traffic Processor SC8548 Traffic Processor SC8548 Traffic Processor SC8548 Traffic Processor SC8548
201839
Traffic Processor IXP 1200
Fast Path HTTP, L4, WAP 20, RTSP (RTP) data, FTP data
Traffic Processor SC8548
As can be seen, the CSG1 featured a pipelined architecture, with five IXP1200 traffic processors (TPs) running at 166MHz and one Power PC (PPC) 405GP control processor (CP) running at 166MHz. In contrast, the CSG2 features a parallel architecture, with one IXP2800 flow-distributor TP running at 1.4GHz, five PPC 8548 TPs running at 1.25GHz, and one PPC 8548 CP running at 1.25GHz. The benefits of the CSG2 approach include:

Increased processing power Reduced inter-CPU data sharing Separation of the control and data planes Reduced complexity Easier debugging
1-5
Overview
MIB Support
The CSG2 supports the following MIBs:

CISCO-CONFIG-MAN-MIB CISCO-CONTENT-SERVICES-MIB implemented in the Cisco IOS software. CISCO-ENHANCED-MEMPOOL-MIB CISCO-ENTITY-ASSET-MIB CISCO-ENTITY-FRU-CONTROL-MIB CISCO-ENTITY-VENDORTYPE-OID-MIB CISCO-HSRP-EXT-MIB CISCO-HSRP-MIB CISCO-IMAGE-MIB CISCO-IP-STAT-MIB CISCO-ISCSI-MIB CISCO-MEMORY-POOL-MIB CISCO-PING-MIB CISCO-PROCESS-MIB CISCO-PRODUCTS-MIB CISCO-PSD-CLIENT-MIB CISCO-QUEUE-MIB CISCO-RTTMON-MIB CISCO-SYSLOG-MIB CISCO-TCP-MIB CISCO-VLAN-IFTABLE-RELATIONSHIP-MIB ENTITY-MIB ETHERLIKE-MIB IF-MIB MIB II RMON2-MIB RSVP-MIB SNMP-FRAMEWORK-MIB SNMP-NOTIFICATION-MIB SNMP-TARGET-MIB SNMPv2-MIB SNMPv3-MIB TCP-MIB UDP-MIB
1-6
OL-22840-05
Chapter 1
CSG2 Billing Criteria

The CSG2 can bill different services based on different criteria, as shown in Table 1-1.
Table 1-1 CSG2 Billing Criteria
Service Internet and Corporate Access Multimedia Messaging Service (MMS) E-mail Broadcast Services Downloads, Ringtones, Music, etc. Games
Subscription Yes Yes Yes No No Yes
Event No Yes Yes Yes Yes No
Volume Yes No Yes No No No
Duration No No No Yes No Yes
Content No Yes No Yes Yes Yes
CSG2 Interactions with External Entities

The CSG2 communicates with several different external entities:
The Billing Mediation Agent (BMA)The BMA receives the billing records from the CSG2 and formats them as required by the billing engine. At the end of each transaction, a billing record indicating the content accessed and the amount deducted is sent to the BMA, so that it can be logged in the subscriber's bill. For more information about the BMA, see the Configuring BMA Support section on page 3-1 The Quota ServerThe CSG2 uses quota servers to return billing quota values for subscribers. The quota server interfaces with the billing system balance manager to reserve credit. The quota server then translates the reserved credit for the subscriber into quota based on the business and rating rules for multiple subscriber services on the CSG2. For more information about the quota server, see the Configuring Quota Server Support section on page 4-1
An External Extensible Markup Language (XML) User DatabaseThe CSG2 can use an XML database to associate an IP address with a user ID, and can refer to the database when it receives a packet with an unknown IP address. XML-based database queries add additional robustness to the CSG2, allowing continued monitoring across a failover, even in the absence of fresh RADIUS flows. For more information about the XML user database, see the Configuring the User Database section on page 2-9.
The Interprocessor Communication (IPC) ModuleThe CSG2 IPC module provides a communication channel between the CSG2 Control Processor (CP) and Traffic Processors (TPs), and, in a redundant CSG2 deployment, between the TPs on the active CSG2 and their counterparts on the standby CSG2. For more information about the IPC module, see the Configuring IPC Support section on page 6-1.
The Cisco Persistent Storage Device (PSD)The PSD provides backup capabilities as necessary, such as during network outages. The PSD stores the payload from a packet in a queue, and the data can be retrieved exactly as it was sent. For more information about the PSD, see the Configuring PSD Support section on page 7-1.
1-7
Overview
Internet Small Computer Systems Interface (iSCSI)Instead of using the PSD as backup storage, the CSG2 can use the Storage Area Network (SAN) connected to the iSCSI to store CDRs until the BMAs can be reached. For more information about the iSCSI, see the Configuring iSCSI Support section on page 8-1. The RADIUS Client and ServerRADIUS is a distributed client/server system that secures networks against unauthorized access. In the Cisco implementation, RADIUS clients run on Cisco routers and send authentication requests to a central RADIUS server that contains all subscriber authentication and network service access information. The RADIUS client and server retrieve subscriber correlation information (the IP address, the MSISDN, the User-Name, and the Billing Plan) for prepaid subscribers. The CSG2 acts as a RADIUS proxy or RADIUS endpoint to retrieve the subscriber correlation information. In addition, the CSG2 can report RADIUS attributes when it communicates with the BMA and quota servers. For more information about RADIUS clients and servers, see the Configuring RADIUS Support section on page 9-1.
Policy and Charging Rules Function (PCRF)Gx is a Third Generation Partnership Project (3GPP) Diameter application. In a Gx-enabled network, a Gx reference point is located between a PCRF and a Policy and Charging Enforcement Function (PCEF). The CSG2 can act as a PCEF, either as part of an eGGSN node, with a CSG2 and a GGSN as separate cards in a Cisco 7600 Series Router, or as a stand-alone Gi-node, with interoperability from external GGSNs. For more information about Gx features, see the Configuring Gx Support section on page 10-1.
CDR Support
The CSG2 provides the following call detail record (CDR) support:

Fixed CDR Support for HTTP, IMAP, RTSP, and WAP, page 1-8 Single CDR Support for HTTP and WAP Connectionless, page 1-8 Service-Level CDR Summarization, page 1-9 Prepaid and Postpaid Envelope Information Support for SMTP, page 1-9 Fixed Attribute CDRs for WAP, page 1-9 CDR Suppression for Unestablished TCP Connections, page 1-9 Conditional CDR Blocking, page 1-10
Fixed CDR Support for HTTP, IMAP, RTSP, and WAP

The CSG2 supports the generation of fixed-format CDRs for HTTP, IMAP, RTSP, and WAP. For more information, see the Configuring Fixed, Variable, or Combined Format CDR Support section on page 2-30.
Single CDR Support for HTTP and WAP Connectionless

For HTTP and WAP, the CSG2 reduces the multiple CDRs generated to a single CDR, which is reported at the end of the transaction. This feature is supported for both WAP connectionless and WAP connection-oriented traffic, as well as for HTTP traffic. For more information, see the Single CDR Support for HTTP and WAP section on page 2-32.
1-8
OL-22840-05
Chapter 1
Service-Level CDR Summarization

By default, the CSG2 generates billing records for each transaction. This large number of records might overwhelm the charging gateway (CG) or the collector. To prevent this situation, the CSG2 can summarize CDRs at the service level, instead of at the transaction level. For more information about service-level CDR summarization, see the Enabling Service-Level CDR Summarization section on page 5-9.
Prepaid and Postpaid Envelope Information Support for SMTP

The CSG2 provides SMTP with prepaid and postpaid support, including envelope information in the CDR. SMTP prepaid support includes all existing billing options (including IP bytes, TCP bytes excluding retransmissions, duration, and fixed). SMTP CDRs include e-mail envelope information as well as IP byte counts, TCP byte counts, and e-mail data (X-CSG-SIZE) byte counts for each e-mail message. When multiple e-mails are sent over a single TCP connection, each e-mail message is assigned byte counts until the start of the next e-mail message. The last e-mail is assigned bytes from the start of that e-mail until the end of the TCP connection. The return code reported in the CDR is the one returned for the DATA portion of the e-mail message. If the CSG2 does not receive that data return code, it reports the last error return code (other than 250) received for individual recipients (because a bad recipient return code might be the cause of the e-mail not being sent). If the CSG2 receives a QUIT before receiving any return code, it reports a default return code of 554 (Transaction failed). This enables the CSG2 to apply refunding via the SMTP return code value. If the subscriber runs out of quota in the middle of a transaction, the session is terminated and all known information is reported in a CDR. The application return code indicates whether the e-mail was received, and the authentication failure bit is set in the TCP flags field. There are no commands required to enable this support.
Fixed Attribute CDRs for WAP

To support some legacy billing systems, the CSG2 provides a fixed attribute format for WAP CDRs. The same set of attributes is reported in each CDR regardless of the Wireless Session Protocol (WSP) protocol data unit (PDU) type. CDRs contain zero-length attributes when there is no information to report, but the same set of attributes are always reported in the same sequence. There are no commands required to enable this support.
CDR Suppression for Unestablished TCP Connections

If a BMA receives too many CDRs simultaneously, it can become overloaded. If this occurs, many of the TCP sessions might be unable to complete the initial handshake, and each of those failed TCP sessions generates a CDR. To prevent this flood of CDRs from occurring, you can prevent the CSG2 from generating these CDRs. For more information, see the Configuring CDR Suppression for Unestablished TCP Connections section on page 2-40.
1-9
Overview
Conditional CDR Blocking

The CSG2 can selectively block the generation of the following types of CDRs:
Transaction-level and service-level CDRs of prepaid users By definition, the CSG2 cannot associate a pre-policy transaction with a policy, and thus cannot determine whether the transaction as prepaid. Therefore, even if you have configured the ip csg report block prepaid command, the CSG2 does not block the sending of pre-policy transaction-level CDRs of prepaid users.
Pre-policy transaction-level CDRs A pre-policy transaction is one that cannot be associated with a policy. A pre-policy transaction is one that meets one of the following criteria:
The TCP handshake does not complete. The TCP handshake completes but is not followed by a request. The HTTP post is issued but does not contain the full URL; the rest of the URL is never
received.
Transaction-level CDRs. of unknown users.
The CSG2 does not support the preloading of conditional CDR blocking. To enable conditional CDR blocking, use the ip csg report block command in global configuration mode.
Byte Counting
The CSG2 reports the number of IP bytes uploaded and downloaded, the number of TCP bytes uploaded and downloaded by the application, and the packet counts (or PDU counts for WAP records). These counts exclude the IP and TCP headers, as well as retransmissions. This section includes the following information:

Byte Counting Overview, page 1-10 HTTP Byte Counting, page 1-12 WAP Byte and Packet Counting, page 1-13 IMAP Byte Counting, page 1-14 FTP and RTSP Byte Counting, page 1-15 SIP Byte Counting, page 1-15 POP3 and SMTP Byte Counting, page 1-15 Byte and Packet Counting After a Failover, page 1-15 Flexible Accounting for Retransmitted TCP Segments, page 1-15
Byte Counting Overview

This section describes how the GGSN and the CSG2 handle traffic, including the types of packets that they might drop. This section includes the following information:

Byte Counting on the GGSN, page 1-11 Byte Counting on the CSG2, page 1-11
1-10
OL-22840-05
Chapter 1
Byte Counting on the GGSN

Typically, the GGSN forwards all packets to the upstream next-hop. However, the GGSN drops packets that meet one or more of the following conditions:

The packet is a broadcast or multicast packet. The packet contains a destination for which there is no forwarding route. The packet is a bad IP packet. For example, there might be a checksum error. The packet matches an ACL or filter that is configured to drop the packet. The IP option field is set within the IP header of the packet.
The GGSN does not forward the dropped packets to the CSG2, so the CSG2 does not count these packets.
Byte Counting on the CSG2

When the CSG2 receives a packet that matches an allowed content and service, it processes the packet and forwards it to the upstream next-hop. The CSG2 counts all forwarded packets. There are some conditions that might cause the CSG2 to drop a packet (although these dropped packets account for only a very small percentage of the total network traffic). For example, the CSG2 drops the following types of packets:

A packet for a TCP connection that is received after the TCP session has been closed or reset. This condition might occur if a handset is out-of-sync with a server. A packet for a TCP connection that does not generate a session because the signals are out-of-order. For example, the CSG2 might receive a SYN-ACK without receiving a SYN. This problem might be caused by network congestion, or by an out-of-sync condition. An out-of-order TCP packet. This problem might also be caused by network congestion or an out-of-sync condition. A packet that matches a content or service that is disallowed. A packet that does not match any allowed content. A packet that is received after a user has exhausted his quota and before the quota server has responded to a request for more quota. A packet that is received while the CSG2 is waiting for a Service Authorization Response. A packet that contains a destination for which there is no forwarding route, A bad IP packet, such as a packet with a checksum error. A packet matches an ACL or filter that is configured to drop the packet.
The CSG2 does not count packets that are dropped. The CSG2 also does not count some other types of packets, such as:

A packet that matches a content that belongs to a free service. A packet that is generated by the CSG2, such as a reset (RST) for an unexpected TCP signal or AoC signaling.
1-11
Overview
HTTP Byte Counting

HTTP 1.1 allows a client to send multiple HTTP requests without waiting for the corresponding responses. Therefore, a single IP datagram might contain requests or responses for more than one HTTP transaction. The CSG2 reports the total number of IP bytes of an HTTP transaction transferred between a client and a server. The CSG2 counts the IP bytes for the TCP session SYN as part of the first transaction. The CSG2 counts the IP bytes for the TCP session FIN, FIN/ACK, or RST as part of the last transaction. The CSG2 counts the IP and TCP header bytes of an IP datagram that contains multiple transactions as part of the first transaction in the datagram. If the CSG2 receives retransmitted SYN packet before it receives the first SYN/ACK from the server, it includes the IP bytes for the retransmitted SYN packet in the byte counts in the HTTP_Stats CDR. The CSG2 discards out-of-order FIN packets, even if they contain data, and depends on retransmission of the out-of-order FIN packets to ensure correct billing. If the final ACK on a TCP 3-way handshake is retransmitted, the CSG2 does not report the IP bytes associated with the retransmitted ACK in the HTTP_Stats CDR. To enable the CSG2 to count fixed-format HTTP IP bytes more accurately, a new CDR and a new TLV have been added to the existing fixed HTTP intermediate CDRs. If HTTP header insertion is enabled, the CSG2 counts the HTTP IP bytes before header insertion takes place. There are no commands required to enable HTTP IP byte counting. This section includes the following additional information:

HTTP IP Bytes vs. TCP Bytes, page 1-12 Policy Matching for HTTP Downgrade, page 1-13 Counting Uncorrelated HTTP IP Bytes, page 1-13 Packet Counts for Pipelined HTTP, page 1-13 TCP Byte Counts for Accelerated Sessions, page 1-13
HTTP IP Bytes vs. TCP Bytes

The CSG2 reports the total number of IP bytes of an HTTP transaction transferred between a client and a server. For a given transaction, there will always be more IP bytes than TCP bytes. For HTTP quota management, the billing process has always managed IP bytes, not TCP bytes (for basis byte ip) and has always provided transaction grants as IP bytes. From a system behavior point of view, the CSG2 quota management for HTTP may appear different, because the forwarding process takes the granted quota and applies it to IP bytes instead of TCP bytes. For example, an empty TCP packet for HTTP would have previously consumed 0 bytes of IP quota - now it would take 40 (assuming standard IP and TCP header size).
Note
If you want the CSG2 to continue to report TCP byte counts for HTTP transactions, you can configure a service with basis byte tcp to count TCP bytes instead of IP bytes as quadrans, and you can configure the CSG2 to inspect BMA records for reported TCP byte counts.
1-12
OL-22840-05
Chapter 1
Configuring basis byte tcp allows counting of only TCP payload and exclusion of overhead for network retransmission. With this option, the CSG2 excludes IP and TCP headers from volume counts. Retransmitted packets are also not counted.
Policy Matching for HTTP Downgrade

This feature enables the CSG2 to process TCP packets carrying HTTP messages. The CSG2 does not count packets that are queued or dropped. The CSG2 can support up to 65536 concurrent active HTTP transactions per session. When parsing HTTP Method, Request-URI, or Message-Headers, the CSG2 might downgrade from Layer 7 inspection to Layer 4 inspection.

If this occurs, and if there is a catch-all policy configured for the content, the CSG2 assigns the default policy and counts the new bytes in the downgraded transaction. If there is no catch-all policy, but the block command is configured for the policy, the CSG2 does not allow the downgraded transaction to pass. If there is neither a catch-all policy nor a block command configured for the policy, the CSG2 counts the new bytes as unaccounted bytes (slop).
Counting Uncorrelated HTTP IP Bytes

Sometimes the CSG2 cannot correlate some IP bytes to any transaction at the end of a TCP session. This can include any retransmits or ACKs without payloads that are received after the CSG2 has reported the CDR for a specific transaction. You can configure the CSG2 to include these IP bytes in its reports by setting the records delay command in CSG2 content configuration mode to a non-zero value.
Packet Counts for Pipelined HTTP

Packet counts for pipelined HTTP operations are a snapshot of the number of packets detected on the connection since the previous statistics were reported. The packet count might even be zero if two pipelined operations share the same packet.
TCP Byte Counts for Accelerated Sessions

TCP bytes are not reported in CDRs for accelerated sessions. For accelerated sessions, the number of TCP bytes reported in the TCP Stat TLV is set to 0.
WAP Byte and Packet Counting

WAP byte counting is always IP-based. The CSG2 reports WAP datagram sizes (including IP and UDP headers), the number of IP packets per transaction, and PDU counts. (The PDU count is not the same as the packet count. Multiple WAP PDUs can share a single packet.) Bytes for retransmitted WAP PDUs and segments are not counted against quota, but they are counted and listed separately from non-retransmitted counts in the WAP CDRs. Byte and PDU counts are further specified by source. Reports include the number of bytes and PDUs uploaded from source to destination and the number of bytes downloaded from destination to source. The CSG2 splits all concatenated PDUs received from the client into multiple IP packets to be sent to the server. Therefore, packet counts are based on the number of WAP PDUs, not on the number of IP packets.
1-13
Overview
Byte counting for concatenated PDUs is complicated because multiple transactions are combined into a single IP packet. For example, a concatenated CONNECT/GET shares the same IP/UDP headers, yet they are treated as two separate transactions, they result in two separate CDRs, and they might even be charged differently from each other. In addition to the IP/UDP headers, there are several other bytes in the packet that define it as a concatenated packet. It might not be obvious to which transaction these bytes are assigned. Here is how the CSG2 assigns the IP bytes:

The size of the IP/UDP headers (usually 28 bytes) is assigned to the first PDU. The single byte that identifies the packet as a concatenated packet is also be assigned to the first PDU. A one- or two-byte length field is assigned to each PDU.
For example, a CONNECT/GET concatenated PDU that contains one-byte PDU length fields yields the following byte count totals:

CONNECT transaction = IP/UDP header length + 1 + 1 + PDU size GET transaction = 1 + PDU size
IMAP Byte Counting

Service-level fixed-format CDRs for IMAP include the following IMAP-specific counts:

Number of header retrievals. That is, the number of times that the CSG2 retrieved the header attribute of an e-mail message (for example, BODY[HEADER], RFC822.HEADER). Header IP bytes sent upstream (client to server) Header IP bytes sent downstream (server to client) Header TCP bytes sent upstream Header TCP bytes sent downstream Number of body retrievals. That is, the number of times that the CSG2 retrieved any portion of the body text of an e-mail message (for example, BODY[], BODY[TEXT], BODY[3], BODY[]<0.4096>, RFC822, RFC822.TEXT). Body IP bytes sent upstream Body IP bytes sent downstream Body TCP bytes sent upstream Body TCP bytes sent downstream
The CSG2 reports incremental byte counts for the IMAP service-level fixed-format CDRs. For example, if 100 KB of traffic is generated for the first 15 minutes, 50 KB for the next 15 minutes, and the CSG2 generates intermediate CDRs every 15 minutes, then the CSG2 reports the change in the total byte count from the point at which the last CDR was reported to the point at which the current CDR is reported. Thus, the first CDR would report 100 KB, and the second would report 50 KB. With fixed-format CDRs, the incremental byte counts might be reported at a given time interval or after a volume threshold has been reached (for example, every 15 minutes, or after every 100 KB.) For IMAP byte counting, keep the following considerations in mind:

Message tags cannot be longer than 100 bytes. If the CSG2 encounters a message with a tag that is longer than 100 bytes, only the IP and TCP upstream and downstream byte counts are reported. The byte counts associated with a continuation response flow are accounted for in the next classified transaction.
1-14
OL-22840-05
Chapter 1
FTP and RTSP Byte Counting

For FTP and RTSP, the CSG2 reports the upstream and downstream IP bytes and TCP bytes. Even though FTP and RTSP data sessions usually appear to be network-initiated, the uploaded bytes for FTP and RTSP (for example, in IP statistics) are counted from the originator of the session, the endpoint from which the first packet for the session is received.
Note
For service-level CDRs, the uploaded bytes for FTP and RTSP are counted from the subscriber to the network, and the downloaded bytes are counted from the network to the subscriber. The CSG2 discards out-of-order FIN packets, even if they contain data, and depends on retransmission of the out-of-order FIN packets to ensure correct billing.
SIP Byte Counting

For SIP, the CSG2 reports the upstream and downstream IP bytes and TCP bytes. You cannot charge SIP subscriber sessions as a function of the TCP data volume processed. (That is, you cannot configure basis byte tcp in CSG2 service configuration mode for SIP.) You can charge SIP transactions based on transaction duration time, using the basis seconds transaction command in CSG2 service configuration mode.
POP3 and SMTP Byte Counting

For Post Office Protocol, version 3 (POP3) and SMTP, the CSG2 reports the upstream and downstream IP bytes and TCP bytes.
Byte and Packet Counting After a Failover

After a failover, the standby CSG2 (now the active CSG2) considers the first 32 KB TCP bytes received to be retransmitted packets and does not count TCP bytes for those packets. However, the IP byte count is counted normally.
Flexible Accounting for Retransmitted TCP Segments

By default, the CSG2 includes IP bytes and packets for retransmitted TCP segments when counting IP bytes. However, you can prevent the CSG2 from including those IP bytes and packets. For more information, see the Configuring Flexible TCP Packet Counting section on page 2-42.
CSG2 User Table

The CSG2 User Table identifies all subscribers known to the CSG2. The CSG2 User Table can hold up to 1,250,000 entries with the 2 GB-SAMI option, or up to 500,000 entries with the 1 GB-SAMI option. The User Table is populated based on the contents of RADIUS Accounting Start messages, or from the user database, if either feature is enabled in your configuration. For more information about the User Table, see the following sections:
1-15
Overview
IPv6 and Dual-Stack Addresses in the CSG2 User Table, page 1-16 Configuring the CSG2 User Table section on page 2-9
IPv6 Bearer Support and Dual-Stack

The CSG2 supports the use of IPv4, IPv6, and dual-stack addresses for most new and existing features. A dual-stack implementation is one that uses both IPv4 and IPv6 addresses. To define the subset of Layer 3 and Layer 4 flows that can be processed by the CSG2 accounting services using IPv6 addressing, use the ipv6 command in CSG2 content configuration mode. To configure an IPv6 client group for a content, specify the IPv6 access list name using the client-group command in CSG2 content configuration mode To configure an IPv6 next-hop address for a content, specify the IPv6 address using the next-hop command in CSG2 content configuration mode This section includes the following information:

IPv6 and Dual-Stack Addresses in the CSG2 User Table, page 1-16 IPv6 and Dual-Stack Feature Limitations and Exceptions, page 1-17
IPv6 and Dual-Stack Addresses in the CSG2 User Table

The CSG2 User Table supports IPv4, IPv6, and dual-stack addresses. For IPv6 and dual-stack addresses, the RADIUS Accounting Request packets for a bearer must contain the Framed-IPv6-Prefix. The User Table indexes subscribers as follows:

IPv4 subscriberThe User Table entry is indexed by the subscriber's IPv4 address. IPv6 subscriberThe User Table entry is indexed by the subscriber's /64 IPv6 prefix. The subscriber can be represented in the User Table by many IPv6 addresses, but all of the addresses must correspond to the same /64 IPv6 prefix. Even if a subscriber is represented by more than one IPv6 address, the address does not change during the lifetime of an individual flow. The CSG2 does not support variable-length IPv6 prefixes. Only the /64 IPv6 prefix is supported. Dual-stack subscriberThe User Table entry is indexed by the subscriber's /64 IPv6 prefix.
All IPv4 flows for a dual-stack User Table entry use a single IPv4 address. This IPv4 address
can change during the lifetime of the User Table entry. That is, the IPv4 address can be deallocated and the same or a different IPv4 address can be allocated.
All IPv6 flows for a dual-stack User Table entry use an IPv6 address formed from a single /64
IPv6 prefix. Again, the subscriber can be represented by many IPv6 addresses, but all of the addresses must correspond to the same /64 IPv6 prefix.
A dual-stack subscriber might be represented by many IPv6 addresses, provided the addresses
all correspond to the same /64 IPv6 prefix.

The CSG2 treats a dual-stack subscriber as a single user. For example, the IPv4 and IPv6 flows
for the subscriber share services, quota, Gx session, Gx volume thresholds and counts, and so on. The CSG2 sends both the IPv4 and the IPv6 addresses when communicating with the BMA, the quota server, and the PCRF.
1-16
OL-22840-05
Chapter 1
IPv6 and Dual-Stack Feature Limitations and Exceptions

All new and existing CSG2 features support IPv6 and dual-stack addresses, with the following limitations and exceptions:

A given CSG2 content cannot be configured to support both IPv4 and IPv6 addresses. Each content can support only a single type of IP address, either IPv4 or IPv6. You can configure both IPv4 and IPv6 client groups and next-hop addresses for a given content. However, the CSG2 uses only the client group or next-hop address that matches the content configuration (IPv4 or IPv6). A subinterface that is enabled for interface awareness and is configured for both IPv4 and IPv6 has the following requirements:
The VRF table must be defined using the vrf definition command in global configuration mode.
Do not use the ip vrf command.

The vrf forwarding command must be configured in interface configuration mode. The subinterface must be associated with the same VRF table (or default routing table) for both
IPv4 and IPv6. For example, the following configuration is valid because:
It uses the vrf definition and vrf forwarding commands. The GigabitEthernet0/0.20 subinterface is associated with VRF V4-V6 for both IPv4 and IPv6. The GigabitEthernet0/0.30 subinterface is associated with the default routing table for both
IPv4 and IPv6.

vrf definition V4-V6 address-family ipv4 exit-address-family ! address-family ipv6 exit-address-family ! interface GigabitEthernet0/0.20 vrf forwarding V4-V6 encapsulation dot1Q 20 ip csg subscriber ip address 10.10.20.100 255.0.0.0 ipv6 address 10:10:20: :100/64 ! interface GigabitEthernet0/0.30 encapsulation dot1Q 30 ip csg subscriber ip address 172.10.20.100 255.255.255.0 ipv6 address 172:10:20: :100/64
However, the following configuration is not valid because the GigabitEthernet0/0.40 subinterface is associated with the V4-Only VRF table for IPv4 and with the default routing table for IPv6:
ip vrf V4-Only ! interface GigabitEthernet0/0.40 encapsulation dot1Q 40 ip vrf forwarding V4-Only ip address 10.10.40.100 255.0.0.0 ipv6 address 10:10:40: :100/64
1-17
Overview
The CSG2 supports IPv6 or dual-stack addresses for all supported protocols except NBAR-classified protocols. However, the FTP and SIP control and data sessions must both be either IPv4 or IPv6. The CSG2 does not support mixed IPv4/IPv6 control and data sessions for FTP or SIP. For a given session, the CSG2 does not support Network Address Translation (NAT) between IPv4 and IPv6. The CSG2 does not support IPv6 or dual-stack addresses for the PSD. The CSG2 does not support any IPv6-specific MIBs. The CSG2 does not support IPv6 or dual-stack addresses for the following features:
Fixed format CDRs GTP over IPv6 on the BMA or quota server interface HTTP X-Forwarded-For NBAR protocol support XML user database
CSG2 Interface Awareness

Many provider networks offer data access, control over subscriber addressing, and dedicated Virtual Routing and Forwarding (VRF) over the wireless network to enterprises and Mobile Virtual Network Operators (MVNOs). Interface awareness uses VRF tables to enable the CSG2 to distinguish between subscribers and sessions that share the same IP address on different VLANs (that is, subscribers and sessions with overlapping IP addresses). Configurations with overlapping IP address requirements cannot use the CSG2 RADIUS user database to determine the users identity, because user database queries do not include VRF table information. Because the quota server can only respond to the CSG2 (that is, there can be no quota server-initiated messages), the Extended User Index TLV is required to in order to identify or trigger action for a subscriber within a CSG2 table. To support traffic segregation across VLANs, the CSG2 uses next-hop to bind flows to uplink and downlink routing hops. The CSG2 routes uplink packets (from the Network Access Server [NAS]) by applying next-hop policies to the contents on each NAS VLAN. The CSG2 routes downlink packets via the downlink address supplied by the NAS in the RADIUS Accounting Start message. Logically, that means that a dedicated per-VLAN NAS is required for interface awareness. Physically, however, it depends on the capabilities of the NAS. Each RADIUS proxy statement can have a table name. When a User Table entry is created as a result of a Start message sent to that proxy IP address, the specified table name is associated with the subscriber. Depending on your network, you might choose to route this subscriber's traffic different from another subscriber's traffic, even when the source or destination IP addresses are the same. To do so, use the next-hop command in CSG2 content configuration mode, or specify the downlink next-hop in the Start message. To associate a VRF table name with a particular CSG2 component, specify the vrf keyword on the appropriate ip csg command in global configuration mode. For example, to associate a VRF table name with a particular RADIUS proxy, specify the vrf keyword on the ip csg radius proxy command in global configuration mode. When configuring Interface Awareness, keep the following considerations in mind:

Table IDs and names are not supported or reported in fixed-format TLVs. If a content configuration is required on multiple VLANs, you must define the content multiple times, once for each of the VLANs on which it is required. Contents cannot be shared across tables.
1-18
OL-22840-05
Chapter 1
VLAN-specific content configurations must handle all traffic from subscribers arriving on a VLAN marked with a table name. The CSG2 uses the VLAN table name to locate subscriber entries. Therefore, if you want to apply the same contents to multiple tables, you must redefine all of your contents. The CSG2 does not support the use of the word forwarding as a valid VRF name.
For additional requirements for a subinterface that is enabled for interface awareness and is also configured for both IPv4 and IPv6, see the IPv6 and Dual-Stack Feature Limitations and Exceptions section on page 1-17.
Billing Plan Features

A CSG2 billing plan is a set of services. When the CSG2 encounters a new subscriber, the CSG2 retrieves the subscribers billing plan. The CSG2 provides the following billing plan features:

Configuring a Billing Plan Offline Billing Control Assigning a Default Billing Plan Displaying Billing Plan User Counts
BMA Features
The CSG2 monitors data flows and generates accounting records that can be used to bill customers at a content level. The CSG2 sends the accounting records to a Billing Mediation Agent (BMA), which formats the records as required by the customers billing system. At the end of each transaction, a billing record indicating the content accessed and the amount deducted is sent to the BMA, so that it can be logged in the subscriber's bill. The CSG2 provides the following BMA features:

Configuring the BMA Local Port Configuring a BMA Configuring the BMA Keepalive Time Configuring the BMA GTP Message Buffer Configuring the BMA Retransmit Time Configuring the BMA Retry Number Configuring the BMA Window Size Configuring BMA Load Sharing Reporting the Billing Plan ID to the BMA
For descriptions of these features, and instructions for configuring them, see the Configuring BMA Support procedure on page 3-1.
1-19
Overview
Quota Server Features

The CSG2 uses quota servers to return billing quota values for subscribers. The quota server interfaces with the billing system balance manager to reserve credit. The quota server then translates the reserved credit for the subscriber into quota based on the business and rating rules for multiple subscriber services on the CSG2. For each CSG2 content billing service, the CSG2 downloads a separate quota, and deducts from that quota. Quotas are specified in units called quadrans. A quadran is a generic unit whose value is defined by each quota server. A quadran can represent, for example, a click for a per-click service (for example, an HTTP request), or a byte for a per-volume service. The value of a quadran is transparent to the CSG2; the CSG2 simply requests and downloads quadrans as needed from quota servers. The CSG2 provides the following quota server features:

Configuring the Quota Server Local Port Configuring a Quota Server Configuring the Quota Server Keepalive Time Configuring the Quota Server GTP Message Buffer Configuring the Quota Server Retransmit Time Configuring the Quota Server Retry Number Configuring the Quota Server Window Size Configuring Quota Server Load Sharing Reassigning Subscribers to a New Quota Server Sending User Profile Requests to Quota Servers Quota Push Replacing Quota Balance Delaying Quota Reauthorization Asynchronous Quota Return Reporting the Billing Plan ID to the Quota Server Pricing by Quota Server Configuration Example Differentiating Prices Configuration Example Reducing the Number of Services Configuration Example
For descriptions of these features, and instructions for configuring them, see the Configuring Quota Server Support procedure on page 4-1.
Service Features
A CSG2 content billing service is a component of a billing plan to which subscribers subscribe. You can configure one or more content billing services for the CSG2. Each service represents a group of content that is billed the same way, such as billing per-click (or per-request) or billing per-IP byte, and that shares part of a subscribers quota. Grouping content into one or more services enables you to separate, for example, a subscribers prepaid quota for Internet browsing from his quota for e-mails. The CSG2 provides the following features for content billing services:
1-20
OL-22840-05
Chapter 1
Configuring a Basic Content Billing Service Configuring the Billing Basis for a Service Specifying a Service Owner Specifying a Service Class Configuring a Service Idle Time Configuring a Service Lifetime Configuring Advice of Charge Configuring Service Verification Enabling Service-Level CDR Summarization Support for eG-CDRs with GGSN Configuring Passthrough Mode and the Default Quota Configuring Metering Configuring the Quota Reauthorization Threshold Configuring the Quota Reauthorization Timeout Final Unit Indication Enabling a Refund Policy for a Service Configuring Content Access Control
For descriptions of these features, and instructions for configuring them, see the Configuring Service Support procedure on page 5-1.
IPC Features
The CSG2 Interprocessor Communication (IPC) module provides a communication channel between the CSG2 Control Processor (CP) and Traffic Processors (TPs), and, in a redundant CSG2 deployment, between the TPs on the active CSG2 and their counterparts on the standby CSG2. The CSG2 provides the following IPC features:

Configuring the IPC Keepalive Time Configuring the IPC Retransmit Time Configuring the IPC Retry Number Changing the IPC Crash Dump Setting
For descriptions of these features, and instructions for configuring them, see the Configuring IPC Support procedure on page 6-1.
PSD Features
The Cisco Persistent Storage Device (PSD) provides persistent storage capabilities to the CSG2, and allows the CSG2 to store data on the PSDs internal hard drive. The CSG2 provides the following PSD features:

Configuring the PSD Local Port Configuring the PSD
1-21
Overview
Configuring the PSD Packet Drain Settings Configuring the PSD Keepalive Time Configuring the PSD GTP Message Buffer Configuring the PSD Retransmit Time Configuring the PSD Retry Number Configuring the PSD Window Size
For descriptions of these features, and instructions for configuring them, see the Configuring PSD Support procedure on page 7-1.
Note
The CSG2 supports the Cisco Persistent Storage Device Module Software Release 2.0 or later. The CSG2 does not support IPv6 addresses for the PSD.
iSCSI Features
The CSG2 can use a Storage Area Network (SAN) connected to an Internet Small Computer Systems Interface (iSCSI) to store CDRs when BMAs are unreachable. The CSG2 provides the following iSCSI capabilities:

iSCSI Overview Configuring an iSCSI Target Interface Profile on the CSG2 Associating an iSCSI Target Interface Profile with the CSG2 Configuring the iSCSI Packet Drain Settings Verifying the iSCSI Session
For descriptions of these capabilities, and instructions for configuring them, see the Configuring iSCSI Support procedure on page 8-1.
RADIUS Features
RADIUS is a distributed client/server system that secures networks against unauthorized access. In the Cisco implementation, RADIUS clients run on Cisco routers and send authentication requests to a central RADIUS server that contains all subscriber authentication and network service access information. The RADIUS client and server retrieve subscriber correlation information (the IP address, the MSISDN, the User-Name, and the Billing Plan) for prepaid subscribers. The CSG2 acts as a RADIUS proxy or RADIUS endpoint to retrieve the subscriber correlation information. In addition, the CSG2 can report RADIUS attributes when it communicates with the BMA and quota servers. The CSG2 provides the following RADIUS features:

Configuring RADIUS Proxy Configuring RADIUS Endpoint Configuring RADIUS Handoff Configuring RADIUS Packet of Disconnect Configuring RADIUS Change of Authorization
1-22
OL-22840-05
Chapter 1
Configuring RADIUS Monitor RADIUS Attributes and VSA Subattributes Enabling RADIUS Roaming Service Control Enabling RADIUS Geo-Redundancy Retrieving the Billing Plan ID from RADIUS RADIUS Subscriber Cleanup RADIUS Error Acknowledgment RADIUS Correlation Processing
For descriptions of these features, and instructions for configuring them, see the Configuring RADIUS Support procedure on page 9-1.
Gx Features
CSG2 provides policy control via the Gx interface. Gx is a Third Generation Partnership Project (3GPP) Diameter application. In a Gx-enabled network, a Gx reference point is located between a Policy and Charging Rules Function (PCRF) and a Policy and Charging Enforcement Function (PCEF). The CSG2 can act as a PCEF, either as part of an eGGSN node, with a CSG2 and a GGSN as separate cards in a Cisco 7600 Series Router, or as a stand-alone Gi-node, with interoperability from external GGSNs. The CSG2 provides the following Gx features:

Support for the Cisco eGGSN for Cisco GGSN Release 10.0 and the Single IP Feature, page 10-5 Enabling Gx on the CSG2, page 10-3 Configuring a User Profile, page 10-3 Support for Single IP GGSN, page 10-5 Dynamic Redirection, page 10-6 Cisco 7600 LTE Integration, page 10-7 Preloading Policies, page 10-8 Support for Gx TCP Signature Reporting, page 10-11 Dynamic Provisioning of 3GPP Per-User DGRs, page 10-11 Dynamic Provisioning of Cisco Per-User DGRs, page 10-12 Gx Event Triggers, page 10-13 Volume and Duration Triggers, page 10-14 Per-Subscriber Volume and Time Thresholds, page 10-14 Service Flow Detection Triggers, page 10-15 Gx Event Trigger Usage Reporting, page 10-15 Gx Service Groups, page 10-16 Billing Plan Assignment and Modification, page 10-16 PDP Context QoS Signaling, page 10-16 Secondary PDP Context Activation, page 10-17
1-23
Overview
PCRF-Specified Service-Level and User-Level QoS, page 10-17 PCRF Failure Handling, page 10-17 User Session Continuation After PCRF Timeout, page 10-17 Restrictions for Gx, page 10-18
For descriptions of these features, and instructions for configuring them, see the Configuring Gx Support procedure on page 10-1.
Note
Gx features in the CSG2 R5 and later require the 2 GB-SAMI option. The CSG2 R5 and later on the 1 GB-SAMI option does not support Gx.
Mobile PCC Features

Cisco Mobile Policy Control & Charging (PCC) provides a generic PCC infrastructure that supports a Diameter-based policy control interface that can be easily tailored to meet the needs of various application gateways, such as the CG2 and eGGSN. The CSG2 provides the following Mobile PCC features:

Per-User PCC Policy Preloading PCRF Load Balancing Handling Redundancy in PCC Handling Response Codes in PCC Mobile PCC Configuration Examples
For descriptions of these features, and instructions for configuring them, see the Configuring Mobile PCC Support procedure on page 11-1.
HTTP Features
The CSG2 provides the following HTTP features:

HTTP Pipelining and Chunked Transfer Encoding, page 1-25 Support for Multipart HTTP, page 1-25 HTTP Header Insertion, page 1-25 HTTP 1.0 Content Billing, page 1-25 HTTP 1.1 Content Billing, page 1-25 HTTP Records Reporting Flexibility, page 1-26 HTTP Error Code Reporting, page 1-26 Out-of-Order Forwarding of HTTP Packets, page 1-26 Relative URI Matching, page 1-26 Learning Client IP Addresses Using Inspection of HTTP X-Forwarded-For Headers, page 1-27 Restrictions for HTTP, page 1-27
There are no commands required to enable these features, unless otherwise indicated.
1-24
OL-22840-05
Chapter 1
HTTP Pipelining and Chunked Transfer Encoding

The CSG2 supports full HTTP pipelining and chunked transfer encoding. Packet counts for pipelined HTTP operations are a snapshot of the number of packets detected on the connection since the previous statistics were reported. The packet count might even be zero if two pipelined operations share the same packet. If pipelined connections are replicated to a standby CSG2, and a failover occurs, the CSG2 does not increment the content counters for traffic flowing through these connections. The CSG2 does increment the content counters for new pipelined connections created after the failover. When performing AoC for a TCP connection carrying pipelined HTTP requests, the CSG2 responds with the redirect to the client as soon as the quota server requests the redirect. This could result in the redirect arriving at the client before responses for previous requests arrive, and the client might associate the redirect with a different request in the pipeline.
Support for Multipart HTTP

For HTTP sessions, multipart content does not cause the CSG2 to invoke Layer 4 billing for the remainder of the connection. Instead, the CSG2 parses the data for the delimiter specified in the header and continues to use Layer 7 billing.
HTTP Header Insertion

The CSG2 can insert a configured set of headers into HTTP requests that match a policy or service. The network server uses the data in the inserted headers when determining how to fulfill the HTTP request. You can configure headers and header groups for the CSG2 to insert in HTTP requests. When you configure a header for the CSG2, you can assign it to a class of headers, and you can specify a default include or exclude behavior for that class of headers. HTTP headers flow in the clear over the Internet to the network server. However, you can configure the CSG2 to encrypt the data portion of a header using the Triple Data Encryption Algorithm (3DEA). Wireless TCP (WTCP) for header insertion is supported. WTCP is a proxy-based modification of TCP that is used in wireless networks to improve performance. For detailed information about HTTP header insertion, see the Configuring Header Insertion section on page 2-25.
HTTP 1.0 Content Billing

The CSG2 enables you to bill subscribers for individual transactions by discriminating on a per-object basis, and on a per-subscriber basis. Unlike traditional billing models, which bill for broad classes of traffic, this service enables differentiated billing based on the actual object being requested. You can even bill objects at different rates to different customers. For example, you can bill advertisements to the advertiser, rather than to the subscriber.
HTTP 1.1 Content Billing

The CSG2 separately records each request over a persistent HTTP 1.1 session.
1-25
Overview
HTTP Records Reporting Flexibility

The clients IP address is included in the HTTP Header message. This enables the BMA to identify the client by user ID (and by IP address) immediately, without having to wait for the HTTP Statistics record. You can configure the CSG2 to send the HTTP Header message as soon as it is generated. This reduces latency and notifies the BMA about the clients transaction as quickly as possible. Although this type of reporting is more efficient, it provides less information; use it only when the BMA needs to react to the clients activity very quickly. You can configure the CSG2 to not send the HTTP Statistics message. This configuration reduces the load on the BMA and is useful when the billing policy depends only on the event and does not require detailed statistics. Note that the CSG2 still sends the HTTP Statistics message if the session fails (for example, if a Reset [RST] is received without a Finish [FIN], or if the session times out).
HTTP Error Code Reporting

The CSG2 reports HTTP-specific information about the request, such as the URL, as well as HTTP error codes (response codes of 300 or higher).
Out-of-Order Forwarding of HTTP Packets

The CSG2 parses most HTTP packets that it receives, but it does not always parse packets that contain only payload data, such as JPG files or other binary data. The CSG2 enforces ordering of those unparsed packets by queueing out-of-order packets or dropping them if the queue is full. However, the CSG2 can count and forward those unparsed packets out-of-order if they meet one of the following conditions:
The CSG2 has determined that the packet lies within the unparsed range of an HTTP request/response. The request/response should not be multipart or chunked. The unparsed range is determined based on the Content-Length field in the headers of the request/response. The CSG2 has determined that the remainder of the request/response will not be parsed. The CSG2 makes this determination if the request/response header is not chunked and has a Content-Type field but no Content-Length field. The CSG2 has downgraded the packet from Layer 7 inspection to Layer 4 inspection
Forwarding the packets without enforcing packet ordering reduces the CSG2's impact on TCP flows, prevents the throttling of HTTP flows, and increases overall HTTP throughput. The CSG2 closes a transaction when the first response packet for the next transaction is received. For HTTP pipelined requests, that can lead to an increase in bytes that are counted as unaccounted bytes (slop). To mitigate this situation, use the records delay command in content configuration mode to delay the generation of HTTP transaction CDRs (and the closing of those transactions).
Relative URI Matching

The CSG2 supports relative Uniform Resource Identifiers (URIs) for URL matching. This feature enables the CSG2 to match URL patterns even for HTTP requests that do not include the full URL. For example, the following HTTP request includes the full URL, including the host field in the URI: GET http://www.yahoo.com/index.htm HTTP/1.1 However, an HTTP request that is not sent to a proxy might not include the full URL, and might look like this: GET /index.htm HTTP/1.1
1-26
OL-22840-05
Chapter 1
It can be difficult to configure URL match patterns for such requests. Relative URI support enables the CSG2 to:

Determine whether the URI in an HTTP request is a relative URI. Parse the host header of the HTTP request for the host information. Prefix the URI with http:// and the host information for relative URIs before matching a URL map.
Relative URI support enables content providers to support non-proxied mobile users. To enable relative URI support for CSG2 URL matching, use the relative command in CSG2 content configuration mode. The following example shows how to enable relative URI support for content RURI-CONTENT:
ip csg map RURI-MAP match url http://172.18.71.122/index.html ! ip csg policy RURI-POLICY map RURI-MAP ! ip csg content RURI-CONTENT ip 172.18.71.122 any parse protocol http relative policy RURI-POLICY inservice
The CSG2 supports relative URIs for HTTP only.
Learning Client IP Addresses Using Inspection of HTTP X-Forwarded-For Headers

If your network is configured with a gateway or proxy placed between the client and the CSG2, you can configure the CSG2 to determine the clients IP address by inspecting the HTTP X-Forwarded-For header. The CSG2 can also obscure the contents of X-Forwarded-For headers, overwriting the contents with blanks, thereby preventing the exposure of potentially sensitive IP addresses. To configure the way the CSG2 is to handle X-Forwarded-For headers, use the subscriber-ip http-header x-forwarded-for (CSG2 content) command in CSG2 content configuration mode.
Restrictions for HTTP

For HTTP, the CSG2 imposes the following restrictions:

HTTP and HTTPS cannot share the same port. However, SSL can be tunneled over HTTP using the Connect method. When HTTP X-Forwarded-For is enabled, only one CSG2 Traffic Processor (TP) is used for the entire system. The CSG2 does not support IPv6 or dual-stack for HTTP X-Forwarded-For. With RFC 2818, an HTTP session can become encrypted via the UPGRADE method. If Layer 7 billing is defined for the HTTP port, the session might time out when the UPGRADE occurs, because the CSG2 code cannot parse the encrypted data after TLS negotiation. Some HTTP Layer 7 methods and content types cause the CSG2 to invoke Layer 4 processing for the remainder of the TCP connection. For details, see the HTTP compliance exceptions in the Layer 7 Inspection (parse protocol=specific protocol) section on page I-1.
1-27
Overview
SIP Features
The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol used for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. The CSG2 provides detailed billing information and services for content transported over the network using SIP. For SIP and Session Description Protocol (SDP), keep the following considerations in mind:

Individual SIP/SDP headers are not parsed beyond the first 256 characters. Domain names used in headers are not resolved to IP addresses. If domain names are used in headers for which IP addresses are required (such as media connect headers), the CSG2 cannot correctly identify and correlate the SIP media traffic. The CSG2 cleans up media sessions for SIP calls when a positive response to a BYE request is processed (200 ok). Media packets that flow after the 200 ok are not associated with the media session.
WAP Features
The CSG2 provides the following WAP features:

WAP Traffic, page 1-28 WAP 2.0, page 1-29 Support for WAP Segmentation and Reassembly (SAR), page 1-30
WAP Traffic
The CSG2 can intercept WAP traffic and generate reports that include contextual WAP information and counts of the bytes transferred. WAP functionality provides protocol-level prepaid and postpaid billing, including the following functionality:
Billing CDRs for Wireless Transaction Protocol (WTP) and WSP in support of WAP 1.2The ability to generate billing records for each WAP GET, POST, PUSH or CONFIRMED PUSH, ABORT and REPLY PDUs, as well as a summary report at WAP Disconnect. Records include URL, User Agent, source and destination IP, separate IP byte and PDU counts from both the initiator and the responder. (The PDU count is not the same as the packet count. Multiple WAP PDUs can share a single packet.) Prepaid billing for WTP and WSP in support of WAP 1.2, including the ability to differentiate WAP browsing from the Multimedia Messaging Service (MMS), and to exclude charging for MMS. Top-up capability using URL-redirect. URL-map support for WAP. Support for multiple services. WAP 2.0 support: The CSG2 HTTP support is compatible with WAP 2.0 traffic. WAP byte counting is always IP-based. Retransmitted bytes are not counted against quota, but they are reported separately in the WAP CDRs.
1-28
OL-22840-05
Chapter 1
WAP 2.0
The CSG2 supports billing for the following types of WAP 2.0 network flows:

Retrieving a message from the network using HTTP.request-method: GET Posting a message into the network using HTTP.request-method: POST Acknowledging a PUSH indication using HTTP.request-method: POST
WAP 2.0 mobile devices can participate in these flows, implemented as WAP 2.0/TCP across a WAP 2.0 Proxy or Push Proxy Gateway (PPG): WAP 2.0 mobile devices can be configured to use the WAP 2.0 proxy or to ignore it. However, if a WAP 2.0 proxy is not configured, the configuration resembles HTML over HTTP (in that you must choose the appropriate content rules so that HTTP policies can be applied to the WAP 2.0 traffic). The WAP 2.0 proxy enables you to identify WAP 2.0 traffic by configuring a content that examines traffic to and from the WAP 2.0 proxy. Using an account type of http enables billing of WAP 2.0, including support for policies based on the HTTP method, URL and HTTP header values. The current limitations of HTTP billing (with respect to Transport Layer Security [TLS]) apply to billing WAP 2.0 and MMS/WAP 2.0. The CSG2 also supports PPG-Originated TCP (PO-TCP), implemented as WAP 2.0 over SMS OTA-PUSH rather than WAP 2.0 over HTTP. In PO-TCP, the PPG establishes a direct connection to the mobile device using prior knowledge of its IP address. The PPG negotiates an understanding of the mobile device identity and capabilities by using HTTP.request-method: OPTIONS, and then uses HTTP.request-method: POST to deliver the PUSH notification as a WAP 2.0 XML message. WAP 2.0 mobile devices can implement support for extensive MMS over WAP 2.0. Service providers use MMS to differentiate and promote their products; thus, the billing of MMS over WAP 2.0 needs to be differentiated from other WAP 2.0 billing. The CSG2 can bill MMS over the supported WAP 2.0 flows at a differentiated rate by using HTTP billing capabilities to detect some or all of the following characteristics of MMS/WAP 2.0 traffic:

The URL of a GET of MMS content points to the MMSC and encodes an MMS message ID. The URL of the POST of an MMS message or an MMS message notification acknowledgement points to the MMSC. The Content-Type HTTP header of the POST of an MMS message or an MMS message notification acknowledgement is application/vnd.wap.mms-message. PO-TCP SMS-based notification carrying the Uniform Resource Identifier (URI) for the MMS. The handset then initiates a GET request to that URI to retrieve the information. TO-TCP (Terminal-Originated TCP), which starts with SMS, but provides only the IP address of the PPG. The handset must then open a TCP connection and wait for an HTTP request from the PPG. This HTTP request is an OPTIONS method. It must succeed before the handset can retrieve the notification.
MMS over WAP 2.0 allows the following types of notification:

The CSG2 Layer 7 billing for MMS relies entirely on the PO-TCP and SMS-based notification types. TO-TCP is not supported.
Note
If a terminal reuses a persistent PO-TCP to initiate a new method request, the packets are dropped and the PO-TCP connection appears hung until TCP retry attempts expire.
1-29
Overview
Support for WAP Segmentation and Reassembly (SAR)

The CSG2 applies the appropriate policy to the WAP transaction if it contains a URL that spans multiple WAP segmented packets. There are no commands required to enable support for WAP SAR.
RTSP Features
The CSG2 provides the following Real Time Streaming Protocol (RTSP) features:

RTSP Billing, page 1-31 Per-Click Authorization, page 1-31 RTSP TEARDOWN Reply Delay, page 1-31 URL Maps for Interleaved RTSP, page 1-31 Correlation, page 1-32 RTSP offers minimal support for TCP-interleaved and HTTP-tunneled transport. For authorized content, the first stream is sent to the quota server. The action must be identical to that sent for the control connection because the stream is interleaved on the control connection and cannot be ended or charged independent of the control connection. RTSP supports multiple transport choices.
RTSP clients and servers negotiate the transport choice dynamically before the stream is started. One transport choice is to interleave the stream with the control channel. In this mode, the CSG2
For RTSP, keep the following considerations in mind:
cannot map the transport connection to a different policy, and URL mapping cannot be supported.
The other transport choice for RTSP is use of a single HTTP connection. RTSP that is tunneled
over HTTP has the same limitation as interleaved RTSP: The stream cannot be mapped to a policy different from the one used by the control connection, as both the stream and the control connection share the same transport.

The CSG2 does not support multicast RTSP. The CSG2 does not support return code-based refunding for RTSP, but it does support flag-based refunding for RTSP. The CSG2 does not correlate streams that are described in a container file, such as SMIL. The CSG2 parses only the RTSP control session. When multiple RTSP streams are multiplexed over the same transport channel, the CSG2 reports cumulative statistics for all the streams. If RTSP URL mapping and filtering are used, and if multiple RTSP streams share the same transport channel, the CSG2 generates a single Content Authorization Request, and the request contains all the URLs carried over that stream. Also, the RTSP stream CDR contains the URLs for all the streams that are multiplexed over the same transport channel. If an RTSP proxy is used, place the CSG2 on the client side of the proxy. If the CSG2 is placed on the network side of the proxy, the CSG2 sees packets originating from the proxy, and the CDRs contain the proxys IP address, instead of the clients. The CSG1 created two connections for every session (one for each direction of the flow). The CSG2 creates only the session. Therefore, the RTSP statistics reported by the show ip csg content name detail command for the CSG1 differ from those reported for the CSG2.
1-30
OL-22840-05
Chapter 1
RTSP Billing
RTSP billing correlates all the streams that are associated with an RTSP session, and reports application-level information (for example, filename) to the billing system. RTSP billing provides the following functionality:

Correlation of various streams associated with an RTSP session Reporting of application-level information (for example, filename) to the billing system
RTSP uses the following protocols for streaming to the client. The client presents the server with a choice of acceptable protocols and port numbers, and the server responds with its choice of protocol that includes:
RTSP also requires a UDP server-to-client stream for RTP (audio/video stream delivery), and a bidirectional UDP flow pair for exchanging synchronization information. The ports for the UDP flows are negotiated on the TCP connection during the SETUP exchange. RTSP can use RealNetworks Data Transport (RDT) for the stream transport. This establishes a UDP flow in each direction: one for stream delivery from the server, and the other for requesting the resending of lost media packets. RTSP can operate completely over the single TCP connection. RTSP can be tunneled over HTTP. The client sends a SETUP request that identifies one or more modes it can support. The server responds with a mode that it has selected and ports that are to be used.
RTSP transport modes are negotiated on the control connection using the following methods:

Per-Click Authorization
Per-click authorization implements functions like AoC redirection and retrieval of price from an external server. For the control session, the CSG2 sends a Content Authorization Request at the beginning of the TCP session. For each transaction involving a data stream, the CSG2 sends a Content Authorization Request before it allows the data stream to flow. This request allows the quota server to inspect the filename before granting authorization. RTSP allows the multiplexing of multiple data streams over the same transport. For example, audio and video presentations can be multiplexed over the same UDP flows. The quota server must ensure that it does not send contradictory responses to the various Content Authorization Requests. For example, if one request is allowed and the other one is denied, the behavior of the CSG2 is undefined.
RTSP TEARDOWN Reply Delay

When the CSG2 receives an RTSP TEARDOWN request from a client, it ends the control session and the data sessions and generates CDRs without waiting for an acknowledgement from the server, and without waiting for the data sessions to idle out.
URL Maps for Interleaved RTSP

By default, the CSG2 assigns the policy for an RTSP control session when the session begins (SYN). At that time, the CSG2 cannot use URL mapping to assign the policy because it does not know the URL, nor does it know the transport method for the data (for example, HTTP over RTSP).
1-31
Overview
However, you can enable the CSG2 to use URL mapping to assign the policy. To do so, you must delay policy assignment and charging for the control session until the CSG2 knows the first RTSP stream URL and the data transport method. To do so, use the control-url command in CSG2 content configuration mode. You can also prevent the CSG2 from using URL mapping unless the data is interleaved over the control session. To do so, specify the interleaved keyword on the control-url command. If you enable policy assignment for URL maps for interleaved RTSP, all packets processed before the policy is assigned are passed and treated as pre-policy packets (that is, packets that cannot be associated with a policy).
Correlation
The CSG2 provides RTSP correlation at the RTSP session level. All TCP/UDP flows associated with an RTSP session share a correlator. The CSG2 does not correlate RTSP streams that do not share the RTSP session ID.
Correlating Multiple Streams Controlled by a Single RTSP Session
An RTSP session can control multiple streams, such as the audio stream and the video stream for a movie. For instance, a client can perform the following operations over the same RTSP session:
DESCRIBE rtsp://a.ex.com/movie.sdp The client requests the description of a movie. The server assigns a session ID to the client, and sends the.sdp file containing information about the movie.
SETUP rtsp://a.ex.com/movie/audio The client requests the setup of a stream. SETUP rtsp://a.ex.com/movie/video The client requests the setup of a second stream. This results in the setting up of four UDP flows. PLAY rtsp://a.ex.com/movie.sdp
In this example, all the streams share the RTSP session and the session ID. There is one RTSP control TCP session, with four associated UDP streams. The CSG2 correlates all four UDP streams with the control session.
Correlating Multiple Streams Controlled by HTTP
HTTP sessions can be used to correlate multiple related RTSP streams. Different RTSP streams could go to different servers. The CSG2 has no easy way to determine which two streams are related. For example, a web server (W) hosts the media description file, movie.sdp; a video server (V) contains the video stream; and an audio server (A) contains the audio stream. Table 1-2 identifies the interactions that occur.
Table 1-2 Multiple Streams Controlled by HTTP
Client C C C C C
Server M V A V A
Protocol HTTP RTSP RTSP RTSP RTSP
Method/URL GET /movie.sdp SETUP rtsp://v.eg.com/video SETUP rtsp://a.eg.com/audio PLAY rtsp://v.eg.com/video PLAY rtsp://a.eg.com/audio
1-32
OL-22840-05
Chapter 1
In the previous example, there are five concurrent sessions:

One HTTP 1.1 session Two RTSP video sessions Two RTSP audio sessions
All of the TCP and UDP sessions associated with an RTSP session can be correlated. In this same example, the sessions associated with the video on server V are correlated. Similarly, the sessions associated with the audio on server A are correlated; however, there is no correlation between the audio and video flows, and neither the audio flow nor the video flow is correlated with the HTTP session.
Implications of Container Files
A container file is a storage entity in which multiple, continuous media types pertaining to the same subscriber presentation are present. A container file represents an RTSP presentation; each of its components is an RTSP stream. While the components are transported as independent streams, it is desirable to maintain a common context for these streams at the server. Synchronized Multimedia Integration Language (SMIL) is an example of a programming language that can be used to describe the contents of a container file. The CSG2 does not correlate the streams within a container file.
Interleaved RTSP
Interleaved RTSP passes RTSP data in the TCP control session. Because the CSG2 parses the control session, it could cause a large performance bottleneck. To avoid bottlenecks, the CSG2 performs the following actions for interleaved RTSP sessions:

Waits for a SETUP request/reply to determine whether this is an interleaved RTSP session. Remembers the URL information. After determining interleaved RTSP, reports RTSP information to the BMA/quota server, and begins fastpath processing for the connection. Any subsequent transactions on the same RTSP control connection are not visible to the CSG2s billing function.
This method provides some RTSP-level information, but avoids making the RTSP path a target of denial-of-service (DoS) attacks. If most of the RTSP streaming billing applications are protected, customers have some control over the servers to ensure that interleaved RTSP is not used excessively.
CDRs
The CSG2 generates the following CDRs for RTSP:

TCP control session: TCP, TCPInt, RTSP Data streams: RTSP stream UDP CDRs for each UDP session
Note
If you are using fixed CDR support, the CSG2 does not generate any UDP CDRs.
RTSP billing in the CSG2 is based on inspection of the RTSP SETUP and TEARDOWN messages that are exchanged between the client and server. The CSG2 builds the RTSP CDR immediately after the RTSP TEARDOWN signal if the URL exactly matches the URL from the RTSP SETUP signal. Otherwise, the CSG2 builds the CDR after any condition that causes the flows to be terminated, as when a service_stop is triggered (for example, when the access server sends a RADIUS Accounting Stop for the subscriber).
1-33
Overview
Session Processing
RTSP control session processing uses an 8-byte correlator is assigned to the RTSP control session. The most significant 6 bytes of the correlator are assigned from the session ID and the session ID sequence. The least significant 2 bytes of the correlator are zeroed (for example, 0x0000). The CSG2 keeps track of RTSP sessions, and an RTSP session is used to correlate multiple streams that are associated with the session.
Note
An RTSP session might comprise more than one TCP session; alternatively, an RTSP session can exist without even one TCP session between client and server. When the client sends a setup command, the CSG2 notes the client ports, and extracts the server port information from the SETUP response. Data connections to these ports are processed as if they hit the content, policy definition for the control server. The following example (from RFC 2326) uses a single RTSP session to control multiple streams. The CSG2 actions are annotated after various steps. In this example, the client (C) requests a presentation from the media server (M). The movie is stored in a container file. The client has attached an RTSP URL to the container file.
C->M: SYN port=RTSP M->C: SYN-ACK Assign 8 byte correlator X. Lower two bytes of the correlator are 0. C->M: DESCRIBE rtsp://foo/twister RTSP/1.0 CSeq: 1 M->C: RTSP/1.0 200 OK CSeq: 1 Content-Type: application/sdp Content-Length: 164 v=0 o=- 2890844256 2890842807 IN IP4 172.16.2.93 s=RTSP Session i=An Example of RTSP Session Usage a=control:rtsp://foo/twister t=0 0 m=audio 0 RTP/AVP 0 a=control:rtsp://foo/twister/audio m=video 0 RTP/AVP 26 a=control:rtsp://foo/twister/video C->M: SETUP rtsp://foo/twister/audio RTSP/1.0 CSeq: 2 Transport: RTP/AVP;unicast;client_port=8000-8001 M->C: RTSP/1.0 200 OK CSeq: 2 Transport: RTP/AVP;unicast;client_port=8000-8001; server_port=9000-9001 Session: 12345678
Build RTSP record. Correlator = X + i. The CSG2 makes sure that X + i results in an even number. RTSP usage records for these two UDP flows carry X + i and X + i + 1 as the correlators. The correlators share 63 bits to help bind together the various flows for an RTSP transaction; that also enables you to distinguish the various interim records for one UDP flow from another.
C->M: SETUP rtsp://foo/twister/video RTSP/1.0
1-34
OL-22840-05
Chapter 1
CSeq: 3 Transport: RTP/AVP;unicast;client_port=8002-8003 Session: 12345678 M->C: RTSP/1.0 200 OK CSeq: 3 Transport: RTP/AVP;unicast;client_port=8002-8003; server_port=9004-9005 Session: 12345678
Build RTSP record. Correlator = X + 3. RTSP usage records generated for these two UDP flows carry the same correlator.
C->M: PLAY rtsp://foo/twister RTSP/1.0 CSeq: 4 Range: npt=0Session: 12345678
M->C: RTSP/1.0 200 OK CSeq: 4 Session: 12345678 RTP-Info: url=rtsp://foo/twister/video; seq=9810092;rtptime=3450012 C->M: TEARDOWN rtsp://foo/twister RTSP/1.0 CSeq: 6 Session: 12345678 V->C: RTSP/1.0 200 OK CSeq: 6
This TEARDOWN does not correspond to the SETUP URL; therefore, the CSG2 lets the streams idle out and sends the usage records when the streams idle out.
DNS Support
The Domain Name System (DNS) protocol is a Layer 7 application protocol used for translating domain names into IP addresses. The CSG2 supports Layer 7 inspection of DNS traffic over both TCP and UDP, which enables postpaid and prepaid billing of individual DNS transactions. For detailed information about DNS support, see the Configuring DNS Support section on page 2-19.
POP3 Support
The CSG2 generates a single CDR for each POP3 e-mail. The CDR includes all necessary information, such as the IP byte count and the TCP byte count. The CSG2 no longer generates a final TCP Stats record. If a subscriber downloads multiple e-mails during a single TCP session, the CSG2 generates a CDR for the previous e-mail each time it processes a new POP3 RETR (retrieve message) or TOP (retrieve specific lines of the message body) command. The CSG2 generates a CDR for the last e-mail when it processes the POP3 STATS (statistics) command (for TCP termination). The CSG2 supports POP3 in both prepaid and postpaid mode. For basis fixed prepaid billing, the CSG2 treats each e-mail download as a transaction and a prepaid debit subject to weighting.
1-35
Overview
The CSG2 also supports refunding for POP3. If an e-mail download request (TOP or RETR) flows from the client to the server, and the next server response is not OK, or the session ends without seeing OK, then the prepaid debit returns the prepaid quota consumed for this transaction. The refund return code used is 554; if you want the CSG2 to provide refunding for POP3, you must specify return code 554 on the retcode command in CSG2 refund configuration mode for the POP3 refund definition. If a subscriber tries to download e-mail and no e-mail exists, the CSG2 generates a POP3 CDR that contains an application return code TLV with a value of 554. This is the only condition in which the CSG2 includes a non-zero return code in a POP3 CDR. To define the POP3 protocol type for a billing policy, use the parse protocol pop3 command in CSG2 content configuration mode.
SMTP and POP3 Billing

SMTP is the Internet e-mail transfer protocol that operates over TCP with port 25. Subscribers send messages using SMTP. SMTP is also used to transfer messages between SMTP gateways (or relays). POP3 is a common protocol used to retrieve Internet e-mail from an e-mail server. POP3 also operates over TCP and typically uses port 110. SMTP and POP3 messages consist of the following parts:

EnvelopeThe SMTP and POP3 commands and responses. HeadersRFC 2822 headers that appear as contents to the SMTP and POP3 protocols. The RFC 2822 headers are of the form header field name: header field body. Some common header field names are To, From, Date, Subject, Cc, and Bcc. BodyThe part of the message that appears as contents to the SMTP and POP3 protocols, but does not include headers. The headers and body of the message are separated by a blank line (for example, <CR><LF><CR><LF> in RFC 2822).
The CSG2 inspects SMTP and POP3 messages and reports all RFC 2822 header field names and bodies that appear in the header section of the message (before the body of the message). SMTP and POP3 envelope information is not reported, except for the SMTP return code from the DATA command. For SMTP, the sender and recipients in the SMTP MAIL and RCPT commands are not reported, but the values from the To, From, Date, Cc, and Bcc headers in the contents of the e-mail message are reported to identify senders and recipients. Because the amount of information in the header section might be greater than an IP packet encapsulated in an Ethernet frame, the information might span multiple records by using the CSG2 Continue Data Record type. Because the amount of information in a single header field might also be greater than an IP packet over Ethernet, the CSG2 Report String Attribute reports also has a continuation option. This means that information for a single header might span multiple CSG2 Report String Attribute reports, which might span multiple CSG2 Data Records.
Note
If a TCP connection carries multiple e-mail messages, each e-mail message generates a separate SMTP or POP3 Data Record (plus Continuation Data Records if necessary).
1-36
OL-22840-05
Chapter 1
SMTP CDR Header Removal

An SMTP CDR can be very large, as it includes a report attribute for each SMTP header embedded at the beginning of a message. The CSG2 enables you to eliminate these headers from an SMTP CDR, leaving only the SMTP envelope headers and the size attribute in the report. These are reported as X-CSG-MAIL, X-CSG-RCPT and X-CSG-SIZE. For more information, see the Configuring SMTP CDR Header Removal section on page 2-39.
FTP Billing
The CSG2 supports both postpaid and prepaid FTP protocol-aware billing. The CSG2 can generate TCP billing records for FTP connections, and records that report FTP-specific information, such as the filename. Users can define basis fixed and basis byte prepaid billing services for FTP.
Note
There is no regular expression (map) support for differentiating FTP services. FTP requires a control TCP connection to well-known server port 21.
Attribute, Header, Method, and URL Mapping

The CSG2 uses maps to match attributes, headers, methods, or URLs against a pattern, to determine whether flows will be processed by the CSG2 accounting services. For more information about maps, see the Configuring Maps for Pattern-Matching section on page 2-43.
Configurable Regex Memory

As CSG2 maps become more complex, your CSG2 configuration might require more memory when compiling regular expression (regex) engines. The CSG2 enables you to increase the size of the regex memory. For more information about setting the regex memory size, see the Configuring Maps for Pattern-Matching section on page 2-43.
Configurable URL Map Normalization

The CSG2 uses URL map normalization to determine whether two URLs with different syntaxes are equivalent. The CSG2 does this by modifying the supplied URLs, removing the dot-segments . and . . prior to running the URLs through the regex engine. For example, the CSG2 normalizes the following URL: http://www.somehost.com/. ./img/somehost.jpg to this: http://img/somehost.jpg
1-37
Overview
However, there might be situations in which you do not want the CSG2 to normalize URLs. In such cases, you can disable URL map normalization, enabling the CSG2 to search explicitly for the dot-segments in URL map search strings. For example, when URL map normalization is disabled, the CSG2 treats this: http://www.somehost.com/. ./img/somehost.jpg and this: http://img/somehost.jpg as two different, unique URLs when performing URL map searches. By default, URL map normalization is enabled for all CSG2 contents. To disable URL map normalization for a content, use the no form of the normalize-url command in CSG2 content configuration mode. For more information about enabling or disabling URL map normalization, see the Configuring Maps for Pattern-Matching section on page 2-43.
Service Duration Billing

The Service Duration Billing feature enables the CSG2 to deduct quota based on the time of network usage for prepaid (or managed) subscribers. With this feature, the subscriber is charged for the time duration of the CSG2 service. The following sections describe how this feature works:

Charging for Service Duration Billing, page 1-38 Calculating Usage for Service Duration Billing, page 1-39 Configuring Activity-Based Time Billing, page 1-42 Reporting Quadrans to the Quota Server and to the BMA, page 1-43 Handling Out-of-Quota Conditions, page 1-43
Charging for Service Duration Billing

Service Duration Billing is charged according to the following rules:
For TCP sessions, the Last Billable Session Time (LBST) is the timestamp of the end of the session. The end of the session is detected using TCP session termination signaling (RST, FIN/ACK signals) or session idleness. Because non-TCP sessions (such as UDP) do not have a Layer 4 session termination mechanism, the LBST for non-TCP sessions is determined based on the time that the last packet was forwarded for the IP session.
For a service, the First Billable Time (FBT) is the timestamp (in seconds) of the first grant of network access to a session mapped to a duration-based charging prepaid service. Typically, this time is equal to the timestamp of the first Service Authorization Response with a quota other than zero. For a service, the Last Billable Time (LBT) is the greatest timestamp (in seconds) of the LBST for all IP sessions mapping to the service for this subscriber. Optionally (and by default), the value for service idle is added to the maximum interval of the LBST when the LBT is calculated. The service idle timeout is added to the duration because the duration calculation already includes the intermediate idle intervals (the ones between IP sessions); this means that the last idle interval is also included.
1-38
OL-22840-05
Chapter 1
Calculating Usage for Service Duration Billing

The calculations for Service Duration Billing usage are as follows:
If the service is ended as a result of service idleness, the calculation for usage is: LBT FBT = Usage If the service is ended as a result of an asynchronous event such as subscriber logoff, the calculation for usage is: LBT FBT = Usage or Asynchronous Event Timestamp FBT = Usage whichever is smaller. If the service runs out of quota, the calculation for usage is: LBT FBT = Usage or Out Of Quota Timestamp FBT = Usage whichever is smaller.
Note
If the subscriber runs out of quota, but the subscriber refreshes the quota before the service idles out, the periods (or gaps) of zero quota are not included in the usage calculation. When a Service Duration Billing service is a member of a billing plan, and an accounting definition is in service and downloaded to a CSG2 module, you cannot modify the billing basis or meter configuration. You are instructed at the console to configure no inservice on the downloaded accounting definitions. The following examples show how Service Billing Duration usage is calculated in different situations. In these examples:

SIT is the service idle timer, configured by using the idle command in CSG2 service configuration mode. The service idle time is not included in the billing charge. (T2 T0) + (T6 T4) = Usage
In Figure 1-2, the CSG2 calculates usage for Service 1 as: and the usage for Service 2 as: T7 T1 = Usage
1-39
Overview
Figure 1-2
Service Duration BillingLayer 7 Inspection, Two Services, Overlapping Transactions, Example One
T0
Service 1 Service 2
T1
Transaction 1
T2
T3
SIT
T4
T5
Transaction 2
T6
T7
Transaction 1
In Figure 1-3, the CSG2 calculates usage for Service 1 as: T5 T0 = Usage and the usage for Service 2 as: T7 T1 = Usage
Figure 1-3 Service Duration BillingLayer 7 Inspection, Two Services, Overlapping Transactions, Example Two
T0
Service 1 Service 2
T1
Transaction 1
T2
T3
T4
Transaction 2
T5
T6
T7
SIT
Transaction 1
In Figure 1-4, the CSG2 calculates usage for Service 1 as: (T2 T0) + (T6 T4) = Usage and the usage for Service 2 as: T7 T2 = Usage
Figure 1-4 Service Duration BillingLayer 7 Inspection, Two Services, Non-Overlapping Transactions, Example One
T0
Service 1 Service 2
T1
Transaction 1
T2 T2' T3
SIT
T4
T5
Transaction 2 Transaction 1
T6
T7
In Figure 1-5, the CSG2 calculates usage for Service 1 as: T5 T0 = Usage and the usage for Service 2 as: T7 T2 = Usage
1-40
OL-22840-05
158039
158038
158037
Chapter 1
Figure 1-5
Service Duration BillingLayer 7 Inspection, Two Services, Non-Overlapping Transactions, Example Two
T0
Service 1 Service 2
T1
Transaction 1
T2 T2' T3
T4
Transaction 2
T5
T6
T7
SIT
Transaction 1
In Figure 1-6, if T4 T2 > SIT, the CSG2 calculates usage for Service 1 as: (T2 T0) + (T6 T4) = Usage
Figure 1-6 Service Duration BillingLayer 7 Inspection, One Service, Example One
T0
Service 1
T1
T2
T3
SIT
T4
T5
T6
158041
In Figure 1-7, if T3 T2 < SIT, the CSG2 calculates usage for Service 1 as: T4 T0 = Usage
Figure 1-7 Service Duration BillingLayer 7 Inspection, One Service, Example Two
T0
Service 1
T1
T2
T3
T4
T5
T6
158042
SIT
In Figure 1-8, if the SIT does not time out, the CSG2 calculates usage for Service 1 as: T6 T0 = Usage
Figure 1-8 Service Duration BillingLayer 7 Inspection, One Service, Example Three
T0
Service 1
T1
Transaction 1
T2
SIT
T3
T4
T5
T6
In Figure 1-9, if the SIT does not time out, the CSG2 calculates usage for Service 1 as: T6 T0 = Usage
1-41
158043
158040
Overview
Figure 1-9
Service Duration BillingLayer 7 Inspection, One Service, Example Four
T0
Service 1
T1
Transaction 1
T2
T3
T4
T5
T6
Configuring Activity-Based Time Billing

Activity-based time billing is an enhancement to standard CSG2 duration-based billing. Activity-based time billing enables you to eliminate charging for periods of inactivity between packets. You implement activity-based time billing by specifying a quota consumption time (QCT) for a service. The QCT is the maximum time, in seconds, that the CSG2 can charge a user during periods of inactivity. For example, assume that packet 1 is received at t=0 seconds, packet 2 is received at t=1 second and packet 3 is received at t=100 seconds.

With only standard duration-based billing configured, the service is charged for the full 100 seconds. If you implement activity-based time billing with a QCT of 5 seconds, the CSG2 charges the service for only 6 seconds for packets 1 and 2 (1 second plus the QCT of 5 seconds). The CSG2 then restarts the QCT timer when packet 3 arrives.
The CSG2 supports activity-based time billing for prepaid users and for virtual prepaid services. To enable activity-based time billing, enter the following command in CSG2 service configuration mode: Command
csg2(config-csg-service)# qct qct
Purpose Specifies a quota consumption time (QCT) for a CSG2 service.
A quota server can specify a QCT in a Service Authorization Response, a Service Reauthorization Response, or a Quota Push message. If a quota server specifies a QCT, the quota server QCT overrides the QCT specified using the qct command, as well as any prior quota server QCTs. Make sure the QCT does not exceed the service idle timeout value, set using the idle command in CSG2 service configuration mode. A quota server can also specify a quota holding time (QHT) in a Service Authorization Response, a Service Reauthorization Response, or a Quota Push message. The QHT corresponds to the service idle timeout. If a quota server specifies a QHT, the quota server QHT overrides the service idle timeout, as well as any prior quota server QHTs.
1-42
OL-22840-05
158044
SIT
Chapter 1
Reporting Quadrans to the Quota Server and to the BMA

For Service Duration Billing, quadrans are reported to the quota server and to the BMA in seconds. In messages sent to the BMA on a perIP-session basis (such as TCP statistics), the prepaid TLVs (Session ID, Service ID, Quadran) are present; the value for quadrans in the Quadran TLV is zero because the duration is based on service, not on individual sessions or on the sum of the durations of the individual sessions.
Handling Out-of-Quota Conditions

When a subscriber runs out of quota, the CSG2 ends the subscriber sessions that are mapped to the service. The sessions are ended using the same asynchronous session mechanism that is used when a subscriber User Table entry is deleted. The CSG2 reauthorizes when the remaining time is low (instead of 0) in order to more quickly determine session processing when zero quota is reached.
Connection Duration Billing

Connection Duration Billing enables the CSG2 to deduct quota based on the time that a subscriber is logged on to the IP network. That differs from Service Duration Billing, which charges on the basis of a service duration. Because the service measures the duration of subscriber access, the service is never idleit is ended only when the subscriber logs out, or when a Service Stop Request is received from the quota server. The CSG2 charges on the basis of the following rules:
The First Billable Time (FBT) is the timestamp, in seconds, of the first non-zero grant of quota in a Service Authorization Response for the Connection Duration service. A Service Authorization Request is generated when the following conditions are met:
A User Table entry is created (typically as a result of a RADIUS Accounting Start message). A Connection Duration service is part of the billing profile for the User Table entry (indicated
in a RADIUS Access-Accept message, a RADIUS Accounting Start message, or a Quota Server User Profile Response). If the subscriber has quota, the FBT is typically the same time as the RADIUS Accounting Start message.
The Last Billable Time (LBT) is the timestamp, in seconds, when the User Table entry is deleted. During the service lifetime, the CSG2 updates the LBT when either of the following situations occurs:
An IP session starts or ends. The CSG2 sends a Service Reauthorization Request. This results in an update to the service
balance and usage before the Service Reauthorization Request is sent. The CSG2 uses the following algorithm to calculate the usage: LBT FBT = Usage or Out Of Quota Timestamp FBT = Usage whichever is smaller. Therefore, if the service does not run out of quota, the algorithm is simply as follows: LBT FBT = Usage
1-43
Overview
If the subscriber runs out of quota, but refreshes the quota before the service times out, the periods of zero quota are not included in the usage calculation. When the subscriber runs out of quota, existing prepaid and postpaid IP sessions for the subscriber are terminated. If the subscriber does not have quota to proceed, no IP sessions are allowed for the subscriber. The CSG2 provides enforcement only for the policies that have accounting configured. Connection Duration Billing requires an external quota server. Connection Duration Billing is not supported for internal quota servers, such as a gateway general packet radio service (GPRS) support node (GGSN) for postpaid subscribers. Therefore, you cannot use Connection Duration Billing if your quota servers are GGSNs. To configure Connection Duration Billing, use the activation command and the basis second command in CSG2 service configuration mode. When configuring Service Duration Billing, make sure the content idle timer duration, set using the idle command in CSG2 content configuration mode, does not exceed the service idle timer duration, set using the idle command in CSG2 service configuration mode.
Postpaid Service Tagging

This feature enables the CSG2 to map postpaid content to a CSG2 service, and to report the service name in a CSG2 Service ID TLV in transaction-level CDRs to the BMA. (The CSG2 Service Session ID TLV is not sent in variable-format records for postpaid service tagging.) The service must be associated with a billing plan that is configured for postpaid mode.
Stateful Redundancy and Failover

The CSG2 supports stateful redundancy for HTTP, IMAP, POP3, SMTP, TCP, and WAP connections. Stateful redundancy is the configuration of the active CSG2 to share information related to billing with its standby CSG2 in the event of a failure. That is, the session continues to be billed even when the active CSG2 fails and the standby CSG2 takes over. During normal operation, connection and billing state information is sent by the active CSG2 to the standby CSG2, and from the active quota server to the standby quota server. The active CSG2 and the standby CSG2s maintain state information for the configured BMAs. The active CSG2 keeps the standby CSG2 informed about which BMAs and quota servers are being used. If the active CSG2 fails, the standby CSG2 takes over operation and tries to use the same BMAs or quota servers, if it has connectivity. Otherwise, the standby CSG2 selects the BMAs or quota servers that have the highest priority. The active CSG2 also informs the standby CSG2 when user IDs are added to or removed from the User Table, and sends the correlators to the standby CSG2 to ensure consistency when sending billing records for recovered connections to the BMAs. Quota use is also correlated. If connections are replicated to a standby CSG2, and a failover occurs, the CSG2 does not increment the content counters for traffic flowing through these connections. The CSG2 does increment the content counters for new connections created after the failover.
1-44
OL-22840-05
Chapter 1
The CSG2 provides full stateful failover for IMAP sessions. The CSG2 provides limited stateful failover for FTP, HTTP, POP3, RTSP, SIP, SMTP, and WAP sessions.
For POP3, SMTP, and WAP sessions, subscriber information and quota information are maintained on the standby CSG2; however, in-process transactions are not. If the active CSG2 fails, the subscriber transaction is completed on the standby, but no quota is charged for the transaction. Normal billing resumes with the subscribers next transaction. For HTTP sessions, subscriber information and quota information are maintained on the standby CSG2; however, the sessions are downgraded to Layer 4. If the active CSG2 fails, the replicated HTTP session continues until it closes and a Layer 4 CDR is generated, but no quota is charged for the transaction. Normal billing resumes with the subscribers next transaction. For FTP, RTSP, and SIP sessions, media traffic is replicated to the standby CSG2 and classified as postpaid type other traffic. A Layer 4 CDR is generated showing only the media traffic that passes on the standby CSG2. Control sessions for FTP, RTSP, and SIP do not have stateful support but are maintained to allow media traffic to pass. This support allows for the best user experience possible at the expense of allowing traffic to pass freely for existing sessions. New sessions starting on the standby CSG2 are handled normally.
The CSG2 also supports stateful redundancy for TCP connections. That is, the session continues to be billed even when the active CSG2 fails and the standby CSG2 takes over. The CSG2 does not support stateful redundancy for IP or UDP connections.
Note
Before manually resetting an active CSG2, make sure the standby CSG2 has the complete subscriber and session fault-tolerant (FT) configuration information. In the logs for the active CSG2, the following message indicates that the exchange with the standby CSG2 was successful: CSG user and session FT dump complete. The CSG2 counts and charges packets that complete CSG2 feature processing and are scheduled for forwarding. It is possible for these packets to be dropped in the Cisco SAMI module due to incomplete ARP entry, incorrect IP routing, or output queue contention. For example, when an active CSG2 fails over to a standby CSG2 in a redundant configuration, some ARP entries on the standby CSG2 might not yet be populated, and the CSG2 might drop packets. In many cases, you can resolve the problem with incomplete ARP entries by routing subscriber traffic and GTP control traffic to a common default gateway IP address. Typically, this default gateway IP address is an address on the Supervisor Engine. The CSG1 and CSG2 cannot act as stateful standbys for each other.
Default Policy
The CSG2 matches content on a best-match basis, based on Layer 3 and Layer 4 information. When there is a successful content match, the CSG2 matches against the policies configured within the content, linearly, on a first-match basis. If no policy within the content matches, the CSG2 matches against an implicit default policy, which matches all traffic. Matching this default policy does not generate a CDR, because no accounting policies can be configured for the default policy.
Note
Even if you have used the next-hop command in CSG2 content configuration mode to define a next-hop IPv4 or IPv6 address, traffic that matches the default content might not be routed with next-hop.
1-45
Overview
Tariff Switch
Tariff switch is a feature in which the CSG2 tracks the total quota usage for a prepaid service at the time of a tariff-time change. The tariff-time change is specified on a per-service basis by the quota server. The CSG2 supports tariff switch for all prepaid protocols. The CSG2 sends tariff switch TLVs only for transaction-level CDRs, not for service-level CDRs. The tariff switch usage for the prepaid service is reported to the quota server in the next Service Reauthorization, Quota Return, or Service Stop message sent for this service. The tariff switch usage for a tariff-time change is sent once and is sent in addition to the cumulative usage at the time of the message to the quota server. If the Supplemental Usage Reporting feature is enabled for a service at the tariff switch time, the CSG2 also reports supplemental usage at the tariff switch time in addition to the tariff-time switch usage. The life of a prepaid service instance might span multiple tariff switch times. For a given service instance associated with a subscriber, the CSG2 can handle only one tariff switch time value. If a transaction spans multiple tariff switches, the CSG2 reports only the most recent tariff switch information in its record, unless an intermediate record was generated between tariff-switch times. The CSG2 might not generate a Service Reauthorization Request between tariff switch times. The quota server can force a report of the tariff switch time usage by specifying a quota timeout value in the Service Authorization Response that will force a Quota Return before the next tariff switch time. The quota server must choose the timeout carefully to avoid causing a flood of Quota Return messages at a given time. At any given time, the CSG2 service can track usage for a single tariff switch time; after reporting the usage for a tariff switch, the quota server can specify the time of the next tariff-time change in a Service Authorization Response. If CSG2 refunding is configured for a prepaid service, the tariff switch usage might not include usage on existing IP sessions at the tariff switch time. This is because the usage cannot be charged until the session ends and the refund conditions are evaluated. Tariff switch usage for individual transactions is reported to the BMA in the records containing quota usage (typically intermediate and statistics records). Note that intermediate records might be sent to the BMA to report tariff switch usage, even without configuration of intermediate records; this is necessary because transactions might span multiple tariff switch times. To avoid flooding the BMA with records, the CSG2 sends intermediate records to the BMA for transactions that span a tariff switch time and do not terminate quickly. If a transaction is configured for BMA reporting using a fixed-format CDR, the tariff switch usage information is not reported in the record. The tariff switch qualified usage field in the CDR is the cumulative usage since the creation of the service instance. There are no commands required to enable tariff switch. The output of the show ip csg users all detail command displays information about the tariff switch.
Prepaid Error Reimbursement

The Prepaid Error Reimbursement feature (also known as CSG2 quota refund) allows the CSG2 to automatically refund quota for failed transactions, as defined by the CLI.

To specify IP, TCP, or wireless application protocol (WAP) flag bit masks and values for CSG2 quota refund, use the flags command in CSG2 refund configuration mode. To specify the range of application return codes for which the CSG2 refunds quota, use the retcode command in CSG2 refund configuration mode. The return codes are protocol-specific.
1-46
OL-22840-05
Chapter 1
The CSG2 also adds a refund TLV to the statistics records on the BMA interface. The refund TLV is added for transactions that meet a refund condition. The refund amount contains the quota amount to be refunded for the transaction. The refund amount is the same number that is reported in the quadrans TLV. Thus, the full charge for the transaction is always refunded for these protocols.
Note
Prepaid Error Reimbursement requires an external quota server. Prepaid Error Reimbursement is not supported for internal quota servers, such as a GGSN for postpaid subscribers. Therefore, you cannot use Prepaid Error Reimbursement if your quota servers are GGSNs. Prepaid Error Reimbursement is not supported for duration-based services. Service-level CDRs do not contain quota reimbursement information.
Postpaid Billing
Figure 1-10 shows simple traffic flows between the various components in a simple postpaid CSG2 environment.
Figure 1-10 Traffic Flow Between Client and Server
UserID database GGSN Mobile client Private network CSG2 XML frontend CNR (DHCP)
Client
Client
Clients send requests that pass through a private network, or through a GGSN, before they reach the Internet. The CSG2 monitors data flows and generates accounting records that can be used to bill customers at a content level. The CSG2 sends the accounting records to a Billing Mediation Agent (BMA), which formats the records as required by the customers billing system. User IDs are obtained from RADIUS Accounting records, or by querying the user database.
Prepaid Content Billing and Accounting

In addition to postpaid billing, the CSG2 provides prepaid content billing and accounting. You can configure multiple prepaid billing plans, and subscribers can choose the plan that best meets their needs. Each subscriber can use only one billing plan.
201834
Billing Mediation Agent
Internet
1-47
Overview
The CSG2 uses a BMA to interface with a billing server. At the end of each transaction, the CSG2 sends a billing record to the BMA, indicating the content accessed and the amount deducted. The BMA logs the information in the subscribers bill. The CSG2 uses a quota server to keep track of the quota that is left in the subscribers account. Each CSG2 supports one quota server and multiple idle standby quota servers. The CSG2 allows multiple groups of subscribers on each quota server, with one quota manager for each subscriber. Figure 1-11 illustrates a typical CSG2 prepaid content billing network.
Figure 1-11 CSG2 Prepaid Content Billing Network
User ID database GGSN Mobile client Private network CSG2 XML front end Quota server CNR (DHCP)
Client
Client
Quota is provided by the Quota Manager, on request for quota by the CSG2. This quota is either for an initial service connection, or for reauthorization when the original or last quota grant is depleted. The Quota Manager can provide a value ranging from 0 to 2,147,483,647 (0x00000000 to 0x7FFFFFFF). This value called quadrans comes in three forms: basis byte for volume-based billing, basis fixed for event-based billing, and basis second for duration-based billing. When quota is depleted to zero, the subscriber can no longer access the service. Quota is held on a per-service basis. Therefore, if a subscriber is connected to more than one service, the CSG2 stores quota for each service that is open. After the subscriber finishes a session by closing the bearer session (a RADIUS Accounting Stop message is sent from a GGSN), the service is stopped, and any unused quota is returned to the Quota Manager. While this prepaid system is in operation, the normal postpaid system runs by sending CDRs to the BMA. CSG2 prepaid differs from CSG1 mostly due to the greatly reduced use of reserved quota. HTTP reserves a small amount of quota while processing a single TCP packet; other protocols do not reserve quota at all. This has the following benefits:

Quota can no longer be trapped on a transaction that does not need the quota. The TLVs that contain quota balance and usage statistics are more accurate. Quota reauthorization thresholds are based on actual usage (except in some refund cases) instead of the sum of usage and reserved quota. Service-level CDRs are sent to BMAs at values closer to the volume thresholds.
1-48
201835
Billing Mediation Agent
Internet
OL-22840-05
Chapter 1
The following flow example describes a basic prepaid flow between the CSG2 and the Quota Manager:
1. 2. 3. 4. 5. 6. 7. 8. 9.
The NAS or GGSN sends a RADIUS Access Request message to the RADIUS Server. On receipt of a RADIUS Access-Accept message from the RADIUS Server, the NAS or GGSN sends a RADIUS Accounting Start message to the RADIUS Server. The CSG2 creates a subscriber entry and links the subscriber IP address to either the username or Calling Station ID (depending upon the configuration of the CSG2). The CSG2 sends a User Authorization Request to the Quota Manager. The Quota Manager replies to the CSG2 with a valid billing plan for the subscriber (User Authorization Response). Subscriber traffic begins to flow from the NAS or GGSN to the requested network. The CSG2 sends a Service Authorization Request to the Quota Manager, requesting quota for this connection. The Quota Manager returns a given quota in the Service Authorization Response (if there is quota to give). The subscriber traffic passes the CSG2 to the service, and the prepaid billing begins. the content and service time out.
10. A Service Stop occurs if either the NAS or GGSN sends a RADIUS Accounting Stop message, or if 11. The Service Stop provides the quota used and returns any remaining quota.
Dual Quota Support

The CSG2 enables you to charge two different billing bases (the plural of basis) for the same service. For example, you can charge for both time and volume. When a transaction is charged, quota is deducted from both configured bases. Both sets of quota are maintained and reported to the quota server. For more information, see the description of the basis command in CSG2 service configuration mode.
Quality of Service (QoS) Support

IP Quality of Service (QoS) provides appropriate network resources (bandwidth, delay, jitter, and packet loss) to applications. QoS maximizes the return on investments on network infrastructure by ensuring that noncritical applications do not hamper the performance of mission-critical applications. IP QoS can be deployed by defining classes or categories of applications. These classes are defined by using various classification techniques available in Cisco IOS software. After these classes are defined and attached to an interface, the desired QoS features, such as marking or policing, can then be applied to the classified traffic to provide the appropriate network resources amongst the defined classes. The CSG2 enables you to apply QoS to subscriber and network traffic. For example, you can limit (police) the rate of peer-to-peer traffic to and from a specific subscriber that passes through the CSG2. The CSG2 supports QoS Releases 5, 7, 8, and 99. For more information, see the Configuring Quality of Service (QoS) section on page 2-33.
1-49
Overview
NBAR Protocol Support

Classifying traffic is an important first step in configuring QoS in a network. Network Based Application Recognition (NBAR) is a Cisco IOS classification engine that can be used to classify packets and then apply QoS to the classified traffic. NBAR classifies a packet by inspecting its application layer data to determine the protocol being used. NBAR can classify existing CSG2 enhanced protocols over standard or non-standard ports. NBAR can also classify many other protocols for the CSG2 (basic protocol support) that do not use standard ports, including a number of peer-to-peer (P2P) and instant messaging (IM) protocols. For the CSG2, NBAR can classify the following protocols:
Table 1-3 TCP Stateful Protocols
TCP Stateful Protocol Exchange FTP HTTP
Type TCP TCP TCP
Description Microsoft Remote Procedure Call (MS-RPC) for Exchange File Transfer Protocol HTTP with URL, host, or MIME classification
Table 1-4
TCP and UDP Static-Port Protocols
TCP or UDP Static-Port Protocol HTTP IMAP POP3 RTP RTSP SIP SMTP
Type TCP TCP/UDP TCP/UDP TCP/UDP TCP/UDP UDP TCP/UDP
Well-Known Port 80 143, 220 110 5004, 5005 554 5060 161, 162
Description Hypertext Transfer Protocol Internet Message Access Protocol Post Office Protocol, version 3 Real-Time Transport Protocol Payload Classification Real Time Streaming Protocol Session Initiation Protocol Simple Network Management Protocol
Table 1-5
Peer-to-Peer (P2P) Protocols
P2P Protocol BitTorrent DirectConnect eDonkey eMule FastTrack Gnutella Jtella
Type TCP TCP/UDP TCP TCP TCP TCP TCP
Description File-Sharing Application File-Sharing Application File-Sharing Application File-Sharing Application File-Sharing Application File-Sharing Application File-Sharing Application
1-50
OL-22840-05
Chapter 1
Table 1-5
Peer-to-Peer (P2P) Protocols
P2P Protocol Kazaa2 WinMX
Type TCP TCP/UDP
Description File-Sharing Application File-Sharing Application
Table 1-6
Voice Over IP (VoIP) Protocols
VoIP Protocol Google MSN Skype version 1.x Skype version 2.x Skype version 3.0 Yahoo!
Type TCP/UDP TCP/UDP TCP/UDP TCP/UDP TCP/UDP TCP/UDP
Well-Known Port 5222, 5223 6901 80, 443 80, 443 80, 443
Description Google Talk MSN Messenger (Voice) Application allowing telephone conversation over the Internet Application allowing telephone conversation over the Internet Application allowing telephone conversation over the Internet
5000-5001 (TCP), Yahoo! Messenger (Voice) 5000-5010 (UDP)
Table 1-7
Instant Messaging (IM) Protocols
IM Protocol AIM
Type TCP/UDP
Well-Known Port 5190
Description AOL Instant Messenger NBAR supports only the classification of chat messages for AIM. NBAR does not support other AOL IM clients, such as the AIM Express web-based IM client. HTTP proxy and SOCKS proxy are not supported.
1-51
Overview
Table 1-7
Instant Messaging (IM) Protocols
IM Protocol MSN
Type TCP/UDP
Well-Known Port 1863, 5190, 6891 to 6901
Description MSN Messenger (IM) NBAR supports only the classification of chat messages for MSN IM. NBAR does not support other MSN IM clients, such as the MSN Web Messenger web-based IM client. SOCKS proxy is not supported.
Yahoo!
TCP
5010
Yahoo! Messenger (IM) NBAR supports only the classification of chat messages for Yahoo! Messenger (IM). NBAR does not support other Yahoo! IM clients, such as the Yahoo! Messenger for the Web web-based IM client. HTTP proxy and SOCKS proxy are not supported.
NBAR classification does not replace the CSG2 enhanced protocol inspection provided for the FTP, HTTP, IMAP, POP3, RTSP, SIP, and SMTP protocols. However, NBAR classification does allow for classification, charging, and control of those protocols over non-standard ports, or if any of those protocols do not match a defined content. NBARs ability to classify P2P traffic is a function of particular interest to the CSG2. The typical CSG2 protocol handler relies on well-known ports. Because P2P traffic does not use a standard port range, it is difficult to identify and classify P2P traffic. However, the CSG2 can use NBAR to classify P2P traffic.
Note
For non-P2P protocols, such as HTTP and RTSP, NBAR does not replace the Layer 7 inspection that the CSG2 protocol handlers perform. NBAR simply reports the traffic to the CSG2 as HTTP traffic, RTSP traffic, and so on. The CSG2 maintains packet and byte counts for all traffic classified by NBAR. TCP bytes are not reported in CDRs for accelerated NBAR sessions. For accelerated NBAR sessions, the number of TCP bytes reported in the TCP Stat TLV is set to 0. For more information about configuring the CSG2 to support NBAR, see the Configuring NBAR Protocol Support section on page 2-35. For more information about classifying network traffic using NBAR, including the protocols that NBAR supports, see the Classifying Network Traffic Using NBAR chapter of the Cisco IOS Quality of Service Solutions Configuration Guide, Cisco IOS Release 12.4:
http://cisco.com/en/US/docs/ios/qos/configuration/guide/clsfy_traffic_nbar_ps6350_TSD_Products_ Configuration_Guide_Chapter.html
1-52
OL-22840-05
Chapter 1
License-Exceeded Notifications
You can enable the CSG2 to generate license-exceeded notifications (syslog messages and SNMP traps) if the number of concurrent subscribers accessing the network exceeds a configured subscriber threshold. For more information, see the Configuring the Subscriber Threshold for License-Exceeded Notifications section on page 2-52.
User Logoff Notifications

You can enable the CSG2 to notify the BMA when it deletes a User Table entry for a user. User logoff notifications are not supported for sticky user entries in the User Table. To enable this feature, enter the following command in global configuration mode: Command
csg2(config)# ip csg report user logoff
Purpose Enables the CSG2 to send User Termination call detail records (CDRs) to the Billing Mediation Agents (BMAs).
Obtaining User IDs

The CSG2 uses two methods to obtain user IDs:
The CSG2 can use an external user ID database to map IP addresses to user IDs. When the CSG2 receives a packet with an unknown IP address, and it needs to associate the IP address with a user ID, it queries the database. If the user ID is not available, the CSG2 generates an accounting record without it. The CSG2 can act as a RADIUS Accounting Server or as a RADIUS proxy for RADIUS Accounting messages. The CSG2 can examine the accounting messages to determine the user IDs. (The CSG2 does not support full RADIUS Accounting.)
After identifying a subscriber, the CSG2 associates the subscribers IP address with the user ID. If a quota server has been defined, the CSG2 tries to download the subscribers profile. The profile indicates whether the subscriber is postpaid or prepaid and indicates the subscribers billing plan. If the subscriber is prepaid, the CSG2 also downloads the subscribers quota, and then forwards the subscribers flows.
Filtering Accounting
Filtering lets you specify the following items:

Sites to include or exclude for billing information. Specific sites are identified by URL, IP address, protocol, or port parameters. A customer string to insert in billing records for the specified site. That protocol-specific information is to be generated for billing records to a specified site.
The CSG2 supports Per-Event Filtering, which permits or denies a transaction as directed by the quota server. To enable Per-Event Filtering, use the aoc enable command in CSG2 service configuration mode.
1-53
Overview
Intermediate CDRs
Typically, the CSG2 sends two CDRs for each HTTP session. The CSG2 sends one CDR for all non-HTTP sessions, when the sessions end. However, for long-lived sessions, you might want to monitor the progress of the session. To monitor long-lived sessions, you can configure the CSG2 to send intermediate CDRs after a specified number of seconds, or after a specified number of bytes, whichever occurs first. Intermediate counts are also correlated between the active CSG2 and the standby CSG2. The CSG2 supports intermediate CDRs for FTP, HTTP, IP, RTSP, SIP, TCP, and UDP. The CSG2 does not support intermediate CDRs for DNS, WAP, or e-mail protocols (such as IMAP, POP3, and SMTP).
Accelerated Sessions
The CSG2 supports the acceleration of data flow packets using the IXP on the Cisco SAMI, resulting in greater throughput and packet rates. A subset of the packets in the flows is forwarded directly by one of the IXPs, without interaction with a PPC. The CSG2 supports accelerated sessions for postpaid Layer 4 inspection for the following protocols:

FTP HTTP with intermediate transaction-level CDRs (Requires out-of-order packet-forwarding) RTSP SIP TCP UDP NBAR after classification with intermediate transaction-level CDRs Summarized intermediate service-level CDRs, eG-CDRs, and Gx time-based event triggers are supported for duration-based billing (basis second), but not for volume-based billing (basis byte).
The CSG2 applies acceleration to HTTP and NBAR sessions on a per transaction basis. The CSG2 supports the acceleration of virtual prepaid sessions. Some transactions might not be accelerated because of issues with payload size, packet timing, system load, and so on. The CSG2 applies acceleration opportunistically to a subset of sessions. Therefore, the CSG2 might not accelerate all of the sessions that match an accelerated content definition. For example:

Internal implementation details of the CSG2 might prevent acceleration. Some load management conditions might prevent acceleration. Characteristics of the session or transaction might prevent acceleration, such as an HTTP transaction with a small content length A session that is subject to intermediate billing with an imminent CDR deadline might not be accelerated.
1-54
OL-22840-05
Chapter 1
When planning for accelerated sessions, keep the following considerations in mind:

The CSG2 does not support the acceleration of sessions for Layer 7 protocols other than HTTP and NBAR. The CSG2 does not support the acceleration of sessions associated with either per-user (billing plan-based) QoS or per-user-service (service-based) QoS. Accelerated sessions that are updated dynamically with QoS information do not honor the QoS while they are being accelerated.
The CSG2 does not support the acceleration of sessions if Roaming Service Control, also known as seamless roaming or RADIUS reauthorization, is configured. The CSG2 does not support the reporting of TCP bytes in CDRs for accelerated sessions
To enable accelerated sessions for a content, use the accelerate command in CSG2 content configuration mode. To set a session acceleration rate for the CSG2, use the ip csg load accel rate command in global configuration mode.
Packet Forwarding
The CSG2 forwards client/server traffic using next-hop, as specified in the content. For example:
ip csg content FORWARD-INTERNET-TRAFFIC ip any next-hop 1.1.1.1 policy FORWARD_PKT inservice
In this example, if traffic matches this content and policy, the CSG2 forwards the traffic to the next-hop router that has an IPv4 address of 1.1.1.1. The CSG2 supports next-hop packet forwarding for all protocols.
Note
Even if you have used the next-hop command in CSG2 content configuration mode to define a next-hop IPv4 or IPv6 address, traffic that matches the default content might not be routed with next-hop.
Per-User Uplink Next-Hop Support

In addition to content-configured next-hop IPv4 or IPv6 addresses, the CSG2 supports per-user uplink next-hop IP addresses. You can specify per-user uplink next-hop IP addresses in the following messages:

A RADIUS Access-Accept messages A RADIUS Accounting-Start messages A Gx Attribute Value Pair (AVP) in Re-Authorization Request (RAR) messages A Gx AVP in a Credit Control Answer (CCA) messages
When routing traffic, the CSG2 gives priority to content-configured next-hop IP addresses over per-user uplink next-hop IP addresses. However, you can change the order in which the CSG2 selects next-hop IP addresses. For more information, see the Changing the Order of Next-Hop IP Address Selection section on page 2-57.
1-55
Overview
URL-Redirect
You can configure the CSG2 to respond to an HTTP or WAP subscriber with a response code and a URL to which the subscriber must redirect. For more information about URL-redirect, see the Configuring URL-Redirect section on page 2-12.
Supplemental Usage Reports

You can configure the CSG2 to report supplemental usage to the quota server when sending a Service Stop, Quota Return, or Service Reauthorization Request message. For more information, see the Configuring Supplemental Usage Reporting section on page 2-40.
Enhanced Interoperability with Cisco Service-Aware GGSN

The CSG2 can couple with a Cisco GGSN to form a service-aware GGSN. When operating in this mode, the CSG2 gets quota from the GGSN. For more information, see the Cisco GGSN Release 5.2 Configuration Guide. The CSG2 can also exchange service usage information with the Cisco GGSN release 9.2 or later. Doing so enables the GGSN to generate eG-CDRs that contain service usage information for prepaid and postpaid users. For more information, see the Support for eG-CDRs with GGSN section on page 5-11. There are no new commands required to enable enhanced interoperability. However, to enable a quota server for eGGSN, enter the following command in global configuration mode: Command
csg2(config)# ip csg quota-server [vrf vrf-name] ipv4-address port-number eggsn
Purpose Configures a CSG2 quota server and enables it for eGGSN.

Note
The CSG2 does not support the use of the word forwarding as a valid VRF name.
Miscellaneous Features
The CSG2 provides the following miscellaneous features:

IP Fragment Support for All Protocols, page 1-57 Out-of-Order Packet Support for All Protocols, page 1-57 Enhanced Adaptability for Network-Generated Out-of-Order TCP Packets for Layer 4 Flows, page 1-57 Billing Chain Failure Notification, page 1-57 Asynchronous Service Stop, page 1-57 Support for Port Number Ranges, page 1-57 Service Rule Scaling, page 1-58 Packet Counts, page 1-58 Negative Quadrans, page 1-58
1-56
OL-22840-05
Chapter 1
IP Fragment Support for All Protocols

The CSG2 supports IP fragmentation for all protocols, including fragments that arrive out of order. There are no commands required to enable IP fragment support.
Out-of-Order Packet Support for All Protocols

When performing Layer 4 inspection of TCP-based protocols, the CSG2 forwards packets that are received out of order. When performing Layer 7 inspection of TCP-based protocols, the CSG2 buffers packets that are received out of order, and processes and forwards them in the proper order. There are no commands required to enable support for out-of-order packets.
Enhanced Adaptability for Network-Generated Out-of-Order TCP Packets for Layer 4 Flows
The CSG2 queues TCP packets that arrive out of order, and forwards them when the TCP stream catches up with the packet. Packets that arrive out of order cannot be parsed until the in-order data arrives. Therefore, forwarding of out-of-order TCP packets is supported only for the protocols that are not parsed by the CSG2: type other, FTP, RTSP, SIP, and NBAR. There are no commands required to enable support for out-of-order packets.
Billing Chain Failure Notification

Some quota servers can be configured to grant quota in a Service Authorization Response (or Quota Push) when communication to the back-end billing server fails. This feature enables the CSG2 to flag this condition in BMA records and in subsequent quota server requests. If the quota server sets this flag in a quota grant during the lifetime of a service instance, the CSG2 will flag this condition for all communication to the quota server and BMA during the lifetime of the service instance (that is, per-user service). There are no commands required to enable support for this feature.
Asynchronous Service Stop

The Asynchronous Service Stop feature allows the quota server to request the CSG2 to stop a prepaid service for a defined subscriber and service, and to send a Service Stop.
Support for Port Number Ranges

When you configure content on the CSG2, you can define a single port number, or a range of port numbers. This eliminates the need to configure a content for each port. When defining a range of port numbers, choose a range that is applicable to the associated policies. For example, defining a range of port numbers from 80 to 8080 for parse protocol http means that the CSG2 must perform intensive HTTP inspection on many intermediate ports, ports that might not be expected to carry HTTP flows. HTTP inspection of such a high volume of non-HTTP flows can result in excessive processing by the CSG2, as well as generating many CDRs that the customer had not planned for.
1-57
Chapter 1 CSG2 Prerequisites
Overview
Service Rule Scaling

The CSG2 supports up to 32,768 service rules, where a service rule is defined as a content/policy pair within a service applied to a billing plan.
Packet Counts
The CSG2 reports the number of IP bytes uploaded and downloaded, the number of TCP bytes uploaded and downloaded by the application, and the packet counts (or PDU counts for WAP records). These counts exclude the IP and TCP headers, as well as retransmissions.
Negative Quadrans
The quota balance in a prepaid service can become a negative value when the user's quota is being depleted, and the billing basis is byte ip or byte tcp. This can occur because the CSG2 forwards the entire received packet as long as the service's available quota is greater than 0. If the forwarded packet has more bytes than the quota balance, the balance becomes negative. Note that the CSG2 might report this negative balance to the quota server as a negative number in the Remaining Quota TLV.
CSG2 Prerequisites

The CSG2 supports IPv4, IPv6, and IPv4/v6 (dual-stack) addresses. Under certain conditions, such as low processor memory, a user session to the Cisco SAMI might fail. If this occurs, you will need to use the physical front panel consoles to access the Cisco SAMI. The CSG2 R5 runs with Cisco IOS Release 12.4(24)MDA or later. If your configuration supports the maximum IP packet length, you must also configure the buffers huge size 65535 command in global configuration mode. When you configure redundant CSG2s, the standby CSG2 must use the same software release as the active CSG2, or a later software release. If your CSG2s act as standbys for each other, they must all use the same software release. FTP requires a control TCP connection to well-known server port 21. Gx features in the CSG2 R5 and later require the 2 GB-SAMI option. The CSG2 R5 and later on the 1 GB-SAMI option does not support Gx.
CSG2 Restrictions

You can install one CSG2 on each Cisco SAMI module, and up to nine Cisco SAMI modules on each Cisco 7600 series router chassis. The CSG2 supports up to 5000 interfaces. The CSG2 does not support IP packets larger than 1500 bytes. The CSG2 supports up to 32 concurrently active Billing Mediation Agents (BMAs). The CSG2 supports up to 32 concurrently active quota servers. The CSG2 supports up to 2048 contents, with up to 2033 available for user configuration, and up to 1024 services.
1-58
OL-22840-05
Chapter 1
Overview CSG2 Restrictions
The CSG2 supports up to 8192 policies. The CSG2 supports up to 32,768 service rules, where a service rule is defined as a content/policy pair within a service applied to a billing plan. The CSG2 supports up to 128 billing plans. For maps, the CSG2 supports:
Up to 1408 match patterns per map Up to 1408 total match patterns per policy Up to 1408 total match patterns per content Up to 8192 total match patterns per CSG2 (assuming there is enough memory available)
The CSG2 supports up to 4,000 total VLANs (client and server). Do not reuse port numbers on the same IP address. The CSG2 drops packets with Layer 2, Layer 3, or Layer 4 errors, without charging for those packets. The CSG2 reports all times in Coordinated Universal Time (UTC), regardless of the setting of the clock timezone or clock summer-time command in privileged EXEC mode. The CSG2 does not support the clock set command in privileged EXEC mode. The CSG2 does not support the mset option on the standby timers command in interface configuration mode. The CSG2 supports the Cisco Persistent Storage Device Module Software Release 2.0 or later. The CSG2 does not support dynamic routing, only static routing. However, OSPF can be configured on the CSG2 to perform IPv4 route injection to neighboring nodes. If all quota servers fail, the CSG2 begins storing Service Stop Requests, in order to forward them when a quota server comes back online. In a Cisco mobile Service Exchange Framework (mSEF) GGSN-CSG2 environment, when the GGSN quota server comes back online and the CSG2 forwards the stored Service Stop Requests, if the subscribers packet data protocol (PDP) context is no longer active or is not known to the Diameter-Closed Loop Charging Interface (D-CLCI) backend, the GGSN quota server might respond to the request with GTP reject code 201. If there are no teletypes (TTYs) available, CSG2 configuration commands might fail. Therefore, do not allow the TTYs to become depleted.
1-59
Chapter 1 CSG2 Restrictions
Overview
1-60
OL-22840-05
CH A P T E R

This section describes the steps to take when installing and configuring the Content Services Gateway 2 (CSG2):

Preparing to Install the CSG2 Software, page 2-1 Installing the CSG2 Software, page 2-3 Upgrading the CSG2 Software, page 2-7 Saving and Restoring CSG2 Configurations, page 2-7 Configuring the CSG2 Features, page 2-8 CSG2 Configuration Examples, page 2-58
Note
For hardware requirements, such as power supply and environmental requirements, as well as hardware installation instructions, see the Service and Application Module for IP User Guide.
Preparing to Install the CSG2 Software

Before you install the CSG2, keep the following considerations in mind:
The CSG2 requires one of the following Cisco 7600 Series Routers and Supervisor Engines:
Cisco 7600 Series Supervisor Engine 720 with a Multilayer Switch Feature Card 3
(WS-SUP720) running Cisco IOS Release 12.4(33)SRB1 or later

Cisco 7600 Series Supervisor Engine 720 with a Multilayer Switch Feature Card 3 and Policy
Feature Card 3B (WS-SUP720-3B) running Cisco IOS Release 12.4(33)SRB1 or later

Cisco 7600 Series Supervisor Engine 720 with a Multilayer Switch Feature Card 3 and Policy
Feature Card 3BXL (WS-SUP720-3BXL) running Cisco IOS Release 12.2(33)SRB1 or later
Cisco 7600 Series Supervisor Engine 32 with a Multilayer Switch Feature Card
(WS-SUP32-GE-3B) running Cisco IOS Release 12.2(33)SRC or later and LCP ROMMON Version 12.2[121] or later on the Cisco SAMI
Cisco 7600 Series Supervisor Engine 32 with a Multilayer Switch Feature Card and 10 Gigabit
Ethernet Uplinks (WS-SUP32-10GE-3B) running Cisco IOS Release 12.4(33)SRC or later and LCP ROMMON Version 12.2[121] or later on the Cisco SAMI
Cisco 7600 Series Route Switch Processor 720 with Distributed Forwarding Card 3C
(RSP720-3C-GE) running Cisco IOS Release 12.4(33)SRC or later
2-1
Chapter 2 Preparing to Install the CSG2 Software
Cisco 7600 Series Route Switch Processor 720 with Distributed Forwarding Card 3CXL
(RSP720-3CXL-GE) running Cisco IOS Release 12.2(33)SRC or later The CSG2 does not support any earlier releases of the Cisco IOS. Therefore, you must upgrade to a Supervisor Engine running the specified Cisco IOS release or later, before installing the Cisco Service and Application Module for IP (SAMI), and before running or upgrading the CSG2 on the Cisco SAMI. For details on upgrading the Cisco IOS release running on the Supervisor Engine, refer to the Upgrading to a New Software Release section in the Release Notes for Cisco IOS Release 12.2SR for the Cisco 7600 Series Routers. For information about verifying and upgrading the LCP ROMMON image on the Cisco SAMI, see the Manually Upgrading an LCP ROMMON Image section in the Cisco Service and Application Module for IP User Guide.
You must configure virtual LANs (VLANs) on the Cisco 7600 series router and assign physical interfaces to the VLANs before you configure VLANs for the CSG2. The VLAN IDs for the router and for the CSG2 must be the same. For details, see the Cisco 7600 Series Cisco IOS Software Configuration Guide. If the Multilayer Switch Function Card (MSFC) is used on the next-hop router on either the subscriber-side VLAN or the network-side VLAN, then you must configure the corresponding Layer 3 VLAN interface.
Caution
If you use the MSFC as the router for both the subscriber side and the network side at the same time, you must ensure that packets for billable flows cannot bypass the CSG2. Also, if you use static ip route commands to switch traffic to the CSG2s, packets might loop between the MSFC and the CSG2 in this configuration. To avoid these problems, use other routing techniques to switch packets to the CSG2, such as policy-based routing. The following example shows how to configure the Layer 3 VLAN interface:
Sup> enable Sup# configure terminal Sup(config)# interface vlan 130 Sup(config-if)# ip address 10.10.1.10 255.255.255.0 Sup(config-if)# no shutdown Sup(vlan)# exit
The software interface for the CSG2 is the Cisco IOS command-line interface (CLI). The CSG2 CLI has been enhanced to increase its operational robustness, scalability and programmability. For more information about using the CLI and Cisco IOS command modes, see the Cisco 7600 Series Cisco IOS Software Configuration Guide. During the installation and configuration, enter all commands by either establishing a console connection with the CSG2, or by Telnetting to the CSG2. Enter each configuration command on a separate line. In any command mode, you can enter the question mark (?) at the prompt to see a list of available commands. For example:
Sup> ?
or
Sup(config)# ip csg ?
The online help shows the default configuration values and the ranges that are available for each command.
2-2
OL-22840-05
Chapter 2
Configuring the CSG2 Installing the CSG2 Software
Installing the CSG2 Software

You could install the CSG1 software from the Supervisor Engine boot flash memory, from a removable flash PC memory card inserted in the Supervisor Engine, or from an external TFTP server. However, you install the CSG2 software for the Cisco SAMI, independent of the Supervisor Engine. That is, no Supervisor Engine upgrade is needed when you install the CSG2 feature enhancements. To install the CSG2 software, follow these steps:
Step 1
Assign VLANs to the CSG2 by entering the following commands, beginning in privileged EXEC mode:
Sup# enable Sup# configure terminal Sup(config)# svclc vlan-group group-number vlan-range Sup(config)# svclc module slot-number vlan-group group-number Sup(config)# svclc multiple-vlan-interfaces
where:

group-number is the number of the VLAN group that you are assigning to the CSG2. vlan-range is a list of one or more VLANs in the group, specified as follows:
A single number in the range 2 to 1000 or 1025 to 4094 A range of numbers separated by a hyphen, such as 2-5 Single numbers or ranges of numbers separated by commas, such as 5,7-10,13,45-100
slot-number is the slot in which the CSG2 is installed.
For example, to assign VLAN groups 1 and 6 to the CSG2 in slot 2, enter the following commands, beginning in privileged EXEC mode:
Sup# enable Sup# configure terminal Sup(config)# svclc vlan-group 1 5,30,43,765 Sup(config)# svclc vlan-group 6 6 Sup(config)# svclc module 2 vlan-group 1,6 Sup(config)# svclc multiple-vlan-interfaces
Step 2
Bypass the Domain Name System (DNS) security for the remote copy protocol (rcp) and remote shell (rsh), by entering the following command in global configuration mode:
Sup(config)# no ip rcmd domain-lookup
Step 3
Enable the CSG2 to copy files to and from the Supervisor Engine, by entering the following command in global configuration mode:
Sup(config)# ip rcmd rcp-enable
Note
Because of the way the CSG2 configuration is stored on the Supervisor Engine, you cannot use the MIB to copy the startup CSG2 configuration directly off of the Cisco SAMI. The configuration must be collected via Telnet or Secure Shell (SSH). If you are using CiscoWorks RME to manage your configuration, make sure the option to enable Telnet or Secure Shell (SSH) collection is enabled Enable the CSG2 to execute commands on the Supervisor Engine using rsh or rcp, by entering the following command in global configuration mode:
Sup(config)# ip rcmd remote-host local-username {ip-address | host | access-list} remote-username [enable [level]]
Step 4
2-3
Chapter 2 Installing the CSG2 Software
where:

local-username is the name of the CSG2 on the local router. ip-address is the IP address of the remote host from which the local router will accept remotely executed commands. host is the name of the remote host. access-list is the number of an access list of remote hosts. remote-username is the name of the CSG2 on the remote host. enable enables the CSG2 to execute privileged EXEC commands using rsh, or to copy files to the router using rcp. level is the privilege level assigned to the CSG2. The privilege level defaults to 15, the highest level.
For example, to enable the CSG2 to copy commands to and from the Supervisor Engine, using remote host HOST1, at the highest privilege level, enter the following command in privileged EXEC mode:
Sup(config)# ip rcmd remote-host * HOST1 * enable
Step 5
Configure the Supervisor Engine as a Cisco Network Time Protocol (NTP) master clock to which the CSG2 can synchronize itself, by entering the following commands in global configuration mode:
Sup(config)# ntp master Sup(config)# ntp update-calendar
Step 6
Download a CSG2 software image from the Supervisor Engine by entering the following command from the Supervisor prompt:
Sup# upgrade hw-module slot slot-number software file name
where:

slot-number is the slot in which the Cisco SAMI is installed. name is the CSG2 image name.
The following message is displayed while the image is being downloaded: Copy in progress...CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC When the download is complete, the following prompt is displayed:
Sup#
Step 7
Power down and reset the CSG2 by entering the following command in privileged EXEC mode:
Sup# hw-module module slot-number reset
where slot-number is the slot in which the CSG2 is installed. The CSG2 powers down and resets.
Step 8
Establish a console session with the CSG2, by entering the following command in privileged EXEC mode:
Sup# session slot slot-number processor 3
Or Telnet to the CSG2, by entering the following command in privileged EXEC mode:
Sup# telnet 127.0.0.slot-number3
where:
2-4
OL-22840-05
Chapter 2
Configuring the CSG2 Installing the CSG2 Software
Step 9
slot-number is the slot in which the CSG2 is installed. 3 is the control processor (CP) number for the CSG2. Always session into CP 3 when configuring or monitoring the CSG2.
Define a GigabitEthernet subinterface for VLAN subscriber and network traffic, and enable 802.1Q encapsulation, by entering the following commands, beginning in privileged EXEC mode:
csg2# configure terminal csg2(config)# interface GigabitEthernet 0/0.3 csg2(config-if)# encapsulation dot1q vlan-id
where vlan-id is the VLAN identifier.

Step 10
Configure the VLAN as a subscriber interface for the CSG2, by entering the following command in interface configuration mode:
csg2(config-if)# ip csg subscriber
Step 11
Configure a primary IP address for the interface, by entering the following command in interface configuration mode:
csg2(config-if)# ip address ip-address ip-mask
where:
Step 12
ip-address is the primary IP address. ip-mask is the CSG2 mask for the associated IP subnet.
Configure a standby IP address to activate the Hot Standby Router Protocol (HSRP) for the interface, by entering the following command in interface configuration mode:
csg2(config-if)# standby ip ip-address
where ip-address is the standby IP address.

Step 13
If you are not configuring the CSG2 for redundancy ( that is, active-only operation), you must define a secondary IP address under the GigabitEthernet interface to be used as the RADIUS endpoint or RADIUS proxy CSG2 IP address. To do so, enter the following command in interface configuration mode:
csg2(config-if)# ip address ip-address ip-mask secondary
where:

ip-address is the secondary IP address. ip-mask is the CSG2 mask for the associated IP subnet.
If you are configuring the CSG2 for redundancy (that is, active-standby operation), you must define a standby secondary IP address as the RADIUS endpoint or RADIUS proxy CSG2 IP address.
Step 14
Identify the CSG2 as an endpoint for RADIUS Access and RADIUS Accounting messages, by entering the following command in global configuration mode:
csg2(config)# ip csg radius endpoint [vrf csg-vrf-name] csg-address key [encrypt] secret-string [vrf sub-vrf-name]
Or identify the CSG2 as a proxy for RADIUS Access and RADIUS Accounting messages by entering the following command in global configuration mode:
csg2(config)# ip csg radius proxy [vrf csg-vrf-name] csg-address [vrf server-vrf-name] server-address csg-source-address [key [encrypt] secret-string] [vrf sub-vrf-name]
2-5
Chapter 2 Installing the CSG2 Software
where:
vrf csg-vrf-name, vrf server-vrf-name, and vrf sub-vrf-name are the Virtual Routing and Forwarding (VRF) tables used for RADIUS communication.
Note Step 15
The CSG2 does not support the use of the word forwarding as a valid VRF name. csg-address is the CSG2 IP address. server-address is the RADIUS proxy server IP address. csg-source-address is the RADIUS proxy source IP address that the CSG2 is to use when sending packets to the server. key is the RADIUS key. encrypt indicates how the secret-string is represented when the configuration is displayed (for example, show run), or how it is written to nonvolatile memory (for example, write memory). secret-string is the clear password value for MD5 authentication.
Enable the CSG2 to synchronize its software clock with the one in the Supervisor Engine, by entering the following command in global configuration mode:
csg2(config)# ntp server 127.0.0.xy
where:
Step 16
x is the slot in which the Supervisor Engine is installed. y identifies the Supervisor Engine1 for Supervisor Engine 720.
Establish a static route for traffic to the CSG2, by entering the following command in global configuration mode:
csg2(config)# ip route ip-prefix ip-mask ip-address
where:
Step 17
ip-prefix is the IP route prefix for the destination. ip-mask is the IP prefix mask for the destination. ip-address is the IP address of the next hop that can be used to reach that network.
Power down and reset the CSG2 by entering the following command in privileged EXEC mode:
Sup# hw-module module slot-number reset
where slot-number is the slot in which the CSG2 is installed. The CSG2 powers down and resets.
2-6
OL-22840-05
Chapter 2
Configuring the CSG2 Upgrading the CSG2 Software
Upgrading the CSG2 Software

To upgrade the CSG2 software, follow these steps:
Step 1
Download a CSG2 software image from the Supervisor Engine by entering the following command from the Supervisor prompt:
Sup# upgrade hw-module slot slot-number software file name
where:

slot-number is the slot in which the Cisco SAMI is installed. name is the CSG2 image name.
The following message is displayed while the image is being downloaded: Copy in progress...CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC When the download is complete, the following prompt is displayed:
Sup#
Step 2
Establish a console session with the CSG2, by entering the following command in privileged EXEC mode:
Sup# session slot slot-number processor 3
Or Telnet to the CSG2, by entering the following command in privileged EXEC mode:
Sup# telnet 127.0.0.slot-number3
where:
Step 3
slot-number is the slot in which the CSG2 is installed. 3 is the control processor (CP) number for the CSG2. Always session into CP 3 when configuring or monitoring the CSG2.
At the prompt, enter the following command to reload the CSG2:

Router# reload
Saving and Restoring CSG2 Configurations

Note
In CSG1, the configuration was modified and stored along with the Supervisor Engine configuration. In CSG2, the configuration is modified and stored by either establishing a session with the control processor (CP), or via a direct console connection with the CSG2. To save the CSG2 configuration on the Supervisor Engine bootflash and slave bootflash, enter the following command in privileged EXEC mode:
csg2(config)# write memory
2-7
Chapter 2 Configuring the CSG2 Features
For more information about saving and restoring configurations, see the Cisco 7600 Series Cisco IOS Software Configuration Guide.
Configuring the CSG2 Features

Note
Unless otherwise specified, all the examples in this guide assume that you have already established a console session with the CSG2, or that you have Telnetted to the CSG2, and that you have entered the appropriate configuration mode for the command that you are configuring. Perform the following tasks to configure content billing features on the CSG2:

Configuring the User Database, page 2-9 Configuring the CSG2 User Table, page 2-9 Configuring the Fragment Database, page 2-11 Configuring the Session Table, page 2-11 Configuring URL-Redirect, page 2-12 Configuring Policies and Traffic Types, page 2-13 Configuring a Content Billing Service, page 2-14 Configuring a Billing Plan, page 2-14 Assigning a Default Billing Plan, page 2-15 Displaying Billing Plan User Counts, page 2-16 Configuring Content, page 2-16 Setting a Session Acceleration Rate for Contents, page 2-19 Configuring DNS Support, page 2-19 Configuring Header Insertion, page 2-25 Enabling Header Insertion, page 2-28 Configuring 3DEA Keys for Header Data Encryption, page 2-30 Configuring Single-TP Mode, page 2-30 Configuring Fixed, Variable, or Combined Format CDR Support, page 2-30 Configuring a Refund Policy on the CSG2, page 2-32 Configuring Quality of Service (QoS), page 2-33 Configuring NBAR Protocol Support, page 2-35 Configuring 8-Byte TLVs, page 2-38 Configuring HTTP Header Reporting, page 2-38 Configuring SMTP CDR Header Removal, page 2-39 Configuring Supplemental Usage Reporting, page 2-40 Configuring Actual PDU Reporting for WAP, page 2-40 Configuring CDR Suppression for Unestablished TCP Connections, page 2-40 Configuring Conditional CDR Blocking, page 2-41
2-8
OL-22840-05
Chapter 2
Configuring the CSG2 Configuring the CSG2 Features
Configuring Content Name Reporting, page 2-41 Configuring Policy Name Reporting, page 2-41 Configuring Flexible TCP Packet Counting, page 2-42 Configuring Maps for Pattern-Matching, page 2-43 Configuring Connection Redundancy, page 2-44 Configuring High Availability, page 2-44 Classifying Data Traffic, page 2-49 Configuring a CSG2 Subscriber Interface, page 2-49 Configuring Case Sensitivity, page 2-49 Configuring WAP and WSP Support, page 2-50 Blocking Ports, page 2-51 Configuring SNMP Timers, page 2-51 Configuring the Interval for Protocol Transaction Statistics, page 2-52 Configuring the Cisco SAMI Bit Rate Limit, page 2-52 Configuring the SNMP Notification Types, page 2-52 Configuring the Subscriber Threshold for License-Exceeded Notifications, page 2-52 Configuring Packet Logging and Reporting, page 2-53 Changing the Order of Next-Hop IP Address Selection, page 2-57
Configuring the User Database

The CSG2 can use an XML user database to associate an IP address with a user ID, and can refer to the database when it receives a packet with an unknown IP address. XML-based database queries add additional robustness to the CSG2, allowing continued monitoring across a failover, even in the absence of fresh RADIUS flows. To configure the user database that you want the CSG2 to query for user IDs, enter the following command in global configuration mode: Command
csg2(config)# ip csg database [vrf vrf-name] ipv4-address port-number local-port
Purpose Identifies the database server that answers CSG2 user ID queries. You can configure one and only one database server to answer CSG2 user ID queries.
Note
Configuring the CSG2 User Table

The CSG2 User Table identifies all subscribers known to the CSG2. The table is populated on the basis of the contents of RADIUS Accounting Start messages, or from the user database, if either feature is enabled in your configuration.
2-9
When the CSG2 processes a data packet, it searches the User Table and queries the user database for source and destination IP addresses that match the data packet:
1. 2. 3.
If the User Table contains an entry with a matching source IP address, the CSG2 uses that entry for charging and for CDR generation. If not, then if the User Table contains an entry with a matching destination IP address, the CSG2 uses that entry for charging and for CDR generation. If not, then if the user database is configured and it contains an entry with a matching source IP address or destination IP address, the CSG2 uses the IP address that is returned (and the associated user ID) for charging and for CDR generation. If neither the User Table nor the user database contains a matching source or destination IP address, then the CSG2 uses postpaid charging for the data packet, and the generated CDRs do not contain a user ID.
4.
To configure the User Table, enter the following command in global configuration mode: Command
csg2(config)# ip csg entries user profile {quota-server | radius {pass | remove | timeout timeout}}
Purpose Specifies the location from which the CSG2 is to obtain the subscriber profile and billing plan when generating entries for the User Table.
Note
To enable the CSG2 to parse user profile attributes in eGGSN mode, you must configure either the ip csg entries user profile radius pass command or the ip csg entries user profile radius remove command. For more information on eGGSN mode, see the Configuring Gx Support section on page 10-1.
You can set a global idle timer for User Table entries for all billing plans, and you can also set an individual User Table entry idle timer for each individual billing plan.

If an idle timer is set for a billing plan, the CSG2 uses that idle timer. Otherwise, the CSG2 uses the global idle timer.
That is, if there is an entry idle timer value in the billing plan, it is used; otherwise, if there is a global entry idle timer value configured, it is used. The idle timer for a subscriber entry starts when all billable sessions for that subscriber have ended. Typically, a TCP session ends when the subscriber and the network have sent FIN messages to each other. Other protocols time out based on the configured idle timer value in the content configuration. The timer restarts when a RADIUS Accounting Start or an Interim Accounting message is received. The timer stops when a session starts. When the idle timer expires, if Packet of Disconnect (PoD) is not configured, the CSG2 deletes the User Table entry. If Packet of Disconnect (PoD) is configured, the CSG2 sends a PoD message and the CSG2 deletes the User Table entry when the PoD message is ACKed, NAKed, or when all retries have been sent; the RADIUS Stop message does not have to be received by the CSG2. The idle timer also enables the CSG2 to eliminate an idle User Table entry if the NAS fails to deliver a RADIUS Accounting Stop request for an idle subscriber. Eliminating idle entries from the User Table frees up CSG2 resources. If Connection Duration Billing is enabled, you can use either the global entry idle timer or the billing plan entry idle timer to release a subscriber connection. The idle timer does not affect sticky user entries.
2-10
OL-22840-05
Chapter 2
To set a global User Table idle timer, enter the following command in global configuration mode: Command
csg2(config)# ip csg entries user idle duration [pod]
Purpose Specifies how long the CSG2 is to retain entries in the CSG2 User Table.
To set a User Table idle timer for a specific billing plan, enter the following command in CSG2 billing configuration mode: Command
csg2(config-csg-billing)# entries user idle duration [pod]
Purpose Sets the time after which entries for idle subscribers are deleted from the CSG2 User Table.
The CSG2 User Table can hold up to 1250000 entries with the 2 GB-SAMI option, or up to 500000 entries with the 1 GB-SAMI option. However, the CSG2 also enables you to specify the maximum number of entries allowed in the User Table. To do so, enter the following command in global configuration mode: Command
csg2(config)# ip csg entries user max entries
Purpose Specifies the maximum number of entries allowed in the CSG2 User Table. The maximum number of entries is not enforced on the buffer pool maximum size, it is enforced during allocation of individual entries to the User Table.
Configuring the Fragment Database

The CSG2 enables you to define the maximum number of entries in the CSG2 fragment database, as well as how long the CSG2 is to retain the entries. The CSG2 divides the configured maximum number of entries evenly among the traffic processors. For example, if you configure a maximum of 100 entries, the maximum buffer pool size on each traffic processor is 20. To configure the fragment database, enter the following command in global configuration mode: Command
csg2(config)# ip csg entries fragment {idle duration | maximum entries-number}
Purpose Defines the maximum number of entries in the CSG2 fragment database, or defines how long the CSG2 is to retain the entries.
Configuring the Session Table

The CSG2 enables you to specify the maximum number of entries allowed in the CSG2 session table. This is the maximum number of sessions that the CSG2 can support. When the number of active sessions reaches the specified maximum, the CSG2 begins dropping incoming new sessions.
2-11
The maximum number of entries is not enforced on the buffer pool maximum size, it is enforced during allocation of individual subscriber sessions to the table. To specify the maximum number of entries allowed in the CSG2 session table, enter the following command in global configuration mode: Command
csg2(config)# ip csg entries session user max entries
Purpose Specifies the maximum number of entries allowed in the CSG2 session table.
Configuring URL-Redirect
The CSG2 can redirect subscriber flows to an alternate IP address or URL when a subscribers quota is exhausted. Once configured, the CSG2 redirects subscriber requests to another network that informs the subscriber that the quota has been exceeded and that describes any appropriate actions to take. In a redirect scenario, the CSG2 responds to the HTTP or WAP subscriber with a response code and a URL to which the subscriber must be redirected. You can configure the redirect URL using the ip csg redirect command in CSG2 user group configuration mode, or the quota server can provide the redirect URL during service authorization (or reauthorization) or content authorization processing. For service authorization or content authorization, the quota server reply contains the REDIRECT-URL action code and the redirect URL. In some network configurations, you might want the quota server to return the same redirect URL for HTTP and WAP. If you do not want to use a single redirect URL, the service authorization and Content Authorization Requests identify whether the request is for HTTP or WAP. A redirect URL that is returned from the quota server in a service authorization response, or that is returned in a Content Authorization Response with the REDIRECT_URL action code, takes precedence over a redirect URL that is configured using the ip csg redirect command. The CSG2 uses the URL specified by the ip csg redirect command when the quota server responds with the FORWARD action code.

The ip csg redirect http command redirects subscriber HTTP flows to the specified alternate URL when the subscribers quota is exhausted. The ip csg redirect sip command redirects subscriber SIP flows to the specified alternate URL when the subscribers quota is exhausted. The ip csg redirect interval command specifies the length of time, in seconds, during which the CSG2 redirects an out-of-quota subscriber. After this interval, the CSG2 drops the requests until quota can be requested again. The start of the interval is the time of the first redirect after a quota grant of zero. The counter is reset, and the timer is stopped after another quota grant of zero is given. The ip csg redirect maximum command specifies the maximum number of times a redirect is to be performed for an out-of-quota subscriber during a redirect interval. The ip csg redirect wap command redirects subscriber WAP flows to the specified alternate URL when the subscribers quota is exhausted. The ip csg redirect interval command is set to 8 seconds. The ip csg redirect maximum command is set to 15. The CSG2 receives a Service Authorization Response with zero quadrans.
For example, if all of the following conditions are met:

2-12
OL-22840-05
Chapter 2
The CSG2 has redirect information.
Then redirection occurs when the subscriber runs out of quota (assuming that the subscriber has not received quota in the interim). The 8-second timer starts after the first redirect. Therefore, request 1 is redirected, and up to 14 more requests can be redirected, if they occur within 8 seconds after the first redirect. URL-redirect requires configuration of a policy and service so that subscribers who have exhausted their quotas can access the network specified in the redirect URL. To redirect subscriber flows to an alternate IP address when the subscribers quota is exhausted, or to set the amount of time and the number of redirects that the CSG2 allows, enter the following command in global configuration mode: Command
csg2(config)# ip csg redirect {http url | interval seconds | maximum number | sip url | wap url}
Purpose Redirects subscriber flows to an alternate IP address when the subscribers quota is exhausted.
Configuring Policies and Traffic Types

Policies are access rules that traffic must match in order to be handled by a specific server farm. Policies allow the CSG2 to apply filters to certain types of traffic subject to the accounting service. When the CSG2 matches policies, it selects the policy that appears first in the policy list. Policies are located in the policy list in the sequence in which they were configured in the content. You can reorder the policies in the list by removing policies and reentering them in the order that you prefer. To configure accounting records policies, enter the following commands beginning in global configuration mode: Command
Step 1
csg2(config)# ip csg policy policy-name
Purpose Defines a policy for qualifying flows for CSG2 billing services, and enters CSG2 policy configuration mode. Because of limitations on the number of URL match patterns that the CSG2 can handle, do not define more than 16,000 policies.
Step 2
csg2(config-csg-policy)# accounting [customer-string string]
Specifies accounting and an optional customer string for a CSG2 policy. This command is required if the CSG2 is to generate CDRs for content that matches the CSG2 policy. For FTP and RTSP accounting, the CSG2 matches prepaid services on the basis of the IP address and port number of the control connection to the FTP or RTSP server IP address.
Step 3
csg2(config-csg-policy)# class-map class-map-name
Associates a global class map with a CSG2 policy. You can associate each CSG2 policy with one and only one class map. You can either configure maps (that is, attribute, header, method, or URL maps) on a given policy, or you can associate the policy with a class map; you cannot do both. If you do, the CSG2 ignores the configured maps.
2-13
Command
Step 4 Step 5
csg2(config-csg-policy)# insert header-group header-group-name csg2(config-csg-policy)# map map-name
Purpose Associates a header group for a CSG2 policy. References an attribute, header, method, or URL map that is part of a CSG2 billing policy. The conditions specified in the referenced map must be true in order for the flows to be processed by the CSG2 accounting services. If the conditions are not true, the flows are not processed. You can either configure maps (that is, attribute, header, method, or URL maps) on a given policy, or you can associate the policy with a class map; you cannot do both. If you do, the CSG2 ignores the configured maps.
Configuring a Content Billing Service

A CSG2 content billing service is a component of a billing plan to which subscribers subscribe. For information on configuring one or more content billing services for the CSG2, see the Configuring Service Support section on page 5-1.
Configuring a Billing Plan

A CSG2 billing plan is a set of services. When the CSG2 encounters a new subscriber, the CSG2 retrieves the subscribers billing plan. You can define up to 128 billing plans. To configure a billing plan, enter the following commands beginning in global configuration mode: Command
Step 1
csg2(config)# ip csg billing billing-plan-name
Purpose Defines a CSG2 billing plan, and enters CSG2 billing configuration mode. Because of limitations on the number of URL match patterns that the CSG2 can handle, do not define more than 16,000 policies.
Step 2 Step 3 Step 4 Step 5 Step 6
csg2(config-csg-billing)# service service-name [mode {postpaid | prepaid virtual}] csg2(config-csg-billing)# entries user idle duration [pod] csg2(config-csg-billing)# mode {postpaid | prepaid [virtual]} csg2(config-csg-billing)# offline csg2(config-csg-billing)# user-default
Associates a service with a CSG2 billing plan. (Optional) Sets the time after which entries for idle subscribers are deleted from the CSG2 User Table. (Optional) Specifies the mode for a CSG2 billing plan. (Optional) Enables offline billing for a CSG2 billing plan. (Optional) Designates a CSG2 billing plan as the default billing plan.
2-14
OL-22840-05
Chapter 2
Offline Billing Control

Offline billing enables the CSG2 to send CDRs to the BMA. By default, offline billing is enabled. If offline billing is disabled, the CSG2 does not send CDRs to the BMA. The enabling and disabling of offline billing is also supported for preloaded billing plans. To disable offline billing, enter the following command in CSG2 billing configuration mode: Command
csg2(config-csg-billing)# no offline
Purpose Disables offline billing for a CSG2 billing plan.
If offline billing is disabled and you want to enable it, enter the following command in CSG2 billing configuration mode: Command
csg2(config-csg-billing)# offline
Purpose Enables offline billing for a CSG2 billing plan.
Assigning a Default Billing Plan

If no external entity can assign a billing plan to a subscriber (for example, if no quota server is available), the CSG2 can assign a user-specified default billing plan to the subscriber. You can designate only one billing plan as the default billing plan. The default billing plan can be prepaid or postpaid. In order for the CSG2 to assign the default billing plan to the subscriber, an entry in the CSG2 User Table must be created for the subscriber by RADIUS or by the user database. Sticky user entries in the CSG2 User Table cannot use the default billing plan. If a subscriber is assigned to the default billing plan because there are no active quota servers, and a quota server then becomes active, the subscriber continues to use the default billing plan. To designate a billing plan as the default billing plan, enter the following command in CSG2 billing configuration mode: Command
csg2(config-csg-billing)# user-default
Purpose Designates a CSG2 billing plan as the default billing plan.
To designate a different billing plan as the default billing plan, use the following procedure:
Step 1 Step 2
Remove the default designation from the old default billing plan, using the no form of the user-default command. Designate the new billing plan as the default billing plan, using the user-default command.
2-15
Displaying Billing Plan User Counts

The CSG2 can display the user count for a billing plan. To display the total number of CSG2 users with valid billing plans, and the current user counts and the highwater user counts for all billing plans, enter the following command in privileged EXEC mode: Command
Sup(config)# show ip csg billing user count
Purpose Displays user counts for all billing plans (those that were configured via CLI and those that were preloaded).
To display the current user count and the highwater user count for a specific billing plan, use the show ip csg billing plan billing-plan-name user count command in privileged EXEC mode. Command
Sup(config)# show ip csg billing plan billing-plan-name user count
Purpose Displays user counts for the specified billing plan.
Configuring Content
The CSG2 uses the Cisco command-line interface (CLI), and requires content configurations or virtual server configurations. This section provides information about configuring content. A CSG2 content configuration contains the following information:

Layer 3 information that specifies the IP-level details of the content. Layer 4 information that specifies transport layer parameters, such as TCP and User Datagram Protocol (UDP) port numbers.
In order to determine the service for a subscriber, the CSG2 first matches a content with the first packet in a flow, then matches the policy. The CSG2 then uses the content, policy, and the subscribers billing plan to determine the service. If the content configuration does not match any service listed under a subscribers billing plan, the CSG2 considers the service to be either free or postpaid, and the CSG2 forwards the flow and does not try to authorize the subscriber with the quota server. If BMAs are configured, the CSG2 generates a per-transaction CDR. The CSG2 supports overlapping contents, as when one content is a subset of another. If one content overlaps another, the CSG2 selects the content that best matches the flow. For example, if you configure Content A with ip any and Content B with ip any tcp 80, the CSG2 matches TCP port 80 flows to Content B, because ip any tcp 80 is a more precise match than ip any. The CSG2 does not support duplicate contents. That is, you cannot configure two contents with identical configurations.
2-16
OL-22840-05
Chapter 2
To configure content for a CSG2 accounting service, enter the following commands beginning in global configuration mode: Command
Step 1 Step 2
csg2(config)# ip csg content content-name
Purpose Configures content for CSG2 accounting services, and enters CSG2 content configuration mode. References a standard access list that is part of a CSG2 content. Enables the CSG2 to use URL mapping to assign a policy to an RTSP control session. Defines the subset of Layer 3 and Layer 4 flows that can be processed by the CSG2 accounting services using IPv4 addressing. You can define port-number as a single value or as a range of numbers. We recommend that all content that is configured for NBAR processing (parse protocol nbar) also be configured to match all traffic, using the ip any command.
csg2(config-csg-content)# client-group {std-access-list-number | std-ipv4-access-list-name | ipv6 std-ipv6-access-list-name} csg2(config-csg-content)# control-url [interleaved
Step 3 Step 4
csg2(config-csg-content)# ip {any | ipv4-address [ipv4-mask]} [any | protocol [port-number [last-port-number]]]
Step 5
csg2(config-csg-content)# parse protocol {dns | ftp | http [insert] | imap | nbar | other | pop3 | rtsp | sip | smtp | wap {connection-oriented | connectionless}} csg2(config-csg-content)# policy policy-name [priority priority-number] csg2(config-csg-content)# accelerate
Defines how the CSG2 is to parse traffic for a content.
Step 6 Step 7 Step 8 Step 9
Associates a CSG2 billing policy with a content. (Optional) Enables acceleration for sessions that match a CSG2 content. (Optional) Forces the CSG2 to drop packets that do not match a configured billing policy. (Optional) Specifies the minimum amount of time that the CSG2 maintains an idle content connection. (Optional) Defines the subset of Layer 3 and Layer 4 flows that can be processed by the CSG2 accounting services using IPv6 addressing. (Optional) Specifies the mode for CSG2 TCP sessions. (Optional) Defines a next-hop IPv4 or IPv6 address.
csg2(config-csg-content)# block
csg2(config-csg-content)# idle duration
Step 10 csg2(config-csg-content)# ipv6 {any | ipv6-address |

ipv6-prefix} [any | protocol] [port-number]
Step 11 csg2(config-csg-content)# mode tcp

{datagram | transparent [zero]}
Step 12 csg2(config-csg-content)# next-hop

{ipv4-address | ipv6 ipv6-address} [reverse | subscriber [media]]
Step 13 csg2(config-csg-content)# normalize-url
(Optional) Enables URL map normalization for a CSG2 content.
2-17
Command
Step 14 csg2(config-csg-content)# parse length number
Purpose (Optional) Defines the maximum number of Layer 7 bytes that the CSG2 is to parse when attempting to assign a policy. If the parse length is exceeded, the CSG2 blocks or forwards packets on the basis of the block command. This command is valid only if parse protocol http or parse protocol nbar is also configured.
Step 15 csg2(config-csg-content)# pending timeout Step 16 csg2(config-csg-content)# records delay seconds
(Optional) Sets the pending connection timeout. (Optional) Specifies the delay before the CSG2 is to send the HTTP Statistics CDR. Specifying a records delay enables CSG2 accounting for retransmitted packets and ACKs after the transaction closes, but before the connection closes.
Step 17 csg2(config-csg-content)# relative
(Optional) Enables relative URI support for CSG2 URL matching. The CSG2 supports relative URIs for HTTP only. (Optional) Enables the generation of intermediate CDRs. If you do not specify the records intermediate command, or if you specify the records intermediate command for a content for a protocol handler that does not support intermediate statistics, the CSG2 does not generate intermediate CDRs.
Step 18 csg2(config-csg-content)# records intermediate

{bytes bytes | seconds seconds | bytes bytes seconds seconds}
Step 19 csg2(config-csg-content)# replicate [delay seconds]
(Optional) Replicates the connection state for all TCP connections to the CSG2 content servers on the standby system. Replication is not supported for DNS, or WAP 1.x. For HTTP, the replicated session is treated as Layer 4. No HTTP parsing is performed when the replicated session on the standby CSG2 becomes active.
Step 20 csg2(config-csg-content)# subscriber-ip http-header

x-forwarded-for [obscure]
(Optional) Specifies that the CSG2 is to obtain the subscriber's IP address from the HTTP X-Forwarded-For header. Single-TP mode is required for HTTP X-Forwarded-For operation. Before configuring the CSG2 for X-Forwarded-For operation, configure the CSG2 for single-TP mode by entering the ip csg mode single-tp command, then performing a write memory, then restarting the CSG2. If your configuration is fault-tolerant, and you want to obscure the contents of X-Forwarded-For headers, do not configure the replicate connection tcp command in CSG2 content configuration mode.
2-18
OL-22840-05
Chapter 2
Command
Step 21 csg2(config-csg-content)# vlan vlan-number
Purpose (Optional) Restricts CSG2 billing content to a single source VLAN. The VLAN number is dependent on the CSG2 card that receives the content. When the content is downloaded to a CSG2 card, the vlan-number argument is mapped to a specific VLAN number.
Step 22 csg2(config-csg-content)# vrf vrf-name
(Optional) Restricts the CSG2 content to packets within a single Virtual Routing and Forwarding (VRF) table.
Note
The CSG2 does not support the use of the word forwarding as a valid VRF name. If there are sessions on a content, and you take the content out of service (with the no inservice command), the CSG2 does not allow the content to be placed back in service (with the inservice command) until the sessions have been cleaned up. If you try to enter the inservice command before the CSG2 has cleaned up the sessions, the command fails.
Step 23 csg2(config-csg-content)# inservice
Activates the content service on each CSG2.

Note
Setting a Session Acceleration Rate for Contents

The CSG2 enables you to set a session acceleration rate for all contents that are enabled for session acceleration. The CSG2 applies the session acceleration rate to each traffic processor (TP). That is, the rate is set on a per-TP basis, not on a per-content basis. To set a session acceleration rate for the CSG2, enter the following command in global configuration mode: Command
csg2(config)# ip csg load accel rate accel-rate
Purpose Sets a session acceleration rate for the CSG2, in connections per second.
Configuring DNS Support

The Domain Name System (DNS) protocol is a Layer 7 application protocol used for translating domain names into IP addresses. The CSG2 supports Layer 7 inspection of DNS traffic over both TCP and UDP, which enables postpaid and prepaid billing of individual DNS transactions. This section contains the following information:

Enabling DNS Global Domain Mining section on page 2-20 Defining DNS Domain Groups section on page 2-20 Populating the DNS IP Map Table section on page 2-21
2-19
Defining a DNS Catchall Content section on page 2-22 Updating DNS Domain Groups section on page 2-23 Implementing Virtual Contents section on page 2-23 Enabling DNS Refunding section on page 2-23 DNS Feature Support and Restrictions section on page 2-24 Sample DNS Configurations section on page 2-24
Enabling DNS Global Domain Mining

To enable the CSG2 to bill for DNS transactions, you must first enable global domain mining. Global domain mining is the process by which the CSG2 parses, or mines, DNS transactions, collecting the domain names and associated server IP addresses and Virtual Routing and Forwarding (VRF) tables. To enable global domain mining for the CSG2, enter the following command in global configuration mode: Command
csg2(config)# ip csg domain mining
Purpose Enables global domain mining for the CSG2.
Defining DNS Domain Groups

When mining DNS transactions, the CSG2 collects only those domain names that are defined in DNS domain groups. A domain group is a set of domain match patterns used to select and characterize domains that are mined by contents that have DNS parsing and mining enabled. The domain group is global. When a content enables DNS parsing and DNS mining, the CSG2 matches domains that are extracted from parsed transactions against the set of global domain groups. To define a domain group, enter the following commands beginning in global content configuration mode: Command
Step 1 Step 2
csg2(config)# ip csg domain group domain-group-name priority priority csg2(config-csg-domain-group)# match domain value
Purpose Defines a CSG2 domain group, and enters CSG2 domain group configuration mode. Defines a domain name match pattern for a CSG domain group.
In addition to enabling global domain mining for the CSG2, you must enable domain name mining for one or more contents in order for the CSG2 to add IP address-to-domain group mapping entries to the DNS IP Map Table.
2-20
OL-22840-05
Chapter 2
To enable DNS support for a content, and to associate a content with a domain group, enter the following commands in CSG2 content configuration mode: Command
Step 1
csg2(config-csg-content)# parse protocol dns
Purpose Traffic parsed by the CSG2 is parsed as DNS traffic. The CSG2 does not allocate resources to the DNS IP Map Table until at least one content configured with parse protocol dns is brought inservice.
Step 2 Step 3
csg2(config-csg-content)# domain group domain-group-name csg2(config-csg-content)# mining domain-group-name
Associates a CSG2 content with a DNS domain group. Enables domain name mining for the CSG2 content. Configure this command for DNS contents. Do not configure this command for virtual contents.
Step 4
csg2(config-csg-content)# inservice
Activates the content.

Note
If there are sessions on a content, and you take the content out of service (with the no inservice command), the CSG2 does not allow the content to be placed back in service (with the inservice command) until the sessions have been cleaned up. If you try to enter the inservice command before the CSG2 has cleaned up the sessions, the command fails.
Populating the DNS IP Map Table

When global domain mining is enabled, the CSG2 creates the DNS IP Map Table and begins populating it with configured domain groups mapped to their associated server IP addresses and VRF tables.

The CSG2 learns and stores entries in the DNS IP Map Table per traffic processor (TP). The CSG2 does not share information across TPs. The CSG2 includes only DNS type A results in the table. The CSG2 updates the time to live (TTL) for an existing entry in the table only if the update increases the TTL for the entry. In addition:
If the entry was created by an authoritative server, the update must come from an authoritative
server.
If the entry was created by a non-authoritative server, the update can come from either an
authoritative server or a non-authoritative server.

If a newly mined domain name maps to an unexpired entry in the table, but the new domain
group is different, the CSG2 updates the entry, including the TTL.

A DNS query might contain an IP address in search of a domain name. The CSG2 does not include such reverse DNS lookups in the table. The CSG2 does not support inverse queries (obsolete via RFC 3425).
2-21
To define the size of the DNS IP Map Table hash table, enter the following command in global configuration mode: Command
csg2(config)# ip csg entries dns map hash size
Purpose Defines the size of the DNS IP Map Table hash table.
The CSG2 deletes an entry from the DNS IP Map Table when the following conditions are met:

The entry must expire. The DNS map interval must elapse and the CSG2 must check for and delete the expired entry.
Between the time that the entry expires and the DNS map interval elapses, the CSG2 does not use the expired entry when matching flows. To define the maximum time to live (TTL) for entries in the DNS IP Map Table, enter the following command in global configuration mode: Command
csg2(config)# ip csg entries dns map ttl maximum seconds
Purpose Defines the maximum time to live (TTL) for entries in the DNS IP Map Table.
To define the minimum time to live (TTL) for entries in the DNS IP Map Table, enter the following command in global configuration mode: Command
csg2(config)# ip csg entries dns map ttl minimum seconds
Purpose Defines the minimum time to live (TTL) for entries in the DNS IP Map Table.
To define how often the CSG2 is to check for and delete expired entries in the DNS IP Map Table, enter the following command in global configuration mode: Command
csg2(config)# ip csg entries dns map interval
Purpose Defines how often the CSG2 is to check for and delete expired entries in the DNS IP Map Table.
Defining a DNS Catchall Content

It can take time to fully populate the DNS IP Map Table. Therefore, we recommend that you configure a catchall content to match all traffic, using the ip any command, to handle sessions until the table is fully populated.
2-22
OL-22840-05
Chapter 2
Updating DNS Domain Groups

Before updating a configured domain group, take any content that is associated with the domain group out of service. Then disable global domain mining for the CSG2, using the no form of the ip csg domain mining command in global configuration mode. When disabling global domain mining, keep the following considerations in mind:

We recommend that you disable global domain mining only during your maintenance window. If you disable global domain mining, you do not need to disable mining for any contents (using the no form of the mining command in CSG2 content configuration mode). Disabling global domain mining is sufficient. When global domain mining is disabled, the CSG2 can still use the DNS IP Map Table for lookups, but it cannot add to or update the table. If you leave global domain mining disabled, all of the entries in the table eventually expire and are deleted by the CSG2. How long it takes for all of the entries to expire depends on how long global domain mining is disabled, the setting of the ip csg entries dns map ttl minimum command in global configuration mode. If the changes you are making to domain groups could affect existing domain group matching, we recommend that you clear the DNS IP Map Table, using the clear ip csg dns map command in global configuration mode. For example, given an existing domain group Cisco1 configured with match domain *cisco.com.
If you add domain group Cisco2 configured with match domain *CISCO.com, existing
matching is not affected and you do not need to clear the DNS IP Map Table.
If you add domain group Cisco3 configured with match domain *wwwin.cisco.com, server IP
addresses and VRF tables that are currently mapped to Cisco1, but that could map to Cisco3, continue to map to Cisco1. Existing matching is affected and you do need to clear the DNS IP Map Table.
Implementing Virtual Contents

The CSG2 can bill subscriber flows differently depending on where they are headed. For example, the CSG2 can bill traffic destined for a partner's server differently than traffic destined for a competitor's server. To accomplish this differentiated billing, the CSG2 uses DNS virtual contents. A virtual content is a CSG2 content that is configured to match on a set of DNS domains in addition to the standard configured qualifiers such as IP subnet, Layer 4 port, and so on. The CSG2 learns the IP addresses that belong to the DNS domains by mining DNS traffic. Thereafter, all subscriber flows destined for any of the learned IP addresses match that virtual content. Once the content is matched, the regular policy and service configurations provide the necessary differentiated billing. If a content specifies both an IP subnet and a set of DNS domains, the flow must match both qualifiers.
Enabling DNS Refunding

You can enable the CSG2 to refund for all unsuccessful DNS queries. Unsuccessful DNS queries include the following:

Non-zero return codes Truncated responses Redirected queries (referrals)
2-23
Incomplete transactions (no answer to a query)
To enable DNS refunding, enter the following command in CSG2 refunding configuration mode: Command
csg2(config)# flags dns value
Purpose Enables refunding for all DNS protocol transactions that do not complete successfully.
DNS Feature Support and Restrictions

The CSG2 supports the following features for DNS:

Attribute maps Basic Gx features IP fragments Layer 7 inspection of DNS traffic over both TCP and UDP. Out-of-order packets Postpaid and prepaid transaction CDRs and billing Refunding Service-level CDR summarization Virtual contents
The CSG2 does not support hosting more than one domain on a single IP address. If you configure a domain group so as to map IP addresses for domains hosted on virtual servers that share one IP address across more than one domain, the service provider will experience unexpected results. The CSG2 supports only domains that use dedicated sets of IP addresses. The CSG2 does not support the following features for DNS:

AoC redirection Content authorization DNS requests that are pipelined DNS requests that contain multiple queries. The CSG2 passes such requests without charge and without updating the domain information in the DNS IP Map Table. The CSG2 tracks the number of DNS requests that it parses that contain multiple queries. Fixed CDRs and fixed attribute CDRs HA session/transaction replication. You cannot configure the replicate command for a DNS content. Intermediate CDRs MapsHeader maps, method maps, and URL maps are not supported. Service verification
Sample DNS Configurations

The following is a sample DNS configuration. This sample configuration also shows how to assign a policy for DNS transactions using attribute maps that match on host headers:
ip csg map CISCO_MAP match attribute host www.cisco.com
2-24
OL-22840-05
Chapter 2
! ip csg policy CISCO accounting customer-string dns_cisco map CISCO_MAP ! ip csg policy CATCHALL accounting customer-string dns_catchall ! ip csg content DNS ip any 53 policy CISCO policy CATCHALL parse protocol dns mining inservice ! ip csg domain mining
The following is a sample DNS domain group configuration:

ip csg domain group CISCO priority 1 match domain www.CISCO.com* match domain www.cisco.com* ! ip csg policy CATCHALL accounting customer-string cisco1 ! ip csg content ANY domain group CISCO policy CATCHALL inservice ! ip csg domain mining
The following is a sample virtual content configuration:

ip csg domain group PARTNER priority 1 match domain www.CISCO.com* match domain www.cisco.com* ! ip csg content PARTNER ip any domain group PARTNER inservice ! ip csg domain mining
Configuring Header Insertion

The CSG2 can insert a configured set of headers into HTTP requests that match a policy or service. The network server uses the data in the inserted headers when determining how to fulfill the HTTP request. The data in the inserted headers can come from the following sources:

The configuration, as hard-coded strings RADIUS attributes and VSA subattributes Quota server responses Platform timestamps
2-25
When headers are inserted, some data might not be immediately available. For example, a configured header might specify that RADIUS attribute data is to be inserted, but if the CSG2 had not received the required RADIUS attribute at the time the user logged on to the network, then the RADIUS attribute data is not available for insertion. In such cases, the CSG2 inserts an empty header. (That is, the CSG2 inserts the header name with no header value.) Wireless TCP (WTCP) for header insertion is supported. WTCP is a proxy-based modification of TCP that is used in wireless networks to improve performance. This section contains the following information:

Configuring a Header, page 2-26 Configuring a Header Group, page 2-27 Enabling Header Insertion, page 2-28 Including and Excluding Headers for Insertion, page 2-29 Configuring 3DEA Keys for Header Data Encryption, page 2-30
Configuring a Header
You can configure a header for the CSG2 to insert in HTTP requests. The commands that are used to configure header data are order-sensitive. Each data item is inserted into the HTTP header, concatenated, in the order in which it was configured. For example, in the following sample configuration, the CSG2 inserts the string Clear text as data first, followed by the string My encrypted string (after it has been encrypted), followed by the timestamp.
ip csg header HDR-1 name X-HDR class abcd include string 1 Clear text encrypt begin string 2 My encrypted string encrypt end timestamp
As shown in the above example, header data can be encrypted. You cannot configure the following commands within the encrypted portion of the header (that is, between the encrypt begin and encrypt end commands):

class name timestampBecause the timestamp is constantly changing, the CSG2 does not allow it to be encrypted.
You can use the class command to assign a CSG2 header to a class of headers, and to specify a default include or exclude behavior for that header. You can use the radius command to specify a RADIUS attribute or VSA subattribute, and to indicate where it is to be inserted into a CSG2 header. Any information for the configured RADIUS attribute or VSA subattribute must be present in the incoming RADIUS Accounting-Start message.
2-26
OL-22840-05
Chapter 2
To configure a header for the CSG2, enter the following commands beginning in global configuration mode: Command
Step 1 Step 2
csg2(config)# ip csg header header-name
Purpose Defines a CSG2 header to be inserted in HTTP requests, and enters CSG2 header configuration mode. Specifies a name for a CSG2 header. When he CSG2 inserts the name into an HTTP header, it appends a colon (:) and a space to the name. For example, the name X-HEADER is inserted as X-HEADER: .
csg2(config-csg-header)# name name
Step 3
csg2(config-csg-header)# class class-name {exclude | include}
Specifies the class to which a CSG2 header belongs, as well as the default header insertion behavior to use for user profiles that do not specify a default behavior. Specifies when encryption is to begin and end for a CSG2 header. If you specify encrypt begin for a CSG2 header, but you do not specify encrypt end for the header, encryption continues to the end of the header configuration.
Step 4
csg2(config-csg-header)# encrypt {begin | end}
Step 5 Step 6
csg2(config-csg-header)# quota-server
Inserts data from the Quota-Server TLV into a CSG2 header. Specifies a RADIUS attribute or vendor-specific attribute (VSA) subattribute, and indicates where it is to be inserted into a CSG2 header. Specifies a text string and indicates where it is to be inserted into a CSG2 header. Indicates where a timestamp is to be inserted into a CSG2 header. The timestamp is the time, in Coordinated Universal Time (UTC) format, when the CSG2 inserted the header data into the HTTP header.
csg2(config-csg-header)# radius {radius-attribute-number | vsa {vendor-id | 3gpp} radius-subattribute-number} csg2(config-csg-header)# string string
Step 7 Step 8
csg2(config-csg-header)# timestamp
Configuring a Header Group

You can configure a header group for the CSG2 to insert in HTTP requests. You can configure many different header groups, each of which can include many different headers. However, the total number of header commands that you can configure on a given card is 4,000. That is, you can configure a single header-group of up to 4,000 headers; or one header group of 3500 headers and another of 500 headers; or any other combination of header groups and headers that does not exceed 4,000 total header commands. Duplicate header commands are included in the total. For example, if you include header HDR-TEST1 in five different header groups, that counts as five header inclusions, not just one.
2-27
To configure a header for the CSG2, enter the following commands beginning in global configuration mode: Command
Step 1 Step 2
csg2(config)# ip csg header-group group-name
Purpose Defines a CSG2 header group, and enters CSG2 header-group configuration mode. Includes a header in a CSG2 header group.
csg2(config-csg-header-group)# header header-name
The headers that are defined for a header group are order-sensitive. Each header in a header group is inserted into the HTTP header, concatenated, in the order in which it was configured. For example, given the following configuration:
ip csg header-group HG-1 header HDR-1 header HDR-2 header HDR-3
The data items for HDR-1 are inserted into the HTTP header first, then the data items for HDR-2, then the data items for HDR-3.
Enabling Header Insertion

You can specify a header group for insertion on a policy. When a flow is processed by the CSG2 such that the matched policy is configured with a header group, that flow is enabled for header insertion and the CSG2 inserts the specified header group. To specify a header group for insertion on a policy, enter the following command in CSG2 policy configuration mode: Command
csg2(config-csg-policy)# insert header-group header-group-name
Purpose Associates a header group for a CSG2 policy.
You can also specify a header group for insertion on a service. Specifying a header group on a service does not enable flows for header insertion. However, any header group specified on a service is inserted for any flows that are enabled for header insertion and that are using that service. If a flow matches a policy with a header group configured, and also uses a service with a header group configured, the policy match enables the flow for header insertion, and the CSG2 inserts the combined set of header groups from the policy and from the service into the flow. To specify a header group for insertion on a service, enter the following command in CSG2 service configuration mode: Command
csg2(config-csg-service)# header-group header-group-name
Purpose Associates associate a CSG2 header group with a CSG2 service. You can associate more than one header group with a given service, and you can associate a header group with more than one service.
2-28
OL-22840-05
Chapter 2
You can create a content that enables all matching flows for header insertion, but we do not recommend doing so. Enabling a flow for header insertion requires the CSG2 to buffer and copy packet contents. This reduces overall throughput for affected flows. To create a content that enables header insertion for all matching flows, enter the following command in CSG2 content configuration mode: Command
csg2(config-csg-content)# parse protocol http insert
Purpose Traffic parsed by the CSG2 is subject to HTTP header insertion. This command is supported for legacy configurations only.
Including and Excluding Headers for Insertion

When you configure a header for the CSG2, you can assign it to a class of headers, and you can specify a default include or exclude behavior for that class of headers. The CSG2 determines whether to insert a class of headers for a subscriber as follows:
1.
For RADIUS, the CSG2 can use the Cisco subattribute 1 VSA (VSA 9 1) to extract a subscribers include or exclude specification for a class of headers. For more information, see the Parsing RADIUS VSA Subattributes for Header Insertion Inclusion and Exclusion section on page 9-8. If the subscribers data specifies include or exclude for the class of headers, the CSG2 uses that specification. If the subscribers data specifies both include and exclude for the class of headers, the CSG2 includes the class of headers. If a subscriber opts out for a class of headers, the CSG2 does not insert headers of that class into HTTP requests for that subscriber. If a subscriber has opted out for all classes of header, the CSG2 forwards traffic for that subscriber by proxy without inserting any headers.
2.
If the subscribers data does not specify include or exclude for the class of headers, the CSG2 uses the configured default include or exclude specification for that class of headers, configured on the class command in CSG2 header configuration mode. For more information, see the Configuring a Header section on page 2-26. If there is no configured default include or exclude specification for the class of headers, the default behavior for the CSG2 is exclude. That is, the CSG2 does not insert that class of headers for that subscriber.
3.
To summarize the CSG2s include/exclude behavior for a class of headers: If the subscriber has specified include for a given class of header If the subscriber has specified exclude for a given class of header If the subscriber has specified both include and exclude for a given class of header And either include or exclude is The CSG2 inserts that class of configured on the class command for that headers for that subscriber. class of headers And either include or exclude is The CSG2 does not insert that configured on the class command for that class of headers for that class of headers subscriber. And either include or exclude is The CSG2 inserts that class of configured on the class command for that headers for that subscriber. class of headers
2-29
If the subscriber has specified neither include And include is configured on the class nor exclude for a given class of header command for that class of headers If the subscriber has specified neither include And exclude is configured on the class nor exclude for a given class of header command for that class of headers
The CSG2 inserts that class of headers for that subscriber. The CSG2 does not insert that class of headers for that subscriber.
Configuring 3DEA Keys for Header Data Encryption

HTTP headers flow in the clear over the Internet to the network server. However, you can configure the CSG2 to encrypt the data portion of a header using the Triple Data Encryption Algorithm (3DEA). To define 3DEA keys for the CSG2, enter the following command in global configuration mode: Command
csg2(config)# ip csg keys [encrypt] key1 key2 key3
Purpose Defines Triple Data Encryption Algorithm (3DEA) keys for the CSG2. All three keys are required.
Configuring Single-TP Mode

In normal multiple-TP mode, the CSG2 distributes subscriber traffic among all of the TPs, based on each subscribers IP address. In single-TP mode, the CSG2 dispatches traffic for all subscribers to the first TP to be processed. Single-TP mode is required for HTTP X-Forwarded-For operation. Before configuring the CSG2 for X-Forwarded-For operation, configure the CSG2 for single-TP mode, then perform a write memory, then restart the CSG2. To enable the CSG2 to use a single TP instead of multiple TPs, enter the following command in global configuration mode: Command
csg2(config)# ip csg mode single-tp
Purpose Enables the CSG2 to use a single TP instead of multiple TPs. If you intend to operate in single-TP mode, the ip csg mode single-tp command must be the first command in your CSG2 configuration.
Configuring Fixed, Variable, or Combined Format CDR Support

The CSG2 supports both fixed and variable format CDR generation. The CSG2 also supports combined (variable-single) format CDR generation for HTTP and WAP traffic. The same variables are reported in each CDR regardless of Wireless Session Protocol (WSP) Protocol Data Unit (PDU) type. CDRs contain zero-length variables when there is no information to report, but the same set of variables are always reported in the same sequence. Fixed record format generates CDRs that always contain the same set of Tag-Length-Values (TLVs). Some might have a length of zero. This format is primarily used for integration with legacy billing systems.
2-30
OL-22840-05
Chapter 2
Note
The CSG2 does not support fixed CDRs for IPv6 or for dual stack (IPv4/v6). The CSG2 supports Fixed CDRs only for IPv4. This section contains the following information:

Fixed CDR Support for HTTP and WAP, page 2-31 Fixed CDR Support for IMAP, page 2-31 Fixed CDR Support for RTSP, page 2-32 Single CDR Support for HTTP and WAP, page 2-32 Specifying the CDR Format, page 2-32
Fixed CDR Support for HTTP and WAP

The CSG2 provides fixed CDR support for HTTP and WAP. This support generates one fixed CDR for every HTTP transaction, instead of two CDRs, which are typically generated at the beginning and end of the transaction. The single CDR contains all the fields that are included in the HTTP header and HTTP statistics records, in a fixed format. In addition, the same fixed-format service TLVs that were included for WAP are also included for HTTP. The single CDR also includes RADIUS TLVs, in ascending order, based on the RADIUS TLVs configured using the ip csg report radius attribute command in CSG2 global configuration mode. This scheme is very flexible, enabling you to add RADIUS attributes dynamically. This function applies to both WAP and HTTP fixed CDRs. For more information, see the Reporting RADIUS Attributes and VSA Subattributes section on page 9-9. Fixed CDR support does not support RADIUS attribute 26 (the vendor-specific attribute, or VSA), because the list of attributes defined within the VSA is variable. Therefore, a predefined fixed list of attributes cannot be determined when RADIUS attribute 26 is configured. The CSG2 also supports fixed HTTP intermediate records. The fixed intermediate record format is identical to the format of the fixed record created at the end of the transaction, except for the message type, which is necessary to differentiate the two records. The intermediate statistics, such as TCP byte counts, are per intermediate period, and are not cumulative. This differs from the existing HTTP intermediate support for variable format CDRs, in which the TCP byte counts are cumulative. The Content Delivered TLV contains a value of 0x00 (not delivered) if the HTTP response code is greater than or equal to 400, or if the TCP byte download count is less than 12 bytes.
Fixed CDR Support for IMAP

The CSG2 provides fixed CDR support for the Internet Message Access Protocol (IMAP). When configuring CSG2 support for IMAP, keep in mind that the CSG2 cannot examine IMAP flows sent over an encrypted tunnel, such as Secure Socket Layer (SSL) or Transport Layer Security (TLS). When an encrypted tunnel is used for IMAP traffic, the CSG2 records only IP and TCP upstream and downstream byte counts. No other counts are provided.
2-31
Fixed CDR Support for RTSP

This feature enables the CSG2 to send the existing RTSP stream CDRs in a fixed format. The same fixed-format service TLVs that were included for WAP are also included for RTSP.
Single CDR Support for HTTP and WAP

For HTTP and WAP, the CSG2 reduces the multiple CDRs generated to a single CDR, which is reported at the end of the transaction. This feature is supported for both WAP connectionless and WAP connection-oriented traffic, as well as for HTTP traffic. The single CDR contains the standard variable format, and it also includes a comprehensive list of TLVs containing all pertinent information for the transaction. For WAP connectionless transactions, it includes everything that is included in a WAP GET and REPLY CDR. For HTTP transactions, it includes everything in the HTTP header and HTTP statistics records. When you configure single CDR support, the CSG2 suppresses HTTP intermediate record generation.
Specifying the CDR Format

To specify the CDR format to be used by the CSG2, enter the following command in global configuration mode: Command
csg2(config)# ip csg records format [fixed | variable [combined {http | wap}]]
Purpose Specifies variable, fixed, or combined (variable-single) CDR format.
Configuring a Refund Policy on the CSG2

The prepaid error reimbursement feature allows the CSG2 to automatically refund quota for failed transactions, as defined by the CLI. The CSG2 checks them in the following order: TCP/WAP flags, Application Return Code. The CSG2 supports flag-based refunding for all protocols. The CSG2 supports return code-based refunding for all protocols except RTSP. To configure a refund policy on the CSG2, enter the following commands beginning in global configuration mode: Command
Step 1 Step 2
csg2(config)# ip csg refund
Purpose Specifies a refund policy to apply to the various services, and enters CSG2 refund configuration mode. Specifies the range of application return codes for which the CSG2 refunds quota for Prepaid Error Reimbursement. The return codes are protocol-specific. Specifies protocol flag bit masks and values for CSG2 Prepaid Error Reimbursement.
csg2(config-csg-refund)# retcode {ftp | http | imap | pop3 | sip | smtp | wap} rc-start [rc-end] csg2(config-csg-refund)# flags {dns | ip mask | tcp mask| wap} value
Step 3
For information about enabling a refund policy for a service, see the Enabling a Refund Policy for a Service section on page 5-20.
2-32
OL-22840-05
Chapter 2
Configuring Quality of Service (QoS)

The CSG2 enables you to apply QoS to subscriber and network traffic. For example, you can limit (police) the rate of peer-to-peer traffic to and from a specific subscriber that passes through the CSG2. The CSG2 provides the following QoS support:

You can configure both per-user (billing plan-based) QoS and per-user-service (service-based) QoS. If user traffic matches both a billing plan configured for QoS and a service configured for QoS, the CSG2 applies the per-user-service QoS police rate first, then the per-user QoS police rate. If the traffic passes the per-user-service check, but then fails the per-user check, the CSG2 takes the action configured for per-user Qos on the qos profile (CSG2 billing) command. Therefore, if the per-user-service check is more stringent than the per-user check (assuming there is no traffic hitting other services for this user), then all packets that pass the per-user-service check should also pass the per-user check. You can set a maximum police rate and burst size for a billing plan or service. Excess packets can be transmitted, dropped, or marked. You can set different rates and burst sizes in the network-to-subscriber and subscriber-to-network directions. The CSG2 polices each QoS profile separately. For example, if two subscribers are assigned the same billing plan, and that billing plan has an attached QoS profile with a limit of 100,000 bits per second, then the CSG2 polices each subscriber's traffic to 100,000 bits per second, independent of the other.
The CSG2 can perform Differentiated Services Code Point (DSCP) marking of packets. You can set different markings in the network-to-subscriber and subscriber-to-network directions.
Note
The CSG2 does not inspect packets to see if the DSCP fields are already set. When the CSG2 sets a DSCP field, it overrides any marking that has already been applied to the packet (for example, by the GGSN). The CSG2 is transparent to DSCP tagging. When the CSG2 forwards a packet, it forwards the DSCP value without modification.
The CSG2 can block packets from specified services. Blocking applies in both the network-to-subscriber and subscriber-to-network directions. The CSG2 does not support any type of priority queueing for QoS. The CSG2 applies QoS on a per-packet basis.
For HTTP packets that span more than one transaction, such as multiple pipelined HTTP GET
requests, the CSG2 applies the per-user-service QoS profile associated with the first (oldest) transaction for which the packet has data.
For IP fragments, the CSG2 applies the QoS profile to the entire reassembled packet.
The CSG2 supports QoS for both eGGSN and Gi-Node modes. The QoS parameters can be provisioned via Gx or via the quota server. The CSG2 does not support QoS provisioning via the command-line interface (CLI) or via RADIUS messages. The quota server can use one of the following means to signal QoS for a subscriber:
A User Authorization Response (through the conditional QoS Rate Limit User TLV) A Service Authorization Response (through the conditional QoS Rate Limit User TLV) Quota Push Request (through the conditional QoS Rate Limit User TLV)
2-33
The CSG2 supports QoS for FTP, RTSP, and SIP only for the data or media session, not for the control session. The CSG2 does not support QoS for IMAP, POP3, or SMTP.
To enable QoS for the CSG2, you must first configure one or more QoS profiles. You can configure up to 2048 QoS profiles per CSG2. A QoS profile instance is consumed:

Every time you configure a QoS profile. Every time a new CSG2 User Table entry or service is instantiated that uses a billing plan or service that is associated with a QoS profile. If the QoS profile applies in both the network-to-subscriber direction and the subscriber-to-network direction, the Cisco SAMI considers that to be two separate QoS profiles. Every time a new CSG2 User Table entry or service is instantiated that receives per-user QoS or per-user QoS from the quota server via the conditional QoS Rate Limit User TLV.
To configure a QoS profile, enter the following commands beginning in global configuration mode: Command
Step 1
csg2(config)# ip csg qos profile qos-profile name
Purpose Configures a Quality of Service (QoS) profile name for the CSG2, and enters CSG2 QoS profile configuration mode. Configures rate limiting (policing) for a CSG2 Quality of Service (QoS) profile.
Step 2
csg2(config-csg-qos-profile)# police {rate police-rate burst burst-size | conform-action [drop | transmit | set-dscp-transmit dscp] | exceed-action [drop | transmit | set-dscp-transmit dscp] | conform-action [drop | transmit | set-dscp-transmit dscp] exceed-action [drop | transmit | set-dscp-transmit dscp]}
After configuring a QoS profile, you must associate it with a billing plan (for per-user QoS) or a service (for per-user-service QoS). You can implement Quality of Service (QoS) on a per-user-service basis (that is, you can apply the QoS to traffic to and from a particular subscriber and to a specific service). To associate a QoS profile with a billing plan, enter the following command in CSG2 billing configuration mode: Command
csg2(config-csg-billing)# qos profile qos-profile-name {network | subscriber}
Purpose Associates a Quality of Service (QoS) profile with a CSG2 billing plan.
To associate a QoS profile with a service, enter the following command in CSG2 service configuration mode: Command
csg2(config-csg-service)# qos profile qos-profile-name {network | subscriber}
Purpose Associates a Quality of Service (QoS) profile with a CSG2 service.
2-34
OL-22840-05
Chapter 2
If user traffic matches both a billing plan configured for QoS and a service configured for QoS, the CSG2 applies the per-user-service QoS police rate first, then the per-user QoS police rate. If the traffic passes the per-user-service check, but then fails the per-user check, the CSG2 takes the action configured for per-user Qos on the qos profile (CSG2 billing) command. Therefore, if the per-user-service check is more stringent than the per-user check (assuming there is no traffic hitting other services for this user), then all packets that pass the per-user-service check should also pass the per-user check. If you configure QoS for subscribers or services that bill HTTP, you must configure a delay on the HTTP contents to ensure accurate reporting of byte and packet counts in the transaction CDRs. We recommend a delay of at least 30 seconds. However, you might need to configure a longer delay, depending on your network conditions and QoS parameters. To configure a QoS delay for HTTP contents, enter the following command in CSG2 content configuration mode: Command
csg2(config-csg-content)# records delay seconds
Purpose Specifies the delay before the CSG2 is to send the HTTP Statistics CDR. Specifying a records delay enables CSG2 accounting for retransmitted packets and ACKs after the transaction closes, but before the connection closes. To display information about the QoS configuration, enter one of the following commands in privileged EXEC mode:
Command
csg2# show ip csg users all detail
Purpose Displays detailed information about all CSG2 subscribers, including information about the QoS configuration. Displays detailed information about the specified CSG2 subscriber, including information about the QoS configuration.
csg2# show ip csg users {ipv4-address ipv4-mask | id user-name} detail
For more information about QoS, including how to dynamically load protocol description language modules (PDLMs) and how to configure custom protocols, see the Cisco IOS Quality of Service Solutions Configuration Guide, Cisco IOS Release 12.4.
Configuring NBAR Protocol Support

NBAR is a Cisco IOS classification engine that the CSG2 can use to classify packets. The CSG2 can then use service-based QoS to apply QoS to the classified traffic. The CSG2 uses NBAR to classify peer-to-peer (P2P) traffic and other protocols, including custom protocols.
Note
For non-P2P protocols, such as HTTP and RTSP, NBAR does not replace the Layer 7 inspection that the CSG2 protocol handlers perform. NBAR simply reports the traffic to the CSG2 as HTTP traffic, RTSP traffic, and so on. Before configuring the CSG2 to use NBAR, you must configure a global class map. The global class map determines the P2P protocols that NBAR can classify.
2-35
To enable the CSG2 to use NBAR to classify P2P traffic, enter the following commands beginning in global configuration mode: Command
Step 1
csg2(config)# class-map [match-all | match-any] class-map-name
Purpose Creates a class map to be used for matching packets to a specified class, and enters class map configuration mode. Configures NBAR to match traffic by a protocol type that is known to NBAR. If you configure more than one match protocol command, you must specify match any on the class-map command. Here is a sample configuration for global class map GLOBAL:
class-map match-any GLOBAL match protocol bittorrent match protocol directconnect
Step 2
csg2(config-cmap)# match protocol protocol-name [variable-field-name-value]
Some Voice Over IP (VoIP) protocols use the Session Traversal Utilities for NAT (STUN) protocol. To enable NBAR to classify these protocols correctly, you must enable STUN, using the match protocol stun-nat command in class map configuration mode. You can enable STUN in any class map; it does not need to be enabled in the same class map in which the VoIP protocols are configured. Here is a sample configuration for a VoIP class map, with configuration for SIP, Google Talk, MSN Messenger (Voice), Yahoo! Messenger (Voice), and STUN:
class-map match-any voip match protocol sip match protocol gtalk-voip match protocol msn-voip match protocol yahoo-voip match protocol stun-nat
Note
For more information about configuring global class maps and using NBAR to classify traffic, see the Cisco IOS Quality of Service Solutions Configuration Guide, Cisco IOS Release 12.4. After you configure a global class map, you must associate it with a CSG2 policy. If you do not do so, the CDR cannot report the correct protocol. To associate a class map with a CSG2 policy, enter the following commands beginning in global configuration mode:
Command
Step 1 Step 2
csg2(config)# ip csg policy policy-name
Purpose Defines a policy for qualifying flows for the CSG2 billing services, and enters CSG2 policy configuration mode. Associates a global class map with a CSG2 policy. You can associate each CSG2 policy with one and only one class map.
csg2(config-csg-policy)# class-map class-map-name
2-36
OL-22840-05
Chapter 2
The following example associates class map CLASS with policy POLICY:
ip csg policy POLICY class-map CLASS
Note
You can either configure maps (that is, attribute, header, method, or URL maps) on a given policy, or you can associate the policy with a class map; you cannot do both. If you do, the CSG2 ignores the configured maps. After you associate the global class map with a policy, you must associate the policy with a content. To associate a policy with a content, enter the following commands beginning in global configuration mode:
Command
Step 1 Step 2
csg2(config)# ip csg content content-name
Purpose Configures content for CSG2 services, and enters CSG2 content configuration mode. Defines the maximum number of Layer 7 bytes that the CSG2 is to parse when attempting to assign a policy. NBAR uses this command to determine how many bytes of a given session to parse when attempting to identify the sessions protocol. If the length is exceeded, NBAR could not identify the protocol, and the CSG2 might not assign a protocol to the session. For instant messaging (IM) protocols, we recommend that you configure a parse length greater than 10,000.
csg2(config-csg-content)# parse length number
Step 3
csg2(config-csg-content)# parse protocol nbar
Defines how the CSG2 is to parse traffic for a content. The nbar keyword indicates that the traffic is to be parsed by the CSG2 NBAR protocol handler.
Step 4
csg2(config-csg-content)# ip any
Enables the CSG2 to process all Layer 3 and Layer 4 flows. We recommend that all content that is configured for NBAR processing also be configured to match all traffic, using the ip any command.
Step 5
csg2(config-csg-content)# policy policy-name [priority priority-number]
Associates a CSG2 billing policy with a content.
The following example associates policy POLICY with content CONTENT:

ip csg content CONTENT parse length 5000 parse protocol nbar ip any policy POLICY
To display information about the subscriber sessions that were classified by NBAR, enter the following command in privileged EXEC mode: Command
csg2# show ip csg sessions user nbar
Purpose Displays information about subscriber sessions that were classified by NBAR.
2-37
Configuring 8-Byte TLVs

Some 4-byte CSG2 TLVs might wrap when using a High-Speed Downlink Packet Access (HSDPA) connection. To prevent the TLVs from wrapping, you can configure the CSG2 to send 8-byte TLVs instead of 4-byte TLVs. Table 2-1 shows the new TLVs that have 8-byte fields.
Table 2-1 TLVs with 8-Byte Fields
Existing TLVs with 4-Byte Fields CSG_IPSTATS (0x03) CSG_TCP_STATS (0x05) CSG_SVC_IP_BYTE_USAGE (0x41) CSG_SVC_TCP_BYTE_USAGE (0x46) CSG_REFUND (0x27) CSG_WAP_IP_STATS (0x23)
New TLVs with 8-Byte Fields CSG_8BYTE_IPSTATS (0x64) CSG_8BYTE _TCP_STATS (0x65) CSG_8BYTE _SVC_IP_BYTE_USAGE (0x66) CSG_8BYTE _SVC_TCP_BYTE_USAGE (0x67) CSG_8BYTE _REFUND (0x68) CSG_8BYTE_WAP_IP_STATS (0x69)
The following CDRs use the new 8-byte TLVs:

FTP HTTP Statistics/HTTP Statistics Intermediate IP/IP Intermediate NBAR Stats/Interm NBAR Stats POP3 Service Usage - variable format Single Variable HTTP SIP Call/Interm SIP Call SIP Event/Interm SIP Event SMTP TCP/TCP Intermediate UDP/UDP Intermediate
To enable the CSG2 to send 8-byte TLVs, enter the following command in global configuration mode: Command
csg2(config)# ip csg report 8bytetlv
Purpose Enables the CSG2 to send 8-byte TLVs instead of 4-byte TLVs
Configuring HTTP Header Reporting

The CSG2 allows you to include multiple HTTP request headers in the CSG2 HTTP_Header CDR.
2-38
OL-22840-05
Chapter 2
To define HTTP reporting on the CSG2, enter the following command in global configuration mode: Command
csg2(config)# ip csg report http header x-header
Purpose Defines the inclusion of multiple HTTP request headers in the CSG2 HTTP_Header CDR.
Configuring SMTP CDR Header Removal

An SMTP CDR can be very large, as it includes a report attribute for each SMTP header embedded at the beginning of a message. The CSG2 enables you to eliminate these headers from an SMTP CDR, leaving only the SMTP envelope headers and the size attribute in the report. These are reported as X-CSG-MAIL, X-CSG-RCPT and X-CSG-SIZE. You can enable the CSG2 to remove SMTP CDR headers. When SMTP CDR header removal is enabled, the CSG2 reports the following header information to the BMA:

X-CSG-MAIL X-CSG-RCPT X-CSG-SIZE
When SMTP CDR header removal is disabled, the CSG2 reports the following header information to the BMA:

X-CSG-MAIL X-CSG-RCPT X-CSG-SIZE X-Priority1 X-MSMail-Priority1 X-Mailer1 X-MimeOLE1
To disable SMTP CDR header removal, including RFC 2822 header TLVs in SMTP CDRs, enter the following command in global configuration mode: Command
csg2(config)# ip csg report smtp rfc2822
Purpose Specifies that the CSG2 is to include RFC 2822 header TLVs in SMTP CDRs. To enable SMTP CDR header removal, use the no form of this command.e
1. Presence of this header depends on the contents of the SMTP header.
2-39
Configuring Supplemental Usage Reporting

You can configure the CSG2 to report supplemental usage to the quota server when sending a Service Stop, Quota Return, or Service Reauthorization Request message. The supplemental usage data reports the uploaded bytes, downloaded bytes, usage time in seconds, and time stamps for the first and last billable sessions. Reports contain statistics since the last report. The supplemental usage is included in the Service Stop Notification (0x0011) and in the Quota Return Notification (0x0009). If a tariff switch timeout occurs during the interval, the CSG2 sends the tariff switch TLVs along with the supplemental usage TLVs. The supplemental usage TLVs cover the data from the tariff switch time to the end of the interval. Supplemental usage reporting always reports IP bytes, even if the billing basis is configured for TCP bytes. To enable supplemental usage reporting on the CSG2, enter the following command in global configuration mode: Command
csg2(config)# ip csg report usage {bytes ip | seconds}
Purpose Enables CSG2 supplemental usage reporting to the quota server. If you want to report both IP bytes and usage in seconds, you can specify both ip csg report usage bytes ip and ip csg report usage seconds.
Configuring Actual PDU Reporting for WAP

The CSG2 can report actual protocol data units (PDUs) in wireless application protocol (WAP) CDRs. To report actual PDUs, enter the following command in global configuration mode: Command
csg2(config)# ip csg report wap actual-pdu
Purpose Specifies whether actual PDUs are to be reported in CSG2 WAP CDRs.
Configuring CDR Suppression for Unestablished TCP Connections

If a BMA receives too many CDRs simultaneously, it can become overloaded. If this occurs, many of the TCP sessions might be unable to complete the initial handshake, and each of those failed TCP sessions generates a CDR. To prevent this flood of CDRs from occurring, you can prevent the CSG2 from generating these CDRs. To prevent the CSG2 from generating CDRs when a TCP session has not set up completely and no data has been exchanged, enter the following command in global configuration mode: Command
csg2(config)# ip csg report tcp estab
Purpose Prevents the CSG2 from generating CDRs when a TCP session has not set up completely and no data has been exchanged.
To enable the CSG2 to generate these CDRs, enter the no form of the command in global configuration mode:
2-40
OL-22840-05
Chapter 2
Command
csg2(config)# no ip csg report tcp estab
Purpose Enables the CSG2 to generate CDRs when a TCP session has not set up completely and no data has been exchanged. This is the default setting.
Configuring Conditional CDR Blocking

The CSG2 can selectively block the generation of the following types of CDRs:
Transaction-level and service-level CDRs of prepaid users By definition, the CSG2 cannot associate a pre-policy transaction with a policy, and thus cannot determine whether the transaction as prepaid. Therefore, even if you have configured the ip csg report block prepaid command, the CSG2 does not block the sending of pre-policy transaction-level CDRs of prepaid users.
Pre-policy transaction-level CDRs A pre-policy transaction is one that cannot be associated with a policy. A pre-policy transaction is one that meets one of the following criteria:
The TCP handshake does not complete. The TCP handshake completes but is not followed by a request. The HTTP post is issued but does not contain the full URL; the rest of the URL is never
received.
Transaction-level CDRs. of unknown users.
The CSG2 does not support the preloading of conditional CDR blocking. To enable conditional CDR blocking, enter the following command in global configuration mode: Command
csg2(config)# ip csg report block {prepaid | transaction [pre-policy | user unknown]}
Purpose Prevents the CSG2 from sending CDRs to BMAs.
Configuring Content Name Reporting

The CSG2 allows you to include content names in variable-format CDRs. To enable the CSG2 to report content names, enter the following command in global configuration mode: Command
csg2(config)# ip csg report content
Purpose Enables the CSG2 to report content names in variable-format CDRs.
Configuring Policy Name Reporting

The CSG2 allows you to include policy names in variable-format CDRs. To enable the CSG2 to report policy names, enter the following command in global configuration mode:
2-41
Command
csg2(config)# ip csg report policy
Purpose Enables the CSG2 to report policy names in variable-format CDRs.
Configuring Flexible TCP Packet Counting

By default, the CSG2 includes IP bytes and packets for retransmitted TCP segments when counting IP bytes. However, you can prevent the CSG2 from including those IP bytes and packets. To include IP bytes and packets in IP byte counts, enter the following command in global configuration mode: Command
csg2(config)# ip csg count retransmit ip
Purpose Enables the CSG2 to include IP bytes and packets for retransmitted TCP segments when counting IP bytes. This is the default setting. To exclude IP bytes and packets from IP byte counts, enter the following command in global configuration mode:
Command
csg2(config)# no ip csg count retransmit ip
Purpose Prevents the CSG2 from including IP bytes and packets for retransmitted TCP segments when counting IP bytes.
When the no ip csg count retransmit ip command is configured, the CSG2 places the following restrictions on IP byte counting:

The CSG2 does not count IP bytes for retransmitted TCP payload bytes. The CSG2 does not count IP or TCP header bytes if all of the TCP payload bytes in a packet are retransmitted bytes. However, if any of the TCP payload bytes are not retransmitted bytes (that is, they are new bytes), then the CSG2 counts the IP and TCP header bytes and any new TCP payload bytes. If the packet is fragmented, the CSG2 counts the IP header bytes of each fragment. The CSG2 does not count a packet if all of the TCP payload bytes in the packet are retransmitted. However, if any of the TCP payload bytes are not retransmitted bytes (that is, they are new bytes), then the CSG2 counts the packet. If the packet is fragmented, the CSG2 counts the IP header bytes of each fragment. The CSG2 does not count the header bytes or the packet if the packet has SYN or FIN flags set, contains no TCP payload, and the TCP sequence number is a retransmit. However, the CSG2 does count the header bytes and the packet if the packet is an ACK that contains no TCP payload, regardless of the TCP sequence number.
2-42
OL-22840-05
Chapter 2
Configuring Maps for Pattern-Matching

The CSG2 maps are used to match attributes, headers, methods, or URLs against a pattern, to determine whether flows will be processed by the CSG2 accounting services. To define the CSG2 billing content filter maps, follow these steps: Command
Step 1 Step 2
csg2(config)# ip csg map map-name
Purpose Defines the CSG2 billing content filters (attribute, header, method, and URL maps), and enters CSG2 map configuration mode. (Optional) Specifies a Layer 7 protocol header attribute match pattern for a CSG2 billing map.
Note
csg2(config-csg-map)# match attribute {host | field-name} value
The match attribute command supports only HTTP and Session Initiation Protocol (SIP).
Step 3 Step 4 Step 5
csg2(config-csg-map)# match header header-name value csg2(config-csg-map)# match method method-name csg2(config-csg-map)# match url pattern
(Optional) Specifies a header match pattern for a CSG2 billing map. (Optional) Specifies a method match pattern for a CSG2 billing map. (Optional) Specifies a URL match pattern for a CSG2 billing map.
The following example shows how to configure an attribute map, header map, method map, and URL map in the same content:
ip csg map attributes match attribute host www.newshostprovider.com ! ip csg map headers match header Content-Type text*html ! ip csg map methods match method GET ! ip csg map urls match url www.news-site.com* ! ip csg policy news map attributes map headers map methods map urls ! ip csg content news ip any 80 parse protocol http policy news inservice
As CSG2 maps become more complex, your CSG2 configuration might require more memory when compiling regular expression (regex) engines. The default CSG2 regex memory is 100 MB, but the CSG2 enables you to increase the size.
2-43
To specify the size of the CSG2 regex memory, enter the following command in global configuration mode: Command
csg2(config)# ip csg regex memory memory
Purpose (Optional) Specifies the size of the CSG2 regex memory.
The CSG2 uses URL map normalization to determine whether two URLs with different syntaxes are equivalent. The CSG2 does this by modifying the supplied URLs, removing the dot-segments . and . . prior to running the URLs through the regex engine. However, there might be situations in which you do not want the CSG2 to normalize URLs. In such cases, you can disable URL map normalization, enabling the CSG2 to search explicitly for the dot-segments in URL map search strings. By default, URL map normalization is enabled for all CSG2 contents. To disable URL map normalization for a content, enter the following command in CSG2 content configuration mode:
csg2(config-csg-content)# no normalize-url
(Optional) Disables URL map normalization for a CSG2 content.
For more information, including how to specify match patterns and how the CSG2 matches those patterns, see the descriptions of the map (CSG2 policy), match attribute (CSG2 map), match header (CSG2 map), match method (CSG2 map), and match url (CSG2 map) commands.
Configuring Connection Redundancy

Connection redundancy prevents open connections from becoming unresponsive when the active CSG2 fails and the standby CSG2 becomes active. With connection redundancy, the active CSG2 replicates forwarding information to the standby CSG2 for each connection that is to remain open when the active CSG2 fails over to the standby CSG2. To enable connection redundancy, enter the replicate command in CSG2 content configuration mode.
Configuring High Availability

The CSG1 fault-tolerant feature has been replaced with the CSG2 high availability (HA) feature. The HA component of the CSG2 provides both stateless and stateful redundancy.

Stateless HA coordinates traffic delivery to the active system via the redundancy facility (RF) and Hot Standby Routing Protocol (HSRP), through the RF for Interdevice redundancy (RF Interdev). Stateful HA provides a state messaging conduit for other CSG2 software components by providing a state encapsulation and delivery service. When CSG2s are load-balanced, you must configure the standby use-bia command in interface configuration mode. Doing so ensures that the MAC address of the active CSG2 device changes (from the firewall load-balancing devices perspective) when a switchover occurs. HA does not support the use of the standby preempt command in interface configuration mode.
For high availability (HA), keep the following considerations in mind:
2-44
OL-22840-05
Chapter 2
When an active CSG2 fails over to a standby CSG2, the standby CSG2 sets its initial TCP sequence number based on the first packet it receives on the TCP session. The former standby CSG2now the active CSG2 counts only the IP bytes for TCP packets, with the sequence number inside the initial sequence number plus 64 KB. This is true for packets from the subscriber and for packets from the network. Components That Provide HA, page 2-45 Enabling HA, page 2-46 Configuring a Secondary IP Address for HA, page 2-46 Synchronizing Clocks for HA, page 2-46 Modifying an HA Configuration, page 2-47 Distributed Crash Data Collection, page 2-47 Configuring HA for CSG2s in Different Chassis, page 2-48 Configuring the CSG2 for HA Peer Connectivity, page 2-48
This section contains the following information:

Components That Provide HA

Table 2-2 lists the components that interact to provide CSG2 HA.
Table 2-2 Components That Provide HA
Component Redundancy Facility (RF) RF for Interdevice redundancy (RF Interdev)
Description IOS redundancy facility used to coordinate active and standby HA systems and their state progressions. Software layer that listens for HSRP updates regarding the status of a named HSRP group, and drives the RF state machines with updates when HSRP moves through key state transitions. Layer 3 virtualization protocol that presents adjacent devices with a virtual IP and a virtual MAC address, with the active role coordinated between the devices via priorities and elections. Reliable communications protocol used by RF Interdev for messaging between systems. Classifies ingress packets for delivery to the correct Cisco SAMI processor, and directs CSG2 HA stateful messages to the six TPs based on the destination port of the inbound messages. Classifies incoming packets, invokes a protocol handler based on classification, and delivers CSG2 HA UDP packets, arriving for local replication of the IP address and port, to the HA packet handler routine for processing. RF client that listens for state transition signals and instructions to bulk_sync (dump the CSG2 state table to the remote system). Handles the dump process on the CSG2 and maps incoming messages to the correct receiver routine in other CSG2 HA-aware components. CSG2 software that sends or receives HA messages through the CSG2 HA component.
Hot Standby Routing Protocol (HSRP)
Stream Control Transmission Protocol (SCTP) CSG2 Internet Exchange Point (IXP)
CSG2 Demultiplexor
CSG2 HARF Interface CSG2 HAMessaging CSG2 HAHA-Aware Components
2-45
Enabling HA
The CSG2 uses two separate commands to enable replication. Using separate commands allows for the synchronization of subscriber and quota states independent of per-flow synchronization. To enable replication of session and flows, use the replicate command in CSG2 content configuration mode. For more information, see the Configuring Content section on page 2-16 To enable HA state replication between redundant CSG2 systems, enter the following command in global configuration mode: Command
csg2(config)# ip csg replicate [vrf vrf-name] local-ip remote-ip base-port
Purpose Enables HA state replication between redundant CSG2 systems.

Note
Configuring a Secondary IP Address for HA

In some configurations, you might want the CSG2 to answer ARPs for CSG2 RADIUS endpoint and proxy IP addresses. To achieve this behavior, you must configure a secondary IP address on the appropriate interface, to facilitate the Layer 2 presence of the IP address on connected VLAN segments.
In redundant configurations, you must configure the secondary IP address as a standby secondary IP address in interface configuration mode. For example, any configuration that uses RADIUS load balancing to distribute traffic across multiple CSG2s, with the CSG2s acting as redundant devices, must use this approach. Note that the RADIUS load balancing real servers must be Layer 2-adjacent to the RADIUS load-balancing device.
interface GigabitEthernet0/0.107 encapsulation dot1Q 107 ip address 10.10.107.22 255.255.255.0 standby 0 ip 10.10.107.111 standby 0 ip 10.10.107.112 secondary ! ip csg radius endpoint 10.10.107.112 key cisco
In non-redundant configurations, you must configure the secondary IP address as a secondary IP address in interface configuration mode.
interface GigabitEthernet0/0.107 encapsulation dot1Q 107 ip address 10.10.107.22 255.255.255.0 ip address 10.10.107.22 255.255.255.0 secondary ! ip csg radius endpoint 10.10.107.112 key cisco
Synchronizing Clocks for HA

HA requires the clocks in your active and standby CSG2s to be synchronized with the clocks in any associated Supervisor Engines, to ensure correct billing. If your active and standby CSG2s are not installed in the same Cisco 7600 series router chassis, you must also synchronize the clocks in the associated Supervisor Engines with each other.
2-46
OL-22840-05
Chapter 2
To synchronize the CSG2 clocks, configure the Cisco Network Time Protocol (NTP) on each Cisco SAMI, as described in the Configuring NTP procedure in the Service and Application Module for IP User Guide. To determine whether the clocks are synchronized, enter the show clock command on each active Supervisor Engine and on each Cisco SAMI, and ensure that the timestamps are identical. To display the clock timestamps for all of the Cisco SAMIs in a given chassis, enter the execute-on all-samis command in privileged EXEC mode.
Note
The CSG2 reports all times in Coordinated Universal Time (UTC), regardless of the setting of the clock timezone or clock summer-time command in privileged EXEC mode.
Modifying an HA Configuration
To ensure stability, RF Interdev forces a system reload if an active system transitions to a standby state, or if communication between an active system and a standby system is interrupted. Both of these conditions can occur when you modify the ipc zone default or standby configurations for a CSG2 HA configuration. To avoid forced reloads, use the following procedure when modifying any aspect of a CSG2 HA configuration (such as ipc, standby, or replicate).
Step 1
Remove the standby scheme configured in inter-device configuration mode:

csg2(config)# redundancy inter-device csg2(config-red-interdevice)# no scheme standby SB
Step 2
Save the configuration changes to memory:

Step 3
Reload the CSG2:

Router# reload
Modify the CSG2 configuration. Reconfigure the standby scheme configured in inter-device configuration mode, if necessary. Save the configuration changes to memory again:
Step 7
Reload the CSG2 again:

Router# reload
Distributed Crash Data Collection

The CSG2 uses a control processor (CP) and multiple traffic processors (TPs), operating in parallel. If one of the processors fails, it can be useful to have crash data from all of the processors, not just the failed one. To that end, distributed crash data collection enables the CP and each TP to generate the following crash data:
Crash information from the failed processor
2-47
Debugging information from all of the non-failed processors designator_processornumber_timestamp
The processors use the following format when creating the crash and debugging information files: where:

designator indicates whether the file contains crash information (crashinfo) or debugging information (debuginfo) processornumber is the CP or TP number timestamp is the date and time when the file was created
For example, crashinfo_proc4_20080603-171440 is a crash information file for TP 4 that was created on June 3, 2008, at 5:14:40PM. The CSG2s Line Card Processor (LCP) collects each TPs crash and debugging information files and combines the files into a single .tar file, stored on the LCP in the core: file system: lcp# dir core: 1048576 Jul 11 16:18:40 2008 crashinfo 1075200 May 3 00:19:05 2008 crashinfo_collection-20080503-001844.tar You can read the .tar file from the Supervisor Engine. For example, for slot 2: cat# dir sami#2-fs:core/ Directory of sami#2-fs:core/ 12 ---- 1048576 Jul 11 2008 16:18:40 +00:00 crashinfo 22 ---- 1075200 May 3 2008 00:19:05 +00:00 crashinfo_collection-20080503-001844.tar There are no commands required to enable distributed crash data collection.
Note
Do not configure the exception crashinfo file command in global configuration mode. Doing so can break the file-naming convention and corrupt the crash and debugging information files.
Configuring HA for CSG2s in Different Chassis

If the CSG2s are in different chassis, we recommend that you configure the Supervisor Engines as peers of each other, in addition to configuring them as clients of the same NTP servers. This peer configuration ensures that, if one of the Supervisor Engines loses connectivity to its servers, it can obtain time synchronization information for the peer Supervisor Engine.
Configuring the CSG2 for HA Peer Connectivity

When configuring the CSG2 for HA peer connectivity, keep the following considerations in mind:

The VLAN used by the CSG2 for HA must be used only for CSG2 HA, and nothing else. Each CSG2 in the chassis requires at least a Gigabit of bandwidth for HA operations; we strongly recommend two Gigabits of bandwidth for redundancy. If both the active CSG2 and the standby CSG2 are in the same chassis, then the chassis itself provides the redundancy. However, your CSG2s are then susceptible to the Supervisor Engine or the chassis itself becoming a single point of failure.
2-48
OL-22840-05
Chapter 2
The HA VLAN must be physically redundant, such as a port-channel using at least two different physical ports on at least two different line cards. The port-channel must be able to experience the complete loss of any physical component (card, port, or cable) and still provide sufficient bandwidth for HA. This bandwidth must be reserved for HA via a physical separation or via QoS separation from any other traffic (including CSG2 bearer traffic).
Classifying Data Traffic

The CSG2 enables you to classify data traffic on the basis of its access path, using the Network Access Server (NAS) IP address reported in the RADIUS Accounting Start message. Transport-type information is reported in fixed record format CDRs. To classify data traffic on the basis of its access path, enter the following command in global configuration mode: Command
csg2(config)# ip csg transport-type assign ipv4-address value
Purpose Classifies data traffic on the basis of its access path.
Configuring a CSG2 Subscriber Interface

To configure a subscriber interface as a CSG2 subscriber interface, enter the following command in interface configuration mode: Command
Router# ip csg subscriber
Purpose Defines a subscriber interface as a CSG2 subscriber interface.

Note
All traffic routed through the CSG2, including peer-to-peer traffic, must flow from a subscriber interface to a network interface, or from a network interface to a subscriber interface. Therefore, configure the ip csg subscriber command on only the subscriber interface, never on the network interface.
Configuring Case Sensitivity

By default, CSG2 attribute, header, method, and URL match patterns are case-sensitive. To explicitly configure the CSG2 to treat match patterns as case-sensitive, enter the following command in global configuration mode: Command
Router# ip csg case-sensitive
Purpose Specifies whether the CSG2 is to treat attribute, header, method, and URL match patterns as case-sensitive.
2-49
To disable case-sensitivity for CSG2 match patterns, enter the following command in global configuration mode: Command
Router# no ip csg case-sensitive
Purpose Specifies that the CSG2 is to treat attribute, header, method, and URL match patterns as not case-sensitive.
Configuring WAP and WSP Support

The CSG2 can intercept wireless application protocol (WAP) traffic and generate reports that include contextual WAP information and counts of the bytes transferred. This feature supports both prepaid and postpaid billing. This section provides the following information:

Counting Bytes and Packets, page 2-50 Incomplete WAP Transactions, page 2-50 Multimedia Messaging Service, page 2-50
Counting Bytes and Packets

The CSG2 reports WAP datagram sizes (including IP and UDP headers), the number of IP packets per transaction, and PDU counts. (The PDU count is not the same as the packet count. Multiple WAP PDUs can share a single packet.) Bytes for retransmitted WAP PDUs and segments are counted and listed separately from non-retransmitted counts in the billing reports. Byte and PDU counts are further specified by source. Reports include the number of bytes and PDUs uploaded from source to destination and the number of bytes downloaded from destination to source.
Incomplete WAP Transactions

When the internal session representing a WAP flow for the CSG2 expires (because of inactivity or receipt of a WAP DISCONNECT packet), any outstanding elements in the WAP transaction queue are reported. These outstanding elements are transactions that were not completed. Examples include a GET request for which a full REPLY was not received, and a segmented POST or PUSH that was incomplete (missing a segment). In such cases, the incomplete flag is set on the Wireless Transaction Protocol (WTP) Info Tag-Length-Value (TLV) in the WAP statistics record. The record reports the Wireless Session Protocol (WSP) PDU type, WTP transaction class, WTP transaction ID, and the number of IP bytes transferred during the attempted transaction.
Multimedia Messaging Service

The CSG2 differentiates Multimedia Messaging Service (MMS) traffic running over WAP from other WAP traffic by inspecting the Wireless Session Protocol (WSP) Content Type. If MMS prepaid charging is disabled, all MMS traffic flows even when non-MMS, WAP traffic is blocked because of insufficient quota. Postpaid reports for MMS are generated as for all WAP traffic. Typically, several WAP packets are exchanged during a transaction before the WSP Content Type can be identified. When prepaid WAP with free MMS is configured, some packets still flow (even if a subscriber has insufficient quota) in order to identify the WSP Content Type. But the transaction does not complete, and the subscriber does not receive content if he or she has insufficient quota for a non-MMS, WAP request.
2-50
OL-22840-05
Chapter 2
It is not always possible to determine the WSP Content Type for incomplete transactions. In these instances, no quota is deducted for prepaid subscribers.
Blocking Ports
RTSP RealPlayer subscribers ignore the explicit definition of port 554 in the URL, and attempt to connect to ports 554, 7070, 80, and 8080. Many other streaming media servers also listen on ports 7070, 80, and 8080. For HTTP transport, if the media streams from any port other than port 554 (such as port 7070, 80, or 8080), the CSG2 does not bill the stream as RTSP. Therefore, for RTSP billing, you must block TCP and HTTP connections to the server network on ports 7070, 80, and 8080. To block a port, you must configure a content that matches the connection to the server network and sends transactions to a false next-hop IP address, as shown in the following example:
ip csg content BLOCK7070 ip 1.1.1.0 255.255.255.0 tcp next-hop 10.10.10.1 policy RTSP-BLOCK inservice ! ip csg content BLOCK80 ip 1.1.1.0 255.255.255.0 tcp next-hop 10.10.10.1 policy RTSP-BLOCK inservice ! ip csg content BLOCK8080 ip 1.1.1.0 255.255.255.0 tcp next-hop 10.10.10.1 policy RTSP-BLOCK inservice ! ip csg content RTSPCONTSERVER ip 1.1.1.0 255.255.255.0 tcp idle 50 replicate policy RTSP inservice 7070
80
8080
554
Configuring SNMP Timers

The CSG2 enables you to configure SNMP timers for lost CSG2 records. To configure an SNMP timer and to enter CSG2 SNMP timer configuration mode, enter the following command in global configuration mode: Command
csg2(config)# ip csg snmp timer {bma | psd | quota-server} [interval]
Purpose Defines Simple Network Management Protocol (SNMP) timers for lost CSG2 records.
2-51
Configuring the Interval for Protocol Transaction Statistics

The CSG2 can display rate statistics per protocol. The show ip csg stats protocol command displays the statistics count, rate, maximum rate, and maximum rate timestamp for the transaction, byte count, and packet count for each of the protocols that is configured on the CSG2. You can configure the interval, in seconds, that the CSG2 is to use when calculating the rates for this command. The displayed rate is the transaction count per second averaged over the specified interval: (T2-T1) / interval where:

T1 is the transaction count at the beginning of the configured interval. T2 is the transaction count at the end of the configured interval. interval is the configured interval.
To configure the rate interval for the CSG2, enter the following command in global configuration mode: Command
csg2(config)# ip csg statistics protocol interval interval
Purpose Defines the interval for protocol traffic statistics rate calculation for the CSG2.
Configuring the Cisco SAMI Bit Rate Limit

To specify the bit rate limit to be used by the Cisco Service and Application Module for IP (SAMI) for each PowerPCs (PPCs) traffic, enter the following command in global configuration mode: Command
csg2(config)# sami rate bits-per-second all
Purpose Specifies the bit rate limit to be used by the Cisco SAMI for each PPCs traffic.
Configuring the SNMP Notification Types

To enable Simple Network Management Protocol (SNMP) notification types that are available on the CSG2, enter the following command in global configuration mode: Command
csg2(config)# snmp-server enable traps csg [bma [records | state] | database | quota-server [records | state]]
Purpose Enables SNMP notification types that are available on the CSG2.
Configuring the Subscriber Threshold for License-Exceeded Notifications

You can enable the CSG2 to generate license-exceeded notifications (syslog messages and SNMP traps) if the number of concurrent subscribers accessing the network exceeds a configured subscriber threshold. The default subscriber threshold is 300,000.
2-52
OL-22840-05
Chapter 2
Only the active CSG2 generates license-exceeded notifications. To configure a subscriber threshold and enable license-exceeded notifications, enter the following command in global configuration mode: Command
csg2(config)# ip csg license warning-enable threshold
Purpose Sets a subscriber threshold for the CSG2 to generate license-exceeded notifications.
If the subscriber threshold is exceeded, the CSG2 generates a license-exceeded SNMP trap, and begins generating license-exceeded syslog messages. The CSG2 continues to generate license-exceeded syslog messages every five minutes, even if the number of concurrent subscribers accessing the network drops below the subscriber threshold, until one of the following actions occurs:

The subscriber threshold is changed, using the ip csg license warning-enable command (or disabled, using the no form of the command). The CSG2 is prevented from generating the syslog messages, using the clear ip csg license warning command in privileged EXEC mode.
Note
The clear ip csg license warning command stops the generation of syslog messages until the limit is exceeded again. Therefore, if the current CSG2 User Table size is greater than the current configured value, and you enter the clear ip csg license warning command, the CSG2 begins generating notifications again when the next User Table entry is created. The CSG2 is prevented from generating the syslog messages, using the no form of the ip csg license syslog enable command in global configuration mode. The CSG2 is prevented from generating the SNMP traps, using the no form of the snmp-server enable traps csg license warning-enable command in global configuration mode.
Note
Sticky entries in the CSG2 User Table are included in the count of concurrent subscribers. The CSG2 uses this command only to determine when and if to generate license-exceeded notifications. This command does not increase or decrease the actual number of concurrent subscribers allowed by the CSG2 license that you purchased. The SNMP licensing trap is enabled by default. For more information about how to configure system monitoring, logging, and SNMP support, see the Cisco IOS Network Management Configuration Guide.
Configuring Packet Logging and Reporting

Note
We recommend that you enable packet logging only when directed to do so by Cisco Technical Assistance Center (TAC) engineers.
2-53
We recommend that you configure packet filters, define the size of the packet buffer, and enable packet logging on the CP, not on the individual TPs. Configuring and enabling packet logging on the CP enables the CSG2 to log packets for all of the TPs. Sometimes it is necessary to examine events and interesting packets in order to diagnose and correct problems that occur in the network. The debug ip csg command is useful in many of these situations, but it can have an impact on CSG2 performance, and it is not always desirable to use this command in a production network. The CSG2 packet logging facility, also called the CSG2 event trace facility, enables you to log interesting packets with minimal impact on the network. When enabled, the CSG2 logs the packets to an internal memory buffer for later retrieval, as needed. Packet logging provides the following advantages over the debug ip csg command:

Packet logging is relatively light-weight, with little or no formatting required for logged packets. The packet buffer is specific to the application; using other debugging methods does not impact the buffer. You can configure packet logging to control what information is logged, and when. Packet logging is a silent facility with minimal impact on production networks. Trouble-Shooting a Problem Using Packet Logging, page 2-55 Configuring a Packet Filter, page 2-55 Defining the Size of the Packet Buffer, page 2-56 Enabling and Disabling Packet Logging, page 2-56 Displaying the Contents of the Packet Buffer, page 2-56 Setting Up Packet Logging for NBAR, page 2-57
This section includes the following information:

2-54
OL-22840-05
Chapter 2
Trouble-Shooting a Problem Using Packet Logging

To trouble-shoot a problem using packet logging, use the following procedure:
Step 1 Step 2
Detect a problem with a specific flow, such as packets being dropped. Identify the characteristics of the flow, such as the subscriber IP address and subnet, the associated protocol, the action that the CSG2 is taking on the packets (for example, dropping them), the Virtual Routing and Forwarding (VRF) table used for the flow, and so on. If necessary, configure access lists to match the subnet IP addresses of the flow. Configure a packet filter that matches the attributes of the flow, so that the CSG2 logs only those packets that are relevant to the detected problem. For more information, see the Configuring a Packet Filter section on page 2-55. Define the size of the packet buffer. For more information, see the Defining the Size of the Packet Buffer section on page 2-56. Enable packet logging. For more information, see the Enabling and Disabling Packet Logging section on page 2-56. When the CSG2 has logged enough packets, or when the packet buffer is full, disable packet logging. For more information, see the Enabling and Disabling Packet Logging section on page 2-56. Confirm that the CSG2 has logged packets that are relevant to the detected problem by displaying the contents of the packet buffer and identifying the relevant packets. For more information, see the Displaying the Contents of the Packet Buffer section on page 2-56. Provide the relevant packets and other information to the Cisco Technical Assistance Center (TAC).
Step 3 Step 4
Step 5 Step 6 Step 7 Step 8
Step 9
Configuring a Packet Filter

To configure a packet filter, enter one or more of the following commands in global configuration mode: Command
csg2(config)# ip csg event-trace packet match action {dropped | forwarded | queued} csg2(config)# ip csg event-trace packet match error {parse} csg2(config)# ip csg event-trace packet match ip {[global | vrf vrf-name] [subscriber subscriber-acl] [network network-acl]) csg2(config)# ip csg event-trace packet match protocol
Purpose Defines action-based filters for CSG2 packet logging. Defines error-based filters for CSG2 packet logging. Defines IP-based filters for CSG2 packet logging.
Note
Defines protocol-based filters for CSG2 packet logging. For the full list of protocol matching options, see the description of the ip csg event-trace packet match protocol command.
2-55
Defining the Size of the Packet Buffer

To define the size of the packet buffer, enter the following command in global configuration mode: Command
csg2(config)# ip csg event-trace packet entries number-of-entries
Purpose Changes the size of the CSG2 packet buffer.
Enabling and Disabling Packet Logging

By default, packet logging is disabled. To enable packet logging, enter the following command in global configuration mode: Command
csg2(config)# ip csg event-trace packet enable [no-wrap]
Purpose Enables the CSG2 to log packets. The no-wrap option instructs the CSG2 to clear the existing packet buffer and then log packets until the packet buffer is full. To disable packet logging, enter the following command in global configuration mode:
Command
csg2(config)# no ip csg event-trace packet enable
Purpose Disables CSG2 packet logging.
Displaying the Contents of the Packet Buffer

To display the contents of the packet buffer, enter the following command in privileged EXEC mode: Command
csg2# show ip csg event trace packet
Purpose Displays the contents of the CSG2 packet buffer for a specific traffic processor (TP), if entered on a TP; or for all of the TPs, if entered on the control processor (CP). For the full list of display options for packet logging, see the description of the show ip csg command.
2-56
OL-22840-05
Chapter 2
Setting Up Packet Logging for NBAR

The following example shows how to set up packet logging for NBAR content. In this sample configuration:

The parse protocol nbar command in content PEER-TO-PEER indicates that the CSG2 is to use the IOS NBAR feature to classify the packets that match that content. The parse length 5000 command in content PEER-TO-PEER indicates that the CSG2 is to parse no more than 5000 bytes per-session (regardless of direction) when attempting to identify the peer-to-peer protocol and assign a policy. The class-map P2P-CLASSIFICATION command in policy P2P-POLICY indicates that the policy is to be applied to those packets or sessions that are classified as one of the protocols listed in class map P2P-CLASSIFICATION. The match-any option in the class-map match-any P2P-CLASSIFICATION command indicates that both Gnutella packets and Skype packets are to be considered part of class P2P-CLASSIFICATION, and are therefore to be assigned to policy P2P-POLICY. The ip csg event-trace packet match protocol nbar gnutella command indicates that the CSG2 is to log all Gnutella packets in the packet buffer.
The pertinent configuration is as follows:

ip csg content PEER-TO-PEER ip any parse protocol nbar parse length 5000 policy P2P-POLICY ! ip csg policy P2P-POLICY accounting customer-string p2p-traffic class-map P2P-CLASSIFICATION ! ip csg service P2P-SERVICE content P2P policy P2P-POLICY ! class-map match-any P2P-CLASSIFICATION match protocol gnutella match protocol skype ! ip csg event-trace packet enable ip csg event-trace packet match protocol nbar gnutella
Note
If the CSG2 is configured to log packets that have been classified as a particular protocol by NBAR, it might also log some packets of other protocols. This can occur because it takes time for NBAR to identify the protocol for a packet, so the CSG2 logs all packets that hit the NBAR content, unless it can ascertain that a packet is definitely not of the desired protocol. For example, if the CSG2 is configured to log Gnutella packets (that is, the ip csg event-trace packet match protocol nbar gnutella command is configured), it might log a few non-Gnutella packets.
Changing the Order of Next-Hop IP Address Selection

In addition to content-configured next-hop IP addresses, the CSG2 supports per-user uplink next-hop IP addresses. You can specify per-user uplink next-hop IP addresses in the following messages:
2-57
Chapter 2 CSG2 Configuration Examples
A RADIUS Access-Accept messages A RADIUS Accounting-Start messages A Gx Attribute Value Pair (AVP) in a Credit Control Request (CCR) messages A Gx AVP in a Credit Control Answer (CCA) messages The next-hop subscriber media IP address, if configured The next-hop subscriber IP address, if configured The next-hop IP address. (if the subscriber initiated the connection) or the next-hop reverse IP address (if the subscriber did not initiate the connection), if configured The per-user uplink next-hop IP address, if specified The destination IP address of the user packet from the subscriber
When routing traffic, the CSG2 selects the next-hop IP address in the following order:
1. 2. 3. 4. 5.
However, if you want the CSG2 to give priority to per-user uplink next-hop IP addresses, you can enable the CSG2 to select the next-hop IP address in the following order:
1. 2. 3. 4. 5.
The per-user uplink next-hop IP address The next-hop subscriber media IP address The next-hop subscriber IP address The next-hop or next-hop reverse IP address The destination IP address of the user packet from the subscriber
To change the next-hop IP address selection order, enter the following command in CSG2 content configuration mode: Command
csg2(config-csg-content)# next-hop override
Purpose Changes the order in which the CSG2 selects the next-hop IP address.
CSG2 Configuration Examples

This section provides the following sample configurations for CSG2:

Sample Configuration for Subscriber-to-Subscriber Traffic, page 2-58 Sample Configuration for HTTP X-Forwarded-For, page 2-60 Sample Configuration for High Availability, page 2-61 Sample Configuration for HA Peer Connectivity, page 2-62 Sample Configuration for HTTP Header Insertion, page 2-66 Sample Configuration for IPv4- and IPv6-Aware VRF, page 2-68
Sample Configuration for Subscriber-to-Subscriber Traffic

The CSG2 handles the following scenarios for subscriber-to-subscriber traffic:
Subscriber-A and Subscriber-B are owned by the same CSG2, which is not a member of a CSG2 cluster.
2-58
OL-22840-05
Chapter 2
Configuring the CSG2 CSG2 Configuration Examples
Subscriber-A and Subscriber-B are owned by the same CSG2, which is a member of a CSG2 cluster. Subscriber-A and Subscriber-B are owned by different CSG2s, both of which are members of a CSG2 cluster. Subscriber-A and Subscriber-B are owned by different CSG2s, which are not members of the same CSG2 cluster. Subscriber-A is the initiator of the session. Subscriber-B refers to the receiver of the session. A CSG2 cluster is a group of CSG2s in the same load-balancing group. A subscriber is owned by a CSG2 if the CSG2 creates a User Table entry that corresponds to the subscribers IP address. If RADIUS endpoint or RADIUS proxy is configured, the CSG2 that owns the subscriber is the one that processes RADIUS Accounting Requests for the subscriber.
where:

In each scenario, the CSG2 generates consistent CDRs for both prepaid and postpaid charging:
The CSG2 charges each subscriber for the transaction, based on the billing plan and service associated with each subscriber. If the subscribers are prepaid, the CSG2 creates a separate service for each subscriber, and the quota server grants quota separately for each service. The CSG2 generates two sets of CDRs, one set for each subscriber, in accordance with the billing plan and service associated with each subscriber.
When configuring the CSG2 for subscriber-to-subscriber traffic, keep the following considerations in mind:

The CSG2 always performs a session lookup for each arriving data packet before matching content. Each subscriber-to-subscriber session is flagged with the subscriber IP address and network IP address.
For traffic arriving on the subscriber interface, the subscriber IP address is the source IP address
and the network IP address is the destination IP address.

For traffic arriving on the network interface, the subscriber IP address is the destination IP
address and the network IP address is the source IP address. This sample configuration includes the following information:

Configuring Next-Hop for a Subscriber-to-Subscriber Content, page 2-59 Configuring Prepaid Subscriber-to-Subscriber Contents for a Service, page 2-60
Configuring Next-Hop for a Subscriber-to-Subscriber Content

On each CSG2 that handles subscriber-to-subscriber traffic, you must configure subscriber-to-subscriber content using the next-hop command:
access-list 11 permit 11.0.0.0 0.255.255.255 ! ip csg content SUB-TO-SUB ip 11.0.0.0 255.0.0.0 any client-group 11 next-hop 10.5.1.100 subscriber policy ANY-MS inservice
2-59
When configuring the next-hop configuration, keep the following considerations in mind:

Configure the IP address of the Supervisor Engine in which the CSG2 is installed as the next-hop IP address for the CSG2, for subscriber-to-subscriber traffic. If you are using firewall load balancing, configure an IP address on the Supervisor Engine that is Layer 2-adjacent to the CSG2 as the next-hop IP address.
Configuring Prepaid Subscriber-to-Subscriber Contents for a Service

On each CSG2 that handles prepaid subscriber-to-subscriber traffic, you must configure a service that includes subscriber-to-subscriber contents:
ip csg service SUB-TO-SUB content SUB-TO-SUB policy ANY-MS
Sample Configuration for HTTP X-Forwarded-For

The following example shows how to configure the CSG2 to obtain the subscriber's IP address from the HTTP X-Forwarded-For header, including the configuration of single-TP mode:
ip csg mode single-tp ip csg map WEB match url *.(htm|asp|php) ip csg policy CATCHALL accounting ip csg policy WEB accounting map WEB ip csg content XF4 ip any tcp 80 subscriber-ip http x-forwarded-for policy WEB inservice
2-60
OL-22840-05
Chapter 2
Sample Configuration for High Availability

The following example shows how to configure the CSG2 for High Availability (HA).
Figure 2-1 Configuring the CSG2 for High Availability
VLAN: 20 Standby IP: 10.10.25.1
10.10.25.14 Active 10.10.24.14
10.10.25.13 Standby 10.10.24.13
HA Configuration on the Active CSG2

redundancy inter-device scheme standby SB ! ipc zone default association 1 no shutdown protocol sctp local-port 30001 local-ip 10.10.24.14 remote-port 30001 remote-ip 10.10.24.13 ! interface gig 0/0 ! interface gig 0/0.10 ip csg subscriber encaps dot1q 10 vlan 10 ip address 10.10.24.14 255.255.255.0 standby use-bia standby 5 ip 10.10.24.1 standby 5 ip 10.10.24.100 secondary standby 5 name SB ! interface gig 0/0.20 encaps dot1q 20 vlan 20 ip address 10.10.25.14 255.255.255.0 standby use-bia standby 5 ip 10.10.25.1 standby 5 follow SB ! ip csg replicate 10.10.24.14 10.10.14.13 2000 ip csg radius endpoint 10.10.24.100 key cisco
201838
VLAN: 10 Standby IP: 10.10.24.1 Standby Name: SB
2-61
HA Configuration on the Standby CSG2

redundancy inter-device scheme standby SB ! ipc zone default association 1 no shutdown protocol sctp local-port 30001 local-ip 10.10.24.13 remote-port 30001 remote-ip 10.10.24.14 ! interface gig 0/0 ! interface gig 0/0.10 ip csg subscriber encaps dot1q 10 ip address 10.10.24.13 255.255.255.0 standby use-bia standby 5 ip 10.10.24.1 standby 5 ip 10.10.24.100 secondary standby 5 priority 95 standby 5 name SB ! interface gig 0/0.20 encaps dot1q 20 ip address 10.10.25.13 255.255.255.0 standby use-bia standby 5 ip 10.10.25.1 standby 5 priority 95 standby 5 follow SB ! ip csg replicate 10.10.24.13 10.10.24.14 2000 ip csg radius endpoint 10.10.24.100 key Cisco
Sample Configuration for HA Peer Connectivity

When configuring the CSG2 for HA peer connectivity, keep the following considerations in mind:

The VLAN used by the CSG2 for HA must be used only for CSG2 HA, and nothing else. Each CSG2 in the chassis requires at least a Gigabit of bandwidth for HA operations; we strongly recommend two Gigabits of bandwidth for redundancy. If both the active CSG2 and the standby CSG2 are in the same chassis, then the chassis itself provides the redundancy. However, your CSG2s are then susceptible to the Supervisor Engine or the chassis itself becoming a single point of failure. The HA VLAN must be physically redundant, such as a port-channel using at least two different physical ports on at least two different line cards. The port-channel must be able to experience the complete loss of any physical component (card, port, or cable) and still provide sufficient bandwidth for HA. This bandwidth must be reserved for HA via a physical separation or via QoS separation from any other traffic (including CSG2 bearer traffic). Sample Configuration for Supervisor Engine Side 1, page 2-63 Sample Configuration for CSG2 Side 1, page 2-63 Sample Configuration for Supervisor Engine Side 2, page 2-64
This section includes the following information

2-62
OL-22840-05
Chapter 2
Sample Configuration for CSG2 Side 2, page 2-64 Displaying Port-Channel Information for One Side, page 2-65 Configuring CSG2 Network/Subscriber Traffic, page 2-66
Sample Configuration for Supervisor Engine Side 1

The pertinent configuration for Supervisor Engine side 1 is as follows:
svclc multiple-vlan-interfaces svclc module 4 vlan-group 4,5 svclc vlan-group 4 10,100,200 svclc vlan-group 5 500 ! interface GigabitEthernet1/47 description inter-chassis port channel switchport switchport access vlan 500 channel-group 1 mode on ! interface GigabitEthernet1/48 description inter-chassis port channel switchport switchport access vlan 500 channel-group 1 mode on
The port-channel interface is created as a result of joining channel-group 1 and can be verified using the following command:
csg_sup# show running interfaces port-channel 1 Current configuration : 109 bytes ! interface Port-channel1 switchport switchport access vlan 500 switchport trunk encapsulation dot1q end
Sample Configuration for CSG2 Side 1

The pertinent configuration for CSG2 side 1 is as follows:
redundancy inter-device scheme standby SB ! ipc zone default association 1 no shutdown protocol sctp local-port 30001 local-ip 192.168.5.6 remote-port 30001 remote-ip 192.168.5.5 ! interface GigabitEthernet0/0.500 encapsulation dot1Q 500 ip address 192.168.5.6 255.255.255.0 standby 0 ip 192.168.5.1 standby 0 name SB ! ip csg replicate 192.168.5.6 192.168.5.5 2000
2-63
Sample Configuration for Supervisor Engine Side 2

The pertinent configuration for Supervisor Engine side 2 is as follows:
svclc multiple-vlan-interfaces svclc module 4 vlan-group 4,5 svclc vlan-group 4 10,100,200 svclc vlan-group 5 500 ! interface GigabitEthernet1/47 description inter-chassis port channel switchport switchport access vlan 500 channel-group 2 mode on ! interface GigabitEthernet1/48 description inter-chassis port channel switchport switchport access vlan 500 channel-group 2 mode on
The port-channel interface is created as a result of joining channel-group 2 and can be verified using the following command:
csg_sup# show running interfaces port-channel 2 Current configuration : 109 bytes ! interface Port-channel2 switchport switchport access vlan 500 switchport trunk encapsulation dot1q end
Sample Configuration for CSG2 Side 2

The pertinent configuration for CSG2 side 2 is as follows:
redundancy inter-device scheme standby SB ! ipc zone default association 1 no shutdown protocol sctp local-port 30001 local-ip 192.168.5.5 remote-port 30001 remote-ip 192.168.5.6 ! interface GigabitEthernet0/0.500 encapsulation dot1Q 500 ip address 192.168.5.5 255.255.255.0 standby 0 ip 192.168.5.1 standby 0 name SB ! ip csg replicate 192.168.5.5 192.168.5.5 2000
2-64
OL-22840-05
Chapter 2
Displaying Port-Channel Information for One Side

Use the following commands to display the port-channel information for one side of the configuration:
csg_sup# show running interfaces port-channel 2 Building configuration... Current configuration : 109 bytes ! interface Port-channel2 switchport switchport access vlan 500 switchport trunk encapsulation dot1q end csg_sup# show interfaces port-channel 2 Port-channel2 is up, line protocol is up (connected) Hardware is EtherChannel, address is 001f.9ecb.2af6 (bia 001f.9ecb.2af6) MTU 1500 bytes, BW 2000000 Kbit, DLY 10 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s input flow-control is off, output flow-control is off Members in this channel: Gi1/47 Gi1/48 ARP type: ARPA, ARP Timeout 04:00:00 Last input never, output never, output hang never Last clearing of show interface counters 02:31:37 Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 2000 bits/sec, 4 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 2448 packets input, 178170 bytes, 0 no buffer Received 2425 broadcasts (2376 multicasts) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored 0 watchdog, 0 multicast, 0 pause input 0 input packets with dribble condition detected 117 packets output, 18805 bytes, 0 underruns 0 output errors, 0 collisions, 1 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 pause output 0 output buffer failures, 0 output buffers swapped out csg_sup# show interfaces gigabitEthernet 1/47 GigabitEthernet1/47 is up, line protocol is up (connected) Hardware is c7600 1Gb 802.3, address is 001f.9ecb.2af6 (bia 001f.9ecb.2af6) Description: inter-chassis port channel MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s input flow-control is off, output flow-control is off Clock mode is auto ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:43, output hang never Last clearing of show interface counters 02:32:31 Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 2000 bits/sec, 4 packets/sec
2-65
5 minute output rate 0 bits/sec, 0 packets/sec 7878 packets input, 594299 bytes, 0 no buffer Received 7798 broadcasts (7701 multicasts) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 8 frame, 0 overrun, 0 ignored 0 watchdog, 0 multicast, 0 pause input 0 input packets with dribble condition detected 8395 packets output, 640596 bytes, 0 underruns 0 output errors, 0 collisions, 4 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 pause output 0 output buffer failures, 0 output buffers swapped out csg_sup# show interfaces gigabitEthernet 1/48 GigabitEthernet1/48 is up, line protocol is up (connected) Hardware is c7600 1Gb 802.3, address is 001f.9ecb.2af7 (bia 001f.9ecb.2af7) Description: inter-chassis port channel MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 1000Mb/s input flow-control is off, output flow-control is off Clock mode is auto ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:49, output 00:00:44, output hang never Last clearing of show interface counters 02:32:54 Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 10771 packets input, 832887 bytes, 0 no buffer Received 10556 broadcasts (10438 multicasts) 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 16 frame, 0 overrun, 0 ignored 0 watchdog, 0 multicast, 0 pause input 0 input packets with dribble condition detected 12970 packets output, 990962 bytes, 0 underruns 0 output errors, 0 collisions, 4 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier, 0 pause output 0 output buffer failures, 0 output buffers swapped out
Configuring CSG2 Network/Subscriber Traffic

Inter-chassis network and subscriber traffic must have a similar setup, contained within a redundant inter-chassis connection (that is, a port-channel interface as shown above). This traffic, however, can share the bandwidth in the inter-chassis connection with other VLANS using trunks, as it does not need to be isolated as the CSG2 HA VLAN must be. However, you must ensure you have enough inter-chassis bandwidth to accommodate your anticipated maximum load for the shared port-channel.
Sample Configuration for HTTP Header Insertion

The commands that are used to configure header data are order-sensitive. Each data item is inserted into the HTTP header, concatenated, in the order in which it was configured. The headers that are defined for a header group are also order-sensitive. Each header in a header group is inserted into the HTTP header, concatenated, in the order in which it was configured.
2-66
OL-22840-05
Chapter 2
For example, given the following configuration:

ip csg header HDR-1 name X-HDR class abcd include string 1 Clear text encrypt begin string 2 My encrypted string encrypt end timestamp ! ip csg header HDR-2 name X-RAD-3GPP-22 class X-RAD-3GPP-22 include radius vsa 10415 22 ! ip csg header HDR-3 name X-QS-TLV class X-QS-TLV include quota-server ! ip csg header-group HG-1 header HDR-1 header HDR-2 header HDR-3 ! ip csg policy P_HOST accounting customer-string string1 insert header-group HG-1
The following sample configuration for HTTP header insertion has the following characteristics:

Header group HG-1 is defined for policy P-HOST. Header group HG-1 includes HDR-1, HDR-2, and HDR-3, in that order. Header HDR-1 is configured with name X-HDR and class abcd. The include keyword specifies that the CSG2 is to include the header when performing header insertion for a user who does not specify a class name for include in the user profile. The string Clear text is inserted first in the header as unencrypted data. The string My encrypted string is encrypted and inserted next. The timestamp is inserted next. Header HDR-2 is configured with name X-RAD-3GPP-22 and class X-RAD-3GPP-22. The include keyword is specified for HDR-2. RADIUS VSA subattribute 3GPP 22 (vendor ID 10415, VSA subattribute 22) is inserted in the header as unencrypted data, after the timestamp.
Header HDR-3 is configured with name X-QS-TLV and class X-QS-TLV. The include keyword is specified for HDR-3. Data from the Quota-Server TLV is inserted in the header as unencrypted data, after the RADIUS VSA subattribute.
2-67
Sample Configuration for IPv4- and IPv6-Aware VRF

The following configuration provides VRF support in an IPv4/IPv6 environment:
vrf definition MS-30 address-family ipv4 exit-address-family ! address-family ipv6 exit-address-family ! interface GigabitEthernet0/0.2001 description CSG2 MS 3.0 subscriber vrf forwarding MS-30 encapsulation dot1Q 2001 ip csg subscriber ip address 10.20.1.72 255.255.255.0 ipv6 address 2001:0:0:2001: :97/64 ipv6 enable standby version 2 standby 1100 ipv6 autoconfig standby 1100 follow CSG2-HA standby 2001 ip 10.20.1.92 standby 2001 ip 10.20.1.171 secondary standby 2001 follow CSG2-HA ! ip route vrf MS-30 12.1.0.0 255.255.0.0 10.20.1.62 ipv6 route vrf MS-30 2001:1:1: :/48 GigabitEthernet0/0.2001 FE80: :5:73FF:FEA0:44 ! ip csg radius proxy vrf MS-30 10.20.1.171 10.0.220.112 10.0.220.174 key test vrf MS-30 ip csg radius endpoint vrf MS-30 10.29.2.175 key test vrf MS-30 ip csg radius pod nas vrf MS-30 1700 key test ip csg radius coa nas vrf MS-30 3799 key test ! ip csg policy POL-ANY-MS accounting ! ip csg content ANY-MS ip any vrf MS-30 policy POL-ANY-MS inservice
2-68
OL-22840-05
CH A P T E R
Configuring BMA Support

The CSG2 monitors data flows and generates accounting records that can be used to bill customers at a content level. The CSG2 sends the accounting records to a Billing Mediation Agent (BMA), which formats the records as required by the customers billing system. At the end of each transaction, a billing record indicating the content accessed and the amount deducted is sent to the BMA, so that it can be logged in the subscriber's bill. The CSG2 provides the following features for the BMA:

Configuring the BMA Local Port, page 3-1 Configuring a BMA, page 3-2 Configuring the BMA Keepalive Time, page 3-2 Configuring the BMA GTP Message Buffer, page 3-3 Configuring the BMA Retransmit Time, page 3-3 Configuring the BMA Retry Number, page 3-4 Configuring the BMA Window Size, page 3-4 Configuring BMA Load Sharing, page 3-5 Reporting the Billing Plan ID to the BMA, page 3-5
Configuring the BMA Local Port

The first step when configuring CSG2 support for the BMA is to configure the local port on which the CSG2 is to communicate with the BMA. To activate one or more BMAs, you must configure a local port, the local port on which the CSG2 is to communicate with the BMA. The local port must be unique with respect to all other configured local ports, such as the quota server local port. The CSG2 allows you to configure a port number that is not the general packet radio service (GPRS) tunneling protocol (GTP) prime (GTP) default port (3386).
3-1
Chapter 3 Configuring a BMA
To configure a local port for the BMA, enter the following command in global configuration mode: Command
csg2(config)# ip csg bma local-port port-number
Purpose Configures the local port on which the CSG2 communicates with the BMA. The BMA local port number must be different from the PSD local port number and from the quota server local port number (configured with the ip csg psd local-port command and the ip csg quota-server local-port command, respectively).
Configuring a BMA
You must configure the BMA to which you want the CSG2 to send accounting records. You can configure only one BMA. Accounting records are sent only to the configured BMA. This provides a measure of security to ensure that records are not sent to unauthorized systems. When you configure a BMA, make sure that its IP address and port number match on both the active CSG2 and the standby CSG2. The CSG2 differentiates BMAs on the basis of their IP addresses and port numbers. You can configure multiple BMAs with the same IP address, but the CSG2 does not support nodealive or redirect for multiple BMAs with the same IP address. If you have enabled interface awareness, you can also associate a VLANs Virtual Routing and Forwarding (VRF) table name with the BMA. To configure a BMA, enter the following command in global configuration mode: Command
csg2(config)# ip csg bma [vrf vrf-name] ipv4-address port-number priority
Purpose Configures the BMA to which the CSG2 is to send billing records.
Note
Configuring the BMA Keepalive Time

By default, the CSG2 sends keepalive messages to the BMA once every 60 seconds. That setting is sufficient in most environments, but the CSG2 also allows you to change the time between keepalive messages, if necessary.
Note
We recommend that you change the keepalive time interval only when directed to do so by Cisco Technical Assistance Center (TAC) engineers. In most environments, the default value is the most appropriate setting.
3-2
OL-22840-05
Chapter 3
Configuring BMA Support Configuring the BMA GTP Message Buffer
To change the keepalive timer for the BMA, enter the following command in global configuration mode: Command
csg2(config)# ip csg bma keepalive number-of-seconds
Purpose Defines the BMA keepalive time interval for the CSG2.
Configuring the BMA GTP Message Buffer

The CSG2 can buffer GTP messages in either the Cisco Persistent Storage Device (PSD) or in the Storage Area Network (SAN) connected to the Internet Small Computer Systems Interface (iSCSI), as configured. (For more information, see the Configuring PSD Support section on page 7-1 and the Configuring iSCSI Support section on page 8-1.) By default, the CSG2 can buffer up to 10,000 general packet radio service (GPRS) tunneling protocol prime (GTP) messages for all BMAs. That setting is sufficient in most environments, but the CSG2 also allows you to change the BMA GTP message buffer, if necessary.
Note
We recommend that you change the number of GTP messages that can be buffered only when directed to do so by Cisco Technical Assistance Center (TAC) engineers. In most environments, the default value is the most appropriate setting. To change the maximum number of GTP messages, enter the following command in global configuration mode:
Command
csg2(config)# ip csg bma messages number
Purpose Specifies the maximum number of GTP messages that the CSG2 can buffer for the BMA. If the BMA GTP message buffer exceeds 75% of number, the CSG2 stops reading GTP messages from the PSD or SAN. When the buffer drops below the 75% threshold, the CSG2 again begins reading from the PSD or SAN, placing the buffered GTP messages in the BMA queue. For example, using the default setting of 10,000 messages, the CSG2 can read from the PSD or SAN as long as the buffer contains less than 7,500 GTP messages75% of 10,000 messages. By default, the CSG2 limits the rate at which GTP messages are read from the PSD to 500 packets/second, and from the SAN to 167 packets/second. However, you can change those default rates. For more information, see the Configuring the PSD Packet Drain Settings section on page 7-2 and the Configuring the iSCSI Packet Drain Settings section on page 8-4.
Configuring the BMA Retransmit Time

By default, the CSG2 retransmits packets to a BMA once every four seconds. That setting is sufficient in most environments, but the CSG2 also allows you to change the time between retransmits, if necessary.
3-3
Chapter 3 Configuring the BMA Retry Number
Note
We recommend that you change the retransmit time interval only when directed to do so by Cisco Technical Assistance Center (TAC) engineers. In most environments, the default value is the most appropriate setting. To change the BMA retransmit time interval for the CSG2, enter the following command in global configuration mode:
Command
csg2(config)# ip csg bma retransmit number-of-seconds
Purpose Defines the BMA retransmit time interval for the CSG2.
Configuring the BMA Retry Number

By default, the CSG2 retries communication with a BMA three times before determining that the link has failed. That setting is sufficient in most environments, but the CSG2 also allows you to change the number of retries, if necessary.
Note
We recommend that you change the number of retries allowed only when directed to do so by Cisco Technical Assistance Center (TAC) engineers. In most environments, the default value is the most appropriate setting. To change the maximum number of BMA retries allowed before the CSG2 determines that the link has failed, enter the following command in global configuration mode:
Command
csg2(config)# ip csg bma retries number-of-retries
Purpose Defines the maximum number of BMA retries allowed before the CSG2 determines that the link has failed.
Configuring the BMA Window Size

By default, the CSG2 sets the maximum BMA transmit window size to 128 packets, and sets the minimum BMA transmit window size automatically. Those settings are sufficient in most environments, but the CSG2 also allows you to change the maximum and minimum BMA transmit window sizes, if necessary.
Note
We recommend that you change the transmit window size only when directed to do so by Cisco Technical Assistance Center (TAC) engineers. In most environments, the default value is the most appropriate setting.
3-4
OL-22840-05
Chapter 3
Configuring BMA Support Configuring BMA Load Sharing
To define the BMA transmit window size for the CSG2, enter the following command in global configuration mode: Command
csg2(config)# ip csg bma window {max window-size | min window-size | min auto}
Purpose Defines the BMA transmit window size for the CSG2.
Configuring BMA Load Sharing

The CSG2 allows load sharing among BMAs. This support is useful in environments in which the number of billing records sent by the CSG2 could overwhelm a single BMA. Multiple BMAs can be simultaneously active, and the CSG2 assigns a BMA to each subscriber. All billing records for the subscriber are sent to the same BMA. If a BMA fails, all subscribers associated with that BMA are distributed among the other active other BMAs. The CSG2 maintains GTP sequence numbers for each BMA.
Note
You can configure multiple BMAs with the same IPv4 address, but the CSG2 does not support nodealive or redirect for multiple BMAs with the same IPv4 address. The CSG2 creates a sticky object to ensure that all the billing records for a subscriber are sent to the same BMA. If the user ID is not available (for example, if the internal table is too small to hold all user ID entries, or if the CSG2 cannot access the user ID database), the CSG2 creates a sticky object for the subscriber IP address. In addition to activating multiple BMAs, the CSG2 allows you to specify the time to wait before it deletes inactive sticky objects. To configure BMA load sharing, enter the following command in global configuration mode:
Command
csg2(config)# ip csg bma activate [number [sticky seconds]]
Purpose Activates one or more BMAs.
Reporting the Billing Plan ID to the BMA

The CSG2 reports the billing plan identifier in BMA records. The CSG2 also reports the billing plan ID in messages to the quota server. There are no commands required to enable billing plan ID reporting.
3-5
Chapter 3 Reporting the Billing Plan ID to the BMA
3-6
OL-22840-05
CH A P T E R
Configuring Quota Server Support

The CSG2 uses quota servers to return billing quota values for subscribers. The quota server interfaces with the billing system balance manager to reserve credit. The quota server then translates the reserved credit for the subscriber into quota based on the business and rating rules for multiple subscriber services on the CSG2. For each CSG2 content billing service, the CSG2 downloads a separate quota, and deducts from that quota. Quotas are specified in units called quadrans. A quadran is a generic unit whose value is defined by each quota server. A quadran can represent, for example, a click for a per-click service (for example, an HTTP request), or a byte for a per-volume service. The value of a quadran is transparent to the CSG2; the CSG2 simply requests and downloads quadrans as needed from quota servers. The CSG2 provides the following features for the quota server:

Configuring the Quota Server Local Port, page 4-2 Configuring a Quota Server, page 4-2 Configuring the Quota Server Keepalive Time, page 4-2 Configuring the Quota Server GTP Message Buffer, page 4-3 Configuring the Quota Server Retransmit Time, page 4-3 Configuring the Quota Server Retry Number, page 4-4 Configuring the Quota Server Window Size, page 4-4 Configuring Quota Server Load Sharing, page 4-5 Reassigning Subscribers to a New Quota Server, page 4-5 Sending User Profile Requests to Quota Servers, page 4-6 Quota Push, page 4-6 Replacing Quota Balance, page 4-6 Delaying Quota Reauthorization, page 4-7 Asynchronous Quota Return, page 4-7 Reporting the Billing Plan ID to the Quota Server, page 4-7 Pricing by Quota Server Configuration Example, page 4-8 Differentiating Prices Configuration Example, page 4-8 Reducing the Number of Services Configuration Example, page 4-9
4-1
Chapter 4 Configuring the Quota Server Local Port
Configuring the Quota Server Local Port

The first step when configuring CSG2 support for the quota server is to configure the local port on which the CSG2 is to communicate with the quota server. For prepaid billing, you must configure at least one quota server local port, the local port on which the CSG2 is to communicate with quota servers. To configure a local port for quota servers, enter the following command in global configuration mode: Command
csg2(config)# ip csg quota-server local-port port-number
Purpose Configures the local port on which the CSG2 communicates with quota servers. The quota server local port number must be different from the BMA local port number and from the PSD local port number (configured with the ip csg bma local-port command and the ip csg psd local-port command, respectively).
Configuring a Quota Server

For prepaid billing, you must configure at least one quota server. You can configure up to 32 quota servers. Each quota server must have a unique priority and a unique IP address (or a unique IP address-VRF name combination, if VRF is configured). When you configure a quota server, make sure that its IP address and port number match on both the active CSG2 and the standby CSG2. The CSG2 differentiates quota servers on the basis of their IP addresses and port numbers. You can configure multiple quota servers with the same IP address, but the CSG2 does not support nodealive or redirect for multiple quota servers with the same IP address. You can also enable the quota server for eGGSN. If you have enabled interface awareness, you can also associate a VLANs Virtual Routing and Forwarding (VRF) table name with the quota server. To configure a quota server, enter the following command in global configuration mode: Command
csg2(config)# ip csg quota-server [vrf vrf-name] ipv4-address port-number {priority | eggsn}
Purpose Configures CSG2 quota servers. To enable the quota server for eGGSN, specify the eggsn keyword.
Note
Configuring the Quota Server Keepalive Time

By default, the CSG2 sends keepalive messages to the quota servers once every 60 seconds. That setting is sufficient in most environments, but the CSG2 also allows you to change the time between keepalive messages, if necessary.
4-2
OL-22840-05
Chapter 4
Configuring Quota Server Support Configuring the Quota Server GTP Message Buffer
Note
We recommend that you change the keepalive time interval only when directed to do so by Cisco Technical Assistance Center (TAC) engineers. In most environments, the default value is the most appropriate setting. To change the keepalive timer for the quota servers, enter the following command in global configuration mode:
Command
csg2(config)# ip csg quota-server keepalive number-of-seconds
Purpose Defines the quota server keepalive time interval for the CSG2.
Configuring the Quota Server GTP Message Buffer

By default, the CSG2 can buffer up to 10,000 general packet radio service (GPRS) tunneling protocol prime (GTP) messages for the quota servers. That setting is sufficient in most environments, but the CSG2 also allows you to change the quota server GTP message buffer, if necessary.
Note
We recommend that you change the number of GTP messages that can be buffered only when directed to do so by Cisco Technical Assistance Center (TAC) engineers. In most environments, the default value is the most appropriate setting. To change the maximum number of GTP messages, enter the following command in global configuration mode:
Command
csg2(config)# ip csg quota-server messages number
Purpose Specifies the maximum number of GTP messages that the CSG2 can buffer for all quota servers.
Configuring the Quota Server Retransmit Time

By default, the CSG2 retransmits packets to a quota server once every four seconds. That setting is sufficient in most environments, but the CSG2 also allows you to change the time between retransmits, if necessary.
Note
We recommend that you change the retransmit time interval only when directed to do so by Cisco Technical Assistance Center (TAC) engineers. In most environments, the default value is the most appropriate setting.
4-3
Chapter 4 Configuring the Quota Server Retry Number
To change the quota server retransmit time interval for the CSG2, enter the following command in global configuration mode: Command
csg2(config)# ip csg quota-server retransmit number-of-seconds
Purpose Defines the quota server retransmit time interval for the CSG2.
Configuring the Quota Server Retry Number

By default, the CSG2 retries communication with a quota server three times before determining that the link has failed. That setting is sufficient in most environments, but the CSG2 also allows you to change the number of retries, if necessary.
Note
We recommend that you change the number of retries allowed only when directed to do so by Cisco Technical Assistance Center (TAC) engineers. In most environments, the default value is the most appropriate setting. To change the maximum number of quota server retries allowed before the CSG2 determines that the link has failed, enter the following command in global configuration mode:
Command
csg2(config)# ip csg quota-server retries number-of-retries
Purpose Defines the maximum number of quota server retries allowed before the CSG2 determines that the link has failed.
Configuring the Quota Server Window Size

By default, the CSG2 sets the maximum quota server transmit window size to 128 packets, and sets the minimum quota server transmit window size automatically. Those settings are sufficient in most environments, but the CSG2 also allows you to change the maximum and minimum quota server transmit window sizes, if necessary.
Note
We recommend that you change the transmit window size only when directed to do so by Cisco Technical Assistance Center (TAC) engineers. In most environments, the default value is the most appropriate setting. To define the quota server transmit window size for the CSG2, enter the following command in global configuration mode:
Command
csg2(config)# ip csg quota-server window {max window-size | min window-size | min auto}
Purpose Defines the quota server transmit window size for the CSG2.
4-4
OL-22840-05
Chapter 4
Configuring Quota Server Support Configuring Quota Server Load Sharing
Configuring Quota Server Load Sharing

The CSG2 allows load sharing among quota servers. This support is useful in environments in which the number of quota transactions sent by the CSG2 could overwhelm a single quota server. Multiple quota servers can be simultaneously active, and the CSG2 assigns a quota server to each subscriber. All quota transactions for the subscriber are handled by the same quota server. If a quota server fails, all subscribers associated with that quota server are distributed among the other active other quota servers.
Note
The CSG2 differentiates quota servers on the basis of their IPv4 addresses and port numbers. You can configure multiple quota servers with the same IPv4 address, but the CSG2 does not support nodealive or redirect for multiple quota servers with the same IPv4 address. The CSG2 creates a sticky object to ensure that all the quota transactions for a subscriber are sent to the same quota server. If the user ID is not available (for example, if the internal table is too small to hold all user ID entries, or if the CSG2 cannot access the user ID database), the CSG2 creates a sticky object for the subscriber IP address. In addition to activating multiple quota servers, the CSG2 allows you to specify the time to wait before it deletes inactive sticky objects. To configure quota server load sharing, enter the following command in global configuration mode:
Command
csg2(config)# ip csg quota-server activate number
Purpose Activates one or more quota servers. You do not need to use this command to activate a quota server that is enabled for eGGSN (that is, a quota server that is configured with the eggsn option on the ip csg quota-server command). A quota server that is enabled for eGGSN activates as soon as it is configured.
Reassigning Subscribers to a New Quota Server

If a quota server fails, you can reassign the subscribers to a different quota server. To reassign subscribers to a different quota server, enter the following command in global configuration mode: Command
csg2(config)# ip csg quota-server reassign
Purpose Reassigns subscribers to a different CSG2 quota server after a failure.

Note
This command is not supported for quota servers that are enabled for eGGSN (that is, quota servers that are configured with the eggsn option on the ip csg quota-server command). If a quota server that is enabled for eGGSN fails, it does not fail over to the next available quota server.
4-5
Chapter 4 Sending User Profile Requests to Quota Servers
Sending User Profile Requests to Quota Servers

By default, the CSG2 can send user profile requests to quota servers as needed. However, you can configure the CSG2 to prevent it from sending those user profile requests. To enable the CSG2 to send user profile requests (the default setting), enter the following command in global configuration mode: Command
csg2(config)# ip csg quota-server user-profile
Purpose Enables the CSG2 to send user profile requests to quota servers.
To prevent the CSG2 from sending user profile requests, enter the no form of the command in global configuration mode: Command
csg2(config)# no ip csg quota-server user-profile
Purpose Prevents the CSG2 from sending user profile requests to quota servers.
Quota Push
This feature enables operators to push quota for a service instance associated with an individual subscriber. This enables quota servers to provide quota for a subscriber or service before traffic from that subscriber or service reaches the CSG2. This eliminates the delay that can occur when quota is obtained through a service authorization request and response. A sophisticated quota server could also use quota push for better control of quota levels during active sessions. The CSG2 accepts a quota push for a subscriber at any point after the subscriber and billing plan are known to the CSG2 (that is, when a CSG2 User Table element exists for the subscriber). For example, the CSG2 accepts a quota push after receiving an accounting start but does not require an existing service for the subscriber (one is created). The CSG2 does not begin charging against quota until traffic begins to arrive and a session is created. Zero-quota might be granted so that cause code and authorization actions can be set (for example, for a free service). A quota download message is sent to the BMA in response to receiving a quota push. The service idle timer starts whenever quota is pushed, in case the expected traffic never arrives. The CSG2 rejects the Quota Push message if the Replace current balance flag is not set in the Granted Quadrans TLV. There are no commands required to enable quota push.
Replacing Quota Balance

By default, when the CSG2 receives a quota grant from the quota server, the CSG2 adds the granted quota to the current balance for a subscribers service. Quota balance replacement enables the quota server to instruct the CSG2 to replace the current quota balance with the amount of granted quota for a subscribers service. If the replacement grant is provided in a Service Authorization Response, the CSG2 subtracts the amount of quota used since the Service Reauthorization Requests from the granted quota before replacing the balance.
4-6
OL-22840-05
Chapter 4
Configuring Quota Server Support Delaying Quota Reauthorization
There are no commands required to enable quota balance replacement.
Delaying Quota Reauthorization

The CSG2 accepts the Reauthorization Delay TLV, which specifies the number of seconds the CSG2 delays its next reauthorization request to the quota server for the service specified in the message. This TLV also specifies the action the CSG2 is to take for the service between the time the message is received and the next reauthorization:

WaitThe CSG2 keeps transactions in a pending state during the delay period. In pending state, the CSG2 maintains the transaction state but drops packets. DenyThe CSG2 drops new transactions during the delay period. Existing transactions are dropped if quota expires during the delay period. The CSG2 does not maintain the session state; the subscriber must open a new connection after the delay period.
Note
For HTTP pipelining, dropping new transactions can also affect existing transactions if they share the same TCP connection. Quota servers can use delayed quota reauthorization to deny subscribers access to CSG2 categories without having to continually deny authorization requests (that is, for blacklisting services). To do so, the quota server sends a grant of 0 quadrans in a Service Authorization Response, Quota Push Request, or Service Verification Response message, with a long reauthorization delay timer (0xFFFFFFFF), a Deny action, and a cause code of 0x03.
There are no commands required to enable delayed quota reauthorization.
Asynchronous Quota Return

The Asynchronous Quota Return feature allows the quota server to request the CSG2 to return quota for a defined subscriber and service, and to send a Quota Return. The quota reserved for ongoing transactions is recalled from the transactions and included in the quota returned in the Quota Return message. Because all of the quota is returned, there is no longer any reserved quota to process ongoing pending transactions. Packets received for pending transactions are dropped. However, time-based billing holds back 5 seconds of quota, so transactions can proceed while returning quota for time-based billing. There are no commands required to enable asynchronous quota return.
Reporting the Billing Plan ID to the Quota Server

The CSG2 reports the billing plan identifier in messages to the quota server. The CSG2 also reports the billing plan ID in billing records. There are no commands required to enable billing plan ID reporting.
4-7
Chapter 4 Pricing by Quota Server Configuration Example
Pricing by Quota Server Configuration Example

The following example shows a CSG2 configuration in which the quota server performs all pricing. In this example:

Assume that Subscriber X has $10.00 in his account. There are two types of content:
C1This content is billed per object (for example, URL GET); each object costs $0.01. C2This content is billed per byte; each kilobyte costs $0.01.
The quota server controls each object transaction for content C1. The quota server controls all the pricing.
ip csg content C1 policy P1 inservice ! ip csg content C2 policy P2 inservice ! ip csg service PERCLICK basis fixed content C1 policy P1 ! ip csg service PERBYTE basis byte ip exclude mms content C2 policy P2 ! ip csg billing REGULAR service PERCLICK service PERBYTE
When Subscriber X, with a subscription to billing plan REGULAR, tries to access content that matches C1, the CSG2 tries to download quota for Subscriber X for service PERCLICK. The quota server borrows money from Subscriber Xs $10.00, and returns some quadrans to the CSG2. Each quadran is good for one object download, or one click. If the quota server is configured for the CSG2 to query for each click, it can choose to send just one quadran at a time, so that the CSG2 queries the quota server each time. However, if the quota server is configured to grant $2.00 worth of quadrans to the CSG2 in one shot, it can send 200 quadrans to the CSG2, which the CSG2 keeps using for Subscriber Xs access to C1. When Subscriber X tries to access content that matches C2, the CSG2 makes another request to the quota server to get Subscriber Xs quota for C2. C2 is billed per IP byte. The quota server borrows another $5.00 from Subscriber Xs account, and sends 500000 quadrans to the CSG2. As Subscriber X continues to access C2, his traffic is metered for volume. For each byte, the CSG2 deducts one quadran.
Differentiating Prices Configuration Example

The following example extends the previous example by adding a content type that is priced differently. In this example:

Assume that Subscriber X has $10.00 in his account. There are three types of content:
4-8
OL-22840-05
Chapter 4
Configuring Quota Server Support Reducing the Number of Services Configuration Example
C1This content is billed per *.jpg file, where each JPG file costs $0.01. C2This content is billed per byte, where each kilobyte costs $0.01. C3This content is billed per *.mp3 file, where each MP3 file costs $0.05.
The quota server controls each object transaction for content C1. The quota server controls all the pricing.
This configuration requires an additional service type, MP3, which allows the quota server to price object downloads (clicks) differently for MP3 files.
ip csg content C1 policy P1 inservice ! ip csg content C2 policy P2 inservice ! ip csg content MP3 policy P1 inservice ! ip csg service PERCLICK basis fixed content C1 policy P1 ! ip csg service PERBYTE basis byte ip content C2 policy P2 ! ip csg service MP3 basis fixed content C1 policy P1 ! ip csg billing REGULAR service PERCLICK service PERBYTE service MP3
When Subscriber X tries to download an MP3 file (that is, a file that matches content type MP3), the CSG2 requests the MP3 quota for Subscriber X. Each download of an MP3 file costs $0.05, so the quota server borrows $1.00 from Subscriber Xs account, and returns 20 quadrans to the CSG2 for service MP3. The CSG2 can use the quadrans for 20 downloads of MP3 files. Alternatively, the quota server could send just one quadran, which is enough for only one transaction. This would force the CSG2 to ask for quota before each download of an MP3 file.
Reducing the Number of Services Configuration Example

The Differentiating Prices Configuration Example section on page 4-8 shows that you can create a new service for one type of content and differentiate its billing from other types of content. However, with each new service, the subscribers quota fragments further, and traffic between the CSG2 and the quota server increases.
4-9
Chapter 4 Reducing the Number of Services Configuration Example
You can reduce traffic by specifying a symbolic weight on the CSG2. In the following example, each MP3 download ($0.05) costs five times as much as each JPG download ($0.01). By assigning a weight of 5 to MP3 downloads, you can keep both content C1 and content MP3 under service PERCLICK, thereby reducing the overall number of services and reducing the traffic between the CSG2 and the quota server.
ip csg content C1 policy P1 inservice ! ip csg content C2 policy P2 inservice ! ip csg content MP3 policy P1 inservice ! ip csg service PERBYTE basis byte ip content C2 policy P2 ! ip csg service PERCLICK basis fixed content C1 policy P1 content MP3 policy P1 weight 5 ! ip csg billing REGULAR service PERCLICK service PERBYTE
When the quota server borrows $1.00 from Subscriber Xs account and sends 100 quadrans for service PERCLICK, the CSG2 can use the quadrans for 100 JPG files, or for 20 MP3 files, or for a mix of the two content types.
4-10
OL-22840-05
CH A P T E R

A CSG2 content billing service is a component of a billing plan to which subscribers subscribe. You can configure one or more content billing services for the CSG2. Each service represents a group of content that is billed the same way, such as billing per-click (or per-request) or billing per-IP byte, and that shares part of a subscribers quota. Grouping content into one or more services enables you to separate, for example, a subscribers prepaid quota for Internet browsing from his quota for e-mails. For each service, the CSG2 downloads a separate quota, and deducts from that quota. Quotas are specified in units called quadrans. A quadran is a generic unit whose value is defined by each quota server. A quadran can represent, for example, a click for a per-click service (for example, an HTTP request), or a byte for a per-volume service. The value of a quadran is transparent to the CSG2; the CSG2 simply requests and downloads quadrans as needed from quota servers. The CSG2 requests an additional quota grant when a subscribers per-click quota falls below a specified percentage of the last quota grant, or when a subscribers per-volume quota falls below a specified percentage of the last quota grant or 32 KB, whichever is greater. For each service that a subscriber tries to access, the CSG2 maintains a separate logical accounting session. When a subscribers quota is divided among multiple services, the CSG2 requests an additional quota grant for each service individually, based on its usage. If a subscriber fails authorization for a service, but continues to send new requests for that service, the CSG2 waits a specified time before sending the quota server a reauthorization request for that subscriber. This ensures that the quota server is not inundated with reauthorization requests from unauthorized subscribers. The CSG2 allows you to define a pool of up to 1024 services. You can authorize each subscriber for any number of services from that pool, but we recommend that the billing system not authorize each subscriber for more than 10 active services. Exceeding this guideline could lead to the following problems:

The increase in the number of quota authorizations per subscriber can overload both the quota server and the CSG2. As the number of services for which a subscriber is actively authorized increases, the subscribers quota becomes fragmented. Although the CSG2 allows the billing system to recall and redistribute the quota, so that the subscriber is not denied service because of quota fragmentation, the process increases overhead in both the quota server and the CSG2.
The CSG2 supports multiple protocols under a single service definition. The CSG2 provides the following features for content billing services:

Configuring a Basic Content Billing Service, page 5-2 Configuring the Billing Basis for a Service, page 5-2
5-1
Chapter 5 Configuring a Basic Content Billing Service
Specifying a Service Owner, page 5-3 Specifying a Service Class, page 5-3 Configuring a Service Idle Time, page 5-4 Configuring a Service Lifetime, page 5-4 Configuring Advice of Charge, page 5-4 Configuring Service Verification, page 5-8 Enabling Service-Level CDR Summarization, page 5-9 Support for eG-CDRs with GGSN, page 5-11 Configuring Passthrough Mode and the Default Quota, page 5-12 Configuring Metering, page 5-13 Configuring the Quota Reauthorization Threshold, page 5-18 Configuring the Quota Reauthorization Timeout, page 5-19 Final Unit Indication, page 5-19 Enabling a Refund Policy for a Service, page 5-20 Configuring Content Access Control, page 5-20
Configuring a Basic Content Billing Service

Each content billing service is associated with one or more contents and policies. Multiple services can include the same content/policy pair, as long as the services are not associated with the same billing plan. They cannot be associated with the same billing plan because then the match of content/policy pair to service would not be unique. To configure a service, enter the following commands beginning in global configuration mode: Command
Step 1 Step 2
csg2(config)# ip csg service service-name csg2(config-csg-service)# content content-name policy policy-name [weight weight-name]
Purpose Configures a CSG2 content billing service, and enters CSG2 service configuration mode. Configures a content and policy as a member of a CSG2 billing service, and optionally assigns a weight to the content.
Configuring the Billing Basis for a Service

The billing basis specifies how billing is to be charged:

Per-click (fixed-cost) billing is charged at a fixed cost, which is deducted each time the first packet for a transaction matches a content-policy pair (that is, deducted for each request). Volume-based billing can be based on either the number of IP bytes or the number of TCP bytes. Duration-based billing can be based on either service duration time or connection duration time.
5-2
OL-22840-05
Chapter 5
Configuring Service Support Specifying a Service Owner
To configure the billing basis for a service, enter the following command in CSG2 service configuration mode: Command
csg2(config-csg-service)# basis {byte ip | byte tcp | fixed | second [connect | transaction]} [dual [byte ip | byte tcp | fixed | second transaction}]]
Purpose Specifies the billing basis for a CSG2 content billing service.
Note
When changing the basis for a service, the content must be taken out of service.
To specify the activation mode for a CSG2 Connection Duration service, enter the following command in CSG2 service configuration mode: Command
csg2(config-csg-service)# activation [automatic | user-profile]
Purpose Specifies the activation mode for a CSG2 Connection Duration service (that is, a service configured with basis second connect).

automaticActivates the Connection Duration service, unless the billing profile indicates that no service is to be activated. user-profileActivates the Connection Duration service only if the billing profile specifies this service as the connect service. This is the default setting.
Specifying a Service Owner

The CSG2 enables you to specify an identifier or name for a CSG2 service owner to be used with fixed-record format. The owner is responsible for the content associated with the service. The administrator who configures owner identification is responsible for its accuracy. Correct configuration requires that contents for this service, their policies, and any associated URL or header maps, identify all data transfers with this owner, and only data transfers with this owner. To do so, enter the following command in CSG2 service configuration mode: Command
csg2(config-csg-service)# owner {id id | name name}
Purpose Specifies an identifier or name for a CSG2 service owner.
Specifying a Service Class

The CSG2 enables you to specify a service class value to be used with fixed-record format. The class is opaque to the CSG2 and has meaning only for the administrator. It is reported as tariff-class in fixed-record format call detail records (CDRs). To specify a service class, enter the following command in CSG2 service configuration mode: Command
csg2(config-csg-service)# class value
Purpose Specifies a service class value.
5-3
Chapter 5 Configuring a Service Idle Time
Configuring a Service Idle Time

The CSG2 enables you to configure an idle timer for a service. The timer begins when there are no sessions. If the timer expires and the subscribers quota for the service has not been used, the CSG2 assumes that the service is idle and sends a Service Stop to free up the resources. For services configured with basis second, make sure the idle timeout value for the content configurations, set using the idle command in CSG2 content configuration mode, does not exceed the service idle timeout value, set using the idle command in CSG2 service configuration mode. To configure a service idle timer, enter the following command in CSG2 service configuration mode: Command
csg2(config-csg-service)# idle duration
Purpose Specifies the minimum amount of time that the CSG2 maintains a service with no subscriber sessions.
Configuring a Service Lifetime

The prevalence of always-on connections in today's networks can result in CSG2 services that never stop, resulting in very high usage. If tuning the CSG2 service idle timer does not reduce the usage sufficiently, you can define a maximum duration (or lifetime) for a service. The CSG2 supports configuring a lifetime for:

Prepaid and postpaid services Configured and preloaded services Clears the sessions belonging to the service for the subscriber Clears the service from the subscriber Sends a service-level CDR to the BMA, if configured to do so, with the Service Lifetime Exceeded cause code For true prepaid services, sends Service Stop records with the Service Lifetime Exceeded cause code to the quota server and to the BMA For virtual prepaid services, the CSG2 does not send any Service Stop records
When the lifetime expires for a service, the CSG2 performs the following actions:

To specify a lifetime for a CSG2 service, enter the following command in CSG2 service configuration mode: Command
csg2(config-csg-service)# lifetime duration
Purpose Specifies a maximum duration, or lifetime, for a CSG2 service.
Configuring Advice of Charge

Advice of Charge (AoC) is a function that enables a service provider to provide messaging and authorization prompts to its subscribers. The CSG2s support for AoC uses a quota server and a customer-provided notification server to host the actual messaging:
5-4
OL-22840-05
Chapter 5
Configuring Service Support Configuring Advice of Charge
The quota server is responsible for telling the CSG2 to block subscriber requests and redirect them to the notification server when the subscriber must make a decision to pay for the service. It is also responsible for telling the CSG2 to allow the subscriber request to flow when the subscriber has agreed to pay. The notification server is responsible for communicating fees to the subscriber and providing the option to pay. The subscribers payment decision must be communicated from the notification server to the quota server.
The CSG2s role in the AoC process is to redirect subscriber data requests to the notification server. The CSG2 provides URL-redirect support for HTTP and wireless application protocol 1.x (WAP 1.x), for redirecting to the notification server. With URL-redirect, the notification server can be a standard web server, because the CSG2 does the redirection at the protocol level. The CSG2 allows the redirection for AoC to be triggered once per service (when the first access to the service is made by the subscriber), or at the start of any new data transaction. The former is accomplished using the CSG2s service verification function, the latter using the CSG2s content authorization function. The URL can be pre-configured, or it can be provided dynamically by the quota server (the more flexible option). You can configure content authorization to request a pass/fail authorization for any transaction (for example, for individual SMTP e-mails), but the CSG2 does not honor redirect requests from the quota server in the middle of a TCP connection. In general, the method by which the notification server communicates success or failure of the AoC to the quota server is outside the scope of the CSG2s role in the process. However, the CSG2 does provide some additional assists for URL-redirects that greatly ease the burden on the backend systems. For example, the CSG2 provides the ability to strip trailing tokens from a URL. Therefore, an HTTP-based notification server can be deployed such that it will append the results of the AoC to the subscribers HTTP request when redirecting the subscriber to the final requested content. The CSG2 reports this URL, token and all, to the quota server on the next Content Authorization Request. If configured to do so, upon successfully receiving permission from the quota server to forward the flow, the CSG2 strips the token from the request so that the content server is not confused by the extra data. You can instruct the CSG2 to obtain authorization from the quota server for each subscriber request for content. The CSG2s support for AoC has the following restrictions:

AoC is supported for all protocols except DNS, IMAP, and POP3. However, AoC via content authorization and URL-redirect is supported for only HTTP, SIP, WAP 1.x, and WAP 2.0. AoC token-stripping is not supported for requests in which the URL is fragmented over more than one IP packet. AoC is not supported for Connection Duration services (that is, services configured with basis second connect). When performing AoC for a TCP connection carrying pipelined HTTP requests, the CSG2 responds with the redirect to the subscriber as soon as the quota server requests the redirect. This could result in the redirect arriving at the subscriber before responses for previous requests arrive, and the subscriber might associate the redirect with a different request in the pipeline. When a CSG2 prepaid service is configured for AoC, the weighting value for charging the content is not determined until the CSG2 processes the Content Authorization Response. For SMTP billing (parse protocol smtp), the CSG2 does not send the Content Authorization Request until it processes the SMTP DATA command. If the CSG2 does not process the SMTP DATA command for a session, then the CSG2 does not charge the session for volume and event billing.
5-5
Chapter 5 Configuring Advice of Charge
If a Content Authorization Request is queued to a quota server, and the quota server fails, the CSG2 reassigns the request to the standby quota server or to some other active quota server. If there is no standby quota server or other active quota server, the CSG2 completes the AoC request with action code 0 (Drop).
Note
If the quota server queue is very long and very slow, the Interprocessor Communication (IPC) request for the AoC message might timeout on the Traffic Processor (TP). If this occurs, and if the timeout handler on the TP has already triggered, then the CSG2 might treat the response from the quota server as a failed message, dropping the packet.

Enabling AoC URL-Rewriting, page 5-6 Configuring an AoC Token, page 5-6 Configuring AoC URL-Appending, page 5-7 Redirect Flexibility, page 5-8
Enabling AoC URL-Rewriting

When AoC URL-rewriting is enabled, the CSG2 alerts the quota server of a new transaction, and allows it to direct the CSG2 to perform any of the following mutually exclusive actions:

DROP: Drop all packets for this flow. FORWARD: Forward the flow without altering the destination (a weight might be specified). REDIRECT-URL: Redirect subscriber requests to the URL provided by the quota server. The CSG2 sends a Layer 7 redirect to the subscriber (for example, HTTP 302 response) that contains the redirect URL.
To enable AoC URL-rewriting, enter the following command in CSG2 service configuration mode: Command
csg2(config-csg-service)# aoc enable
Purpose Enables Advice of Charge (AoC) URL-rewriting for the CSG2.
Configuring an AoC Token

When direct communication is not possible between the quota server and the notification server, payment decision information can be shared indirectly by modifying the URL in the subscriber request. The notification server appends a string beginning with a token to the originally requested URL and sends it to the subscriber as part of a redirect reply after the subscriber agrees to pay. The CSG2 receives the subsequent GET request containing the rewritten URL and sends it to the quota server in a Content Authorization Request. The quota server recognizes the token string and understands that the subscriber has agreed to pay for the request. It responds to the CSG2 with a FORWARD action code in the Content Authorization Response. The CSG2 detects the token, creates a new GET request that contains the original URL (without the appended token and any characters following it), and sends the GET on behalf of the subscriber. The token must be known by the CSG2, the quota server, and the notification server. The token is administratively defined on the CSG2 by using the CLI. The token must be chosen carefully to ensure that it is present only in URLs that are rewritten by the notification server and not in other subscriber requests.
5-6
OL-22840-05
Chapter 5
Configuring Service Support Configuring Advice of Charge
URL-rewriting allows a top-off server to append parameters to a URL in order to convey state information to the quota server during a Content Authorization Request. Whenever a Content Authorization Response contains the forward action code, and the URL contains the AoC confirmation token, the token and all trailing characters are removed from the URL before the request is forwarded to the server. If the token uses the URL-escape format, the redirect URL to which the token is being matched must also use the URL-escape format. The CSG2 supports AoC URL-rewriting for only HTTP and WAP 1.x. If you have enabled AoC URL-rewriting, you can define a URL-rewriting token for AoC. To do so, enter the following command in CSG2 service configuration mode: Command
csg2(config-csg-service)# aoc confirm token
Purpose Configures a token for use in AoC URL-rewriting.
Configuring AoC URL-Appending

Whenever a Content Authorization Response contains a REDIRECT_URL action code for a WAP Content Authorization Request, the CSG2 can optionally append the originally requested URL to the one returned by the quota server. For example, if the subscriber requests the following URL: http://www.redirect_url.com/home.wml and the quota server returns the following URL in a REDIRECT_URL Content Authorization Response: http://www.redirect_url. .com/charges.wml then the CSG2 sends the following URL as part of a redirect message to the subscriber: http://www.redirect_url. .com/charges.wml?www.redirect_url. .com/home.wml The default behavior is to pass the redirect URL to the subscriber as specified by the quota server without modification. The CSG2 supports AoC URL-appending for WAP 1.x and WAP 2.0 only. If you have enabled AoC URL-rewriting, you can enable AoC URL-appending for AoC. To do so, enter the following command in CSG2 service configuration mode: Command
csg2(config-csg-service)# aoc append url
Purpose Specifies that the CSG2 is to append the original URL to the redirect URL sent by the quota server on a Content Authorization REDIRECT_URL response for use in AoC URL-rewriting.
5-7
Chapter 5 Configuring Service Verification
Redirect Flexibility
A quota server can request a redirect for multiple reasons (top-up, sorry indication, login request). The CSG2 allows the quota server to return the IP address and port number for each redirect. Thus, a different port number, or even a different network, can be used for every reason that the quota server might request the redirect. The CSG2 stores the most recent redirect address and port number for each service under each subscriber profile, and uses that address and port instead of the globally defined default.
Configuring Service Verification

Service verification is a capability similar to Advice of Charge (AoC), which is provided the first time a subscriber accesses a service using HTTP or WAP 1.x. A Service Verify Request quota management message supplies the quota server with content from the subscriber request (the URL, header information, subscriber agent, and so on). The quota server responds with a Service Verification Response that includes a decision to redirect the request to a notification server, to forward it, or to drop it. Service verification provides the same URL-rewriting capabilities that are provided by AoC. An administrator uses the command-line interface (CLI) to define the service confirmation token that is used in URL-rewriting. As long as service verification is enabled, sessions of any type for this subscriber do not trigger service reauthorization requests. Service reauthorization resumes for the subscriber when service verification is disabled. Service verification supports forward, redirect-URL, and drop authorization action codes sent in a Service Verification Response. Service verification also supports optional downloading of quota for a subscriber in a Service Verification Response. The CSG2 sends service verification requests even when no quota is supplied in the Service Verification Response, if the Service Authorization Response contains the cause TLV with value 0x04 (subscriber low on quota, but service access is permitted). Quota Download call detail records (CDRs) are sent to the BMA, as appropriate, whenever the quota server supplies quota in a Service Verification Response. Service verification can be used in conjunction with existing AoC functionality. Service verification is supported only for HTTP and WAP 1.x. This section contains the following information:

Enabling Service Verification URL-Rewriting, page 5-8 Configuring a Service Verification Token, page 5-9
Enabling Service Verification URL-Rewriting

When service verification URL-rewriting is enabled, the CSG2 alerts the quota server of a new transaction, and allows it to direct the CSG2 to perform any of the following mutually exclusive actions:

DROP: Drop all packets for this flow. FORWARD: Forward the flow without altering the destination (a weight might be specified). REDIRECT-URL: Redirect subscriber requests to the URL provided by the quota server. The CSG2 sends a Layer 7 redirect to the subscriber (for example, HTTP 302 response) that contains the redirect URL.
5-8
OL-22840-05
Chapter 5
Configuring Service Support Enabling Service-Level CDR Summarization
To enable service verification, enter the following command in CSG2 service configuration mode: Command
csg2(config-csg-service)# verify enable
Purpose Enables service verification for the CSG2. Service verification is disabled when you enter the no form of this command, or when the quota server sends a Service Verify Tag-Length-Value (TLV) in a Service Authorization Response or Service Verification Response.
Configuring a Service Verification Token

URL-rewriting allows a top-off server to append parameters to a URL in order to convey state information to the quota server during a Service Verification Request. Whenever a Service Verification Response contains the forward action code, and the URL contains the verify confirmation token, the token and all trailing characters are removed from the URL before the request is forwarded to the server. If the token uses the URL-escape format, the redirect URL to which the token is being matched must also use the URL-escape format. The CSG2 supports URL-rewriting for HTTP, WAP 1.x, and WAP 2.0. If you have enabled service verification URL-rewriting, you can define a URL-rewriting token for service verification. To do so, enter the following command in CSG2 service configuration mode: Command
csg2(config-csg-service)# verify confirm token
Purpose Configures a token for use in CSG2 service verification URL-rewriting.
Enabling Service-Level CDR Summarization

By default, the CSG2 generates billing records for each transaction. This large number of records might overwhelm the charging gateway (CG) or the collector. To prevent this situation, the CSG2 can summarize CDRs at the service level, instead of at the transaction level. For example, if a subscriber accesses the open Internet service, and the data is billed solely on the basis of volume, it is of little use to generate records for each HTTP transaction. With service-level CDR summarization enabled, the CSG2 generates only consolidated records on service-level usage. Information from individual events is not reported (for example, no URLs). The CSG2 uses the Service Usage - variable format (0x0040) CDR for service-level CDR summarization. Service-level CDRs differ from Service Stop CDRs as follows:
The CSG2 sends a Service Stop message to the quota server when a prepaid service instance ends. At the same time, the CSG2 sends a companion CDR, the Service Stop Notification CDR (0x11), to the BMA. The CSG2 sends a service-level CDR to the BMA when a service instance ends, or, if configured, when a volume- or time-based threshold is met. The CSG2 sends service-level CDRs only to the BMA, and only if the service is configured for service-level CDRs.
5-9
Chapter 5 Enabling Service-Level CDR Summarization
The CSG2 can generate intermediate service-level CDRs for volume-based billing or for time-based billing. Cause codes 0x0A and 0x0B are used for service-level CDRs generated for volume- or time-based billing. The CSG2 supports the following protocols in both fixed and variable format: FTP, IP, HTTP, IMAP, POP3, RTSP, SMTP, and WAP 1.x. (POP3 and IMAP are supported in postpaid mode only.) To configure service-level CDR summarization, enter the following command in CSG2 service configuration mode: Command
csg2(config-csg-service)# records granularity service {bytes bytes | seconds seconds | bytes bytes seconds seconds}
Purpose Specifies that the CSG2 is to generate summarized, service-level CDRs.
Note
To enable service-level CDR summarization in postpaid mode, you must also specify that the associated billing plan is postpaid by using the mode postpaid command in CSG2 billing configuration mode. Service-level CDRs are generated only for subscribers with entries in the CSG2 User Table entry. If a subscriber does not have an entry in the User Table, the CSG2 generates transaction-level CDRs. If there are no quota servers configured on the CSG2, and you want to use service-level CDRs in a postpaid environment (that is, all users are postpaid), you can configure a single postpaid billing plan and assign all users to that billing plan. In the following example, all postpaid users are automatically assigned to billing plan EVERYBODY:
ip csg map SPORTS match url http://www.nhl.com/* ! ip csg map MOVIES match url http://www.hollywood.com/* ! ip csg policy SPORTS map SPORTS ! ip csg policy MOVIES map MOVIES ! ip csg content HTTP ip any tcp 80 policy SPORTS policy MOVIES inservice ! ip csg service SPORTS content HTTP policy SPORTS records granularity service byte 128000 ! ip csg service MOVIES content HTTP policy MOVIES records granularity service bytes 128000 ! ip csg billing EVERYBODY mode postpaid service SPORTS service MOVIES
5-10
OL-22840-05
Chapter 5
Configuring Service Support Support for eG-CDRs with GGSN
Support for eG-CDRs with GGSN

The CSG2 can exchange service usage information with the Cisco GGSN release 9.2 or later. Doing so enables the GGSN to generate eG-CDRs that contain service usage information for prepaid and postpaid users. The CSG2 sends service usage information to the GGSN using GTP' and the enhanced eGGSN quota server interface. For a service interval (that is, the time since the last report for this service), the CSG2 sends uplink and downlink IP volumes, the first packet time, the last packet time, and the time usage. The reported usage is the usage since the last report, not the cumulative usage.
For a postpaid service, the CSG2 calculates the sum of time usages as the service's last-packet-time minus the service's first-packet-time. That sum usually does not equal the sum of the last-packet-time minus the first-packet-time for all intervals. For a prepaid or virtual prepaid service, the time usage matches the service duration billing usage calculated for the service, including any quota consumption time (QCT) calculations.
The GGSN enables the CSG2 subscriber as an eG-CDR user via a RADIUS Accounting Request message. The GGSN also specifies the IP address and UDP port of the eGGSN quota server. The same quota server can be used for both eG-CDR reporting and for online charging. The CSG2 generates service usage information when any of the following conditions occurs:

A GGSN-generated RADIUS Interim Accounting Request is received with a Gn-interface trigger match specified in a Cisco VSA A GGSN-generated Service Control Request due to overall user volume or time usage is received A service instance is terminated A CSG2 service matches a volume or time threshold A CSG2 prepaid service reauthorization occurs due to low quota or quota return events, as defined in the 3GPP standards (if the CSG2 is configured to do so)
The CSG2 also records and reports usage at tariff-switch time for prepaid services. The CSG2 does not generate BMA records for users that are enabled for eG-CDR. The CSG2 sends service usage information to the GGSN for only those services that are configured for records granularity service. That means that user flows or transactions that do not map to a service configured for records granularity service do not result in any record to a BMA or to an eGGSN quota server. When the GGSN is enabled as the quota server for a CSG2 prepaid subscriber:
The GGSN uses prepaid service usage information to create the eG-CDRs for that subscriber. In this mode, the GGSN can instruct the CSG2 to stop sending service charging information to the GGSN and to disable any record generation to BMA devices. If a service is online-disabled, the eGGSN does not generate eG-CDR information for the service, and the CSG2 does not generate CDRs for the service.
To specify an interworking mode for the CSG2 and the eGGSN, enter the following command in global configuration mode: Command
csg2(config)# ip csg egcdr mode {tight}
Purpose Specifies an interworking mode for the CSG2 and the eGGSN. Tight interworking mode enables a global set of triggers for adding containers to eG-CDRs for the service data flow when the CSG2 has a direct interface to a quota server via GTP'. This is currently the only supported mode.
5-11
Chapter 5 Configuring Passthrough Mode and the Default Quota
To configure a rating group for a CSG2 eG-CDR service, enter the following command in CSG2 service configuration mode: Command
csg2(config-csg-service)# rating-group rating-group-number
Purpose Configures a rating group for a CSG2 eG-CDR service.
Configuring Passthrough Mode and the Default Quota

For prepaid subscribers, sessions are blocked when a quota server is not available for authorization grant of quota. In passthrough mode, the CSG2 grants quota for services and their sessions when a quota server is not available. The CSG2 allows all traffic to pass, and CDRs are flagged for special consideration by the BMA. For each service for which you want to use passthrough mode, you must enable it by entering the following command in CSG2 service configuration mode: Command
csg2(config-csg-service)# passthrough quota-grant
Purpose Enables passthrough mode for a CSG2 service.
You also use this command to specify the size of each quota grant (the default quota) to assign to a service. When passthrough mode is enabled for a service, and a session for a service needs quota, and no quota server is active, the CSG2 grants the service the amount of quadrans specified on the passthrough command. (There are three types of quadrans: basis byte for volume-based billing, basis fixed for event-based billing, and basis second for duration-based billing.) The CSG2 continues to grant quota as long as a quota server is inactive. When the service becomes idle, the CSG2 generates and stores a Service Stop Request message, containing the total usage for this instance of the service. When a quota server becomes active, the CSG2 forwards all stored Service Stop Request messages to the quota server. This section contains the following information about passthrough mode:

Flagging of Messages, page 5-12 User Profile Requests, page 5-12 Quota Server Recovery, page 5-13
Flagging of Messages
To facilitate billing recovery, some messages to the quota server and the BMA include a QuotaServerFlags TLV. The CSG2 adds this TLV whenever it grants a passthrough mode quota to a service.
User Profile Requests

When the CSG2 learns of new subscribers, it typically sends a User Profile Request to an active quota server. This enables the CSG2 to learn the billing plan to use for each subscriber. If the quota server returns a NULL billing plan, this indicates that a subscriber is postpaid.
5-12
OL-22840-05
Chapter 5
Configuring Service Support Configuring Metering
Quota Server Recovery

When a quota server becomes active, the CSG2 forwards stored Service Stop Requests to it. Additional actions taken by the CSG2 depend on subscriber traffic. Prepaid subscribers might have some services that were granted quota in passthrough mode. For those services, when quota runs low, the CSG2 sends a Service Reauthorization Request to the quota server, flagging the request with the QuotaServerFlags TLV. The usage TLV and remaining TLV contain the sum total of quota granted to the service since it began. This total might be a combination of quota granted by the quota server before the failure and quota granted by the CSG2 in passthrough mode. The requested quadrans TLV contains a request for an additional quota amount. When the quota server responds to a Service Stop or a Service Reauthorization Request, the CSG2 moves the service out of passthrough mode. If the quota server denies quota when it sends a Service Authorization Response message, the CSG2 blocks the traffic. The CSG2 also flags CDRs generated by traffic for these services, which received passthrough mode quota grants, with QuotaServerFlags TLVs, until a Service Stop Request is sent. That is, once a service is granted a passthrough mode quota, the CSG2 flags all CDRs for that serviced, up to and including the Service Stop. This applies only to prepaid subscribers. Postpaid subscribers CDRs are never flagged.
Configuring Metering
The CSG2 enables you to control some aspects of metering. This section contains the following information:

Configuring an Initial Quota for Metering, page 5-13 Configuring a Minimum Quota for Metering, page 5-14 Configuring a Debit Increment for Metering, page 5-14 Excluding RTSP PAUSE from Metering, page 5-15 Including IMAP Bytes in Metering, page 5-15 Excluding MMS from Metering, page 5-17 Excluding the Final Service Idle from Metering, page 5-18
Configuring an Initial Quota for Metering

TheCSG2 enables you to specify the initial quota, in quadrans, debited from the balance at the beginning of a service when the service is configured for Service Duration Billing. The debit occurs when the CSG2 grants the first network access for a session that has been mapped to the service. The initial value is not rounded up to the nearest increment value. Specifying the initial quota allows you to apply connection setup charges to a service. To specify the initial quota, enter the following command in CSG2 service configuration mode: Command
csg2(config-csg-service)# meter initial value
Purpose Specifies the initial quota debited by the CSG2 from the balance at the beginning of a service when the service is configured for Service Duration Billing.
5-13
Chapter 5 Configuring Metering
Configuring a Minimum Quota for Metering

The CSG2enables you to specify the minimum number of quadrans debited for a service or session, excluding the value in meter initial. For example, to force the CSG2 to debit 90 quadrans when less than 90 quadrans of network usage were used for the service, specify meter minimum 90. If the initial value is 20 quadrans and the minimum is 90 quadrans, then the minimum total charge is 110 quadrans. The minimum value is applied only if at least 1 session is granted network access for the service. If basis second is configured for the service, the usage is rounded up to the minimum value when the Service Stop is sent. For a minimum value of 90, 150 seconds of network usage is not rounded up for the purpose of calculating usage in the Service Stop, but, for example, 63 seconds of network usage is rounded up to 90 quadrans.
Note
The rounding-up of network usage is not reflected in calculations for the Usage Tag-Length-Value (TLV) in Service Reauthorization Requests.
To specify the minimum number of quadrans debited by the CSG2 for a service or session, enter the following command in CSG2 service configuration mode: Command
csg2(config-csg-service)# meter minimum value
Purpose Specifies the minimum number of quadrans debited for a service or session.
Configuring a Debit Increment for Metering

The CSG2enables you to specify the increment, in seconds, for debiting quota upon completion of a service configured for Service Duration Billing. For example, to enable the CSG2 to charge quota per minute instead of per second, specify meter increment 60. If basis second is configured for the service, the network usage (usage excluding the initial charge) is rounded up to the nearest integer multiple of the increment value when the Service Stop is sent. For an increment value of 60, the CSG2 does not round up 120 seconds of network usage; however, the CSG2 does round up, say, 163 seconds of network usage to 180 quadrans before it calculates total usage for reporting in the Service Stop.
Note
The increment value is considered when determining whether sufficient quota exists for granting network access for a session. For instance, if the increment is 60, the network usage is 50, and the balance is 10, network access is permitted. However, if the increment is 60, the network usage is 70, and the balance is 10, network access is not permitted because the balance is not sufficient to satisfy the entire increment (that is, a minimum of 1 minute of quota would be required to allow access for a portion of the minute).
5-14
OL-22840-05
Chapter 5
To specify the debiting increment, enter the following command in CSG2 service configuration mode: Command
csg2(config-csg-service)# meter increment value
Purpose Specifies the increments for debiting quota by the CSG2 upon completion of a service configured for Service Duration Billing.
Excluding RTSP PAUSE from Metering

The CSG2 monitors the RTSP control session between the RTSP subscriber and network and scans for PAUSE and PLAY methods. When a PAUSE method is detected, the CSG2 initiates an event to inform the prepaid service to stop charging for duration-based billing. Then, when a PLAY method is detected, the CSG2 initiates an event to inform the prepaid service to resume the charging for duration-based billing. The event corresponding to the PLAY is only necessary when the CSG2 is in the PAUSE state. When configuring RTSP PAUSE support, keep the following considerations in mind:

RTSP pause is supported only for duration-based billing (basis second). Duration-based billing applies only to a billing service, and RTSP might not be the only application that is operating over a given billing service. Therefore, the suspension of billing for the PAUSE period applies only if there are no other applications operating over the same billing service. Both last billable and intermediate idles for RTSP are excluded from duration-based billing if RTSP PAUSE support is configured. RTSP PAUSE support applies only to classical RTSP transport, in which the stream data is transmitted over a separate User Datagram Protocol (UDP) connection. RTSP PAUSE support does not apply to the TCP or HTTP interleaved transport modes. RTSP pause support is independent of the UDP content idle timer value and of the RTSP service idle timer. RTSP pause support does not stop the UDP content idle timer. RTSP PAUSE support applies only to charges for prepaid quota usage (quadrans TLV). The RTSP PAUSE time is not reflected in any CDRs.
To exclude the RTSP PAUSE time from the duration-based billing calculation, enter the following command in CSG2 service configuration mode: Command
csg2(config-csg-service)# meter exclude pause rtsp
Purpose Excludes the RTSP PAUSE time from the CSG2 usage calculation duration billing.
Including IMAP Bytes in Metering

The CSG2 provides transaction support for IMAP. The CSG2 defines an IMAP transaction as a tagged response from an IMAP server that contains TEXT. TEXT is the part of the e-mail that follows the envelope; the presence of TEXT results in a classification of BODY. The CSG2 includes IMAP transaction counts in the Completed Transactions TLV. The CSG2 does not include any envelope information in the IMAP transaction CDRs.
5-15
Chapter 5 Configuring Metering
For requests and responses that are not transactions (they do not contain TEXT), the CSG2 accumulates the bytes and includes them in the next transaction. When the IMAP session ends, the CSG2 reports any remaining bytes. Consider the following simple example of an IMAP transaction with BODY: Subscriber request: 1 FETCH 5 BODY[] Network response: * 5 FETCH (BODY[]{55}cr-lf-55-bytes-of-e-mail-followed-by-cr-lf)cr-lf 1 OK FETCH COMPLETE The CSG2 handles this request and response as follows:
The subscriber request is tagged 1. The CSG2 parses the request and increments the body up byte counts, because the request was for a BODY[]. The CSG2 parses the untagged response from the network and notes that it contains TEXT (BODY[]). The CSG2 parses the tagged response 1 OK FETCH COMPLETE, which means this is an IMAP transaction (a tagged response that contains TEXT).
Here is a more complicated example: Subscriber request: 8 FETCH 1:100 BODY[]<0.5> Network response: * 1 FETCH (BODY[]<0> . . . . .)cr-lf * 2 FETCH (BODY[]<0> . . . . .)cr-lf * 3 FETCH (BODY[]<0> . . . . .)cr-lf * 4 FETCH (BODY[]<0> . . . . .)cr-lf ... * 100 FETCH (BODY[]<0> . . . . .)cr-lf 8 OK FETCH COMPLETE The CSG2 handles this request and response as follows:
The subscriber request is tagged 8. The CSG2 parses the request and increments the body up byte counts, because the request was for a BODY[]. The network sends 100 untagged responses which the CSG2 parses, noting that the response contains TEXT (BODY[]). The CSG2 parses the tagged response 8 OK FETCH COMPLETE, which means this is an IMAP transaction (a tagged response that contains TEXT). The CDR reports 100 BODY fetches, the request bytes are allocated to body up, and the response bytes are allocated to body down.
The CSG2 categorizes bytes as BODY, HEADER, and OTHER, determined as follows:
BODYThe bytes are classified as BODY if a fetch request or response is encountered for one of the following specifications (including any appended <> subset variants):
BODY[] BODY[#] BODY[TEXT] BODY[#.TEXT] BODY.PEEK[]
5-16
OL-22840-05
Chapter 5
BODY.PEEK[#] BODY.PEEK[TEXT] BODY.PEEK[#.TEXT] RFC822 RFC822.TEXT
HEADERIf the bytes cannot be classified as BODY, then they are classified as HEADER if a fetch request or response is encountered for one of the following specifications (including any appended <> subset variants):
BODY[HEADER] BODY[#.HEADER] BODY.PEEK[HEADER] BODY.PEEK[#.HEADER] RFC822.HEADER
OTHERIf request or response cannot be classified as BODY or HEADER, then it is classified as OTHER. OTHER examples include:
SYN/FIN/ACK/RST packets that do not contain a payload Non-HEADER or BODY IMAP commands such as 3 select inbox Retransmitted packets Anything else that is not considered BODY or HEADER If the session becomes encrypted or enters PASSTHRU mode, subsequent packets for the
session cannot be parsed and are treated as OTHER.
Note
Any IMAP transaction that is not an OK tagged response (such as 1 OK FETCH COMPLETE) is subject to a prepaid refund. To specify which IMAP bytes are billed for when doing prepaid debits (BODY only, BODY and HEADER only, or BODY and OTHER only), enter the following command in CSG2 service configuration mode:
Command
csg2(config-csg-service)# meter include imap body {header | only | other}
Purpose Specifies which IMAP bytes are billed for by the CSG2 when doing prepaid debits. Because IMAP metering is byte-based, you cannot configure both meter include imap and basis fixed or basis second in the same service. Only basis byte is meaningful with meter include imap.
Excluding MMS from Metering

By default, the CSG2 treats Multimedia Messaging Service (MMS) traffic like any other WAP 1.x traffic and generates prepaid and postpaid WAP statistics reports for it. The content type distinguishes it as MMS traffic. You can disable MMS prepaid billing by performing the following task:
5-17
Chapter 5 Configuring the Quota Reauthorization Threshold
To disable MMS prepaid billing, excluding MMS bytes from the CSG2 usage calculation, enter the following command in CSG2 service configuration mode: Command
csg2(config-csg-service)# meter exclude mms wap
Purpose Excludes bytes for a WAP 1.x Multimedia Messaging Service (MMS) session from the CSG2 usage calculation.
Excluding the Final Service Idle from Metering

The CSG2 enables you to exclude the final service idle from the CSG2 usage calculation duration billing. Excluding the final service idle might result in reduced charging because the next service access occurs after the service idles, rather than occurring before the service idles. You cannot configure both meter exclude svc-idle and basis byte or basis fixed in the same service. Only basis second is meaningful with meter exclude svc-idle. To exclude the final service idle, enter the following command in CSG2 service configuration mode: Command
csg2(config-csg-service)# meter exclude svc-idle
Purpose Excludes the final service idle from the CSG2 usage calculation duration billing.
Configuring the Quota Reauthorization Threshold

You can configure the threshold of available quota that triggers CSG2 service reauthorization. To configure the reauthorization threshold, enter the following command in CSG2 service configuration mode: Command
csg2(config-csg-service)# reauthorization threshold threshold
Purpose Configures the CSG2 reauthorization threshold.
For services configured for fixed-cost billing (basis fixed), the reauthorization trigger is the smaller of the following values:

The threshold configured using the reauthorization threshold command 25% of the last quota grant returned from the quota server
For services configured for volume-based billing (basis byte), the reauthorization trigger is the smaller of the following values:

The threshold configured using the reauthorization threshold command 32 KB or 25% of the last quota grant returned from the quota server, whichever is larger
For services configured for duration-based billing (basis second), the reauthorization trigger is the threshold configured using the reauthorization threshold command.
5-18
OL-22840-05
Chapter 5
Configuring Service Support Configuring the Quota Reauthorization Timeout
Note
The CSG2 can also accept a threshold specified by the quota server in a quota grant to the CSG2. The threshold must appear in each and every quota server response. The quota server threshold, if present, overrides the threshold specified using the reauthorization threshold command.
Configuring the Quota Reauthorization Timeout

After the CSG2 receives a grant of zero quadrans in a Service Authorization Response, the CSG2 waits before it requests quota in a Service Reauthorization Request. You can configure a timer to trigger the service reauthorization. To specify the CSG2 reauthorization timeout, enter the following command in CSG2 service configuration mode: Command
csg2(config-csg-service)# reauthorization timeout [initial initial-timeout] [maximum maximum-timeout]
Purpose Configures the CSG2 reauthorization timeout.
For every quota grant of zero, the reauthorization time doubles, until the maximum timeout is reached. For example, if the initial timeout is set to 30 seconds, and the maximum timeout is set to 250 seconds, the reauthorization times (assuming quota grants of zero) would be:

30 seconds 60 seconds 120 seconds 240 seconds 250 seconds 250 seconds
And so on.
Note
The CSG2 can also accept a timeout specified by the quota server in a quota grant to the CSG2. The timeout must appear in each and every quota server response. The quota server timeout, if present, overrides the timeout specified using the reauthorization timeout command.
Final Unit Indication

The CSG2 can dynamically redirect or terminate a service after using the final quota for the service. The action to be taken is communicated to the CSG2 via Final Unit Indication (FUI) TLVs sent by the GGSN, acting as a GTP quota server. The GGSN sends FUI TLVs in Service Authorization Response and Quota Push Request messages. The FUI TLVS also indicate the action that the CSG2 is to take when the quota is fully consumed:
REDIRECTThe CSG2 is to redirect the session to a dynamic URL provided by the GGSN. If the GGSN does not provide a dynamic URL, the CSG2 handles the FUI action as TERMINATE.
5-19
Chapter 5 Enabling a Refund Policy for a Service
The CSG2 supports dynamic redirection for HTTP, Session Initiation Protocol (SIP), and wireless application protocol (WAP) URLs. The CSG2 does not support Layer 3 redirection to an Internet Protocol version 4 (IPv4) or Internet Protocol version 6 (IPv6) address. The CSG2 does not support a GTP' TLV equivalent of the RESTRICTION_FILTER_RULE AVP.

TERMINATEThe CSG2 is to terminate the service by sending a Service Stop message. The CSG2 cleans up all traffic sessions associated with the service. RESTRICT_ACCESSThe CSG2 does not support this action, handling it instead as TERMINATE.
If the GGSN does not send a FUI TLV, the CSG2 handles the FUI action as TERMINATE. There are no CSG2 commands required to enable this support.
Enabling a Refund Policy for a Service

The prepaid error reimbursement feature allows the CSG2 to automatically refund quota for failed transactions. If you have configured a refund policy for the CSG2, you can enable that refund policy for use by a prepaid service. For more information about refunding in CSG2, see the Configuring a Refund Policy on the CSG2 section on page 2-32. To enable a refund policy, enter the following command in CSG2 service configuration mode: Command
csg2(config-csg-service)# refund policy-name
Purpose Specifies the refund policy for a CSG2 prepaid service.
Configuring Content Access Control

You can enable the CSG2 to restrict access to specified content, such as a set of sensitive URLs, for a specified class of users, such as users travelling out of the country. Content access control enables the CSG2 to permit or deny access to a restricted content based on RADIUS attributes and VSA subattributes. To control access to a content, you must first specify a name for each RADIUS attribute or VSA subattribute that you want the CSG2 to use as a criterion when making next-hop routing decisions. You can specify up to 1000 names for RADIUS attributes or VSA subattributes. To specify a name for a RADIUS attribute or VSA subattribute, enter the following command in global configuration mode: Command
csg2(config)# ip csg radius attribute-name attribute {radius-attribute-number | vsa {vendor-id | 3gpp}} radius-subattribute-number}
Purpose Specifies a name for a RADIUS attribute or VSA subattribute that is to be used in subsequent CSG2 configuration commands.
Note
You cannot use the no form of this command to delete a name if the name is currently in use in your configuration.
5-20
OL-22840-05
Chapter 5
Configuring Service Support Configuring Content Access Control
After naming a RADIUS attribute or VSA subattribute, you must define at least one user class. The user class specifies match values for the named RADIUS attribute or VSA subattribute. If the match values match the RADIUS attribute and VSA subattribute values for a user, as specified in RADIUS Accounting Start and Update requests, then the user class is a match for that user. You can define up to 1000 user classes. You must specify at least one match value for each user class. You can define up to 64 match values for a given user class. To define a user class, and to specify a user class match value, enter the following commands beginning in global configuration mode: Command
Step 1
csg2(config)# ip csg user class user-class-name
Purpose Defines a user class to be used by the CSG2 when making routing decisions, and enters CSG2 user class configuration mode.
Note
You cannot use the no form of this command to delete a user class if the user class is currently being used in your configuration.
Step 2
csg2(config-csg-user-class)# radius attribute-name {any | integer integer-value | ip [string] ipv4-address | ip [string] acl acl-number | string attribute-string}
Specifies a user class match value for a RADIUS attribute or VSA subattribute.
After defining a user class, you must associate it with one or more services. The user class specification for a service determines whether matching transactions are to be allowed (permit) or dropped (deny) for the service. You can associate up to 64 user classes with each configured service. User classes associated with services are matched in order of priority. The first user class to be matched determines whether transactions are to be allowed (permit) or dropped (deny) for the service. To associate a user class with a CSG2 service, enter the following command in CSG2 service configuration mode: Command
csg2(config-csg-service)# user-class user-class-name {deny | permit} priority priority
Purpose Associates a global user class with a CSG2 service.
5-21
Chapter 5 Configuring Content Access Control
5-22
OL-22840-05
CH A P T E R

The CSG2 Interprocessor Communication (IPC) module provides a communication channel between the CSG2 Control Processor (CP) and Traffic Processors (TPs), and, in a redundant CSG2 deployment, between the TPs on the active CSG2 and their counterparts on the standby CSG2. The CSG2 provides the following features for the IPC module:

Configuring the IPC Keepalive Time, page 6-1 Configuring the IPC Retransmit Time, page 6-1 Configuring the IPC Retry Number, page 6-2 Changing the IPC Crash Dump Setting, page 6-2
Configuring the IPC Keepalive Time

By default, the CSG2 sends keepalive messages to the IPC module once every 60 seconds. That setting is sufficient in most environments, but the CSG2 also allows you to change the time between keepalive messages, if necessary.
Note
We recommend that you change the keepalive time interval only when directed to do so by Cisco Technical Assistance Center (TAC) engineers. In most environments, the default value is the most appropriate setting. To change the keepalive timer for the IPC module, enter the following command in global configuration mode:
Command
csg2(config)# ip csg ipc keepalive number-of-seconds
Purpose Defines the IPC keepalive time interval for the CSG2.
Configuring the IPC Retransmit Time

By default, the CSG2 retransmits packets to an IPC module once every four seconds. That setting is sufficient in most environments, but the CSG2 also allows you to change the time between retransmits, if necessary.
6-1
Chapter 6 Configuring the IPC Retry Number
Note
We recommend that you change the retransmit time interval only when directed to do so by Cisco Technical Assistance Center (TAC) engineers. In most environments, the default value is the most appropriate setting. To change the IPC retransmit time interval for the CSG2, enter the following command in global configuration mode:
Command
csg2(config)# ip csg ipc retransmit number-of-seconds
Purpose Defines the IPC retransmit time interval for the CSG2.
Configuring the IPC Retry Number

By default, the CSG2 retries communication with an IPC module three times before determining that the link has failed. That setting is sufficient in most environments, but the CSG2 also allows you to change the number of retries, if necessary.
Note
We recommend that you change the number of retries allowed only when directed to do so by Cisco Technical Assistance Center (TAC) engineers. In most environments, the default value is the most appropriate setting. To change the maximum number of IPC retries allowed before the CSG2 determines that the link has failed, enter the following command in global configuration mode:
Command
csg2(config)# ip csg ipc retries number-of-retries
Purpose Defines the maximum number of IPC retries allowed before the CSG2 determines that the link has failed.
Changing the IPC Crash Dump Setting

The CSG2 enables you to define the action to be taken by the CSG2 if an IPC link fails:

Never generate a crash dump. This is the default setting. Wait a specified length of time, then generate a crash dump.
The default setting, to never generate a crash dump, is sufficient in most environments, but the CSG2 also allows you to change the crash dump setting, if necessary.
Note
We recommend that you change the crash dump setting only when directed to do so by Cisco Technical Assistance Center (TAC) engineers. In most environments, the default value is the most appropriate setting.
6-2
OL-22840-05
Chapter 6
Configuring IPC Support Changing the IPC Crash Dump Setting
To define the action to be taken by the CSG2 if an IPC link fails, enter the following command in global configuration mode: Command
csg2(config)# ip csg ipc crashdump [never | tolerance [number of seconds]]
Purpose Defines the action to be taken by the CSG2 if an IPC link fails,.
6-3
Chapter 6 Changing the IPC Crash Dump Setting
6-4
OL-22840-05
CH A P T E R
Configuring PSD Support

The CSG2 supports the Cisco Persistent Storage Device (PSD) Module Software Release 2.0 or later. The PSD provides persistent storage capabilities to the CSG2, and allows the CSG2 to store data on the PSDs internal hard drive. Under normal conditions, the CSG2 sends call detail records (CDRs) to the Billing Mediation Agents (BMAs). If for any reason those BMAs cannot be reached, CDRs are sent to the PSD for safekeeping until contact is reestablished with the BMAs. When contact is reestablished, the CSG2 retrieves the CDRs from the PSD and forwards them to the BMAs.
Note
Instead of using the PSD as backup storage, the CSG2 can use the Storage Area Network (SAN) connected to the Internet Small Computer Systems Interface (iSCSI). For more information, see the Configuring iSCSI Support section on page 8-1. The CSG2 supports only one type of backup device, either a PSD or an iSCSI device. The PSD and iSCSI features can coexist, but only one can be enabled at a time. The CSG2 does not support IPv6 or dual-stack addresses for the PSD.
Storage
Under normal conditions, the PSD provides standby capabilities when necessaryfor example, during network outages. The PSD stores the payload from the packet in a queue, and is unaware of the content or format of that data, so that the data can be retrieved exactly as it was sent.
Retrieval
Once the CSG2 determines that the regular data server is again reachable (in this case, the BMA), it retrieves the stored data from the PSD. The data is returned to the CSG2 in the same order and form as it was deposited. The CSG2 is responsible for maintaining order, if necessary, or of mixing retrieved data with incoming live records. Once the CSG2 acknowledges to the PSD that it has successfully sent the data to the data server (the BMA), the PSD deletes that data. The PSD stores the data until it receives this acknowledgement. The CSG2 provides the following features for the Cisco Persistent Storage Device (PSD):

Configuring the PSD Local Port, page 7-2 Configuring the PSD, page 7-2 Configuring the PSD Packet Drain Settings, page 7-2 Configuring the PSD Keepalive Time, page 7-3
7-1
Chapter 7 Configuring the PSD Local Port
Configuring the PSD GTP Message Buffer, page 7-3 Configuring the PSD Retransmit Time, page 7-4 Configuring the PSD Retry Number, page 7-4 Configuring the PSD Window Size, page 7-5
Configuring the PSD Local Port

The first step when configuring CSG2 support for the PSD is to configure the local port on which the CSG2 is to communicate with the PSD. To configure a local port for the PSD, enter the following command in global configuration mode: Command
csg2(config)# ip csg psd local-port port-number
Purpose Configures the local port on which the CSG2 communicates with the PSD. The PSD local port number must be different from the BMA local port number and from the quota server local port number (configured with the ip csg bma local-port command and the ip csg quota-server local-port command, respectively).
Configuring the PSD

You can configure one and only one PSD for each CSG2. If you have enabled interface awareness, you can also associate a VLANs Virtual Routing and Forwarding (VRF) table name with the PSD. To configure a PSD, enter the following command in global configuration mode: Command
csg2(config)# ip csg psd vrf vrf-name] ipv4-address port-number
Purpose Configures the PSD.

Note
Configuring the PSD Packet Drain Settings

When the BMA becomes active, the CSG2 begins draining packets from the PSD. By default, the CSG2 limits the rate at which GTP messages are read from the PSD to 500 packets/second. However, you can change that rate. For example, you can specify an interval of 2 seconds to yield a rate of 250 packets/second (500 packets/2 seconds).
7-2
OL-22840-05
Chapter 7
Configuring PSD Support Configuring the PSD Keepalive Time
To configure a delay before the CSG2 begins draining packets, enter the following command in global configuration mode: Command
csg2(config)# ip csg psd drain delay number-of-seconds
Purpose Defines the delay interval, in seconds, before draining packets from the PSD when the BMA becomes active.
You can also change the rate at which GTP messages are read from the PSD by changing the number of packets to be drained per interval. For example, specifying that 1000 packets are to be drained per interval yields a rate of 1000 packets/second (1000 packets/1 second). To configure the number of packets to be drained from the PSD, enter the following command in global configuration mode: Command
csg2(config)# ip csg psd drain packet number-of-packets
Purpose Defines the number of packets to be drained from the PSD per drain delay interval when the BMA becomes active.
Configuring the PSD Keepalive Time

By default, the CSG2 sends keepalive messages to the PSD once every 60 seconds. That setting is sufficient in most environments, but the CSG2 also allows you to change the time between keepalive messages, if necessary.
Note
We recommend that you change the keepalive time interval only when directed to do so by Cisco Technical Assistance Center (TAC) engineers. In most environments, the default value is the most appropriate setting. To change the keepalive timer for the PSD, enter the following command in global configuration mode:
Command
csg2(config)# ip csg psd keepalive number-of-seconds
Purpose Defines the PSD keepalive time interval for the CSG2.
Configuring the PSD GTP Message Buffer

The CSG2 can buffer general packet radio service (GPRS) tunneling protocol prime (GTP) messages for the BMA. For the PSD, the CSG2 can buffer additional GTP messages, beyond the size of the BMA GTP message queue. The default settings are sufficient in most environments, but the CSG2 also allows you to change the PSD GTP message buffer, if necessary.
Note
We recommend that you change the number of GTP messages that can be buffered only when directed to do so by Cisco Technical Assistance Center (TAC) engineers. In most environments, the default value is the most appropriate setting.
7-3
Chapter 7 Configuring the PSD Retransmit Time
To change the maximum number of GTP messages, beyond the size of the BMA GTP message queue, that the CSG2 can buffer for the PSD, enter the following command in global configuration mode: Command
csg2(config)# ip csg psd margin number
Purpose Specifies the maximum number of GTP messages, beyond the size of the BMA message queue, that the CSG2 can buffer for the PSD.
Configuring the PSD Retransmit Time

By default, the CSG2 retransmits packets to the PSD once every four seconds. That setting is sufficient in most environments, but the CSG2 also allows you to change the time between retransmits, if necessary.
Note
We recommend that you change the retransmit time interval only when directed to do so by Cisco Technical Assistance Center (TAC) engineers. In most environments, the default value is the most appropriate setting. To change the PSD retransmit time interval for the CSG2, enter the following command in global configuration mode:
Command
csg2(config)# ip csg psd retransmit number-of-seconds
Purpose Defines the PSD retransmit time interval for the CSG2.
Configuring the PSD Retry Number

By default, the CSG2 retries communication with the PSD three times before determining that the link has failed. That setting is sufficient in most environments, but the CSG2 also allows you to change the number of retries, if necessary.
Note
We recommend that you change the number of retries allowed only when directed to do so by Cisco Technical Assistance Center (TAC) engineers. In most environments, the default value is the most appropriate setting. To change the maximum number of PSD retries allowed before the CSG2 determines that the link has failed, enter the following command in global configuration mode:
Command
csg2(config)# ip csg psd retries number-of-retries
Purpose Defines the maximum number of PSD retries allowed before the CSG2 determines that the link has failed.
7-4
OL-22840-05
Chapter 7
Configuring PSD Support Configuring the PSD Window Size
Configuring the PSD Window Size

By default, the CSG2 sets the maximum PSD transmit window size to 128 packets, and sets the minimum PSD transmit window size automatically. Those settings are sufficient in most environments, but the CSG2 also allows you to change the maximum and minimum PSD transmit window sizes, if necessary.
Note
We recommend that you change the transmit window size only when directed to do so by Cisco Technical Assistance Center (TAC) engineers. In most environments, the default value is the most appropriate setting. To define the PSD transmit window size for the CSG2, enter the following command in global configuration mode:
Command
csg2(config)# ip csg psd window {max window-size | min window-size | min auto}
Purpose Defines the PSD transmit window size for the CSG2.
7-5
Chapter 7 Configuring the PSD Window Size
7-6
OL-22840-05
CH A P T E R
Configuring iSCSI Support

Under normal conditions, the CSG2 sends call detail records (CDRs) to the Billing Mediation Agent (BMA). If for any reason those BMAs cannot be reached, CDRs are sent to the Cisco Persistent Storage Device (PSD) for safekeeping until contact is reestablished with the BMAs. When contact is reestablished, the CSG2 retrieves the CDRs from the PSD and forwards them to the BMAs. For more information, see the Configuring PSD Support section on page 7-1. Instead of using the PSD as backup storage, the CSG2 can use the Storage Area Network (SAN) connected to the Internet Small Computer Systems Interface (iSCSI) to store CDRs until the BMAs can be reached. This chapter describes that function.
Note
The CSG2 supports only one type of backup device, either a PSD or an iSCSI device. The PSD and iSCSI features can coexist, but only one can be enabled at a time. The CSG2 provides the following features for the SAN connected to the iSCSI:

iSCSI Overview, page 8-1 Configuring an iSCSI Target Interface Profile on the CSG2, page 8-2 Associating an iSCSI Target Interface Profile with the CSG2, page 8-3 Configuring the iSCSI Packet Drain Settings, page 8-4 Verifying the iSCSI Session, page 8-4
iSCSI Overview
The iSCSI transport protocol operates over TCP/IP, enabling mobile operators and service providers to use their SAN connected to an iSCSI to save CDRs. SAN technology, which enables customers to build scalable storage solutions, is comprised of the following primary elements:
SCSIAn interface standard which enables multiple devices to be installed on a system, attached to cable to form a chain of devices. Each device is assigned a unique ID, which is expressed as a number, that identifies that device on the bus. SCSI IDs can be broken into Logical Unit Numbers (LUNs), enabling a number of devices to share a single SCSI ID. Devices from which I/O requests originate are called initiators, and devices from which responses originate are called targets.
8-1
Chapter 8 Configuring an iSCSI Target Interface Profile on the CSG2
SANTechnology that involves moving network storage to a separate network of its own. Disk, tape, and optical storage can then be attached to the storage network that is based on a fabric of switches and hubs that connects storage devices to a heterogeneous set of servers. A SAN system provides block-level access to data residing on shared storage arrays through dedicated storage networks. Under normal conditions, the SAN connected to the iSCSI provides standby capabilities when necessaryfor example, during network outages. The SAN stores the payload from the packet in a queue, and is unaware of the content or format of that data, so that the data can be retrieved exactly as it was sent. Once the CSG2 determines that the regular data server is again reachable (in this case, the BMA), it retrieves the stored data from the SAN. The data is returned to the CSG2 in the same order and form as it was deposited. The CSG2 is responsible for maintaining order, if necessary, or of mixing retrieved data with incoming live records. Once the CSG2 acknowledges to the SAN that it has successfully sent the data to the data server (the BMA), the SAN deletes that data. The SAN stores the data until it receives this acknowledgement.
iSCSITransport protocol that maps SCSI requests and responses over TCP and provides block-level data transfer between the SCSI initiator (such as the CSG2), and the target (the storage device on the SAN). The initiator sends I/O requests and the target sends I/O responses. Storage is not directly connected to network clients. Storage is not directly connected to servers. Storage devices are interconnected. Multiple servers can share multiple storage devices.
A SAN topology is distinguished by the following features:

When configuring iSCSI CDR backup and storage on the CSG2, keep the following considerations in mind:

Currently, iSCSI targets cannot be dynamically discovered. The number of TCP connections per iSCSI session is limited to one. The iSCSI target device should be preformatted. Each LUN must have only one FAT32 partition. Maximum of size of a LUN must not be more than 2TB, which is the maximum disk size supported by a FAT32 file system.
Configuring an iSCSI Target Interface Profile on the CSG2

In the SCSI environment, the CSG2 functions as an iSCSI initiator. To enable the CSG2 to use the SAN for CDR backup storage, you must first configure an iSCSI target interface profile on the CSG2 that includes the name and IPv4 address of the target, and the TCP port on which to listen for iSCSI traffic.
8-2
OL-22840-05
Chapter 8
Configuring iSCSI Support Associating an iSCSI Target Interface Profile with the CSG2
To configure the iSCSI target interface profile on the CSG2, complete the following tasks, beginning in global configuration mode: Command
Step 1
Router(config)# ip iscsi target-profile target-profile-name
Purpose Creates an iSCSI profile for an iSCSI target on the CSG2, and enters iSCSI configuration mode
Note
You can configure only one iSCSI target profile on a given CSG2.
Step 2 Step 3 Step 4 Step 5 Step 6
Router(config-iscsi)# name target-name
Specifies the name of an iSCSI target in the target profile on the CSG2 Specifies the IPv4 address of an iSCSI target in the target interface profile on the CSG2. Specifies the number of the port on which to listen for iSCSI traffic in the iSCSI target interface profile on the CSG2. Specifies the session timeout for an iSCSI target in the target interface profile on the CSG2. Specifies the portal group tag for an iSCSI target in the target interface profile on the CSG2.
Router(config-iscsi)# ip ipv4-address
Router(config-iscsi)# port port-number
Router(config-iscsi)# session-timeout
Router(config-iscsi)# target-portal
Associating an iSCSI Target Interface Profile with the CSG2

After you have configured the iSCSI target interface profile on the CSG2, you must configure the CSG2 to use the iSCSI for CDR storage when no BMA is available. To do so, you must associate the iSCSI target interface profile with the CSG2. This enables the CSG2 to read from and write to the remote SAN, using the iSCSI. To associate an iSCSI target interface profile with the CSG2, enter the following command in global configuration mode: Command
csg2(config)# ip csg iscsi profile target-profile-name
Purpose Specifies the iSCSI target interface profile to be used as backup storage for the CSG2.
Note
You can associate only one iSCSI target interface profile at a time with a given CSG2. The profile name specified must be the same as the one configured using the ip iscsi target-profile command.
8-3
Chapter 8 Configuring the iSCSI Packet Drain Settings
Configuring the iSCSI Packet Drain Settings

When the BMA becomes active, the CSG2 begins draining CDRs from the SAN. By default, the CSG2 limits the rate at which GTP messages are read from the SAN to 167 packets/second. However, you can change that rate. For example, you can specify an interval of 2 seconds to yield a rate of 250 packets/second (500 packets/2 seconds). To configure a delay before the CSG2 begins draining packets, enter the following command in global configuration mode: Command
csg2(config)# ip csg iscsi drain delay number-of-seconds
Purpose Defines the delay interval, in seconds, before draining packets from the iSCSI when the BMA becomes active.
You can also change the rate at which GTP messages are read from the SAN by changing the number of packets to be drained per interval. For example, specifying that 600 packets are to be drained per interval yields a rate of 200 packets/second (600 packets/3 seconds). To configure the number of packets to be drained from the iSCSI, enter the following command in global configuration mode: Command
csg2(config)# ip csg iscsi drain packet number-of-packets
Purpose Defines the number of packets to be drained from the iSCSI per drain delay interval when the BMA becomes active.
Verifying the iSCSI Session

To verify that the iSCSI session is up, use the following command in privileged EXEC mode: Command
Router# show ip iscsi session
Purpose Displays the status of iSCSI session.
8-4
OL-22840-05
CH A P T E R
Configuring RADIUS Support

RADIUS is a distributed client/server system that secures networks against unauthorized access. In the Cisco implementation, RADIUS clients run on Cisco routers and send authentication requests to a central RADIUS server that contains all subscriber authentication and network service access information. The RADIUS client and server retrieve subscriber correlation information (the IP address, the MSISDN, the User-Name, and the Billing Plan) for prepaid subscribers. The CSG2 acts as a RADIUS proxy or RADIUS endpoint to retrieve the subscriber correlation information. In addition, the CSG2 can report RADIUS attributes when it communicates with the BMA and quota servers. Figure 9-1 illustrates the placement of the CSG2 as a RADIUS Accounting proxy or monitor in the RADIUS Accounting and data flows.
Figure 9-1 RADIUS Accounting and Data FlowsRADIUS Accounting Proxy or Monitor
RADIUS Accounting flow CSG2 Data flow AAA
Best when running CSG2 in stateful failover mode
Figure 9-2 illustrates the placement of the CSG2 as a RADIUS Accounting endpoint plus Access Registrar-Identity Cache Engine (AR-ICE) in the RADIUS Accounting and data flows.
201836
9-1
Chapter 9 Configuring RADIUS Proxy
Figure 9-2
RADIUS Accounting and Data FlowsRADIUS Accounting Endpoint Plus AR-ICE
AAA
RADIUS Accounting flow AR-ICE
XML CSG2
Data flow RADIUS Accounting is replicated by ICE CSG2 serves as an endpoint for the RADIUS Accounting ICE caches the RADIUS Accounting CSG2 might query for username via XML if User Table entry is missing Recommended when not running CSG2 in stateful failover mode
The CSG2 provides the following RADIUS features:

Configuring RADIUS Proxy, page 9-2 Configuring RADIUS Endpoint, page 9-3 Configuring RADIUS Handoff, page 9-4 Configuring RADIUS Packet of Disconnect, page 9-4 Configuring RADIUS Change of Authorization, page 9-6 Configuring RADIUS Monitor, page 9-6 RADIUS Attributes and VSA Subattributes, page 9-7 Enabling RADIUS Roaming Service Control, page 9-11 Enabling RADIUS Geo-Redundancy, page 9-12 Retrieving the Billing Plan ID from RADIUS, page 9-12 RADIUS Subscriber Cleanup, page 9-13 RADIUS Error Acknowledgment, page 9-14 RADIUS Correlation Processing, page 9-15
Configuring RADIUS Proxy

The CSG2 can act as a RADIUS proxy, forwarding all of the RADIUS Accounting messages it receives to a configured RADIUS server. When the RADIUS server acknowledges a message with an ACK, the CSG2 forwards the ACK to the client. RADIUS proxy supports both RADIUS Access and RADIUS Accounting. The CSG2 RADIUS proxy function allows operation with clients that use many port numbers. The RADIUS client sends messages to the configured CSG2 (virtual) IP address. The CSG2 accepts messages for all ports on the configured IP address. You must configure a RADIUS proxy IP address for the CSG2 to use when it forwards a RADIUS message to the server.
9-2
201837
OL-22840-05
Chapter 9
Configuring RADIUS Support Configuring RADIUS Endpoint
You can also configure an optional RADIUS key.

If you configure a RADIUS key, the CSG2 parses and acts on a message only if the RADIUS Authenticator is correct. If you do not configure a RADIUS key, the CSG2 always parses and forwards every message.
If you have enabled interface awareness, you can also associate a VLANs Virtual Routing and Forwarding (VRF) table name with a particular RADIUS proxy. You can specify up to 1024 RADIUS proxies. To specify that the CSG2 is a proxy for RADIUS messages, enter the following command in global configuration mode: Command
csg2(config)# ip csg radius proxy [vrf csg-vrf-name] csg-address [vrf server-vrf-name] server-address csg-source-address [key [encrypt] secret-string] [vrf sub-vrf-name]
Purpose Specifies that the CSG2 is a proxy for RADIUS messages.

Note
Note
If you specify the ip csg entries user profile radius remove command, you might also need to configure a key. For Enhanced RADIUS Proxy, in order for the CSG2 to act on the optional Quota-Server TLV in a RADIUS Accounting Start message, the referenced quota server must be manually configured prior to receiving the RADIUS Accounting Start message that contains the TLV. If the CSG2 runs out of RADIUS proxy ports, it might begin dropping RADIUS requests from clients. To avoid this problem, the CSG2 reuses depleted RADIUS proxy ports. By default, the CSG2 can reassign a depleted port after 30 seconds. To set a different timeout, enter the following command in global configuration mode.
Command
csg2(config)# ip csg radius proxy timeout timeout
Purpose Specifies the interval that the CSG2 must wait before assigning a depleted RADIUS proxy port to a new RADIUS client.
Configuring RADIUS Endpoint

The CSG2 RADIUS features require that you configure the Network Access Server (NAS) to direct RADIUS messages to the CSG2 IP address (or to the alias address if this is a redundant configuration). You must also configure the NAS to the specific port number for the CSG2. You can also configure an optional RADIUS key.

If you configure a RADIUS key, the CSG2 parses and acts on a message only if the RADIUS Authenticator is correct. If you do not configure a RADIUS key, the CSG2 always parses every message.
If you have enabled interface awareness, you can also associate a VLANs Virtual Routing and Forwarding (VRF) table name with a particular RADIUS endpoint.
9-3
Chapter 9 Configuring RADIUS Handoff
You can specify up to 2048 RADIUS endpoints. To configure the CSG2 as a RADIUS Accounting endpoint, enter the following command in global configuration mode: Command
csg2(config)# ip csg radius endpoint [vrf csg-vrf-name] csg-address key [encrypt] secret-string [vrf sub-vrf-name]
Purpose Identifies the CSG2 as an endpoint for RADIUS Accounting messages.

Note
If you want the CSG2 RADIUS endpoint IP address to be a member of a CSG2 interface subnet, you must configure the CSG2 IP address as follows:

In non-redundant configurations, you must configure the CSG2 IP address as a secondary IP address configured on the appropriate interface. In redundant configurations, you must configure the CSG2 IP address as a standby secondary IP address on the appropriate interface.
Configuring RADIUS Handoff

In networks that do not use Cisco Home Agents, the CSG2s RADIUS handoff feature can manage handoffs for roaming subscribers. When RADIUS handoff is configured, and a RADIUS Accounting Stop is received, the CSG2 starts a handoff timer instead of immediately deleting the CSG2 User Table entry for the roaming subscriber.
When a handoff occurs, the CSG2 detects a RADIUS Accounting Start message for the same subscriber with a different network address server (NAS) IP address. The CSG2 then uses the existing User Table entry for the subscriber, to preserve the subscriber information, and turns off the timer. If the handoff timer expires before the CSG2 detects a RADIUS Accounting Start message for the subscriber, the CSG2 assumes a handoff did not occur and deletes the User Table entry for the subscriber. In the event of a failover, all handoff timers are restarted.
To configure RADIUS handoff support, enter the following command in global configuration mode: Command
csg2(config)# ip csg radius handoff duration
Purpose Configures the CSG2 RADIUS handoff timer.
Configuring RADIUS Packet of Disconnect

The quota server can use the RADIUS Packet of Disconnect (PoD) feature to instruct the CSG2 to disconnect a subscriber. The CSG2 sends a Disconnect-Request to the NAS, identifying the subscriber, and the NAS responds with a Disconnect_ACK (positive acknowledgement) or Disconnect_NAK (negative acknowledgement).
9-4
OL-22840-05
Chapter 9
Configuring RADIUS Support Configuring RADIUS Packet of Disconnect
By using one of the following methods, the quota server instructs the CSG2 to disconnect a subscriber:

The quota server can send the UserDisconnectRequest message to the CSG2. This message uses the UserIndex TLV to identify the subscriber to be disconnected. The quota server can use Action Code 4 in the Action TLV in one of the following requests and responses:
The Service Authorization Response (indicating that the CSG2 will send the PoD message when
the quota runs out)

The Service Stop Request (indicating that the CSG2 will send the PoD message immediately) The User Profile Response (indicating that the CSG2 will send the PoD message immediately)
The CSG2 sends the PoD message to the NAS that is specified by the NAS-IP-Address attribute (4) in the RADIUS Accounting Start. You can also configure an optional RADIUS key. To configure support for RADIUS PoD, enter the following commands in global configuration mode: Command
Step 1
csg2(config)# ip csg radius pod attribute {radius-attribute-number | vsa {vendor-id | 3gpp} radius-subattribute-number}
Purpose Specifies the RADIUS attributes and vendor-specific attribute (VSA) subattributes to be copied from the RADIUS Start message and sent to the Network Access Server (NAS) in the PoD message. Specifies the NAS port to which the CSG2 is to send the PoD message, and the key to use in calculating the Authenticator.
Note
Step 2
csg2(config)# ip csg radius pod nas [vrf vrf-name] [start-ip end-ip] port key [encrypt secret-string]
Step 3
csg2(config)# ip csg radius pod timeout timeout retransmit retransmit
Specifies the number of times to retry the RADIUS PoD message if it is not acknowledged by means of an ACK message, and the interval between retransmissions.
The following sample configuration specifies the following Packet of Disconnect (PoD) characteristics:

The RADIUS attributes to be copied from the RADIUS Start message and sent to the NAS in the PoD message The NAS port to which the CSG2 is to send the PoD message, and the key to use in calculating the Authenticator The number of times to retry the RADIUS PoD message if it is not acknowledged, and the interval between retries
Here is a sample configuration for RADIUS PoD:

ip ip ip ip ip ip csg csg csg csg csg csg radius radius radius radius radius radius userid User-Name pod attribute 44 pod nas 1.1.1.0 1.1.1.255 1700 key secret pod nas 1701 key password pod timeout 30 retransmits 5 proxy 1.2.3.4 5.6.7.8 key secret
9-5
Chapter 9 Configuring RADIUS Change of Authorization
Configuring RADIUS Change of Authorization

In a Cisco eGGSN deployment, the CSG2 can use a RADIUS Change of Authorization (CoA) Request to change the authorization of a Gx-enabled subscriber. The CSG2 sends a CoA-Request to the NAS, identifying the session, and the NAS responds with a CoA_ACK (positive acknowledgement) or CoA_NAK (negative acknowledgement). The CSG2 sends the CoA message to the NAS that is specified by the NAS-IP-Address attribute (4) in the RADIUS Accounting Start. You can also configure an optional RADIUS key. To configure support for RADIUS CoA, enter the following commands in global configuration mode: Command
Step 1
csg2(config)# ip csg radius coa nas [vrf vrf-name] [start-ip end-ip] port key [encrypt] secret-string
Purpose Specifies the NAS port to which the CSG2 is to send the CoA message, and the key to use in calculating the Authenticator.
Note
Step 2
csg2(config)# ip csg radius coa timeout timeout retransmit retransmit
Specifies the number of times to retry the RADIUS CoA message if it is not acknowledged by means of an ACK message, and the interval between retransmissions.
Configuring RADIUS Monitor

RADIUS monitor provides a way to insert the CSG2 into the RADIUS flow without changing the authentication, authorization, and accounting (AAA) or Network Access Server (NAS) addresses in the network. The CSG2 monitors the traffic between the RADIUS client and the RADIUS server, and watches for RADIUS messages that match the configured rule. You must configure the IP address of the RADIUS server. You can also configure an optional RADIUS key. To configure RADIUS monitor support, enter the following command in global configuration mode: Command
Router(config)# ip csg radius monitor [vrf csg-vrf-name] server-address server-port [key [encrypt] secret-string] [vrf sub-vrf-name]
Purpose Specifies that the CSG2 is to monitor the RADIUS flows to the specified server.
Note
9-6
OL-22840-05
Chapter 9
Configuring RADIUS Support RADIUS Attributes and VSA Subattributes
To specify that the CSG2 is to monitor the RADIUS flows to the specified Network Access Server (NAS), enter the following command in global configuration mode: Command
Router(config)# ip csg radius monitor nas nas-ipv4-address [vrf csg-vrf-name]
Purpose Specifies that the CSG2 is to monitor the RADIUS flows to the specified Network Access Server (NAS).
Note
Here is a sample configuration for RADIUS monitor:

ip csg radius monitor 1.2.3.4 1813 key NAS_TABLE
RADIUS Attributes and VSA Subattributes


RADIUS Attributes Required for CSG2 User Table, page 9-7 Parsing RADIUS VSA Subattributes for Header Insertion Inclusion and Exclusion, page 9-8 Specifying Binary RADIUS Attributes and VSA Subattributes, page 9-8 Deleting Entries from the CSG2 User Table, page 9-8 Reporting RADIUS Attributes and VSA Subattributes, page 9-9
RADIUS Attributes Required for CSG2 User Table

The User Table identifies all subscribers known to the CSG2. The table is populated from the contents of RADIUS Accounting Start messages, or from the user database, if either feature is enabled in your configuration. The following RADIUS attributes must be in the RADIUS Accounting Start in order for the CSG2 to build an entry for a subscriber in the User Table:

8 (Framed-IP-Address) Either 4 (NAS-IP-Address) or 32 (NAS-Identifier) Either 1 (User-Name) or 31 (Calling-Station-Id), as configured Subattribute value csg:quota_server=ip:port includes the quota server IP address and port in a RADIUS Start Accounting Message. You must manually configure the quota server referenced by this subattribute in order for the CSG2 to act on this VSA. If the quota server is not configured, the CSG2 creates a null entry in the User Table for the quota server. The user specified by the RADIUS message uses the quota server in the VSA. Subattribute value csg:downlink_nexthop=ip includes the downlink next-hop IP address in a RADIUS Start Accounting Message. The downlink next-hop IP address is the address to which all downlink traffic is sent for a given user IP address, plus table pairing. If this VSA is not present, traffic is routed based on the routing tables of the CSG2.
The CSG RADIUS interface recognizes the following Cisco-specific VSAs:
9-7
Chapter 9 RADIUS Attributes and VSA Subattributes
When the CSG2 receives the RADIUS Access-Accept with Billing Plan ID included, it caches the information. The cached information is identified by user ID (either RADIUS Attribute 1 or RADIUS Attribute 31, as configured). When the CSG2 receives the RADIUS Accounting Start message with the user ID, the CSG2 builds a User Table entry by using the cached information.
Note
Cached information is not displayed in the output of the show ip csg users command.
Parsing RADIUS VSA Subattributes for Header Insertion Inclusion and Exclusion
The CSG2 can extract a subscribers include or exclude behavior for a class of headers from the RADIUS Access-Accept message or RADIUS Accounting-Request message. To do so, the CSG2 uses the contents of Cisco subattribute 1 VSA (VSA 9 1). The include format is csg:optin_class=class-string and the exclude format is csg:optout_class=class-string.
Specifying Binary RADIUS Attributes and VSA Subattributes

By default, the CSG2 assumes that all RADIUS attributes and VSA subattributes are in human-readable format. However, you can use this command to indicate that a specific RADIUS attribute or VSA subattribute is in binary format. To indicate that a RADIUS attribute or VSA subattribute is in binary format, enter the following command in global configuration mode: Command
csg2(config)# ip csg radius binary attribute {radius-attribute-number | vsa {vendor-id | 3gpp} radius-subattribute-number}
Purpose Indicates that a RADIUS attribute or VSA subattribute is in binary format. You can indicate that up to 256 binary RADIUS attributes or vendor-specific attribute (VSA) subattributes.
Deleting Entries from the CSG2 User Table

For enhanced network connectivity options, such as secondary packet data protocol (PDP) contexts, the NAS sends multiple RADIUS Accounting Stop messages. In the case of secondary PDP contexts, for example, the NAS sends a RADIUS Accounting Stop as each context is terminated. The CSG2 removes the subscriber from the User Table when it receives the final stop, which contains an attribute indicating it is final. The CSG2 support for this functionality allows the specific attribute to be configured. If this function is configured, the CSG2 processes only the RADIUS Accounting Stop that contains the configured attribute. The contents of the specified attribute are not examined.
Note
Retransmitted RADIUS Accounting Stop messages might cause problems when associating traffic with a subscriber. To avoid any problems, do not configure your RADIUS server to reuse an IP address immediately after it is released by a subscriber.
9-8
OL-22840-05
Chapter 9
Configuring RADIUS Support RADIUS Attributes and VSA Subattributes
You can specify the attribute that must be included in the RADIUS Accounting Stop request in order for the CSG2 User Table entry to be deleted. To do so, enter the following command in global configuration mode: Command
csg2(config)# ip csg radius stop purge {radius-attribute-number | vsa} {vendor-id | 3gpp} radius-subattribute-number}
Purpose Specifies the attribute that must be included in the RADIUS Accounting Stop request in order for the CSG2 User Table entry to be deleted.
By default, the CSG2 deletes 1000 User Table entries per second in response to a RADIUS Accounting On or RADIUS Accounting Off message, or in response to the clear ip csg user all command. To specify a different deletion rate, enter the following command in global configuration mode: Command
csg2(config)# ip csg radius on-off purge deletions-per-second
Purpose Specifies the rate at which the CSG2 is to delete CSG2 User Table entries in response to a RADIUS Accounting On or RADIUS Accounting Off message, or in response to the clear ip csg user all command. The actual rate at which the CSG2 deletes User Table entries might be slightly higher or lower than the specified rate.
Reporting RADIUS Attributes and VSA Subattributes

You can specify a set of attributes and VSA subattributes to be extracted from the RADIUS Accounting Start messages for each subscriber. The CSG2 then reports those attributes and subattributes to the Billing Mediation Agent (BMA) and quota server in every call detail record (CDR). The CSG2 can also include the attributes and subattributes in RADIUS PoD messages, if configured to do so. You can use RADIUS attributes and subattributes to determine where a subscriber is connecting to the network, and for correlation purposes. For example, in a gateway general packet radio service (GPRS) environment you can use attributes and subattributes as follows:
NAS-IP-Address (4) identifies the gateway that provides accounting control for the subscriber. Examples of such devices include the gateway general packet radio service (GPRS) support node (GGSN), the Packet Data Serving Node (PDSN), the Home Agent, and the Cisco AS5300 Universal Access Server. SGSN IP (26/10415/6) identifies the Service GPRS Support Node (SGSN) that the subscriber is accessing.CSG2 Acct-session-ID (44) uniquely identifies the session on the NAS and can be used correlate GGSN accounting records.
The CSG2 reports attributes and subattributes in the order in which they appear in the RADIUS message. If there are multiple instances of an attribute, the CSG2 reports all of them. The CSG2 saves and reports attribute and subattribute information for each subscriber. When the CSG2 receives a new RADIUS Accounting Start or RADIUS Interim Accounting Request, it saves the attribute and subattribute information parsed from the new request.
9-9
Chapter 9 RADIUS Attributes and VSA Subattributes
The CSG2 saves only those attributes or subattributes which meet both of the following criteria:

They are present in the new RADIUS Accounting Start or RADIUS Interim Accounting Request. They are configured for reporting at the time the new request arrives at the CSG2.
All previously stored attribute and subattribute information from previous requests is destroyed, even if the new RADIUS Accounting Start or RADIUS Interim Accounting Request does not contain all of the attributes and subattributes that were present in the previous request. Only the currently stored attributes are reported in CDRs.
Note
The impact of RADIUS VSA subattribute parsing on CSG2 performance has not been measured. Storage is consumed based on the attributes selected. To configure the list of attributes and subattributes to be copied from the RADIUS Start message and sent to the BMA and quota server, enter the following command in global configuration mode:
Command
csg2(config)# ip csg report radius attribute {radius-attribute-number | vsa} {vendor-id | 3gpp} radius-subattribute-number}
Purpose Specifies the RADIUS attributes and VSA subattributes to be copied from the RADIUS Start message and sent to the BMA in CSG2 CDRs.
The attributes are configured by their standard number, as shown in the following example:
ip ip ip ip csg csg csg csg report report report report radius radius radius radius attribute attribute attribute attribute 3 5 7 44
You can specify as many attributes as you want. If you specify so many attributes that the total message size is greater than a single UDP packet, the CSG2 supports continuation messages. A continuation message includes a correlator, a continuation number (so that messages that are received out of order can be reordered), and an indication of the final message. To specify the list of attributes and subattributes to be copied from the RADIUS Start message and sent to the NAS in the PoD message, see the description of the ip csg radius pod attribute command in the Configuring RADIUS Packet of Disconnect section on page 9-4. If both the reporting of RADIUS attributes and Roaming Service Control are enabled, the CSG2 sends the combined list of attributes in every CDR to the BMA and quota server (but only changes in the Roaming Service Control attributes trigger reauthorization). For example, if the CSG2 is configured to report attributes 1, 3, and 5, and configured to monitor attributes 2, 4, and 6 for Roaming Service Control, then the CSG2 reports attributes 1, 2, 3, 4, 5, and 6 in all CDRs to the BMA and quota server. For more information about Roaming Service Control, see the Enabling RADIUS Roaming Service Control section on page 9-11.
9-10
OL-22840-05
Chapter 9
Configuring RADIUS Support Enabling RADIUS Roaming Service Control
Enabling RADIUS Roaming Service Control

Roaming Service Control, also known as seamless roaming or RADIUS reauthorization, enables the CSG2 to reauthorize prepaid users, instead of ending the users sessions, when a configured list of attributes changes. For both prepaid and postpaid subscribers, a change in the contents of the RADIUS reauthorization attributes results in the generation of a CDR to a BMA.
1. 2. 3. 4.
When you enable Roaming Service Control, you also configure a list of RADIUS attributes and VSA subattributes to be monitored and saved by the CSG2. When the CSG2 receives a RADIUS Start message, it saves the subset of attributes that are in both the configured list and the message. When the CSG2 receives a subsequent RADIUS Start or RADIUS Interim Accounting message, it compares the saved subset of attributes, and their contents, to the attributes in the new message. If any attribute in the saved subset is missing from the list of attributes in the new message, or if there are any new attributes in the message that are not in the saved subset, or if any of the contents of the attributes are different, the CSG2 reauthorizes prepaid users without ending their sessions. If service-level CDR summarization is enabled, the CSG2 sends a Service Usage CDR for each service in the session. Otherwise, if intermediate CDRs are supported for the session, the CSG2 sends an intermediate CDR for each service in the session. However, if you have enabled fixed-format CDRs, the CSG2 does not generate intermediate CDRs during roaming events. The CDR includes:
The Cause TLV, indicating that the CDR was generated due to the receipt of a reauthorization
5.
trigger
The saved subset of attributes from the first RADIUS Start message The list of attributes from the new message
For more information about service-level CDR summarization, see the Enabling Service-Level CDR Summarization section on page 5-9. For more information about intermediate CDRs, see the Intermediate CDRs section on page 1-54. For more information about fixed-format CDRs, see the Configuring Fixed, Variable, or Combined Format CDR Support section on page 2-30. To enable Roaming Service Control, enter the following command in global configuration mode: Command
csg2(config)# ip csg radius reauthorization attribute {radius-attribute-number | vsa} {vendor-id | 3gpp} radius-subattribute-number}
Purpose Defines the RADIUS attributes and VSA subattributes to be monitored by the CSG2, and enables Roaming Service Control.
The attributes are configured by their standard number, as shown in the following example:
ip csg radius reauthorization attribute 14 ip csg radius reauthorization attribute vsa 7777 44 ip csg radius reauthorization attribute 26 7778 4
If both Roaming Service Control and the reporting of RADIUS attributes are enabled, the CSG2 sends the combined list of attributes in every CDR to the BMA and quota server (but only changes in the Roaming Service Control attributes trigger reauthorization). For example, if the CSG2 is configured to
9-11
Chapter 9 Enabling RADIUS Geo-Redundancy
report attributes 1, 3, and 5, and configured to monitor attributes 2, 4, and 6 for Roaming Service Control, then the CSG2 reports attributes 1, 2, 3, 4, 5, and 6 in all CDRs to the BMA and quota server. For more information about the reporting of RADIUS attributes, see the Reporting RADIUS Attributes and VSA Subattributes section on page 9-9.
Enabling RADIUS Geo-Redundancy

In a typical RADIUS proxy configuration, the CSG2 proxies all RADIUS Accounting Requests from the client to the AAA server. In a geographically redundant configuration, the CSGs in both locations might proxy a RADIUS request for the same user to a AAA server. To prevent that occurrence, the CSG2 supports geo-redundancy high availability (HA). Geo-redundancy enables the CSG2 to dynamically determine whether to proxy a given RADIUS Accounting Request to the AAA server. If geo-redundancy is enabled, and if the RADIUS Accounting Request includes the RADIUS VSA csg:geo-update attribute, the CSG2 does not proxy the RADIUS Accounting Request to the AAA server. Instead, the CSG2 returns an ACK to the originator to acknowledge the processing of the RADIUS Accounting Request. You can configure geo-redundancy HA such that the active and standby Home Agents send RADIUS Accounting Start, Stop, and Update requests to their associated CSG2s, replicating the user and billing information. When a failover occurs in such a configuration, the standby Home Agent that takes over the active role directs the user traffic to the correct CSG2 for accounting and forwarding. To enable geo-redundancy for the CSG2, enter the following command in global configuration mode: Command
csg2(config)# ip csg geo-redundancy
Purpose Enables geo-redundancy for the CSG2.
Note
Before enabling geo-redundancy on the CSG2, ensure that the GGSN is configured to support geo-redundancy.
Retrieving the Billing Plan ID from RADIUS

The CSG2 can extract the Billing Plan ID from the RADIUS Access-Accept message or RADIUS Accounting-Request message by using the Cisco subattribute 1 VSA. The format of the VSA is:

Attribute number: 26 (=vendor specific) Vendor ID: 9 (=Cisco) Subattribute: 1 (=Cisco generic) Format: csg:billing_plan= billing_plan_name The billing_plan_name can be null, indicating that the subscriber is a postpaid subscriber. Otherwise, the billing plan name must be sent as an uppercase string to match a configured billing plan on the CSG2.
If the message includes the billing plan, the user ID (RADIUS attribute 1 or 31, as configured) must also be included; otherwise, the CSG2 cannot associate the billing plan with the subscriber.
9-12
OL-22840-05
Chapter 9
Configuring RADIUS Support RADIUS Subscriber Cleanup
If the CSG2 is configured to obtain the billing plan from RADIUS, and the billing plan subattribute is not included in the RADIUS messages, the CSG2 queries the quota server to obtain the attribute (that is, the CSG2 sends a User Profile Request). To configure the CSG2 to obtain the billing plan from RADIUS, the following command in global configuration mode: Command
csg2(config)# ip csg entries user profile radius {remove | pass | timeout timeout}
Purpose Specifies that the CSG2 is to obtain the Cisco vendor-specific attribute (VSA) subattribute 1, which contains the billing plan name, from the RADIUS Access-Accept and RADIUS Accounting-Request messages when generating entries for the CSG2 User Table.
Note
To enable the CSG2 to parse user profile attributes in eGGSN mode, you must configure either the ip csg entries user profile radius pass command or the ip csg entries user profile radius remove command. For more information on eGGSN mode, see the Configuring Gx Support section on page 10-1.
To specify the RADIUS attribute that the CSG2 is to use to extract the user identifier from a RADIUS record, enter the following command in global configuration mode: Command
csg2(config)# ip csg radius userid {1 | 31 | User-Name | Calling-Station-Id}
Purpose Specifies the RADIUS attribute used to extract the user identifier from a RADIUS record.
RADIUS Subscriber Cleanup

A subscribers connectivity attributes might change over time without a RADIUS Accounting Stop message arriving to close down the previous accounting. Instead, it is possible that a new RADIUS Accounting Start message or a RADIUS Interim Accounting message might arrive with the updated information. Some customers might choose to close all of a subscribers services if a significant change has occurred in the subscribers status. Subscriber cleanup enables the CSG2 to delete the subscriber entry as if it had received a Stop, to close all of the subscribers services, and to create a new entry. To clean up the CSG2 User Table entry for a subscriber, enter the following command in global configuration mode: Command
csg2(config)# ip csg radius start restart session-id {radius-attribute-number | vsa} {vendor-id | 3gpp} radius-subattribute-number}
Purpose Deletes an existing CSG2 User Table entry for a specific subscriber, and creates a new entry for that subscriber.
To avoid deleting the subscriber entry because of a retransmission of the RADIUS message, the ip csg radius start restart session-id command specifies an attribute to detect duplicate messages. If the contents of the attribute in the message match the contents of the previous message, the existing entry is not deleted.
9-13
Chapter 9 RADIUS Error Acknowledgment
RADIUS Error Acknowledgment

By default, the CSG2 acknowledges the following RADIUS parse errors:

Invalid RADIUS message or attribute length RADIUS Authenticator does not match what the CSG2 calculates Incorrect RADIUS attribute length User profile information such as billing plan or quota server does not match the CSG2 configuration
You can prevent the CSG2 from acknowledging these errors. To prevent the CSG2 from acknowledging RADIUS parse errors, enter the following command in global configuration mode: Command
csg2(config)# no ip csg radius ack error parse
Purpose Prevents the CSG2 from generating a RADIUS response to a RADIUS Accounting Start Request or a RADIUS Accounting Interim Request when it encounters a RADIUS parse error condition.
Note
You must use the no form of this command, no ip csg radius ack error parse, to prevent the CSG2 from acknowledging these RADIUS parse errors. By default, the CSG2 acknowledges the following user resource errors:

Maximum number of users reached Unable to allocate memory for creating a user entry or for storing RADIUS attribute information (such as report attributes or parsed billing plan information) Unable to communicate user information via inter-processor communication Load manager prevents allocation of a user
You can prevent the CSG2 from acknowledging these errors. To prevent the CSG2 from acknowledging user resource errors, enter the following command in global configuration mode: Command
csg2(config)# no ip csg radius ack error user
Purpose Prevents the CSG2 from generating a RADIUS response to a RADIUS Accounting Start Request or a RADIUS Accounting Interim Request when it encounters a user resource error condition.
Note
You must use the no form of this command, no ip csg radius ack error user, to prevent the CSG2 from acknowledging these user resource errors.
9-14
OL-22840-05
Chapter 9
Configuring RADIUS Support RADIUS Correlation Processing
RADIUS Correlation Processing

A retransmitted RADIUS Stop might cause the CSG2 to remove a subscriber entry from the CSG2 User Table when the entry should not be removed. To avoid this problem, the CSG2 must be able to associate a session correlator from the RADIUS Start message with a subscriber entry in the User Table, and compare that correlator with the correlator in the RADIUS Stop message. If the correlators match, the CSG2 deletes the subscriber entry; otherwise, the CSG2 retains the entry in the User Table. The CSG2 can use the Acct-Session-Id (attribute 44) as the correlator, or it can use the following vendor-specific attribute (VSA) subattribute (attribute 26, Vendor-Id 9, subattribute 1): csg:user_session_correlator=string If both attributes are included in the RADIUS Start or RADIUS Stop message, the CSG2 uses the VSA subattribute. When RADIUS correlation processing is enabled:

If there is no correlator saved in the User Table entry, the CSG2 deletes the entry. If there is a correlator saved in the User Table entry, the CSG2 compares it to the correlator in the RADIUS Stop. If the correlators match, the CSG2 deletes the entry; if they do not match, or if there is no correlator in the RADIUS Stop, the CSG2 retains the entry in the User Table.
To enable RADIUS correlation processing by the CSG2, enter the following command in global configuration mode: Command
csg2(config)# no ip csg radius correlation
Purpose Enables RADIUS correlation processing by the CSG2.
9-15
Chapter 9 RADIUS Correlation Processing
9-16
OL-22840-05
CH A P T E R
10
CSG2 provides policy control via the Gx interface. Gx is a Third Generation Partnership Project (3GPP) Diameter application. In a Gx-enabled network, a Gx reference point is located between a Policy and Charging Rules Function (PCRF) and a Policy and Charging Enforcement Function (PCEF). The Gx reference point can be used for charging control and policy control by applying Attribute Value Pairs (AVPs) relevant to the application. The PCRF acts as a Diameter server and performs the following functions:

It uses the Gx interface to provision PCC rules to, and remove PCC rules from, the PCEF. It handles policy control decisions. It provides network control regarding the service data flow detection, gating, Quality of Service (QoS), and flow-based charging (except credit management) towards the PCEF. It receives session- and media-related information from Application Functions (AFs) and informs the AFs of traffic plane events. It uses the Gx interface to send traffic plane events to the PCRF. It enforces policy, handles flow-based charging, and controls QoS and the handling of user plane traffic. It provides service data flow detection and counting as well as online and offline charging interactions. It can report changes in the status of service data flows. Detect a packet that belongs to a service data flow. Identify the service to which the service data flow contributes. Provide applicable charging parameters and policy control for a service data flow.
The PCEF acts as a Diameter client and performs the following functions:

In a Gx-enabled network, the PCC rules are used to:

PCC rules are dynamically provisioned by the PCRF to the PCEF over the Gx interface. Dynamic PCC rules are dynamically generated in the PCRF. Dynamic PCC rules can be activated, modified, and deactivated at any time.
10-1
Chapter 10
In a Gx-enabled network, the CSG2 acts as a PCEF, either as part of an eGGSN node, with a CSG2 and a GGSN as separate cards in a Cisco 7600 Series Router, or as a stand-alone Gi-node, with interoperability from external GGSNs.
In eGGSN mode, the CSG2 acts as a Gx interface endpoint while the GGSN manages PDP contexts. The CSG2 and the GGSN communicate with each other using the RADIUS protocol. The CSG2 provides basic Gx support with enhancements for per-user Layer 7 rules, policy preloading, and per-user service policies. The GGSN provides GTP, PDP AAA Authentication, and QoS RAN Signaling. To enable the CSG2 to parse user profile attributes in eGGSN mode, you must configure either the ip csg entries user profile radius pass command or the ip csg entries user profile radius remove command.
In Gi-node mode, the stand-alone CSG2 acts as a Gx interface endpoint. Gi-node mode supports all of the same functions as eGGSN mode, with the following exception:
PDP Context QoS Signaling is not supported.
The CSG2 supports both the eGGSN mode and the Gi-node mode in both RADIUS endpoint and RADIUS proxy modes. Figure 10-1 illustrates the placement of the CSG2 in a Gx-enabled network:
Figure 10-1 CSG2 in a Gx-Enabled Network
Application Function Proxy Call Session Control Function V
IP
AAA
Ri
Ri PCRF
Gi
275940
GPRS GGSN CS G2
The CSG2 provides the following Gx features:

Support for the Cisco eGGSN for Cisco GGSN Release 10.0 and the Single IP Feature, page 10-5 Enabling Gx on the CSG2, page 10-3 Configuring a User Profile, page 10-3
10-2
OL-22840-05
Chapter 10
Configuring Gx Support Enabling Gx on the CSG2
Dynamic Redirection, page 10-6 Cisco 7600 LTE Integration, page 10-7 Preloading Policies, page 10-8 Support for Gx TCP Signature Reporting, page 10-11 Dynamic Provisioning of 3GPP Per-User DGRs, page 10-11 Dynamic Provisioning of Cisco Per-User DGRs, page 10-12 Gx Event Triggers, page 10-13 Volume and Duration Triggers, page 10-14 Per-Subscriber Volume and Time Thresholds, page 10-14 Service Flow Detection Triggers, page 10-15 Gx Event Trigger Usage Reporting, page 10-15 Gx Service Groups, page 10-16 Billing Plan Assignment and Modification, page 10-16 PDP Context QoS Signaling, page 10-16 Secondary PDP Context Activation, page 10-17 PCRF-Specified Service-Level and User-Level QoS, page 10-17 PCRF Failure Handling, page 10-17 User Session Continuation After PCRF Timeout, page 10-17 Restrictions for Gx, page 10-18
Note
Gx features in the CSG2 R5 and later require the 2 GB-SAMI option. The CSG2 R5 and later on the 1 GB-SAMI option does not support Gx.
Enabling Gx on the CSG2

To enable Gx support on the CSG2, enter the following command in global configuration mode: Command
csg2(config)# ip csg pcc gx
Purpose Enables Gx on the CSG2.
Configuring a User Profile

To enable Gx support for a CSG2 subscriber, define a user profile and associate that profile with the subscriber. The user profile:

Enables Gx for all associated subscribers. Defines the actions that the CSG2 is to take if a PCRF fails.
10-3
Chapter 10 Configuring a User Profile
Defines the Mobile Policy Control & Charging (MPCC) profile to be used by the CSG2 when sending per-user Credit Control Requests (CCRs) to the PCRF.
To define a user profile, enter the following commands beginning in global configuration mode: Command
Step 1 Step 2
csg2(config)# ip csg user profile profile-name csg2(config-csg-user-profile)# pcc gx
Purpose Defines a user profile to be associated with a CSG2 subscriber, and enters CSG2 user profile configuration mode. Enables Gx for subscribers associated with a CSG2 user profile. If a RADIUS Accounting Request contains a Cisco VSA that specifies the Gx behavior of the subscriber, the RADIUS-specified behavior overrides the Gx behavior specified by the pcc gx command.
Step 3
csg2(config-csg-user-profile)# pcrf failure [continue | terminate]
(Optional) Defines the actions that the CSG2 is to take for a PCC user if the PCRF fails when the user session is activated.

continueCreate the CSG2 User Table entry for the PCC user and forward the RADIUS Accounting Start request. terminateDo not create the CSG2 User Table entry for the PCC user and do not forward the RADIUS Accounting Start request. This is the default setting.
Step 4 Step 5
csg2(config-csg-user-profile)# pcrf profile mpcc-profile-name csg2(config-csg-user-profile)# pcrf timeout [continue | terminate]
(Optional) Defines an MPCC profile to be used by the CSG2 when sending per-user CCRs to the PCRF. (Optional) Defines the actions that the CSG2 is to take for a Policy Control & Charging (PCC) user if the Policy and Charging Rule Function (PCRF) times out.
To associate a user profile with a subscriber, enter the following command in global configuration mode: Command
csg2(config)# ip csg select profile-name {any | radius called-station-id csid-string}
Purpose Associates a CSG2 user profile with a subscriber.
The CSG2 determines that a user is a Gx user in one of the following ways:

The GGSN sends a RADIUS Accounting Start Request or a RADIUS Accounting Interim Request with Cisco vendor-specific attributes (VSAs) that indicate that the user is a Gx user. The CSG2 compares the access point name (APN) name in attribute 30 (Called-Station-Id) of the RADIUS Accounting Start against a configured list of APN names to determine that the user is a Gx user.
10-4
OL-22840-05
Chapter 10
Configuring Gx Support Support for the Cisco eGGSN for Cisco GGSN Release 10.0 and the Single IP Feature
Support for the Cisco eGGSN for Cisco GGSN Release 10.0 and the Single IP Feature
The CSG2 supports the Cisco eGGSN for Cisco GGSN release 10.0. This section includes the following features:

Support for Single IP GGSN, page 10-5 RADIUS VSA Subattributes for Single IP Support, page 10-5 Route Injection, page 10-6
Support for Single IP GGSN

The CSG2 supports GGSN single IP routing in an eGGSN environment. The CSG2 provides the following capabilities as part of its support:

Direct messaging to a GGSN Traffic and Control Processor (TCOP) for RADIUS and GTP interfaces. Prepaid or eG-CDR communication to each GGSN TCOP. The CSG2 can send and receive GTP' Data Records to a TCOP port that differs from the defined port of the eGGSN quota server. The port is communicated to the CSG2 in a RADIUS Accounting Request. GTP' control packets are sent to the configured port on the CSG2 for an eGGSN quota server.
RADIUS VSA Subattributes for Single IP Support

The CSG2 supports the RADIUS VSA subattributes that provide the Change of Authorization (CoA) destination port, the Packet of Disconnect (PoD) destination port, or the eGGSN quota server information (IP address, control port, and data port).
The CSG2 sends the CoA or PoD message to the port received in a RADIUS VSA subattribute. If no RADIUS VSA subattribute contains the port, the CSG2 uses the CoA or PoD Network Access Server (NAS) port (configured with the ip csg radius coa nas or ip csg radius pod nas command in global configuration mode) as the destination port.
The CSG2 sends eGGSN quota server control messages, such as nodealive and echo, to the control port. The CSG2 sends eGGSN quota server data messages, such as eG-CDR or prepaid quota manager messages, to the data port. The eGGSN quota server can be selected as a prepaid quota server on the basis of RADIUS VSA subattribute eggsn_qs_mode. If the eGGSN quota server is selected as a prepaid quota server, it can receive prepaid messages, such as User Authorization and Service Authorization messages.
10-5
Chapter 10 Dynamic Redirection
Single IP routing requires that Cisco-specific VSA subattributes eggsn_qs and eggsn_qs_mode must both be present in the same RADIUS Accounting Start or Update request.
Route Injection
Route injection enables the CSG2 to advertise routes for subscriber IP address pools via the Open Shortest Path First (OSPF) protocol. This allows adjacent routers to dynamically route traffic for a subscriber to the CSG2 that owns the subscriber, instead of utilizing static routing mechanisms such as static IP routes or policy-based routing.
1. 2.
The CSG2 receives the routes to be injected in RADIUS Accounting Start or RADIUS Interim Accounting Request messages. The CSG2 extracts the route injection mask from the RADIUS Access-Accept message or RADIUS Accounting-Request message by using the Cisco subattribute 1 VSA. The format of the VSA is:
Attribute number: 26 (=vendor specific) Vendor ID: 9 (=Cisco) Subattribute: 1 (=Cisco generic) Format: csg:dl_subnet_mask= mask
The mask must be something like 255.255.255.0 or 255.255.0.0. Mask definitions in the following format are not supported: /32, /24, /8.
3. 4.
The CSG2 inserts the mask and an IP prefix into the routing table. The OSPF routing protocol advertises the route to the Supervisor Engine, which in turn determines the flows to be routed back through the CSG2.
Multiple subscribers can use the same route. When all of the subscribers using a given route log off, the CSG2 removes the route from the routing table. To enable route injection for the CSG2, enter the following commands in global configuration mode: Command
csg2(config)# router mobile csg2(config)# ip csg radius route inject
Purpose Enables Mobile IP on the router. Enables the CSG2 to inject routes into the routing table for dynamic IP pools.
Dynamic Redirection
The CSG2 extends the Cisco-Flow-Status AVP to enable PCRF-specified redirection for a charging rule or service. If the PCRF had previously specified a Cisco-Flow-Status of BLOCK for the rule or service, it might instead specify a Cisco-Flow-Status of REDIRECT. The PCRF also includes the grouped Redirect-Server-AVP to specify the Redirect-Server information. The PCRF-specified redirect takes effect immediately, and is not related to the redirect for prepaid charging low-quota situations. The CSG2 supports dynamic redirection for HTTP, Session Initiation Protocol (SIP), and wireless application protocol (WAP) URLs. The CSG2 does not support Layer 3 redirection to an Internet Protocol version 4 (IPv4) or Internet Protocol version 6 (IPv6) address. Mid-stream transactions and protocols other than HTTP, SIP, and WAP are blocked. You cannot use the ip csg redirect command in conjunction with dynamic redirection.
10-6
OL-22840-05
Chapter 10
Configuring Gx Support Cisco 7600 LTE Integration
Cisco 7600 LTE Integration

The CSG2 supports Cisco 7600 Long Term Evolution (LTE) sessions. LTE sessions bind charging rules and QoS to an IP-CAN bearer within an IP-CAN session. The CSG2 supports LTE by integrating and communicating with the Cisco 7600 LTE Packet Data Network Gateway (PGW) Release 1.0 via the RADIUS Accounting and RADIUS CoA messages.

The RADIUS Accounting messages include information for the CSG2 about bearer bindings (how rules are to be associated with bearers). The CoA messages include information such as charging rules and QoS, which the PGW requires to perform bearer binding.
The CSG2 supports Release 8 Evolved Packet System (EPS) bearer QoS. QoS received from the PGW is converted to a QoS-Information AVP for the Gx interface. If the QOS_CHANGE event trigger is armed, and the QoS changes, the CSG2 notifies the PCRF. The Cisco PGW Release 1.0 or later supports IPv4, IPv6, and IPv4/v6 (dual stack). LTE supports:

Changes to 3GPP Release 8 QoS from the PCRF Additions, deletions, and modifications to Traffic Filter Templates (TFTs) from the PCRF A TFT is the set of all packet filters associated with an EPS bearer. An uplink TFT is used by the UE; a downlink TFT is used by the PDN.
LTE does not support Roaming Service Control, also known as seamless roaming or RADIUS reauthorization. The CSG2 supports the following new 3GPP Gx event triggers for Cisco 7600 LTE Integration: Event RAI_CHANGE (12) USER_LOCATION_CHANGE (13) UE_IP_ADDRESS_ALLOCATE (18) UE_IP_ADDRESS_RELEASE (19) DEFAULT_EPS_BEARER_QOS_CHANGE (20) AN_GW_CHANGE (21) SUCCESSFUL_RESOURCE_ALLOCATION (22) RESOURCE_MODIFICATION_REQUEST (23) Trigger Change in the Routing Area Identity (RAI) Change in the user location Allocate an IPv4 address for a dual-stack capable UE Release an IPv4 address for a dual-stack capable UE Change in the default Evolved Packet System (EPS) Bearer QoS Change of serving Access Node Gateway address Resources for a rule have been successfully allocated PCC rules are requested for a resource modification request initiated by the UE
There are no new CSG2 commands required to enable this support. However, Cisco 7600 LTE Integration requires the following configuration:

Gx must be enabled on the CSG2, using the ip csg pcc gx command in global configuration mode. The CSG2 must be configured to obtain the Cisco VSA subattribute 1 from the RADIUS Accounting-Request messages for LTE sessions, using the ip csg entries user profile radius command in global configuration mode.
10-7
Chapter 10 Preloading Policies
Preloading Policies
The CSG2 can preload global billing plans, contents, domain groups, headers, header groups, maps, Quality of Service (QoS) profiles, policies, and services, as necessary, from the PCRF. If configured to do so, the CSG2 preloads policies when it boots up. However, you can also dynamically load new and changed policies at any time, without rebooting the CSG2.
Note
The standby CSG2 must have replicated all preloaded policy information before requesting replicated User Table, session, and service information from the active CSG2. To preload policies for the CSG2 from the PCRF without rebooting, enter the following command in privileged EXEC mode:
Command
csg2# csg start preload
Purpose Begins preloading policies for the CSG2 from the PCRF.
You can also configure a policy preloading retransmission delay and a retransmission number for the CSG2 to use when sending a Policy Preloading Request to the PCRF. To configure a delay and retry number, enter the following command in global configuration mode: Command
csg2(config)# ip csg preload request delay delay-in-seconds retries number-of-retries
Purpose Configures a policy preloading retransmission delay and a retransmission number for the CSG2 to use when sending a Policy Preloading Request to the PCRF. The delay is the number of seconds to wait for a policy preload response (CCA) before sending another policy preload request (CCR) to the PCRF. The number of retries is the number of times to retransmit the message. Preloaded policies are subject to the same requirements and restrictions as policies that are configured via CLI. In general, preloaded CSG2 components cannot reference or be associated with components that are configured via CLI, and vice versa. The following sections list additional considerations to keep in mind when preparing policies for preloading:

Preloaded Billing Plans, page 10-9 Preloaded Contents, page 10-9 Preloaded Domain Groups, page 10-9 Preloaded Headers, page 10-9 Preloaded Header Groups, page 10-10 Preloaded Maps, page 10-10 Preloaded Policies, page 10-10 Preloaded Services, page 10-10
10-8
OL-22840-05
Chapter 10
Configuring Gx Support Preloading Policies
Preloaded Billing Plans

When preparing billing plans for preloading, keep the following considerations in mind:

Only one billing plan (either preloaded or configured via CLI) can be the default billing plan. All services and QoS profiles associated with a preloaded billing plan must also be preloaded. If you associate more than one preloaded service with a given preloaded billing plan, the services must have different content/policy pairs. You cannot associate more than one preloaded service that is configured with activation automatic with a given preloaded billing plan. A preloaded service that is configured with mode prepaid virtual can be associated only with a preloaded billing plan that is configured with mode prepaid. Virtual prepaid mode is supported for preloaded billing plans.
Preloaded Contents
When preparing contents for preloading, keep the following considerations in mind:

All client groups, domain groups, and policies associated with a preloaded content must also be preloaded. All VRFs associated with a preloaded content must be preconfigured via CLI, using the vrf definition command in global configuration mode. If parse protocol wap is configured for a preloaded content, you must also configure the udp keyword on the ip command for that content. You cannot specify just one port with a value of zero on the ip command for a preloaded content. Both the beginning port number and the ending port number must be zero, or neither can be zero. You cannot remove a preloaded content that is currently referenced by a service. You cannot specify duplicate preloaded contents (that is, contents configured with the same options). You cannot configure a preloaded content with an invalid IP address/IP mask combination or an unknown application type.
Preloaded Domain Groups

You cannot configure the same priority for two different domain groups (either preloaded or configured via CLI).
Preloaded Headers
When preparing headers for preloading, keep the following considerations in mind:

You cannot specify duplicate RADIUS attributes or VSA subattributes for a given preloaded header. RADIUS attribute 26 requires the Vsa-Vendor-Id and Vsa-Subattribute-Type Attribute Value Pairs (AVPs). The Vsa-Vendor-Id and Vsa-Subattribute-Type AVPs are valid only for RADIUS attribute 26.
10-9
Chapter 10 Preloading Policies
Preloaded Header Groups

All headers associated with a preloaded header group must also be preloaded.
Preloaded Maps
When preparing maps for preloading, keep the following considerations in mind:

Preloaded header and attribute maps must contain an attribute string. You cannot remove a preloaded map that is currently referenced by a policy. You cannot modify a preloaded map that is referenced by a content that is currently in service.
Preloaded Policies
When preparing policies for preloading, keep the following considerations in mind:

All header groups and maps associated with a preloaded policy must also be preloaded. You cannot remove a preloaded policy that is currently referenced by a content or service. All class maps associated with a preloaded policy must be preconfigured via CLI, using the class-map command in global configuration mode.
Preloaded Services
When preparing services for preloading, keep the following considerations in mind:

All header groups and QoS profiles associated with a preloaded service must also be preloaded. You cannot configure a content/policy pair for a preloaded service if it is already configured for a different service in the same billing plan. A policy must already be configured for a content before configuring the associated content/policy pair. You cannot configure basis byte tcp for RTSP, SIP, or WAP. Therefore, basis byte tcp is mutually exclusive with meter exclude control sip and meter exclude mms wap for preloaded services. You cannot configure basis byte tcp for a preloaded service unless all associated preloaded contents are TCP-only. If you configure basis second for a preloaded service, you must configure all associated content commands with weight 1 (the default setting). If you configure basis second or basis second connect for a preloaded service, you cannot configure the refund command. If you configure basis second connect for a preloaded service, you cannot configure the following commands:
aoc append url aoc confirm aoc enable idle
10-10
OL-22840-05
Chapter 10
Configuring Gx Support Support for Gx TCP Signature Reporting
meter include imap verify confirm verify enable
If you configure meter exclude control sip for a preloaded service, you must also configure basis byte ip, basis fixed, or basis second transaction for the service. If you configure meter exclude mms wap for a preloaded service, you must also configure basis byte ip or basis fixed for the service. If you configure meter exclude pause rtsp or meter exclude svc-idle for a preloaded service, you must also configure basis second for the service. If you configure meter increment, meter initial, or meter minimum for a preloaded service, you must also configure basis second or basis second connect. Dual basis for a preloaded service has the same requirements and restrictions as first basis. The dual basis must be different from the first basis. All refund policies associated with a preloaded content must be preconfigured via CLI, using the ip csg refund command in global configuration mode.
Support for Gx TCP Signature Reporting

The CSG2 supports exporting the IP and TCP headers from a subscriber TCP SYN (or SYN-ACK) packet to a Policy and Charging Rule Function (PCRF) device via the Gx protocol. The PCRF selectively arms a Cisco per-user TCP Signature trigger to request the TCP signature information. The subscriber must be identified as a Gx user to allow this reporting to the PCRF. The PCRF can arm the TCP Signature trigger using a subscriber Credit Control Answer (CCA) or Resource Allocation Request (RAR) message. The CSG2 reports the TCP signature of the next TCP flow in a subscriber Credit Control Request-Update (CCR-Update) message. After the trigger is hit, it is cleared until it is armed again by the PCRF. There are no CSG2 commands required to enable this support.
Dynamic Provisioning of 3GPP Per-User DGRs

The CSG2 uses a 3GPP-compliant PCC architecture to dynamically download 3GPP per-user Dynamic Gx Rules (DGRs) for each subscriber PDP context. The CSG2 supports unsolicited provisioning of rules by the PCRF. The eGGSN, if present, establishes the PDP context only after downloading the PCC rules. The CSG2 includes a number of elements as AVPs in updates sent to the PCRF (such as SGSN Address, RAT, and so on). In addition, the CSG2 reports the time of the mobile (not of the gateway) in CCR and reauthorization answer (RAA) messages. The CSG2 can dynamically provision 3GPP per-user DGRs using both standard AVPs and Cisco AVPs. When provisioning with standard AVPs, the CSG2 uses the following procedure:
Step 1 Step 2
After identifying a user as a Gx user, the CSG2 sends a Diameter CCR to the PCRF. The PCRF responds with a CCA message with one or more Layer 4 DGRs formatted as standard Charging-Rule-Definition AVPs.
10-11
Chapter 10 Dynamic Provisioning of Cisco Per-User DGRs
Step 3
The CSG2 associates the DGRs with the User Table entry, downloads the DGRs, and sends a RADIUS CoA Request to the GGSN when complete.
Note
If the CSG2 is a Gi-node, it does not send a RADIUS CoA to the GGSN. Instead, it delays the proxy or acknowledgement of the RADIUS Accounting Request until it has successfully downloaded the rules. If the PCRF fails, the CSG2 does not create the User Table entry for the PCC user, and it does not forward or acknowledge the RADIUS Accounting Start request.
When provisioning with Cisco AVPs, the CSG2 uses the following procedure:
Step 1 Step 2
After identifying a user is a Gx user, the CSG2 sends a Diameter CCR to the PCRF. The PCRF responds with a CCA message with one or more Layer 4 DGRs formatted as Cisco-Charging-Rule-Definition AVPs. (The use of Cisco-Charging-Rule-Definition AVPs enables features that are available with configured Gx contents.) The CSG2 associates the DGRs with the User Table entry, downloads the rules, and proxies (or ACKs) the RADIUS request when complete.
Step 3
Note
There are no CSG2 commands required to enable this support.
Dynamic Provisioning of Cisco Per-User DGRs

The CSG2 supports Layer 7 DGRs by referencing global contents, policies, and services that are either configured or dynamically downloaded. The CSG2 dynamically provisions Cisco per-user DGRs using Cisco AVPs. When provisioning with standard AVPs, the CSG2 uses the following procedure:
Step 1 Step 2
After identifying a user is a Gx user, the CSG2 sends a Diameter CCR to the PCRF. The PCRF responds with a CCA message with one or more Layer 7 DGRs formatted as Cisco-Charging-Rule-Definition AVPs. The CCA can also include one or more Layer 4 DGRs formatted as either standard Charging-Rule-Definition AVPs or Cisco-Charging-Rule-Definition AVPs. The CSG2 associates the DGRs with the User Table entry, downloads the rules, and proxies (or ACKs) the RADIUS request when complete.
Step 3
10-12
OL-22840-05
Chapter 10
Configuring Gx Support Gx Event Triggers
Note
Gx Event Triggers
The CSG2 supports the use of armed event triggers to provide the following roaming features in a Gx-enabled network:
Dynamic blocking of subscriber traffic, of a service, or of a change in the service-level Qos when a subscriber roams. The PCRF might also indicate that the CSG2 is to continue forwarding traffic without blocking or modifying any QoS. Blocking the establishment of the PDP context, or of traffic for specific DGRs or services when a subscriber roams. Policy reauthorization.
The CSG2 supports the following 3GPP Gx event triggers: Event SGSN_CHANGE (0) QOS_CHANGE (1) RAT_CHANGE (2) TFT_CHANGE (3) PLMN_CHANGE (4) LOSS_OF_BEARER (5) RECOVERY_OF_BEARER (6) IP-CAN_CHANGE (7) QOS_CHANGE_EXCEEDING_AUTHORIZATION (11) RAI_CHANGE (12) USER_LOCATION_CHANGE (13) UE_IP_ADDRESS_ALLOCATE (18) UE_IP_ADDRESS_RELEASE (19) DEFAULT_EPS_BEARER_QOS_CHANGE (20) Trigger Change in the serving Service GPRS Support Node (SGSN) address Change in the Quality of Service (QoS) Change of Radio Access Technology (RAT) type Change in the Traffic Flow Template (TFT) Change of the SGSN Mobile Network Code (MNC) Mobile Country Code (MCC) tuple Bearer associated with the PCC rules was lost Bearer associated with the PCC rules was recovered Change of IP Connectivity Access Network (IP-CAN) type Change in the requested QoS beyond the authorized values for a specific bearer Change in the Routing Area Identity (RAI) Change in the user location Allocate an IPv4 address for a dual-stack capable UE Release an IPv4 address for a dual-stack capable UE Change in the default Evolved Packet System (EPS) Bearer QoS
10-13
Chapter 10 Volume and Duration Triggers
Event AN_GW_CHANGE (21) SUCCESSFUL_RESOURCE_ALLOCATION (22) RESOURCE_MODIFICATION_REQUEST (23)
Trigger Change of serving Access Node Gateway address Resources for a rule have been successfully allocated PCC rules are requested for a resource modification request initiated by the UE
Volume and Duration Triggers

The CSG2 can report excessive DGR volume usage and duration to the PCRF.
The PCRF specifies the maximum DGR volume usage in an armed volume trigger. When a subscriber passes traffic that matches a DGR, and the IP byte volume (uplink plus downlink) associated with the DGR equals or exceeds the trigger value, the CSG2 reports the usage for the DGR to the PCRF in a CCR and disables the trigger. The PCRF can re-arm the trigger in the CCA. The PCRF specifies the maximum DGR duration for an armed time duration trigger. When a subscriber passes traffic that matches a DGR, the CSG2 notes the timestamp of the first packet. Each time the CSG2 processes another packet, it compares the timestamp to that of the first packet. If the difference between the two timestamps exceeds the duration trigger, the CSG2 reports the usage for the DGR to the PCRF in a CCR and disables the trigger. The PCRF can re-arm the trigger in the CCA.
Per-Subscriber Volume and Time Thresholds

The CSG2 provides per-subscriber volume and time thresholds. These thresholds, which do not require a corresponding charging rule, enable you to selectively and dynamically control subscriber IP flows (IMS and non-IMS) for flow-gating, differentiated billing and charging, and QoS. The per-subscriber volume threshold is triggered each time the sum of all bytes for the subscriber exceeds the specified threshold. The CSG2 then sends a CCR-U to the PCRF with the current volume of traffic and resets the trigger. When the threshold is reached, the PCRF can make the decision to change the QoS. The per-subscriber time threshold is triggered when the time between the first packet and the current packet exceeds the time threshold. The CSG2 then sends a CCR-U to the PCRF and resets the trigger. Each event that is triggered is reported in its own CCR-U; events are not grouped. Charging rule triggers can still be used in conjunction with these per-subscriber triggers. Each trigger generates its own independent CCR-U to the PCRF when the threshold is exceeded. There are no CSG2 commands required to enable this support. The output of the show ip csg users detail command includes the Subscriber Sign-On Timestamp and User Table Entry Creation Time fields.
10-14
OL-22840-05
Chapter 10
Configuring Gx Support Service Flow Detection Triggers
Service Flow Detection Triggers

The CSG2 can notify the PCRF when it receives the first packet that matches a DGR. The PCRF requests the notification in an armed service flow detection trigger. When a subscriber passes traffic that matches a DGR, the CSG2 notifies the PCRF in a CCR, disables the trigger, and handles the traffic. The PCRF can re-arm the trigger in the CCA. There are no CSG2 commands required to enable this support.
Gx Event Trigger Usage Reporting

The PCRF can instruct the CSG2 to include usage information in the CCR-U when an event trigger is hit. The CSG2 includes volume and time usage for each rule, service group, and the user, as well as the most recent values in the Gx AVPs, or the lack of AVPs if they are absent. Each usage is then reset to 0, the CSG2 disables the trigger, and the PCRF can re-arm the trigger in the CCA. The CSG2 supports the following 3GPP Gx event triggers: Event SGSN_CHANGE (0) QOS_CHANGE (1) RAT_CHANGE (2) TFT_CHANGE (3) PLMN_CHANGE (4) LOSS_OF_BEARER (5) RECOVERY_OF_BEARER (6) IP-CAN_CHANGE (7) QOS_CHANGE_EXCEEDING_AUTHORIZATION (11) RAI_CHANGE (12) USER_LOCATION_CHANGE (13) UE_IP_ADDRESS_ALLOCATE (18) UE_IP_ADDRESS_RELEASE (19) DEFAULT_EPS_BEARER_QOS_CHANGE (20) AN_GW_CHANGE (21) SUCCESSFUL_RESOURCE_ALLOCATION (22) RESOURCE_MODIFICATION_REQUEST (23) Trigger Change in the serving Service GPRS Support Node (SGSN) address Change in the Quality of Service (QoS) Change of Radio Access Technology (RAT) type Change in the Traffic Flow Template (TFT) Change of the SGSN Mobile Network Code (MNC) Mobile Country Code (MCC) tuple Bearer associated with the PCC rules was lost Bearer associated with the PCC rules was recovered Change of IP Connectivity Access Network (IP-CAN) type Change in the requested QoS beyond the authorized values for a specific bearer Change in the Routing Area Identity (RAI) Change in the user location Allocate an IPv4 address for a dual-stack capable UE Release an IPv4 address for a dual-stack capable UE Change in the default Evolved Packet System (EPS) Bearer QoS Change of serving Access Node Gateway address Resources for a rule have been successfully allocated PCC rules are requested for a resource modification request initiated by the UE
10-15
Chapter 10 Gx Service Groups
Gx Service Groups
The CSG2 Gx implementation provides several per-subscriber controls (such as thresholds and Cisco QoS enforcement) that are implemented at various levels - user level, service level, and charging rule level.
Note
All of these controls pertain to individual subscribers. For example, service level means control of a service for an individual subscriber, not a service aggregated over many subscribers. The PCRF can specify controls for groups of services for a given subscriber. The controls that are implemented for service groups are:

Cisco QoS Volume and Time Triggers and Thresholds Flow Gating (Permit/Drop/URL Redirect)
For a given subscriber, a service can be a member of a only one service group. Thus, a user IP flow might be a member of a single service group (as well as a member of a single service). The service group volume threshold and QoS are shared among all flows on a packet-by-packet basis (that is, the threshold and QoS are not split in any pre-determined way among flows or services). When a subscriber sends traffic that matches a service, any block or redirect that is associated with the service is applied. If the traffic is allowed to pass by the service, the service group flow status is applied. The threshold implementation is similar to the per-user, per-service, and per-rule implementations. The PCRF can enable or disable the feature by arming and disarming the triggers and thresholds in CCA and RAR messages. Service group control and service membership in a group must be specified via Gx by the PCRF. Service group control will not be configurable via CLI nor specified via the GTP' prepaid interface. There are no CSG2 commands required to enable this support.
Billing Plan Assignment and Modification

The PCRF can assign a new or changed billing plan to a CSG2 subscriber. The PCRF sends the billing plan assignment to the CSG2, and the CSG2 then associates the billing plan with a User Table entry. If there is already a RADIUS or quota server billing plan assigned to the subscriber, the PCRF billing plan overrides the existing billing plan. When the PCRF overrides an existing billing plan, the CSG2 immediately ends all existing user transactions and services for that subscriber. There are no CSG2 commands required to enable this support.
PDP Context QoS Signaling

The eGGSN can signal a QoS change for a PDP context by sending a PDP Update Request to the SGSN. If the SGSN rejects the QoS Update Procedure, the eGGSN increments a counter. This feature is supported only on in eGGSN mode, not in Gi-node mode. There are no CSG2 commands required to enable this support.
10-16
OL-22840-05
Chapter 10
Configuring Gx Support Secondary PDP Context Activation
Secondary PDP Context Activation

The GGSN can send a RADIUS Accounting Start Request to the CSG2, requesting a new Accounting-Session-Id for an existing subscriber. The CSG2 then sends a Diameter CCR to the PCRF, and the PCRF responds with a CCA message, provisioning zero, one, or more Layer 4 or Layer 7 DGRs formatted as either standard Charging-Rule-Definition AVPs or Cisco-Charging-Rule-Definition AVPs. There are no CSG2 commands required to enable this support.
PCRF-Specified Service-Level and User-Level QoS

The PCRF can specify QoS parameters for the CSG2 to apply to a specific service for a user, or to all traffic for a user. There are no CSG2 commands required to enable this support.
PCRF Failure Handling

The PCRF can fail to respond to the PCEF if all of the Diameter peers for the MPCC profile are down, too busy, unable to deliver, or looping. If that occurs, and if configured to do so, the CSG2 can take the following actions:

Apply the already provisioned per-user rules to the flows Report the failed PCRF in BMA CDRs and quota server messages Switch to a standby PCRF
To define PCRF failure handling for the CSG2, enter the following command in global configuration mode: Command
csg2(config-csg-user-profile)# pcrf failure [continue | terminate]
Purpose Defines the actions that the CSG2 is to take for a PCC user if the PCRF fails when the user session is activated.

User Session Continuation After PCRF Timeout

If configured to do so, and if all of the Diameter peers for the MPCC profile are down, the CSG2 can take the following actions in the event that the PCRF times out:

The CSG2 applies the already provisioned per-user rules to the flows. The CSG2 reports the timed-out PCRF in BMA CDRs and quota server messages. The CSG2 switches to a standby PCRF.
10-17
Chapter 10 Restrictions for Gx
To define PCRF timeout handling for the CSG2, enter the following command in global configuration mode: Command
csg2(config-csg-user-profile)# pcrf timeout [continue | terminate]
Purpose (Optional) Defines the actions that the CSG2 is to take for a PCC user if the PCRF times out when the user session is activated.

Restrictions for Gx
For Gx, the CSG2 imposes the following restrictions:

The CSG2 does not provide IPv6 transport for the control plane interfaces. In a Gx charging rule, the flow descriptions in both the uplink and downlink directions must map to the same service. Mapping an existing flow or session to a new DGR is not supported. Provisioning of charging gateways (BMAs, quota servers, and so on) is not supported. Policy control for HTTP X-Forwarded-For data packets is not supported. Per-rule QoS is not enforced on the CSG2. For LTE users, per-rule QoS is included in the CoA messages passed to the Cisco PGW for bearer-binding. If a global content update results in changed parameters, the CSG2 closes all open transactions and sessions associated with the content. Only one external preloading server can be active at any given time. If the CSG2 receives a flow before it receives per-user PCC rules from PCRF, the CSG2 matches the flow against existing CSG2 contents. Preloaded policy objects must not reference CLI-configured objects, and vice versa. For example, a preloaded billing plan must not reference a CLI-configured service. You cannot use preloading to modify a CLI-configured object, and you cannot use the CLI to modify a preloaded policy object.
10-18
OL-22840-05
CH A P T E R
12

This chapter contains the following information about Content Service Gateway (CSG2) support for prepaid billing:

Configuring a Prepaid Billing Plan, page 12-1 Configuring Virtual Prepaid Mode, page 12-2 Prepaid WAP Support, page 12-3 Configuring a Postpaid Service for a Prepaid Billing Plan, page 12-3
Configuring a Prepaid Billing Plan

A billing plan identifies one or more content billing services to be used for prepaid billing. To define a billing plan, follow these steps, beginning in global configuration mode: Command
Step 1 Step 2
Router (config)# ip csg billing billing-plan-name Router (config-csg-billing)# service service-name
Purpose Defines a CSG2 billing plan, and enters CSG2 billing configuration mode. Associates a prepaid service with a prepaid CSG2 billing plan.
The following example shows how to define a prepaid billing plan:

ip csg billing REGULAR service MOVIES service BROWSING
When a CSG2 prepaid subscriber initiates a new IP session, a large amount of quota might be reserved for the IP session if the IP session maps to a service configured for basis byte ip or basis byte tcp. The reservation often greatly exceeds the amount of quota that the session actually uses. This does not result in incorrect charging. However, as a result of one or more large reservations for IP sessions, the CSG2 might make additional requests for quota from the quota server.
12-1
Chapter 12 Configuring Virtual Prepaid Mode
Configuring Virtual Prepaid Mode

Virtual prepaid mode enables a service provider to use prepaid features for a service, without interfacing to the quota server for subscribers for whom the provider does not want to enforce quota restrictions. In virtual prepaid mode, the CSG2 does not send any messages to the quota server (other than a Quota Server User-Profile Request to obtain the billing plan). The CSG2 also does not generate any BMA records related to interfacing with the quota server for virtual prepaid services. The CSG2 grants the virtual prepaid service a large initial quota and replenishes the balance as needed. The CSG2 reports virtual prepaid quota usage to the BMA in the same TLVs in which it reports prepaid usage. If accelerated sessions are enabled for a content, virtual prepaid sessions associated with that content are also accelerated. When configuring virtual prepaid mode, keep the following considerations in mind:

You can configure virtual prepaid mode for all of the services in a billing plan, or for one or more services in a prepaid billing plan. Typically, you cannot configure virtual prepaid mode for a service in a billing plan that is configured as a postpaid billing plan. However, if you configure the qct command for a service in a postpaid billing plan, you can configure virtual prepaid mode for that service. Each virtual prepaid service is configured with a basis, and can also be configured with a dual basis. Charging is in accordance with the configured billing basis. For virtual prepaid services, the CSG2 ignores any values configured with the passthrough, reauthorization threshold, or reauthorization timeout commands in service configuration mode. Virtual prepaid service usage is not reported in fixed-format Service Usage CDRs.
To configure all of the services in a prepaid billing plan as virtual prepaid services, follow these steps, beginning in global configuration mode: Command
Step 1 Step 2
Router (config)# ip csg billing billing-plan-name
Purpose Defines a CSG2 billing plan, and enters CSG2 billing configuration mode. Specifies a virtual prepaid billing plan.
Router (config-csg-billing)# mode prepaid virtual
To configure a virtual prepaid service for a user with a prepaid billing plan, follow these steps, beginning in global configuration mode: Command
Step 1 Step 2
Router (config)# ip csg billing billing-plan-name Router (config-csg-billing)# service service-name mode prepaid virtual
Purpose Defines a CSG2 billing plan, and enters CSG2 billing configuration mode. Specifies a virtual prepaid service.
12-2
OL-22840-05
Chapter 12
Configuring Prepaid Support Prepaid WAP Support
Prepaid WAP Support

Some upstream WAP browsing traffic occurs because the CSG2 must inspect the reply before determining whether the traffic is an MMS transaction. However, the downstream WAP browsing replies are discarded if quota is depleted. Control information is charged against quota for non-MMS transactions. WSP PDU types SUSPEND and RESUME are never charged against quota.
Configuring a Postpaid Service for a Prepaid Billing Plan

The CSG2 supports both prepaid and postpaid billing services. In most cases, a user with a prepaid billing plan uses prepaid services. However, the CSG2 enables you to define a postpaid service for a user with a prepaid billing plan. This enables you to provide service-level CDR granularity for postpaid transactions for a prepaid user.
Note
You cannot define a prepaid service for a postpaid billing plan. To define a postpaid service for a user with a prepaid billing plan, follow these steps, beginning in global configuration mode:
Command
Step 1 Step 2
Router (config)# ip csg billing billing-plan-name Router (config-csg-billing)# service service-name mode postpaid
Purpose Defines a CSG2 billing plan, and enters CSG2 billing configuration mode. Associates a postpaid service with a prepaid CSG2 billing plan.
Note
If you do not specify the mode postpaid option, the service is prepaid.
12-3
Chapter 12 Configuring a Postpaid Service for a Prepaid Billing Plan
12-4
OL-22840-05
CH A P T E R
11
Configuring Mobile PCC Support

Cisco Mobile Policy Control & Charging (PCC) provides a generic PCC infrastructure that supports a Diameter-based policy control interface that can be easily tailored to meet the needs of various application gateways, such as the CG2 or eGGSN. For more information about Diameter, see the following documents:
Diameter Credit Control Application feature guide: http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/ht_diam.html Cisco IOS Security Configuration Guide, Cisco IOS Release 12.4 Per-User PCC, page 11-1 Policy Preloading, page 11-1 PCRF Load Balancing, page 11-2 Handling Redundancy in PCC, page 11-3 Handling Response Codes in PCC, page 11-3 Mobile PCC Configuration Examples, page 11-5
The CSG2 provides the following features for Mobile PCC:

Per-User PCC
Mobile PCC provides support for per-user policy interactions between the Policy and Charging Enforcement Function (PCEF) and the Policy and Charging Rule Function (PCRF). (Strictly speaking, these are per-user session policy interactions.) The application PCC handler is responsible for enforcing the policies received from PCRF.
Policy Preloading
The Mobile PCC infrastructure implements a generic policy preloading module. This module interfaces with the IOS authentication, authorization, and accounting (AAA) shim layer to send and receive Diameter messages towards the policy server and the gateway application. This provides an interface for the gateway application to initiate policy preloading and to receive global policy objects. The Mobile PCC infrastructure policy preloading module receives the following messages from the IOS AAA shim layer:
11-1
Chapter 11 PCRF Load Balancing
Receipt of Policy Preload Response (RAA) Server-Initiated Global Policy Push (RAR) Policy Preload Timer, page 11-2 Session ID Format for Policy Preloading, page 11-2
The Mobile PCC infrastructure policy preloading module provides the following procedures:

Policy Preload Timer

Typically, the gateway application blocks data traffic while policy preloading is in progress. When certain error conditions occur, such as the PCEF not receiving an RAR after a Credit Control Request (CCR)/Credit Control Answer (CCA) for policy preload, policy preloading could become stuck in INPROGRESS state. The configurable policy preload timer can prevent this situation. The policy preload timer starts when preloading begins and stops when preloading is complete or when the timer expires, whichever occurs first. If the timer expires before policy preloading is complete, the Mobile PCC infrastructure notifies the application handler that policy preloading has failed. The application handler then has the option of removing all of the policy preloaded objects that were installed before the timer expired.
Session ID Format for Policy Preloading

The Session-Id AVP is included in all Diameter messages and is used to identify the session. The same session ID is used throughout the life of a session. When policy preload requests are initiated, the PCC generates the session ID with the following format: host-of-origin;0;seconds-since-1970 After a session has been created for preloading, the same session ID is used for all preload requests while the system is up.
PCRF Load Balancing

The Mobile PCC infrastructure uses a round robin algorithm to select the policy method list for PCRF load balancing. For example, if you configure a group of three authentication, authorization, and accounting (AAA) method lists for a Mobile PCC profile:

The first request would go to the first method list. The second request would go to the second method list. The third request would go to the third method list. The fourth request would go back to the first method list.
And so on. When a gateway application needs to send an initial CCR for a session, it sends the profile name to the PCC, and the PCC uses the profile name to select the method list for the CCR. The same method list is used for the initial CCR and for all remaining messages to the PCRF associated with that session. If the gateway application does not send a profile name, the PCC uses the default method list for that session. If no default method list is configured, requests for PCC charging rules are not sent to the PCRF.
11-2
OL-22840-05
Chapter 11
Configuring Mobile PCC Support Handling Redundancy in PCC
Note
CCRs are not load-balanced among PCRF servers that are part of the same server group. Only one of the servers is selected when the CCRs are assigned. All other servers act as standby servers in the server group.
Handling Redundancy in PCC

The PCC must determine the redundancy state of the gateway application and must forward requests to the policy server only when the gateway application is active. The PCC creates and updates the session information for per-user requests received on the standby processor and does not send them over wire to the policy server. For policy preloading, the PCC must synchronize the preload information, such as session info and preload status, to the PCC on the standby processor. The PCC synchronizes this information with the standby processor when the active application PCC handler receives session data with the policy preload response. For per-user policy control, the session identifier, method list, and PCRF information must by synchronized to the standby PCC. This synchronization is initiated when the active PCC receives the policy authorization response (CCA). The PCC synchronizes the following information to the standby PCC on a per-session basis:

Session ID Destination Host Destination Realm Methodlist Name PCRF IP Address VRF Table ID (the VRF associated with the peer) Port Number (the port number on which the peer is running) Preload Status (synchronized for policy preload sessions only)
No other information or statistics are synchronized.
Handling Response Codes in PCC

This section describes how the Mobile PCC infrastructure handles the following response codes:

Response Code for CCA, page 11-3 Response Code for RAA, page 11-4
Response Code for CCA

The PCC sends one of the following response codes when notifying the application gateway of the CCA message:
SUCCESS = 1 This response code is sent when there is no failure.
11-3
Chapter 11 Handling Response Codes in PCC
FAILURE = 2 SERVER_TIMEOUT = 3 SERVER_DOWN = 4
Response Code for RAA

When the PCC receives the policy charging rules or global objects in a RAR, it forwards them to the application gateway. After processing the charging rules or global objects, the PCC includes one of the following response codes when communicating the RAA back to the Diameter base:
DIA_POLICY_IF_SUCCESS = 1 When it receives a DIA_POLICY_IF_SUCCESS response code, the IOS AAA shim layer sets the Result-Code to DIA_RESULT_CODE_SUCCESS (2001).
DIA_POLICY_IF_SESSION_NOT_FOUND =3 This response code is sent when the session associated with the RAR is not found in the PCC, or if there is some other failure. When it receives a DIA_POLICY_IF_SESSION_NOT_FOUND response code, the IOS AAA shim layer sets the Result-Code to DIA_RESULT_CODE_UNKNOWN_SESSION_ID (5002).
Per-User RAAs
For per-user RAAs, the application gateway includes the following attributes in requests to the PCC:

[Auth-Application-Id] [Charging-Rule-Report] [Access-Network-Charging-Address] [Access-Network-Charging-Identifier-Gx] [Failed-AVP] [Charging-Rule-Event] [Event-Trigger]
The gateway application includes the [Failed-AVP] attribute if one or more of the charging rules fails to install.
Preload RAAs
For preload RAAs, the gateway application passes the object type (for which the RAA was sent), the preload response code, and the failed preload objects to the PCC. Valid preload response codes are:

PRELOAD_INCONSISTENT_DATA=0 PRELOAD_MISSING_MANDATORY_DATA =1 PRELOAD_FAILURE_TO_ENFORCE =2 PRELOAD_WRONG_ORDER =3 PRELOAD_CONFLICT_WITH_STATIC_CONFIG=4 PRELOAD_NO_ERROR = 255
11-4
OL-22840-05
Chapter 11
Configuring Mobile PCC Support Mobile PCC Configuration Examples
If preloading completes successfully, the gateway application sends the PRELOAD_NO_ERROR response code to the PCC. If preloading fails, the gateway application includes the appropriate response code for the error and passes the failed preload objects to the PCC.
Mobile PCC Configuration Examples

This section provides the following sample configurations for Mobile PCC:

Diameter Configuration Example, page 11-5 Diameter Redundancy Configuration Example, page 11-6 Mobile PCC Configuration Example, page 11-7
Diameter Configuration Example

The following sample configuration illustrates how to configure AAA method lists, server groups and Diameter servers.
aaa new-model ! aaa group server diameter pcrf_sg_preload server name preload_server ! aaa group server diameter pcrf_sg_web1 server policy_server_web1 ! aaa group server diameter pcrf_sg_wap1 server policy_server_wap1 ! aaa group server diameter pcrf_sg_smtp1 server policy_server_smtp1 ! aaa group server diameter pcrf_sg_web2 server policy_server_web2 ! aaa group server diameter pcrf_sg_wap2 server policy_server_wap2 ! aaa group server diameter pcrf_sg_smtp2 server policy_server_smtp2 ! aaa authentication login default line aaa authorization policy-if pcrf_preload_list group pcrf_sg_preload aaa authorization policy-if pcrf_list_web1 group pcrf_sg_web1 aaa authorization policy-if pcrf_list_web2 group pcrf_sg_web2 aaa authorization policy-if pcrf_list_wap1 group pcrf_sg_wap1 aaa authorization policy-if pcrf_list_wap2 group pcrf_sg_wap2 aaa authorization policy-if pcrf_list_smtp1 group pcrf_sg_smtp1 aaa authorization policy-if pcrf_list_smtp2 group pcrf_sg_smtp2 ! !configure diameter peers ! diameter peer preload_server address ipv4 13.1.1.1 transport tcp port 5000 timer watchdog 1000
11-5
Chapter 11 Mobile PCC Configuration Examples
destination host preload_server.cisco.com ! diameter peer policy_server_web1 address ipv4 14.1.1.1 transport tcp port 5000 timer watchdog 1000 destination host policy_server_web1.cisco.com ! diameter peer policy_server_web2 address ipv4 15.1.1.1 transport tcp port 5000 timer watchdog 1000 destination host policy_server_web2.cisco.com ! diameter peer policy_server_wap1 address ipv4 16.1.1.1 transport tcp port 5000 timer watchdog 1000 destination host policy_server_wap1.cisco.com ! diameter peer policy_server_wap2 address ipv4 17.1.1.1 transport tcp port 5000 timer watchdog 1000 destination host policy_server_wap2.cisco.com ! diameter peer policy_server_smtp1 address ipv4 18.1.1.1 transport tcp port 5000 timer watchdog 1000 destination host policy_server_smtp1.cisco.com ! diameter peer policy_server_smtp2 address ipv4 19.1.1.1 transport tcp port 5000 timer watchdog 1000 destination host policy_server_smtp2.cisco.com ! !diameter global configuration ! diameter origin realm cisco.com diameter origin host gw.cisco.com diameter vendor supported 3gpp diameter vendor supported cisco
Diameter Redundancy Configuration Example

When a gateway application is installed in redundant mode, you must enable the redundancy for Diameter using the diameter redundancy command in global configuration mode. If redundancy is enabled, the Diameter client needs to work with HSRP, and therefore must use a loopback address as the source address to the TCP connection. Both the active device and the standby device must use the same source address for the connection towards the Diameter server. The policy server must have a route to the loopback via the HSRP virtual IP address towards the Diameter client. Therefore, only the active device receives the connection from the server. Use the source interface command in Diameter peer configuration mode to define the source interface for the active and standby devices. The Diameter client on the standby node must not initiate a TCP connection to the server until the standby-to-active transition occurs.
11-6
OL-22840-05
Chapter 11
Configuring Mobile PCC Support Mobile PCC Configuration Examples
The following sections provide the sample configuration on the active device and on the standby device when Diameter redundancy is enabled:

Active Device Configuration, page 11-7 Standby Device Configuration, page 11-7
Active Device Configuration

interface Loopback1 description diameter source loopback address ip address 9.9.9.9 255.255.255.255 ! interface GigabitEthernet0/0.1 description connects to PCRF encapsulation dot1Q 36 ip address 11.1.36.92 255.255.255.0 no snmp trap link-status standby version 2 standby 2 ip 11.1.36.100 standby 2 name GGSN-HSRP ! diameter redundancy ! diameter peer policy-server1 source interface loopback1
Standby Device Configuration

interface Loopback1 description diameter source loopback address ip address 9.9.9.9 255.255.255.255 ! interface GigabitEthernet0/0.1 description connects to PCRF encapsulation dot1Q 36 ip address 11.1.36.93 255.255.255.0 no snmp trap link-status standby version 2 standby 2 ip 11.1.36.100 standby 2 name GGSN-HSRP ! diameter redundancy ! diameter peer policy-server1 source interface loopback1
Mobile PCC Configuration Example

The following is a sample configuration for Mobile PCC.
! Enable preload mpcc preload ! !Configure profiles ! mpcc profile web_profile any !Option any makes the above a default Mobile PCC profile policy-if pcrf_list_web1 pcrf policy-if pcrf_list_web2
11-7
Chapter 11 Mobile PCC Configuration Examples
!Configure a destination realm in Mobile realm destination web.com ! mpcc profile wap_profile pcrf policy-if pcrf_list_wap1 pcrf policy-if pcrf_list_wap2 !Configure a destination realm in Mobile realm destination wap.com ! mpcc profile smtp_profile pcrf policy-if pcrf_list_smtp1 pcrf policy-if pcrf_list_smtp2 !Configure a destination realm in Mobile realm destination smtp.com ! !Configure a destination realm in global mpcc destination-realm cisco.com ! !Configure a preload method-list mpcc preload policy-if pcrf_preload_list ! !Configure preload timer in seconds mpcc preload timeout 1200
PCC profile configuration mode
configuration mode
11-8
OL-22840-05
A P P E N D I X

This appendix documents the commands necessary to configure and monitor the CSG2. Other commands used with the CSG2 are documented in the following publications:
Service and Application Module for IP User Guide for the following commands:
Supervisor console commands PowerPC console commands PowerPC ROM-monitor (ROMmon) console commands Broadcom BCM Linux-based Storage Area Network Operation System (SanOS) console
commands
Broadcom BCM ROMmon console commands Line Card Processor (LCP) console commands
For Diameter commands:

Diameter Credit Control Application feature guide:
http://www.cisco.com/en/US/docs/ios/12_4t/12_4t11/ht_diam.html
Cisco IOS Security Command Reference, Cisco IOS release 12.4
Cisco IOS Server Load Balancing Command Reference for IOS SLB-specific commands Cisco IOS Release 12.2 command reference publications for other IOS commands accelerate, page A-8 accounting (CSG2 policy), page A-10 activation, page A-11 aoc append url, page A-13 aoc confirm, page A-14 aoc enable, page A-16 basis, page A-18 block, page A-22 class (CSG2 header), page A-23 class (CSG2 service), page A-25 class-map (CSG2 policy), page A-26
All of the CSG2 commands are listed below in alphabetical order:

A-1
Appendix A
clear ip csg, page A-28 clear ip iscsi statistics, page A-32 clear mpcc, page A-33 clear mpcc session, page A-34 clear record-storage-module stats, page A-35 client-group (CSG2 content), page A-36 content (CSG2 service), page A-38 control-url, page A-40 csg start preload, page A-41 debug ip csg, page A-42 debug mpcc, page A-49 domain group (CSG2 content), page A-50 encrypt (CSG2 header), page A-52 entries user idle, page A-53 flags, page A-55 header (CSG2 header-group), page A-58 header-group (CSG2 service), page A-60 idle (CSG2 content), page A-61 idle (CSG2 service), page A-63 insert header-group (CSG2 policy), page A-65 inservice (CSG2 content), page A-66 ip (CSG2 content), page A-67 ip (iSCSI), page A-69 ip csg billing, page A-71 ip csg bma, page A-73 ip csg bma activate, page A-75 ip csg bma keepalive, page A-77 ip csg bma local-port, page A-78 ip csg bma messages, page A-80 ip csg bma retransmit, page A-82 ip csg bma retries, page A-83 ip csg bma window, page A-85 ip csg case-sensitive, page A-86 ip csg content, page A-87 ip csg count retransmit ip, page A-90 ip csg database, page A-91 ip csg domain group, page A-92 ip csg domain mining, page A-94
A-2
OL-22840-05
Appendix A
ip csg egcdr mode, page A-96 ip csg entries dns map hash size, page A-97 ip csg entries dns map interval, page A-99 ip csg entries dns map ttl maximum, page A-101 ip csg entries dns map ttl minimum, page A-102 ip csg entries fragment, page A-103 ip csg entries session user max, page A-105 ip csg entries user idle, page A-107 ip csg entries user max, page A-109 ip csg entries user profile, page A-111 ip csg event-trace packet enable, page A-114 ip csg event-trace packet entries, page A-116 ip csg event-trace packet match action, page A-118 ip csg event-trace packet match error, page A-119 ip csg event-trace packet match ip, page A-120 ip csg event-trace packet match protocol, page A-122 ip csg geo-redundancy, page A-126 ip csg header, page A-127 ip csg header-group, page A-129 ip csg ipc crashdump, page A-131 ip csg ipc keepalive, page A-132 ip csg ipc retransmit, page A-133 ip csg ipc retries, page A-134 ip csg iscsi drain delay, page A-135 ip csg iscsi drain packet, page A-136 ip csg iscsi profile, page A-138 ip csg keys, page A-139 ip csg license syslog enable, page A-140 ip csg license warning-enable, page A-142 ip csg load accel rate, page A-144 ip csg map, page A-145 ip csg mode single-tp, page A-147 ip csg pcc gx, page A-148 ip csg policy, page A-149 ip csg preload request, page A-151 ip csg psd, page A-152 ip csg psd drain delay, page A-154 ip csg psd drain packet, page A-155
A-3
Appendix A
ip csg psd keepalive, page A-156 ip csg psd local-port, page A-157 ip csg psd margin, page A-159 ip csg psd retransmit, page A-160 ip csg psd retries, page A-161 ip csg psd window, page A-163 ip csg qos profile, page A-164 ip csg quota-server, page A-165 ip csg quota-server activate, page A-168 ip csg quota-server keepalive, page A-170 ip csg quota-server local-port, page A-171 ip csg quota-server messages, page A-173 ip csg quota-server reassign, page A-174 ip csg quota-server retransmit, page A-175 ip csg quota-server retries, page A-176 ip csg quota-server user-profile, page A-178 ip csg quota-server window, page A-179 ip csg radius ack error parse, page A-180 ip csg radius ack error user, page A-182 ip csg radius attribute, page A-184 ip csg radius binary attribute, page A-186 ip csg radius coa nas, page A-188 ip csg radius coa timeout, page A-190 ip csg radius correlation, page A-191 ip csg radius endpoint, page A-193 ip csg radius handoff, page A-196 ip csg radius monitor, page A-198 ip csg radius monitor nas, page A-200 ip csg radius on-off purge, page A-202 ip csg radius pod attribute, page A-203 ip csg radius pod nas, page A-205 ip csg radius pod timeout, page A-207 ip csg radius proxy, page A-208 ip csg radius proxy timeout, page A-212 ip csg radius reauthorization attribute, page A-213 ip csg radius route inject, page A-215 ip csg radius start restart session-id, page A-216 ip csg radius start restart session-id, page A-216
A-4
OL-22840-05
Appendix A
ip csg radius stop purge, page A-218 ip csg radius userid, page A-220 ip csg records format, page A-222 ip csg redirect, page A-223 ip csg refund, page A-225 ip csg regex memory, page A-226 ip csg replicate, page A-227 ip csg report 8bytetlv, page A-229 ip csg report block, page A-231 ip csg report content, page A-233 ip csg report http header, page A-235 ip csg report policy, page A-237 ip csg report radius attribute, page A-239 ip csg report smtp rfc2822, page A-242 ip csg report tcp estab, page A-244 ip csg report usage, page A-246 ip csg report user logoff, page A-248 ip csg report wap actual-pdu, page A-250 ip csg select, page A-252 ip csg service, page A-254 ip csg snmp timer, page A-257 ip csg statistics protocol interval, page A-258 ip csg subscriber, page A-259 ip csg transport-type assign, page A-260 ip csg user class, page A-261 ip csg user profile, page A-263 ip iscsi target-profile, page A-265 ipv6 (CSG2 content), page A-267 lifetime (CSG2 service), page A-269 map (CSG2 policy), page A-271 match attribute (CSG2 map), page A-273 match domain (CSG2 domain group), page A-278 match header (CSG2 map), page A-281 match method (CSG2 map), page A-285 match url (CSG2 map), page A-288 meter exclude control sip, page A-292 meter exclude mms wap, page A-294 meter exclude network-init sip, page A-296
A-5
Appendix A
meter exclude pause rtsp, page A-298 meter exclude svc-idle, page A-300 meter include imap, page A-302 meter increment, page A-305 meter initial, page A-307 meter minimum, page A-309 mining (CSG2 content), page A-311 mode, page A-313 mode tcp, page A-315 mpcc destination-realm, page A-316 mpcc include avp destination-host, page A-317 mpcc preload, page A-318 mpcc preload policy-if, page A-319 mpcc preload timeout, page A-320 mpcc profile, page A-321 name (CSG2 header), page A-323 name (iSCSI), page A-324 next-hop (CSG2 content), page A-326 next-hop override (CSG2 content), page A-328 normalize-url, page A-330 offline, page A-332 owner (CSG2 service), page A-333 parse length (CSG2 content), page A-334 parse protocol (CSG2 content), page A-336 passthrough, page A-338 pcc gx, page A-339 pcrf failure, page A-341 pcrf policy-if, page A-342 pcrf profile, page A-344 pcrf timeout, page A-345 pending (CSG2 content), page A-346 police, page A-347 policy (CSG2 content), page A-351 port (iSCSI), page A-353 qct (CSG2 service), page A-355 qos profile (CSG2 billing), page A-357 qos profile (CSG2 service), page A-359 quota-server (CSG2 header), page A-361
A-6
OL-22840-05
Appendix A
radius (CSG2 header), page A-362 radius (CSG2 user class), page A-364 rating-group (CSG2 service), page A-366 realm destination, page A-367 reauthorization threshold, page A-368 reauthorization timeout, page A-370 records delay, page A-372 records granularity, page A-374 records intermediate, page A-376 refund, page A-378 relative, page A-379 replicate (CSG2 content), page A-380 retcode, page A-382 sami rate all, page A-384 service, page A-385 session-timeout (iSCSI), page A-387 show ip csg, page A-389 show ip iscsi, page A-411 show mpcc, page A-414 show record-storage-module, page A-417 snmp-server enable traps csg, page A-419 string (CSG2 header), page A-421 subscriber-ip http-header x-forwarded-for (CSG2 content), page A-422 target-portal (iSCSI), page A-424 timestamp (CSG2 header), page A-426 user class (CSG2 service), page A-427 user-default, page A-429 verify confirm, page A-431 verify enable, page A-433 vlan (CSG2 content), page A-434 vrf (CSG2 content), page A-435
A-7
Appendix A accelerate
accelerate
To enable acceleration for sessions that match a CSG2 content, use the accelerate command in CSG2 content configuration mode. To disable acceleration, use the no form of this command. accelerate no accelerate
Syntax Description
This command has no arguments or keywords.
Command Default
Acceleration is not enabled.
Command Modes
CSG2 content configuration
Command History
Release 12.4(24)MDA
Modification This command was introduced.
Usage Guidelines
Acceleration is enabled only if the protocol specified using the parse protocol command also supports acceleration. TCP bytes are not reported in CDRs for accelerated sessions. For accelerated sessions, the number of TCP bytes reported in the TCP Stat TLV is set to zero. Acceleration is not supported for the following CSG2 features:

eG-CDRs with GGSN Gx sessions HTTP header insertion Intermediate CDRs Prepaid sessions Service-level CDRs (acceleration is supported only for transaction-level CDRs)
Examples
The following example shows how to enable acceleration for sessions that match content LAYER4:
ip csg content LAYER4 ip any parse protocol other accelerate inservice
A-8
OL-22840-05
Appendix A
CSG2 Command Reference accelerate
Related Commands
Command ip csg content ip csg load accel rate parse protocol (CSG2 content)
Description Configures content for CSG2 services, and enters CSG2 content configuration mode. Specifies a session acceleration rate for the CSG2. Defines how the CSG2 is to parse traffic for a content.
A-9
Appendix A accounting (CSG2 policy)
accounting (CSG2 policy)

To specify accounting and an optional customer string for a CSG2 policy, use the accounting command in CSG2 policy configuration mode. To remove accounting for a policy, use the no form of this command. accounting [customer-string string] no accounting [customer-string string]
Syntax Description
customer-string string
(Optional) 1- to 16-byte string to be written in the generated accounting records.
Command Default
The default is no accounting.
Command Modes
CSG2 policy configuration
Command History
Release 12.4(11)MD
Modification This command was migrated from CSG1. Changes from CSG1: All keywords and arguments except customer-string string were removed.
12.4(15)MD
Support for FTP was added.
Usage Guidelines
This command is required if the CSG2 is to generate call detail records (CDRs) for content that matches the CSG2 policy. This command is required to enable billing functions (such as CDR generation and prepaid charging) for content that matches a CSG2 policy. For FTP and Real Time Streaming Protocol (RTSP) accounting, the CSG2 matches prepaid services on the basis of the IP address and port number of the control connection to the FTP or RTSP network IP address.
Examples
The following example shows how to specify accounting and customer strings for a CSG2 policy:
ip csg policy MOVIES accounting customer-string MOVIES
Related Commands
Command ip csg policy
Description Defines a policy for qualifying flows for the CSG2 billing services, and enters CSG2 policy configuration mode.
A-10
OL-22840-05
Appendix A
CSG2 Command Reference activation
activation
To specify the activation mode for a CSG2 Connection Duration service, use the activation command in CSG2 service configuration mode. To restore the default setting, use the no form of this command. activation [automatic | user-profile] no activation
Syntax Description
automatic
(Optional) Activates the Connection Duration service, unless the billing profile indicates that no service is to be activated. If you specify the automatic keyword, the CSG2 activates the Connection Duration service in the subscribers billing plan automatically, unless the service name is specified with a zero length as the connect service in the billing profile information. The connect service information must be specified in the same message as the subscribers billing plan.
user-profile
(Optional) Activates the Connection Duration service only if the billing profile specifies this service as the connect service. This is the default setting. If you specify the user-profile keyword, the CSG2 activates the Connection Duration service for a subscriber only if the service name is specified as a connect service in the billing profile information in an authentication, authorization, and accounting (AAA) Access-Accept, an AAA Accounting-Start, or a Quota Server User-Profile Response.
Command Default
The Connection Duration service is activated only if the billing profile specifies this service as the connect service.
Command Modes
CSG2 service configuration
Command History
Release 12.4(11)MD
Modification This command was migrated from CSG1. Changes from CSG1: None.
Usage Guidelines
This command requires that the service be configured with basis second connect.
Examples
The following example specifies automatic activation for Connection Duration service CONNECT.
ip csg service CONNECT basis second connect activation automatic
A-11
Appendix A activation
Related Commands
Command ip csg service
Description Configures a CSG2 content billing service, and enters CSG2 service configuration mode.
A-12
OL-22840-05
Appendix A
CSG2 Command Reference aoc append url
aoc append url

To specify that the CSG2 is to append the original URL to the redirect URL sent by the quota server on a Content Authorization REDIRECT_URL response for use in Advice of Charge (AoC) URL-rewriting, use the aoc append url command in CSG2 service configuration mode. To restore the default setting, use the no form of this command. aoc append url no aoc append url
Syntax Description
Command Default
The CSG2 does not append the original URL to the redirect URL.
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
Before configuring this command, you must enable AoC by configuring the aoc enable command. The CSG2 performs this function only for content parsed as connectionless or connection-oriented wireless application protocol (WAP 1.x). For other protocols, the CSG2 ignores this configuration option.
Examples
The following example specifies that the CSG2 is to append the original URL to the redirect URL for use in AoC URL-rewriting:
ip csg service MOVIES aoc enable aoc append url
Related Commands
Command aoc confirm aoc enable ip csg service
Description Configures a token for use in Advice of Charge (AoC) URL-rewriting. Enables Advice of Charge (AoC) URL-rewriting for the CSG2. Configures a CSG2 content billing service, and enters CSG2 service configuration mode.
A-13
Appendix A aoc confirm
aoc confirm
To configure a token for use in Advice of Charge (AoC) URL-rewriting, use the aoc confirm command in CSG2 service configuration mode. To remove the token, use the no form of this command. aoc confirm token no aoc confirm
Syntax Description
token
A string of up to 15 alphanumeric characters. The string is not case-sensitive. Acceptable characters include alphanumeric characters and any of the following special characters: $-_.+!*'(),?/:@&=;~%. To enter other special characters not listed, use the URL-escape format with the percent sign (%).
Command Default
None
Command Modes
Command History
Release 12.4(11)MD
Modification This command was migrated from CSG1. Changes from CSG1:

The name of this command changed from aoc confirmation to aoc confirm. The configuration mode for this command changed from CSG user group configuration to CSG2 service configuration. The list of supported special characters changed.
Usage Guidelines
Before configuring this command, you must enable AoC by configuring the aoc enable command. URL-rewriting allows a top-off server to append parameters to a URL in order to convey state information to the quota server during a Content Authorization Request. Whenever a Content Authorization Response contains the forward action code, and the URL contains the AoC confirmation token, the token and all trailing characters are removed from the URL before the request is forwarded to the server. The token is used for HTTP and WAP 1.x content authorization URL-rewriting. If the token uses the URL-escape format, the redirect URL to which the token is being matched must also use the URL-escape format.
Examples
The following example specifies a token for Advice of Charge (AoC) URL-rewriting:
ip csg service MOVIES aoc enable aoc confirm ?CSG_AOC_OK
A-14
OL-22840-05
Appendix A
CSG2 Command Reference aoc confirm
Related Commands
Command aoc append url aoc enable ip csg service
Description Specifies that the CSG2 is to append the original URL to the redirect URL sent by the quota server for use in Advice of Charge (AoC) URL-rewriting. Enables Advice of Charge (AoC) URL-rewriting for the CSG2. Configures a CSG2 content billing service, and enters CSG2 service configuration mode.
A-15
Appendix A aoc enable
aoc enable
To enable Advice of Charge (AoC) URL-rewriting for the CSG2, use the aoc enable command in CSG2 service configuration mode. To restore the default setting, use the no form of this command. aoc enable no aoc enable
Syntax Description
Command Default
The CSG2 does not append the original URL to the redirect URL.
Command Modes
Command History
Release 12.4(11)MD
Modification This command was migrated from CSG1. Changes from CSG1: The name of this command changed from authorize content to aoc enable.
Usage Guidelines
This command is not valid if the service is configured with basis second connect. If this command is configured, the CSG2 alerts the quota server of a new transaction, and allows it to direct the CSG2 to perform any of the following mutually exclusive actions:

DROP: Instructs the CSG2 to drop all packets for this flow. FORWARD: Instructs the CSG2 to forward the flow without altering the destination (a weight might be specified). REDIRECT-URL: Instructs the CSG2 to redirect subscriber requests to the URL provided by the quota server. The CSG2 sends a Layer 7 redirect to the subscriber (for example, HTTP 302 response) that contains the redirect URL. This applies to both HTTP and WAP 1.x protocols.
Examples
The following example enables AoC URL-rewriting for the CSG2:

ip csg service MOVIES aoc enable
Related Commands
Command aoc append url
Description Specifies that the CSG2 is to append the original URL to the redirect URL sent by the quota server for use in Advice of Charge (AoC) URL-rewriting.
A-16
OL-22840-05
Appendix A
CSG2 Command Reference aoc enable
Command aoc confirm ip csg service
Description Configures a token for use in Advice of Charge (AoC) URL-rewriting. Configures a CSG2 content billing service, and enters CSG2 service configuration mode.
A-17
Appendix A basis
basis
To specify the billing basis for a CSG2 content billing service, use the basis command in CSG2 service configuration mode. To use the default billing basis, use the no form of this command. basis {byte ip | byte tcp | fixed | second [connect | transaction]} [dual [byte ip | byte tcp | fixed | second transaction}]] no basis {byte ip | byte tcp | fixed | second [connect | transaction]} [dual [byte ip | byte tcp | fixed | second transaction}]]
Syntax Description
byte ip byte tcp
(Optional) Billing charge is a function of the IP data volume processed during the subscribers session. This is the default setting. (Optional) Billing charge is a function of the TCP data volume processed during the subscribers session.
Note
Supplemental usage reporting always reports IP bytes, even if the billing basis is configured for TCP bytes.
fixed
(Optional) Billing charge is a fixed cost, which is deducted each time the first packet for a transaction matches a content-policy pair (that is, deducted for each request). (Optional) Billing charge is duration-based for the CSG2 service. Unless the connect keyword is also configured, the billing is for the service duration time. (Optional) Billing charge is based on connection duration time, not service duration time.
Note
second
connect
If you specify the connect keyword, the balance and consumed fields in the output of the show ip csg users command are updated only when there is a Service Reauthorization Request for new quota. The transaction keyword is valid for Session Initiation Protocol (SIP) only. If you specify the transaction keyword, you cannot specify the dual byte tcp option. That is, basis second transaction dual byte tcp is not a valid command.
transaction
(Optional) Billing charge is based on transaction duration time.

Note
dual byte ip byte tcp
(Optional) Configures the basis for dual quota, also known as the dual basis. (Optional) Billing charge for dual quota is a function of the IP data volume processed during the subscribers session. (Optional) Billing charge for dual quota is a function of the TCP data volume processed during the subscribers session.
Note
Supplemental usage reporting always reports IP bytes, even if the billing dual basis is configured for TCP bytes.
A-18
OL-22840-05
Appendix A
CSG2 Command Reference basis
fixed
(Optional) Billing charge for dual quota is a fixed cost, which is deducted each time the first packet for a transaction matches a content-policy pair (that is, deducted for each request). (Optional) Billing charge for dual quota is based on transaction duration time for the CSG2 service.
Note
second transaction
The second transaction keyword is valid for Session Initiation Protocol (SIP) only.
Command Default
The default setting is byte ip (billing charge is a function of the IP data volume processed). The dual quota is not configured.
Command Modes
Command History
Release 12.4(11)MD 12.4(15)MD 12.4(22)MD
Modification This command was migrated from CSG1. Changes from CSG1: The exclude mms keyword was removed. The transaction keyword was added. The dual keyword was added.
Usage Guidelines
For TCP billing, configuring basis byte tcp allows counting of only TCP payload and exclusion of overhead for network retransmission. With this option, the CSG2 excludes IP and TCP headers from volume counts. The byte counting is limited to TCP payload. Retransmitted packets are not counted. Services that are configured with the basis second connect command (that is, for Connection Duration Billing) are subject to the following restrictions:

Service verification is not supported for Connection Duration services. If redirect is to be performed when the Connection Duration service runs out of quota, the URL location to which the CSG2 redirects must map to a policy that does not have accounting configured. This is because all IP sessions mapped to policies with accounting configured (postpaid or prepaid) are dropped when the Connection Duration service has no quota. When a Service Duration Billing Service is a member of a billing plan, and an accounting definition is in service and downloaded to a CSG2 module, you cannot modify the basis or meter configuration. You are instructed at the console to configure no inservice on the downloaded Accounting definitions. If a content configuration is included in a service configured for basis second, the CSG2 restricts the content idle timeout to less than or equal to the service idle timeout for the service. The content idle time is not included in the last billable time for the service. The CSG2 does not allow you to specify weights for Service Duration Billing.
For Service Duration Billing:
A-19
Appendix A basis
Note
We recommend that you first remove the service from each billing plan, make the basis changes, and add it back to each billing plan. If you delete it, the service is automatically removed from each billing plan, and you must add it back to each plan after configuring it. To enable Connection Duration Billing for a service, configure the service name as a service under one or more billing plans in CSG2 billing configuration mode, then enter the basis second connect command in CSG2 service configuration mode. Because Internet Message Access Protocol (IMAP) metering is byte-based, you cannot configure both meter include imap and basis fixed or basis second in the same service. Only basis byte is meaningful with meter include imap. You cannot configure both meter exclude svc-idle and basis byte or basis fixed in the same service. Only basis second is meaningful with meter exclude svc-idle. The CSG2 enables you to charge two different billing bases (the plural of basis) for the same service. For example, you can charge for both time and volume. When a transaction is charged, quota is deducted from both configured bases. Both sets of quota are maintained and reported to the quota server. To enable dual quota, specify the dual keyword and configure the dual basis. When configuring dual quota, keep the following considerations in mind:

The two bases are known as the first basis and the dual basis. For dual basis, the first basis must be basis fixed, basis second, or basis second transaction. The first basis cannot be basis byte ip or basis byte tcp. If the first basis is basis fixed, the dual basis can be basis byte ip or basis byte tcp. If the first basis is basis second, the dual basis can be basis byte ip, basis byte tcp, basis fixed, or basis second transaction. If the first basis is basis second transaction, the dual basis can be basis byte ip or basis fixed. You can configure a reauthorization threshold for each basis, using the reauthorization threshold command in CSG2 service configuration mode. You can configure a passthrough quota grant for each basis, using the passthrough command in CSG2 service configuration mode. You can configure fixed-format CDRs, using the ip csg records format command in global configuration mode, but the CSG2 does not report the dual quota in fixed-format CDRs. If the first basis for a service is basis second, you cannot use metering that is mutually exclusive with duration-based billing, such as meter exclude mms wap or meter exclude control sip, in the same service.
Examples
The following example shows how to specify fixed billing for the CSG2 service MOVIES:
ip csg service MOVIES basis fixed
The following commands are used to configure Service Duration Billing for the OFF_NET service.
ip csg service OFF_NET basis second
A-20
OL-22840-05
Appendix A
CSG2 Command Reference basis
The following example shows how to bill for both duration and IP data volume for the CSG2 service DUALBILL:
ip csg service DUALBILL basis second dual byte ip
Related Commands
Command ip csg service meter exclude svc-idle meter include imap meter increment passthrough qct (CSG2 service) reauthorization threshold
Description Configures a CSG2 content billing service, and enters CSG2 service configuration mode. Excludes timers from the usage calculation. Specifies which Internet Message Access Protocol (IMAP) bytes are billed for when doing prepaid debits. Specifies the increments for debiting quota upon completion of a service configured for Service Duration Billing. Enables passthrough mode for a CSG2 service. Specifies a quota consumption time (QCT) for a CSG2 service. Specifies the CSG2 reauthorization threshold.
A-21
Appendix A block
block
To force the CSG2 to drop packets that do not match a configured billing policy, use the block command in CSG2 content configuration mode. To restore the default behavior, enabling the CSG2 to forward the packets without billing, use the no form of this command. block no block
Syntax Description
Command Default
None
Command Modes
Command History
Release 12.4(11)MD

The name of this command changed from ip csg block to block. The configuration mode for this command changed from global to CSG2 content configuration.
Usage Guidelines
By default, if packets do not match any billing policy, the CSG2 forwards the packets without billing. This command causes the CSG2 to drop the packets instead.
Examples
The following example shows how to force the CSG2 to drop packets that do not match any billing policy:
ip csg content MOVIES block
Related Commands
Command ip csg content ip csg policy parse length (CSG2 content)
Description Configures content for CSG2 services, and enters CSG2 content configuration mode. Defines a policy for qualifying flows for the CSG2 accounting services, and enters CSG2 policy configuration mode. Defines the maximum number of Layer 7 bytes that the CSG2 is to parse when attempting to assign a policy.
A-22
OL-22840-05
Appendix A
CSG2 Command Reference class (CSG2 header)
class (CSG2 header)

To specify the class to which a CSG2 header belongs, as well as the default header insertion behavior to use for user profiles that do not specify a default behavior, use the class command in CSG2 header configuration mode. To remove the class, use the no form of this command. class class-name {exclude | include} no class class-name
Syntax Description
class-name
Name of the class to which this header belongs. The user profile controls which classes are allowed to be inserted and which are not. The class name is not case-sensitive. Exclude this header when performing CSG2 header insertion for a user who does not specify a class name for include in the user profile. Include this header when performing CSG2 header insertion for a user who does not specify a class name for include in the user profile.
exclude include
Command Default
If a header does not belong to a class, the header is always included during insertion.
Command Modes
CSG2 header configuration
Command History
Release 12.4(24)MD
Usage Guidelines
This command is required when defining a CSG2 header. Each header can belong to a class of headers. A user's profile can specify by class name whether a class of headers is to be included or excluded when performing CSG2 header insertion When a configured header belongs to a class that is not specified in a user's profile, a default behavior is used. When you configure a header for the CSG2, you can assign it to a class of headers. This command enables you to specify a default include or exclude behavior for that class of headers. If a header belongs to a class that is not specified in a user's profile, the CSG2 applies a default behavior to the header. CSG2 determines whether to insert a class of headers for a subscriber as follows:
1.
For RADIUS, the CSG2 can use the Cisco subattribute 1 VSA (VSA 9 1) to extract a subscribers include or exclude for a class of headers. For more information, see the Parsing RADIUS VSA Subattributes for Header Insertion Inclusion and Exclusion section on page 9-8. If the subscribers data specifies include or exclude for the class of headers, the CSG2 uses that specification. If the subscribers data specifies both include and exclude for the class of headers, the CSG2 uses include for the class of headers.
A-23
Appendix A class (CSG2 header)
If a subscriber opts out for a class of headers, the CSG2 does not insert headers of that class into HTTP requests for that subscriber. If a subscriber has opted out for all classes of header, the CSG2 forwards traffic for that subscriber by proxy without inserting any headers. If a subscriber's data does not specify include or exclude for a class of headers, the CSG2 uses the configured default behavior for each header of that class, separately.
2.
If the subscribers data does not specify include or exclude for the class of headers, the CSG2 uses the configured default include or exclude for that class of headers, configured on the class command in CSG2 header configuration mode. For more information, see the Configuring a Header section on page 2-26. If there is no configured default include or exclude for the class of headers, the default behavior for the CSG2 is exclude. That is, the CSG2 does not insert that class of headers for that subscriber.
3.
To summarize the CSG2s include/exclude behavior for a class of headers: If the subscriber has specified include for a given class of header If the subscriber has specified exclude for a given class of header If the subscriber has specified both include and exclude for a given class of header And either include or exclude is The CSG2 inserts that class of configured on the class command for that headers for that subscriber. class of headers And either include or exclude is The CSG2 does not insert that configured on the class command for that class of headers for that class of headers subscriber. And either include or exclude is The CSG2 inserts that class of configured on the class command for that headers for that subscriber. class of headers The CSG2 inserts that class of headers for that subscriber. The CSG2 does not insert that class of headers for that subscriber.
If the subscriber has specified neither include And include is configured on the class nor exclude for a given class of header command for that class of headers If the subscriber has specified neither include And exclude is configured on the class nor exclude for a given class of header command for that class of headers
When you activate the inservice command in CSG2 service configuration mode, the CSG2 verifies that all headers configured for this service (via header-groups) are configured with valid name and class commands. If the CSG2 detects an error, the command fails.
Examples
The following example shows how to specify class testclassname with the include option:
class testclassname include
Related Commands
Command ip csg header
Description Defines a CSG2 header to be inserted in HTTP requests, and enters CSG2 header configuration mode.
A-24
OL-22840-05
Appendix A
CSG2 Command Reference class (CSG2 service)
class (CSG2 service)

To specify a service class value, use the class command in CSG2 service configuration mode. To remove the service class value, use the no form of this command. class value no class value
Syntax Description
value
Specifies a value in the range 1 to 255.
Command Default
None
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
The class command is used with fixed-record format to identify a service class value. This value is opaque to the CSG2 and has meaning only for the administrator. It is reported as tariff-class in fixed-record format call detail records (CDRs).
Examples
The following example specifies a class value for the service:

ip csg service FOO class 7
Related Commands
Command ip csg service ip csg transport-type assign mode ip csg records format owner (CSG2 service)
Description Configures a CSG2 content billing service, and enters CSG2 service configuration mode. Classifies data traffic on the basis of its access path. Specifies the mode for a CSG2 billing plan. Specifies variable or fixed CDR format. Specifies an identifier or name for a service owner.
A-25
Appendix A class-map (CSG2 policy)
class-map (CSG2 policy)

To associate a global class map with a CSG2 policy, use the class-map command in CSG2 policy configuration mode. To remove the association, use the no form of this command. class-map class-map-name no class-map class-map-name
Syntax Description
class-map-name
Name of the global class map to be associated with the policy.
Command Default
None
Command Modes
Command History
Release 12.4(22)MD
Usage Guidelines
This command is valid only if the policy is associated with a content that uses Network Based Application Recognition (NBAR) to classify sessions. (That is, the content must be configured with the parse protocol nbar command.) Otherwise, the CSG2 ignores the class map. You can associate one and only one global class map with a given policy. The CSG2 uses the policy class map and global class map to classify packets by matching packets to one or more specified protocols. If a packet matches one of the protocols, the CSG2 assigns the session whose packets match the associated NBAR content to the associated policy. The protocols to match are configured in a global class map. To configure a global class map, use the class-map command in global configuration mode.
Note
A global class map can match on fields other than the protocol (such as DSCP bits). However, the CSG2 supports matching on only protocols recognized by NBAR and supported by the CSG2. You can either configure maps (that is, attribute, header, method, or URL maps) on a given policy, or you can associate the policy with a class map; you cannot do both. If you do, the CSG2 ignores the configured maps.
Examples
The following example associates class map CLASS with policy POLICY:
ip csg policy POLICY class-map CLASS
A-26
OL-22840-05
Appendix A
CSG2 Command Reference class-map (CSG2 policy)
Related Commands
Description Defines a policy for qualifying flows for the CSG2 billing services, and enters CSG2 policy configuration mode.
A-27
Appendix A clear ip csg
clear ip csg
To clear the CSG2, use the clear ip csg command in privileged EXEC mode. clear ip csg { counters | dns map | event-trace packet | license warning | preload | sessions user [application] [ipv4-address ipv4-mask | ipv6 ipv6-prefix] | user [ all | {ipv4-address | ipv6 ipv6-prefix} {global | vrf vrf-name} ] }
Syntax Description
counters
Clears all CSG2 cumulative counters and statistics except the following:

CSG2 state counters are not cleared. For example, counters such as current number of sessions are not cleared. Peak rates of parameters are not cleared. Timestamps in traffic statistics are not cleared.
dns map event-trace packet
Clears the contents of the CSG2 Domain Name System (DNS) IP Map Table. Clears the contents of the packet buffer on a specific traffic processor (TP), if entered on a TP; or on all of the TPs, if entered on the control processor (CP). Prevents the CSG2 from generating license-exceeded system (syslog) messages, if the number of concurrent subscribers accessing the network exceeds the configured subscriber threshold. Removes all Gx policy preload objects from the CSG2 configuration. If configured on the active CSG2, this command also removes all Gx policy preload objects from any backup CSG2s.
license warning
preload
sessions user
Closes all subscriber sessions.
A-28
OL-22840-05
Appendix A
CSG2 Command Reference clear ip csg
application
(Optional) Closes subscriber sessions for only the specified application:

ftpCloses FTP subscriber sessions. httpCloses HTTP subscriber sessions. imapCloses IMAP subscriber sessions. nbarCloses subscriber sessions that were classified by Network Based Application Recognition (NBAR). otherCloses other subscriber sessions. pop3Closes POP3 subscriber sessions. rtspCloses RTSP subscriber sessions. sipCloses SIP subscriber sessions. smtpCloses SMTP subscriber sessions. wapCloses WAP subscriber sessions.
ipv4-address ip-mask
(Optional) Closes subscriber sessions for only the specified subscriber IPv4 address and subscriber IPv4 address mask. Specify IPv4 address 0.0.0.0 to close subscriber sessions for all subscriber IPv4 addresses. Specify IPv4 address mask 0 to close subscriber sessions for all subscriber IPv4 address masks.
ipv6 ipv6-prefix user all ipv4-address ipv6 ipv6-prefix global vrf vrf-name
(Optional) Closes subscriber sessions for only the specified subscriber IPv6 prefix. Closes all subscriber entries in the CSG2 User Table. (Optional) Closes all subscriber entries in the CSG2 User Table. (Optional) Closes only those subscriber entries in the CSG2 User Table that are associated with the specified IPv4 address. (Optional) Closes only those subscriber entries in the CSG2 User Table that are associated with the specified IPv6 prefix. (Optional) Closes all subscriber entries that are associated with the specified IPv4 or IPv6 address. (Optional) Closes only those subscriber entries that are associated with the specified IPv4 or IPv6 address and that are associated with the specified Virtual Routing and Forwarding (VRF) table.
Note
Command Default
None
Command Modes
Privileged EXEC
Command History
Release 12.4(11)MD
A-29
Appendix A clear ip csg
Release 12.4(15)MD 12.4(22)MD 12.4(22)MDA 12.4(24)MD 12.4(24)MDA
Modification The ftp keyword was added. The license warning keywords were added. The event-trace packet and preload keywords were added. The dns map keywords were added. The ipv6 keyword and ipv6-prefix argument were added for the sessions user and user keywords. The ip keyword was removed.
Usage Guidelines
By default, the CSG2 deletes 1000 User Table entries per second in response to the clear ip csg user all command. To specify a different deletion rate, use the ip csg radius on-off purge command in global configuration mode. If the event-trace packet option is configured, the CSG2 clears the contents of the packet buffer but does not otherwise change the packing logging settings. For example, if you configured the no-wrap option on the ip csg event-trace packet enable command, and packet logging then stopped automatically when the buffer became full, clearing the packet buffer does not restart packet logging. To restart packet logging, you must re-enter the ip csg event-trace packet enable command, with or without the no-wrap option. If the ip csg license warning-enable command is configured, and the number of concurrent subscribers accessing the network exceeds the configured subscriber threshold, the CSG2 generates a license-exceeded SNMP trap, and begins generating license-exceeded syslog messages. The CSG2 continues to generate license-exceeded syslog messages every five minutes, even if the number of concurrent subscribers accessing the network drops below the subscriber threshold, until one of the following actions occurs:
The CSG2 is prevented from generating the syslog messages, using the clear ip csg license warning command.
Note
The clear ip csg license warning command stops the generation of syslog messages until the limit is exceeded again. Therefore, if the current CSG2 User Table size is greater than the current configured value, and you enter the clear ip csg license warning command, the CSG2 begins generating notifications again when the next User Table entry is created. The CSG2 is prevented from generating the syslog messages, using the no form of the ip csg license syslog enable command in global configuration mode. The CSG2 is prevented from generating the SNMP traps, using the no form of the snmp-server enable traps csg license warning-enable command in global configuration mode. The subscriber threshold is changed, using the ip csg license warning-enable command in global configuration mode (or disabled, using the no form of the command).
We recommend that you configure the clear ip csg preload command only when directed to do so by Cisco Technical Assistance Center (TAC) engineers, and only when the Gx policy preload configuration is unusable and cannot be repaired through the Policy and Charging Rule Function (PCRF) interface.
Examples
The following example clears all counters and statistics for the CSG2:
clear ip csg counters
A-30
OL-22840-05
Appendix A
CSG2 Command Reference clear ip csg
The following example clears all sessions for application http and IPv4 address mask 1.2.3.4/32:
clear ip csg sessions user http 1.2.3.4/32
The following example clears sessions for application ftp and IPv6 subscriber 12AB:0000:0000:CD31:0000:0000:0000:0000/64:
clear ip csg sessions user ftp ipv6 12AB:0000:0000:CD31:0000:0000:0000:0000/64
The following example clears all subscriber entries from the CSG2 User Table that are associated with IPv4 address 1.2.3.4:
clear ip csg user 1.2.3.4
The following example clears all subscriber entries from the CSG2 User Table that are associated with IPv4 address 1.2.3.4 and that are also associated with VRF table AAA:
clear ip csg user 1.2.3.4 vrf AAA
The following example clears all subscriber entries from the CSG2 User Table that are associated with IPv6 prefix 12AB:0000:0000:CD31:0000:0000:0000:0000/64:
clear ip csg users ipv6 12AB:0000:0000:CD31:0000:0000:0000:0000 global
Related Commands
Command ip csg event-trace packet enable ip csg license syslog enable ip csg license warning-enable ip csg preload request
Description Enables the CSG2 to log packets. Enables the CSG2 to generate system (syslog) messages when the subscriber threshold is exceeded. Sets a subscriber threshold for the CSG2 to generate license-exceeded notifications. Configures a policy preloading retransmission delay and a retransmission number for the CSG2 to use when sending a Policy Preloading Request to the Policy and Charging Rule Function (PCRF). Displays information about the CSG2. Enables Simple Network Management Protocol (SNMP) notification types that are available on the CSG2
show ip csg snmp-server enable traps csg
A-31
Appendix A clear ip iscsi statistics
clear ip iscsi statistics

To clear current iSCSI statistics, use the clear ip iscsi statistics command in privileged EXEC mode. clear ip iscsi statistics
Syntax Description
Command Default
No default behavior or values.
Command Modes
Privileged EXEC
Command History
Release 12.4(15)MD
Examples
The following example clears iSCSI-related statistics:

clear ip iscsi statistics
Related Commands
Command show ip iscsi
Description Displays information about the iSCSI.
A-32
OL-22840-05
Appendix A
CSG2 Command Reference clear mpcc
clear mpcc
To clear the Mobile PCC error and statistics counters, use the clear mpcc command in privileged EXEC mode. clear mpcc [pcrf method-list-name | preload] {errors | stats}
Syntax Description
pcrf method-list-name
(Optional) Clears Mobile Policy Control & Charging (PCC) error or statistics counters for the specified Policy and Charging Rule Function (PCRF) method list name. (Optional) Clears Mobile PCC policy preloading error or statistics counters. Clears Mobile PCC error counters for the specified Mobile PCC component. Clears Mobile PCC statistics counters for the specified Mobile PCC component.
preload errors stats
Command Default
Clears Mobile PCC error or statistics counters at the global level.
Command Modes
Privileged EXEC
Command History
Release 12.4(22)MDA
Examples
The following example shows how to clear Mobile PCC statistics counters for PCRF method list service1-method-list1:
clear mpcc pcrf service1-method-list1 stats
A-33
Appendix A clear mpcc session
clear mpcc session

To clear a Mobile PCC session, use the clear mpcc session command in privileged EXEC mode. clear mpcc session {preload | user {all | session-id}}
Syntax Description
preload
Clears the Mobile Policy Control & Charging (PCC) policy preloading session. This clear command deletes the preload session or a specified subscriber session or all subscriber sessions.
user all user session-id
Clears all Mobile PCC subscriber sessions. Clears the specified Mobile PCC subscriber session.
Command Default
None.
Command Modes
Privileged EXEC
Command History
Release 12.4(22)MDA
Examples
The following example shows how to clear the Mobile PCC policy preloading session:
clear mpcc session preload
A-34
OL-22840-05
Appendix A
CSG2 Command Reference clear record-storage-module stats
clear record-storage-module stats

To clear current record storage module (RSM) statistics, use the clear record-storage-module stats command in privileged EXEC mode. clear record-storage-module stats
Syntax Description
Command Default
Command Modes
Privileged EXEC
Command History
Release 12.4(15)MD
Examples
The following example clears RSM-related statistics:

clear record-storage-module stats
Related Commands
Command show record-storage-module
Description Displays information about the record storage module (RSM).
A-35
Appendix A client-group (CSG2 content)
client-group (CSG2 content)

To reference a standard access list that is part of a CSG2 content, use the client-group command in CSG2 content configuration mode. To delete the reference, use the no form of this command. client-group {std-access-list-number | std-ipv4-access-list-name | ipv6 std-ipv6-access-list-name} no client-group {std-access-list-number | std-ipv4-access-list-name | ipv6 std-ipv6-access-list-name}
Syntax Description
std-access-list-number std-ipv4-access-list-name ipv6 std-ipv6-access-list-name
Standard IP access list number. The ranges are from 1 to 99 and from 1300 to 1999. Standard access list name for IPv4. Standard access list name for IPv6.
Command Default
All subscribers can access the content.
Command Modes
Command History
Release 12.4(11)MD

The configuration mode for this command changed from CSG policy configuration to CSG2 content configuration. The range for the std-access-list-number argument increased from 1300 to 1999.
12.4(24)MDA
The ipv6 keyword and std-ipv6-access-list-name argument were added.
Usage Guidelines
The client-group command is used to qualify subscribers for the CSG2 content. The conditions specified in the referenced access list must be true in order for the flows to be processed by the CSG2 content. If the conditions are not true, the CSG2 determines this to be a content mismatch, and normal content match processing continues (that is, the CSG2 tries to match a less specific content). If no contents are matched, the CSG2 does not process the flow (that is, the CSG2 blocks this traffic flow). If you reference an access list that includes a deny statement, and that deny statement is matched, then the CSG2 treats the traffic as a content mismatch and normal content processing continues, allowing the traffic to match another less specific content. For example, in the following configuration, packets from IPv4 address 1.1.1.1 do not match CONTENT1, but they do match CONTENT2:
ip csg content CONTENT1 ip any client-group 99 inservice ! ip csg content CONTENT2
A-36
OL-22840-05
Appendix A
CSG2 Command Reference client-group (CSG2 content)
ip any inservice ! access-list 99 deny 1.1.1.1 access-list 99 permit any
You can use next-hop with client groups as long as a given client group is always sent to the same next hop. You cannot send a given client group to two or more different next hops based on a content. The CSG2 searches contents with the same IP and VLAN configuration, but different client groups, in numerical order. For example, given two contents with the same IP/VLAN configuration, one referencing client group 4 and the other client group 7, the CSG2 matches the content that references client group 4.
Examples
The following example shows how to reference client group 44 for the CSG2 content MOVIES:
ip csg content MOVIES client-group 44
The following example shows how to reference IPv6 client group SERVER for the CSG2 content MOVIES:
ip csg content MOVIES client-group ipv6 SERVER
Related Commands
Command ip csg content ipv6 (CSG2 content) next-hop (CSG2 content)
Description Configures content for CSG2 services, and enters CSG2 content configuration mode. Defines the subset of Layer 3 and Layer 4 flows that can be processed by the CSG2 accounting services using IPv6 addressing. Defines a next-hop IPv4 or IPv6 address.
A-37
Appendix A content (CSG2 service)
content (CSG2 service)

To configure a content and policy as a member of a CSG2 billing service, and optionally to assign a weight to this content, use the content command in CSG2 service configuration mode. To remove a content name from the billing service, use the no form of this command. content content-name policy policy-name [weight weight-value] no content content-name policy policy-name
Syntax Description
content-name
Name of the content for this service. The name can be from 1 to 15 characters long, and can include uppercase or lowercase letters (the CSG2 changes all letters to uppercase), numbers, and any special characters. Name of a configured policy to apply to the content for this service. (Optional) Number of quadrans to deduct for each transaction. The range is from 0 to 32767. The default weight-value is 1 quadran.
policy policy-name weight weight-value
Command Default
The default weight-value is 1 quadran.
Command Modes
Command History
Release 12.4(11)MD
Modification This command was migrated from CSG1. Changes from CSG1: The weight-name argument was replaced with the weight-value argument.
Usage Guidelines
You must configure a policy before configuring this command. Content can reference more than one policy. Therefore, you can have multiple content commands with the same content-name argument, but different policy-name arguments. To make a specific content free, specify a weight-value of 0. Each content billing service is associated with one or more contents and policies. Multiple services can include the same content/policy pair, as long as the services are not associated with the same billing plan. They cannot be associated with the same billing plan because then the match of content/policy pair to service would not be unique.
Examples
The following example shows how to configure content for the CSG2 service MOVIES. In this example:

Policy MOVIES_COMEDY is applied to content MOVIES_COMEDY. Policy MOVIES_ACTION is applied to content MOVIES_ACTION. Content MOVIES_ACTION is given a billing weight of 2.
A-38
OL-22840-05
Appendix A
CSG2 Command Reference content (CSG2 service)
ip csg service MOVIES content MOVIES_COMEDY policy MOVIES_COMEDY content MOVIES_ACTION policy MOVIES_ACTION weight 2
Related Commands
Command ip csg content ip csg policy ip csg service
Description Configures content for CSG2 services, and enters CSG2 content configuration mode. Defines a policy for qualifying flows for the CSG2 accounting services, and enters CSG2 policy configuration mode. Configures a CSG2 content billing service, and enters CSG2 service configuration mode.
A-39
Appendix A control-url
control-url
To enable the CSG2 to use URL mapping to assign a policy to an RTSP control session, use the control-url command in CSG2 content configuration mode. To disable this option, use the no form of this command. control-url [interleaved] no control-url [interleaved]
Syntax Description
interleaved
(Optional) Use URL mapping to assign a policy to the control session only if the data is interleaved over the control session.
Command Default
Do not use URL mapping to assign a policy to an RTSP control session.
Command Modes
Command History
Release 12.4(22)MD
Usage Guidelines
This option is supported only for RTSP. If you enable policy assignment for URL maps for interleaved RTSP, all packets processed before the policy is assigned are passed and treated as pre-policy packets (that is, packets that cannot be associated with a policy).
Examples
The following example enables the CSG2 to use URL mapping when assigning a CSG2 policy to an RTSP control session:
ip csg content MOVIES_COMEDY control-url
Related Commands
Command ip csg content
Description Configures content for CSG2 services, and enters CSG2 content configuration mode.
A-40
OL-22840-05
Appendix A
CSG2 Command Reference csg start preload
csg start preload

To begin preloading policies for the CSG2 from the Policy and Charging Rule Function (PCRF), use the csg start preload command in privileged EXEC mode. csg start preload
Syntax Description
Command Default
None
Command Modes
Privileged EXEC
Command History
Release 12.4(22)MDA
Usage Guidelines
If configured to do so, the CSG2 preloads policies during boot-up. This command enables you to send a request to begin preloading policies without having to reload the CSG2. The standby CSG2 must have replicated all preloaded policy information before requesting replicated User Table, session, and service information from the active CSG2.
Examples
The following example begins preloading policies:

csg start preload
Related Commands
Command ip csg preload request
Description Configures a policy preloading retransmission delay and a retransmission number for the CSG2 to use when sending a Policy Preloading Request to the Policy and Charging Rule Function (PCRF).
A-41
Appendix A debug ip csg
debug ip csg
To set the flags to obtain debugging output for the various CSG2 components, use the debug ip csg command in privileged EXEC mode. To disable the debugging feature, use the no form of this command. debug ip csg { all | accel [detail] | acl {number | name acl-name} [vrf vrf-name | global] | configuration sync | content | crashinfo | dns [detail] | error | event-trace packet | frag | ftp | gtp { any | bma [priority] | ipc | psd | quota-server [priority] }| gx | header | http [detail] | imap | interm | ipc [detail] | iscsi [detail] | nbar | other | packet [dump] | policy | pop3 | preload | psd [detail] | qs [detail] | radius [detail] | replicate | rtsp [detail] | service [detail | ha] | session {event | state [detail]} | sip | smtp | stats | tlv | udb [xml] | users [detail] |
A-42
OL-22840-05
Appendix A
CSG2 Command Reference debug ip csg
wap [detail] | xml } no debug ip csg { all | accel [detail] | acl {number | name acl-name} [vrf vrf-name | global] | configuration sync | content | crashinfo | dns [detail] | error | event-trace packet | frag | ftp | gtp { any | bma [priority] | ipc | psd | quota-server [priority] }| gx | header | http [detail] | imap | interm | ipc [detail] | iscsi [detail] | nbar | other | packet [dump] | policy | pop3 | preload | psd [detail] | qs [detail] | radius [detail] | replicate | rtsp [detail] | service [detail | ha] | session {event | state [detail]} | sip | smtp | stats | tlv | udb [xml] | users [detail] |
A-43
wap [detail] | xml }
Syntax Description
all accel [detail]
Generates debugging output for all CSG2 components. Generates debugging output for accelerated sessions. To generate detailed debugging output for accelerated sessions, specify the optional detail keyword.
acl number acl name acl-name vrf vrf-name
Generates debugging output for all subscribers in the numbered simple access control list (ACL). Generates debugging output for all subscribers in the named simple access control list (ACL). (Optional) Generates debugging output for the Virtual Routing and Forwarding (VRF) table with the ACL.
Note
global configuration sync content
(Optional) Generates debugging output for the default routing table with the ACL. Generates debugging output for the configuration synchronization component. Generates debugging output for the CSG2 content debug messages, indicating the results of the content match algorithm. This output is filtered if debug ip csg acl has been configured. Generates debugging output for the crash information component. Generates debugging output for the Domain Name System (DNS) component. To generate detailed debugging output for the DNS component, specify the optional detail keyword.
crashinfo dns [detail]
error event-trace packet
Generates debugging output for situations that might indicate a problem. Generates debugging output for the packet logging component for a specific traffic processor (TP), if entered on a TP; or for all of the TPs, if entered on the control processor (CP). Generates debugging output for the CSG2 fragment database. Generates debugging output for the FTP component. Generates debugging output for the general packet radio service (GPRS) tunneling protocol (GTP) components interaction with components other than the Billing Mediation Agent (BMA), the Interprocessor Communication (IPC) component, the Persistent Storage Device (PSD) component, or the quota server. Generates debugging output for the GTP components interaction with the BMA. To generate detailed debugging output for the GTP components interaction with a specific BMA, specify the quota servers priority.
frag ftp gtp any
gtp bma [priority]
gtp ipc
Generates debugging output for the GTP components interaction with the IPC component.
A-44
OL-22840-05
Appendix A
gtp psd gtp quota-server [priority]
Generates debugging output for the GTP components interaction with the PSD component. Generates debugging output for the GTP components interaction with the quota server. To generate detailed debugging output for the GTP components interaction with a specific quota server, specify the quota servers priority.
gx header http [detail]
Generates debugging output for the Gx component. Generates debugging output for the header insertion component. Generates debugging output for the HTTP component. To generate detailed debugging output for the HTTP component, specify the optional detail keyword.
imap interm ipc [detail]
Generates debugging output for the Internet Message Access Protocol (IMAP) component. Generates debugging output for the intermediate CDRs component. Generates debugging output for the IPC component. To generate detailed debugging output for the IPC component, specify the optional detail keyword.
iscsi [detail]
Generates debugging output for the iSCSI component. To generate detailed debugging output for the iSCSI component, specify the optional detail keyword.
mail other packet [dump]
Generates debugging output for the mail component. Generates debugging output for other components. Generates debugging output for e-mail packets. To generate a dump of all inbound packets in hexadecimal format, specify the optional dump keyword.
policy pop3 preload psd [detail]
Generates debugging output for the policy component. Generates debugging output for the Post Office Protocol, version 3 (POP3) component. Generates debugging output for the Gx policy preloaded component. Generates debugging output for the PSD component. To generate detailed debugging output for the PSD component, specify the optional detail keyword.
qs [detail]
Generates debugging output for the quota server component. To generate detailed debugging output for the quota server component, including all packets to and from the quota server in both hexadecimal and ASCII formats, specify the optional detail keyword.
radius [detail]
Generates debugging output for the RADIUS component. To generate detailed debugging output for the RADIUS component, specify the optional detail keyword.
A-45
replicate
Generates debugging output for the high availability (HA) component, including stateful messages as well as stateless transitions and the dump/bulk synchronization processes. You can also use the following commands to debug the redundancy facility (RF), the RF for Interdevice redundancy (RF Interdev), and the Hot Standby Router Protocol (HSRP):

debug redundancy progression debug redundancy interdev debug standby
service [detail]
Generates debugging output for the subscriber services component. To generate detailed debugging output for the subscriber services component, specify the optional detail keyword.
Note
If you specify the detail keyword, the CSG2 might generate debugging output for every packet mapped to the service.
service [ha]
Generates debugging output for the subscriber services component. To generate debugging output for high availability (HA) replication for the subscriber services component, specify the optional ha keyword.
session event session state [detail]
Generates debugging output for the session event component. Generates debugging output for the session state component. To generate detailed debugging output for the session state component, specify the optional detail keyword.
rtsp [detail]
Generates debugging output for the Real Time Streaming Protocol (RTSP) component. To generate detailed debugging output for the RTSP component, specify the optional detail keyword.
sip smtp stats tlv udb [xml]
Generates debugging output for the Session Initiation Protocol (SIP) component. Generates debugging output for the Simple Mail Transfer Protocol (SMTP) component. Generates debugging output for the statistics component. Generates debugging output for the Tag-Length-Values (TLVs) component. Generates debugging output for the User Database (UDB) component. To generate debugging output for only the XML component, specify the optional xml keyword.
users [detail]
Generates debugging output for the subscriber component. To generate detailed debugging output for the subscriber component, specify the optional detail keyword.
wap [detail]
Generates debugging output for the wireless application protocol (WAP) component. To generate detailed debugging output for the WAP component, specify the optional detail keyword.
Command Default
The CSG2 generates no debugging output.
A-46
OL-22840-05
Appendix A
Command Modes
Privileged EXEC
Command History
Release 12.4(11)MD
The acl number, configuration sync, detail, dump, error, frag, global, ha, http, interm, ipc, mail, other, packet, priority, qs, replicate, service, session event, session state, stats, and vrf vrf-name, keywords and arguments were added. The any, bma, ipc, psd, and quota-server keywords were added for the gtp keyword. The agent, api, cpu, module number, quota, prepaid, record storage slot, and timer keywords and arguments were removed.
12.4(15)MD 12.4(22)MD 12.4(22)MDA 12.4(24)MD 12.4(24)MD1 12.4(24)MDA
The crashinfo, ftp, iscsi, mail, and sip keywords were added. The nbar keyword was added. The event-trace packet, gx, and preload keywords were added. The dns and header keywords were added. The detail keyword was added for the users keyword. The accel and name keywords and acl-name argument were added.
Usage Guidelines
To see most but not all debugging output, use the all option to turn on all debugging flags, and then use the no form of this command to exclude debugging output for any options that are not of interest to you. Restrict the output of other CSG2 debugging commands to subscribers specified in the ACL. Once the debug flags are set, they are automatically sent to the CSG2 cards when a configuration is downloaded. Similarly, changes in the debug settings are sent to the CSG2 cards that are being debugged. When generating debugging output for ACL (that is, configuring the acl keyword), keep the following considerations in mind:
Generating debugging output for ACL disables all of the following types of debugging:
Configuration Error GTP IPC PSD RADIUS Replicate Statistics TLV UDB
A-47
You can generate debugging output independently for IPv4 and IPv6 ACLs. The CSG2 supports debugging for standard IOS ACLs both numbered (IPv4, using the number option) and named (IPv4 or IPv6, using the name acl-name option). For consistency, only the source address is considered for IPv6 ACLs; the destination address should be any. If configured, the VRF table must support the respective address family, either IPv4 or IPv6. If you do not specify an ACL with the VRF table, the table applies to any address family that does not already have an ACL configured and that is supported by the table.
You can use the show debug command to display the debug flag settings.
Note
You must re-enter the debug command after every reload because it is not saved in the startup configuration.
Examples
The following example shows how to turn on debugging for rtsp and udb:
debug ip csg rtsp debug ip csg udb
A-48
OL-22840-05
Appendix A
CSG2 Command Reference debug mpcc
debug mpcc
To set the flags to obtain debugging output for the various Mobile PCC components, use the debug mpcc command in privileged EXEC mode. To disable the debugging feature, use the no form of this command. debug mpcc {all | pcrf method-list-name}
Syntax Description
all pcrf method-list-name
Generates debugging output for all Mobile Policy Control & Charging (PCC) components. Generates debugging output for the specified Policy and Charging Rule Function (PCRF) method list name.
Command Default
None.
Command Modes
Privileged EXEC
Command History
Release 12.4(22)MDA
Examples
The following example shows how to obtain debugging output for PCRF method list service1-method-list1:
debug mpcc pcrf service1-method-list1
A-49
Appendix A domain group (CSG2 content)
domain group (CSG2 content)

To associate a CSG2 content with a Domain Name System (DNS) domain group, use the domain group command in CSG2 content configuration mode. To restore the default setting, use the no form of this command. domain group domain-group-name no domain group domain-group-name
Syntax Description
domain-group-name
Name of the domain group to be associated with the content.
Command Default
The content is not associated with a DNS domain group.
Command Modes
Command History
Release 12.4(24)MD
Usage Guidelines
Before configuring the domain group command, ensure that the following conditions are all met:

The content must be taken out of service. The domain group must be defined, using the ip csg domain group command in global configuration mode. Global domain mining must be enabled for the CSG2, using the ip csg domain mining command in global configuration mode. The DNS IP Map Table must be enabled, using the mining command in CSG2 content configuration mode. It can take time to fully populate the DNS IP Map Table. Therefore, we recommend that you configure a catchall content to match all traffic, using the ip any command, to handle sessions until the DNS mapping table is fully populated If you use this command to associate a content with a DNS domain group, and you also configure an IPv4 subnet for the content using the ip ipv4-address ipv4-mask command, then a session matches the content only if it matches both the domain group and the subnet. Therefore, we recommend that you specify ip any for any contents that are associated with a domain group. When matching contents, the ip command takes precedence over the domain group command, and the domain group command takes precedence over all of the other commands in CSG2 content configuration mode.
When configuring the domain group command, keep the following considerations in mind:
A-50
OL-22840-05
Appendix A
CSG2 Command Reference domain group (CSG2 content)
For example, given the following contents:

CONTENT1 is configured with the ip command but is not configured with the domain group
command.
CONTENT2 is configured with the ip any command and is configured with the domain group
command If a session could match either content, the CSG2 chooses CONTENT1 for the match, because the ip command takes precedence over the domain group command. On the other hand, given the following contents:
CONTENT3 is configured with the domain group command but is not configured with the
parse protocol dns command (or any other command in CSG2 content configuration mode).
CONTENT4 is configured with the parse protocol command but is not configured with the
domain group command. If a session could match either content, the CSG2 chooses CONTENT3 for the match, because the domain group command takes precedence over the parse protocol dns command (or any other command in CSG2 content configuration mode, other than the ip command).
Examples
The following example shows how to associate content CONTENT2 with domain group DNS-GRP1:
ip csg billing CONTENT2 domain group DNS-GRP1
Related Commands
Command ip csg content ip csg domain group mining (CSG2 content)
Description Configures content for CSG2 accounting services, and enters CSG2 content configuration mode. Defines a CSG2 domain group, and enters CSG2 domain group configuration mode. Enables domain name mining for the CSG2 content.
A-51
Appendix A encrypt (CSG2 header)
encrypt (CSG2 header)

To specify when encryption is to begin and end for a CSG2 header, use the encrypt command in CSG2 header configuration mode. To remove the encryption specification, use the no form of this command. encrypt {begin | end} no encrypt {begin | end}
Syntax Description
begin end
Indicates the beginning of encryption for a CSG2 header. Indicates the end of encryption for a CSG2 header.
Command Default
If you specify encrypt begin for a CSG2 header, but you do not specify encrypt end for the header, encryption continues to the end of the header configuration.
Command Modes
Command History
Release 12.4(24)MD
Usage Guidelines
This command is optional for a CSG2 header. If you specify no encrypt begin, the corresponding encrypt end is also removed. If you specify no encrypt end, only encrypt end is removed. The corresponding encrypt begin is not removed.
Examples
The following example shows how to begin encryption for a CSG2 header:
encrypt begin
The following example shows how to end encryption for a CSG2 header:
encrypt end
Related Commands
A-52
OL-22840-05
Appendix A
CSG2 Command Reference entries user idle
entries user idle

To set the time after which entries for idle subscribers are deleted from the CSG2 User Table, use the entries user idle command in CSG2 billing configuration mode. To use the default settings, use the no form of this command. entries user idle duration [pod] no entries user idle
Syntax Description
idle duration
Number of seconds after which entries for idle subscribers are deleted from the CSG2 User Table. The range is from 0 (entries never idle out) to 2147483647. The default setting is 0 (entries never idle out). (Optional) Specifies whether the CSG2 is to send the RADIUS Packet of Disconnect message when an entry idles out.
pod
Command Default
The default idle duration is 0 seconds, and the CSG2 does not send the RADIUS Packet of Disconnect message when an entry idles out.
Command Modes
CSG2 billing configuration
Command History
Release 12.4(11)MD
Modification This command was migrated from CSG1. Changes from CSG1: The name of this command changed from entries idle (CSG2 billing) to entries user idle.
Usage Guidelines
The CSG2 User Table identifies all subscribers known to the CSG2. The table is populated on the basis of the contents of RADIUS Accounting Start messages, or from the user database, if either feature is enabled in your configuration. When setting the entry idle timer, keep the following considerations in mind:
You can set the entry idle timer either globally, using the ip csg entries user idle command in global configuration mode, or in each billing plan, using the entries user idle command. If you do not set the timer in the billing plan, the CSG2 uses the global timer. That is, if there is an entry idle timer value in the billing plan, it is used; otherwise, if there is a global entry idle timer value configured, it is used. If set, the idle timer starts when there are no billable sessions, and restarts whenever a RADIUS Accounting Start or a RADIUS Interim Accounting message is received. The timer stops when a billable session is started. If you do not specify the pod keyword, the CSG2 deletes the idle entry when the timer expires. If you specify the pod keyword, and if RADIUS Packet of Disconnect (PoD) is configured for the CSG2, the CSG2 sends a PoD message when the idle timer expires. The CSG2 deletes the idle entry when the PoD message is ACKed, NAKed, or when all retries have been sent.
A-53
Appendix A entries user idle
If Connection Duration Billing is enabled, you can use either the billing plan entry idle timer or the global entry idle timer to release a subscriber connection.
Examples
The following example shows how to specify an entry idle time of 1 hour for CSG2 billing plan REGULAR:
ip csg billing REGULAR entries user idle 3600
Related Commands
Command ip csg billing ip csg entries user idle ip csg radius pod attribute ip csg radius pod nas ip csg radius pod timeout
Description Defines a CSG2 billing plan, and enters CSG2 billing configuration mode. Specifies how long the CSG2 is to retain entries in the CSG2 User Table. Specifies the RADIUS attributes to be copied from the RADIUS Start message and sent to the NAS in the PoD message. Specifies the NAS port to which the CSG2 is to send the PoD message, and the key to use in calculating the Authenticator. Specifies the number of times to retry the RADIUS PoD message if it is not acknowledged by means of an ACK message, and the interval between retransmissions. Specifies that the CSG2 is to be a proxy for RADIUS messages. Specifies the mode for a CSG2 billing plan. Associates a Quality of Service (QoS) profile with a CSG2 billing plan. Associates a service with a CSG2 billing plan. Designates a CSG2 billing plan as the default billing plan.
ip csg radius proxy mode qos profile (CSG2 billing) service user-default
A-54
OL-22840-05
Appendix A
CSG2 Command Reference flags
flags
To specify protocol flag bit masks and values for CSG2 Prepaid Error Reimbursement, use the flags command in CSG2 refund configuration mode. To remove the flags, use the no form of this command. flags {dns | ip mask | tcp mask | wap} value no flags {dns | ip mask | tcp mask | wap} value
Syntax Description
dns ip tcp wap mask
Enables refunding for all Domain Name System (DNS) protocol transactions that do not complete successfully. Enables refunding for all IP protocol connections other than TCP or WAP. Enables refunding for all TCP connections Enables refunding for all wireless application protocol (WAP) connections. The mask for an ip or tcp flag must match that reported to the Billing Mediation Agent (BMA) for connection termination. The range for mask is from 0x01 to 0xFF. The value for a dns, ip, tcp, or wap flag, which must match that reported to the BMA for connection termination.

value
For a dns flag, the range for value is from 0x00 to 0x01. For an ip or tcp flag, the range for value is from 0x00 to 0xFF. For a wap flag, value can be 0x00, 0x01, 0x02, or 0x04.
Command Default
None
Command Modes
CSG2 refund configuration
Command History
Release 12.4(11)MD 12.4(24)MD
Modification This command was migrated from CSG1. Changes from CSG1: None. The dns keyword was added.
Usage Guidelines
The CSG2 supports flag-based refunding for all protocols. The dns flag values are:

0x00: Refunding is enabled for successful transactions. 0x01: Refunding is enabled for failed transactions (unanswered DNS queries).
A-55
Appendix A flags
The ip flag values are:
0x01: Connection initiator.

0: The connection was initiated by the subscriber. The source address is associated with the user
ID.
1: The connection was initiated by the network. The destination address is associated with the
user ID.
0x80: Connection terminated because of lack of authorization failure.

0: The connection was not terminated as a result of an authorization failure. 1: The connection was terminated as a result of an authorization failure.
0x7E: Reserved. 0x01: Connection initiator.

0: The connection was initiated by the subscriber. The source address is associated with the user
The tcp flag values are:
ID.
1: The connection was initiated by the network. The destination address is associated with the
user ID.
0x02: TCP termination type.

0: Normal TCP termination (FIN or RST). 1: Connection timed out.
0x04: Persistent Connection (multiple sequential transactions per TCP connection).

0: The reported connection is not a persistent connection. 1: The reported connection is a persistent connection.
0x08: Destination Initiated Close (valid only if TCP termination type is 0).
0: The connection teardown was initiated by the source IP in the flow. 1: The connection teardown was initiated by the destination IP in the flow.
0x10: Destination Side FIN (valid only if TCP termination type is 0).
0: The destination side never sent a FIN (it might have sent an RST). 1: The destination side sent a FIN.
0x20: Source Side FIN (valid only if TCP termination type is 0).
0: The source side never sent a FIN (it might have sent an RST). 1: The source side sent a FIN.
0x40: Connection not closed (valid only for HTTP 1.1).

0: The connection has been closed. 1: The connection is not closed yet, and TCP close bits have no meaning.
0x80: Connection terminated because of lack of authorization failure.

0: The connection was not terminated as a result of an authorization failure. 1: The connection was terminated as a result of an authorization failure.
A-56
OL-22840-05
Appendix A
CSG2 Command Reference flags
The wap flag values are:

0x00: Normal. 0x01: Aborted. 0x02: Incomplete. 0x04: Forced abort.
Examples
The following example shows how to set flags for DNS, IP, TCP, and WAP:
ip csg flags flags flags flags refund COMPANY-REFUND dns 0 ip 80 80 tcp 43 00 wap 04
Related Commands
Command ip csg refund retcode
Description Specifies the CSG2 refund policy to apply to the various services, and enters CSG2 refund configuration mode. Specifies the range of application return codes for which the CSG2 refunds quota for Prepaid Error Reimbursement.
A-57
Appendix A header (CSG2 header-group)
header (CSG2 header-group)

To include a header in a CSG2 header group, use the header command in CSG2 header-group configuration mode. To delete a header from a header group, use the no form of this command. header header-name no header header-name
Syntax Description
header-name
Name of the header. The name can be from 1 to 15 characters long, and can include uppercase or lowercase letters (CSG2 changes all letters to uppercase), numbers, and any special characters.
Command Default
None.
Command Modes
CSG2 header-group configuration
Command History
Release 12.4(24)MD
Usage Guidelines
You can configure many different header groups, each of which can include many different headers. However, the total number of header commands that you can configure on a given card is 4,000. That is, you can configure a single header-group of up to 4,000 headers; or one header group of 3500 headers and another of 500 headers; or any other combination of header groups and headers that does not exceed 4,000 total header commands. Duplicate header commands are included in the total. For example, if you include header HDR-TEST1 in five different header groups, that counts as five header inclusions, not just one. The headers that are defined for a header group are order-sensitive. Each header in a header group is inserted into the HTTP header, concatenated, in the order in which it was configured. For example, given the following configuration:
A-58
OL-22840-05
Appendix A
CSG2 Command Reference header (CSG2 header-group)
Examples
The following example shows how to include headers HDR-1, HDR-2, and HDR-3 in CSG2 header group HG-1:
Related Commands
Command ip csg header-group
Description Defines a CSG2 header group.
A-59
Appendix A header-group (CSG2 service)
header-group (CSG2 service)

To associate a CSG2 header group with a CSG2 service, use the header-group command in CSG2 service configuration mode. To remove the header group from the service, use the no form of this command. header-group header-group-name no header-group header-group-name
Syntax Description
header-name
Name of the header group to be associated with the service.
Command Default
No header group is associated with the service.
Command Modes
Command History
Release 12.4(24)MD
Usage Guidelines
You can associate more than one header group with a given service, and you can associate a header group with more than one service.
Examples
The following example shows how to associate header group HG-1 with service CSG2-SERVICE:
ip csg service CSG2-SERVICE header-group HG-1
Related Commands
Command ip csg header-group ip csg service
Description Defines a CSG2 header group. Configures a CSG2 service, and enters CSG2 service configuration mode.
A-60
OL-22840-05
Appendix A
CSG2 Command Reference idle (CSG2 content)
idle (CSG2 content)

To specify the minimum amount of time that the CSG2 maintains an idle content connection, use the idle command in CSG2 content configuration mode. To restore the default idle duration value, use the no form of this command. idle duration no idle duration
Syntax Description
duration
Content idle timer duration in seconds. If no packets are received on a content connection for more than duration seconds, the CSG2 assumes the connection is idle and ends the connection. The range is from 4 to 65535. The default is 300.
Command Default
The default idle duration is 300 seconds (5 minutes).
Command Modes
Command History
Release 12.4(11)MD
Modification This command was migrated from CSG1. Changes from CSG1: The default setting for the duration argument changed from 3600 seconds to 300 seconds.
Usage Guidelines
Real Time Streaming Protocol (RTSP) billing in the CSG2 is based on inspection of the RTSP SETUP and TEARDOWN messages that are exchanged between the subscriber and network. The CSG2 builds the RTSP call detail record (CDR) immediately after the RTSP TEARDOWN signal if the URL exactly matches that from the RTSP SETUP signal. Otherwise, the CSG2 builds the CDR after any condition that causes the flows to be terminated, as when a service_stop is triggered (for example, when the access network sends a RADIUS Accounting Stop for the subscriber). For RTSP, do not set the idle timer duration to less than 60 seconds. When using HTTP as the transport for RTSP, the control connection is used sparingly and might time out, causing the stream to become unresponsive. This occurs because the subscriber opens two TCP connections, one for the main content and one for control. The subscriber uses the control connection sparingly, which can cause the connection to time out. To prevent this problem, ensure that the content idle timer has a duration of at least 60 seconds (the default setting is 300 seconds). This is not an issue when using UDP or TCP as the transport. The CSG2 tracks usage on a per-session basis. User Datagram Protocol (UDP) does not have an end-of-session indicator and simply idles out. For that reason, for UDP and wireless application protocol 1.x (WAP 1.x), setting the content idle timer to a low value (for example, 30) allows the CSG2
A-61
Appendix A idle (CSG2 content)
to quickly recognize that a session has ended and to generate billing records accordingly. Other service-level features of the CSG2 that count sessions (such as passthrough mode and service-level CDRs) are similarly affected by the content idle timer setting. For TCP, the CSG2 does not send a reset (RST) until a packet is received. For a service configured with basis second, make sure the idle timeout value for the content configuration, set using the idle command in CSG2 content configuration mode, does not exceed the service idle timeout value, set using the idle command in CSG2 service configuration mode. Examples of these contents include:

Non-TCP contents TCP contents with policies for HTTP or WAP 2.0 where the subscriber or network does not close the TCP connection at the end of the transaction
Examples
The following example shows how to configure a 120-second idle timer for the CSG2 content MOVIES_COMEDY:
ip csg content MOVIES_COMEDY idle 120
Related Commands
Command idle (CSG2 service) ip csg content pending (CSG2 content)
Description Specifies the minimum amount of time that the CSG2 maintains a service with no subscriber sessions. Configures content for CSG2 services, and enters CSG2 content configuration mode. Sets the pending connection timeout.
A-62
OL-22840-05
Appendix A
CSG2 Command Reference idle (CSG2 service)
idle (CSG2 service)

To specify the minimum amount of time that the CSG2 maintains a service with no subscriber sessions, use the idle command in CSG2 service configuration mode. To restore the default idle duration value, use the no form of this command. idle duration no idle duration
Syntax Description
duration
Service idle timer duration, in seconds. The timer begins when there are no sessions. If a subscribers quota for a service is unused for more than duration seconds, the CSG2 assumes that the service is idle and sends a Service Stop to free up the resources. The range is from 0 to 4294967295. Specifying 0 disables the timer. The default is 300.
Command Default
The default idle duration is 300 seconds (5 minutes).
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
For services configured with basis second, make sure the idle timeout value for the content configurations, set using the idle command in CSG2 content configuration mode, does not exceed the service idle timeout value, set using the idle command in CSG2 service configuration mode. Examples of these contents include:

Non-TCP contents TCP contents with policies for HTTP or WAP 2.0 where the subscriber or network does not close the TCP connection at the end of the transaction
If a subscriber's quota for a service is unused for more than the service idle timer duration, the CSG2 assumes that the service is idle and sends a ServiceStop to free up quota. For RTSP, do not set the idle timer duration to less than 60 seconds.
Examples
The following example shows how to configure a 120-second idle timer for the CSG2 service MOVIES:
ip csg service MOVIES idle 120
A-63
Appendix A idle (CSG2 service)
Related Commands
Command idle (CSG2 content) ip csg service lifetime (CSG2 service) pending (CSG2 content)
Description Specifies the minimum amount of time that the CSG2 maintains an idle content connection. Configures a CSG2 content billing service, and enters CSG2 service configuration mode. Specifies a maximum duration, or lifetime, for a CSG2 service. Sets the pending connection timeout.
A-64
OL-22840-05
Appendix A
CSG2 Command Reference insert header-group (CSG2 policy)
insert header-group (CSG2 policy)

To define a header group for a CSG2 policy, use the insert header-group command in CSG2 policy configuration mode. To delete the header group from the policy, use the no form of this command. insert header-group header-group-name no insert header-group header-group-name
Syntax Description
header-group-name
Name of the header group. The name can be from 1 to 15 characters long, and can include uppercase or lowercase letters (the CSG2 changes all letters to uppercase), numbers, and any special characters.
Command Default
No header group is defined for the policy.
Command Modes
Command History
Release 12.4(24)MD
Usage Guidelines
Use this command to enable the CSG2 to insert headers, associated with the specified header group, into requests for subscribers flows that match the policy.
Examples
The following example shows how to define header group HG-1 for CSG2 policy P-HOST:
ip csg policy P-HOST accounting customer-string string1 insert header-group HG-1
Related Commands
A-65
Appendix A inservice (CSG2 content)
inservice (CSG2 content)

To activate the content service on each CSG2, use the inservice command in CSG2 content configuration mode. To suspend the content service, use the no form of this command. inservice no inservice
Syntax Description
Command Default
The default value is no inservice.
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
When you activate the inservice command, the CSG2 verifies the parameters semantically. If the CSG2 detects an error, the command fails. If there are sessions on a content, and you take the content out of service (with the no inservice command), the CSG2 does not allow the content to be placed back in service (with the inservice command) until the sessions have been cleaned up. If you try to enter the inservice command before the CSG2 has cleaned up the sessions, the command fails.
Examples
The following example shows how to place the CSG2 content MOVIES_COMEDY in service:
ip csg content MOVIES_COMEDY inservice
Related Commands
A-66
OL-22840-05
Appendix A
CSG2 Command Reference ip (CSG2 content)
ip (CSG2 content)
To define the subset of Layer 3 and Layer 4 flows that can be processed by the CSG2 accounting services using IPv4 addressing, use the ip command in CSG2 content configuration mode. To delete the flow definition, use the no form of this command. ip {any | ipv4-address [ipv4-mask]} [any | protocol [port-number [last-port-number]]] no ip {any | ipv4-address}
Syntax Description
any ipv4-address ipv4-mask
All Layer 3 and Layer 4 flows can be processed. This is the default setting. IPv4 address for which Layer 3 and Layer 4 flows can be processed. (Optional) Mask that identifies the network for which Layer 3 and Layer 4 flows can be processed. You can express the network mask in either IPv4 dotted notation (n.n.n.n) or prefix notation (/nn, where nn is the number of leading 1-bits). For example, 255.255.0.0 and /16 are equivalent network masks. The default network mask is 255.255.255.255 or /32, which means flows to a specific host can be processed.
any protocol
(Optional) All protocol types of Layer 3 and Layer 4 flows can be processed. This is the default setting. (Optional) Protocol type of Layer 3 and Layer 4 flows that can be processed:

anyFlows of any protocol type can be processed. This is the default setting. tcpOnly TCP flows can be processed. udpOnly User Datagram Protocol (UDP) flows can be processed. protocol-numberNumber identifying the protocol whose flows can be processed. The range is from 0 to 255, where 0 means the same as any.
port-number
(Optional) Specifies the beginning of the range of port numbers for which Layer 3 and Layer 4 flows can be processed. The range is from 0 to 65535, where 0 indicates that flows from any port number can be processed. (Optional) Specifies the end of the range of port numbers, The range is from port-number to 65535. If you are specifying a single port number, do not specify last-port-number.
last-port-number
Command Default
If you do not specify this command or the ipv6 command, the content defaults to IPv4 and all Layer 3 and Layer 4 flows (that is, ip any). If you specify an IPv4 address but no network mask, the default network mask is 255.255.255.255 or /32 (flows to a specific host can be processed). If you do not specify a protocol, flows of any protocol type can be processed. If you specify a protocol but no port number, the default port number is 0, which means that flows from any port number can be processed. The CSG2 parses port numbers only when processing TCP and UDP traffic. For all other protocols, the CSG2 does not track the Layer 4 port.
A-67
Appendix A ip (CSG2 content)
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
This command is required to place an IPv4 content in service. UDP ports 9200 and 9201 are well-known Wireless Session Protocol (WSP) and Wireless Transaction Protocol (WTP) wireless application protocol (WAP) ports. When a policy with parse protocol wap is associated with a content, use even-numbered UDP ports to designate WSP traffic, and use odd-numbered ports to designate WTP traffic. Although you can use this command to specify a port number for Layer 3 content (ip any any port-number), the CSG2 does not support Layer 3 content rules. The CSG2 ignores the specified port number, and the show ip csg content command displays the port number as 0. We recommend that all IPv4 content that is configured for NBAR processing (parse protocol nbar) also be configured to match all traffic, using the ip any command.
Examples
The following example shows how to specify that, for content MOVIES_COMEDY, only flows for IPv4 address 172.18.45.0/24 and TCP port 8080 are to be processed by the CSG2 accounting services:
ip csg content MOVIES_COMEDY ip 172.18.45.0/24 tcp 8080
Related Commands
Command ipv6 (CSG2 content) ip csg content
Description Defines the subset of Layer 3 and Layer 4 flows that can be processed by the CSG2 accounting services using IPv6 addressing. Configures content for CSG2 services, and enters CSG2 content configuration mode.
A-68
OL-22840-05
Appendix A
CSG2 Command Reference ip (iSCSI)
ip (iSCSI)
To specify the IPv4 address of an iSCSI target in the target interface profile on the CSG2, use the ip command in iSCSI configuration mode. To remove the IPv4 address configuration, use the no form of the command. ip ipv4-address no ip ipv4-address
Syntax Description
ipv4-address
IPv4 address of the iSCSI target.
Command Default
Command Modes
iSCSI configuration
Command History
Release 12.4(15)MD
Usage Guidelines
Only one target can be defined per profile.
Examples
The following example configures an iSCSI target interface profile with the name targetA to a SCSI target with the IPv4 address 10.0.0.1:
ip iscsi target-profile targetA name iqn.2002-10.edu.abc.iol.iscsi.draft20-target:1 ip 10.0.0.1 port 3260 session-timeout 120 target-portal 1
Related Commands
Command ip csg iscsi drain delay
Description Defines the delay interval, in seconds, before draining packets from the Storage Area Network (SAN) connected to the Internet Small Computer Systems Interface (iSCSI) when the Billing Mediation Agent (BMA) becomes active. Defines the number of packets to be drained from the Storage Area Network (SAN) connected to the Internet Small Computer Systems Interface (iSCSI) per drain delay interval when the Billing Mediation Agent (BMA) becomes active.
ip csg iscsi drain packet
A-69
Appendix A ip (iSCSI)
Command ip csg iscsi profile ip iscsi target-profile name (iSCSI) port (iSCSI) session-timeout (iSCSI) target-portal (iSCSI)
Description Specifies the Internet Small Computer Systems Interface (iSCSI) target to be used as backup storage for the CSG2. Creates an iSCSI profile for an iSCSI target on the CSG2, and enters iSCSI configuration mode. Specifies the name of an iSCSI target in the target profile on the CSG2 Specifies the number of the port on which to listen for iSCSI traffic in the iSCSI target interface profile on the CSG2. Specifies the session timeout for an iSCSI target in the target interface profile on the CSG2. Specifies the portal group tag for an iSCSI target in the target interface profile on the CSG2.
A-70
OL-22840-05
Appendix A
CSG2 Command Reference ip csg billing
ip csg billing
To define a CSG2 billing plan, and to enter CSG2 billing configuration mode, use the ip csg billing command in global configuration mode. To delete the billing plan, use the no form of this command. ip csg billing billing-plan-name no ip csg billing billing-plan-name
Syntax Description
billing-plan-name
Name of the billing plan, which is a set of services. When the CSG2 encounters a new subscriber, the CSG2 retrieves its billing plan. The name can be from 1 to 64 characters long, and can include uppercase or lowercase letters (the CSG2 changes all letters to uppercase), numbers, and any special characters.
Command Default
None
Command Modes
Global configuration
Command History
Release 12.4(11)MD
Usage Guidelines
You can define up to 128 billing plans. The characteristics of each billing plan are defined by the following commands:

entries user idle mode offline qos profile (CSG2 billing) service user-default
Examples
The following example shows how to define a CSG2 billing plan named REGULAR:
ip csg billing REGULAR
A-71
Appendix A ip csg billing
Related Commands
Command entries user idle mode offline qos profile (CSG2 billing) service user-default
Description Sets the time after which entries for idle subscribers are deleted from the CSG2 User Table. Specifies the mode for a CSG2 billing plan. Enables offline billing for a CSG2 billing plan. Associates a Quality of Service (QoS) profile with a CSG2 billing plan. Associates a service with a CSG2 billing plan. Designates a CSG2 billing plan as the default billing plan.
A-72
OL-22840-05
Appendix A
CSG2 Command Reference ip csg bma
ip csg bma
To configure the Billing Mediation Agents (BMAs) to which the CSG2 is to send billing records, use the ip csg bma command in CSG2 global configuration mode. To remove a BMA from the list of agents, use the no form of this command. ip csg bma [vrf vrf-name] ipv4-address port-number priority no ip csg bma [vrf vrf-name] ipv4-address port-number
Syntax Description
vrf vrf-name
(Optional) Virtual Routing and Forwarding (VRF) table which the CSG2 is to use to communicate with the BMA.
Note
ipv4-address
IPv4 address of the BMA you wish to define. When you configure a BMA, make sure that its IPv4 address and port number match on both the active CSG2 and the standby CSG2. You can configure multiple BMAs with the same IPv4 address, but the CSG2 does not support nodealive or redirect for multiple BMAs with the same IPv4 address.
port-number
Port number of the BMA you wish to define. The range is from 1 to 65535. The CSG2 differentiates BMAs on the basis of their port numbers. When you configure a BMA, make sure its port number matches on both the active CSG2 and the standby CSG2.
priority
Priority of the BMA you wish to define. The priority specifies the order of preference of the agents. A lower number indicates a higher priority. If the current agent becomes unusable, the CSG2 uses the highest priority BMA available. Priorities for different agents do not have to be sequential. That is, you can have three agents with priorities 1, 5, and 10. The range of priorities is from 1 to 1000.
Command Default
Active and standby BMAs are not defined. If no VRF table is specified, the CSG2 uses the global routing table to communicate with the BMA.
Command Modes
A-73
Appendix A ip csg bma
Command History
Release 12.4(11)MD

The name of this command changed from agent (CSG2 accounting) to ip csg bma. The vrf vrf-name keyword and argument were added.
Usage Guidelines
You must specify the BMA local port using the ip csg bma local-port command before you enter the ip csg bma command. Accounting records are sent only to the agents identified in the ip csg bma command. This provides a measure of security to ensure that records are not sent to unauthorized systems. General packet radio service (GPRS) tunneling protocol (GTP) prime (GTP) does not support nodealive or redirect for multiple agents with the same IPv4 address.
Note
You can configure multiple BMAs with the same IPv4 address, but the CSG2 does not support nodealive or redirect for multiple BMAs with the same IPv4 address.
Examples
The following example shows how to configure a BMA with priority 10 that uses VRF table BMAVRF:
ip csg bma vrf BMAVRF 1.2.3.4 5555 10
Related Commands
Command ip csg bma activate ip csg bma keepalive ip csg bma local-port ip csg bma messages
Description Enables support for multiple active BMAs. Defines the Billing Mediation Agent (BMA) keepalive time interval for the CSG2. Defines the port on which the CSG2 listens for packets from the BMAs. Specifies the maximum number of general packet radio service (GPRS) tunneling protocol prime (GTP) messages that the CSG2 can buffer for all Billing Mediation Agents (BMAs). Defines the Billing Mediation Agent (BMA) retransmit time interval for the CSG2. Defines the maximum number of Billing Mediation Agent (BMA) retries allowed before the CSG2 determines that the link has failed. Defines the Billing Mediation Agent (BMA) transmit window size for the CSG2.
ip csg bma retransmit ip csg bma retries ip csg bma window
A-74
OL-22840-05
Appendix A
CSG2 Command Reference ip csg bma activate
ip csg bma activate

To enable support for multiple active Billing Mediation Agents (BMAs), use the ip csg bma activate command in CSG2 global configuration mode. To disable support for multiple active BMAs, use the no form of this command. ip csg bma activate [number [sticky seconds]] no ip csg bma activate [number [sticky seconds]]
Syntax Description
number
(Optional) Number of BMAs that the CSG2 tries to activate at the same time. If you have defined more BMAs than number, and an active BMA fails, the BMA with the highest priority (lowest number) that is not already active is made active. The range is from 1 to 32. The default value is 1.
sticky seconds
(Optional) Number of seconds of inactivity after which a sticky object is to be deleted. The CSG2 creates a sticky object to ensure that all the billing records for a subscriber are sent to the same BMA. If the user ID is not available (for example, if the internal table is too small to hold all user ID entries, or if the CSG2 cannot access the user ID database), the CSG2 creates a sticky object for the subscriber IP address. This entry is removed from the table based on inactivity. Entries that contain a user ID do not age out; they are removed only by RADIUS messages. The range is from 1 to 64000. The default value is 30.
Command Default
The default value for number is 1. The default value for seconds is 30.
Command Modes
Command History
Release 12.4(11)MD

The name of this command changed from agent activate to ip csg bma activate. The range of the number argument changed from 1 to 10, to 1 to 32.
A-75
Appendix A ip csg bma activate
Usage Guidelines
Use this command to load-balance CDRs among multiple active BMAs. When the CSG2 uses multiple active BMAs, it sends all CDRs for a given user to a particular BMA. The CSG2 stores that BMA assignment in the CSG2 User Table entry for that user. For example, if a configuration has four active BMAs, and one of those BMAs fails, the CSG2 looks for a suitable standby BMA. If the CSG2 finds a suitable standby BMA, it transfers all of the CDRs from the failed BMA to the new BMA, and updates all of the affected User Table entries to reflect the new BMA assignment. However, if the CSG2 cannot find a suitable standby BMA, it redistributes all of the CDRs from the failed BMA among the remaining three active BMAs. It does so by finding the User Table entries for the affected users in the CDRs. The CSG2 then assigns one of the active BMAs to each affected user, and updates the User Table entries to reflect the new BMA assignments. The CSG2 reassigns all CDRs for a given user to the same BMA. If the CSG2 cannot find a User Table entry for a user (for example, the user has logged off), it creates a temporary sticky object as a placeholder and assigns a new BMA to the sticky object. This ensures that the remaining CDRs for that user are sent to the same BMA.
Note
This command is valid only if your CSG2 uses multiple active BMAs. If your CSG2 uses one and only one active BMA, the default settings are sufficient (that is, ip csg bma activate 1 sticky 30).
Examples
The following example shows how to enable support for multiple active BMAs for the CSG2 accounting service A1. In this example, up to two BMAs can be active at the same time, and the CSG2 deletes inactive sticky objects after 60 seconds:
ip csg bma activate 2 sticky 60
Related Commands
Command ip csg bma ip csg quota-server activate
Description Defines the Billing Mediation Agents (BMAs) to which the CSG2 is to send billing records Activates one or more quota servers.
A-76
OL-22840-05
Appendix A
CSG2 Command Reference ip csg bma keepalive
ip csg bma keepalive

To define the Billing Mediation Agent (BMA) keepalive time interval for the CSG2, use the ip csg bma keepalive command in global configuration mode. To reset the BMA keepalive timer to the default value, use the no form of this command. ip csg bma keepalive number-of-seconds no ip csg bma keepalive
Syntax Description
number-of-seconds
Time, in seconds, between BMA keepalives. The range is from 1 to 65535. The default value is 60.
Command Default
The default value is 60 seconds.
Command Modes
Command History
Release 12.4(11)MD

The name of this command changed from keepalive to ip csg bma keepalive. The configuration mode for this command changed from CSG accounting to global configuration.
Usage Guidelines
Examples
The following example shows how to specify a BMA keepalive time of 300 seconds:
ip csg bma keepalive 300
Related Commands
Command ip csg bma ip csg ipc keepalive ip csg psd keepalive ip csg quota-server keepalive
Description Defines the Billing Mediation Agents (BMAs) to which the CSG2 is to send billing records Defines the Interprocessor Communication (IPC) keepalive time interval for the CSG2. Defines the Cisco Persistent Storage Device (PSD) keepalive time interval for the CSG2. Defines the quota-server keepalive time interval for the CSG2.
A-77
Appendix A ip csg bma local-port
ip csg bma local-port

To define the port on which the CSG2 communicates with the Billing Mediation Agent (BMA), use the ip csg bma local-port command in CSG2 global configuration mode. To remove the port, use the no form of this command. ip csg bma local-port port-number no ip csg bma local-port
Syntax Description
port-number
Port number on which the BMA will listen. The range is from 1024 to 65535. 5000 is not a valid port number. The BMA local port number must be different from the Persistent Storage Device (PSD) local port number and from the quota server local port number (configured with the ip csg psd local-port command and the ip csg quota-server local-port command, respectively).
Command Default
No BMA local ports are configured.
Command Modes
Command History
Release 12.4(11)MD
Modification This command was migrated from CSG1. Changes from CSG1: The name of this command changed from agent local-port to ip csg bma local-port.
Usage Guidelines
You must specify the BMA local port using the ip csg bma local-port command before you enter the ip csg bma command. This command accommodates BMAs that configure a port number that is not the general packet radio service (GPRS) tunneling protocol (GTP) prime (GTP) default port (3386). You must configure a local port to activate BMAs. The local port must be unique with respect to all other configured local ports, such as the quota server local port.
Note
The CSG2 drops requests (such as nodealive, echo, and redirect requests) unless they come from a configured BMA IP address. The CSG2 also verifies IP addresses against the configured list of BMAs. If there is no match, the CSG2 drops the request. The CSG2 does not look at a requests source port; instead, the CSG2 replies to the same port from which the request came.
A-78
OL-22840-05
Appendix A
CSG2 Command Reference ip csg bma local-port
Examples
The following example shows how to specify local port 5555 as the port on which the CSG2 listens for the CSG2 accounting service A1:
ip csg bma local-port 5555
Related Commands
Command ip csg bma ip csg psd local-port ip csg quota-server local-port
Description Defines the Billing Mediation Agents (BMAs) to which the CSG2 is to send billing records Configures the local port on which the CSG2 communicates with the Cisco Persistent Storage Device (PSD). Configures the local port on which the CSG2 communicates with quota servers.
A-79
Appendix A ip csg bma messages
ip csg bma messages

To specify the maximum number of general packet radio service (GPRS) tunneling protocol prime (GTP) messages that the CSG2 can buffer for all Billing Mediation Agents (BMAs), use the ip csg bma messages command in global configuration mode. To restore the default setting, use the no form of this command. ip csg bma messages number no ip csg bma messages
Syntax Description
number
Maximum number of GTP messages that can be buffered for all BMAs. The range is from 1 to 65535. The default is 10000.
Command Default
The CSG2 buffers up to 10000 GTP messages.
Command Modes
Command History
Release 12.4(11)MD

The name of this command changed from records max to ip csg bma messages. The configuration mode for this command changed from CSG accounting to global configuration.
Usage Guidelines
We recommend that you change the number of GTP messages that can be buffered only when directed to do so by Cisco Technical Assistance Center (TAC) engineers. In most environments, the default value is the most appropriate setting. The CSG2 can buffer GTP messages in either the Cisco Persistent Storage Device (PSD) or in the Storage Area Network (SAN) connected to the Internet Small Computer Systems Interface (iSCSI), as configured. (For more information, see the Configuring PSD Support section on page 7-1 and the Configuring iSCSI Support section on page 8-1.) If the BMA GTP message buffer exceeds 75% of the number specified on this command, the CSG2 stops reading GTP messages from the PSD or SAN. When the buffer drops below the 75% threshold, the CSG2 again begins reading from the PSD or SAN, placing the buffered GTP messages in the BMA queue. For example, using the default setting for this command of 10,000 messages, the CSG2 can read from the PSD or SAN as long as the buffer contains less than 7,500 GTP messages75% of 10,000 messages.
A-80
OL-22840-05
Appendix A
CSG2 Command Reference ip csg bma messages
By default, the CSG2 limits the rate at which GTP messages are read from the PSD to 500 packets/second, and from the SAN to 167 packets/second. However, you can change those default rates. For more information, see the Configuring the PSD Packet Drain Settings section on page 7-2 and the Configuring the iSCSI Packet Drain Settings section on page 8-4.
Examples
The following example shows how to configure the CSG2 to buffer up to 12345 GTP messages:
ip csg bma messages 12345
Related Commands
Command ip csg bma ip csg iscsi drain delay
Description Defines the Billing Mediation Agents (BMAs) to which the CSG2 is to send billing records Defines the delay interval, in seconds, before draining packets from the Storage Area Network (SAN) connected to the Internet Small Computer Systems Interface (iSCSI) when the Billing Mediation Agent (BMA) becomes active. Defines the number of packets to be drained from the Storage Area Network (SAN) connected to the Internet Small Computer Systems Interface (iSCSI) per drain delay interval when the Billing Mediation Agent (BMA) becomes active. Defines the delay interval, in seconds, before draining packets from the Cisco Persistent Storage Device (PSD) when the Billing Mediation Agent (BMA) becomes active. Defines the number of packets to be drained from the Cisco Persistent Storage Device (PSD) per drain delay interval when the Billing Mediation Agent (BMA) becomes active. Specifies the maximum number of general packet radio service (GPRS) tunneling protocol prime (GTP) messages, beyond the size of the Billing Mediation Agent (BMA) message queue, that the CSG2 can buffer for the Cisco Persistent Storage Device (PSD). Specifies the maximum number of general packet radio service (GPRS) tunneling protocol prime (GTP) messages that the CSG2 can buffer for all quota servers.
ip csg psd drain delay
ip csg psd drain packet
ip csg psd margin
ip csg quota-server messages
A-81
Appendix A ip csg bma retransmit
ip csg bma retransmit

To define the Billing Mediation Agent (BMA) retransmit time interval for the CSG2, use the ip csg bma retransmit command in global configuration mode. To reset the BMA retransmit timer to the default value, use the no form of this command. ip csg bma retransmit number-of-seconds no ip csg bma retransmit
Syntax Description
number-of-seconds
Time, in seconds, between BMA retransmits. The range is from 2 to 65535. The default value is 4.
Command Default
Command Modes
Command History
Release 12.4(11)MD 12.4(15)MD
Modification This command was introduced. The range changed from 1 to 65535 to 2 to 65535.
Usage Guidelines
Examples
The following example shows how to specify a BMA retransmit time of 2 seconds:
ip csg bma retransmit 2
Related Commands
Command ip csg bma ip csg ipc retransmit ip csg psd retransmit
Description Defines the Billing Mediation Agents (BMAs) to which the CSG2 is to send billing records Defines the Interprocessor Communication (IPC) retransmit time interval for the CSG2. Defines the Cisco Persistent Storage Device (PSD) retransmit time interval for the CSG2.
ip csg quota-server retransmit Defines the quota server retransmit time interval for the CSG2.
A-82
OL-22840-05
Appendix A
CSG2 Command Reference ip csg bma retries
ip csg bma retries

To define the maximum number of Billing Mediation Agent (BMA) retries allowed before the CSG2 determines that the link has failed, use the ip csg bma retries command in global configuration mode. To reset the number of BMA retries to the default value, use the no form of this command. ip csg bma retries [packet] number-of-retries no ip csg bma retries
Syntax Description
packet number-of-retries
(Optional) Attempt to send a packet to the BMA the specified number of times, then discard the packet. Maximum number of BMA retries allowed by the CSG2. The range is from 1 to 65535. The default value is 3.
Command Default
The default value is 3 retries.
Command Modes
Command History
Release 12.4(11)MD 12.4(15)MD
Modification This command was introduced. The packet keyword was added.
Usage Guidelines
We recommend that you change the number of retries allowed only when directed to do so by Cisco Technical Assistance Center (TAC) engineers. In most environments, the default value is the most appropriate setting. By default, the CSG2 retries a packet forever; it never discards a packet. If you configure the ip csg bma retries packet command, the CSG2 tries to send a packet to the BMA the specified number of times, then discards the packet. (The first attempt to send a packet to the BMA is not counted as a retry.) For example, if you configure ip csg bma retries packet 4, the CSG2 tries to send a packet to the BMA five times before discarding it (the initial attempt plus four retries).
Examples
The following example shows how to allow two BMA retries:

ip csg bma retries 2
The following example shows how to allow the CSG2 to try to send a packet to the BMA four times, in addition to the initial attempt:
ip csg bma retries packet 4
A-83
Appendix A ip csg bma retries
Related Commands
Command ip csg bma ip csg ipc retries
Description Defines the Billing Mediation Agents (BMAs) to which the CSG2 is to send billing records Defines the maximum number of Interprocessor Communication (IPC) retries allowed before the CSG2 determines that the link has failed. Defines the maximum number of Cisco Persistent Storage Device (PSD) retries allowed before the CSG2 determines that the link has failed. Defines the maximum number of quota server retries allowed before the CSG2 determines that the link has failed.
ip csg psd retries
ip csg quota-server retries
A-84
OL-22840-05
Appendix A
CSG2 Command Reference ip csg bma window
ip csg bma window

To define the Billing Mediation Agent (BMA) transmit window size for the CSG2, use the ip csg bma window command in global configuration mode. To reset the BMA transmit window size to the default value, use the no form of this command. ip csg bma window {max window-size | min window-size | min auto} no ip csg bma window {max | min}
Syntax Description
max window-size min window-size min auto
Maximum size, in packets, of the BMA transmit window. The range is from 1 to 65535. The default value is 128. Minimum size, in packets, of the BMA transmit window. The range is from 1 to 65535. Specifies that the CSG2 is to determine the minimum size of the BMA transmit window automatically. The CSG2 keeps track of the maximum number of ACKs received in one response and sets that number as the minimum window.
Command Default
The default maximum window size is 128 packets. The default minimum window size is automatically determined by the CSG2.
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
Examples
The following example shows how to set the maximum BMA transmit window to 64 packets:
ip csg bma window max 64
Related Commands
Command ip csg bma ip csg psd window ip csg quota-server window
Description Defines the Billing Mediation Agents (BMAs) to which the CSG2 is to send billing records Defines the Cisco Persistent Storage Device (PSD) transmit window size for the CSG2. Defines the quota server transmit window size for the CSG2.
A-85
Appendix A ip csg case-sensitive
ip csg case-sensitive
To specify whether to treat CSG2 attribute, header, method, and URL match patterns as case-sensitive, use the ip csg case-sensitive command in global configuration mode. To disable case-sensitivity for CSG2 match patterns, use the no form of this command. ip csg case-sensitive no ip csg case-sensitive
Syntax Description
Command Default
CSG2 match patterns are case-sensitive.
Command Modes
Command History
Release 12.4(11)MD
Examples
The following example shows how to disable case-sensitivity for CSG2 match patterns:
no ip csg case-sensitive
Related Commands
Command match attribute (CSG2 map) match header (CSG2 map) match method (CSG2 map) match url (CSG2 map)
Description Specifies a Layer 7 protocol header attribute match pattern for a CSG2 billing map. Specifies a header match pattern for a CSG2 billing map. Specifies a method match pattern for a CSG2 billing map. Specifies a URL match pattern for a CSG2 billing map.
A-86
OL-22840-05
Appendix A
CSG2 Command Reference ip csg content
ip csg content
To configure content for CSG2 services, and to enter CSG2 content configuration mode, use the ip csg content command in global configuration mode. To delete the content configuration, use the no form of this command. ip csg content content-name no ip csg content content-name
Syntax Description
content-name
Name of the content. The name can be from 1 to 15 characters long, and can include uppercase or lowercase letters (the CSG2 changes all letters to uppercase), numbers, and any special characters.
Command Default
None
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
You can define up to 2048 contents. The characteristics of each content configuration are defined by the following commands:

accelerate block client-group (CSG2 content) control-url domain group (CSG2 content) idle (CSG2 content) inservice (CSG2 content) ip (CSG2 content) ipv6 (CSG2 content) mining (CSG2 content) mode tcp next-hop (CSG2 content) next-hop override (CSG2 content) normalize-url
A-87
Appendix A ip csg content
parse length (CSG2 content) parse protocol (CSG2 content) pending (CSG2 content) policy (CSG2 content) records delay records intermediate relative replicate (CSG2 content) subscriber-ip http-header x-forwarded-for (CSG2 content) vlan (CSG2 content) vrf (CSG2 content)
You cannot change characteristics for a content while it is in service. In order to determine the service for a subscriber, the CSG2 first matches a content with the first packet in a flow, then matches the policy. The CSG2 then uses the content, policy, and the subscribers billing plan to determine the service. If the content configuration does not match any service listed under a subscribers billing plan, the CSG2 considers the service to be either free or postpaid, and the CSG2 forwards the flow and does not try to authorize the subscriber with the quota server. If BMAs are configured, the CSG2 generates a per-transaction CDR. The CSG2 supports overlapping contents, as when one content is a subset of another. If one content overlaps another, the CSG2 selects the content that best matches the flow. For example, if you configure Content A with ip any and Content B with ip any tcp 80, the CSG2 matches TCP port 80 flows to Content B, because ip any tcp 80 is a more precise match than ip any. The CSG2 does not support duplicate contents. That is, you cannot configure two contents with identical configurations. For Domain Name System (DNS) domain name mining, the CSG2 does not allocate resources to the DNS IP Map Table until at least one content configured with parse protocol dns is brought inservice.
Examples
The following example shows how to define the CSG2 content named MOVIES_COMEDY:
ip csg content MOVIES_COMEDY
Related Commands
Command accelerate block client-group (CSG2 content) control-url
Description Enables acceleration for sessions that match a CSG2 content. Forces the CSG2 to drop packets that do not match a configured billing policy. References a standard access list that is part of a CSG2 content. Enables the CSG2 to use URL mapping to assign a policy to an RTSP control session.
A-88
OL-22840-05
Appendix A
CSG2 Command Reference ip csg content
Command domain group (CSG2 content) idle (CSG2 content) inservice (CSG2 content) ip (CSG2 content)
Description Associates a CSG2 content with a Domain Name System (DNS) domain group. Specifies the minimum amount of time that the CSG2 maintains an idle content connection. Activates the content service on each CSG2. Defines the subset of Layer 3 and Layer 4 flows that can be processed by the CSG2 accounting services using IPv4 addressing. Defines the subset of Layer 3 and Layer 4 flows that can be processed by the CSG2 accounting services using IPv6 addressing. Enables domain name mining for the CSG2 content. Specifies the mode for CSG2 TCP sessions. Defines a next-hop IPv4 or IPv6 address. Changes the order in which the CSG2 selects the next-hop IPv4 or IPv6 address. Enables URL map normalization for a CSG2 content. Defines the maximum number of Layer 7 bytes that the CSG2 is to parse when attempting to assign a policy. Defines how the CSG2 is to parse traffic for a content. Associates a CSG2 billing policy with a content. Specifies the delay before the CSG2 is to send the HTTP Statistics CDR. Enables the generation of CSG2 intermediate CDRs. Enables relative URI support for CSG2 URL matching. Replicates the connection state for all TCP connections to the CSG2 content servers on the standby system.
ipv6 (CSG2 content)
mining (CSG2 content) mode tcp next-hop (CSG2 content) next-hop override (CSG2 content) normalize-url parse length (CSG2 content) parse protocol (CSG2 content) policy (CSG2 content) records delay records intermediate relative replicate (CSG2 content)
subscriber-ip http-header x-forwarded-for Specifies that the CSG2 is to obtain the subscriber's IP address from the HTTP X-Forwarded-For header. (CSG2 content) vlan (CSG2 content) vrf (CSG2 content) Restricts the CSG2 billing content to a single source VLAN. Restricts the CSG2 content to packets within a single Virtual Routing and Forwarding (VRF) table.
A-89
Appendix A ip csg count retransmit ip
ip csg count retransmit ip

To enable the CSG2 to include IP bytes and packets for retransmitted TCP segments when counting IP bytes, use the ip csg count retransmit ip command in global configuration mode. To exclude IP bytes and packets for retransmitted TCP segments from the IP byte count, use the no form of this command. ip csg count retransmit ip no ip csg count retransmit ip
Syntax Description
Command Default
The CSG2 includes IP bytes and packets for retransmitted TCP segments when counting IP bytes.
Command Modes
Command History
Release 12.4(22)MD
Usage Guidelines
When the no ip csg count retransmit ip command is configured, the CSG2 places the following restrictions on IP byte counting:

The CSG2 does not count IP bytes for retransmitted TCP payload bytes. The CSG2 does not count IP or TCP header bytes if all of the TCP payload bytes in a packet are retransmitted bytes. However, if even one of the TCP payload bytes is not a retransmitted byte (that is, at least one of the TCP payload bytes is a new byte), then the CSG2 does count the IP and TCP header bytes.
The CSG2 does not count a packet if all of the TCP payload bytes in the packet are retransmitted. However, if even one of the TCP payload bytes is not a retransmitted byte (that is, at least one of the TCP payload bytes is a new byte), then the CSG2 does count the packet.
The CSG2 does not count the header bytes or the packet if the packet has SYN or FIN flags set, contains no TCP payload, and the TCP sequence number is a retransmit. However, the CSG2 does count the header bytes and the packet if the packet is an ACK that contains no TCP payload, regardless of the TCP sequence number.
Examples
The following example shows how to exclude IP bytes and packets for retransmitted TCP segments when counting IP bytes:
no ip csg cont retransmit ip
A-90
OL-22840-05
Appendix A
CSG2 Command Reference ip csg database
ip csg database
To identify the database server that answers CSG2 user ID queries, use the ip csg database command in global configuration mode. To disable the database server, use the no form of this command. ip csg database [vrf vrf-name] ipv4-address port-number local-port no ip csg database
Syntax Description
vrf vrf-name
(Optional) Specifies the Virtual Routing and Forwarding (VRF) table to be used for communication with the database server.
Note
ipv4-address port-number local-port
IPv4 address of the database server that answers user ID queries. Port number of the database server that answers user ID queries. The range is from 1 to 65535. Local port number that the CSG2 is to use to send queries to the database server. The range is from 1 to 65535.
Command Default
If no VRF table is specified, the CSG2 uses the global routing table to communicate with the database server.
Command Modes
Command History
Release 12.4(11)MD

The name of this command changed from database to ip csg database. The configuration mode for this command changed from CSG user group to global configuration. The vrf vrf-name and local-port keywords and arguments were added.
Usage Guidelines
You can configure one and only one database server to answer CSG2 user ID queries. The subscriber traffic must flow on an interface in the global routing table (not the VRF table).
Examples
The following example shows how to specify a user database server with IPv4 address 10.1.2.3, port number 11111, and local port number 22222:
ip csg database 10.1.2.3 11111 22222
A-91
Appendix A ip csg domain group
ip csg domain group

To define a CSG2 domain group, and to enter CSG2 domain group configuration mode, use the ip csg domain group command in global configuration mode. To delete the domain group, use the no form of this command. ip csg domain group domain-group-name priority priority no ip csg domain group domain-group-name
Syntax Description
domain-group-name
Name of the domain group. The name can be from 1 to 15 characters long, is not case-sensitive, and can include uppercase or lowercase letters (the CSG2 changes all letters to uppercase), numbers, and any special characters. Priority of the domain group. The priority specifies the order of preference of the domain groups. A lower number indicates a higher priority, and higher priority domain groups are matched before lower priority domain groups. Priorities for different domain groups do not have to be sequential. That is, you can have three domain groups with priorities 1, 5, and 10. The range of priorities is from 1 to 511.
priority priority
Command Default
No domain group is defined.
Command Modes
Command History
Release 12.4(24)MD
Usage Guidelines
A domain group is a set of domain match patterns used to select and characterize domains that are mined by contents that have DNS parsing and mining enabled. The domain group is global. When a content enables DNS parsing and DNS mining, the CSG2 matches domains that are extracted from parsed transactions against the set of global domain groups. You must configure at least one match domain command for each domain group. A domain group configured without a match domain command is not included in the CSG2s domain group lookup. You cannot use the no form of this command to delete a domain group, nor can you change the priority or match domains for a domain group, if global mining is enabled (using the ip csg domain mining command) or if the domain group is currently being used by a CSG2 content. You can define up to 511 domain groups.
A-92
OL-22840-05
Appendix A
CSG2 Command Reference ip csg domain group
The characteristics of each domain group are defined by the following command:
match domain (CSG2 domain group)
Examples
The following example shows how to define domain group CISCO with priority 5:
ip csg domain group CISCO priority
Related Commands
Command match domain (CSG2 domain group)
Description Defines a domain name match pattern for a CSG domain group.
A-93
Appendix A ip csg domain mining
ip csg domain mining

To enable global domain mining for the CSG2, use the ip csg domain mining command in global configuration mode. To disable global domain mining, use the no form of this command. ip csg domain mining no ip csg domain mining
Syntax Description
Command Default
Global domain mining is not enabled.
Command Modes
Command History
Release 12.4(24)MD
Usage Guidelines
When this command is configured, all CSG2 contents that are configured to do so begin Domain Name System (DNS) mining. Before making any configuration changes to domain groups that are part of a CSG2 content, you must use the no form of this command to disable global domain mining. When disabling global domain mining, keep the following considerations in mind:

We recommend that you disable global domain mining only during your maintenance window. If you disable global domain mining, you do not need to disable mining for any contents (using the no form of the mining command in CSG2 content configuration mode). Disabling global domain mining is sufficient. When global domain mining is disabled, the CSG2 can still use the DNS IP Map Table for lookups, but it cannot add to or update the table. If you leave global domain mining disabled, all of the entries in the table eventually expire and are deleted by the CSG2. How long it takes for all of the entries to expire depends on how long global domain mining is disabled, the setting of the ip csg entries dns map ttl minimum command in global configuration mode. If the changes you are making to domain groups could affect existing domain group matching, we recommend that you clear the DNS IP Map Table, using the clear ip csg dns map command in global configuration mode. For example, given an existing domain group Cisco1 configured with match domain *cisco.com.
If you add domain group Cisco2 configured with match domain *CISCO.com, existing
matching is not affected and you do not need to clear the DNS IP Map Table.
A-94
OL-22840-05
Appendix A
CSG2 Command Reference ip csg domain mining
If you add domain group Cisco3 configured with match domain *wwwin.cisco.com, server IP
addresses and VRF tables that are currently mapped to Cisco1, but that could map to Cisco3, continue to map to Cisco1. Existing matching is affected and you do need to clear the DNS IP Map Table.
Examples
The following example shows how to enable global domain mining for the CSG2:
ip csg domain mining
Related Commands
Command mining (CSG2 content)
Description Enables domain name mining for the CSG2 content.
A-95
Appendix A ip csg egcdr mode
ip csg egcdr mode

To specify an interworking mode for the CSG2 and the eGGSN, use the ip csg egcdr mode command in global configuration mode. To restore the default setting, use the no form of this command. ip csg egcdr mode {tight} no ip csg egcdr mode
Syntax Description
tight
CSG2/eGGSN interworking mode. The CSG2 uses the interworking mode to enable triggers for adding containers to eG-CDRs. The valid values are:
tightEnables tight interworking mode for the eG-CDR service control interface. Tight mode enables a global set of triggers for adding containers to eG-CDRs for the service data flow when the CSG2 has a direct interface to a quota server via GTP'. This is currently the only supported mode.
Command Default
Tight interworking mode is disabled.
Command Modes
Command History
Release 12.4(24)MD
Examples
The following example shows how to specify tight interworking mode for CSG2 eG-CDR support:
ip csg egcdr mode tight
A-96
OL-22840-05
Appendix A
CSG2 Command Reference ip csg entries dns map hash size
ip csg entries dns map hash size

To define the size of the CSG2 Domain Name System (DNS) IP Map Table hash table, use the ip csg entries dns map hash size command in global configuration mode. To restore the default size, use the no form of this command. ip csg entries dns map hash size number-of-entries no ip csg entries dns map hash size
Syntax Description
number-of-entries
Number of entries allowed in the DNS IP Map Table hash table. The range is from 1024 to 262144, incremented by powers of two. (That is, 1024, 2048, 4096, and so on.) The default setting is 131072.
Command Default
The default DNS IP Map Table hash table size is 131072 entries.
Command Modes
Command History
Release 12.4(24)MD
Usage Guidelines
The CSG2 uses the DNS IP Map Table hash table when looking up entries to assign a content to a subscriber flow. Excessive hash collisions can impact the time it takes the CSG2 to look up entries. You can use this command to minimize the number of hash collisions by increasing the number of entries in the table.
Note
Increasing the size of the hash table uses more system memory. We recommend that you change the hash table size during your maintenance window, or during off-peak hours. When you change the hash table size, the CSG2 discards all existing DNS IP Map Table entries.
Examples
The following example shows how to specify a maximum DNS IP Map Table size of 2048 entries:
ip csg entries dns map hash size 2048
A-97
Appendix A ip csg entries dns map hash size
Related Commands
Command ip csg entries dns map interval ip csg entries dns map ttl maximum ip csg entries dns map ttl minimum
Description Defines how often the CSG2 is to check for and delete expired entries in the DNS IP Map Table. Defines the maximum time to live (TTL) for entries in the CSG2 Domain Name System (DNS) IP Map Table. Defines the minimum time to live (TTL) for entries in the CSG2 Domain Name System (DNS) IP Map Table.
A-98
OL-22840-05
Appendix A
CSG2 Command Reference ip csg entries dns map interval
ip csg entries dns map interval

To define how often the CSG2 is to check for and delete expired entries in the Domain Name System (DNS) IP Map Table, use the ip csg entries dns map interval command in global configuration mode. To restore the default interval, use the no form of this command. ip csg entries dns map interval seconds no ip csg entries dns map interval
Syntax Description
seconds
Time, in seconds, between checks for expired entries. The range is from 1 to 604800 (1 week). The default size is 300 (5 minutes).
Command Default
The default interval is 300 seconds.
Command Modes
Command History
Release 12.4(24)MD
Usage Guidelines
The CSG2 deletes an entry from the DNS IP Map Table when the following conditions are met:

The entry must expire. The DNS map interval must elapse and the CSG2 must check for and delete the expired entry.
Between the time that the entry expires and the DNS map interval elapses, the CSG2 does not use the expired entry when matching flows. If the time to live (TTL) for a DNS IP Map Table entry is small, it might remain in the table for many times its TTL. You can reduce the time that expired entries remain in the table by configuring the CSG2 to check the table for expired entries more often.
Note
If the DNS IP Map Table is very large, reducing the interval can significantly increase the load on the system. Removing expired entries is a low-priority task. Therefore, if the system is heavily loaded with high-priority tasks, expired entries might remain in the table for longer than the configured interval.
Examples
The following example shows how to configure the CSG2 to check the DNS IP Map Table for expired entries every 10 minutes:
ip csg entries dns map interval 600
A-99
Appendix A ip csg entries dns map interval
Related Commands
Command ip csg entries dns map hash size ip csg entries dns map ttl maximum ip csg entries dns map ttl minimum
Description Defines the size of the CSG2 Domain Name System (DNS) IP Map Table hash table. Defines the maximum time to live (TTL) for entries in the CSG2 Domain Name System (DNS) IP Map Table. Defines the minimum time to live (TTL) for entries in the CSG2 Domain Name System (DNS) IP Map Table.
A-100
OL-22840-05
Appendix A
CSG2 Command Reference ip csg entries dns map ttl maximum
ip csg entries dns map ttl maximum

To define the maximum time to live (TTL) for entries in the CSG2 Domain Name System (DNS) IP Map Table, use the ip csg entries dns map ttl maximum command in global configuration mode. To restore the default setting, use the no form of this command. ip csg entries dns map ttl maximum seconds no ip csg entries dns map ttl maximum
Syntax Description
seconds
Maximum TTL, in seconds, for entries in the DNS IP Map Table. The range is from 1 to 604800 (1 week). The default size is 604800 (1 week).
Command Default
The default maximum TTL is 604800 seconds.
Command Modes
Command History
Release 12.4(24)MD
Usage Guidelines
The maximum TTL must be equal to or greater than the minimum TTL.
Examples
The following example shows how to define a maximum TTL for the DNS IP Map Table of 3600 seconds (1 hour):
ip csg entries dns map ttl maximum 3600
Related Commands
Command ip csg entries dns map hash size ip csg entries dns map interval ip csg entries dns map ttl minimum
Description Defines the size of the CSG2 Domain Name System (DNS) IP Map Table hash table. Defines how often the CSG2 is to check for and delete expired entries in the DNS IP Map Table. Defines the minimum time to live (TTL) for entries in the CSG2 Domain Name System (DNS) IP Map Table.
A-101
Appendix A ip csg entries dns map ttl minimum
ip csg entries dns map ttl minimum

To define the minimum time to live (TTL) for entries in the CSG2 Domain Name System (DNS) IP Map Table, use the ip csg entries dns map ttl minimum command in global configuration mode. To restore the default setting, use the no form of this command. ip csg entries dns map ttl minimum seconds no ip csg entries dns map ttl minimum
Syntax Description
seconds
Minimum TTL, in seconds, for entries in the DNS IP Map Table. The range is from 1 to 604780 (1 week less 1 second). The default size is 0.
Command Default
The default minimum TTL is 0 seconds.
Command Modes
Command History
Release 12.4(24)MD
Usage Guidelines
The minimum TTL must be equal to or less than the maximum TTL.
Examples
The following example shows how to define a minimum TTL for the DNS IP Map Table of 120 seconds (2 minutes):
ip csg entries dns map ttl minimum 120
Related Commands
Command ip csg entries dns map hash size ip csg entries dns map interval ip csg entries dns map ttl maximum
Description Defines the size of the CSG2 Domain Name System (DNS) IP Map Table hash table. Defines how often the CSG2 is to check for and delete expired entries in the DNS IP Map Table. Defines the maximum time to live (TTL) for entries in the CSG2 Domain Name System (DNS) IP Map Table.
A-102
OL-22840-05
Appendix A
CSG2 Command Reference ip csg entries fragment
ip csg entries fragment

To define the maximum number of entries in the CSG2 fragment database, or to define how long the CSG2 is to retain the entries, use the ip csg entries fragment command in global configuration mode. To restore the default settings, use the no form of this command. ip csg entries fragment {idle duration | maximum entries-number} no ip csg entries fragment {idle | max}
Syntax Description
idle duration maximum entries-number
Number of seconds after which entries are deleted from the CSG2 fragment database. The range is from 1 to 255. The default setting is 5. Maximum number of entries allowed in the CSG2 fragment database. The range is from 1 to 65535. The default number of entries is 16384.
Command Default
The default idle duration is 5 seconds. The default maximum number of entries is 16384.
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
The CSG2 divides the configured maximum number of entries evenly among the traffic processors. For example, if you configure a maximum of 100 entries, the maximum buffer pool size on each traffic processor is 20.
Examples
The following example shows how to specify a maximum CSG2 fragment database size o0f 32,768 entries:
ip csg entries fragment maximum 32768
Related Commands
Command ip csg database ip csg entries user idle ip csg entries user max
Description Server that answers user ID queries. Specifies how long the CSG2 is to retain entries in the CSG2 User Table. Specifies the maximum number of entries allowed in he CSG2 User Table.
A-103
Appendix A ip csg entries fragment
Command ip csg entries user profile
Description Specifies the location from which the CSG2 is to obtain the subscriber profile and billing plan when generating entries for the CSG2 User Table. Specifies the maximum number of entries allowed in the CSG2 session table. Specifies the maximum number of general packet radio service (GPRS) tunneling protocol prime (GTP) messages, beyond the size of the Billing Mediation Agent (BMA) message queue, that the CSG2 can buffer for the Cisco Persistent Storage Device (PSD). Specifies the maximum number of general packet radio service (GPRS) tunneling protocol prime (GTP) messages that the CSG2 can buffer for all quota servers.
ip csg entries session user max ip csg psd margin
A-104
OL-22840-05
Appendix A
CSG2 Command Reference ip csg entries session user max
ip csg entries session user max

To specify the maximum number of entries allowed in the CSG2 session table, use the ip csg entries session user max command in global configuration mode. To restore the default settings, use the no form of this command. ip csg entries session user max entries no ip csg entries session user max
Syntax Description
entries
Maximum number of entries allowed in the session table. This is the maximum number of sessions that the CSG2 can support. When the number of active sessions reaches the specified maximum, the CSG2 begins dropping incoming new sessions. The range is from 1 to 1800000. The default number of entries is 1000000.
Command Default
The default maximum number of entries is 1000000.
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
The maximum number of entries is not enforced on the buffer pool maximum size, it is enforced during allocation of individual subscriber sessions to the table.
Examples
The following example shows how to specify a maximum CSG2 session table size of 100,000 entries:
ip csg entries session user max 100000
Related Commands
Command ip csg database ip csg entries fragment ip csg entries user idle ip csg entries user max ip csg entries user profile
Description Server that answers user ID queries. Defines the maximum number of entries in the CSG2 fragment database, or how long the CSG2 is to retain the entries. Specifies how long the CSG2 is to retain entries in the CSG2 User Table. Specifies the maximum number of entries allowed in he CSG2 User Table. Specifies the location from which the CSG2 is to obtain the subscriber profile and billing plan when generating entries for the CSG2 User Table.
A-105
Appendix A ip csg entries session user max
Command ip csg psd margin
Description Specifies the maximum number of general packet radio service (GPRS) tunneling protocol prime (GTP) messages, beyond the size of the Billing Mediation Agent (BMA) message queue, that the CSG2 can buffer for the Cisco Persistent Storage Device (PSD). Specifies the maximum number of general packet radio service (GPRS) tunneling protocol prime (GTP) messages that the CSG2 can buffer for all quota servers.
A-106
OL-22840-05
Appendix A
CSG2 Command Reference ip csg entries user idle
ip csg entries user idle

To specify how long the CSG2 is to retain entries in the CSG2 User Table, use the ip csg entries user idle command in global configuration mode. To restore the default settings, use the no form of this command. ip csg entries user idle duration [pod] no ip csg entries user idle
Syntax Description
duration
Number of seconds after which the CSG2 is to delete entries for idle subscribers from the CSG2 User Table. The range is from 0 (entries never idle out) to 2147483647. The default setting is 0. (Optional) Specifies whether the CSG2 is to send the RADIUS Packet of Disconnect message when an entry idles out.
pod
Command Default
The default idle duration is 0 seconds (entries never idle out), and the CSG2 does not send the RADIUS Packet of Disconnect message when an entry idles out.
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
The CSG2 User Table identifies all subscribers known to the CSG2. The table is populated on the basis of the contents of RADIUS Accounting Start messages, or from the user database, if either feature is enabled in your configuration. When setting the entry idle timer, keep the following considerations in mind:
You can set the entry idle timer either globally, using the ip csg entries user idle command, or in each billing plan, using the entries user idle command in CSG2 billing configuration mode. If you do not set the timer in the billing plan, the CSG2 uses the global timer. That is, if there is an entry idle timer value in the billing plan, it is used; otherwise, if there is a global entry idle timer value configured, it is used. If set, the idle timer starts when there are no billable sessions, and restarts whenever a RADIUS Accounting Start or a RADIUS Interim Accounting message is received. The timer stops when a billable session is started. If you do not specify the pod keyword, the CSG2 deletes the idle entry when the timer expires. If you specify the pod keyword, and if RADIUS Packet of Disconnect (PoD) is configured for the CSG2, the CSG2 sends a PoD message when the idle timer expires. The CSG2 deletes the idle entry when the PoD message is ACKed, NAKed, or when all retries have been sent.
A-107
Appendix A ip csg entries user idle
If Connection Duration Billing is enabled, you can use either the billing plan entry idle timer or the global entry idle timer to release a subscriber connection. The idle timer does not affect sticky user entries.
Examples
The following example shows how to specify a CSG2 User Table entry idle time of 86,400 seconds:
ip csg entries user idle 86400
Related Commands
Command entries user idle ip csg database ip csg entries fragment ip csg entries user max ip csg entries user profile
Description Sets the time after which entries for idle subscribers are deleted from the CSG2 User Table. Server that answers user ID queries. Defines the maximum number of entries in the CSG2 fragment database, or how long the CSG2 is to retain the entries. Specifies the maximum number of entries allowed in he CSG2 User Table. Specifies the location from which the CSG2 is to obtain the subscriber profile and billing plan when generating entries for the CSG2 User Table. Specifies the maximum number of entries allowed in the CSG2 session table. Specifies the maximum number of general packet radio service (GPRS) tunneling protocol prime (GTP) messages, beyond the size of the Billing Mediation Agent (BMA) message queue, that the CSG2 can buffer for the Cisco Persistent Storage Device (PSD). Specifies the maximum number of general packet radio service (GPRS) tunneling protocol prime (GTP) messages that the CSG2 can buffer for all quota servers.
A-108
OL-22840-05
Appendix A
CSG2 Command Reference ip csg entries user max
ip csg entries user max

To specify the maximum number of entries allowed in the CSG2 User Table, use the ip csg entries user max command in global configuration mode. To restore the default settings, use the no form of this command. ip csg entries user max entries no ip csg entries user max
Syntax Description
entries
Maximum number of entries allowed in the CSG2 User Table.

For the 2 GB-SAMI option, the range is from 1 to 1250000. The default number of entries is 300000. For the 1 GB-SAMI option, the range is from 1 to 500000. The default number of entries is 300000.
The actual number of entries in the CSG2 User Table depends on several variables, including the traffic model being used and the number of RADIUS attributes reported. Even if you set entries-number to a very large number, such as 300000, the CSG2 might never store that many entries in the CSG2 User Table.
Command Default
The default maximum number of entries is 300,000 for both the 1 GB-SAMI and the 2 GB-SAMI options.
Command Modes
Command History
Release 12.4(11)MD 12.4(15)MD
Modification This command was introduced. The range was changed to reflect the differences between the 2 GB-SAMI and 1 GB-SAMI options:

For the 2 GB-SAMI option, the range is from 1 to 1250000. For the 1 GB-SAMI option, the range is from 1 to 500000.
Usage Guidelines
The maximum number of entries is not enforced on the buffer pool maximum size, it is enforced during allocation of individual entries to the CSG2 User Table.
Examples
The following example shows how to specify a maximum CSG2 User Table size of 500000 entries:
ip csg entries user max 500000
A-109
Appendix A ip csg entries user max
Related Commands
Command ip csg database ip csg entries fragment ip csg entries user idle ip csg entries user profile
Description Server that answers user ID queries. Defines the maximum number of entries in the CSG2 fragment database, or how long the CSG2 is to retain the entries. Specifies how long the CSG2 is to retain entries in the CSG2 User Table. Specifies the location from which the CSG2 is to obtain the subscriber profile and billing plan when generating entries for the CSG2 User Table. Specifies the maximum number of entries allowed in the CSG2 session table. Specifies the maximum number of general packet radio service (GPRS) tunneling protocol prime (GTP) messages, beyond the size of the Billing Mediation Agent (BMA) message queue, that the CSG2 can buffer for the Cisco Persistent Storage Device (PSD). Specifies the maximum number of general packet radio service (GPRS) tunneling protocol prime (GTP) messages that the CSG2 can buffer for all quota servers.
A-110
OL-22840-05
Appendix A
CSG2 Command Reference ip csg entries user profile
ip csg entries user profile

To specify the location from which the CSG2 is to obtain the subscriber profile and billing plan when generating entries for the CSG2 User Table, use the ip csg entries user profile command in global configuration mode. To restore the default settings, use the no form of this command. ip csg entries user profile {quota-server | radius {pass | remove | timeout timeout}} no ip csg entries user profile
Syntax Description
quota-server radius
The CSG2 obtains the subscriber profile and billing plan from the quota server. The CSG2 obtains the Cisco vendor-specific attribute (VSA) subattribute 1, which contains the billing plan name, from the RADIUS Access-Accept and RADIUS Accounting-Request messages. Does not remove the VSA containing the billing plan from the RADIUS Access-Accept message. Removes the VSA containing the billing plan from the RADIUS Access-Accept message. Number of seconds to retain cached billing plan data while waiting for a RADIUS Accounting Start message for a user. The range is from 10 to 65535 seconds. The default timeout is 20 seconds.
pass remove timeout timeout
Command Default
If you do not specify the ip csg entries user profile command, the CSG2 obtains the subscriber profile and billing plan from the quota server. If you do not specify a timeout, the default timeout is 20 seconds.
Command Modes
Command History
Release 12.4(11)MD

The name of this command changed from user-profile server to ip csg entries user profile. The configuration mode for this command changed from CSG user group to global configuration.
12.4(15)MD
The timeout keyword and timeout argument were added.
A-111
Appendix A ip csg entries user profile
Usage Guidelines
Keep the following considerations in mind:

The VSA is removed from the RADIUS Access-Accept message only if remove is specified. Use the remove argument only if the RADIUS client cannot accept the Cisco VSA in the message. We recommend that you use pass to reduce processing time on the CSG2. The user ID must be included in the message that contains the billing plan. To enable the CSG2 to parse user profile attributes in eGGSN mode, you must configure either the ip csg entries user profile radius pass command or the ip csg entries user profile radius remove command. For more information on eGGSN mode, see the Configuring Gx Support section on page 10-1.
The CSG2 obtains billing plan data from authentication, authorization, and accounting (AAA) RADIUS Access response packets.

When the CSG2 receives a RADIUS Access response for a user, it caches the billing plan data for that user. When the CSG2 receives a RADIUS Accounting Start message from a Network Access Server (NAS) for that same user, it frees the cached billing plan data. If the cache timeout expires before the CSG2 receives the RADIUS Accounting Start message, the CSG2 frees the cached billing plan data. If the RADIUS Accounting Start message arrives after the cached billing plan data has been freed, the CSG2 creates the user with an unknown billing plan and sends a User Authorization Request to the quota server.
In most cases, the default timeout of 20 seconds is far greater than the delay between the receipt of the RADIUS Access response and the receipt of the RADIUS Accounting Start message. If the default timeout is not large enough, you can use the ip csg entries user profile timeout timeout command to increase the timeout.
Examples
The following example shows how to specify that the CSG2 is to obtain billing plan names from the RADIUS Access-Accept and RADIUS Accounting-Request messages, and that the CSG2 is not to remove the VSA containing the billing plan from the messages:
ip csg entries user profile radius pass
Related Commands
Command ip csg database
Description Server that answers user ID queries.
ip csg entries fragment Defines the maximum number of entries in the CSG2 fragment database, or how long the CSG2 is to retain the entries. ip csg entries user idle Specifies how long the CSG2 is to retain entries in the CSG2 User Table. ip csg entries user max Specifies the maximum number of entries allowed in he CSG2 User Table. ip csg entries session user max ip csg psd margin Specifies the maximum number of entries allowed in the CSG2 session table. Specifies the maximum number of general packet radio service (GPRS) tunneling protocol prime (GTP) messages, beyond the size of the Billing Mediation Agent (BMA) message queue, that the CSG2 can buffer for the Cisco Persistent Storage Device (PSD).
A-112
OL-22840-05
Appendix A
CSG2 Command Reference ip csg entries user profile
Command ip csg quota-server messages ip csg radius userid
Description Specifies the maximum number of general packet radio service (GPRS) tunneling protocol prime (GTP) messages that the CSG2 can buffer for all quota servers. Specifies the RADIUS attribute used to extract the user identifier from a RADIUS record.
A-113
Appendix A ip csg event-trace packet enable
ip csg event-trace packet enable

To enable the CSG2 to log packets, use the ip csg event-trace packet enable command in global configuration mode. To disable packet logging, use the no form of this command. ip csg event-trace packet enable [no-wrap] no ip csg event-trace packet enable
Syntax Description
no-wrap
(Optional) Clears the existing packet buffer and then logs packets until the packet buffer is full.
Command Default
Packet logging is disabled.
Command Modes
Command History
Release 12.4(22)MDA
Usage Guidelines
We recommend that you enable packet logging only when directed to do so by Cisco Technical Assistance Center (TAC) engineers. In most environments, the default setting is the most appropriate setting. Enter this command only on the control processor (CP), not on the traffic processors (TPs). When configured on the CP, this command also takes effect on all of the TPs. Enable packet logging only for diagnostic purposes, and only after configuring filtering, buffer size, and other parameters. When you first enable packet logging, the CSG2 creates a packet buffer in which to log and store the packets. A packet buffer is allocated for each traffic processor (TP) and the control processor (CP). The CSG2 logs and stores a packet in the buffer on the TP or CP that processed the packet. If you disable packet logging without specifying the no-wrap keyword, the contents of the packet buffer are frozen, but they are not cleared and the memory associated with the buffer is not freed. To clear the contents of the packet buffer, you must specify the no-wrap keyword as follows:
To clear the contents of the packet buffer with packet logging still enabled, enter the following command: ip csg event-trace packet enable no-wrap To disable packet logging, clear the contents of the packet buffer, and free the memory associated with the packet buffer, enter the following command: no ip csg event-trace packet enable no-wrap
A-114
OL-22840-05
Appendix A
CSG2 Command Reference ip csg event-trace packet enable
Examples
The following example shows how to enable event tracing for the CSG2:
ip csg event-trace packet enable
Related Commands
Command ip csg event-trace packet entries ip csg event-trace packet match action ip csg event-trace packet match error ip csg event-trace packet match ip ip csg event-trace packet match protocol
Description Changes the size of the CSG2 packet buffer. Defines action-based filters for CSG2 packet logging. Defines error-based filters for CSG2 packet logging. Defines IP-based filters for CSG2 packet logging. Defines protocol-based filters for CSG2 packet logging.
A-115
Appendix A ip csg event-trace packet entries
ip csg event-trace packet entries

To change the size of the CSG2 packet buffer, use the ip csg event-trace packet entries command in global configuration mode. To restore the default setting, use the no form of this command. ip csg event-trace packet entries number-of-entries no ip csg event-trace packet entries number-of-entries
Syntax Description
number-of-entries
Number of packets that the CSG2 can log and store in the packet buffer on each traffic processor (TP) and the control processor (CP). The range is from 0 to 65535. The default number of entries is 100.
Command Default
The default number of entries is 100.
Command Modes
Command History
Release 12.4(22)MDA
Usage Guidelines
We recommend that you enable packet logging only when directed to do so by Cisco Technical Assistance Center (TAC) engineers. In most environments, the default setting is the most appropriate setting. Enter this command only on the control processor (CP), not on the traffic processors (TPs). When configured on the CP, this command also takes effect on all of the TPs. When the packet buffer is full, logging stops unless the no-wrap keyword is specified on the ip csg event-trace packet enable command. Entering this command clears the existing packet buffer, frees the memory associated with the existing packet buffer, and creates a new packet buffer. Packets stored in the existing buffer are not copied to the new buffer. Entering this command with a value of 0 clears any existing buffer.
Examples
The following example shows how to log and store 200 packets:
ip csg event-trace packet entries 200
Related Commands
Command ip csg event-trace packet enable ip csg event-trace packet match action ip csg event-trace packet match error
Description Enables packet logging for the CSG2. Defines action-based filters for CSG2 packet logging. Defines error-based filters for CSG2 packet logging.
A-116
OL-22840-05
Appendix A
CSG2 Command Reference ip csg event-trace packet entries
Command ip csg event-trace packet match ip ip csg event-trace packet match protocol
Description Defines IP-based filters for CSG2 packet logging. Defines protocol-based filters for CSG2 packet logging.
A-117
Appendix A ip csg event-trace packet match action
ip csg event-trace packet match action

To define action-based filters for CSG2 packet logging, use the ip csg event-trace packet match action command in global configuration mode. To delete the filters, use the no form of this command. ip csg event-trace packet match action {dropped | forwarded | queued} no ip csg event-trace packet match action
Syntax Description
dropped forwarded queued
Log packets that are dropped by the CSG2. Log packets that are forwarded by the CSG2. Log packets that are temporarily queued by the CSG2.
Command Default
Log packets no matter what action the CSG2 performs on them.
Command Modes
Command History
Release 12.4(22)MDA
Usage Guidelines
We recommend that you enable packet logging only when directed to do so by Cisco Technical Assistance Center (TAC) engineers. In most environments, the default setting is the most appropriate setting. Enter this command only on the control processor (CP), not on the traffic processors (TPs). When configured on the CP, this command also takes effect on all of the TPs. This command controls only action-based packet logging filters. Other filters might also apply.
Examples
The following example shows how to instruct the CSG2 to log packets that have been forwarded:
ip csg event-trace packet action forward
Related Commands
Command ip csg event-trace packet enable ip csg event-trace packet entries ip csg event-trace packet match error ip csg event-trace packet match ip ip csg event-trace packet match protocol
Description Enables packet logging for the CSG2. Changes the size of the CSG2 packet buffer. Defines error-based filters for CSG2 packet logging. Defines IP-based filters for CSG2 packet logging. Defines protocol-based filters for CSG2 packet logging.
A-118
OL-22840-05
Appendix A
CSG2 Command Reference ip csg event-trace packet match error
ip csg event-trace packet match error

To define error-based filters for CSG2 packet logging, use the ip csg event-trace packet match error command in global configuration mode. To delete the filters, use the no form of this command. ip csg event-trace packet match error {parse} no ip csg event-trace packet match error
Syntax Description
parse
Logs packets that cannot be parsed by the CSG2.
Command Default
Log all packets.
Command Modes
Command History
Release 12.4(22)MDA
Usage Guidelines
We recommend that you enable packet logging only when directed to do so by Cisco Technical Assistance Center (TAC) engineers. In most environments, the default setting is the most appropriate setting. Enter this command only on the control processor (CP), not on the traffic processors (TPs). When configured on the CP, this command also takes effect on all of the TPs. This command controls only error-based packet logging filters. Other filters might also apply. If an error occurs while parsing multiple packets, the CSG2 might not log all of the packets, depending on the protocol of the packets.
Examples
The following example shows how to instruct the CSG2 to log packets that result in parse errors:
ip csg event-trace packet error parse
Related Commands
Command ip csg event-trace packet enable ip csg event-trace packet entries ip csg event-trace packet match action ip csg event-trace packet match ip ip csg event-trace packet match protocol
Description Enables packet logging for the CSG2. Changes the size of the CSG2 packet buffer. Defines action-based filters for CSG2 packet logging. Defines IP-based filters for CSG2 packet logging. Defines protocol-based filters for CSG2 packet logging.
A-119
Appendix A ip csg event-trace packet match ip
ip csg event-trace packet match ip

To define IP-based filters for CSG2 packet logging, use the ip csg event-trace packet match ip command in global configuration mode. To delete the filters, use the no form of this command. ip csg event-trace packet match ip {[global | vrf vrf-name] [subscriber subscriber-acl] [network network-acl]) no ip csg event-trace packet match ip
Syntax Description
global vrf vrf-name
Logs packets that arrive on interfaces attached to the default routing table. Logs packets that arrive on interfaces attached to the Virtual Routing and Forwarding (VRF) table.
Note
subscriber subscriber-acl network network-acl
Logs packets whose subscriber IP addresses are permitted by the simple access control list (ACL) subscriber-acl. Logs packets whose network IP addresses are permitted by the simple access control list (ACL) network-acl.
Command Default
Log packets that arrive on any interface with any subscriber or network IP address.
Command Modes
Command History
Release 12.4(22)MDA
Usage Guidelines
We recommend that you enable packet logging only when directed to do so by Cisco Technical Assistance Center (TAC) engineers. In most environments, the default setting is the most appropriate setting. Enter this command only on the control processor (CP), not on the traffic processors (TPs). When configured on the CP, this command also takes effect on all of the TPs. This command controls only IP-based packet logging filters. Other filters might also apply. This command supports only simple ACLs. It does not support extended ACLs. Each instance of this command overrides the previous instance. For example, if you configure the following commands sequentially, only the last command takes effect: ip csg event-trace packet match ip subscriber 10 ip csg event-trace packet match ip vrf plog-vrf network 11 That is, the CSG2 logs packets only if they arrive on interfaces attached to CRF table plog-vrf and if their network IP addresses are permitted by ACL 11.
A-120
OL-22840-05
Appendix A
CSG2 Command Reference ip csg event-trace packet match ip
Examples
The following example shows how to instruct the CSG2 to log packets only if they arrive on interfaces attached to CRF table plog-vrf and if their network IP addresses are permitted by ACL 11.
ip csg event-trace packet match ip vrf plog-vrf network 11
Related Commands
Command ip csg event-trace packet enable ip csg event-trace packet entries ip csg event-trace packet match action ip csg event-trace packet match error ip csg event-trace packet match protocol
Description Enables packet logging for the CSG2. Changes the size of the CSG2 packet buffer. Defines action-based filters for CSG2 packet logging. Defines error-based filters for CSG2 packet logging. Defines protocol-based filters for CSG2 packet logging.
A-121
Appendix A ip csg event-trace packet match protocol
ip csg event-trace packet match protocol

To define protocol-based filters for CSG2 packet logging, use the ip csg event-trace packet match protocol command in global configuration mode. To delete the filters, use the no form of this command. ip csg event-trace packet match protocol { dns | ftp [control | data] | http | imap | nbar [ aol-messenger | bittorrent | directconnect | edonkey | exchange | fasttrack | ftp | gnutella | http | imap | kazaa2 | msn-messenger | pop3 | rtp | rtsp | sip | skype | smtp | winmx | yahoo-messenger ] other | pop3 | radius [monitor | proxy] | rtsp [control | data] | sip [control | data] | smtp | wap [connectionless | connection-oriented] | } no ip csg event-trace packet match protocol
Syntax Description
dns ftp control data http
Logs packets that match a content configured with parse protocol dns. Logs packets that match a content configured with parse protocol ftp. (Optional) Logs only packets that belong to FTP control sessions. (Optional) Logs only packets that belong to FTP data sessions. Logs packets that match a content configured with parse protocol http.
A-122
OL-22840-05
Appendix A
CSG2 Command Reference ip csg event-trace packet match protocol
imap nbar aol-messenger bittorrent directconnect edonkey exchange fasttrack ftp gnutella http imap kazaa2 msn-messenger pop3 rtp rtsp sip skype smtp winmx yahoo-messenger other pop3 radius monitor
Logs packets that match a content configured with parse protocol imap. Logs packets that match a content configured with parse protocol nbar. (Optional) Logs only packets that have been classified by NBAR as AOL Instant Messenger (AIM) packets. (Optional) Logs only packets that have been classified by NBAR as BitTorrent packets. (Optional) Logs only packets that have been classified by NBAR as DirectConnect packets. (Optional) Logs only packets that have been classified by NBAR as eDonkey packets. (Optional) Logs only packets that have been classified by NBAR as Microsoft Remote Procedure Call (MS-RPC) for Exchange packets. (Optional) Logs only packets that have been classified by NBAR as FastTrack packets. (Optional) Logs only packets that have been classified by NBAR as FTP packets. (Optional) Logs only packets that have been classified by NBAR as Gnutella packets. (Optional) Logs only packets that have been classified by NBAR as HTTP packets. (Optional) Logs only packets that have been classified by NBAR as IMAP packets. (Optional) Logs only packets that have been classified by NBAR as Kazaa2 packets. (Optional) Logs only packets that have been classified by NBAR as MSN Messenger packets. (Optional) Logs only packets that have been classified by NBAR as POP3 packets. (Optional) Logs only packets that have been classified by NBAR as RTP packets. (Optional) Logs only packets that have been classified by NBAR as RTSP packets. (Optional) Logs only packets that have been classified by NBAR as SIP packets. (Optional) Logs only packets that have been classified by NBAR as Skype packets. (Optional) Logs only packets that have been classified by NBAR as SMTP. packets. (Optional) Logs only packets that have been classified by NBAR as WinMX packets. (Optional) Logs only packets that have been classified by NBAR as Yahoo! Messenger packets. Logs packets that match a content configured with parse protocol other. Logs packets that match a content configured with parse protocol pop3. Logs packets that match a content configured with parse protocol radius. (Optional) Logs only packets that belong to RADIUS monitor sessions.
A-123
Appendix A ip csg event-trace packet match protocol
proxy rtsp control data sip control data smtp wap connectionless connection-oriented
(Optional) Logs only packets that belong to RADIUS proxy sessions. Logs packets that match a content configured with parse protocol rtsp. (Optional) Logs only packets that belong to RTSP control sessions. (Optional) Logs only packets that belong to RTSP data sessions. Logs packets that match a content configured with parse protocol sip. (Optional) Logs only packets that belong to SIP control sessions. (Optional) Logs only packets that belong to SIP data sessions. Logs packets that match a content configured with parse protocol smtp. Logs packets that match a content configured with parse protocol wap. (Optional) Logs only packets that belong to WAP connectionless sessions. (Optional) Logs only packets that belong to WAP connection-oriented sessions.
Command Default
Log packets of any protocol.
Command Modes
Command History
Release 12.4(22)MDA 12.4(24)MD
Modification This command was introduced. The dns keyword was added.
Usage Guidelines
We recommend that you enable packet logging only when directed to do so by Cisco Technical Assistance Center (TAC) engineers. In most environments, the default setting is the most appropriate setting. Enter this command only on the control processor (CP), not on the traffic processors (TPs). When configured on the CP, this command also takes effect on all of the TPs. This command controls only protocol-based packet logging filters. Other filters might also apply. The CSG2 can log packets for a protocol correctly only if there is a content configured to parse that protocol. For example, the CSG2 can log packets for FTP only if there is a content configured with the parse protocol ftp command. If you specify the nbar keyword without specifying a protocol, the CSG2 logs all packets classified by NBAR. The CSG2 can log packets for a protocol that is classified by NBAR only if there is a content configured with the parse protocol nbar command, and if a match protocol command for that protocol is configured in class map configuration mode. For more information, see the Configuring NBAR Protocol Support section on page 2-35. It might take a few packets for NBAR to correctly identify a protocol. Therefore, the CSG2 logs all of the pre-identification packets of all session matching an NBAR content.
A-124
OL-22840-05
Appendix A
CSG2 Command Reference ip csg event-trace packet match protocol
Examples
The following example shows how to instruct the CSG2 to log packets only if they are classified by NBAR as HTTP packets:
ip csg event-trace packet match protocol nbar http
Related Commands
Command ip csg event-trace packet enable ip csg event-trace packet entries ip csg event-trace packet match action ip csg event-trace packet match error ip csg event-trace packet match ip
Description Enables packet logging for the CSG2. Changes the size of the CSG2 packet buffer. Defines action-based filters for CSG2 packet logging. Defines error-based filters for CSG2 packet logging. Defines IP-based filters for CSG2 packet logging.
A-125
Appendix A ip csg geo-redundancy
ip csg geo-redundancy
To enable geo-redundancy for the CSG2, use the ip csg geo-redundancy command in global configuration mode. To disable geo-redundancy, use the no form of this command. ip csg geo-redundancy no ip csg geo-redundancy
Syntax Description
Command Default
Geo-redundancy is disabled.
Command Modes
Command History
Release 12.4(22)MDA
Usage Guidelines
Before enabling geo-redundancy on the CSG2, ensure that the GGSN is configured to support geo-redundancy.
Examples
The following example shows how to enable geo-redundancy for the CSG2:
ip csg geo-redundancy
A-126
OL-22840-05
Appendix A
CSG2 Command Reference ip csg header
ip csg header
To define a CSG2 header to be inserted in HTTP requests, and to enter CSG2 header configuration mode, use the ip csg header command in global configuration mode. To delete the header, use the no form of this command. ip csg header header-name no ip csg header header-name
Syntax Description
header-name
Name of the header. The header name must be unique, but different services can reference the same header. The name can be from 1 to 15 characters long, and can include uppercase or lowercase letters (CSG2 changes all letters to uppercase), numbers, and any special characters.
Command Default
No CSG2 header is defined.
Command Modes
Command History
Release 12.4(24)MD
Usage Guidelines
The characteristics of each CSG2 header are defined by the following commands:

class (CSG2 header) encrypt (CSG2 header) name (CSG2 header) quota-server (CSG2 header) radius (CSG2 header) string (CSG2 header) timestamp (CSG2 header)
The commands that are used to configure header data are order-sensitive. Each data item is inserted into the HTTP header, concatenated, in the order in which it was configured. For example, in the following sample configuration, the CSG2 inserts the string Clear text as data first, followed by the string My encrypted string (after it has been encrypted), followed by the timestamp.
ip csg header HDR-1 name X-HDR class abcd include string 1 Clear text encrypt begin string 2 My encrypted string encrypt end
A-127
Appendix A ip csg header
timestamp
As shown in the above example, header data can be encrypted. You cannot configure the following commands within the encrypted portion of the header (that is, between the encrypt begin and encrypt end commands):

class name timestampBecause the timestamp is constantly changing, the CSG2 does not allow it to be encrypted.
You can use the class command to assign a CSG2 header to a class of headers, and to specify a default include or exclude behavior for that header. You can use the radius command to specify a RADIUS attribute or VSA subattribute, and to indicate where it is to be inserted into a CSG2 header. Any information for the configured RADIUS attribute or VSA subattribute must be present in the incoming RADIUS Accounting-Start message.
Examples
The following example shows how to define CSG2 header HDR-1, HDR-2, and HDR-3:
ip csg header HDR-1 name X-HDR class abcd include string 1 Clear text encrypt begin string 2 My encrypted string encrypt end timestamp ! ip csg header HDR-2 name X-RAD-3GPP-22 class X-RAD-3GPP-22 default include radius vsa 10415 22 ! ip csg header HDR-3 name X-QS-TLV class X-QS-TLV default include quota-server
Related Commands
Command class (CSG2 header)
Description Specifies the class to which a CSG2 header belongs, as well as the default header insertion behavior to use for user profiles that do not specify a default behavior. Specifies when encryption is to begin and end for a CSG2 header. Specifies a name for a CSG2 header. Inserts data from the Quota-Server TLV into a CSG2 header. Specifies a RADIUS attribute or vendor-specific attribute (VSA) subattribute and indicates where it is to be inserted into a CSG2 header. Specifies a text string and indicates where it is to be inserted into a CSG2 header. Indicates where a timestamp is to be inserted into a CSG2 header.
encrypt (CSG2 header) name (CSG2 header) quota-server (CSG2 header) radius (CSG2 header)
string (CSG2 header) timestamp (CSG2 header)
A-128
OL-22840-05
Appendix A
CSG2 Command Reference ip csg header-group
ip csg header-group
To define a CSG2 header group, and to enter CSG2 header-group configuration mode, use the ip csg header-group command in global configuration mode. To delete the header group, use the no form of this command. ip csg header-group group-name no ip csg header-group group-name
Syntax Description
group-name
Name of the header group. The name can be from 1 to 15 characters long, and can include uppercase or lowercase letters (CSG2 changes all letters to uppercase), numbers, and any special characters.
Command Default
No CSG2 header group is defined.
Command Modes
Command History
Release 12.4(24)MD
Usage Guidelines
The characteristics of each CSG2 header-group are defined by the following command:
header (CSG2 header-group)
You can configure many different header groups, each of which can include many different headers. However, the total number of header commands that you can configure on a given card is 4,000. That is, you can configure a single header-group of up to 4,000 headers; or one header group of 3500 headers and another of 500 headers; or any other combination of header groups and headers that does not exceed 4,000 total header commands. Duplicate header commands are included in the total. For example, if you include header HDR-TEST1 in five different header groups, that counts as five header inclusions, not just one. The headers that are defined for a header group are order-sensitive. Each header in a header group is inserted into the HTTP header, concatenated, in the order in which it was configured. For example, given the following configuration:
A-129
Appendix A ip csg header-group
Examples
The following example shows how to define header group HG-1 that includes headers HDR-1, HDR-2, and HDR-3:
Related Commands
Command header (CSG2 header-group)
Description Includes a header in a CSG2 header group.
A-130
OL-22840-05
Appendix A
CSG2 Command Reference ip csg ipc crashdump
ip csg ipc crashdump

To define the action to be taken by the CSG2 if an Interprocessor Communication (IPC) link fails, use the ip csg ipc crashdump command in global configuration mode. To restore the default setting, use the no form of this command. ip csg ipc crashdump [never | tolerance [number-of-seconds]] no ip csg ipc crashdump
Syntax Description
never tolerance number-of-seconds
(Optional) Never generate a crash dump in an IPC link fails. This is the default setting. (Optional) Time, in seconds, that the CSG2 is to wait after an IPC link fails before generating a crash dump. The range is from 60 to 600. The default value is 60.
Command Default
The default setting is to never generate a crash dump. If you specify the tolerance keyword without specifying a time, the CSG2 generates a crash dump 60 seconds after an IPC link fails.
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
We recommend that you change the crash dump setting only when directed to do so by Cisco Technical Assistance Center (TAC) engineers. In most environments, the default value is the most appropriate setting.
Examples
The following example shows how to specify that the CSG2 is to generate a crash dump 120 seconds after an IPC link fails:
ip csg ipc crashdump tolerance 120
A-131
Appendix A ip csg ipc keepalive
ip csg ipc keepalive

To define the Interprocessor Communication (IPC) module keepalive time interval for the CSG2, use the ip csg ipc keepalive command in global configuration mode. To reset the IPC keepalive timer to the default value, use the no form of this command. ip csg ipc keepalive number-of-seconds no ip csg ipc keepalive
Syntax Description
number-of-seconds
Time, in seconds, between IPC keepalives. The range is from 1 to 65535. The default value is 8.
Command Default
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
Examples
The following example shows how to specify an IPC keepalive time of 300 seconds:
ip csg ipc keepalive 300
Related Commands
Command ip csg bma keepalive ip csg psd keepalive ip csg quota-server keepalive
Description Defines the Billing Mediation Agent (BMA) keepalive time interval for the CSG2. Defines the Cisco Persistent Storage Device (PSD) keepalive time interval for the CSG2. Defines the quota-server keepalive time interval for the CSG2.
A-132
OL-22840-05
Appendix A
CSG2 Command Reference ip csg ipc retransmit
ip csg ipc retransmit

To define the Interprocessor Communication (IPC) retransmit time interval for the CSG2, use the ip csg ipc retransmit command in global configuration mode. To reset the IPC retransmit timer to the default value, use the no form of this command. ip csg ipc retransmit number-of-seconds no ip csg ipc retransmit
Syntax Description
number-of-seconds
Time, in seconds, between IPC retransmits. The range is from 1 to 65535. The default value is 4.
Command Default
The default value is 4 second.
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
Examples
The following example shows how to specify an IPC retransmit time of 2 seconds:
ip csg ipc retransmit 2
Related Commands
Command ip csg bma retransmit ip csg psd retransmit
Description Defines the Billing Mediation Agent (BMA) retransmit time interval for the CSG2. Defines the Cisco Persistent Storage Device (PSD) retransmit time interval for the CSG2.
ip csg quota-server retransmit Defines the quota server retransmit time interval for the CSG2.
A-133
Appendix A ip csg ipc retries
ip csg ipc retries

To define the maximum number of Interprocessor Communication (IPC) retries allowed before the CSG2 determines that the link has failed, use the ip csg ipc retries command in global configuration mode. To reset the number of IPC retries to the default value, use the no form of this command. ip csg ipc retries number-of-retries no ip csg ipc retries
Syntax Description
number-of-retries
Maximum number of IPC retries allowed by the CSG2. The range is from 1 to 65535. The default value is 20.
Command Default
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
We recommend that you change the number of retries allowed only when directed to do so by Cisco Technical Assistance Center (TAC) engineers. In most environments, the default value is the most appropriate setting.
Examples
The following example shows how to allow two IPC retries:

ip csg ipc retries 2
Related Commands
Command ip csg bma retries ip csg psd retries
Description Defines the maximum number of Billing Mediation Agent (BMA) retries allowed before the CSG2 determines that the link has failed. Defines the maximum number of Cisco Persistent Storage Device (PSD) retries allowed before the CSG2 determines that the link has failed. Defines the maximum number of quota server retries allowed before the CSG2 determines that the link has failed.
A-134
OL-22840-05
Appendix A
CSG2 Command Reference ip csg iscsi drain delay
ip csg iscsi drain delay

To define the delay interval, in seconds, before draining packets from the Storage Area Network (SAN) connected to the Internet Small Computer Systems Interface (iSCSI) when the Billing Mediation Agent (BMA) becomes active, use the ip csg iscsi drain delay command in global configuration mode. To delete the drain delay interval, use the no form of this command. ip csg iscsi drain delay number-of-seconds no ip csg iscsi drain delay
Syntax Description
number-of-seconds
Delay interval, in seconds, before draining packets from the SAN. The range is from 0 to 3. The default value is 1. A value of 0 means no delay.
Command Default
Command Modes
Command History
Release 12.4(15)MD
Usage Guidelines
The CSG2 can buffer GTP messages in the Storage Area Network (SAN) connected to the Internet Small Computer Systems Interface (iSCSI), if so configured. (For more information, see the Configuring iSCSI Support section on page 8-1.) By default, the CSG2 limits the rate at which GTP messages are read from the SAN to 167 packets/second (500 packets/3 seconds). However, you can use the ip csg iscsi drain delay command to change that rate. For example, specifying an interval of 2 seconds yields a rate of 250 packets/second (500 packets/2 seconds).
Examples
The following example shows how to specify a SAN drain delay interval of 2 seconds:
ip csg iscsi drain delay 2
Related Commands
Command ip csg iscsi drain packet
Description Defines the number of packets to be drained from the Storage Area Network (SAN) connected to the Internet Small Computer Systems Interface (iSCSI) per drain delay interval when the Billing Mediation Agent (BMA) becomes active. Specifies the Internet Small Computer Systems Interface (iSCSI) target to be used as backup storage for the CSG2. Creates an iSCSI profile for an iSCSI target on the CSG2, and enters iSCSI configuration mode.
ip csg iscsi profile ip iscsi target-profile
A-135
Appendix A ip csg iscsi drain packet

To define the number of packets to be drained from the Storage Area Network (SAN) connected to the Internet Small Computer Systems Interface (iSCSI) per drain delay interval when the Billing Mediation Agent (BMA) becomes active, use the ip csg iscsi drain packet command in global configuration mode. To delete the drain packet, use the no form of this command. ip csg iscsi drain packet number-of-packets no ip csg iscsi drain packet
Syntax Description
number-of-packets
Number of packets to be drained from the SAN per drain delay interval. The range is from 1 to 64000. The default is 500.
Command Default
The default value is 500 packets.
Command Modes
Command History
Release 12.4(15)MD
Usage Guidelines
The CSG2 can buffer GTP messages in the Storage Area Network (SAN) connected to the Internet Small Computer Systems Interface (iSCSI), if so configured. (For more information, see the Configuring iSCSI Support section on page 8-1.) By default, the CSG2 limits the rate at which GTP messages are read from the SAN to 167 packets/second (500 packets/3 seconds). However, you can use the ip csg iscsi drain packet command to change that rate. For example, specifying that 600 packets are to be drained per interval yields a rate of 200 packets/second (600 packets/3 seconds).
Examples
The following example shows how to specify that 1000 packets are to be drained from the SAN per drain delay interval:
ip csg iscsi drain packet 1000
Related Commands
Description Defines the delay interval, in seconds, before draining packets from the Storage Area Network (SAN) connected to the Internet Small Computer Systems Interface (iSCSI) when the Billing Mediation Agent (BMA) becomes active.
A-136
OL-22840-05
Appendix A
CSG2 Command Reference ip csg iscsi drain packet
Command ip csg iscsi profile ip iscsi target-profile
Description Specifies the Internet Small Computer Systems Interface (iSCSI) target to be used as backup storage for the CSG2. Creates an iSCSI profile for an iSCSI target on the CSG2, and enters iSCSI configuration mode.
A-137
Appendix A ip csg iscsi profile
ip csg iscsi profile

To specify the Internet Small Computer Systems Interface (iSCSI) target to be used as backup storage for the CSG2, use the ip csg iscsi profile command in global configuration mode. To delete the iSCSI target, use the no form of this command. ip csg iscsi profile target-profile-name no ip csg iscsi profile
Syntax Description
target-profile-name
Name of the iSCSI target profile to be used as backup storage.
Command Default
No iSCSI target is specified.
Command Modes
Command History
Release 12.4(15)MD
Usage Guidelines
You can associate only one iSCSI target profile with each CSG2.
Examples
The following example shows how to specify CSG_BACKUP as the iSCSI target:
ip csg iscsi profile CSG_BACKUP
Related Commands
Description Defines the delay interval, in seconds, before draining packets from the Storage Area Network (SAN) connected to the Internet Small Computer Systems Interface (iSCSI) when the Billing Mediation Agent (BMA) becomes active. Defines the number of packets to be drained from the Storage Area Network (SAN) connected to the Internet Small Computer Systems Interface (iSCSI) per drain delay interval when the Billing Mediation Agent (BMA) becomes active. Creates an iSCSI profile for an iSCSI target on the CSG2, and enters iSCSI configuration mode.
ip iscsi target-profile
A-138
OL-22840-05
Appendix A
CSG2 Command Reference ip csg keys
ip csg keys
To define Triple Data Encryption Algorithm (3DEA) keys for the CSG2, use the ip csg keys command in global configuration mode. To delete the keys, use the no form of this command. ip csg keys [encrypt] key1 key2 key3 no ip csg keys [encrypt] key1 key2 key3
Syntax Description
encrypt
(Optional) Indicates how the CSG2 keys are represented when the configuration is displayed (for example, show run), or how it is written to nonvolatile memory (for example, write memory). The valid values are:
Note
0The keys are stored in plain text. This is the default setting. 7The keys are encrypted before they are displayed or written to nonvolatile memory. If your router is configured to encrypt all passwords, then the password is represented as 7 followed by the encrypted text. See the Cisco IOS service command for more details.
key1 key2 key3
First CSG2 key value. Second CSG2 key value. Third CSG2 key value.
Command Default
The keys are stored in plain text.
Command Modes
Command History
Release 12.4(24)MD
Usage Guidelines
All three keys are required.
Examples
The following example shows how to encrypt CSG2 keys TEST-KEY1,TEST-KEY2, and TEST-KEY3:
ip csg keys 7 TEST-KEY1 TEST-KEY2 TEST-KEY3
A-139
Appendix A ip csg license syslog enable
ip csg license syslog enable

To enable the CSG2 to generate system (syslog) messages when the subscriber threshold is exceeded, use the ip csg license syslog enable command in global configuration mode. To disable the syslog messages, use the no form of this command. ip csg license syslog enable no ip csg license syslog enable
Syntax Description
Command Default
The CSG2 generates syslog messages when the subscriber threshold is exceeded.
Command Modes
Command History
Release 12.4(22)MD
Usage Guidelines
If the ip csg license warning-enable command is configured, and the number of concurrent subscribers accessing the network exceeds the configured subscriber threshold, the CSG2 generates a license-exceeded SNMP trap, and begins generating license-exceeded syslog messages. The CSG2 continues to generate license-exceeded syslog messages every five minutes, even if the number of concurrent subscribers accessing the network drops below the subscriber threshold, until one of the following actions occurs:

The CSG2 is prevented from generating the syslog messages, using the no form of the ip csg license syslog enable command. The CSG2 is prevented from generating the syslog messages and the relevant SNMP traps, using the clear ip csg license warning command in global configuration mode.
Note
The clear ip csg license warning command stops the generation of syslog messages and SNMP traps until the limit is exceeded again. Therefore, if the current CSG2 User Table size is greater than the current configured value, and you enter the clear ip csg license warning command, the CSG2 begins generating notifications again when the next User Table entry is created. The subscriber threshold is changed, using the ip csg license warning-enable command in global configuration mode (or disabled, using the no form of the command).
Examples
The following example shows how to prevent the CSG2 from generating license-exceeded syslog messages:
no ip csg license syslog enable
A-140
OL-22840-05
Appendix A
CSG2 Command Reference ip csg license syslog enable
Related Commands
Command clear ip csg ip csg license warning-enable snmp-server enable traps csg
Description Clears the CSG2. Sets a subscriber threshold for the CSG2 to generate license-exceeded notifications. Enables Simple Network Management Protocol (SNMP) notification types that are available on the CSG2
A-141
Appendix A ip csg license warning-enable
ip csg license warning-enable

To set a subscriber threshold for the CSG2 to generate license-exceeded notifications, use the ip csg license warning-enable command in global configuration mode. To restore the default subscriber threshold, use the no form of this command. ip csg license warning-enable threshold no ip csg license warning-enable
Syntax Description
threshold
Subscriber threshold (the number of concurrent CSG2 subscribers that can access the network). If this threshold is exceeded, the CSG2 begins generating license-exceeded notifications (syslog messages and SNMP traps). We recommend that you set the subscriber threshold to the number of subscribers allowed by your purchased CSG2 license. The valid range is 1 to 1,250,000 with the 2 GB-SAMI option, or 1 to 500,000 with the 1 GB-SAMI option. The default is 300,000.
Command Default
The CSG2 does not generate license-exceeded notifications.
Command Modes
Command History
Release 12.4(22)MD
Usage Guidelines
If this command is configured, and the number of concurrent subscribers accessing the network exceeds the configured subscriber threshold, the CSG2 generates a license-exceeded SNMP trap, and begins generating license-exceeded syslog messages. The CSG2 continues to generate license-exceeded syslog messages every five minutes, even if the number of concurrent subscribers accessing the network drops below the subscriber threshold, until one of the following actions occurs:

The subscriber threshold is changed, using the ip csg license warning-enable command (or disabled, using the no form of the command). The CSG2 is prevented from generating the syslog messages, using the clear ip csg license warning command in global configuration mode.
Note
The clear ip csg license warning command stops the generation of syslog messages until the limit is exceeded again. Therefore, if the current CSG2 User Table size is greater than the current configured value, and you enter the clear ip csg license warning command, the CSG2 begins generating notifications again when the next User Table entry is created.
A-142
OL-22840-05
Appendix A
CSG2 Command Reference ip csg license warning-enable
The CSG2 is prevented from generating the syslog messages, using the no form of the ip csg license syslog enable command in global configuration mode. The CSG2 is prevented from generating the SNMP traps, using the no form of the snmp-server enable traps csg license warning-enable command in global configuration mode.
Note
Sticky entries in the CSG2 User Table are included in the count of concurrent subscribers. The CSG2 uses this command only to determine when and if to generate license-exceeded notifications. This command does not increase or decrease the actual number of concurrent subscribers allowed by the CSG2 license that you purchased.
Examples
The following example shows how to enable the CSG2 to generate license-exceeded syslog messages and SNMP traps if more than 400,000 concurrent subscribers are accessing the network:
ip csg license warning-enable 400000
Related Commands
Command clear ip csg ip csg license syslog enable snmp-server enable traps csg
Description Clears the CSG2. Enables the CSG2 to generate system (syslog) messages when the subscriber threshold is exceeded. Enables Simple Network Management Protocol (SNMP) notification types that are available on the CSG2
A-143
Appendix A ip csg load accel rate
ip csg load accel rate

To set a session acceleration rate for the CSG2, use the ip csg load accel rate command in global configuration mode. To restore the default rate, use the no form of this command. ip csg load accel rate accel-rate no ip csg load accel rate
Syntax Description
accel-rate
Session acceleration rate for each traffic processor (TP), in connections per second. The range is from 0 to 10000. The default value is 2400 connections per second.
Command Default
The default session acceleration rate is 2400 connections/second.
Command Modes
Command History
Release 12.4(24)MDA
Usage Guidelines
The CSG2 applies the session acceleration rate to each TP. That is, the rate is set on a per-TP basis, not on a per-content basis.
Examples
The following example shows how to set the session acceleration rate to 1000 connections/second:
ip csg load accel rate 1000
Related Commands
Command accelerate
Description Enables acceleration for sessions that match a CSG2 content.
A-144
OL-22840-05
Appendix A
CSG2 Command Reference ip csg map
ip csg map
To define the CSG2 billing content filters (attribute, header, method, and URL maps), and to enter CSG2 map configuration mode, use the ip csg map command in global configuration mode. To turn off the service, use the no form of this command. ip csg map map-name no ip csg map map-name
Syntax Description
map-name
Name of the map. The name can be from 1 to 15 characters long, and can include uppercase or lowercase letters (the CSG2 changes all letters to uppercase), numbers, and any special characters.
Command Default
None
Command Modes
Command History
Release 12.4(11)MD
Modification This command was migrated from CSG1. Changes from CSG1: The header and url keywords were removed.
Usage Guidelines
The CSG2 maps are used to match attributes, headers, methods, or URLs against a pattern to determine whether flows are to be processed by the CSG2 accounting services. The attributes, headers, methods, or URLs that are to be matched against a pattern are defined by the following commands:

match attribute (CSG2 map) match header (CSG2 map) match method (CSG2 map) match url (CSG2 map)
When configuring a map, keep the following considerations in mind:

We recommend that you configure the URL match pattern during your maintenance window, or during off-peak hours. You cannot specify different types of match patterns in a given map. For example, a map can include one or more match header statements, but it cannot include both match header statements and match url statements. You can specify up to four maps in a given policy: one for attribute matching, one for header matching, one for method matching, and one for URL matching. For example, the following is a valid configuration:
ip csg map HOSTMAP
A-145
Appendix A ip csg map
match header host1 value *.2.*.44 ! ip csg map URLMAP match url */mobile/index.wml ! ip csg policy MAP-POLICY map HOSTMAP map URLMAP
In this example, a flow must match both HOSTMAP and URLMAP in order to match policy MAP-POLICY.
Examples
The following example shows how to configure a CSG2 URL map named MOVIES:
ip csg map MOVIES match url *.movies_(comedy|action|drama).com/*.mpeg
Related Commands
Command ip csg case-sensitive ip csg policy ip csg regex memory map (CSG2 policy)
Description Specifies whether to treat CSG2 sticky objects and attribute, header, method, and URL match patterns as case-sensitive. Defines a policy for qualifying flows for the CSG2 accounting services, and enters CSG2 policy configuration mode,. Specifies the size of the CSG2 regular expression (regex) memory. References an attribute, header, method, or URL map that is part of a CSG2 billing policy.
match attribute (CSG2 Specifies a Layer 7 protocol header attribute match pattern for a CSG2 billing map. map) match header (CSG2 map) match method (CSG2 map) normalize-url Specifies a header match pattern for a CSG2 billing map. Specifies a method match pattern for a CSG2 billing map.
match url (CSG2 map) Specifies a URL match pattern for a CSG2 billing map. Enables URL map normalization for a CSG2 content.
A-146
OL-22840-05
Appendix A
CSG2 Command Reference ip csg mode single-tp
ip csg mode single-tp

To enable the CSG2 to use a single traffic processor (TP) instead of multiple TPs, use the ip csg mode single-tp command in global configuration mode. To restore the default setting, use the no form of this command. ip csg mode single-tp no ip csg mode single-tp
Syntax Description
Command Default
The CSG2 operates in multiple-TP mode.
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
In normal multiple-TP mode, the CSG2 distributes subscriber traffic among all of the TPs, based on each subscribers IP address. In single-TP mode, the CSG2 dispatches traffic for all subscribers to the first TP to be processed. Single-TP mode is required for HTTP X-Forwarded-For operation. Before configuring the CSG2 for X-Forwarded-For operation, configure the CSG2 for single-TP mode by entering the ip csg mode single-tp command, then performing a write memory, then restarting the CSG2. To switch out of single-TP mode, enter the no ip csg mode single-tp command, then perform a write memory, then restart the CSG2. If you intend to operate in single-TP mode, the ip csg mode single-tp command must be the first command in your CSG2 configuration.
Examples
The following example shows how to configure single-TP mode for the CSG2:
ip csg mode single-tp
Related Commands
Command subscriber-ip http-header x-forwarded-for (CSG2 content)
Description Specifies that the CSG2 is to obtain the subscriber's IP address from the HTTP X-Forwarded-For header.
A-147
Appendix A ip csg pcc gx
ip csg pcc gx
To enable Gx on the CSG2, use the ip csg pcc gx command in global configuration mode. To disable Gx on the CSG2, use the no form of this command. ip csg pcc gx no ip csg pcc gx
Syntax Description
Command Default
None
Command Modes
Command History
Release 12.4(22)MDA
Examples
The following example shows how to enable Gx on the CSG2:

ip csg pcc gx
Related Commands
Command ip csg select ip csg user profile pcc gx pcrf failure
Description Associates a CSG2 user profile with a subscriber. Defines a user profile to be associated with a CSG2 subscriber, and enters CSG2 user profile configuration mode. Enables Gx for subscribers associated with a CSG2 user profile. Defines the actions that the CSG2 is to take for a Policy Control & Charging (PCC) user if the Policy and Charging Rule Function (PCRF) fails when the user session is activated. Defines a Mobile Policy Control & Charging (MPCC) profile to be used by the CSG2 when sending per-user Credit Control Requests (CCRs) to the Policy and Charging Rule Function (PCRF). Defines the actions that the CSG2 is to take for a Policy Control & Charging (PCC) user if the Policy and Charging Rule Function (PCRF) times out.
pcrf profile
pcrf timeout
A-148
OL-22840-05
Appendix A
CSG2 Command Reference ip csg policy
ip csg policy
To define a policy for qualifying flows for the CSG2 billing services, and to enter CSG2 policy configuration mode, use the ip csg policy command in global configuration mode. To turn off the service, use the no form of this command. ip csg policy policy-name no ip csg policy policy-name
Syntax Description
policy-name
Name of a policy that applies to the content for this service. The name can be from 1 to 15 characters long, and can include uppercase or lowercase letters (the CSG2 changes all letters to uppercase), numbers, and any special characters.
Command Default
None
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
Because of limitations on the number of URL match patterns that the CSG2 can handle, do not define more than 16,000 policies. For more information on URL match patterns, see the description of the match url (CSG2 map) command. The characteristics of each policy are defined by the following commands:

accounting (CSG2 policy) class-map (CSG2 policy) insert header-group (CSG2 policy) map (CSG2 policy)
You can either configure maps (that is, attribute, header, method, or URL maps) on a given policy, or you can associate the policy with a class map; you cannot do both. If you do, the CSG2 ignores the configured maps. You cannot specify different types of match patterns in a given map. For example, a map can include one or more match header statements, but it cannot include both match header statements and match url statements.
A-149
Appendix A ip csg policy
You can specify up to four maps in a given policy: one for attribute matching, one for header matching, one for method matching, and one for URL matching. For example, the following is a valid configuration:
ip csg map HOSTMAP match header host1 value *.2.*.44 ! ip csg map URLMAP match url */mobile/index.wml ! ip csg policy MAP-POLICY map HOSTMAP map URLMAP
Examples
The following example shows how to configure a CSG2 policy named MOVIES_COMEDY:
ip csg policy MOVIES_COMEDY
Related Commands
Command accounting (CSG2 policy) class-map (CSG2 policy) insert header-group (CSG2 policy) ip csg content ip csg map
Description Specifies accounting and an optional customer string for a CSG2 policy. Associates a global class map with a CSG2 policy. Associates a header group for a CSG2 policy. Configures content for CSG2 services, and enters CSG2 content configuration mode. Defines the CSG2 billing content filters (attribute, header, method, and URL maps), and enters CSG2 map configuration mode. Configures a CSG2 content billing service, and enters CSG2 service configuration mode. References an attribute, header, method, or URL map that is part of a CSG2 billing policy. Specifies a header match pattern for a CSG2 billing map. Specifies a method match pattern for a CSG2 billing map. Specifies a URL match pattern for a CSG2 billing map.
ip csg service map (CSG2 policy) match header (CSG2 map) match method (CSG2 map) match url (CSG2 map)
A-150
OL-22840-05
Appendix A
CSG2 Command Reference ip csg preload request
ip csg preload request

To configure a policy preloading retransmission delay and a retransmission number for the CSG2 to use when sending a Policy Preloading Request to the Policy and Charging Rule Function (PCRF), use the ip csg preload request command in global configuration mode. To restore the default settings, use the no form of this command. ip csg preload request delay delay-in-seconds retries number-of-retries no ip csg preload request
Syntax Description
delay delay-in-seconds
Number of seconds to wait for a policy preload response (CCA) before sending another policy preload request (CCR). The range is from 5 to 60. The default value is 15 seconds. Number of times to retransmit the message. The range is from 1 to 10. The default setting is 3 retries.
retries number-of-retries
Command Default
The default delay is 15 seconds. The default number of retries is 3.
Command Modes
Command History
Release 12.4(11)MDA
Examples
The following example configures a delay of 10 seconds with 5 retries:

ip csg preload request delay 10 retries 5
Related Commands
Command csg start preload
Description Begins preloading policies for the CSG2 from the Policy and Charging Rule Function (PCRF).
A-151
Appendix A ip csg psd
ip csg psd
To configure a Cisco Persistent Storage Device (PSD), use the ip csg psd command in global configuration mode. To remove the PSD, use the no form of this command. ip csg psd [vrf vrf-name] ipv4-address port-number no ip csg psd [vrf vrf-name] ipv4-address port-number
Syntax Description
vrf vrf-name
(Optional) Virtual Routing and Forwarding (VRF) table which the CSG2 is to use to communicate with the PSD.
Note
ipv4-address
IPv4 address for packets destined for the PSD. The CSG2 differentiates PSDs on the basis of their IPv4 addresses. When you configure a PSD, make sure that its IPv4 address matches on both the active CSG2 and the standby CSG2.
port-number
Port number for packets destined for the PSD. The CSG2 differentiates PSDs on the basis of their port numbers. When you configure a PSD, make sure that its port number matches on both the active CSG2 and the standby CSG2.
Command Default
No PSDs are configured. If no VRF table is specified, the CSG2 uses the global routing table to communicate with the PSD.
Command Modes
Command History
Release 12.4(11)MD

The name of this command changed from records-storage to ip csg psd. The configuration mode for this command changed from CSG accounting configuration to global configuration. The vrf vrf-name keyword and argument were added.
Usage Guidelines
You must specify the PSD local port using the ip csg psd local-port command before you enter the ip csg psd command.
Note
You can configure one and only one PSD for each CSG2.
A-152
OL-22840-05
Appendix A
CSG2 Command Reference ip csg psd
Examples
The following example configures a PSD with IPv4 address 1.2.3.4 and port number 7777, that uses VRF table PSDVRF to communicate with the CSG2:
ip csg psd vrf PSDVRF 1.2.3.4 7777
Related Commands
Command ip csg psd drain delay
Description Defines the delay interval, in seconds, before draining packets from the Cisco Persistent Storage Device (PSD) when the Billing Mediation Agent (BMA) becomes active. Defines the number of packets to be drained from the Cisco Persistent Storage Device (PSD) per drain delay interval when the Billing Mediation Agent (BMA) becomes active. Defines the Cisco Persistent Storage Device (PSD) keepalive time interval for the CSG2. Configures the local port on which the CSG2 communicates with the Cisco Persistent Storage Device (PSD). Specifies the maximum number of general packet radio service (GPRS) tunneling protocol prime (GTP) messages, beyond the size of the Billing Mediation Agent (BMA) message queue, that the CSG2 can buffer for the Cisco Persistent Storage Device (PSD). Specifies the maximum number of general packet radio service (GPRS) tunneling protocol prime (GTP) messages, beyond the size of the Billing Mediation Agent (BMA) message queue, that the CSG2 can buffer for the Cisco Persistent Storage Device (PSD). Defines the Cisco Persistent Storage Device (PSD) retransmit time interval for the CSG2. Defines the maximum number of Cisco Persistent Storage Device (PSD) retries allowed before the CSG2 determines that the link has failed. Defines the Cisco Persistent Storage Device (PSD) transmit window size for the CSG2.
ip csg psd keepalive ip csg psd local-port ip csg psd margin
ip csg psd margin
ip csg psd retransmit ip csg psd retries ip csg psd window
A-153
Appendix A ip csg psd drain delay
ip csg psd drain delay

To define the delay interval, in seconds, before draining packets from the Cisco Persistent Storage Device (PSD) when the Billing Mediation Agent (BMA) becomes active, use the ip csg psd drain delay command in global configuration mode. To delete the drain delay interval, use the no form of this command. ip csg psd drain delay number-of-seconds no ip csg psd drain delay
Syntax Description
number-of-seconds
Delay interval, in seconds, before draining packets from the PSD. The range is from 0 to 3. The default value is 1. A value of 0 means no delay.
Command Default
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
The CSG2 can buffer GTP messages in the Cisco Persistent Storage Device (PSD), if so configured. (For more information, see the Configuring PSD Support section on page 7-1.) By default, the CSG2 limits the rate at which GTP messages are read from the PSD to 500 packets/second. However, you can use the ip csg psd drain delay command to change that rate. For example, specifying an interval of 2 seconds yields a rate of 250 packets/second (500 packets/2 seconds).
Examples
The following example shows how to specify a PSD drain delay interval of 2 seconds:
ip csg psd drain delay 2
Related Commands
Command ip csg psd ip csg psd drain packet
Description Configures a Cisco Persistent Storage Device (PSD). Defines the number of packets to be drained from the Cisco Persistent Storage Device (PSD) per drain delay interval when the Billing Mediation Agent (BMA) becomes active.
A-154
OL-22840-05
Appendix A
CSG2 Command Reference ip csg psd drain packet

To define the number of packets to be drained from the Cisco Persistent Storage Device (PSD) per drain delay interval when the Billing Mediation Agent (BMA) becomes active, use the ip csg psd drain packet command in global configuration mode. To delete the drain packet, use the no form of this command. ip csg psd drain packet number-of-packets no ip csg psd drain packet
Syntax Description
number-of-packets
Number of packets to be drained from the PSD per drain delay interval. The range is from 1 to 64000. The default is 500.
Command Default
The default value is 500 packets.
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
The CSG2 can buffer GTP messages in the Cisco Persistent Storage Device (PSD), if so configured. (For more information, see the Configuring PSD Support section on page 7-1.) By default, the CSG2 limits the rate at which GTP messages are read from the PSD to 500 packets/second. However, you can use the ip csg psd drain packet command to change that rate. For example, specifying that 1000 packets are to be drained per interval yields a rate of 1000 packets/second (1000 packets/1 second).
Examples
The following example shows how to specify that 1000 packets are to be drained from the PSD per drain delay interval:
ip csg psd drain packet 1000
Related Commands
Command ip csg psd ip csg psd drain delay
Description Configures a Cisco Persistent Storage Device (PSD). Defines the delay interval, in seconds, before draining packets from the Cisco Persistent Storage Device (PSD) when the Billing Mediation Agent (BMA) becomes active.
A-155
Appendix A ip csg psd keepalive
ip csg psd keepalive

To define the Cisco Persistent Storage Device (PSD) keepalive time interval for the CSG2, use the ip csg psd keepalive command in global configuration mode. To reset the PSD keepalive timer to the default value, use the no form of this command. ip csg psd keepalive number-of-seconds no ip csg psd keepalive
Syntax Description
number-of-seconds
Time, in seconds, between PSD keepalives. The range is from 1 to 65535. The default value is 60.
Command Default
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
Examples
The following example shows how to specify a PSD keepalive time of 300 seconds:
ip csg psd keepalive 300
Related Commands
Command ip csg bma keepalive ip csg ipc keepalive ip csg psd ip csg quota-server keepalive
Description Defines the Billing Mediation Agent (BMA) keepalive time interval for the CSG2. Defines the Interprocessor Communication (IPC) keepalive time interval for the CSG2. Configures a Cisco Persistent Storage Device (PSD). Defines the quota-server keepalive time interval for the CSG2.
A-156
OL-22840-05
Appendix A
CSG2 Command Reference ip csg psd local-port
ip csg psd local-port

To configure the local port on which the CSG2 communicates with the Cisco Persistent Storage Device (PSD), use the ip csg psd local-port command in global configuration mode. To remove a quota server local port configuration, use the no form of this command. ip csg psd local-port port-number no ip csg psd local-port
Syntax Description
port-number
Port number on which the CSG2 is to communicate with the PSD. The range is from 1024 to 65535. 5000 is not a valid port number. The PSD local port number must be different from the Billing Mediation Agent (BMA) local port number and from the quota server local port number (configured with the ip csg bma local-port command and the ip csg quota-server local-port command, respectively).
Command Default
No PSD local port is configured.
Command Modes
Command History
Release 12.4(11)MD

The name of this command changed from records-storage local-port to ip csg psd local-port. The configuration mode for this command changed from CSG accounting configuration to global configuration.
Usage Guidelines
You must specify the PSD local port using the ip csg psd local-port command before you enter the ip csg psd command.
Note
You can configure one and only one PSD for each CSG2.
Examples
The following example configures a PSD with local port number 7777:
ip csg psd local-port 7777
A-157
Appendix A ip csg psd local-port
Related Commands
Command ip csg bma local-port ip csg psd ip csg quota-server local-port
Description Configures the local port on which the CSG2 communicates with the Billing Mediation Agent (BMA). Configures a Cisco Persistent Storage Device (PSD). Configures the local port on which the CSG2 communicates with quota servers.
A-158
OL-22840-05
Appendix A
CSG2 Command Reference ip csg psd margin
ip csg psd margin

To specify the maximum number of general packet radio service (GPRS) tunneling protocol prime (GTP) messages, beyond the size of the Billing Mediation Agent (BMA) message queue, that the CSG2 can buffer for the Cisco Persistent Storage Device (PSD), use the ip csg psd margin command in global configuration mode. To restore the default setting, use the no form of this command. ip csg psd margin number no ip csg psd margin
Syntax Description
number
Maximum number of GTP messages, beyond the size of the BMA message queue, that can be buffered for the PSD. The range is from 100 to 65535. The default is 2000.
Command Default
The CSG2 buffers up to 2000 GTP messages, beyond the size of the BMA message queue.
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
Examples
The following example shows how to configure the CSG2 to buffer up to 3000 GTP messages, beyond the size of the BMA message queue:
ip csg psd margin 2000
Related Commands
Command ip csg bma messages
Description Specifies the maximum number of general packet radio service (GPRS) tunneling protocol prime (GTP) messages that the CSG2 can buffer for all Billing Mediation Agents (BMAs). Configures a Cisco Persistent Storage Device (PSD).
ip csg psd
A-159
Appendix A ip csg psd retransmit
ip csg psd retransmit

To define the Cisco Persistent Storage Device (PSD) retransmit time interval for the CSG2, use the ip csg psd retransmit command in global configuration mode. To reset the PSD retransmit timer to the default value, use the no form of this command. ip csg psd retransmit number-of-seconds no ip csg psd retransmit
Syntax Description
number-of-seconds
Time, in seconds, between PSD retransmits. The range is from 1 to 65535. The default value is 4.
Command Default
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
Examples
The following example shows how to specify a PSD retransmit time of 2 seconds:
ip csg psd retransmit 2
Related Commands
Command ip csg bma retransmit ip csg ipc retransmit ip csg psd ip csg quota-server retransmit
Description Defines the Billing Mediation Agent (BMA) retransmit time interval for the CSG2. Defines the Interprocessor Communication (IPC) retransmit time interval for the CSG2. Configures a Cisco Persistent Storage Device (PSD). Defines the quota server retransmit time interval for the CSG2.
A-160
OL-22840-05
Appendix A
CSG2 Command Reference ip csg psd retries
ip csg psd retries

To define the maximum number of Cisco Persistent Storage Device (PSD) retries allowed before the CSG2 determines that the link has failed, use the ip csg psd retries command in global configuration mode. To reset the number of PSD retries to the default value, use the no form of this command. ip csg psd retries [packet] number-of-retries no ip csg psd retries
Syntax Description
(Optional) Attempt to send a packet to the PSD the specified number of times, then discard the packet. Maximum number of PSD retries allowed by the CSG2. The range is from 1 to 65535. The default value is 3.
Command Default
Command Modes
Command History
Release 12.4(11)MD 12.4(15)MD
Usage Guidelines
We recommend that you change the number of retries allowed only when directed to do so by Cisco Technical Assistance Center (TAC) engineers. In most environments, the default value is the most appropriate setting. By default, the CSG2 retries a packet forever; it never discards a packet. If you configure the ip csg psd retries packet command, the CSG2 tries to send a packet to the PSD the specified number of times, then discards the packet. (The first attempt to send a packet to the PSD is not counted as a retry.) For example, if you configure ip csg psd retries packet 4, the CSG2 tries to send a packet to the PSD five times before discarding it (the initial attempt plus four retries).
Examples
The following example shows how to allow two PSD retries:

ip csg psd retries 2
The following example shows how to allow the CSG2 to try to send a packet to the PSD four times, in addition to the initial attempt:
ip csg psd retries packet 4
A-161
Appendix A ip csg psd retries
Related Commands
Command ip csg bma retries ip csg ipc retries
Description Defines the maximum number of Billing Mediation Agent (BMA) retries allowed before the CSG2 determines that the link has failed. Defines the maximum number of Interprocessor Communication (IPC) retries allowed before the CSG2 determines that the link has failed. Configures a Cisco Persistent Storage Device (PSD). Defines the maximum number of Billing Mediation Agent (BMA) retries allowed before the CSG2 determines that the link has failed.
ip csg psd ip csg quota-server retries
A-162
OL-22840-05
Appendix A
CSG2 Command Reference ip csg psd window
ip csg psd window

To define the Cisco Persistent Storage Device (PSD) transmit window size for the CSG2, use the ip csg psd window command in global configuration mode. To reset the PSD transmit window size to the default value, use the no form of this command. ip csg psd window {max window-size | min window-size | min auto} no ip csg psd window {max | min}
Syntax Description
Maximum size, in packets, of the PSD transmit window. The range is from 1 to 65535. The default value is 128. Minimum size, in packets, of the PSD transmit window. The range is from 1 to 65535. Specifies that the CSG2 is to determine the minimum size of the PSD transmit window automatically. The CSG2 keeps track of the maximum number of ACKs received in one response and sets that number as the minimum window.
Command Default
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
Examples
The following example shows how to set the maximum PSD transmit window to 64 packets:
ip csg psd window max 64
Related Commands
Command ip csg bma window ip csg psd ip csg quota-server window
Description Defines the Billing Mediation Agent (BMA) transmit window size for the CSG2. Configures a Cisco Persistent Storage Device (PSD). Defines the quota server transmit window size for the CSG2.
A-163
Appendix A ip csg qos profile
ip csg qos profile

To configure a Quality of Service (QoS) profile name for the CSG2, and to enter CSG2 QoS profile configuration mode, use the ip csg qos profile command in global configuration mode. To delete the QoS profile name, use the no form of this command. ip csg qos profile qos-profile-name no ip csg qos profile qos-profile-name
Syntax Description
qos-profile-name
Name of the QoS profile. The name can be from 1 to 15 characters long, and can include uppercase or lowercase letters (the CSG2 changes all letters to uppercase), numbers, and any special characters.
Command Default
Command Modes
Command History
Release 12.4(22)MD
Usage Guidelines
A single QoS profile can be used by more than one service or billing plan at the same time. You can configure up to 2048 QoS profiles per CSG2. The characteristics of each profile are defined by the following command:
police
Examples
The following example shows how to configure a QoS profile name:

ip csg qos profile CSG2QOS
Related Commands
Command police qos profile (CSG2 billing) qos profile (CSG2 service)
Description Configures rate limiting (policing) for a CSG2 Quality of Service (QoS) profile. Associates a Quality of Service (QoS) profile with a CSG2 billing plan. Associates a Quality of Service (QoS) profile with a CSG2 service.
A-164
OL-22840-05
Appendix A
CSG2 Command Reference ip csg quota-server
ip csg quota-server
To configure CSG2 quota servers, use the ip csg quota-server command in global configuration mode. To remove a quota server configuration, use the no form of this command. ip csg quota-server [vrf vrf-name] ipv4-address port-number {priority | eggsn} no ip csg quota-server [vrf vrf-name] ipv4-address port-number {priority | eggsn}
Syntax Description
vrf vrf-name
(Optional) Virtual Routing and Forwarding (VRF) table which the CSG2 is to use to communicate with the quota server.
Note
ipv4-address
IPv4 address of the quota server. When you configure a quota server, make sure that its IPv4 address and port number match on both the active CSG2 and the standby CSG2. You can configure multiple quota servers with the same IPv4 address, but the CSG2 does not support nodealive or redirect for multiple quota servers with the same IPv4 address. You can configure up to 32 quota servers. Each quota server must have a unique IPv4 address (or a unique IPv4 address-VRF name combination, if VRF is configured).
port-number
Port number of the quota server. The range is from 1 to 65535. The CSG2 differentiates quota servers on the basis of their port numbers. When you configure a quota server, make sure that its port number matches on both the active CSG2 and the standby CSG2.
priority
Defines active and standby quota servers. The priority specifies the order of preference of the quota servers. A lower number indicates a higher priority. If the current quota server becomes unusable, the CSG2 uses the highest priority quota server available. The range of priorities is from 1 to 1000, but you can configure only up to 32 quota servers. Each quota server must be configured with a unique priority. Priorities for different quota servers do not have to be sequential. That is, you can have three quota servers with priorities 1, 5, and 10, respectively.
eggsn
Indicates that the quota server is enabled for eGGSN.
Command Default
No quota servers are configured. If no VRF table is specified, the CSG2 uses the global routing table to communicate with the quota server.
Command Modes
A-165
Appendix A ip csg quota-server
Command History
Release 12.4(11)MD

The name of this command changed from quota server to ip csg quota-server. The configuration mode for this command changed from CSG user group configuration to global configuration. The vrf vrf-name keyword and argument were added. The reassign keyword was removed.
12.4(24)MD
The eggsn keyword was added.
Usage Guidelines
CSG2 quota servers return billing quota values for subscribers. For prepaid billing, you must configure at least one quota server. You can configure up to 32 quota servers. Each quota server must have a unique priority and a unique IPv4 address (or a unique IPv4 address-VRF name combination, if VRF is configured).
Note
You can configure multiple quota servers with the same IPv4 address, but the CSG2 does not support nodealive or redirect for multiple quota servers with the same IPv4 address. A quota server can recognize a duplicate quota-download request, as when general packet radio service (GPRS) tunneling protocol (GTP) retransmits a packet. When the quota server detects a duplicate quota-download request, it resends the same quota that it sent for the original request. To disable quota server reassignment (that is, to prevent the CSG2 from assigning a new quota server to a subscriber if the original quota server fails), use the no form of the ip csg quota-server reassign command. If an eGGSN quota server fails, the corresponding user Affinity does not be failover to the new eGGSN quota server.
Examples
The following example configures a quota server with IPv4 address 1.2.3.4, port number 6666, and priority 10, that uses VRF table QSVRF to communicate with the CSG2:
ip csg quota-server vrf QSVRF 1.2.3.4 6666 10
Related Commands
Command ip csg quota-server activate ip csg quota-server keepalive ip csg quota-server local-port ip csg quota-server messages
Description Activates one or more quota servers. Defines the quota server keepalive time interval for the CSG2. Configures the local port on which the CSG2 communicates with quota servers. Specifies the maximum number of general packet radio service (GPRS) tunneling protocol prime (GTP) messages that the CSG2 can buffer for all quota servers. Reassigns subscribers to a different CSG2 quota server after a failure.
ip csg quota-server reassign
A-166
OL-22840-05
Appendix A
CSG2 Command Reference ip csg quota-server
Command ip csg quota-server retransmit ip csg quota-server retries ip csg quota-server window
Description Defines the quota server retransmit time interval for the CSG2. Defines the maximum number of quota server retries allowed before the CSG2 determines that the link has failed. Defines the quota server transmit window size for the CSG2.
A-167
Appendix A ip csg quota-server activate
ip csg quota-server activate

To activate one or more quota servers, use the ip csg quota-server activate command in global configuration mode. To deactivate quota servers, use the no form of this command. ip csg quota-server activate number no ip csg quota-server activate
Syntax Description
number
Number of quota servers to activate. The range is from 1 to 32. The default value is 1.
Command Default
The default value is 1.
Command Modes
Command History
Release 12.4(11)MD

The name of this command changed from quota activate to ip csg quota-server activate. The configuration mode for this command changed from CSG user group configuration to global configuration. The range for the number argument changed from 1 to 10, to 1 to 32.
Usage Guidelines
Use this command to load-balance quota transactions among multiple active quota servers. When the CSG2 uses multiple active quota servers, it sends all quota transactions for a given user to a particular quota server. The CSG2 stores that quota server assignment in the CSG2 User Table entry for that user. For example, if a configuration has four active quota servers, and one of those quota servers fails, the CSG2 looks for a suitable standby quota server. If the CSG2 finds a suitable standby quota server, it transfers all of the quota transactions from the failed quota server to the new quota server, and updates all of the affected User Table entries to reflect the new quota server assignment. However, if the CSG2 cannot find a suitable standby quota server, it redistributes all of the quota transactions from the failed quota server among the remaining three active quota servers. It does so by finding the User Table entries for the affected users in the quota transactions. The CSG2 then assigns one of the active quota servers to each affected user, and updates the User Table entries to reflect the new quota server assignments. The CSG2 reassigns all quota transactions for a given user to the same quota server.
A-168
OL-22840-05
Appendix A
CSG2 Command Reference ip csg quota-server activate
If the CSG2 cannot find a User Table entry for a user (for example, the user has logged off), it creates a temporary sticky object as a placeholder and assigns a new quota server to the sticky object. This ensures that the remaining quota transactions for that user are sent to the same quota server.
Note
This command is valid only if your CSG2 uses multiple active quota servers. If your CSG2 uses one and only one active quota server, the default settings are sufficient (that is, ip csg quota-server activate 1 sticky 30).
Usage Guidelines
You do not need to use this command to activate a quota server that is enabled for eGGSN (that is, a quota server that is configured with the eggsn option on the ip csg quota-server command). A quota server that is enabled for eGGSN activates as soon as it is configured.
Examples
The following example shows how to activate two quota servers:

ip csg quota-server activate 2
Related Commands
Command ip csg bma activate ip csg quota-server
Description Enables support for multiple active Billing Mediation Agents (BMAs) Configures CSG2 quota servers.
A-169
Appendix A ip csg quota-server keepalive
ip csg quota-server keepalive

To define the quota server keepalive time interval for the CSG2, use the ip csg quota-server keepalive command in global configuration mode. To reset the quota server keepalive timer to the default value, use the no form of this command. ip csg quota-server keepalive number-of-seconds no ip csg quota-server keepalive
Syntax Description
number-of-seconds
Time, in seconds, between quota server keepalives. The range is from 1 to 65535. The default value is 60.
Command Default
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
Examples
The following example shows how to specify a quota server keepalive time of 300 seconds:
ip csg quota-server keepalive 300
Related Commands
Command ip csg bma keepalive ip csg ipc keepalive ip csg psd keepalive ip csg quota-server
Description Defines the Billing Mediation Agent (BMA) keepalive time interval for the CSG2. Defines the Interprocessor Communication (IPC) keepalive time interval for the CSG2. Defines the Cisco Persistent Storage Device (PSD) keepalive time interval for the CSG2. Configures CSG2 quota servers.
A-170
OL-22840-05
Appendix A
CSG2 Command Reference ip csg quota-server local-port
ip csg quota-server local-port

To configure the local port on which the CSG2 communicates with quota servers, use the ip csg quota-server local-port command in global configuration mode. To remove a quota server local port configuration, use the no form of this command. ip csg quota-server local-port port-number no ip csg quota-server local-port
Syntax Description
port-number
Port number on which the CSG2 is to communicate with quota servers. The range is from 1024 to 65535. 5000 is not a valid port number. The quota server local port number must be different from the Billing Mediation Agent (BMA) local port number and from the Persistent Storage Device (PSD) local port number (configured with the ip csg bma local-port command and the ip csg psd local-port command, respectively).
Command Default
No quota server local ports are configured.
Command Modes
Command History
Release 12.4(11)MD

The name of this command changed from quota local-port to ip csg quota-server local-port. The configuration mode for this command changed from CSG user group configuration to global configuration. The range for the port-number argument changed from 1 to 65535, to 1024 to 65535.
Usage Guidelines
For prepaid billing, you must configure a quota server local port.
Note
The CSG2 drops requests (such as nodealive, echo, and redirect requests) unless they come from a configured quota server IP address. The CSG2 also verifies IP addresses against the configured list of quota servers. If there is no match, the CSG2 drops the request. The CSG2 does not look at a requests source port; the CSG2 replies to the port from which the request came.
A-171
Appendix A ip csg quota-server local-port
Examples
The following example configures quota server local port 6666:

ip csg quota-server local-port 6666
Related Commands
Command ip csg bma local-port ip csg psd local-port ip csg quota-server
Description Configures the local port on which the CSG2 communicates with the Billing Mediation Agent (BMA). Configures the local port on which the CSG2 communicates with the Cisco Persistent Storage Device (PSD). Configures CSG2 quota servers.
A-172
OL-22840-05
Appendix A
CSG2 Command Reference ip csg quota-server messages

To specify the maximum number of general packet radio service (GPRS) tunneling protocol prime (GTP) messages that the CSG2 can buffer for all quota servers, use the ip csg quota-server messages command in global configuration mode. To restore the default settings, use the no form of this command. ip csg quota-server messages number no ip csg quota-server messages
Syntax Description
number
Maximum number of GTP messages that can be buffered for all quota servers. The range is from 1 to 65535. The default is 10000.
Command Default
The CSG2 buffers up to 10000 GTP messages.
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
Examples
The following example shows how to configure the CSG2 to buffer up to 12345 GTP messages:
ip csg quota-server messages 12345
Related Commands
Command ip csg bma messages
Description Specifies the maximum number of general packet radio service (GPRS) tunneling protocol prime (GTP) messages that the CSG2 can buffer for all Billing Mediation Agents (BMAs). Specifies the maximum number of general packet radio service (GPRS) tunneling protocol prime (GTP) messages, beyond the size of the Billing Mediation Agent (BMA) message queue, that the CSG2 can buffer for the Cisco Persistent Storage Device (PSD). Configures CSG2 quota servers.
ip csg psd margin
ip csg quota-server
A-173
Appendix A ip csg quota-server reassign

To reassign subscribers to a different CSG2 quota server after a failure, use the ip csg quota-server reassign command in global configuration mode. To disable quota server reassignment for subscribers, use the no form of this command. ip csg quota-server reassign no ip csg quota-server reassign
Syntax Description
Command Default
Subscribers are reassigned to a different quota server after a failure.
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
This command is not supported for quota servers that are enabled for eGGSN (that is, quota servers that are configured with the eggsn option on the ip csg quota-server command). If a quota server that is enabled for eGGSN fails, it does not fail over to the next available quota server.
Examples
The following example reassigns subscribers after a quota server failure:

Related Commands
Command ip csg quota-server
Description Configures CSG2 quota servers.
A-174
OL-22840-05
Appendix A
CSG2 Command Reference ip csg quota-server retransmit
ip csg quota-server retransmit

To define the quota server retransmit time interval for the CSG2, use the ip csg quota-server retransmit command in global configuration mode. To reset the quota server retransmit timer to the default value, use the no form of this command. ip csg quota-server retransmit number-of-seconds no ip csg quota-server retransmit
Syntax Description
number-of-seconds
Time, in seconds, between quota server retransmits. The range is from 1 to 65535. The default value is 4.
Command Default
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
Examples
The following example shows how to specify a quota server retransmit time of 2 seconds:
ip csg quota-server retransmit 2
Related Commands
Command ip csg bma retransmit ip csg ipc retransmit ip csg psd retransmit ip csg quota-server
Description Defines the Billing Mediation Agent (BMA) retransmit time interval for the CSG2. Defines the Interprocessor Communication (IPC) retransmit time interval for the CSG2. Defines the Cisco Persistent Storage Device (PSD) retransmit time interval for the CSG2. Configures CSG2 quota servers.
A-175
Appendix A ip csg quota-server retries

To define the maximum number of quota server retries allowed before the CSG2 determines that the link has failed, use the ip csg quota-server retries command in global configuration mode. To reset the number of quota server retries to the default value, use the no form of this command. ip csg quota-server retries [packet] number-of-retries no ip csg quota-server retries
Syntax Description
(Optional) Attempt to send a packet to the quota server the specified number of times, then discard the packet. Maximum number of quota server retries allowed by the CSG2. The range is from 1 to 65535. The default value is 3.
Command Default
Command Modes
Command History
Release 12.4(11)MD 12.4(15)MD
Usage Guidelines
We recommend that you change the number of retries allowed only when directed to do so by Cisco Technical Assistance Center (TAC) engineers. In most environments, the default value is the most appropriate setting. By default, the CSG2 retries a packet forever; it never discards a packet. If you configure the ip csg quota-server retries packet command, the CSG2 tries to send a packet to the quota server the specified number of times, then discards the packet. (The first attempt to send a packet to the quota server is not counted as a retry.) For example, if you configure ip csg quota-server retries packet 4, the CSG2 tries to send a packet to the quota server five times before discarding it (the initial attempt plus four retries).
Examples
The following example shows how to allow two quota server retries:
ip csg quota-server retries 2
The following example shows how to allow the CSG2 to try to send a packet to the quota server four times, in addition to the initial attempt:
ip csg quota-server retries packet 4
A-176
OL-22840-05
Appendix A
CSG2 Command Reference ip csg quota-server retries
Related Commands
Command ip csg bma retries ip csg ipc retries
Description Defines the maximum number of Billing Mediation Agent (BMA) retries allowed before the CSG2 determines that the link has failed. Defines the maximum number of Interprocessor Communication (IPC) retries allowed before the CSG2 determines that the link has failed. Defines the maximum number of Cisco Persistent Storage Device (PSD) retries allowed before the CSG2 determines that the link has failed. Configures CSG2 quota servers.
ip csg psd retries
ip csg quota-server
A-177
Appendix A ip csg quota-server user-profile
ip csg quota-server user-profile

To enable the CSG2 to send user profile requests to quota servers, use the ip csg quota-server user-profile command in global configuration mode. To restore the default setting, use the no form of this command. ip csg quota-server user-profile no ip csg quota-server user-profile
Syntax Description
Command Default
The CSG2 sends user profile requests to quota servers as needed.
Command Modes
Command History
Release 12.4(22)MD
Examples
The following example shows how to prevent the CSG2 from sending user profile requests to quota servers:
no ip csg quota-server user-profile
Related Commands
Command ip csg entries user profile
Description Specifies the location from which the CSG2 is to obtain the subscriber profile and billing plan when generating entries for the CSG2 User Table.
A-178
OL-22840-05
Appendix A
CSG2 Command Reference ip csg quota-server window
ip csg quota-server window

To define the quota server transmit window size for the CSG2, use the ip csg quota-server window command in global configuration mode. To reset the quota server transmit window size to the default value, use the no form of this command. ip csg quota-server window {max window-size | min window-size | min auto} no ip csg quota-server window {max | min}
Syntax Description
Maximum size, in packets, of the quota server transmit window. The range is from 1 to 65535. The default value is 128. Minimum size, in packets, of the quota server transmit window. The range is from 1 to 65535. Specifies that the CSG2 is to determine the minimum size of the quota server transmit window automatically. The CSG2 keeps track of the maximum number of ACKs received in one response and sets that number as the minimum window.
Command Default
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
Examples
The following example shows how to set the maximum quota server transmit window to 64 packets:
ip csg quota-server window max 64
Related Commands
Command ip csg bma window ip csg psd window ip csg quota-server
Description Defines the Billing Mediation Agent (BMA) transmit window size for the CSG2. Defines the Cisco Persistent Storage Device (PSD) transmit window size for the CSG2. Configures CSG2 quota servers.
A-179
Appendix A ip csg radius ack error parse
ip csg radius ack error parse

To enable the CSG2 to generate a RADIUS response to a RADIUS Accounting Start Request or a RADIUS Accounting Interim Request when it encounters a RADIUS parse error condition, use the ip csg radius ack error parse command in global configuration mode. To prevent RADIUS responses to errors, use the no form of this command. ip csg radius ack error parse no ip csg radius ack error parse
Syntax Description
Command Default
The CSG2 does not generate a RADIUS response to a RADIUS Accounting Start Request or a RADIUS Accounting Interim Request when it encounters a RADIUS parse error condition.
Command Modes
Command History
Release 12.4(11)MD

The radius ack error command split into two new commandsip csg radius ack error parse and ip csg radius ack error user. The configuration mode for this command changed from CSG user group configuration to global configuration.
Usage Guidelines
Use the no form of this command, no ip csg radius ack error parse, to prevent the CSG2 from acknowledging the following RADIUS parse errors:

Invalid RADIUS message or attribute length RADIUS Authenticator does not match what the CSG2 calculates Incorrect RADIUS attribute length User profile information such as billing plan or quota server does not match the CSG2 configuration
Examples
The following example shows how to prevent RADIUS responses when RADIUS parse errors are encountered.
no ip csg radius ack error parse
A-180
OL-22840-05
Appendix A
CSG2 Command Reference ip csg radius ack error parse
Related Commands
Command ip csg radius ack error user
Description Enables the CSG2 to generate a RADIUS response to a RADIUS Accounting Start Request or a RADIUS Accounting Interim Request when it encounters a user resource error condition. Identifies the CSG2 as an endpoint for RADIUS Accounting messages. Configures RADIUS handoff support. Specifies that the CSG2 is to be a proxy for RADIUS messages. Deletes an existing CSG2 User Table entry for a specific subscriber, and creates a new entry for that subscriber. Specifies the attribute that must be included in the RADIUS Accounting Stop request in order for the CSG2 User Table entry to be deleted.
ip csg radius endpoint ip csg radius handoff ip csg radius proxy ip csg radius start restart session-id ip csg radius stop purge
A-181
Appendix A ip csg radius ack error user
ip csg radius ack error user

To enable the CSG2 to generate a RADIUS response to a RADIUS Accounting Start Request or a RADIUS Accounting Interim Request when it encounters a user resource error condition, use the ip csg radius ack error user command in global configuration mode. To prevent RADIUS responses to errors, use the no form of this command. ip csg radius ack error user no ip csg radius ack error user
Syntax Description
Command Default
The CSG2 does not generate a RADIUS response to a RADIUS Accounting Start Request or a RADIUS Accounting Interim Request when it encounters a user resource error condition.
Command Modes
Command History
Release 12.4(11)MD

The radius ack error command split into two new commandsip csg radius ack error parse and ip csg radius ack error user. The configuration mode for this command changed from CSG user group configuration to global configuration.
Usage Guidelines
Use the no form of this command, no ip csg radius ack error user, to prevent the CSG2 from acknowledging the following user resource errors:

Maximum number of users reached Unable to allocate memory for creating a user entry or for storing RADIUS attribute information (such as report attributes or parsed billing plan information) Unable to communicate user information via inter-processor communication Load manager prevents allocation of a user
Examples
The following example shows how to prevent RADIUS responses when user resource errors are encountered.
no ip csg radius ack error user
A-182
OL-22840-05
Appendix A
CSG2 Command Reference ip csg radius ack error user
Related Commands
Command ip csg radius ack error parse
Description Enables the CSG2 to generate a RADIUS response to a RADIUS Accounting Start Request or a RADIUS Accounting Interim Request when it encounters a RADIUS parse error condition. Identifies the CSG2 as an endpoint for RADIUS Accounting messages. Configures RADIUS handoff support. Specifies that the CSG2 is to be a proxy for RADIUS messages. Deletes an existing CSG2 User Table entry for a specific subscriber, and creates a new entry for that subscriber. Specifies the attribute that must be included in the RADIUS Accounting Stop request in order for the CSG2 User Table entry to be deleted.
ip csg radius endpoint ip csg radius handoff ip csg radius proxy ip csg radius start restart session-id ip csg radius stop purge
A-183
Appendix A ip csg radius attribute
ip csg radius attribute

To specify a name for a RADIUS attribute or VSA subattribute that is to be used in subsequent CSG2 configuration commands, use the ip csg radius attribute command in global configuration mode. To delete the name, use the no form of this command. ip csg radius attribute-name attribute {radius-attribute-number | vsa {vendor-id | 3gpp} radius-subattribute-number} no ip csg radius attribute-name attribute {radius-attribute-number | vsa {vendor-id | 3gpp} radius-subattribute-number}
Syntax Description
attribute-name
Name that the CSG2 is to use for the RADIUS attribute or VSA subattribute. The name can be from 1 to 15 characters long, and can include uppercase or lowercase letters (the CSG2 changes all letters to uppercase), numbers, and any special characters. RADIUS attribute number to be associated with the name. The range is from 1 to 255. Specifies the vendor-specific attribute (VSA). Specifies the vendor ID number. The range is from 1 to 16777215. Specifies the Third Generation Partnership Project (3GPP) vendor ID. Specifies the RADIUS subattribute number. The range is from 1 to 255.
radius-attribute-number vsa vendor-id 3gpp radius-subattribute-number
Command Default
No RADIUS attribute or VSA subattribute is named.
Command Modes
Command History
Release 12.4(24)MD
Usage Guidelines
Use this command to associate a name with a RADIUS attribute or VSA subattribute. The name can then be used in subsequent CSG2 configuration commands (for example, in CSG2 user classes as a criterion when making next-hop routing decisions). You can use more than one ip csg radius attribute command to specify up to 1000 names for RADIUS attributes or VSA subattributes. You cannot use the no form of this command to delete a name if the name is currently in use in your configuration.
Examples
The following example shows how to specify the name RAT for VSA subattribute 3gpp 21:
ip csg radius RAT attribute vsa 3gpp 21
A-184
OL-22840-05
Appendix A
CSG2 Command Reference ip csg radius attribute
Related Commands
Command ip csg report radius attribute
Description Specifies the number of times to retry the RADIUS CoA message if it is not acknowledged by means of an ACK message, and the interval between retransmissions. Defines a user class to be used by the CSG2 when making routing decisions, and enters CSG2 user class configuration mode. Specifies a user class match value for a RADIUS attribute or VSA subattribute.
ip csg user class radius (CSG2 user class)
A-185
Appendix A ip csg radius binary attribute
ip csg radius binary attribute

To indicate that a RADIUS attribute or vendor-specific attribute (VSA) subattribute is in binary format, use the ip csg radius binary attribute command in global configuration mode. To remove the binary indication, use the no form of this command. ip csg radius binary attribute {radius-attribute-number | vsa {vendor-id | 3gpp} radius-subattribute-number} no ip csg radius binary attribute
Syntax Description
RADIUS attribute number. The range is from 1 to 255. VSA. Vendor ID number. The range is from 1 to 16777215. Third Generation Partnership Project (3GPP) vendor ID. Subattribute number. The range is from 1 to 255.
Command Default
CSG2 assumes that all the RADIUS attributes and VSA subattributes are in human-readable format.
Command Modes
Command History
Release 12.4(24)MD
Usage Guidelines
By default, CSG2 assumes that all RADIUS attributes and VSA subattributes are in human-readable format. However, you can use this command to indicate that a specific RADIUS attribute or VSA subattribute is in binary format. You can indicate that up to 256 binary RADIUS attributes or VSA subattributes are in binary format. This command is optional for a CSG2 header.
Examples
The following example shows how to indicate that RADIUS attribute 234 is in binary format:
ip csg radius binary attribute 234
A-186
OL-22840-05
Appendix A
CSG2 Command Reference ip csg radius binary attribute
Related Commands
Description Enables CSG2 to generate a RADIUS response to a RADIUS Accounting Start Request or a RADIUS Accounting Interim Request when it encounters a RADIUS parse error condition. Enables CSG2 to generate a RADIUS response to a RADIUS Accounting Start Request or a RADIUS Accounting Interim Request when it encounters a user resource error condition. Configures RADIUS handoff support. Deletes an existing CSG2 User Table entry for a specific subscriber, and creates a new entry for that subscriber. Specifies the attribute that must be included in the RADIUS Accounting Stop request in order for the CSG2 User Table entry to be deleted. Specifies the RADIUS attribute or vendor-specific attribute (VSA) subattribute to be used to extract the user ID from a RADIUS record. Specifies a RADIUS attribute or vendor-specific attribute (VSA) subattribute, and indicates where it is to be inserted into a CSG2 header,.
ip csg radius handoff ip csg radius start restart session-id ip csg radius stop purge
ip csg radius userid
radius (CSG2 header)
A-187
Appendix A ip csg radius coa nas
ip csg radius coa nas

To specify the Network Access Server (NAS) port to which the CSG2 is to send the Change of Authorization (CoA) message, and to specify the key to use in calculating the Authenticator, use the ip csg radius coa nas command in global configuration mode. To restore the default settings, use the no form of this command. ip csg radius coa nas [vrf vrf-name] [start-ip end-ip] port key [encrypt] secret-string no ip csg radius coa nas [vrf vrf-name] [start-ip end-ip] port key [encrypt] secret-string
Syntax Description
vrf vrf-name
(Optional) Virtual Routing and Forwarding (VRF) table which the CSG2 is to use for RADIUS communication.
Note
start-ip end-ip port key encrypt
(Optional) Specifies the first NAS IP address in a range of addresses. (Optional) Specifies the last NAS IP address in a range of addresses. Specifies the NAS port number to which the CoA message is sent. Specifies a RADIUS key. (Optional) Indicates how the secret-string is represented when the configuration is displayed (for example, show run), or how it is written to nonvolatile memory (for example, write memory). The possible values are 0 and 7:
Note
0The secret-string is stored in plain text. This is the default setting. 7The secret-string is encrypted before it is displayed or written to nonvolatile memory. If your router is configured to encrypt all passwords, then the password is represented as 7 followed by the encrypted text. See the Cisco IOS service command for more details.
secret-string
1- to 64-character clear password value for MD5 authentication. All characters are valid; case is significant. The secret-string is always sent in plain text to the CSG2 module when the configuration is downloaded. The secret-string must match the secret that is specified on the RADIUS client (for example, the gateway general packet radio service [GPRS] support node [GGSN]).
Command Default
The secret-string is stored in plain text. If no VRF table is specified, the CSG2 uses the global routing table for RADIUS communication.
Command Modes
A-188
OL-22840-05
Appendix A
CSG2 Command Reference ip csg radius coa nas
Command History
Release 12.4(22)MDA
Usage Guidelines
The CoA message is sent to the NAS IP address that is specified in the NAS-IP-Address attribute (4) in the RADIUS Accounting Start message. This command specifies the NAS listening port, as well as the key to use in calculating the Authenticator. The RADIUS Accounting Start message which specifies the NAS IP address to which to send the CoA message must be received on an IP address specified by the ip csg radius proxy or ip csg radius endpoint command configured in global configuration mode. In some networks, many NASes might use the same listening port and key. In such networks, you can use this command to specify the range of NAS IP addresses. If no IP addresses are specified, the port number and key apply to all NASes. The global definition is used if a specific range is not configured for the NAS when the CoA message is sent.
Examples
The following example shows how to specify NAS ports and keys:
ip csg radius coa nas 1.1.1.0 1.1.1.255 1700 key secret ip csg radius coa nas 1701 key password
Related Commands
Command ip csg radius coa timeout
Description Specifies the number of times to retry the RADIUS CoA message if it is not acknowledged by means of an ACK message, and the interval between retransmissions.
A-189
Appendix A ip csg radius coa timeout
ip csg radius coa timeout

To specify the number of times to retry the RADIUS Change of Authorization (CoA) message if it is not acknowledged by means of an ACK message, and the interval between retransmissions, use the ip csg radius coa timeout command in global configuration mode. To restore the default timeout, use the no form of this command. ip csg radius coa timeout timeout retransmit retransmit no ip csg radius coa timeout timeout retransmit retransmit
Syntax Description
timeout retransmit retransmit
Number of seconds to wait for an ACK or NAK before sending another CoA message. The range is from 1 to 1000. The default timeout is 5 seconds. Number of times to retransmit the message. The range is from 1 to 100. The default setting is 3 retransmits.
Command Default
The default timeout is 5 seconds. The default number of retransmits is 3 retransmits.
Command Modes
Command History
Release 12.4(22)MDA
Examples
The following example shows how to specify a RADIUS CoA timeout and the number of times to retransmit the message:
ip csg radius coa timeout 30 retransmit 5
Related Commands
Command ip csg radius coa nas
Description Specifies the NAS port to which the CSG2 is to send the CoA message, and specifies the key to use in calculating the Authenticator.
A-190
OL-22840-05
Appendix A
CSG2 Command Reference ip csg radius correlation
ip csg radius correlation

To enable RADIUS correlation processing by the CSG2, use the ip csg radius correlation command in global configuration mode. To disable RADIUS correlation processing, use the no form of this command. ip csg radius correlation no ip csg radius correlation
Syntax Description
Command Default
The CSG2 does not perform RADIUS correlation processing.
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
A retransmitted RADIUS Stop might cause the CSG2 to remove a subscriber entry from the CSG2 User Table when the entry should not be removed. To avoid this problem, the CSG2 must be able to associate a session correlator from the RADIUS Start message with a subscriber entry in the User Table, and compare that correlator with the correlator in the RADIUS Stop message. If the correlators match, the CSG2 deletes the subscriber entry; otherwise, the CSG2 retains the entry in the User Table. The CSG2 can use the Acct-Session-Id (attribute 44) as the correlator, or it can use the following vendor-specific attribute (VSA) subattribute (attribute 26, Vendor-Id 9, subattribute 1): csg:user_session_correlator=string If both attributes are included in the RADIUS Start or RADIUS Stop message, the CSG2 uses the VSA subattribute. To enable this capability, enter the ip csg radius correlation command.

If there is no correlator saved in the User Table entry, the CSG2 deletes the entry. If there is a correlator saved in the User Table entry, the CSG2 compares it to the correlator in the RADIUS Stop. If the correlators match, the CSG2 deletes the entry; if they do not match, or if there is no correlator in the RADIUS Stop, the CSG2 retains the entry in the User Table.
To disable this capability, enter the no ip csg radius correlation command. The CSG2 deletes User Table entries without subscriber session correlation.
Examples
The following example shows how to enable RADIUS correlation processing by the CSG2.
ip csg radius correlation
A-191
Appendix A ip csg radius correlation
Related Commands
Command ip csg radius handoff ip csg radius start restart session-id ip csg radius stop purge
Description Configures RADIUS handoff support. Deletes an existing CSG2 User Table entry for a specific subscriber, and creates a new entry for that subscriber. Specifies the attribute that must be included in the RADIUS Accounting Stop request in order for the CSG2 User Table entry to be deleted. Replicates the connection state for all connections to the CSG2 content servers on the standby system.
replicate (CSG2 content)
A-192
OL-22840-05
Appendix A
CSG2 Command Reference ip csg radius endpoint
ip csg radius endpoint

To identify the CSG2 as an endpoint for RADIUS Accounting messages, use the ip csg radius endpoint command in global configuration mode. To remove the endpoint identification, use the no form of this command. ip csg radius endpoint [vrf csg-vrf-name] csg-address key [encrypt] secret-string [vrf sub-vrf-name] no ip csg radius endpoint [vrf csg-vrf-name] csg-address
Syntax Description
vrf csg-vrf-name
(Optional) Virtual Routing and Forwarding (VRF) table which the CSG2 IP address is to use for RADIUS communication.
Note
csg-address
Specifies the CSG2 IP address. The CSG2 IP address must be a virtual IP address, and it must be unique (or the IP address-VRF name combination must be unique, if VRF is configured). The CSG2 IP address (or the IP address-VRF name combination) must not be specified in other CSG2 commands, and it must not match any real IP address, virtual IP address, or alias IP address (or IP address-VRF name combination) configured on the CSG2. If you want the CSG2 RADIUS endpoint IP address to be a member of a CSG2 interface subnet, you must configure the CSG2 IP address as follows:
Note
In non-redundant configurations, you must configure the CSG2 IP address as a secondary IP address configured on the appropriate interface. In redundant configurations, you must configure the CSG2 IP address as a standby secondary IP address on the appropriate interface. The CSG2 performs radius endpoint processing only on User Datagram Protocol (UDP) traffic that is destined for the server IP address. The server IP address cannot be used for any other UDP communication with the CSG2.
key encrypt
Specifies a RADIUS key. (Optional) Indicates how the secret-string is represented when the configuration is displayed (for example, show run), or how it is written to nonvolatile memory (for example, write memory). The valid values are:
Note
A-193
Appendix A ip csg radius endpoint
secret-string
vrf sub-vrf-name
(Optional) Virtual Routing and Forwarding (VRF) table which the subscriber is to use for RADIUS communication.
Note
Command Default
The secret-string is stored in plain text. If no VRF table is specified for the CSG2, the CSG2 uses the global routing table for RADIUS communication. If no VRF table is specified for the subscriber, the subscriber uses the global routing table for RADIUS communication.
Command Modes
Command History
Release 12.4(11)MD

The name of this command changed from radius endpoint to ip csg radius endpoint. The configuration mode for this command changed from module CSG configuration to global configuration. The vrf csg-vrf-name and vrf sub-vrf-name keywords and arguments were added. The table table-name keyword and argument were removed.
Usage Guidelines
A RADIUS Accounting message sent to the specified csg-address (and any port) is parsed, and is then acknowledged, by the CSG2. CSG2 User Table entries created as a result of RADIUS messaging through the ip csg radius endpoint definition with a VRF configured are indexed by the configured sub-vrf-name. This enables the CSG2 to segment the subscriber space and removes ambiguity if multiple subscribers share the same IP address, provided that their entries were instantiated by RADIUS flows to CSG2 radius definitions bound to different VRFs. If the sub-vrf-name is not configured, the User Table entries are indexed via the global routing table. To change the RADIUS endpoint csg-vrf-name or sub-vrf-name associated with a given csg-address, you must first enter the no form of the ip csg radius endpoint command for that csg-address, then enter the command with the new csg-vrf-name or sub-vrf-name.
A-194
OL-22840-05
Appendix A
CSG2 Command Reference ip csg radius endpoint
You can specify up to 2048 ip csg radius endpoint commands. You can also configure an optional RADIUS key.

Examples
The following example shows how to identify the CSG2 as a RADIUS endpoint:
ip csg radius endpoint vrf RADIUSVRF 1.2.3.4 key secret vrf SUBVRF
Related Commands
Command ip csg radius monitor nas ip csg radius proxy ip csg radius userid
Description Specifies that the CSG2 is to monitor the RADIUS flows to the specified server. Specifies that the CSG2 is to be a proxy for RADIUS messages. Specifies the RADIUS attribute used to extract the user identifier from a RADIUS record.
A-195
Appendix A ip csg radius handoff
ip csg radius handoff

To configure the CSG2 RADIUS handoff timer, use the ip csg radius handoff command in global configuration mode. To turn off the timer, use the no form of this command. ip csg radius handoff duration no ip csg radius handoff
Syntax Description
duration
Handoff timer duration, in seconds. The handoff timer is started when a RADIUS Accounting Stop is received. If the handoff timer expires before a RADIUS Accounting Start for a subscriber is seen, the CSG2 assumes that a handoff did not occur and deletes the CSG2 User Table entry for the subscriber. The range is from 1 to 43200.
Command Default
RADIUS handoff is disabled.
Command Modes
Command History
Release 12.4(11)MD

The name of this command changed from radius handoff to ip csg radius handoff. The configuration mode for this command changed from CSG user group configuration to global configuration.
Usage Guidelines
The handoff timer is started when a RADIUS Accounting Stop is received. If the handoff timer expires before a RADIUS Accounting Start is received for a subscriber, the CSG2 assumes a handoff did not occur and deletes the CSG2 User Table entry for the subscriber.
Examples
The following example shows how to specify a RADIUS handoff timer duration of 1000 seconds:
ip csg radius handoff 1000
A-196
OL-22840-05
Appendix A
CSG2 Command Reference ip csg radius handoff
Related Commands
Description Enables the CSG2 to generate a RADIUS response to a RADIUS Accounting Start Request or a RADIUS Accounting Interim Request when it encounters a RADIUS parse error condition. Enables the CSG2 to generate a RADIUS response to a RADIUS Accounting Start Request or a RADIUS Accounting Interim Request when it encounters a user resource error condition. Specifies that the CSG2 is to be a proxy for RADIUS messages. Deletes an existing CSG2 User Table entry for a specific subscriber, and creates a new entry for that subscriber. Specifies the attribute that must be included in the RADIUS Accounting Stop request in order for the CSG2 User Table entry to be deleted.
ip csg radius proxy ip csg radius start restart session-id ip csg radius stop purge
A-197
Appendix A ip csg radius monitor
ip csg radius monitor

To specify that the CSG2 is to monitor the RADIUS flows to the specified server, use the ip csg radius monitor command in global configuration mode. To stop monitoring the RADIUS flows, use the no form of this command. ip csg radius monitor [vrf vrf-name] server-address server-port [key [encrypt] secret-string] [vrf sub-vrf-name] no ip csg radius monitor [vrf vrf-name] server-address server-port
Syntax Description
vrf csg-vrf-name
Note
server-address server-port key encrypt
Specifies the server address to monitor. Specifies the server port to monitor. (Optional) Specifies a RADIUS key. (Optional) Indicates how the secret-string is represented when the configuration is displayed (for example, show run), or how it is written to nonvolatile memory (for example, write memory). The valid values are:
Note
secret-string
(Optional) 1- to 64-character clear password value for MD5 authentication. All characters are valid; case is significant. The secret-string is always sent in plain text to the CSG2 module when the configuration is downloaded. The secret-string must match the secret that is specified on the RADIUS client (for example, the gateway general packet radio service [GPRS] support node [GGSN]).
vrf sub-vrf-name
Note
Command Default
The secret-string is stored in plain text. If no VRF table is specified for the CSG2, the CSG2 uses the global routing table for RADIUS communication. If no VRF table is specified for the subscriber, the subscriber uses the global routing table for RADIUS communication.
A-198
OL-22840-05
Appendix A
CSG2 Command Reference ip csg radius monitor
Command Modes
Command History
Release 12.4(15)MD
Usage Guidelines
You can configure an optional RADIUS key.

If you configure a RADIUS key, the CSG2 parses and acts on a message only if the RADIUS Authenticator is correct. If you do not configure a RADIUS key, the CSG2 always parses and forwards every message. Even if you configure a key, the CSG2 forwards all RADIUS messages (including Access messages), regardless of the configuration or accuracy of the key, unless the IP or UDP headers specify a length larger than the physical packet size.
Examples
The following example shows how to use the ip csg radius monitor command to enable the CSG2 to monitor the RADIUS flows:
ip csg radius monitor 1.2.3.4 1813 key KEY_TABLE
Related Commands
Command ip csg radius endpoint ip csg radius monitor nas ip csg radius proxy
Description Identifies the CSG2 as an endpoint for RADIUS Accounting messages. Specifies that the CSG2 is to monitor the RADIUS flows to the specified Network Access Server (NAS). Specifies that the CSG2 is to be a proxy for RADIUS messages.
A-199
Appendix A ip csg radius monitor nas
ip csg radius monitor nas

To specify that the CSG2 is to monitor the RADIUS flows to the specified Network Access Server (NAS), use the ip csg radius monitor nas command in global configuration mode. To stop monitoring the RADIUS flows, use the no form of this command. ip csg radius monitor nas nas-ipv4-address [vrf nas-vrf-name] no ip csg radius monitor nas nas-ipv4-address [vrf nas-vrf-name]
Syntax Description
nas-ipv4-address
Specifies the NAS IPv4 address to monitor.

Note
The CSG2 performs radius monitor processing only on User Datagram Protocol (UDP) traffic that is destined for the NAS IPv4 address. The NAS IPv4 address cannot be used for any other UDP communication with the CSG2.
vrf nas-vrf-name
(Optional) Virtual Routing and Forwarding (VRF) table which the NAS IPv4 address is to use for RADIUS communication.
Note
Command Default
If no VRF table is specified for the NAS, the CSG2 uses the global routing table for RADIUS communication.
Command Modes
Command History
Release 12.4(15)MD
Usage Guidelines
This command is required whenever a RADIUS monitor is configured. Use this command to identify each NAS that is to communicate with the RADIUS monitor server. Each interface on which a NAS server resides must be marked as a subscriber interface.
Examples
The following example shows how to use the ip csg radius monitor nas command to enable the CSG2 to monitor the RADIUS flows:
ip csg radius monitor nas 1.2.3.4 vrf NAS_TABLE
A-200
OL-22840-05
Appendix A
CSG2 Command Reference ip csg radius monitor nas
Related Commands
Command ip csg radius monitor ip csg radius proxy
Description Specifies that the CSG2 is to monitor the RADIUS flows to the specified server. Specifies that the CSG2 is to be a proxy for RADIUS messages.
ip csg radius endpoint Identifies the CSG2 as an endpoint for RADIUS Accounting messages.
A-201
Appendix A ip csg radius on-off purge
ip csg radius on-off purge

To specify the rate at which the CSG2 is to delete CSG2 User Table entries in response to a RADIUS Accounting On or RADIUS Accounting Off message, or in response to the clear ip csg user all command, use the ip csg radius on-off purge command in global configuration mode. To restore the default setting, use the no form of this command. ip csg radius on-off purge deletions-per-second no ip csg radius on-off purge
Syntax Description
deletions-per-second
Number of User Table entry deletions per second. The range is from 50 to 65535. The default rate is 1000.
Command Default
The default rate is 1000 User Table entry deletions per second.
Command Modes
Command History
Release 12.4(15)MD
Usage Guidelines
The actual rate at which the CSG2 deletes User Table entries might be slightly higher or lower than the specified rate.
Examples
The following example shows how to specify a User Table deletion rate of 875 entries per second:
ip csg radius on-off purge 875
A-202
OL-22840-05
Appendix A
CSG2 Command Reference ip csg radius pod attribute
ip csg radius pod attribute

To specify the RADIUS attributes and vendor-specific attribute (VSA) subattributes to be copied from the RADIUS Start message and sent to the Network Access Server (NAS) in the Packet of Disconnect (PoD) message, use the ip csg radius pod attribute command in global configuration mode. To disable this feature, use the no form of this command. ip csg radius pod attribute {radius-attribute-number | vsa {vendor-id | 3gpp} radius-subattribute-number} no ip csg radius pod attribute {radius-attribute-number | vsa {vendor-id | 3gpp} radius-subattribute-number}
Syntax Description
radius-attribute-number
RADIUS attribute number to be copied from the RADIUS Start message and sent to the Network Access Server (NAS) in the Packet of Disconnect (PoD) message. The range is from 1 to 255. Specifies the VSA. Specifies the vendor ID number. The range is from 1 to 16777215. Specifies the Third Generation Partnership Project (3GPP) vendor ID. Specifies the subattribute number. The range is from 1 to 255.
vsa vendor-id 3gpp radius-subattribute-number
Command Default
RADIUS attributes sufficient to identify the NAS and subscriber (RFC3576) are sent in the PoD message.
Command Modes
Command History
Release 12.4(11)MD

The name of this command changed from radius pod attribute to ip csg radius pod attribute. The configuration mode for this command changed from CSG user group configuration to global configuration. The 26 keyword was removed.
Usage Guidelines
You can specify up to 256 RADIUS attributes. If the RADIUS message does not contain an attribute, the PoD message attribute does not contain the attribute, either. The CSG2 saves and reports attribute and subattribute information for each subscriber. When the CSG2 receives a new RADIUS Accounting Start or RADIUS Interim Accounting Request, it saves the attribute and subattribute information parsed from the new request.
A-203
Appendix A ip csg radius pod attribute

All previously stored attribute and subattribute information from previous requests is destroyed, even if the new RADIUS Accounting Start or RADIUS Interim Accounting Request does not contain all of the attributes and subattributes that were present in the previous request. Only the currently stored attributes are reported in CDRs. If there are multiple instances of an attribute, all instances are included. Attributes are included in the PoD message in random order.
Examples
The following example shows how to specify RADIUS attributes 44 and 26:
ip csg radius pod attribute 44 ip csg radius pod attribute 26
Related Commands
Command ip csg radius pod nas ip csg radius pod timeout
Description Specifies the NAS port to which the CSG2 is to send the PoD message, and the key to use in calculating the Authenticator. Specifies the number of times to retry the RADIUS PoD message if it is not acknowledged by means of an ACK message, and the interval between retransmissions.
A-204
OL-22840-05
Appendix A
CSG2 Command Reference ip csg radius pod nas
ip csg radius pod nas

To specify the Network Access Server (NAS) port to which the CSG2 is to send the Packet of Disconnect (PoD) message, and to specify the key to use in calculating the Authenticator, use the ip csg radius pod nas command in global configuration mode. To restore the default settings, use the no form of this command. ip csg radius pod nas [vrf vrf-name] [start-ip end-ip] port key [encrypt] secret-string no ip csg radius pod nas [vrf vrf-name] [start-ip end-ip] port key [encrypt] secret-string
Syntax Description
vrf vrf-name
(Optional) Virtual Routing and Forwarding (VRF) table which the CSG2 is to use for RADIUS communication.
Note
start-ip end-ip port key encrypt
(Optional) Specifies the first NAS IP address in a range of addresses. (Optional) Specifies the last NAS IP address in a range of addresses. Specifies the NAS port number to which the PoD message is sent. Specifies a RADIUS key. (Optional) Indicates how the secret-string is represented when the configuration is displayed (for example, show run), or how it is written to nonvolatile memory (for example, write memory). The possible values are 0 and 7:
Note
secret-string
Command Default
The secret-string is stored in plain text. If no VRF table is specified, the CSG2 uses the global routing table for RADIUS communication.
Command Modes
A-205
Appendix A ip csg radius pod nas
Command History
Release 12.4(11)MD

The name of this command changed from radius pod nas to ip csg radius pod nas. The configuration mode for this command changed from CSG user group configuration to global configuration. The vrf vrf-name keyword and argument were added.
Usage Guidelines
The PoD message is sent to the NAS IP address that is specified in the NAS-IP-Address attribute (4) in the RADIUS Accounting Start message. This command specifies the NAS listening port, as well as the key to use in calculating the Authenticator. The RADIUS Accounting Start message which specifies the NAS IP address to which to send the PoD message must be received on an IP address specified by the ip csg radius proxy or ip csg radius endpoint command configured in global configuration mode. In some networks, many NASes might use the same listening port and key. In such networks, you can use this command to specify the range of NAS IP addresses. If no IP addresses are specified, the port number and key apply to all NASes. The global definition is used if a specific range is not configured for the NAS when the PoD message is sent.
Examples
The following example shows how to specify NAS ports and keys:
ip csg radius pod nas 1.1.1.0 1.1.1.255 1700 key secret ip csg radius pod nas 1701 key password
Related Commands
Command ip csg radius pod attribute ip csg radius pod timeout
Description Specifies the RADIUS attributes to be copied from the RADIUS Start message and sent to the NAS in the PoD. Specifies the number of times to retry the RADIUS PoD message if it is not acknowledged by means of an ACK message, and the interval between retransmissions.
A-206
OL-22840-05
Appendix A
CSG2 Command Reference ip csg radius pod timeout
ip csg radius pod timeout

To specify the number of times to retry the RADIUS Packet of Disconnect (PoD) message if it is not acknowledged by means of an ACK message, and the interval between retransmissions, use the ip csg radius pod timeout command in global configuration mode. To restore the default timeout, use the no form of this command. ip csg radius pod timeout timeout retransmit retransmit no ip csg radius pod timeout timeout retransmit retransmit
Syntax Description
timeout retransmit retransmit
Number of seconds to wait for an ACK or NAK before sending another PoD message. The range is from 1 to 1000. The default timeout is 5 seconds. Number of times to retransmit the message. The range is from 1 to 100. The default setting is 3 retransmits.
Command Default
The default timeout is 5 seconds. The default number of retransmits is 3 retransmits.
Command Modes
Command History
Release 12.4(11)MD

The name of this command changed from radius pod timeout to ip csg radius pod timeout. The configuration mode for this command changed from CSG user group configuration to global configuration.
Examples
The following example shows how to specify a RADIUS PoD timeout and the number of times to retransmit the message:
ip csg radius pod timeout 30 retransmit 5
Related Commands
Command ip csg radius pod attribute ip csg radius pod nas
Description Specifies the RADIUS attributes to be copied from the RADIUS Start message and sent to the NAS in the PoD. Specifies the NAS port to which the CSG2 is to send the PoD message, and specifies the key to use in calculating the Authenticator.
A-207
Appendix A ip csg radius proxy
ip csg radius proxy

To specify that the CSG2 is to be a proxy for RADIUS messages, use the ip csg radius proxy command in global configuration mode. To stop the CSG2 from proxying for RADIUS messages, use the no form of this command. ip csg radius proxy [vrf csg-vrf-name] csg-address [vrf server-vrf-name] server-address csg-source-address [key [encrypt] secret-string] [vrf sub-vrf-name] no ip csg radius proxy [vrf csg-vrf-name] csg-address server-address
Syntax Description
vrf csg-vrf-name
Note
csg-address
Specifies the CSG2 IP address. The CSG2 IP address must be a virtual IP address, and it must be unique (or the IP address-VRF name combination must be unique, if VRF is configured). The CSG2 IP address (or the IP address-VRF name combination) must not be specified in other CSG2 commands, and it must not match any real IP address, virtual IP address, or alias IP address (or IP address-VRF name combination) configured on the CSG2. If you want the CSG2 RADIUS proxy IP address to be a member of a CSG2 interface subnet, you must configure the CSG2 IP address as follows:
Note
In non-redundant configurations, you must configure the CSG2 IP address as a secondary IP address configured on the appropriate interface. In redundant configurations, you must configure the CSG2 IP address as a standby secondary IP address on the appropriate interface. The CSG2 performs radius proxy processing only on User Datagram Protocol (UDP) traffic that is destined for the server IP address. The server IP address cannot be used for any other UDP communication with the CSG2.
vrf server-vrf-name
(Optional) Virtual Routing and Forwarding (VRF) table which the server IP address is to use for RADIUS communication.
Note
server-address
Specifies the server IP address.
A-208
OL-22840-05
Appendix A
CSG2 Command Reference ip csg radius proxy
csg-source-address
Specifies the source IP address that the CSG2 is to use when sending packets to the RADIUS server. The CSG2 source IP address must be unique (or the IP address-VRF name combination must be unique, if VRF is configured). If you want the CSG2 RADIUS proxy IP address to be a member of a CSG2 interface subnet, you must configure the CSG2 source IP address as follows:
Note
In non-redundant configurations, you must configure the CSG2 source IP address as a secondary IP address configured on the appropriate interface. In redundant configurations, you must configure the CSG2 source IP address as a standby secondary IP address on the appropriate interface. The CSG2 performs radius proxy processing only on User Datagram Protocol (UDP) traffic that is destined for the csg-source-address. The csg-source-address cannot be used for any other UDP communication with the CSG2. Specify no more than one key for each CSG2 IP address.
key encrypt
(Optional) Specifies a RADIUS key.

Note
(Optional) Indicates how the secret-string is represented when the configuration is displayed (for example, show run), or how it is written to nonvolatile memory (for example, write memory). The possible values are 0 and 7:
Note
secret-string
(Optional) 1- to 64-character clear password value for MD5 authentication. All characters are valid; case is significant. The secret-string is always sent in plain text to the CSG2 module when the configuration is downloaded. The secret-string must match the secret that is specified on the RADIUS client (for example, the gateway general packet radio service [GPRS] support node [GGSN]).
vrf sub-vrf-name
Note
Command Default
The secret-string is stored in plain text. The csg-source-address is set to csg-address. If no VRF table is specified for the CSG2, the CSG2 uses the global routing table for RADIUS communication. If no VRF table is specified for the RADIUS server, the RADIUS server uses the global routing table for
A-209
Appendix A ip csg radius proxy
RADIUS communication. If no VRF table is specified for the subscriber, the subscriber uses the global routing table for RADIUS communication.
Command Modes
Command History
Release 12.4(11)MD

The name of this command changed from radius proxy to ip csg radius proxy. The configuration mode for this command changed from module CSG configuration to global configuration. The vrf csg-vrf-name, vrf server-vrf-name, and vrf sub-vrf-name keywords and arguments were added. The table table-name keyword and argument were removed.
Usage Guidelines
A message sent to the specified csg-address (and any port) is parsed and then forwarded to the specified RADIUS server. When forwarded to the RADIUS server, the source IP address is the csg-source-address. The source port is arbitrarily chosen by the CSG2, and the destination port remains unchanged. When a message is received from the network and forwarded to the subscriber, the source IP address is the csg-address, and the source port remains unchanged. The source IP address and port are taken from the destination IP address and port in the original message from the subscriber. You can configure an optional RADIUS key. If you configure a key, the CSG2 parses and acts on the message only if the RADIUS authenticator is correct. If the key is not configured, the CSG2 always parses the message. Whether you configure a key or not, and whether it is correct or not, the CSG2 always forwards the message. You can specify up to 1024 ip csg radius proxy commands. You can also configure an optional RADIUS key.

You can specify more than one RADIUS key by specifying more than one ip csg radius proxy command, but each command must specify a unique CSG2 IP address (or IP address-VRF name combination, if VRF is configured). All RADIUS messages are forwarded, unless the IP or User Datagram Protocol (UDP) headers specify a length larger than the physical packet size. CSG2 User Table entries created as a result of RADIUS messaging through the ip csg radius endpoint definition with a VRF configured are indexed by the configured sub-vrf-name. This enables the CSG2 to segment the subscriber space and removes ambiguity if multiple subscribers share the same IP
A-210
OL-22840-05
Appendix A
CSG2 Command Reference ip csg radius proxy
address, provided that their entries were instantiated by RADIUS flows to CSG2 radius definitions bound to different VRFs. If the sub-vrf-name is not configured, the User Table entries are indexed via the global routing table.
Note
If your network is designed to check the authorization string in RADIUS messages, we recommend that you enter a secret-string. Additionally, if you configure the ip csg entries user profile radius remove command, you might need to configure a secret-string. To change the RADIUS proxy csg-vrf-name, server-vrf-name, or sub-vrf-name associated with a given csg-address, you must first enter the no form of the ip csg radius endpoint command for that csg-address, then enter the command with the new csg-vrf-name, server-vrf-name, or sub-vrf-name.
Examples
The following example illustrates how to create a RADIUS proxy point:

ip csg radius proxy vrf RADIUSVRF 1.2.3.4 vrf SERVERVRF 5.6.7.8 1.2.3.4 key secret vrf SUBVRF
Related Commands
Command ip csg radius monitor nas ip csg radius proxy timeout ip csg radius userid
Description Specifies that the CSG2 is to monitor the RADIUS flows to the specified server. Specifies the interval that the CSG2 must wait before assigning a depleted RADIUS proxy port to a new RADIUS client. Specifies the RADIUS attribute used to extract the user identifier from a RADIUS record.
ip csg radius endpoint Identifies the CSG2 as an endpoint for RADIUS Accounting messages.
A-211
Appendix A ip csg radius proxy timeout
ip csg radius proxy timeout

To specify the interval that the CSG2 must wait before assigning a depleted RADIUS proxy port to a new RADIUS client, use the ip csg radius proxy timeout command in global configuration mode. To restore the default timeout, use the no form of this command. ip csg radius proxy timeout timeout no ip csg radius proxy timeout timeout
Syntax Description
timeout
Number of seconds that the CSG2 is to wait. The range is from 1 to 65535. The default timeout is 30 seconds.
Command Default
The default timeout is 30 seconds.
Command Modes
Command History
Release
Modification
12.4(22)MDA4 This command was introduced.
Usage Guidelines
If the CSG2 runs out of RADIUS proxy ports, it might begin dropping RADIUS requests from clients. To avoid this problem, the CSG2 reuses depleted RADIUS proxy ports. By default, the CSG2 can reassign a depleted RADIUS proxy port after 30 seconds. To set a different timeout, use this command.
Examples
The following example shows how to specify a RADIUS proxy timeout of 60 seconds:
ip csg radius proxy timeout 60
Related Commands
Command ip csg radius proxy
Description Specifies that the CSG2 is to be a proxy for RADIUS messages.
A-212
OL-22840-05
Appendix A
CSG2 Command Reference ip csg radius reauthorization attribute
ip csg radius reauthorization attribute

To define the RADIUS attributes and VSA subattributes to be monitored by the CSG2, and to enable Roaming Service Control, use the ip csg radius reauthorization attribute command in global configuration mode. To delete a RADIUS attribute, use the no form of this command. ip csg radius reauthorization attribute {radius-attribute-number | vsa {vendor-id | 3gpp} radius-subattribute-number} no ip csg radius reauthorization attribute {radius-attribute-number | vsa {vendor-id | 3gpp} radius-subattribute-number}
Syntax Description
Specifies the RADIUS attribute number. The range is from 1 to 255. Specifies the vendor-specific attribute (VSA). Specifies the vendor ID number. The range is from 1 to 16777215. Specifies the Third Generation Partnership Project (3GPP) vendor ID. Specifies the subattribute number. The range is from 1 to 255.
Command Default
The default behavior is that no RADIUS attribute is defined.
Command Modes
Command History
Release 12.4(15)MD
Usage Guidelines
Roaming Service Control, also known as seamless roaming or RADIUS reauthorization, enables the CSG2 to reauthorize prepaid users, instead of ending the users sessions, when a configured list of attributes changes. For both prepaid and postpaid subscribers, a change in the contents of the RADIUS reauthorization attributes results in the generation of a CDR to a BMA.
1. 2. 3. 4.
When you enable Roaming Service Control, you also configure a list of RADIUS attributes and VSA subattributes to be monitored and saved by the CSG2. When the CSG2 receives a RADIUS Start message, it saves the subset of attributes that are in both the configured list and the message. When the CSG2 receives a subsequent RADIUS Start or RADIUS Interim Accounting message, it compares the saved subset of attributes, and their contents, to the attributes in the new message. If any attribute in the saved subset is missing from the list of attributes in the new message, or if there are any new attributes in the message that are not in the saved subset, or if any of the contents of the attributes are different, the CSG2 reauthorizes prepaid users without ending their sessions. If service-level CDR summarization is enabled, the CSG2 sends a Service Usage CDR for each service in the session.
5.
A-213
Appendix A ip csg radius reauthorization attribute
Otherwise, if intermediate CDRs are supported for the session, the CSG2 sends an intermediate CDR for each service in the session. However, if you have enabled fixed-format CDRs, the CSG2 does not generate intermediate CDRs during roaming events. The CDR includes:
The Cause TLV, indicating that the CDR was generated due to the receipt of a reauthorization
trigger
The saved subset of attributes from the first RADIUS Start message The list of attributes from the new message
For more information about service-level CDR summarization, see the Enabling Service-Level CDR Summarization section on page 5-9. For more information about intermediate CDRs, see the Intermediate CDRs section on page 1-54. For more information about fixed-format CDRs, see the Configuring Fixed, Variable, or Combined Format CDR Support section on page 2-30.
Examples
The following example illustrates how to create a RADIUS proxy point:

ip csg radius reauthorization attribute 14 ip csg radius reauthorization attribute vsa 7777 44 ip csg radius reauthorization attribute 26 7778 4
Related Commands
Command ip csg radius proxy
Description Specifies that the CSG2 is to be a proxy for RADIUS messages.
A-214
OL-22840-05
Appendix A
CSG2 Command Reference ip csg radius route inject
ip csg radius route inject

To enable the CSG2 to inject routes into the routing table for dynamic IP pools, use the ip csg radius route inject command in global configuration mode. To disable route injection, use the no form of this command. ip csg radius route inject no ip csg radius route inject
Syntax Description
Command Default
Route injection is disabled.
Command Modes
Command History
Release 12.4(24)MD1
Usage Guidelines
This command enables the CSG2 to parse a special Cisco VSA for a network mask and insert the mask and an IP prefix into the routing table. The Open Shortest Path First (OSPF) routing protocol then advertises the route to the Supervisor Engine, which in turn determines the flows to be routed back through the CSG2. The CSG2 receives the routes to be injected from RADIUS Accounting Start or RADIUS Interim Accounting Request messages.
Examples
The following example shows how to enable route injection for the CSG2:
ip csg radius route inject
A-215
Appendix A ip csg radius start restart session-id
ip csg radius start restart session-id

To delete an existing CSG2 User Table entry for a specific subscriber, and to create a new entry for that subscriber, use the ip csg radius start restart session-id command in global configuration mode. ip csg radius start restart session-id {radius-attribute-number | vsa {vendor-id | 3gpp} radius-subattribute-number}
Syntax Description
Command Default
The default behavior is that existing CSG2 User Table entries are not deleted.
Command Modes
Command History
Release 12.4(11)MD

The name of this command changed from radius start restart session-id to ip csg radius start restart session-id. The configuration mode for this command changed from module CSG configuration to global configuration. The 26 keyword was removed.
Usage Guidelines
This command:

Deletes an existing CSG2 User Table entry for a specific subscriber (when a RADIUS Accounting Start or RADIUS Interim Accounting is received). Creates a new entry for that subscriber (similar to when a RADIUS Accounting Stop has been received). Terminates all sessions for that subscriber.
To detect duplicate RADIUS requests (in this situation, the existing entry is not deleted), specify the attribute (which might be a VSA) to be used. If the contents of the specified attribute in the original request match the contents of the attribute in the current request, the request is a duplicate and the existing entry is not deleted.
A-216
OL-22840-05
Appendix A
CSG2 Command Reference ip csg radius start restart session-id
Examples
The following example shows how to enable the ip csg radius start restart session-id command:
ip csg radius start restart session-id 44
Related Commands
Command ip csg radius stop purge
Description Specifies the attribute that must be included in the RADIUS Accounting Stop request in order for the CSG2 User Table entry to be deleted.
A-217
Appendix A ip csg radius stop purge
ip csg radius stop purge

To specify the attribute that must be included in the RADIUS Accounting Stop request in order for the CSG2 User Table entry to be deleted, use the ip csg radius stop purge command in global configuration mode. ip csg radius stop purge {radius-attribute-number | vsa {vendor-id | 3gpp} radius-subattribute-number}
Syntax Description
Command Default
The subscriber entry is deleted when a RADIUS Accounting Stop is received.
Command Modes
Command History
Release 12.4(11)MD

The name of this command changed from radius stop purge to ip csg radius stop purge. The configuration mode for this command changed from module CSG configuration to global configuration. The 26 keyword was removed.
Usage Guidelines
The ip csg radius stop purge command specifies the attribute (which might be a VSA) that must be included in the RADIUS Accounting Stop request in order for the CSG2 User Table entry to be deleted. The contents of the specified attribute are not examined.
Examples
The following example shows how to enable the ip csg radius stop purge command:
ip csg radius stop purge 44
A-218
OL-22840-05
Appendix A
CSG2 Command Reference ip csg radius stop purge
Related Commands
Command ip csg radius start restart session-id
Description Deletes an existing CSG2 User Table entry for a specific subscriber, and creates a new entry for that subscriber.
A-219
Appendix A ip csg radius userid
ip csg radius userid

To specify the RADIUS attribute used to extract the user identifier from a RADIUS record, use the ip csg radius userid command in global configuration mode. To specify that no RADIUS attributes are to be used, use the no form of this command. ip csg radius userid {1 | 31 | User-Name | Calling-Station-Id} no ip csg radius userid
Syntax Description
1 31 User-Name Calling-Station-Id
RADIUS attribute number 1. RADIUS attribute number 31. Equivalent to RADIUS attribute number 1. Equivalent to RADIUS attribute number 31.
Command Default
None
Command Modes
Command History
Release 12.4(11)MD

The name of this command changed from radius userid to ip csg radius userid. The configuration mode for this command changed from module CSG configuration to global configuration.
Usage Guidelines
The ip csg radius userid command specifies that the CSG2 obtains the user ID from either attribute 1 or 31. If the no form of this command, no ip csg radius userid, is used, user IDs are not obtained from RADIUS messages.
Examples
The following example shows how to specify RADIUS attribute User-Name:

ip csg radius userid User-Name
A-220
OL-22840-05
Appendix A
CSG2 Command Reference ip csg radius userid
Related Commands
Description Enables the CSG2 to generate a RADIUS response to a RADIUS Accounting Start Request or a RADIUS Accounting Interim Request when it encounters a RADIUS parse error condition. Enables the CSG2 to generate a RADIUS response to a RADIUS Accounting Start Request or a RADIUS Accounting Interim Request when it encounters a user resource error condition. Configures RADIUS handoff support. Deletes an existing CSG2 User Table entry for a specific subscriber, and creates a new entry for that subscriber. Specifies the attribute that must be included in the RADIUS Accounting Stop request in order for the CSG2 User Table entry to be deleted.
ip csg radius handoff ip csg radius start restart session-id ip csg radius stop purge
A-221
Appendix A ip csg records format
ip csg records format

To specify variable, fixed, or combined (variable-single) call detail record (CDR) format, use the ip csg records format command in global configuration mode. To use the default setting, use the no form of this command. ip csg records format [fixed | variable [combined {http | wap}]] no ip csg records format [fixed | variable [combined {http | wap}]]
Syntax Description
fixed variable combined http combined wap
(Optional) Specifies fixed CDR format. (Optional) Specifies variable CDR format. (Optional) Specifies combined (variable-single) CDR format for HTTP traffic. (Optional) Specifies combined (variable-single) CDR format for wireless application protocol (WAP) traffic.
Command Default
The default setting is variable.
Command Modes
Command History
Release 12.4(11)MD

The name of this command changed from records format to ip csg records format. The configuration mode for this command changed from CSG accounting configuration to global configuration. The variable-single-cdr keyword was replaced with the combined keyword. The http and wap keywords were added.
Usage Guidelines
This command is valid only for transaction-based CDRs. It is not valid for service-level CDRs. The CSG2 does not support fixed CDRs for IPv6 or for dual stack (IPv4/v6). The CSG2 supports Fixed CDRs only for IPv4. Fixed record format generates CDRs that always contain the same set of Tag-Length-Values (TLVs). Some might have a length of zero. This format is primarily used for integration with legacy billing systems.
Examples
The following example shows how to specify combined CDR record format for HTTP traffic:
ip csg records format variable combined http
A-222
OL-22840-05
Appendix A
CSG2 Command Reference ip csg redirect
ip csg redirect
To redirect subscriber flows to an alternate IP address when the subscribers quota is exhausted, use the ip csg redirect command in global configuration mode. To remove the redirect, use the no form of this command. ip csg redirect {http url | interval seconds | maximum number | sip url | wap url} no ip csg redirect [http | sip | wap]
Syntax Description
http url
(Optional) Redirects HTTP subscriber flows to the specified redirect URL when quota is depleted, and configures the default URL for use in HTTP redirection. (Optional) Length of time, in seconds, during which the CSG2 redirects an out-of-quota subscriber. After this interval, the CSG2 drops the requests until quota can be requested again. The start of the interval is the time of the first redirect after a quota grant of zero. The range is from 0 to 3600. The default is 8.
interval seconds
maximum number
(Optional) Maximum number of times a redirect is to be performed for an out-of-quota subscriber during a redirect interval. The range is from 0 to 255. The default is 15. (Optional) Redirects Session Initiation Protocol (SIP) call requests (INVITE methods) to the specified redirect URL when quota is depleted. (Optional) Redirects wireless application protocol (WAP) subscriber flows to the specified redirect URL when quota is depleted.
sip url wap url
Command Default
If you do not specify an interval, the CSG2 redirects subscriber flows after 8 seconds. If you do not specify a maximum, the CSG2 allows up to 15 redirects during the interval.
Command Modes
Command History
Release 12.4(11)MD

The name of this command changed from redirect to ip csg redirect. The configuration mode for this command changed from CSG user group configuration to CSG2 service configuration. The interval seconds and maximum number keywords and arguments were added. The nat ipv4-address and port-number keyword and arguments were removed.
12.4(15)MD
The sip keyword and url argument were added.
A-223
Appendix A ip csg redirect
Examples
The following example shows how to configure CSG2 redirects:

ip ip ip ip ip csg csg csg csg csg redirect redirect redirect redirect redirect http http://server/topoff.html sip sip: 1.2.3.4 wap http://server/topoff.wml interval 30 maximum 10
A-224
OL-22840-05
Appendix A
CSG2 Command Reference ip csg refund
ip csg refund
To specify the CSG2 refund policy to apply to the various services, and to enter CSG2 refund configuration mode, use the ip csg refund command in global configuration mode. To disable this feature, use the no form of the command. ip csg refund refund-policy-name no ip csg refund refund-policy-name
Syntax Description
refund-policy-name
Name of the refund policy that applies to the content for this service. The name can be from 1 to 15 characters long, and can include uppercase or lowercase letters (the CSG2 changes all letters to uppercase), numbers, and any special characters.
Command Default
None
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
The characteristics of each policy are defined by the following commands:

flagsThe CSG2 supports flag-based refunding for all protocols. retcodeThe CSG2 supports return code-based refunding for all protocols except RTSP.
Examples
The following example shows how to specify CSG2 refund policy COMPANY-REFUND:
ip csg refund COMPANY-REFUND
Related Commands
Command flags ip csg policy ip csg service retcode
Description Specifies protocol flag bit masks and values for CSG2 Prepaid Error Reimbursement. Defines a policy for qualifying flows for the CSG2 accounting services, and enters CSG2 policy configuration mode. Configures a CSG2 content billing service, and enters CSG2 service configuration mode. Specifies the range of application return codes for which the CSG2 refunds quota for Prepaid Error Reimbursement.
A-225
Appendix A ip csg regex memory
ip csg regex memory

To specify the size of the CSG2 regular expression (regex) memory, use the ip csg regex memory command in global configuration mode. To restore the default setting, use the no form of the command. ip csg regex memory memory no ip csg regex memory memory
Syntax Description
memory
Size of the CSG2 regex memory, in MB. The range is from 100 to 400 with the 2 GB-SAMI option and from 100 to 200 with the 1 GB-SAMI option. The default regex memory is 100 MB.
Command Default
The default regex memory is 100MB.
Command Modes
Command History
Release 12.4(22)MDA4
Usage Guidelines
As CSG2 maps become more complex, your CSG2 configuration might require more memory when compiling regex engines. To increase the size of the regex memory, use this command.
Examples
The following example shows how to specify a CSG2 regex memory size of 150 MB:
ip csg regex memory 150
Related Commands
Command ip csg map map (CSG2 policy)
Description Defines the CSG2 billing content filters (attribute, header, method, and URL maps), and enters CSG2 map configuration mode. References an attribute, header, method, or URL map that is part of a CSG2 billing policy.
match attribute (CSG2 Specifies a Layer 7 protocol header attribute match pattern for a CSG2 billing map. map) match header (CSG2 map) match method (CSG2 map) Specifies a header match pattern for a CSG2 billing map. Specifies a method match pattern for a CSG2 billing map.
match url (CSG2 map) Specifies a URL match pattern for a CSG2 billing map.
A-226
OL-22840-05
Appendix A
CSG2 Command Reference ip csg replicate
ip csg replicate
To enable high availability (HA) state replication between redundant CSG2 systems, use the ip csg replicate command in global configuration mode. To disable state replication, use the no form of this command. ip csg replicate [vrf vrf-name] local-ip remote-ip base-port no ip csg replicate
Syntax Description
vrf vrf-name
(Optional) Virtual Routing and Forwarding (VRF) table which the redundant CSG2s are to use when sending state synchronization messages.
Note
local-ip
Local IP address on the CSG2 used as the source IP address for outgoing state synchronization messages, and as the listen IP address for incoming state synchronization messages. You must configure this IP address on the local CSG2 as either an interface or as a secondary IP address. Remote IP address used as the destination IP address for outgoing state synchronization messages. User Datagram Protocol (UDP) port number used as the source and destination port for state synchronization messages. The specified port number is the first of six sequential UDP ports that the CSG2 uses for state synchronization. For example, if you specify port number 2000, the CSG2 uses ports 2000 through 2005 for state synchronization.
remote-ip base-port
Command Default
Replication is not enabled.
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
The ip csg replicate command enables stateful replication of the CSG2 state data structures, such as the CSG2 User Table. To enable replication of session and flows, use the replicate command in CSG2 content configuration mode. Using two separate commands to enable CSG2 replication allows for synchronization of subscriber and quota states independent of per-flow synchronization.
A-227
Appendix A ip csg replicate
Examples
The following example shows how to enable CSG2 replication to a peer using local IP address 10.10.10.1, remote IP address,10.10.10.2, and UDP ports 2000 through 2005:
Ip csg replicate 10.10.10.1 10.10.10.2 2000
Related Commands
Command replicate (CSG2 content)
Description Replicates the connection state for all connections to the CSG2 content servers on the standby system.
A-228
OL-22840-05
Appendix A
CSG2 Command Reference ip csg report 8bytetlv
ip csg report 8bytetlv

To enable the CSG2 to send 8-byte TLVs instead of 4-byte TLVs, use the ip csg report 8bytetlv command in global configuration mode. To restore the default setting, use the no form of this command. ip csg report 8bytetlv no ip csg report 8bytetlv
Syntax Description
Command Default
The CSG2 sends 4-byte TLVs.
Command Modes
Command History
Release 12.4(22)MD
Usage Guidelines
This command can help prevent the wrapping of 4-byte TLVs when using a High-Speed Downlink Packet Access (HSDPA) connection. The CSG2 IP and TCP volume counters are 8-byte counters that wrap at 0xFFFFFFFFFFFFFFFF (18446744073709552000 bytes). The volume counters are 64 bits unsigned. By default, the CSG2 reports volume usages in BMA records using 4-byte TLVs that wrap at 0xFFFFFFFF (4294967295 bytes). Configuring the ip csg report 8bytetlv command enables the CSG2 to report volume usages using 8-byte TLVs instead of 4-byte TLVs.
Examples
The following example shows how to enable the CSG2 to send 8-byte TLVs:
ip csg report 8bytetlv
Related Commands
Command ip csg report block ip csg report content ip csg report http header ip csg report policy
Description Prevents the CSG2 from sending call detail records (CDRs) to Billing Mediation Agent (BMAs). Enables the CSG2 to report content names in variable-format call detail record (CDRs). Defines the inclusion of multiple HTTP request headers in the CSG2 HTTP_Header call detail record (CDR). Enables the CSG2 to report policy names in variable-format call detail record (CDRs).
A-229
Appendix A ip csg report 8bytetlv
Command ip csg report radius attribute ip csg report smtp rfc2822
Description Specifies the RADIUS attributes to be copied from the RADIUS Start message into CSG2 call detail records (CDRs). Specifies that the CSG2 is to include RFC 2822 header Tag-Length-Values (TLVs) in Simple Mail Transfer Protocol (SMTP) call detail records (CDRs). Prevents the CSG2 from generating CDRs when a TCP session has not set up completely and no data has been exchanged. Enables CSG2 supplemental usage reporting to the quota server. Enables the CSG2 to report User Termination CDRs to the Billing Mediation Agents (BMAs). Specifies whether actual wireless application protocol (WAP) protocol data units (PDUs) are to be reported in CSG2 call detail records (CDRs).
ip csg report tcp estab ip csg report usage ip csg report user logoff ip csg report wap actual-pdu
A-230
OL-22840-05
Appendix A
CSG2 Command Reference ip csg report block
ip csg report block

To prevent the CSG2 from sending call detail records (CDRs) to Billing Mediation Agent (BMAs), use the ip csg report block command in global configuration mode. To restore the default setting, use the no form of this command. ip csg report block {prepaid | transaction [pre-policy | user unknown]} no ip csg report block {prepaid | transaction [pre-policy | user unknown]}
Syntax Description
prepaid transaction pre-policy
Blocks the sending of transaction-level and service-level CDRs for prepaid transactions. Blocks the sending of transaction-level CDRs. (Optional) Blocks the sending of pre-policy transaction-level CDRs. (A pre-policy transaction is one that cannot be associated with a policy.) (Optional) Blocks the sending of transaction-level CDRs. of unknown users.
user unknown
Command Default
The CSG2 sends CDRs to BMAs (CDRs are not blocked).
Command Modes
Command History
Release 12.4(24)MDA
Usage Guidelines
A pre-policy transaction is one that meets one of the following criteria:

The TCP handshake does not complete. The TCP handshake completes but is not followed by a request. The HTTP post is issued but does not contain the full URL; the rest of the URL is never received.
By definition, the CSG2 cannot associate a pre-policy transaction with a policy, and thus cannot determine whether the transaction as prepaid. Therefore, even if you have configured the ip csg report block prepaid command, the CSG2 does not block the sending of pre-policy transaction-level CDRs of prepaid users.
Examples
The following example shows how to block the reporting of transaction-level CDRs of unknown users:
ip csg report block transaction user unknown
A-231
Appendix A ip csg report block
Related Commands
Command ip csg report 8bytetlv ip csg report content ip csg report http header ip csg report policy ip csg report radius attribute ip csg report smtp rfc2822
Description Enables the CSG2 to send 8-byte TLVs instead of 4-byte TLVs. Enables the CSG2 to report content names in variable-format call detail record (CDRs). Defines the inclusion of multiple HTTP request headers in the CSG2 HTTP_Header call detail record (CDR). Enables the CSG2 to report policy names in variable-format call detail record (CDRs). Specifies the RADIUS attributes to be copied from the RADIUS Start message into CSG2 call detail records (CDRs). Specifies that the CSG2 is to include RFC 2822 header Tag-Length-Values (TLVs) in Simple Mail Transfer Protocol (SMTP) call detail records (CDRs). Prevents the CSG2 from generating CDRs when a TCP session has not set up completely and no data has been exchanged. Enables CSG2 supplemental usage reporting to the quota server. Enables the CSG2 to report User Termination CDRs to the Billing Mediation Agents (BMAs). Specifies whether actual wireless application protocol (WAP) protocol data units (PDUs) are to be reported in CSG2 call detail records (CDRs).
A-232
OL-22840-05
Appendix A
CSG2 Command Reference ip csg report content
ip csg report content

To enable the CSG2 to report content names in variable-format call detail record (CDRs), use the ip csg report content command in global configuration mode. To disable this feature, use the no form of this command. ip csg report content no ip csg report content
Syntax Description
Command Default
The CSG2 does not report content names in variable-format CDRs.
Command Modes
Command History
Release 12.4(22)MDA
Examples
The following example shows how to enable the reporting of content names in variable-format CDRs:
ip csg report content
Related Commands
Command ip csg report 8bytetlv ip csg report block ip csg report http header ip csg report policy ip csg report radius attribute ip csg report smtp rfc2822
Description Enables the CSG2 to send 8-byte TLVs instead of 4-byte TLVs. Prevents the CSG2 from sending call detail records (CDRs) to Billing Mediation Agent (BMAs). Defines the inclusion of multiple HTTP request headers in the CSG2 HTTP_Header call detail record (CDR). Enables the CSG2 to report policy names in variable-format call detail record (CDRs). Specifies the RADIUS attributes to be copied from the RADIUS Start message into CSG2 call detail records (CDRs). Specifies that the CSG2 is to include RFC 2822 header Tag-Length-Values (TLVs) in Simple Mail Transfer Protocol (SMTP) call detail records (CDRs). Prevents the CSG2 from generating CDRs when a TCP session has not set up completely and no data has been exchanged. Enables CSG2 supplemental usage reporting to the quota server.
ip csg report tcp estab ip csg report usage
A-233
Appendix A ip csg report content
Command ip csg report user logoff ip csg report wap actual-pdu
Description Enables the CSG2 to report User Termination CDRs to the Billing Mediation Agents (BMAs). Specifies whether actual wireless application protocol (WAP) protocol data units (PDUs) are to be reported in CSG2 call detail records (CDRs).
A-234
OL-22840-05
Appendix A
CSG2 Command Reference ip csg report http header
ip csg report http header

To define the inclusion of multiple HTTP request headers in the CSG2 HTTP_Header call detail record (CDR), use the ip csg report http header command in global configuration mode. To disable this configuration, use the no form of this command. ip csg report http header header-name no ip csg report http header header-name
Syntax Description
header-name
Name of the request header that you want to include in the CSG2 HTTP_Header CDR. The header name can be from 1 to 224 characters long, and can include uppercase or lowercase letters (the CSG2 changes all letters to uppercase), numbers, and any special characters.
Command Default
The default is to copy only the host, user-agent, and from HTTP headers into the CDRs.
Command Modes
Command History
Release 12.4(11)MD

The name of this command changed from report http header to ip csg report http header. The configuration mode for this command changed from CSG accounting configuration to global configuration.
Examples
The following example shows how to enable reporting HTTP header information:
ip csg report http header x-subno ip csg report http header x-al-session-id
Related Commands
Command ip csg report 8bytetlv ip csg report block ip csg report content ip csg report policy
Description Enables the CSG2 to send 8-byte TLVs instead of 4-byte TLVs. Prevents the CSG2 from sending call detail records (CDRs) to Billing Mediation Agent (BMAs). Enables the CSG2 to report content names in variable-format call detail record (CDRs). Enables the CSG2 to report policy names in variable-format call detail record (CDRs).
A-235
Appendix A ip csg report http header
Description Specifies the RADIUS attributes to be copied from the RADIUS Start message into CSG2 call detail records (CDRs). Specifies that the CSG2 is to include RFC 2822 header Tag-Length-Values (TLVs) in Simple Mail Transfer Protocol (SMTP) call detail records (CDRs). Prevents the CSG2 from generating CDRs when a TCP session has not set up completely and no data has been exchanged. Enables CSG2 supplemental usage reporting to the quota server. Enables the CSG2 to report User Termination CDRs to the Billing Mediation Agents (BMAs). Specifies whether actual wireless application protocol (WAP) protocol data units (PDUs) are to be reported in CSG2 call detail records (CDRs).
A-236
OL-22840-05
Appendix A
CSG2 Command Reference ip csg report policy
ip csg report policy

To enable the CSG2 to report policy names in variable-format call detail record (CDRs), use the ip csg report policy command in global configuration mode. To disable this feature, use the no form of this command. ip csg report policy no ip csg report policy
Syntax Description
Command Default
The CSG2 does not report policy names in variable-format CDRs.
Command Modes
Command History
Release 12.4(22)MDA
Examples
The following example shows how to enable the reporting of policy names in variable-format CDRs:
ip csg report policy
Related Commands
Command ip csg report 8bytetlv ip csg report block ip csg report content ip csg report http header ip csg report radius attribute ip csg report smtp rfc2822
Description Enables the CSG2 to send 8-byte TLVs instead of 4-byte TLVs. Prevents the CSG2 from sending call detail records (CDRs) to Billing Mediation Agent (BMAs). Enables the CSG2 to report content names in variable-format call detail record (CDRs). Defines the inclusion of multiple HTTP request headers in the CSG2 HTTP_Header call detail record (CDR). Specifies the RADIUS attributes to be copied from the RADIUS Start message into CSG2 call detail records (CDRs). Specifies that the CSG2 is to include RFC 2822 header Tag-Length-Values (TLVs) in Simple Mail Transfer Protocol (SMTP) call detail records (CDRs). Prevents the CSG2 from generating CDRs when a TCP session has not set up completely and no data has been exchanged. Enables CSG2 supplemental usage reporting to the quota server.
A-237
Appendix A ip csg report policy
A-238
OL-22840-05
Appendix A
CSG2 Command Reference ip csg report radius attribute
ip csg report radius attribute

To specify the RADIUS attributes and VSA subattributes to be copied from the RADIUS Start message and sent to the Billing Mediation Agent (BMA) in CSG2 call detail records (CDRs), use the ip csg report radius attribute command in global configuration mode. To disable this feature, use the no form of this command. ip csg report radius attribute {radius-attribute-number | vsa {vendor-id | 3gpp} radius-subattribute-number} no ip csg report radius attribute {radius-attribute-number | vsa {vendor-id | 3gpp} radius-subattribute-number}
Syntax Description
RADIUS attribute number to be copied from the RADIUS Start message. The range is from 1 to 255. Specifies the vendor-specific attribute (VSA). Specifies the vendor ID number. The range is from 1 to 16777215. Specifies the Third Generation Partnership Project (3GPP) vendor ID. Specifies the RADIUS subattribute number. The range is from 1 to 255.
Command Default
No RADIUS attributes are copied into CDRs.
Command Modes
Command History
Release 12.4(11)MD

The name of this command changed from report radius attribute to ip csg report radius attribute. The configuration mode for this command changed from CSG accounting configuration to global configuration. The 26 keyword was removed.
Usage Guidelines
You can specify up to 256 attributes. If an attribute is not present in the RADIUS message, it is not present in the CDRs, unless ip csg records format fixed is configured. The CSG2 saves and reports attribute and subattribute information for each subscriber. When the CSG2 receives a new RADIUS Accounting Start or RADIUS Interim Accounting Request, it saves the attribute and subattribute information parsed from the new request.
A-239
Appendix A ip csg report radius attribute

All previously stored attribute and subattribute information from previous requests is destroyed, even if the new RADIUS Accounting Start or RADIUS Interim Accounting Request does not contain all of the attributes and subattributes that were present in the previous request. Only the currently stored attributes are reported in CDRs. If there are multiple instances of an attribute, they are all reported. Attributes are reported in the order in which they are presented in the RADIUS message. If both the reporting of RADIUS attributes and Roaming Service Control are enabled, the CSG2 sends the combined list of attributes in every CDR to the BMA and quota server (but only changes in the Roaming Service Control attributes trigger reauthorization). For example, if the CSG2 is configured to report attributes 1, 3, and 5, and configured to monitor attributes 2, 4, and 6 for Roaming Service Control, then the CSG2 reports attributes 1, 2, 3, 4, 5, and 6 in all CDRs to the BMA and quota server. For more information about Roaming Service Control, see the Enabling RADIUS Roaming Service Control section on page 9-11.
Examples
The following example shows how to specify the RADIUS attributes to be copied from the RADIUS Start message into CDRs:
ip ip ip ip csg csg csg csg report report report report radius radius radius radius attribute attribute attribute attribute 3 5 7 44
Related Commands
Command ip csg radius attribute ip csg report 8bytetlv ip csg report block ip csg report content ip csg report http header ip csg report policy ip csg report smtp rfc2822
Description Specifies a name for a RADIUS attribute or VSA subattribute that is to be used in subsequent CSG2 configuration commands. Enables the CSG2 to send 8-byte TLVs instead of 4-byte TLVs. Prevents the CSG2 from sending call detail records (CDRs) to Billing Mediation Agent (BMAs). Enables the CSG2 to report content names in variable-format call detail record (CDRs). Defines the inclusion of multiple HTTP request headers in the CSG2 HTTP_Header call detail record (CDR). Enables the CSG2 to report policy names in variable-format call detail record (CDRs). Specifies that the CSG2 is to include RFC 2822 header Tag-Length-Values (TLVs) in Simple Mail Transfer Protocol (SMTP) call detail records (CDRs). Prevents the CSG2 from generating CDRs when a TCP session has not set up completely and no data has been exchanged. Enables CSG2 supplemental usage reporting to the quota server.
A-240
OL-22840-05
Appendix A
CSG2 Command Reference ip csg report radius attribute
Command ip csg report user logoff
Description Enables the CSG2 to report User Termination CDRs to the Billing Mediation Agents (BMAs).
ip csg report wap actual-pdu Specifies whether actual wireless application protocol (WAP) protocol data units (PDUs) are to be reported in CSG2 call detail records (CDRs).
A-241
Appendix A ip csg report smtp rfc2822
ip csg report smtp rfc2822

To specify that the CSG2 is to include RFC 2822 header Tag-Length-Values (TLVs) in Simple Mail Transfer Protocol (SMTP) call detail records (CDRs), use the ip csg report smtp rfc2822 command in global configuration mode. To exclude SMTP headers from CDRs, use the no form of this command. ip csg report smtp rfc2822 no ip csg report smtp rfc2822
Syntax Description
Command Default
RFC 2822 header TLVs are included in SMTP CDRs.
Command Modes
Command History
Release 12.4(11)MD
Examples
The following example shows how to exclude RFC2822 headers from SMTP CDRs:
no ip csg report smtp rfc2822
Related Commands
Command ip csg report 8bytetlv ip csg report block ip csg report content ip csg report http header ip csg report policy ip csg report radius attribute ip csg report tcp estab ip csg report usage
Description Enables the CSG2 to send 8-byte TLVs instead of 4-byte TLVs. Prevents the CSG2 from sending call detail records (CDRs) to Billing Mediation Agent (BMAs). Enables the CSG2 to report content names in variable-format call detail record (CDRs). Defines the inclusion of multiple HTTP request headers in the CSG2 HTTP_Header call detail record (CDR). Enables the CSG2 to report policy names in variable-format call detail record (CDRs). Specifies the RADIUS attributes to be copied from the RADIUS Start message into CSG2 call detail records (CDRs). Prevents the CSG2 from generating CDRs when a TCP session has not set up completely and no data has been exchanged. Enables CSG2 supplemental usage reporting to the quota server.
A-242
OL-22840-05
Appendix A
CSG2 Command Reference ip csg report smtp rfc2822
A-243
Appendix A ip csg report tcp estab
ip csg report tcp estab

To prevent the CSG2 from generating CDRs when a TCP session has not set up completely and no data has been exchanged, use the ip csg report tcp estab command in global configuration mode. To enable the CSG2 to generate CDRs in such a situation, use the no form of this command. ip csg report tcp estab no ip csg report tcp estab
Syntax Description
Command Default
The CSG2 generates CDRs when a TCP session has not set up completely and no data has been exchanged.
Command Modes
Command History
Release 12.4(22)MD
Usage Guidelines
If a BMA receives too many CDRs simultaneously, it can become overloaded. If this occurs, many of the TCP sessions might be unable to complete the initial handshake, and each of those failed TCP sessions generates a CDR. To prevent this flood of CDRs from occurring, enter the ip csg report tcp estab command to prevent the CSG2 from generating these CDRs.
Examples
The following example shows how to prevent the CSG2 from generating CDRs when a TCP session has not set up completely and no data has been exchanged:
Related Commands
Command ip csg report 8bytetlv ip csg report block ip csg report content ip csg report http header ip csg report policy
Description Enables the CSG2 to send 8-byte TLVs instead of 4-byte TLVs. Prevents the CSG2 from sending call detail records (CDRs) to Billing Mediation Agent (BMAs). Enables the CSG2 to report content names in variable-format call detail record (CDRs). Defines the inclusion of multiple HTTP request headers in the CSG2 HTTP_Header call detail record (CDR). Enables the CSG2 to report policy names in variable-format call detail record (CDRs).
A-244
OL-22840-05
Appendix A
CSG2 Command Reference ip csg report tcp estab
Description Specifies the RADIUS attributes to be copied from the RADIUS Start message into call detail records (CDRs). Specifies that the CSG2 is to include RFC 2822 header Tag-Length-Values (TLVs) in Simple Mail Transfer Protocol (SMTP) call detail records (CDRs). Enables CSG2 supplemental usage reporting to the quota server. Enables the CSG2 to report User Termination CDRs to the Billing Mediation Agents (BMAs). Specifies whether actual wireless application protocol (WAP) protocol data units (PDUs) are to be reported in CSG2 call detail records (CDRs).
ip csg report usage ip csg report user logoff ip csg report wap actual-pdu
A-245
Appendix A ip csg report usage
ip csg report usage

To enable CSG2 supplemental usage reporting to the quota server, use the ip csg report usage command in global configuration mode. To disable supplemental usage reporting, use the no form of this command. ip csg report usage {bytes ip | seconds} no ip csg report usage {bytes ip | seconds}
Syntax Description
bytes ip seconds
Report the number of IP bytes uploaded and downloaded for each interval. Report usage in seconds for the interval, as well as the timestamps of the start of the first and last billable sessions in the interval.
Command Default
None
Command Modes
Command History
Release 12.4(11)MD

The name of this command changed from report usage to ip csg report usage. The configuration mode for this command changed from CSG accounting configuration to global configuration.
Usage Guidelines
Interval report Tag-Length-Values (TLVs) are generated for Service Reauthorization Request, Service Stop, and Quota Return messages. Reports contain statistics since the last report. If you want to report both IP bytes and usage in seconds, you can specify both ip csg report usage bytes ip and ip csg report usage seconds.
Examples
The following example shows how to enable supplemental usage reporting for both IP bytes and seconds:
ip csg report usage bytes ip ip csg report usage seconds
A-246
OL-22840-05
Appendix A
CSG2 Command Reference ip csg report usage
Related Commands
Command ip csg report 8bytetlv ip csg report block ip csg report content ip csg report http header ip csg report policy ip csg report radius attribute ip csg report smtp rfc2822
Description Enables the CSG2 to send 8-byte TLVs instead of 4-byte TLVs. Prevents the CSG2 from sending call detail records (CDRs) to Billing Mediation Agent (BMAs). Enables the CSG2 to report content names in variable-format call detail record (CDRs). Defines the inclusion of multiple HTTP request headers in the CSG2 HTTP_Header call detail record (CDR). Enables the CSG2 to report policy names in variable-format call detail record (CDRs). Specifies the RADIUS attributes to be copied from the RADIUS Start message into call detail records (CDRs). Specifies that the CSG2 is to include RFC 2822 header Tag-Length-Values (TLVs) in Simple Mail Transfer Protocol (SMTP) call detail records (CDRs). Prevents the CSG2 from generating CDRs when a TCP session has not set up completely and no data has been exchanged. Enables the CSG2 to report User Termination CDRs to the Billing Mediation Agents (BMAs). Specifies whether actual wireless application protocol (WAP) protocol data units (PDUs) are to be reported in CSG2 call detail records (CDRs).
ip csg report tcp estab ip csg report user logoff ip csg report wap actual-pdu
A-247
Appendix A ip csg report user logoff
ip csg report user logoff

To enable the CSG2 to send User Termination call detail records (CDRs) to the Billing Mediation Agents (BMAs), use the ip csg report user logoff command in global configuration mode. To disable this feature, use the no form of this command. ip csg report user logoff no ip csg report user logoff
Syntax Description
Command Default
The CSG2 does not send User Termination CDRs to the BMAs.
Command Modes
Command History
Release 12.4(24)MD
Usage Guidelines
When this feature is enabled, the CSG2 generates User Termination CDRs whenever a user session is terminated, and sends the CDRs to the BMAs.
Examples
The following example shows how to enable the CSG2 to send User Termination CDRs to the BMAs:
ip csg report user logoff
Related Commands
Command ip csg report 8bytetlv ip csg report block ip csg report content ip csg report http header ip csg report policy ip csg report radius attribute
Description Enables the CSG2 to send 8-byte TLVs instead of 4-byte TLVs. Prevents the CSG2 from sending call detail records (CDRs) to Billing Mediation Agent (BMAs). Enables the CSG2 to report content names in variable-format call detail record (CDRs). Defines the inclusion of multiple HTTP request headers in the CSG2 HTTP_Header call detail record (CDR). Enables the CSG2 to report policy names in variable-format call detail record (CDRs). Specifies the RADIUS attributes to be copied from the RADIUS Start message into call detail records (CDRs).
A-248
OL-22840-05
Appendix A
CSG2 Command Reference ip csg report user logoff
Command ip csg report smtp rfc2822
Description Specifies that the CSG2 is to include RFC 2822 header Tag-Length-Values (TLVs) in Simple Mail Transfer Protocol (SMTP) call detail records (CDRs). Prevents the CSG2 from generating CDRs when a TCP session has not set up completely and no data has been exchanged. Enables CSG2 supplemental usage reporting to the quota server. Specifies whether actual wireless application protocol (WAP) protocol data units (PDUs) are to be reported in CSG2 call detail records (CDRs).
ip csg report tcp estab ip csg report usage ip csg report wap actual-pdu
A-249
Appendix A ip csg report wap actual-pdu
ip csg report wap actual-pdu

To specify whether actual protocol data units (PDUs) are to be reported in CSG2 wireless application protocol (WAP) call detail records (CDRs), use the ip csg report wap actual-pdu command in global configuration mode. To exclude actual PDUs from WAP CDRs, use the no form of this command. ip csg report wap actual-pdu no ip csg report wap actual-pdu
Syntax Description
Command Default
Actual PDUs are not reported in WAP CDRs.
Command Modes
Command History
Release 12.4(11)MD
Examples
The following example shows how to report actual PDUs in WAP CDRs:
ip csg report wap actual-pdu
Related Commands
Command ip csg report 8bytetlv ip csg report block ip csg report content ip csg report http header ip csg report policy ip csg report radius attribute ip csg report smtp rfc2822
Description Enables the CSG2 to send 8-byte TLVs instead of 4-byte TLVs. Prevents the CSG2 from sending call detail records (CDRs) to Billing Mediation Agent (BMAs). Enables the CSG2 to report content names in variable-format call detail record (CDRs). Defines the inclusion of multiple HTTP request headers in the CSG2 HTTP_Header call detail record (CDR). Enables the CSG2 to report policy names in variable-format call detail record (CDRs). Specifies the RADIUS attributes to be copied from the RADIUS Start message into call detail records (CDRs). Specifies that the CSG2 is to include RFC 2822 header Tag-Length-Values (TLVs) in Simple Mail Transfer Protocol (SMTP) call detail records (CDRs). Prevents the CSG2 from generating CDRs when a TCP session has not set up completely and no data has been exchanged.
A-250
OL-22840-05
Appendix A
CSG2 Command Reference ip csg report wap actual-pdu
Command ip csg report usage ip csg report user logoff
Description Enables CSG2 supplemental usage reporting to the quota server. Enables the CSG2 to report User Termination CDRs to the Billing Mediation Agents (BMAs).
A-251
Appendix A ip csg select
ip csg select
To associate a CSG2 user profile with a subscriber, use the ip csg select command in global configuration mode. To remove the association, use the no form of this command. ip csg select profile-name {any | radius called-station-id csid-string} no ip csg select profile-name {any | radius called-station-id csid-string}
Syntax Description
profile-name any radius called-station-id csid-string
Name of the user profile to be associated with the subscriber. (Optional) Associate the user profile with the subscriber if there is no match based on the RADIUS Called-Station-Id. (Optional) Inspect the RADIUS Called-Station-Id (attribute 30) for the specified csid-string when selecting the user profile. The csid-string is a RADIUS Called-Station-Id string of up to 100 alphanumeric characters. The string is case-sensitive. Acceptable characters include alphanumeric characters and any of the following special characters: $-_.+!*'(),?/:@&=;~%. To enter other special characters not listed, use the URL-escape format with the percent sign (%).
Command Default
None
Command Modes
Command History
Release 12.4(22)MDA
Usage Guidelines
To enable Gx for a subscriber, use this command to map the subscriber to a CSG2 user profile that is configured with the pcc gx command in CSG2 user profile configuration mode.
Examples
The following example associates user profile PCRF-PROFILE with subscribers that match RADIUS Called-Station-Id string cs1.com:
ip csg select PCRF-PROFILE radius called-station-id cs1.com
The following example associates user profile PCRF-DEFAULT-PROFILE with subscribers that do not match any RADIUS Called-Station-Id strings:
ip csg select PCRF-DEFAULT-PROFILE any
A-252
OL-22840-05
Appendix A
CSG2 Command Reference ip csg select
Related Commands
Command ip csg pcc gx ip csg user profile pcc gx pcrf failure
Description Enables Gx on the CSG2. Defines a user profile to be associated with a CSG2 subscriber, and enters CSG2 user profile configuration mode. Enables Gx for subscribers associated with a CSG2 user profile. Defines the actions that the CSG2 is to take for a Policy Control & Charging (PCC) user if the Policy and Charging Rule Function (PCRF) fails when the user session is activated. Defines a Mobile Policy Control & Charging (MPCC) profile to be used by the CSG2 when sending per-user Credit Control Requests (CCRs) to the Policy and Charging Rule Function (PCRF). Defines the actions that the CSG2 is to take for a Policy Control & Charging (PCC) user if the Policy and Charging Rule Function (PCRF) times out.
pcrf profile
pcrf timeout
A-253
Appendix A ip csg service
ip csg service
To configure a CSG2 content billing service, and to enter CSG2 service configuration mode, use the ip csg service command in global configuration mode. To turn off the content billing service, use the no form of this command. ip csg service service-name no ip csg service service-name
Syntax Description
service-name
Name of the content billing service, which is a component of a billing plan that is subscribed to by subscribers. The name can be from 1 to 16 characters long, is not case-sensitive, and can include uppercase or lowercase letters (the CSG2 changes all letters to uppercase), numbers, and any special characters.
Command Default
None
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
The CSG2 allows you to define a pool of up to 1024 services. You can authorize, for each subscriber, any number of services from that pool, but we recommend that the billing system not authorize more than 10 active services for each subscriber. Exceeding this guideline could lead to the following problems:

The increase in the number of quota authorizations per subscriber can overload both the quota server and the CSG2. As the number of services for which a subscriber is actively authorized increases, the subscribers quota becomes fragmented. Although the CSG2 allows the billing system to recall and redistribute the quota so that the subscriber is not denied service because of quota fragmentation, the process increases overhead in both the quota server and the CSG2.
The CSG2 supports multiple protocols under a single service definition. The characteristics of each content billing service are defined by the following commands:

activation aoc append url aoc confirm aoc enable
A-254
OL-22840-05
Appendix A
CSG2 Command Reference ip csg service
basis class (CSG2 service) content (CSG2 service) idle (CSG2 service) lifetime (CSG2 service) meter exclude mms wap meter exclude pause rtsp meter exclude svc-idle meter include imap meter increment meter initial meter minimum owner (CSG2 service) passthrough qct (CSG2 service) rating-group (CSG2 service) reauthorization threshold reauthorization timeout records granularity refund user class (CSG2 service) verify confirm verify enable
Examples
The following example shows how to define a CSG2 content billing service named MOVIES:
ip csg service MOVIES
Related Commands
Command activation aoc append url
Description Specifies the activation mode for a CSG2 Connection Duration service. Specifies that the CSG2 is to append the original URL to the redirect URL sent by the quota server for use in Advice of Charge (AoC) URL-rewriting. Configures a token for use in Advice of Charge (AoC) URL-rewriting. Enables Advice of Charge (AoC) URL-rewriting for the CSG2. Specifies the billing basis for a CSG2 content billing service.
aoc confirm aoc enable basis
A-255
Appendix A ip csg service
Command content (CSG2 service)
Description Configures content as a member of a CSG2 billing service, identifies a policy to apply to this content, and optionally assigns a weight to this content. Specifies the minimum amount of time that the CSG2 maintains a service with no subscriber sessions. Defines a CSG2 billing plan, and enters CSG2 billing configuration mode. Specifies the CSG2 refund policy to apply to the various services, and enters CSG2 refund configuration mode. Specifies a maximum duration, or lifetime, for a CSG2 service. Excludes bytes for a WAP 1.x Multimedia Messaging Service (MMS) session from the CSG2 usage calculation. Excludes the Real Time Streaming Protocol (RTSP) PAUSE time from the CSG2 usage calculation. Excludes the final service idle from the CSG2 usage calculation. Specifies which Internet Message Access Protocol (IMAP) bytes are billed for by the CSG2 when doing prepaid debits. Specifies the increments for debiting quota by the CSG2 upon completion of a service configured for Service Duration Billing. Specifies the initial quota debited by the CSG2 from the balance at the beginning of a service when the service is configured for Service Duration Billing. Specifies the initial quota debited by the CSG2 from the balance at the beginning of a service when the service is configured for Service Duration Billing. Specifies an identifier or name for a CSG2 service owner. Enables passthrough mode for a CSG2 service. Specifies a quota consumption time (QCT) for a CSG2 service. Associates a Quality of Service (QoS) profile with a CSG2 service. Specifies a user class match value for a RADIUS attribute or VSA subattribute. Configures a rating group for a CSG2 eG-CDR service. Specifies the CSG2 reauthorization threshold. Specifies the CSG2 reauthorization timeout. Specifies the granularity at which CSG2 billing call detail records (CDRs) are to be generated. Specifies the refund policy for a CSG2 prepaid service. Associates a user class with a CSG2 service. Configures a token for use in CSG2 service verification URL-rewriting. Enables CSG2 service verification.
idle (CSG2 service) ip csg billing ip csg refund lifetime (CSG2 service) meter exclude mms wap meter exclude pause rtsp meter exclude svc-idle meter include imap meter increment meter initial
meter minimum
owner (CSG2 service) passthrough qct (CSG2 service) qos profile (CSG2 service) radius (CSG2 user class) rating-group (CSG2 service) reauthorization threshold reauthorization timeout records granularity refund user class (CSG2 service) verify confirm verify enable
A-256
OL-22840-05
Appendix A
CSG2 Command Reference ip csg snmp timer
ip csg snmp timer

To define Simple Network Management Protocol (SNMP) timers for lost CSG2 records, use the ip csg snmp timer command in global configuration mode. To restore the default setting, use the no form of this command. ip csg snmp timer {bma | psd | quota-server} interval no ip csg snmp timer {bma | psd | quota-server} interval
Syntax Description
bma psd quota-server interval
Defines an SNMP timer for lost CSG2 Billing Mediation Agent (BMA) records. Defines an SNMP timer for lost CSG2 Persistent Storage Device (PSD) records. Defines an SNMP timer for lost CSG2 quota server records. Interval, in seconds, of the CSG2 SNMP timer. The range is from 1 to 2,147,483,647. The default is 60.
Command Default
The default SNMP timer interval is 60 seconds.
Command Modes
Command History
Release 12.4(11)MD

The psd keyword was added. The agent keyword was replaced with the bma keyword.
Examples
The following example defines a 300-second CSG2 SNMP BMA timer:

ip csg snmp timer bma 300
Related Commands
Command snmp-server enable traps csg
Description Enable Simple Network Management Protocol (SNMP) notification types that are available on the CSG2.
A-257
Appendix A ip csg statistics protocol interval
ip csg statistics protocol interval

To define the interval for protocol traffic statistics rate calculation for the CSG2, use the ip csg statistics protocol interval command in global configuration mode. To restore the default setting, use the no form of this command. ip csg statistics protocol interval interval no ip csg statistics protocol interval interval]
Syntax Description
interval
Interval, in seconds, for rate calculation for the CSG2. The range is from 1 to 300. The default is 60.
Command Default
The default CSG2 rate calculation interval is 60 seconds.
Command Modes
Command History
Release 12.4(22)MDA
Usage Guidelines
The show ip csg stats protocol command displays the statistics count, rate, maximum rate, and maximum rate timestamp for the transaction, byte count, and packet count for each of the protocols that is configured on the CSG2. You can configure the interval, in seconds, that the CSG2 is to use when calculating the rates for this command. The displayed rate is the transaction count per second averaged over the specified interval: (T2-T1) / interval where:

T1 is the transaction count at the beginning of the configured interval. T2 is the transaction count at the end of the configured interval. interval is the configured interval.
Examples
The following example defines a 20-second CSG2 rate calculation interval:

ip csg statistics protocol interval 20
Related Commands
Command parse protocol (CSG2 content) show ip csg
Description Defines how the CSG2 is to parse traffic for a content. Displays information about the CSG2.
A-258
OL-22840-05
Appendix A
CSG2 Command Reference ip csg subscriber
ip csg subscriber
To define a subscriber interface as a CSG2 subscriber interface, use the ip csg subscriber command in interface configuration mode. To restore the default setting, use the no form of this command. ip csg subscriber no ip csg subscriber
Syntax Description
Command Default
The interface is not a CSG2 subscriber interface.
Command Modes
Interface configuration
Command History
Release 12.4(11)MD
Usage Guidelines
All traffic routed through the CSG2, including peer-to-peer traffic, must flow from a subscriber interface to a network interface, or from a network interface to a subscriber interface. Therefore, configure the ip csg subscriber command on only the subscriber interface, never on the network interface.
Examples
The following example defines interface GigabitEthernet0/0.69 as a CSG2 subscriber interface:

interface GigabitEthernet0/0.69 ip csg subscriber
A-259
Appendix A ip csg transport-type assign
ip csg transport-type assign

To classify data traffic on the basis of its access path, use the ip csg transport-type assign command in global configuration mode. To remove transport-type information, use the no form of this command. ip csg transport-type assign ipv4-address value no ip csg transport-type assign ipv4-address value
Syntax Description
ipv4-address value
IPv4 address. Transport-type value in the range 1 to 255.
Command Default
None
Command Modes
Command History
Release 12.4(11)MD

The name of the command changed from ip csg transport-type to ip csg transport type assign. The ipv4-address and value arguments were added.
Usage Guidelines
Use the ip csg transport-type assign command to classify data traffic on the basis of its access path, using the Network Access Server (NAS) IPv4 address reported in the RADIUS Accounting Start message. Transport-type information is reported in fixed record format call detail records (CDRs).
Examples
The following example creates a transport-type table and enters transport-type configuration mode:
ip csg transport-type assign 1.2.3.4 6
Related Commands
Command class (CSG2 service) owner (CSG2 service) mode ip csg records format
Description Specifies a service class value. Specifies an identifier or name for a service owner. Specifies the mode for a CSG2 billing plan. Specifies variable or fixed CDR format.
A-260
OL-22840-05
Appendix A
CSG2 Command Reference ip csg user class
ip csg user class

To define a user class to be used by the CSG2 when making routing decisions, and to enter CSG2 user class configuration mode, use the ip csg user class command in global configuration mode. To delete the user class, use the no form of this command. ip csg user class user-class-name no ip csg user class user-class-name
Syntax Description
user-class-name
Name of the user class. The name can be from 1 to 15 characters long, and can include uppercase or lowercase letters (the CSG2 changes all letters to uppercase), numbers, and any special characters.
Command Default
No user class is defined.
Command Modes
Command History
Release 12.4(24)MD
Usage Guidelines
Use this command to define a user class to be used by the CSG2 when making next-hop routing decisions based on RADIUS attribute and VSA subattribute values associated with a subscriber. If you change a user class, the change does not affect routing decisions for existing sessions, nor does it change the user classes selected for subscribers, until those subscriber records are affected by a user class selection event, such as a RADIUS Accounting Start or RADIUS Interim Accounting message. You cannot use the no form of this command to delete a user class if the user class is currently being used in the CSG2 configuration. You can use more than one ip csg user class command to define up to 1000 user classes. The characteristics of each user class are defined by the following commands:
radius (CSG2 user class)
Examples
The following example shows how to define user class 3G-LAPTOP:

ip csg user class 3G-LAPTOP
A-261
Appendix A ip csg user class
Related Commands
Command ip csg radius attribute radius (CSG2 user class)
Description Specifies a name for a RADIUS attribute or VSA subattribute that is to be used in subsequent CSG2 configuration commands. Specifies a user class match value for a RADIUS attribute or VSA subattribute.
user class (CSG2 service) Associates a user class with a CSG2 service.
A-262
OL-22840-05
Appendix A
CSG2 Command Reference ip csg user profile
ip csg user profile

To define a user profile to be associated with a CSG2 subscriber, and enter CSG2 user profile configuration mode, use the ip csg user profile command in global configuration mode. To delete the user profile definition, use the no form of this command. ip csg user profile profile-name no ip csg profile profile-name
Syntax Description
profile-name
Name of the user profile. The name can be from 1 to 16 characters long, is not case-sensitive, and can include uppercase or lowercase letters (the CSG2 changes all letters to uppercase), numbers, and any special characters.
Command Default
None
Command Modes
Command History
Release 12.4(22)MDA
Usage Guidelines
The characteristics of each user profile are defined by the following commands:

pcc gx pcrf failure pcrf profile pcrf timeout
To associate a user profile with a subscriber, use the ip csg select command in global configuration mode.
Examples
The following example defines user profile PCRF-PROFILE:

ip csg user profile PCRF-PROFILE
Related Commands
Command ip csg pcc gx ip csg select pcc gx
Description Enables Gx on the CSG2. Associates a CSG2 user profile with a subscriber. Enables Gx for subscribers associated with a CSG2 user profile.
A-263
Appendix A ip csg user profile
Command pcrf failure
Description Defines the actions that the CSG2 is to take for a Policy Control & Charging (PCC) user if the Policy and Charging Rule Function (PCRF) fails when the user session is activated. Defines a Mobile Policy Control & Charging (MPCC) profile to be used by the CSG2 when sending per-user Credit Control Requests (CCRs) to the Policy and Charging Rule Function (PCRF). Defines the actions that the CSG2 is to take for a Policy Control & Charging (PCC) user if the Policy and Charging Rule Function (PCRF) times out.
pcrf profile
pcrf timeout
A-264
OL-22840-05
Appendix A
CSG2 Command Reference ip iscsi target-profile
ip iscsi target-profile
To create an iSCSI profile for an iSCSI target on the CSG2, and enter iSCSI configuration mode, use the ip iscsi target-profile command in global configuration mode. To remove the iSCSI profile, use the no form of the command. ip iscsi target-profile target-profile-name no ip iscsi target-profile target-profile-name
Syntax Description
target-profile-name
Name of the iSCSI profile.
Command Default
Command Modes
Command History
Release 12.4(15)MD
Usage Guidelines
You can configure only one iSCSI target profile on a given CSG2. The iSCSI profile enables the CSG2 to read/write to a remote iSCSI device (target) on a SAN via an iSCSI.
Note
The CSG2 supports only one type of backup device, either a PSD or an iSCSI device. The PSD and iSCSI features can coexist, but only one can be enabled at a time. The characteristics of each content billing service are defined by the following commands:

ip (iSCSI) name (iSCSI) port (iSCSI) session-timeout (iSCSI) target-portal (iSCSI)
Examples
The following example configures an iSCSI profile with the name targetA to use to store and retrieve CDRs when a charging gateway (CG) is not available:
ip iscsi target-profile targetA name iqn.2002-10.edu.abc.iol.iscsi.draft20-target:1 ip 10.0.0.1 port 3260 session-timeout 120
A-265
Appendix A ip iscsi target-profile
target-portal 1
Related Commands
Command ip (iSCSI) ip csg iscsi drain delay
Description Specifies the IP address of an iSCSI target in the target interface profile on the CSG2. Defines the delay interval, in seconds, before draining packets from the Storage Area Network (SAN) connected to the Internet Small Computer Systems Interface (iSCSI) when the Billing Mediation Agent (BMA) becomes active. Defines the number of packets to be drained from the Storage Area Network (SAN) connected to the Internet Small Computer Systems Interface (iSCSI) per drain delay interval when the Billing Mediation Agent (BMA) becomes active. Specifies the Internet Small Computer Systems Interface (iSCSI) target to be used as backup storage for the CSG2. Specifies the name of an iSCSI target in the target profile on the CSG2 Specifies the number of the port on which to listen for iSCSI traffic in the iSCSI target interface profile on the CSG2. Specifies the session timeout for an iSCSI target in the target interface profile on the CSG2. Specifies the portal group tag for an iSCSI target in the target interface profile on the CSG2.
ip csg iscsi profile name (iSCSI) port (iSCSI) session-timeout (iSCSI) target-portal (iSCSI)
A-266
OL-22840-05
Appendix A
CSG2 Command Reference ipv6 (CSG2 content)
ipv6 (CSG2 content)

To define the subset of Layer 3 and Layer 4 flows that can be processed by the CSG2 accounting services using IPv6 addressing, use the ipv6 command in CSG2 content configuration mode. To delete the flow definition, use the no form of this command. ipv6 {any | ipv6-address | ipv6-prefix} [any | protocol] [port-number] no ipv6 {any | ipv6-address | ipv6-prefix}
Syntax Description
any ipv6-address ipv6-prefix any protocol
All Layer 3 and Layer 4 flows can be processed. This is the default setting. IPv6 address for which Layer 3 and Layer 4 flows can be processed. IPv6 prefix for which Layer 3 and Layer 4 flows can be processed. (Optional) All protocol types of Layer 3 and Layer 4 flows can be processed. This is the default setting. (Optional) Protocol type of Layer 3 and Layer 4 flows that can be processed:

anyFlows of any protocol type can be processed. This is the default setting. tcpOnly TCP flows can be processed. udpOnly User Datagram Protocol (UDP) flows can be processed. protocol-numberNumber identifying the protocol whose flows can be processed. The range is from 0 to 255, where 0 means the same as any.
port-number
(Optional) Specifies the port number for which Layer 3 and Layer 4 flows can be processed. The range is from 0 to 65535, where 0 indicates that flows from any port number can be processed.
Command Default
If you do not specify this command, the content defaults to IPv4 and all Layer 3 and Layer 4 flows (that is, ip any). If you do not specify a protocol, flows of any protocol type can be processed. If you specify a protocol but no port number, the default port number is 0, which means that flows from any port number can be processed. The CSG2 parses port numbers only when processing TCP and UDP traffic. For all other protocols, the CSG2 does not track the Layer 4 port.
Command Modes
Command History
Release 12.4(24)MDA
Usage Guidelines
This command is required to place an IPv6 content in service.
A-267
Appendix A ipv6 (CSG2 content)
UDP ports 9200 and 9201 are well-known Wireless Session Protocol (WSP) and Wireless Transaction Protocol (WTP) wireless application protocol (WAP) ports. When a policy with parse protocol wap is associated with a content, use even-numbered UDP ports to designate WSP traffic, and use odd-numbered ports to designate WTP traffic. Although you can use this command to specify a port number for Layer 3 content (ipv6 any any port-number), the CSG2 does not support Layer 3 content rules. The CSG2 ignores the specified port number, and the show ip csg content command displays the port number as 0. We recommend that all IPv6 content that is configured for NBAR processing (parse protocol nbar) also be configured to match all traffic, using the ipv6 any command.
Examples
The following example shows how to specify that, for content MOVIES_COMEDY, only flows for IPv6 address 12AB: :CD30:0:0:0:0/60 and TCP port 21 are to be processed by the CSG2 accounting services:
ip csg content MOVIES_COMEDY ipv6 12AB: :CD30:0:0:0:0/60 tcp 21
Related Commands
Command ip (CSG2 content) ip csg content
Description Defines the subset of Layer 3 and Layer 4 flows that can be processed by the CSG2 accounting services using IPv4 addressing. Configures content for CSG2 services, and enters CSG2 content configuration mode.
A-268
OL-22840-05
Appendix A
CSG2 Command Reference lifetime (CSG2 service)
lifetime (CSG2 service)

To specify a maximum duration, or lifetime, for a CSG2 service, use the lifetime command in CSG2 service configuration mode. To disable the lifetime specification, use the no form of this command. lifetime duration no lifetime
Syntax Description
duration
Lifetime of the service, in seconds. The range is 0 to 4294967295.
Command Default
None
Command Modes
Command History
Usage Guidelines
Use this command to specify a maximum duration, after which the CSG2 is to stop the service. The prevalence of always-on connections in today's networks can result in CSG2 services that never stop, resulting in very high usage. You can use this command to define a maximum duration for a service. The CSG2 supports this command for:

Prepaid and postpaid services Configured and preloaded services Clears the sessions belonging to the service for the subscriber Clears the service from the subscriber Sends a service-level CDR to the BMA, if configured to do so, with the Service Lifetime Exceeded cause code For true prepaid services, sends Service Stop records with the Service Lifetime Exceeded cause code to the quota server and to the BMA For virtual prepaid services, the CSG2 does not send any Service Stop records
When the lifetime expires for a service, the CSG2 performs the following actions:

Examples
The following example shows how to specify a lifetime of 2000 seconds for CSG2 service SERVICE-A:
ip csg service SERVICE-A lifetime 2000
A-269
Appendix A lifetime (CSG2 service)
Related Commands
Command idle (CSG2 service) ip csg service
Description Specifies the minimum amount of time that the CSG2 maintains a service with no subscriber sessions. Configures a CSG2 content billing service, and enters CSG2 service configuration mode.
A-270
OL-22840-05
Appendix A
CSG2 Command Reference map (CSG2 policy)
map (CSG2 policy)

To reference an attribute, header, method, or URL map that is part of a CSG2 billing policy, use the map command in CSG2 policy configuration mode. To delete the reference, use the no form of this command. map map-name no map map-name
Syntax Description
map-name
Name of an attribute, header, method, or URL map, as configured with an ip csg map command.
Command Default
None
Command Modes
Command History
Release 12.4(11)MD
Modification This command was migrated from CSG1. Changes from CSG1: This command incorporated the following CSG1 commands:

header-map url-map
Usage Guidelines
The conditions specified in the referenced attribute, header, method, or URL map must be true in order for the flows to be processed by the CSG2 accounting services. If the conditions are not true, the flows are not processed. When configuring a map, keep the following considerations in mind:
You can either configure maps (that is, attribute, header, method, or URL maps) on a given policy, or you can associate the policy with a class map; you cannot do both. If you do, the CSG2 ignores the configured maps. You cannot specify different types of match patterns in a given map. For example, a map can include one or more match header statements, but it cannot include both match header statements and match url statements. You can specify up to four maps in a given policy: one for attribute matching, one for header matching, one for method matching, and one for URL matching. For example, the following is a valid configuration:
ip csg map HOSTMAP match header host1 value *.2.*.44 ! ip csg map URLMAP match url */mobile/index.wml ! ip csg policy MAP-POLICY map HOSTMAP
A-271
Appendix A map (CSG2 policy)
map URLMAP
Examples
The following example shows how to reference maps for CSG2 policies MOVIES and GAMES:
ip csg policy MOVIES map HORROR map COMEDY ip csg policy GAMES map GAMES
Related Commands
Command ip csg map ip csg policy ip csg regex memory
Description Defines the CSG2 billing content filters (attribute, header, method, and URL maps), and enters CSG2 map configuration mode. Defines a policy for qualifying flows for the CSG2 billing services, and enters CSG2 policy configuration mode. Specifies the size of the CSG2 regular expression (regex) memory.
match attribute (CSG2 Specifies a Layer 7 protocol header attribute match pattern for a CSG2 billing map. map) match header (CSG2 map) match method (CSG2 map) normalize-url Specifies a header match pattern for a CSG2 billing map. Specifies a method match pattern for a CSG2 billing map.
match url (CSG2 map) Specifies a URL match pattern for a CSG2 billing map. Enables URL map normalization for a CSG2 content.
A-272
OL-22840-05
Appendix A
CSG2 Command Reference match attribute (CSG2 map)
match attribute (CSG2 map)

To specify a Layer 7 protocol header attribute match pattern for a CSG2 billing map, use the match attribute command in CSG2 map configuration mode. To delete the attribute match pattern, use the no form of this command. match attribute {host | field-name} value no match attribute {host | field-name} value
Syntax Description
host field-name
Match the attribute in the host header field. This is the only pre-defined host header field name. Match the attribute in the user-specified field name (for example, ATTRIBUTE). You can match on any field name in the HTTP or SIP headers (such as User-Agent), or on any user-defined field name (such as Custom-Attribute). The field-name argument can be from 1 to 63 characters long and must exactly match a field name in the HTTP or SIP header. It can include uppercase or lowercase letters (the CSG2 changes all letters to uppercase), numbers, and any other keyboard characters. Spaces are not allowed.
Note
The CSG2 does not treat keyboard characters as special characters in the field-name argument. For example, the CSG2 interprets an asterisk (*) in the field-name argument as an asterisk, not as a wildcard.
value
Regular attribute pattern that is to be matched against the input header. The pattern can include up to 121 characters, minus the length of the field name. For example, if the field name is 7 characters long, the pattern can be up to 114 characters long. The pattern can include wildcards and UNIX string-matching special characters. For example, www.somehost*.com is a valid value.
Command Default
None.
Command Modes
CSG2 map configuration
Command History
Release 12.4(22)MD
A-273
Appendix A match attribute (CSG2 map)
Usage Guidelines
The match attribute command supports only HTTP and Session Initiation Protocol (SIP). Attribute maps are primarily intended to match attributes in the host header field (using the host keyword), but you can also use them to match anything in an HTTP or SIP header. In that sense, attribute maps are similar to header maps, but there are some key differences.
Header maps enable you to search multiple header fields in a given content. Use a header map if you need to search multiple fields. Attribute maps can search only a single header field in a given content. Use an attribute map if you are searching for a specific, unique field name in an HTTP or SIP header.
Header maps consume significant amounts of memory because the CSG2 treats each header match pattern as a double-wildcard match, automatically applying one wildcard at the beginning of the header match pattern and one at the end. Attribute maps consume significantly less memory because they match precisely on a field value without the automatic use of wildcards. (You can still code a wildcard in the value field if needed.)
Attribute maps enable you to have more match patterns per content.
You can use more than one match attribute command to specify multiple attribute match patterns as follows:
All of the match attribute commands for a given map, policy, or content must use the same field identifier (either host or the same user-specified field-name). If you try to configure match attribute commands for a given map, policy, or content with different field identifiers, the configuration fails. For example, the following is a valid configuration, because it uses only host field identifiers on the match attribute commands:
ip csg map NEWSMAP match attribute host www.webnews*.com match attribute host www.web*news.com ! ip csg map WEATHERMAP match attribute host www.webweather*.com match attribute host www.web*weather.com ! ip csg policy NEWSPOLICY map NEWSMAP ! ip csg policy WEATHERPOLICY map WEATHERMAP ! ip csg content PREMIUM policy NEWSPOLICY policy WEATHERPOLICY
The following is not a valid configuration, because it uses both host and field-name (in this case, Custom-Attribute) in the same map:
ip csg map BADMAP1 match attribute host www.webnews*.com match attribute Custom-Attribute WEATHER*
The following is not a valid configuration, because it uses different field-names (in this case, Custom-Attribute and New-Custom-Attribute) in the same map:
ip csg map BADMAP2 match attribute Custom-Attribute WEATHER* match attribute New-Custom-Attribute *WEATHER
A-274
OL-22840-05
Appendix A
The following is not a valid configuration, because it uses a map configured with host and a map configured with field-name (in this case, Custom-Attribute) in the same content:
ip csg map NEWSMAP match attribute host www.webnews*.com ! ip csg map WEATHERMAP match attribute Custom-Attribute WEATHER* ! ip csg policy NEWS map NEWSMAP ! ip csg policy WEATHER map WEATHERMAP ! ip csg content BADCONTENT policy NEWS policy WEATHER
If a flow matches any of a maps attribute match patterns, then the CSG2 accepts and processes the flow (unless another map associated with the flow does not match, of course). If a flow does not match any of a maps attribute match patterns, then the match fails and the CSG2 does not accept or process the flow. By default, the attribute match patterns are case-sensitive. For example, if you define the following attribute match pattern: match attribute host www.*.edu but the actual domain is .EDU, then the match fails and the CSG2 does not accept or process the flow. If you do not want the attribute match patterns to be case-sensitive, configure the no ip csg case-sensitive command.
You can specify up to 1408 match patterns per map; up to 1408 total match patterns per policy; up to 1408 total match patterns per content; and up to 8192 total match patterns per CSG2 (assuming there is enough memory available). The following table shows and describes the special characters that you can use in the value argument in attribute match patterns. Convention * + ? Description Zero or more characters. Zero or more repeated instances of the token preceding the +. Zero or one character.
A-275
Appendix A match attribute (CSG2 map)
Convention \character
Description Escaped character. Examples: \? Match on a question mark (\<ctrl-v>?) \+ Match on a plus sign \* Match on an asterisk \a Alert (ASCII 7) \b Backspace (ASCII 8) \f Form-feed (ASCII 12) \n New line (ASCII 10) \r Carriage return (ASCII 13) \t Tab (ASCII 9) \v Vertical tab (ASCC 11) \0 Null (ASCII 0) \\ Back slash
Bracketed range [0-9] A leading ^ in a range .\x##
Matching any single character from the range. Do not match any in the range. All other characters represent themselves. Any ASCII character as specified in two-digit hex notation. For example, \x3f yields a ? for a one-character wild card match.
You cannot specify different types of match patterns in a given map. For example, a map can include one or more match header statements, but it cannot include both match header statements and match url statements. You can specify up to four maps in a given policy: one for attribute matching, one for header matching, one for method matching, and one for URL matching. For example, the following is a valid configuration:
Examples
The following example shows how to specify an HTTP attribute match pattern for map EDUCATION. In this example, the attribute match is TRUE only for hosts in the .edu domain. Any other host matches FALSE:
ip csg map EDUCATION
A-276
OL-22840-05
Appendix A
match attribute host www.*.edu
Related Commands
Command ip csg case-sensitive ip csg map ip csg policy map (CSG2 policy) match header (CSG2 map) match method (CSG2 map)
Description Specifies whether to treat CSG2 attribute, header, method, and URL match patterns as case-sensitive. Defines the CSG2 billing content filters (attribute, header, method, and URL maps), and enters CSG2 map configuration mode. Defines a policy for qualifying flows for the CSG2 billing services, and enters CSG2 policy configuration mode. References an attribute, header, method, or URL map that is part of a CSG2 billing policy. Specifies a header match pattern for a CSG2 billing map. Specifies a method match pattern for a CSG2 billing map.
A-277
Appendix A match domain (CSG2 domain group)
match domain (CSG2 domain group)

To define a domain name match pattern for a CSG domain group, use the match domain command in CSG2 domain group configuration mode. To delete the domain name match pattern, use the no form of this command. match domain value no match domain value
Syntax Description
value
Regular domain name pattern that is to be matched against the input domain name. The pattern can include up to 127 characters, including wildcards and UNIX string-matching special characters.
Command Default
None.
Command Modes
CSG2 domain group configuration
Command History
Release 12.4(24)MD
Usage Guidelines
You can use more than one match domain command in CSG2 domain group configuration mode to specify multiple domain name match patterns as follows:
You can configure up to 1024 domain name match patterns for all domain groups in the CSG2. That is, if you configure 10 match domain commands for one domain group, you can configure no more than 1014 match domain commands for all remaining domain groups. in the CSG2. You cannot add, change, or delete match domain commands for a domain group if global mining is enabled (using the ip csg domain mining command) or if the domain group is currently being used by a CSG2 content. If a flow matches any of a maps domain name match patterns, then the CSG2 accepts and processes the flow (unless another map associated with the flow does not match, of course). If a flow does not match any of a maps domain name match patterns, then the match fails and the CSG2 does not accept or process the flow. Do not define a domain name match pattern that consists of a single stand-alone wildcard: match domain * Doing so bypasses the way the CSG2 handles no-match conditions.
By default, the domain name match patterns are case-sensitive. For example, if you define the following domain name match pattern: match domain *VF.com
A-278
OL-22840-05
Appendix A
CSG2 Command Reference match domain (CSG2 domain group)
but the actual domain name is vf.com, then the match fails and the CSG2 does not accept or process the flow. If you do not want the domain name match patterns to be case-sensitive, configure the no ip csg case-sensitive command.
You can include up to two wildcards in each domain name match pattern, but the more wildcard matches you use, the fewer maps (of all types) and domain name match patterns the CSG2 can handle, depending on your configuration. When using wildcards in domain name match patterns, observe the following guidelines to optimize the performance of the CSG2:
Minimize the number of domain name match patterns that are applied to a CSG2 domain group
configuration.
Minimize the number of keyword domain group match patterns that you use. In general, it is
better to use multiple single-wildcard domain group match patterns instead of individual keyword domain group match patterns.
Combine several keyword domain group match patterns into a single pattern by using UNIX
string-matching special characters. For example, *.movies_comedy.com/*.mpeg, *.movies_action.com/*.mpeg, and *.movies_drama.com/*.mpeg can be combined into the following single pattern: *.movies_(comedy|action|drama).com/*.mpeg And these patterns *.movies_comedy.com/*.mpeg *.movies_action.com/*.mpeg *.movies_drama.com/*.mpeg *.clips_comedy.com/*.mpeg *.clips_action.com/*.mpeg *.clips_drama.com/*.mpeg can be combined into the following single pattern: *.(movies|clips)*?*(comedy|action|drama).com/*.mpeg
Do not forget that the entire pattern, including wildcards and UNIX string-matching special
characters, cannot exceed 127 characters. The following table shows and describes the special characters that you can use in the value argument in domain name match patterns. Convention * + ? Description Zero or more characters. Zero or more repeated instances of the token preceding the +. Zero or one character.
A-279
Appendix A match domain (CSG2 domain group)
Matching any single character from the range. Do not match any in the range. All other characters represent themselves. Any ASCII character as specified in two-digit hex notation. For example, \x3f yields a ? a one-character wild card match.
Examples
The following example shows how to configure domain name match patterns for domain group PARTNER:
ip csg match match match match domain domain domain domain domain group PARTNER priority 10 *VF.com *vf.com *partner.com *.movies_(comedy|action|drama).com/*.mpeg
Related Commands
ip csg domain group mining (CSG2 content)
Defines a CSG2 domain group, and enters CSG2 domain group configuration mode. Enables domain name mining for the CSG2 content.
A-280
OL-22840-05
Appendix A
CSG2 Command Reference match header (CSG2 map)
match header (CSG2 map)

To specify a header match pattern for a CSG2 billing map, use the match header command in CSG2 map configuration mode. To delete the header match pattern, use the no form of this command. match header header-name value no match header header-name value
Syntax Description
header-name
Header field that is to be matched against the input header. The header-name argument is the name of the HTTP header keyword, such as Content-Type, Host, Referer, User-Agent, or an arbitrary header name from 1 to 63 characters long. The header name can include uppercase or lowercase letters (the CSG2 changes all letters to uppercase), numbers, and any special characters.
Note
For Session Initiation Protocol (SIP), you must enter the long form of the header name. The CSG2 does not support the short form of the header name.
value
Regular header pattern that is to be matched against the input header. The pattern can include up to 121 characters, minus the length of the header name. For example, if the header name is 7 characters long, the pattern can be up to 114 characters long. The pattern can include wildcards and UNIX string-matching special characters.
Command Default
None.
Command Modes
Command History
Release 12.4(11)MD

The name of this command changed from match (header map) to match header. The configuration mode for this command changed from CSG header map configuration to CSG2 map configuration. The protocol protocol and value keywords and arguments were removed. The pattern argument was replaced with the value argument.
12.4(15)MD
Support for Session Initiation Protocol (SIP) headers was added.
A-281
Appendix A match header (CSG2 map)
Usage Guidelines
This command is valid only for HTTP and Session Initiation Protocol (SIP). You can use more than one match header command in CSG2 map configuration mode to specify multiple header match patterns for a header map as follows:
You can configure more than one match header command in a given header map, but they must reference different headers. For example, the following is a valid configuration, because the first match header command references header Host and the other references header User-Agent:
ip csg map HDR1 match header Host www.cisco.com match header User-Agent myagent
But the following is not a valid configuration, because both match header commands reference header Host:
ip csg map HDR1 match header Host www.cisco.com match header Host my.cisco.com
If a flow matches all of a maps header match patterns, then the CSG2 accepts and processes the flow (unless another map associated with the flow does not match, of course). If a flow does not match even one of a maps header match patterns, then the match fails and the CSG2 does not accept or process the flow. The CSG2 treats each header match pattern as a double-wildcard match, automatically applying one wildcard at the beginning of the header match pattern and one at the end. That means that a header match pattern that includes even a single wildcard, such as match header host* 1.2.3.4, is treated as a triple-wildcard match. The more wildcard matches you use, the fewer maps (of all types) and header match patterns the CSG2 can handle, depending on your configuration. Therefore, to optimize the performance of the CSG2, minimize the number of header match patterns that are applied to a CSG2 content configuration, and minimize the number of wildcards used in header match patterns. By default, the header match patterns are case-sensitive. For example, if you define the following header match pattern: match header host1 *.2.*.44 but the actual HTTP header keyword is HOST1, then the match fails and the CSG2 does not accept or process the flow. If you do not want the header match patterns to be case-sensitive, configure the no ip csg case-sensitive command.
You can specify up to 1408 match patterns per map; up to 1408 total match patterns per policy; up to 1408 total match patterns per content; and up to 8192 total match patterns per CSG2 (assuming there is enough memory available). The following table shows and describes the special characters that you can use in the value argument in header match patterns. Convention * + ? Description Zero or more characters. Zero or more repeated instances of the token preceding the +. Zero or one character.
A-282
OL-22840-05
Appendix A
CSG2 Command Reference match header (CSG2 map)
Matching any single character from the range. Do not match any in the range. All other characters represent themselves. Any ASCII character as specified in two-digit hex notation. For example, \x3f yields a ? for a one-character wild card match.
You cannot specify different types of match patterns in a given map. For example, a map can include one or more match header statements, but it cannot include both match header statements and match url statements. You can specify up to four maps in a given policy: one for attribute matching, one for header matching, one for method matching, and one for URL matching. For example, the following is a valid configuration:
Examples
The following example shows how to specify HTTP header match patterns for map HDR1. In this example, the header match is TRUE only for host www.cisco.com and user agent myagent. Any other combination of host and IP address matches FALSE:
ip csg map HDR1
A-283
Appendix A match header (CSG2 map)
match header Host www.cisco.com match header User-Agent myagent
The following example shows how to specify SIP header match patterns for map SIP-HDR1. In this example, the header match is TRUE only for Event presence and Content-Type application/sdp. Any other combination of Event and Content-Type matches FALSE:
ip csg map SIP-HDR1 match header Event presence match header Content-Type application/sdp
Related Commands
Command ip csg case-sensitive ip csg map ip csg policy map (CSG2 policy)
Description Specifies whether to treat CSG2 attribute, header, method, and URL match patterns as case-sensitive. Defines the CSG2 billing content filters (attribute, header, method, and URL maps), and enters CSG2 map configuration mode. Defines a policy for qualifying flows for the CSG2 billing services, and enters CSG2 policy configuration mode. References an attribute, header, method, or URL map that is part of a CSG2 billing policy.
match attribute (CSG2 Specifies a Layer 7 protocol header attribute match pattern for a CSG2 billing map. map) match method (CSG2 map) Specifies a method match pattern for a CSG2 billing map.
A-284
OL-22840-05
Appendix A
CSG2 Command Reference match method (CSG2 map)
match method (CSG2 map)

To specify a method match pattern for a CSG2 billing map, use the match method command in CSG2 map configuration mode. To delete the match pattern, use the no form of this command. match method method-name no match method method-name
Syntax Description
method-name
Method to be matched. Valid methods are:

connectHTTP CONNECT method get HTTP GET method headHTTP HEAD method inviteSIP INVITE method messageSIP MESSAGE method notifySIP NOTIFY method optionsSIP OPTIONS method postHTTP POST method registerSIP REGISTER method subscribeSIP SUBSCRIBE method Any other extension method name of 1 to 15 characters
Command Default
None.
Command Modes
Command History
Release 12.4(11)MD 12.4(15)MD
Modification This command was introduced. Support for Session Initiation Protocol (SIP) methods was added.
Usage Guidelines
This command is valid only for HTTP and SIP. You can use more than one match method command in CSG2 map configuration mode to specify multiple method match patterns for a method map:

If a flow matches any of a maps method match patterns, then the CSG2 accepts and processes the flow (unless another map associated with the flow does not match, of course). If a flow does not match any of a maps method match patterns, then the match fails and the CSG2 does not accept or process the flow.
A-285
Appendix A match method (CSG2 map)
By default, the method match patterns are case-sensitive. For example, if you define the following method match pattern: match method get but the actual method keyword is GET, then the match fails and the CSG2 does not accept or process the flow. If you do not want the method match patterns to be case-sensitive, configure the no ip csg case-sensitive command.
You can specify up to 1408 match patterns per map; up to 1408 total match patterns per policy; up to 1408 total match patterns per content; and up to 8192 total match patterns per CSG2 (assuming there is enough memory available). The following table shows and describes the special characters that you can use in the method-name argument in method match patterns. Convention * + ? \character Description Zero or more characters. Zero or more repeated instances of the token preceding the +. Zero or one character. Escaped character. Examples: \? Match on a question mark (\<ctrl-v>?) \+ Match on a plus sign \* Match on an asterisk \a Alert (ASCII 7) \b Backspace (ASCII 8) \f Form-feed (ASCII 12) \n New line (ASCII 10) \r Carriage return (ASCII 13) \t Tab (ASCII 9) \v Vertical tab (ASCC 11) \0 Null (ASCII 0) \\ Back slash Bracketed range [0-9] A leading ^ in a range .\x## Matching any single character from the range. Do not match any in the range. All other characters represent themselves. Any ASCII character as specified in two-digit hex notation. For example, \x3f yields a ? for a one-character wild card match. When configuring a map, keep the following considerations in mind:
You cannot specify different types of match patterns in a given map. For example, a map can include one or more match header statements, but it cannot include both match header statements and match url statements.
A-286
OL-22840-05
Appendix A
CSG2 Command Reference match method (CSG2 map)
You can specify up to four maps in a given policy: one for attribute matching, one for header matching, one for method matching, and one for URL matching. For example, the following is a valid configuration:
Examples
The following example shows how to specify a GET method match pattern for map MOVIES:
ip csg map MOVIES match method GET
Related Commands
Command ip csg case-sensitive ip csg map ip csg policy map (CSG2 policy) match attribute (CSG2 map) match header (CSG2 map) match url (CSG2 map)
Description Specifies whether to treat CSG2 attribute, header, method, and URL match patterns as case-sensitive. Defines the CSG2 billing content filters (attribute, header, method, and URL maps), and enters CSG2 map configuration mode. Defines a policy for qualifying flows for the CSG2 billing services, and enters CSG2 policy configuration mode. References an attribute, header, method, or URL map that is part of a CSG2 billing policy. Specifies a Layer 7 protocol header attribute match pattern for a CSG2 billing map. Specifies a header match pattern for a CSG2 billing map. Specifies a URL match pattern for a CSG2 billing map.
A-287
Appendix A match url (CSG2 map)
match url (CSG2 map)

To specify a URL match pattern for a CSG2 billing map, use the match url command in CSG2 map configuration mode. To delete the match pattern, use the no form of this command. match url pattern no match url pattern
Syntax Description
pattern
Regular URL pattern to be matched against the input URL. The pattern can include up to 127 characters, including wildcards and UNIX string-matching special characters.
Command Modes
Command History
Release 12.4(11)MD

The name of this command changed from match (URL map) to match url. The configuration mode for this command changed from CSG2 URL map configuration to CSG2 map configuration. The protocol protocol and method method keywords and arguments were removed.
12.4(15)MD
Support for Session Initiation Protocol (SIP) URLs was added.
Usage Guidelines
You can use more than one match url command in CSG2 map configuration mode to specify multiple URL match patterns for a URL map:

If a flow matches any of a maps URL match patterns, then the CSG2 accepts and processes the flow (unless an attribute, header, or method map associated with the flow does not match, of course). If a flow does not match any of a maps URL match patterns, then the match fails and the CSG2 does not accept or process the flow. By default, the URL match patterns are case-sensitive, and you must consider uppercase and lowercase combinations carefully when you create URL match patterns. For example, if you define the following URL match pattern: match url http://url-string but a subscriber enters the following URL in a web browser: HTTP://url-string then the match fails and the CSG2 does not accept or process the flow. If you do not want the URL match patterns to be case-sensitive, configure the no ip csg case-sensitive command.
A-288
OL-22840-05
Appendix A
CSG2 Command Reference match url (CSG2 map)
As a further example, by default the following URLs do not match: http://www.cisco.com/index.html http://www.cisco.com/INDEX.html However, if you have disabled case-sensitivity by entering the no ip csg case-sensitive command, then all of the following URLs match: http://www.cisco.com/index.html http://www.cisco.com/INDEX.html http://www.cisco.com/Index.html http://www.cisco.com/IndeX.html http://www.cisco.com/INdex.html
When you configure URL match patterns for Real Time Streaming Protocol (RTSP) streams, be sure to account for trailing stream IDs in RTSP stream names. For example, URL match pattern *.mpeg does not match rtsp://1.1.1.254:554/movie.mpeg/streamid=0 because the stream name has a trailing /streamid=0. To match such RTSP stream names, use a URL match pattern such as *.mpeg*. You can include up to two wildcards in each URL match pattern, but the more wildcard matches you use, the fewer maps (of all types) and URL match patterns the CSG2 can handle, depending on your configuration. For example, the CSG2 can handle the following combinations of URL maps and URL match patterns:
If you have one content and 1023 policies, then the CSG2 can handle up to 1023 URL maps,
each with one URL match pattern and no wildcards.

If you have 2000 contents, each with the same policy and the same URL map, then the CSG2
can handle up to 100 URL match patterns for that map, with one wildcard in each pattern (such as *movies or movies*, but not *movies*).
If you have one content, one policy, and one URL map, then the CSG2 can handle up to 17
match patterns for that map, with two wildcards in each pattern (such as *movies*).
When using wildcards in URL match patterns, observe the following guidelines to optimize the performance of the CSG2:
Minimize the number of URL match patterns that are applied to a CSG2 content configuration. Minimize the number of keyword URL match patterns that you use. In general, it is better to use
multiple single-wildcard URL match patterns instead of individual keyword URL match patterns.
Combine several keyword URL match patterns into a single pattern by using UNIX
string-matching special characters. For example, *.movies_comedy.com/*.mpeg, *.movies_action.com/*.mpeg, and *.movies_drama.com/*.mpeg can be combined into the following single pattern: *.movies_(comedy|action|drama).com/*.mpeg And these patterns *.movies_comedy.com/*.mpeg *.movies_action.com/*.mpeg
A-289
Appendix A match url (CSG2 map)
*.movies_drama.com/*.mpeg *.clips_comedy.com/*.mpeg *.clips_action.com/*.mpeg *.clips_drama.com/*.mpeg can be combined into the following single pattern: *.(movies|clips)*?*(comedy|action|drama).com/*.mpeg
Do not forget that the entire pattern, including wildcards and UNIX string-matching special
characters, cannot exceed 127 characters. You can specify up to 1408 match patterns per map; up to 1408 total match patterns per policy; up to 1408 total match patterns per content; and up to 8192 total match patterns per CSG2 (assuming there is enough memory available). The following table shows and describes the special characters that you can use in the pattern argument in URL match patterns. Convention * + ? \character Description Zero or more characters. Zero or more repeated instances of the token preceding the +. Zero or one character. Escaped character. Examples: \? Match on a question mark (\<ctrl-v>?) \+ Match on a plus sign \* Match on an asterisk \a Alert (ASCII 7) \b Backspace (ASCII 8) \f Form-feed (ASCII 12) \n New line (ASCII 10) \r Carriage return (ASCII 13) \t Tab (ASCII 9) \v Vertical tab (ASCC 11) \0 Null (ASCII 0) \\ Back slash Bracketed range [0-9] A leading ^ in a range .\x## Matching any single character from the range. Do not match any in the range. All other characters represent themselves. Any ASCII character as specified in two-digit hex notation. For example, \x3f yields a ? for a one-character wild card match. For WAP, the CSG2 supports only URL maps. Attribute, header, and method maps are not supported.
A-290
OL-22840-05
Appendix A
CSG2 Command Reference match url (CSG2 map)

We recommend that you configure the URL match pattern during your maintenance window, or during off-peak hours. You cannot specify different types of match patterns in a given map. For example, a map can include one or more match header statements, but it cannot include both match header statements and match url statements. You can specify up to four maps in a given policy: one for attribute matching, one for header matching, one for method matching, and one for URL matching. For example, the following is a valid configuration:
Examples
The following example shows how to specify URL match patterns for map MOVIES. In this example, the URL match is TRUE for *.movies_comedy.com/*.mpeg, for *.movies_action.com/*.mpeg, for *.movies_drama.com/*.mpeg, and for any other URLs that match the pattern:
ip csg match ip csg match map url map url MOVIES *.movies_(comedy|action|drama).com/*.mpeg IMAGES *.(gif|jpg)
Related Commands
Command ip csg case-sensitive ip csg map ip csg policy map (CSG2 policy) match attribute (CSG2 map) match header (CSG2 map) match method (CSG2 map) normalize-url relative
Description Specifies whether to treat CSG2 attribute, header, method, and URL match patterns as case-sensitive. Defines the CSG2 billing content filters (attribute, header, method, and URL maps), and enters CSG2 map configuration mode. Defines a policy for qualifying flows for the CSG2 billing services, and enters CSG2 policy configuration mode. References an attribute, header, method, or URL map that is part of a CSG2 billing policy. Specifies a Layer 7 protocol header attribute match pattern for a CSG2 billing map. Specifies a header match pattern for a CSG2 billing map. Specifies a method match pattern for a CSG2 billing map. Enables URL map normalization for a CSG2 content. Enables relative URI support in the HTTP request header for URL matching for a CSG2 content.
A-291
Appendix A meter exclude control sip
meter exclude control sip

To exclude call control packets for a Session Initiation Protocol (SIP) session from the CSG2 usage calculation, use the meter exclude control sip command in CSG2 service configuration mode. To return to the default behavior, use the no form of the command. meter exclude control sip no meter exclude control sip
Syntax Description
Command Default
The default behavior is to include the SIP call control packets in the usage calculation.
Command Modes
Command History
Release 12.4(15)MD
Usage Guidelines
The meter exclude control sip command and the basis second command in CSG2 service configuration mode are mutually exclusive. If you configure the meter exclude control sip command, do not configure the basis second command.
Examples
The following example shows how to exclude the call control packets for a SIP session from the usage calculation for the SERVICE-A service:
ip csg service SERVICE-A meter exclude control sip
Related Commands
Command ip csg service meter exclude mms wap meter exclude network-init sip
Description Configures a CSG2 content billing service, and enters CSG2 service configuration mode. Excludes bytes for a WAP 1.x Multimedia Messaging Service (MMS) session from the CSG2 usage calculation. Excludes incoming Session Initiation Protocol (SIP) transactions (that is, those that are initiated from the network) from the CSG2 usage calculation. Excludes the Real Time Streaming Protocol (RTSP) PAUSE time from the CSG2 usage calculation. Excludes the final service idle from the CSG2 usage calculation.
meter exclude pause rtsp meter exclude svc-idle
A-292
OL-22840-05
Appendix A
CSG2 Command Reference meter exclude control sip
Command meter include imap meter increment meter initial
Description Specifies which Internet Message Access Protocol (IMAP) bytes are billed for by the CSG2 when doing prepaid debits. Specifies the increments for debiting quota by the CSG2 upon completion of a service configured for Service Duration Billing. Specifies the initial quota debited by the CSG2 from the balance at the beginning of a service when the service is configured for Service Duration Billing. Specifies the initial quota debited by the CSG2 from the balance at the beginning of a service when the service is configured for Service Duration Billing.
meter minimum
A-293
Appendix A meter exclude mms wap
meter exclude mms wap

To exclude bytes for a WAP 1.x Multimedia Messaging Service (MMS) session from the CSG2 usage calculation, use the meter exclude mms wap command in CSG2 service configuration mode. To return to the default behavior, use the no form of the command. meter exclude mms wap no meter exclude mms wap
Syntax Description
Command Default
The default behavior is to include the MMS in the usage calculation.
Command Modes
Command History
Release 12.4(11)MD
Modification This command was migrated from CSG1. Changes from CSG1: The meter exclude command split into three new commandsmeter exclude mms wap, meter exclude pause rtsp, and meter exclude svc-idle.
Usage Guidelines
The meter exclude mms wap command and the basis second command in CSG2 service configuration mode are mutually exclusive. If you configure the meter exclude mms wap command, do not configure the basis second command.
Examples
The following example shows how to exclude the bytes for a WAP 1.x MMS session from the usage calculation for the SERVICE-A service:
ip csg service SERVICE-A meter exclude mms wap
Related Commands
Command ip csg service meter exclude control sip meter exclude network-init sip
Description Configures a CSG2 content billing service, and enters CSG2 service configuration mode. Excludes call control packets for a Session Initiation Protocol (SIP) session from the CSG2 usage calculation. Excludes incoming Session Initiation Protocol (SIP) transactions (that is, those that are initiated from the network) from the CSG2 usage calculation.
A-294
OL-22840-05
Appendix A
CSG2 Command Reference meter exclude mms wap
Command meter exclude pause rtsp meter exclude svc-idle meter include imap meter increment meter initial
Description Excludes the Real Time Streaming Protocol (RTSP) PAUSE time from the CSG2 usage calculation. Excludes the final service idle from the CSG2 usage calculation. Specifies which Internet Message Access Protocol (IMAP) bytes are billed for by the CSG2 when doing prepaid debits. Specifies the increments for debiting quota by the CSG2 upon completion of a service configured for Service Duration Billing. Specifies the initial quota debited by the CSG2 from the balance at the beginning of a service when the service is configured for Service Duration Billing. Specifies the initial quota debited by the CSG2 from the balance at the beginning of a service when the service is configured for Service Duration Billing.
meter minimum
A-295
Appendix A meter exclude network-init sip
meter exclude network-init sip

To exclude incoming Session Initiation Protocol (SIP) transactions (that is, those that are initiated from the network) from the CSG2 usage calculation, use the meter exclude network-init sip command in CSG2 service configuration mode. To return to the default behavior, use the no form of the command. meter exclude network-init sip no meter exclude network-init sip
Syntax Description
Command Default
The default behavior is to include incoming SIP transactions in the usage calculation.
Command Modes
Command History
Release 12.4(15)MD
Examples
The following example shows how to exclude incoming SIP transactions from the usage calculation for the SERVICE-A service:
ip csg service SERVICE-A meter exclude network-init sip
Related Commands
Command ip csg service meter exclude control sip meter exclude mms wap meter exclude pause rtsp meter exclude svc-idle meter include imap meter increment
Description Configures a CSG2 content billing service, and enters CSG2 service configuration mode. Excludes call control packets for a Session Initiation Protocol (SIP) session from the CSG2 usage calculation. Excludes bytes for a WAP 1.x Multimedia Messaging Service (MMS) session from the CSG2 usage calculation. Excludes the Real Time Streaming Protocol (RTSP) PAUSE time from the CSG2 usage calculation. Excludes the final service idle from the CSG2 usage calculation. Specifies which Internet Message Access Protocol (IMAP) bytes are billed for by the CSG2 when doing prepaid debits. Specifies the increments for debiting quota by the CSG2 upon completion of a service configured for Service Duration Billing.
A-296
OL-22840-05
Appendix A
CSG2 Command Reference meter exclude network-init sip
Command meter initial
Description Specifies the initial quota debited by the CSG2 from the balance at the beginning of a service when the service is configured for Service Duration Billing. Specifies the initial quota debited by the CSG2 from the balance at the beginning of a service when the service is configured for Service Duration Billing.
meter minimum
A-297
Appendix A meter exclude pause rtsp
meter exclude pause rtsp

To exclude the Real Time Streaming Protocol (RTSP) PAUSE time from the CSG2 usage calculation, use the meter exclude pause rtsp command in CSG2 service configuration mode. To return to the default behavior, use the no form of the command. meter exclude pause rtsp no meter exclude pause rtsp
Syntax Description
Command Default
The default behavior is to include the RTSP PAUSE time in the usage calculation.
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
You must configure basis second before configuring this command. The meter exclude pause rtsp command and the qct command in CSG2 service configuration mode are mutually exclusive. If you configure the meter exclude pause rtsp command, do not configure the qct command.
Examples
The following example shows how to exclude the RTSP PAUSE time from the usage calculation for the SERVICE-A service:
ip csg service SERVICE-A basis second meter exclude pause rtsp
Related Commands
Command ip csg service meter exclude control sip meter exclude mms wap
Description Configures a CSG2 content billing service, and enters CSG2 service configuration mode. Excludes call control packets for a Session Initiation Protocol (SIP) session from the CSG2 usage calculation. Excludes bytes for a WAP 1.x Multimedia Messaging Service (MMS) session from the CSG2 usage calculation.
A-298
OL-22840-05
Appendix A
CSG2 Command Reference meter exclude pause rtsp
Command meter exclude network-init sip
Description Excludes incoming Session Initiation Protocol (SIP) transactions (that is, those that are initiated from the network) from the CSG2 usage calculation. Excludes the final service idle from the CSG2 usage calculation. Specifies which Internet Message Access Protocol (IMAP) bytes are billed for by the CSG2 when doing prepaid debits. Specifies the increments for debiting quota by the CSG2 upon completion of a service configured for Service Duration Billing. Specifies the initial quota debited by the CSG2 from the balance at the beginning of a service when the service is configured for Service Duration Billing. Specifies the initial quota debited by the CSG2 from the balance at the beginning of a service when the service is configured for Service Duration Billing.
meter exclude svc-idle meter include imap meter increment meter initial
meter minimum
A-299
Appendix A meter exclude svc-idle
meter exclude svc-idle

To exclude the final service idle from the CSG2 usage calculation, use the meter exclude svc-idle command in CSG2 service configuration mode. To return to the default behavior, use the no form of the command. meter exclude svc-idle no meter exclude svc-idle
Syntax Description
Command Default
The default behavior is to include the service-idle in the usage calculation.
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
Configuration of this command can result in reduced charging because the next service access occurs after the service idles, rather than occurring before the service idles. You cannot configure both meter exclude svc-idle and basis byte or basis fixed in the same service. Only basis second is meaningful with meter exclude svc-idle. The meter exclude svc-idle command and the qct command in CSG2 service configuration mode are mutually exclusive. If you configure the meter exclude svc-idle command, do not configure the qct command.
Examples
The following example shows how to exclude the final service idle from the usage calculation for the OFF_NET service:
ip csg service OFF_NET meter exclude svc-idle
Related Commands
Command ip csg service meter exclude control sip
Description Configures a CSG2 content billing service, and enters CSG2 service configuration mode. Excludes call control packets for a Session Initiation Protocol (SIP) session from the CSG2 usage calculation.
A-300
OL-22840-05
Appendix A
CSG2 Command Reference meter exclude svc-idle
Command meter exclude mms wap meter exclude network-init sip
Description Excludes bytes for a WAP 1.x Multimedia Messaging Service (MMS) session from the CSG2 usage calculation. Excludes incoming Session Initiation Protocol (SIP) transactions (that is, those that are initiated from the network) from the CSG2 usage calculation. Excludes the Real Time Streaming Protocol (RTSP) PAUSE time from the CSG2 usage calculation. Specifies which Internet Message Access Protocol (IMAP) bytes are billed for by the CSG2 when doing prepaid debits. Specifies the increments for debiting quota by the CSG2 upon completion of a service configured for Service Duration Billing. Specifies the initial quota debited by the CSG2 from the balance at the beginning of a service when the service is configured for Service Duration Billing. Specifies the initial quota debited by the CSG2 from the balance at the beginning of a service when the service is configured for Service Duration Billing.
meter exclude pause rtsp meter include imap meter increment meter initial
meter minimum
A-301
Appendix A meter include imap
meter include imap

To specify which Internet Message Access Protocol (IMAP) bytes are billed for by the CSG2 when doing prepaid debits, use the meter include imap command in CSG2 service configuration mode. To return to the default behavior, use the no form of the command. meter include imap body {header | only | other} no meter include imap
Syntax Description
body header body only body other
Only BODY and HEADER IMAP bytes are to be counted when performing prepaid debits. Only BODY IMAP bytes are to be counted when performing prepaid debits. Only BODY and OTHER IMAP bytes are to be counted when performing prepaid debits.
Command Default
All IMAP bytes are to be counted when performing prepaid debits.
Command Modes
Command History
Release 12.4(11)MD

The name of this command changed from meter imap to meter include imap. The body-header, body-only, and body-other keywords changed to body header, body only, and body other, respectively.
Usage Guidelines
You can configure only one meter include imap command per service. The billing basis for the service must be byte. The three categories of bytes are BODY, HEADER, and OTHER, determined as follows:
BODYThe bytes are classified as BODY if a fetch request or response is encountered for one of the following specifications (including any appended <> subset variants):
BODY[] BODY[#] BODY[TEXT] BODY[#.TEXT] BODY.PEEK[] BODY.PEEK[#] BODY.PEEK[TEXT]
A-302
OL-22840-05
Appendix A
CSG2 Command Reference meter include imap
BODY.PEEK[#.TEXT] RFC822 RFC822.TEXT
HEADERIf the bytes cannot be classified as BODY, then they are classified as HEADER if a fetch request or response is encountered for one of the following specifications (including any appended <> subset variants):
BODY[HEADER] BODY[#.HEADER] BODY.PEEK[HEADER] BODY.PEEK[#.HEADER] RFC822.HEADER
OTHERIf request or response cannot be classified as BODY or HEADER, then it is classified as OTHER. OTHER examples include:
SYN/FIN/ACK/RST packets that do not contain a payload Non-HEADER or BODY IMAP commands such as 3 select inbox Retransmitted packets Anything else that is not considered BODY or HEADER If the session becomes encrypted or enters PASSTHRU mode, subsequent packets for the
session cannot be parsed and are treated as OTHER. Because IMAP metering is byte-based, you cannot configure both meter include imap and basis fixed or basis second in the same service. Only basis byte is meaningful with meter include imap.
Examples
The following example shows how to configure IMAP to count only BODY bytes when performing prepaid debits:
ip csg service S1 meter include imap body only
Related Commands
Command ip csg service meter exclude control sip meter exclude mms wap meter exclude network-init sip
Description Configures a CSG2 content billing service, and enters CSG2 service configuration mode. Excludes call control packets for a Session Initiation Protocol (SIP) session from the CSG2 usage calculation. Excludes bytes for a WAP 1.x Multimedia Messaging Service (MMS) session from the CSG2 usage calculation. Excludes incoming Session Initiation Protocol (SIP) transactions (that is, those that are initiated from the network) from the CSG2 usage calculation. Excludes the Real Time Streaming Protocol (RTSP) PAUSE time from the CSG2 usage calculation. Excludes the final service idle from the CSG2 usage calculation.
meter exclude pause rtsp meter exclude svc-idle
A-303
Appendix A meter include imap
Command meter increment meter initial
Description Specifies the increments for debiting quota by the CSG2 upon completion of a service configured for Service Duration Billing. Specifies the initial quota debited by the CSG2 from the balance at the beginning of a service when the service is configured for Service Duration Billing. Specifies the initial quota debited by the CSG2 from the balance at the beginning of a service when the service is configured for Service Duration Billing.
meter minimum
A-304
OL-22840-05
Appendix A
CSG2 Command Reference meter increment
meter increment
To specify the increments for debiting quota by the CSG2 upon completion of a service configured for Service Duration Billing, use the meter increment command in CSG2 service configuration mode. To restore the default behavior, use the no form of the command. meter increment value no meter increment value
Syntax Description
value
Increment, in seconds, for debiting quota upon completion of a service configured for Service Duration Billing. For example, to enable the CSG2 to charge quota per minute instead of per second, specify meter increment 60. The range is from 1 to 65535. The default value is 1.
Command Default
The default increment is 1 second.
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
If basis second is configured for the service, the network usage (usage excluding the initial charge) is rounded up to the nearest integer multiple of the increment value when the Service Stop is sent. For an increment value of 60, the CSG2 does not round up 120 seconds of network usage; however, the CSG2 does round up, say, 163 seconds of network usage to 180 quadrans before it calculates total usage for reporting in the Service Stop.
Note
The increment value is considered when determining whether sufficient quota exists for granting network access for a session. For instance, if the increment is 60, the network usage is 50, and the balance is 10, network access is permitted. However, if the increment is 60, the network usage is 70, and the balance is 10, network access is not permitted because the balance is not sufficient to satisfy the entire increment (that is, a minimum of 1 minute of quota would be required to allow access for a portion of the minute). The meter increment command and the qct command in CSG2 service configuration mode are mutually exclusive. If you configure the meter increment command, do not configure the qct command.
A-305
Appendix A meter increment
Examples
The following example shows how to configure quota debit increments for Service Duration Billing for the OFF_NET service.
ip csg service OFF_NET meter increment 100
Related Commands
Description Configures a CSG2 content billing service, and enters CSG2 service configuration mode. Excludes call control packets for a Session Initiation Protocol (SIP) session from the CSG2 usage calculation. Excludes bytes for a WAP 1.x Multimedia Messaging Service (MMS) session from the CSG2 usage calculation. Excludes incoming Session Initiation Protocol (SIP) transactions (that is, those that are initiated from the network) from the CSG2 usage calculation. Excludes the Real Time Streaming Protocol (RTSP) PAUSE time from the CSG2 usage calculation. Excludes the final service idle from the CSG2 usage calculation. Specifies which Internet Message Access Protocol (IMAP) bytes are billed for by the CSG2 when doing prepaid debits. Specifies the initial quota debited by the CSG2 from the balance at the beginning of a service when the service is configured for Service Duration Billing. Specifies the initial quota debited by the CSG2 from the balance at the beginning of a service when the service is configured for Service Duration Billing.
meter exclude pause rtsp meter exclude svc-idle meter include imap meter initial
meter minimum
A-306
OL-22840-05
Appendix A
CSG2 Command Reference meter initial
meter initial
To specify the initial quota debited by the CSG2 from the balance at the beginning of a service when the service is configured for Service Duration Billing, use the meter initial command in CSG2 service configuration mode. To restore the default behavior, use the no form of the command. meter initial value no meter initial value
Syntax Description
value
Initial quota, in quadrans, debited from the balance at the beginning of a service when the service is configured for Service Duration Billing. The debit occurs when the CSG2 grants the first network access for a session that has been mapped to the service. The initial value is not rounded up to the nearest increment value. The range is from 0 to 65535. The default value is 0.
Command Default
The default quota is 0 quadrans.
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
This command allows connection setup charges to be applied to a service. The debit occurs when the CSG2 grants the first access for the service. The initial value is not rounded up to the nearest increment value.
Examples
The following example shows how to configure an initial quota debit for the OFF_NET service.
ip csg service OFF_NET meter initial 60
Related Commands
Command ip csg service meter exclude control sip
Description Configures a CSG2 content billing service, and enters CSG2 service configuration mode. Excludes call control packets for a Session Initiation Protocol (SIP) session from the CSG2 usage calculation.
A-307
Appendix A meter initial
Command meter exclude mms wap meter exclude network-init sip
Description Excludes bytes for a WAP 1.x Multimedia Messaging Service (MMS) session from the CSG2 usage calculation. Excludes incoming Session Initiation Protocol (SIP) transactions (that is, those that are initiated from the network) from the CSG2 usage calculation. Excludes the Real Time Streaming Protocol (RTSP) PAUSE time from the CSG2 usage calculation. Excludes the final service idle from the CSG2 usage calculation. Specifies which Internet Message Access Protocol (IMAP) bytes are billed for by the CSG2 when doing prepaid debits. Specifies the increments for debiting quota by the CSG2 upon completion of a service configured for Service Duration Billing. Specifies the initial quota debited by the CSG2 from the balance at the beginning of a service when the service is configured for Service Duration Billing.
meter exclude pause rtsp meter exclude svc-idle meter include imap meter increment meter minimum
A-308
OL-22840-05
Appendix A
CSG2 Command Reference meter minimum
meter minimum
To specify the minimum number of quadrans debited by the CSG2 for a service or session, use the meter minimum command in CSG2 service configuration mode. To return to the default behavior, use the no form of the command. meter minimum value no meter minimum value
Syntax Description
value
Minimum number of quadrans debited for a service or session, excluding the value in meter initial. For example, to force the CSG2 to debit 90 quadrans when less than 90 quadrans of network usage were used for the service, specify meter minimum 90. If the initial value is 20 quadrans and the minimum is 90 quadrans, then the minimum total charge is 110 quadrans. The minimum value is applied only if at least 1 session is granted network access for the service. The range is from 0 to 65535. The default value is 0.
Command Default
The default number is 0 quadrans.
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
If meter initial is set to 20 quadrans, and meter minimum is set to 90 quadrans, then the minimum total charge is 110 quadrans. If service duration is configured in the basis command, the usage is rounded up to the minimum value when the Service Stop is sent. For a minimum value of 90, 150 seconds of network usage is not rounded up for the purpose of calculating usage in the Service Stop, but, for example, 63 seconds of network usage is rounded up to 90 quadrans.
Note
A-309
Appendix A meter minimum
Examples
The following example shows how to configure a minimum debit for the OFF_NET service.
ip csg service OFF_NET meter minimum 60
Related Commands
Description Configures a CSG2 content billing service, and enters CSG2 service configuration mode. Excludes call control packets for a Session Initiation Protocol (SIP) session from the CSG2 usage calculation. Excludes bytes for a WAP 1.x Multimedia Messaging Service (MMS) session from the CSG2 usage calculation. Excludes incoming Session Initiation Protocol (SIP) transactions (that is, those that are initiated from the network) from the CSG2 usage calculation. Excludes the Real Time Streaming Protocol (RTSP) PAUSE time from the CSG2 usage calculation. Excludes the final service idle from the CSG2 usage calculation. Specifies which Internet Message Access Protocol (IMAP) bytes are billed for by the CSG2 when doing prepaid debits. Specifies the increments for debiting quota by the CSG2 upon completion of a service configured for Service Duration Billing. Specifies the initial quota debited by the CSG2 from the balance at the beginning of a service when the service is configured for Service Duration Billing.
meter exclude pause rtsp meter exclude svc-idle meter include imap meter increment meter initial
A-310
OL-22840-05
Appendix A
CSG2 Command Reference mining (CSG2 content)
mining (CSG2 content)

To enable domain name mining for the CSG2 content, use the mining command in CSG2 content configuration mode. To disable domain name mining, use the no form of the command. mining no mining
Syntax Description
Command Default
The CSG2 does not build a DNS IP Map Table.
Command Modes
Command History
Release 12.4(24)MD
Usage Guidelines
You must enable domain name mining for one or more contents in order for the CSG2 to add IP address-to-domain group mapping entries to the CSG2 Domain Name System (DNS) IP Map Table. The mining command is valid only if the parse protocol dns command is also specified for the content. The CSG2 creates the DNS IP Map Table only if all of the following conditions are met:

The ip csg domain mining command must be configured in global configuration mode. This command enables global domain mining for the CSG2. The mining command must be configured for the DNS content. (Do not configure the mining command for a virtual content.) DNS transactions must hit the content.
When these conditions are met, the CSG2 creates the DNS IP Map Table and begins adding domain name IP addresses to the table.
Examples
The following example shows how to configure a minimum debit for content DNS-CONTENT:
ip csg content DNS-CONTENT mining
Related Commands
A-311
Appendix A mining (CSG2 content)
Command ip csg domain mining parse protocol (CSG2 content)
Description Enables global domain mining for the CSG2. Defines how the CSG2 is to parse traffic for a content.
A-312
OL-22840-05
Appendix A
CSG2 Command Reference mode
mode
To specify the mode for a CSG2 billing plan, use the mode command in CSG2 billing configuration mode. To use the default mode, use the no form of this command. mode {postpaid | prepaid [virtual]} no mode
Syntax Description
postpaid prepaid virtual
(Optional) Specifies a postpaid billing plan. (Optional) Specifies a prepaid billing plan. This is the default setting. (Optional) Specifies a virtual prepaid billing plan.
Command Default
The default mode is prepaid.
Command Modes
Command History
Release 12.4(11)MD 12.4(22)MDA
Modification This command was migrated from CSG1. Changes from CSG1: None. The virtual keyword was added.
Usage Guidelines
The mode command with the postpaid keyword is used with both fixed-record format and variable-record format to enable service correlation of postpaid CDRs.
Examples
The following example specifies postpaid mode for CSG2 billing plan REGULAR:
ip csg billing REGULAR mode postpaid
The following example specifies virtual prepaid mode for CSG2 billing plan VPLAN:
ip csg billing VPLAN mode prepaid virtual
Related Commands
Command class (CSG2 service) entries user idle ip csg billing
Description Specifies a service class value. Sets the time after which entries for idle subscribers are deleted from the CSG2 User Table. Defines a CSG2 billing plan, and enters CSG2 billing configuration mode.
A-313
Appendix A mode
Command ip csg records format ip csg transport-type assign owner (CSG2 service) qos profile (CSG2 billing) service user-default
Description Specifies variable or fixed call detail record (CDR) format. Classifies data traffic on the basis of its access path. Specifies an identifier or name for a service owner. Associates a Quality of Service (QoS) profile with a CSG2 billing plan. Associates a service with a CSG2 billing plan. Designates a CSG2 billing plan as the default billing plan.
A-314
OL-22840-05
Appendix A
CSG2 Command Reference mode tcp
mode tcp
To specify the mode for CSG2 TCP sessions, use the mode tcp command in CSG2 content configuration mode. To use the default mode, use the no form of this command. mode tcp {datagram | transparent [zero]} no mode tcp
Syntax Description
datagram transparent zero
Specifies that the CSG2 is to treat TCP sessions as datagrams. Specifies that the CSG2 is to treat TCP sessions as transparent. (Optional) Specifies that TCP bytes are not to be reported for transparent TCP sessions.
Command Default
If you do not configure this command, the CSG2 treats TCP sessions as transparent, forwarding all TCP packets, including out-of-order packets, and reporting all new and retransmitted TCP payload bytes.
Command Modes
Command History
Release 12.4(11)MD6
Usage Guidelines
The mode tcp command is valid only if the parse protocol other command is also specified for the content. If you configure the mode tcp transparent command, the CSG2 forwards all TCP packets, including out-of-order packets, and reports all new and retransmitted TCP payload bytes. If you also configure the optional zero keyword, the CSG2 reports zero TCP bytes. The CSG2 uses TCP signals to establish and terminate the TCP sessions. If you configure the mode tcp datagram command, the CSG2 forwards all TCP packets, including out-of-order packets, and reports zero TCP payload bytes. Each TCP session is established by the first SYN, and terminated by the content's idle timer.
Examples
The following example specifies transparent mode for TCP sessions for CSG2 content VPN:
ip csg content VPN ip any tcp 10000 mode tcp transparent
Related Commands
A-315
Appendix A mpcc destination-realm
mpcc destination-realm
To specify a global destination realm to be sent by Mobile PCC in initial CCRs to the PCRF, use the mpcc destination-realm command in global configuration mode. To delete the destination realm, use the no form of this command. mpcc destination-realm destination-realm-string no mpcc destination-realm destination-realm-string
Syntax Description
destination-realm-string
Global destination realm to be sent by Mobile Policy Control & Charging (PCC) in initial policy preload requests (CCRs) to the Policy and Charging Rule Function (PCRF). For subsequent CCRs, Mobile PCC uses the Origin-Realm Attribute Value Pair (AVP) received in the last policy preload response (CCA) as the destination realm.
Command Default
No destination realm is defined.
Command Modes
Command History
Release 12.4(22)MDA
Usage Guidelines
If the realm destination command is not configured for a Mobile PCC profile, then the global destination realm, configured with the mpcc destination-realm command, is used.
Examples
The following example shows how to specify cisco.com as the global destination realm:
mpcc destination-realm cisco.com
Related Commands
Command mpcc profile
Description Defines a Mobile PCC profile to be used to send per-user requests to the Policy and Charging Rule Function (PCRF), and enters Mobile PCC profile configuration mode. Defines a method list to be used by Mobile Policy Control & Charging (PCC) for requests to Policy and Charging Rule Function (PCRF) for policy preloading. Specifies the destination realm to be sent by Mobile Policy Control & Charging (PCC) in initial CCRs to the PCRF.
pcrf policy-if
realm destination
A-316
OL-22840-05
Appendix A
CSG2 Command Reference mpcc include avp destination-host
mpcc include avp destination-host

To include the destination hosts Gx Attribute Value Pair (AVP) in Mobile PCC policy authorization update requests, use the mpcc include avp destination-host command in global configuration mode. To restore the default setting, use the no form of this command. mpcc include avp destination-host no mpcc include avp destination-host
Syntax Description
Command Default
The destination hosts Gx AVP is not included in Mobile Policy Control & Charging (PCC) policy authorization update requests.
Command Modes
Command History
Release 12.4(22)MDA
Usage Guidelines
Use this command to include the destination hosts Gx AVP in Credit Control Request-Update (CCR-U) requests after a PCRF failover, if the new server has a different destination host.
Examples
The following example shows how to include the destination hosts Gx AVP in Mobile PCC policy authorization update requests:
mpcc include avp destination-host
A-317
Appendix A mpcc preload
mpcc preload
To enable policy preloading for Mobile Policy Control & Charging (PCC), use the mpcc preload command in global configuration mode. To disable policy preloading, use the no form of this command. mpcc preload no mpcc preload
Syntax Description
Command Default
Policy preloading is disabled.
Command Modes
Command History
Release 12.4(22)MDA
Examples
The following example shows how to enable policy preloading on the Mobile PCC:
mpcc preload
Related Commands
Command mpcc preload policy-if
Description Defines a global method list to be used by Mobile Policy Control & Charging (PCC) for requests to Policy and Charging Rule Function (PCRF) for policy preloading. Defines a timeout to be used by Mobile Policy Control & Charging (PCC) for policy preloading.
mpcc preload timeout
A-318
OL-22840-05
Appendix A
CSG2 Command Reference mpcc preload policy-if
mpcc preload policy-if

To define a global method list to be used by Mobile Policy Control & Charging (PCC) for requests to Policy and Charging Rule Function (PCRF) for policy preloading, use the mpcc preload policy-if command in global configuration mode. To delete the method list, use the no form of this command. mpcc preload policy-if aaa-method-list no mpcc preload policy-if aaa-method-list
Syntax Description
aaa-method-list
Global authentication, authorization, and accounting (AAA) method list that points to the PCRF IP address through the AAA server group configuration. The method list name can be from 1 to 32 characters long, and can include uppercase or lowercase letters (The CSG2 changes all letters to uppercase), numbers, and any special characters.
Command Default
No global method list is defined.
Command Modes
Command History
Release 12.4(22)MDA
Usage Guidelines
If the pcrf preload policy-if command is not configured, the global method list, configured with the mpcc preload policy-if command, is used for policy preloading.
Examples
The following example shows how to define method list preload-method-list:

mpcc preload policy-if preload-method-list
Related Commands
Command mpcc preload mpcc preload timeout pcrf policy-if
Description Enables policy preloading for Mobile Policy Control & Charging (PCC). Defines a timeout to be used by Mobile Policy Control & Charging (PCC) for policy preloading. Defines a method list to be used by Mobile Policy Control & Charging (PCC) for requests to Policy and Charging Rule Function (PCRF) for policy preloading.
A-319
Appendix A mpcc preload timeout
mpcc preload timeout

To define a timeout to be used by Mobile Policy Control & Charging (PCC) for policy preloading, use the mpcc preload timeout command in global configuration mode. To restore the default setting, use the no form of this command. mpcc preload timeout duration no mpcc preload timeout
Syntax Description
duration
Time, in seconds, during which policy preloading can take place. The range is 60 seconds (1 minute) to 7200 seconds (2 hours). The default is 1800 seconds (30 minutes).
Command Default
The default timeout is 1800 seconds (30 minutes).
Command Modes
Command History
Release 12.4(22)MDA
Usage Guidelines
The policy preload timer starts when preloading begins and stops when preloading is complete or when the timer expires, whichever occurs first.
Examples
The following example shows how to define a policy preload timeout of 3600 seconds (1 hour):
mpcc preload timeout 3600
Related Commands
Command mpcc preload mpcc preload policy-if
Description Enables policy preloading for Mobile Policy Control & Charging (PCC). Defines a global method list to be used by Mobile Policy Control & Charging (PCC) for requests to Policy and Charging Rule Function (PCRF) for policy preloading.
A-320
OL-22840-05
Appendix A
CSG2 Command Reference mpcc profile
mpcc profile
To define a Mobile Policy Control & Charging (PCC) profile to be used to send per-user requests to the Policy and Charging Rule Function (PCRF), and to enter Mobile PCC profile configuration mode, use the mpcc profile command in global configuration mode. To delete the Mobile PCC profile, use the no form of this command. mpcc profile profile-name [any] no mpcc profile profile-name
Syntax Description
profile-name
Name of the Mobile PCC profile. The profile name can be from 1 to 16 characters long, and can include uppercase or lowercase letters (The CSG2 changes all letters to uppercase), numbers, and any special characters.
any
(Optional) Specifies that the Mobile PCC profile is to be used as the default profile. The Mobile PCC uses the default profile if the application gateway does not specify a profile. If there is already a default profile configured, and you configure a new default profile, the new one overrides the old one.
Command Default
No Mobile PCC profile is defined.
Command Modes
Command History
Release 12.4(22)MDA
Usage Guidelines
A Mobile PCC profile is a group of authentication, authorization, and accounting (AAA) method lists. The Mobile PCC load-balances Gx requests to the PCRF across these method lists. You can associate up to 16 method lists with a given Mobile PCC profile.
Examples
The following example shows how to define Mobile PCC profile mpcc-profile1:
mpcc profile mpcc-profile1
A-321
Appendix A mpcc profile
Related Commands
Command mpcc destination-realm pcrf policy-if
Description Specifies a global destination realm to be sent by Mobile PCC in initial CCRs to the PCRF. Defines a method list to be used by Mobile Policy Control & Charging (PCC) for requests to Policy and Charging Rule Function (PCRF) for policy preloading. Specifies the destination realm to be sent by Mobile PCC in initial CCRs to the PCRF.
realm destination
A-322
OL-22840-05
Appendix A
CSG2 Command Reference name (CSG2 header)
name (CSG2 header)

To specify a name for a CSG2 header, use the name command in CSG2 header configuration mode. To remove the name, use the no form of this command. name name no name
Syntax Description
name
Name of the CSG2 header to be inserted into HTTP requests. The name can be from 1 to 40 bytes long, and can include uppercase or lowercase letters, numbers, and any special characters. The name is case-sensitive.
Command Default
None.
Command Modes
Command History
Release 12.4(24)MD
Usage Guidelines
This command is required when defining a CSG2 header. When the CSG2 inserts the name into an HTTP header, it appends a colon (:) and a space to the name. For example, the name X-HEADER is inserted as X-HEADER: . When the CSG2 inserts a header for which no name is configured, the CSG2 uses the name of the header defined on the ip csg header command. When you activate the inservice command in CSG2 service configuration mode, CSG2 verifies that all headers configured for this service (via header-groups) are configured with valid name and class commands. If CSG2 detects an error, the command fails.
Examples
The following example shows how to specify X-HEADER as the name of a CSG2 header:
name X-HEADER
Related Commands
A-323
Appendix A name (iSCSI)
name (iSCSI)
To specify the name of an iSCSI target in the target profile on the CSG2, use the name command in iSCSI configuration mode. To remove the IP address configuration, use the no form of the command. name target-name no name target-name
Syntax Description
target-name
Name of the iSCSI target.
Command Default
Command Modes
iSCSI configuration
Command History
Release 12.4(15)MD
Examples
The following example configures an iSCSI target interface profile with the name targetA to a SCSI target named iqn.2002-10.edu.abc.iol.iscsi.draft20-target:1 :
Related Commands
Description Specifies the IP address of an iSCSI target in the target interface profile on the CSG2. Defines the delay interval, in seconds, before draining packets from the Storage Area Network (SAN) connected to the Internet Small Computer Systems Interface (iSCSI) when the Billing Mediation Agent (BMA) becomes active. Defines the number of packets to be drained from the Storage Area Network (SAN) connected to the Internet Small Computer Systems Interface (iSCSI) per drain delay interval when the Billing Mediation Agent (BMA) becomes active. Specifies the Internet Small Computer Systems Interface (iSCSI) target to be used as backup storage for the CSG2.
ip csg iscsi profile
A-324
OL-22840-05
Appendix A
CSG2 Command Reference name (iSCSI)
Command ip iscsi target-profile port (iSCSI) session-timeout (iSCSI) target-portal (iSCSI)
Description Creates an iSCSI profile for an iSCSI target on the CSG2, and enters iSCSI configuration mode. Specifies the number of the port on which to listen for iSCSI traffic in the iSCSI target interface profile on the CSG2. Specifies the session timeout for an iSCSI target in the target interface profile on the CSG2. Specifies the portal group tag for an iSCSI target in the target interface profile on the CSG2.
A-325
Appendix A next-hop (CSG2 content)
next-hop (CSG2 content)

To define a next-hop IPv4 or IPv6 address, use the next-hop command in CSG2 content configuration mode. To delete the next-hop IPv4 or IPv6 address, use the no form of this command. next-hop {ipv4-address | ipv6 ipv6-address} [reverse | subscriber [media]] no next-hop {ipv4-address | ipv6 ipv6-address} [reverse | subscriber [media]]
Syntax Description
ipv4-address ipv6 ipv6-address reverse subscriber media
IPv4 address of the next hop for packets sourced by the flow initiator. IPv6 address of the next hop for packets sourced by the flow initiator. (Optional) Specifies that the IP address of the next hop is for packets sent to the flow initiator. (Optional) Specifies that the IP address of the next hop is for all packets sent from the subscriber. (Optional) Specifies that the IP address of the next hop is for packets sent from the subscriber for Session Initiation Protocol (SIP) media.
Command Default
None
Command Modes
Command History
Release 12.4(11)MD

The configuration mode for this command changed from CSG policy configuration to CSG2 content configuration. The reverse keyword was added.
12.4(15)MD 12.4(24)MDA
The subscriber and media keywords were added. The ipv6 keyword and ipv6-address argument were added.
Usage Guidelines
You can configure up to one of each of the next-hop IPv4 or IPv6 addresses (forward, reverse, subscriber, and subscriber-media). Subscriber sessions use the subscriber next-hop IPv4 or IPv6 address, if configured. Otherwise, subscriber sessions use the forward and reverse next-hop IPv4 or IPv6 addresses, if configured. SIP media sessions use the subscriber-media next-hop IPv4 or IPv6 address, if configured. Otherwise, SIP media sessions use the forward and reverse next-hop IPv4 or IPv6 addresses, if configured.
Note
Even if you have defined a next-hop IPv4 or IPv6 address, traffic that matches the default content might not be routed with next-hop.
A-326
OL-22840-05
Appendix A
CSG2 Command Reference next-hop (CSG2 content)
Examples
The following example specifies next-hop for CSG2 content MOVIES:

ip csg content MOVIES next-hop 1.2.3.4 next-hop 9.8.7.6 reverse next-hop 2.3.4.5 subscriber media next-hop ipv6 12AB:0000:0000:CD30:0000:0000:0000:0000
Related Commands
Command client-group (CSG2 content) ip csg content ipv6 (CSG2 content)
Description References a standard access list that is part of a CSG2 content. Configures content for CSG2 services, and enters CSG2 content configuration mode. Defines the subset of Layer 3 and Layer 4 flows that can be processed by the CSG2 accounting services using IPv6 addressing. Changes the order in which the CSG2 selects the next-hop IPv4 or IPv6 address.
next-hop override (CSG2 content)
A-327
Appendix A next-hop override (CSG2 content)
next-hop override (CSG2 content)

To change the order in which the CSG2 selects the next-hop IPv4 or IPv6 address, use the next-hop override command in CSG2 content configuration mode. To restore the default order, use the no form of this command. next-hop override no next-hop override
Syntax Description
Command Default
The CSG2 selects the next-hop IPv4 or IPv6 address in the default order.
Command Modes
Command History
Release 12.4(22)MD
Usage Guidelines
By default, when routing traffic the CSG2 selects the next-hop IPv4 or IPv6 address in the following order:
1. 2. 3. 4.
The next-hop subscriber media IP address, if configured The next-hop subscriber IP address, if configured The next-hop IP address. (if the subscriber initiated the connection) or the next-hop reverse IP address (if the subscriber did not initiate the connection), if configured The per-user uplink next-hop IP address, as specified in one of the following messages:
A RADIUS Access-Accept message A RADIUS Accounting-Start message A Gx Attribute Value Pair (AVP) in a Credit Control Request (CCR) message A Gx AVP in a Credit Control Answer (CCA) message
5.
The destination IP address of the user packet from the subscriber
However, if you want the CSG2 to give priority to per-user uplink next-hop IP addresses, you can use this command to enable the CSG2 to select the next-hop IP address in the following order:
1. 2. 3. 4. 5.
The per-user uplink next-hop IP address The next-hop subscriber media IP address The next-hop subscriber IP address The next-hop or next-hop reverse IP address The destination IP address of the user packet from the subscriber
A-328
OL-22840-05
Appendix A
CSG2 Command Reference next-hop override (CSG2 content)
Examples
The following example specifies next-hop override for CSG2 content MOVIES:
ip csg content MOVIES next-hop 1.2.3.4 next-hop 9.8.7.6 reverse Next-hop 2.3.4.5 subscriber media next-hop override
Related Commands
Command client-group (CSG2 content) ip csg content next-hop (CSG2 content)
Description References a standard access list that is part of a CSG2 content. Configures content for CSG2 services, and enters CSG2 content configuration mode. Defines a next-hop IPv4 or IPv6 address.
A-329
Appendix A normalize-url
normalize-url
To enable URL map normalization for a CSG2 content, use the normalize-url command in CSG2 content configuration mode. To disable URL map normalization for a content, use the no form of this command. normalize-url no normalize-url
Syntax Description
Command Default
URL map normalization is enabled.
Command Modes
Command History
Usage Guidelines
The CSG2 uses URL map normalization to determine whether two URLs with different syntaxes are equivalent. The CSG2 does this by modifying the supplied URLs, removing the dot-segments . and . . prior to running the URLs through the regex engine. For example, the CSG2 normalizes the following URL: http://www.somehost.com/. ./img/somehost.jpg to this: http://img/somehost.jpg However, there might be situations in which you do not want the CSG2 to normalize URLs. In such cases, you can disable URL map normalization, enabling the CSG2 to search explicitly for the dot-segments in URL map search strings. For example, when URL map normalization is disabled, the CSG2 treats this: http://www.somehost.com/. ./img/somehost.jpg and this: http://img/somehost.jpg as two different, unique URLs when performing URL map searches.
Examples
The following example shows how to disable URL map normalization for CSG2 content MOVIES_COMEDY:
ip csg content MOVIES_COMEDY no normalize-url
A-330
OL-22840-05
Appendix A
CSG2 Command Reference normalize-url
Related Commands
Command ip csg content ip csg map map (CSG2 policy) match url (CSG2 map)
Description Configures content for CSG2 services, and enters CSG2 content configuration mode. Defines the CSG2 billing content filters (attribute, header, method, and URL maps), and enters CSG2 map configuration mode. References an attribute, header, method, or URL map that is part of a CSG2 billing policy. Specifies a URL match pattern for a CSG2 billing map.
A-331
Appendix A offline
offline
To enable offline billing for a CSG2 billing plan, use the offline command in CSG2 billing configuration mode. To disable offline billing for the plan, use the no form of this command. offline no offline
Syntax Description
Command Default
Offline billing is enabled.
Command Modes
Command History
Release 12.4(22)MDA
Usage Guidelines
Offline billing enables the CSG2 to send CDRs to the BMA. By default, offline billing is enabled. If offline billing is disabled, the CSG2 does not send CDRs to the BMA. The enabling and disabling of offline billing is also supported for preloaded billing plans.
Examples
The following example shows how to disable offline billing for CSG2 billing plan REGULAR:
ip csg billing REGULAR no offline
Related Commands
Command ip csg billing
Description Configures a CSG2 billing plan, and to enter CSG2 billing configuration mode.
A-332
OL-22840-05
Appendix A
CSG2 Command Reference owner (CSG2 service)
owner (CSG2 service)

To specify an identifier or name for a CSG2 service owner, use the owner command in CSG2 service configuration mode. To remove the owner ID or name, use the no form of this command. owner {id id | name name} no owner {id | name}
Syntax Description
id id name name
1- to 15-character string that identifies a service owner. 1- to 38-character string that specifies the name of the service.
Command Default
None
Command Modes
Command History
Release 12.4(11)MD

owner id owner name
Usage Guidelines
Use this command with fixed-record format to identify a service owner.
Examples
The following example specifies an owner ID for the CSG2 service A1:
ip csg service A1 owner id ABC123456
Related Commands
Command class (CSG2 service) ip csg service ip csg transport-type assign mode ip csg records format
Description Specifies a service class value. Configures a CSG2 content billing service, and enters CSG2 service configuration mode. Classifies data traffic on the basis of its access path. Specifies the mode for a CSG2 billing plan. Specifies variable or fixed CDR format.
A-333
Appendix A parse length (CSG2 content)
parse length (CSG2 content)

To define the maximum number of Layer 7 bytes that the CSG2 is to parse when attempting to assign a policy, use the parse length command in CSG2 content configuration mode. To restore the default setting, use the no form of this command. parse length number no parse length
Syntax Description
number
Maximum number of Layer 7 bytes to parse. The range is from 1 to 65535. The default value is 4000.
Command Default
The CSG2 parses up to 4000 Layer 7 bytes when attempting to assign a policy.
Command Modes
Command History
Release 12.4(11)MD 12.4(22)MD
Modification This command was introduced. Support for NBAR was added.
Usage Guidelines
If the parse length is exceeded, the CSG2 blocks or forwards packets on the basis of the block command. NBAR uses this command to determine how many bytes of a given session to parse when attempting to identify the sessions protocol. If the length is exceeded, NBAR could not identify the protocol, and the CSG2 might not assign a protocol to the session. If you specified an instant messaging protocol on the match protocol command in class map configuration mode, we recommend that you configure a parse length of at least 10000. This command is valid only if parse protocol http or parse protocol nbar is also configured.
Examples
The following example specifies that the CSG2 is to parse up to 1234 Layer 7 bytes when attempting to assign a policy:
ip csg content MOVIES parse protocol http parse length 1234
A-334
OL-22840-05
Appendix A
CSG2 Command Reference parse length (CSG2 content)
Related Commands
Command block ip csg content parse protocol (CSG2 content)
Description Forces the CSG2 to drop packets that do not match a configured billing policy. Configures content for CSG2 services, and enters CSG2 content configuration mode. Defines how the CSG2 is to parse traffic for a content.
A-335
Appendix A parse protocol (CSG2 content)
parse protocol (CSG2 content)

To define how the CSG2 is to parse traffic for a content, use the parse protocol command in CSG2 content configuration mode. To restore the default setting, use the no form of this command. parse protocol {dns | ftp | http [insert] | imap | nbar | other | pop3 | rtsp | sip | smtp | wap {connection-oriented | connectionless}} no parse protocol
Syntax Description
dns ftp http insert imap nbar other pop3 rtsp sip smtp wap connection-oriented connectionless
Domain Name System (DNS) protocol traffic. FTP traffic, with Layer 7 inspection of FTP control sessions. HTTP traffic. (Optional) Traffic is subject to HTTP header insertion. This keyword is supported for legacy configurations only. Internet Message Access Protocol (IMAP) traffic. Network Based Application Recognition (NBAR) traffic. Some other type of IP traffic, such as IP, TCP, or User Datagram Protocol (UDP). This is the default setting. Post Office Protocol, version 3 (POP3) traffic. Real Time Streaming Protocol (RTSP) traffic. Session Initiation Protocol (SIP) traffic. Simple Mail Transfer Protocol (SMTP) traffic. Wireless application protocol (WAP) traffic. Defines the WAP traffic as connection-oriented. Defines the WAP traffic as connectionless.
Command Default
The CSG2 parses the traffic as some other type of IP traffic, such as IP, TCP, or User Datagram Protocol (UDP).
Command Modes
Command History
Release 12.4(11)MD 12.4(15)MD 12.4(22)MD 12.4(24)MD
Modification This command was introduced. The ftp and sip keywords were added. The nbar keyword was added. The dns and insert keywords were added.
Usage Guidelines
The CSG2 does not allocate resources to the DNS IP Map Table until at least one content configured with parse protocol dns is brought inservice.
A-336
OL-22840-05
Appendix A
CSG2 Command Reference parse protocol (CSG2 content)
The nbar keyword indicates that the traffic is to be parsed by the CSG2 NBAR protocol handler. We recommend that all content that is configured for NBAR processing (parse protocol nbar) also be configured to match all traffic, using the ip any command.
Examples
The following example specifies that the CSG2 is to parse traffic for this content as HTTP traffic:
ip csg content MOVIES parse protocol http
Related Commands
Command ip csg content parse length (CSG2 content) subscriber-ip http-header x-forwarded-for (CSG2 content)
Description Configures content for CSG2 services, and enters CSG2 content configuration mode. Defines the maximum number of Layer 7 bytes that the CSG2 is to parse when attempting to assign a policy. Specifies that the CSG2 is to obtain the subscriber's IP address from the HTTP X-Forwarded-For header.
A-337
Appendix A passthrough
passthrough
To enable passthrough mode for a CSG2 service, use the passthrough command in CSG2 service configuration mode. To disable passthrough mode, use the no form of this command. passthrough quota-grant [dual dual-quota-grant] no passthrough
Syntax Description
quota-grant dual dual-quota-grant
Size of each quota grant to give to the service. The quota-grant is also called the default quota. The range is from 1 to 2147483647. (Optional) Size of each quota grant to give to the service for dual quota. The range is from 1 to 2147483647.
Command Default
None
Command Modes
Command History
Release 12.4(11)MD 12.4(22)MD
Modification This command was migrated from CSG1. Changes from CSG1: None. The dual keyword and dual-quota-grant argument were added.
Usage Guidelines
Use this command to enable the CSG2 to grant quota to the service when at least one quota server is configured, but none are active.
Examples
The following example specifies that the CSG2 grants 65535 quadrans of quota to the service NAME each time the service runs low on quota, and 100000 quadrans for dual basis:
ip csg service NAME passthrough 65535 dual 100000
Related Commands
Command basis ip csg service reauthorization threshold
Description Specifies the billing basis for a CSG2 content billing service. Configures a CSG2 content billing service, and enters CSG2 service configuration mode. Specifies the CSG2 reauthorization threshold.
A-338
OL-22840-05
Appendix A
CSG2 Command Reference pcc gx
pcc gx
To enable Gx for subscribers associated with a CSG2 user profile, use the pcc gx command in CSG2 user profile configuration mode. To disable Gx for the subscriber, use the no form of this command. pcc gx no pcc gx
Syntax Description
Command Default
Gx is not enabled for the subscriber.
Command Modes
CSG2 user profile configuration
Command History
Release 12.4(22)MDA
Usage Guidelines
Configuration of pcc gx determines whether the user associated with a profile is a PCC user. If a RADIUS Accounting Request contains a Cisco VSA that specifies the Gx behavior of the subscriber, the RADIUS-specified behavior overrides the Gx behavior specified by the pcc gx command.
Examples
The following example shows how to enable Gx for subscribers associated with user profile PCRF-PROFILE:
ip csg user profile PCRF-PROFILE pcc gx
Related Commands
Command ip csg pcc gx ip csg select ip csg user profile pcrf failure
Description Enables Gx on the CSG2. Associates a CSG2 user profile with a subscriber. Defines a user profile to be associated with a CSG2 subscriber, and enters CSG2 user profile configuration mode. Defines the actions that the CSG2 is to take for a Policy Control & Charging (PCC) user if the Policy and Charging Rule Function (PCRF) fails when the user session is activated.
A-339
Appendix A pcc gx
Command pcrf profile
Description Defines a Mobile Policy Control & Charging (MPCC) profile to be used by the CSG2 when sending per-user Credit Control Requests (CCRs) to the Policy and Charging Rule Function (PCRF). Defines the actions that the CSG2 is to take for a Policy Control & Charging (PCC) user if the Policy and Charging Rule Function (PCRF) times out.
pcrf timeout
A-340
OL-22840-05
Appendix A
CSG2 Command Reference pcrf failure
pcrf failure
To define the actions that the CSG2 is to take for a Policy Control & Charging (PCC) user if the Policy and Charging Rule Function (PCRF) fails when the user session is activated, use the pcrf failure command in CSG2 user profile configuration mode. To restore the default behavior, use the no form of this command. pcrf failure [continue | terminate] no pcrf failure
Syntax Description
continue terminate
(Optional) Create the CSG2 User Table entry for the PCC user and forward the RADIUS Accounting Start request. (Optional) Do not create the CSG2 User Table entry for the PCC user and do not forward the RADIUS Accounting Start request. This is the default setting.
Command Default
If the PCRF fails, the CSG2 does not create the User Table entry for the PCC user, and it does not forward or acknowledge the RADIUS Accounting Start request.
Command Modes
Command History
Release 12.4(22)MDA
Examples
The following example shows how to enable the CSG2 to create User Table entries for subscribers associated with user profile PCRF-PROFILE, even if the PCRF fails:
ip csg user profile PCRF-PROFILE pcrf failure continue
Related Commands
Command ip csg pcc gx ip csg select ip csg user profile pcc gx pcrf profile
Description Enables Gx on the CSG2. Associates a CSG2 user profile with a subscriber. Defines a user profile to be associated with a CSG2 subscriber, and enters CSG2 user profile configuration mode. Enables Gx for subscribers associated with a CSG2 user profile. Defines a Mobile Policy Control & Charging (MPCC) profile to be used by the CSG2 when sending per-user Credit Control Requests (CCRs) to the Policy and Charging Rule Function (PCRF). Defines the actions that the CSG2 is to take for a Policy Control & Charging (PCC) user if the Policy and Charging Rule Function (PCRF) times out.
pcrf timeout
A-341
Appendix A pcrf policy-if
pcrf policy-if
To define a method list to be used by Mobile Policy Control & Charging (PCC) for requests to Policy and Charging Rule Function (PCRF) for policy preloading, use the pcrf policy-if command in Mobile PCC profile configuration mode. To delete the method list, use the no form of this command. pcrf policy-if method-list-name no pcrf policy-if method-list-name
Syntax Description
method-list-name
Authentication, authorization, and accounting (AAA) method list that points to the PCRF IP address through the AAA server group configuration. The method list name can be from 1 to 32 characters long, and can include uppercase or lowercase letters (The CSG2 changes all letters to uppercase), numbers, and any special characters.
Command Default
No method list is defined.
Command Modes
Mobile PCC profile configuration
Command History
Release 12.4(22)MDA
Usage Guidelines
If the pcrf preload policy-if command is not configured, the global method list, configured with the mpcc preload policy-if command, is used for policy preloading. You can define up to 16 method lists for a given profile.
Examples
The following example shows how to define method list service1_method_list1:

pcrf policy-if service1_method_list1
Related Commands
Command mpcc destination-realm mpcc preload policy-if
Description Specifies a global destination realm to be sent by Mobile PCC in initial CCRs to the PCRF. Defines a global method list to be used by Mobile Policy Control & Charging (PCC) for requests to Policy and Charging Rule Function (PCRF) for policy preloading.
A-342
OL-22840-05
Appendix A
CSG2 Command Reference pcrf policy-if
Command mpcc profile
Description Defines a Mobile Policy Control & Charging (PCC) profile to be used to send per-user requests to the Policy and Charging Rule Function (PCRF), and enters Mobile PCC profile configuration mode. Specifies the destination realm to be sent by Mobile PCC in initial CCRs to the PCRF.
realm destination
A-343
Appendix A pcrf profile
pcrf profile
To define a Mobile Policy Control & Charging (MPCC) profile to be used by the CSG2 when sending per-user Credit Control Requests (CCRs) to the Policy and Charging Rule Function (PCRF), use the pcrf profile command in CSG2 user profile configuration mode. To delete the MPCC profile definition, use the no form of this command. pcrf profile mpcc-profile-name no pcrf profile mpcc-profile-name
Syntax Description
mpcc-profile-name
Name of the MPCC profile that the CSG2 is to use to send per-user CCRs to the PCRF. The MPCC profile name is configured using the mpcc profile command in global configuration mode.
Command Default
The CSG2 uses the default MPCC profile name to send per-user CCRs to the PCRF. The default MPCC profile name is configured using the mpcc profile any command in global configuration mode.
Command Modes
Command History
Release 12.4(22)MDA
Usage Guidelines
The CSG2 uses the MPCC profile when sending Credit Control Request (CCR) messages to the PCRF.
Examples
The following example defines MPCC profile PCC-PROFILE:

ip csg user profile PCRF-PROFILE pcrf profile PCC-PROFILE
Related Commands
Command ip csg pcc gx ip csg select ip csg user profile pcc gx pcrf failure
Description Enables Gx on the CSG2. Associates a CSG2 user profile with a subscriber. Defines a user profile to be associated with a CSG2 subscriber, and enters CSG2 user profile configuration mode. Enables Gx for subscribers associated with a CSG2 user profile. Defines the actions that the CSG2 is to take for a Policy Control & Charging (PCC) user if the Policy and Charging Rule Function (PCRF) fails when the user session is activated. Defines the actions that the CSG2 is to take for a Policy Control & Charging (PCC) user if the Policy and Charging Rule Function (PCRF) times out.
pcrf timeout
A-344
OL-22840-05
Appendix A
CSG2 Command Reference pcrf timeout
pcrf timeout
To define the actions that the CSG2 is to take for a Policy Control & Charging (PCC) user if the Policy and Charging Rule Function (PCRF) times out, use the pcrf failure command in CSG2 user profile configuration mode. To restore the default behavior, use the no form of this command. pcrf timeout [continue | terminate] no pcrf timeout
Syntax Description
continue terminate
(Optional) Create the CSG2 User Table entry for the PCC user and forward the RADIUS Accounting Start request. (Optional) Do not create the CSG2 User Table entry for the PCC user and do not forward the RADIUS Accounting Start request. This is the default setting.
Command Default
If the PCRF times out, the CSG2 does not create the User Table entry for the PCC user, and it does not forward or acknowledge the RADIUS Accounting Start request.
Command Modes
Command History
Examples
The following example shows how to enable the CSG2 to create User Table entries for subscribers associated with user profile PCRF-PROFILE, even if the PCRF times out:
ip csg user profile PCRF-PROFILE pcrf timeout continue
Related Commands
Command ip csg pcc gx ip csg select ip csg user profile pcc gx pcrf failure
Description Enables Gx on the CSG2. Associates a CSG2 user profile with a subscriber. Defines a user profile to be associated with a CSG2 subscriber, and enters CSG2 user profile configuration mode. Enables Gx for subscribers associated with a CSG2 user profile. Defines the actions that the CSG2 is to take for a Policy Control & Charging (PCC) user if the Policy and Charging Rule Function (PCRF) fails when the user session is activated. Defines a Mobile Policy Control & Charging (MPCC) profile to be used by the CSG2 when sending per-user Credit Control Requests (CCRs) to the Policy and Charging Rule Function (PCRF).
pcrf profile
A-345
Appendix A pending (CSG2 content)
pending (CSG2 content)

To set the pending connection timeout, use the pending command in CSG2 content configuration mode. To restore the default, use the no form of this command. pending timeout no pending
Syntax Description
timeout
Time, in seconds, to wait for a response to an initial synchronization sequence number (SYN) on a TCP session. The range is from 4 to 65535. The default value is 30.
Command Default
The default pending connection timeout is 30 seconds.
Command Modes
Command History
Release 12.4(11)MD
Examples
This example shows how to set the pending connection timer for a CSG2 content:
ip csg content MOVIES_COMEDY pending 300
Related Commands
Command idle (CSG2 content) ip csg content show ip csg
Description Specifies the minimum amount of time that the CSG2 maintains an idle content connection. Configures content for CSG2 services, and enters CSG2 content configuration mode. Displays information about the CSG2.
A-346
OL-22840-05
Appendix A
CSG2 Command Reference police
police
To configure rate limiting (policing) for a CSG2 Quality of Service (QoS) profile, use the police command in CSG2 QoS profile configuration mode. To restore the default settings, use the no form of this command. police {rate police-rate burst burst-size | conform-action [drop | transmit | set-dscp-transmit dscp] | exceed-action [drop | transmit | set-dscp-transmit dscp] | conform-action [drop | transmit | set-dscp-transmit dscp] exceed-action [drop | transmit | set-dscp-transmit dscp]} no police {rate police-rate burst burst-size | conform-action [drop | transmit | set-dscp-transmit dscp] | exceed-action [drop | transmit | set-dscp-transmit dscp] | conform-action [drop | transmit | set-dscp-transmit dscp] exceed-action [drop | transmit | set-dscp-transmit dscp]}
Syntax Description
rate police-rate burst burst-size conform-action exceed-action drop
Rate, in bits per second, at which the CSG2 polices traffic. The valid range is 8000 to 2,000,000,000. Burst size, in bytes. The valid range is 1000 to 512,000,000. Action to be taken on packets that conform to the police rate. The default setting is transmit. Action to be taken on packets that exceed the police rate. The default setting is drop. (Optional) Drop the packet. This is the default setting if you specify exceed-action.
A-347
Appendix A police
transmit
(Optional) Transmit the packet without changing the differentiated services code point (DSCP) field in the IP header. This is the default setting if you specify conform-action. (Optional) Set the DSCP field in the IP header to the value of dscp, then transmit the packet. The CSG2 overrides any marking that has already been applied to the packet (for example, by the GGSN). The valid values for dscp are:

set-dscp-transmit dscp
0-63DSCP value af11AF11 DSCP (001010) af12AF12 DSCP (001100) af13AF13 DSCP (001110) af21AF21 DSCP (010010) af22AF22 DSCP (010100) af23AF23 DSCP (010110) af31AF31 DSCP (011010) af32AF32 DSCP (011100) af33AF33 DSCP (011110) af41AF41 DSCP (100010) af42AF42 DSCP (100100) af43AF43 DSCP (100110) cs1CS1 (precedence 1) DSCP (001000) cs2CS2 (precedence 2) DSCP (010000) cs3CS3 (precedence 3) DSCP (011000) cs4CS4 (precedence 4) DSCP (100000) cs5CS5 (precedence 5) DSCP (101000) cs6CS6 (precedence 6) DSCP (110000) cs7CS7 (precedence 7) DSCP (111000) defaultDefault DSCP (000000) efEF DSCP (101110)
Command Default
If you do not configure the police command, all packets that hit this QoS profile is dropped. If you configure conform-action but you do not configure exceed-action, packets are dropped if they exceed the police rate. If you configure exceed-action but you do not configure conform-action, packets are transmitted if they conform to the police rate.
Command Modes
CSG2 QoS profile configuration
A-348
OL-22840-05
Appendix A
CSG2 Command Reference police
Command History
Release 12.4(22)MD
Usage Guidelines
The burst size must be large enough to accommodate the largest packet that the CSG2 can receive.
The burst size must be larger than the largest Ethernet frame that the CSG2 can receive. Typically, that is a 1500-byte maximum transmission unit (MTU) plus 18 bytes of Ethernet/802.1Q (dot1q) header, or a total of 1518 bytes. The burst size should also be large enough to allow 1.5 seconds of traffic at the configured police rate. For example, if the configured police rate is 50,000 bits per second, then you should configure a burst size of at least 50,000 bps * 1.5 seconds = 75,000 bits, or 9375 bytes. These requirements apply regardless of whether the burst size is configured with the police command or signaled in a quota server or PCRF message. no police rate 8000 burst 1000
To drop all packets that hit this QoS profile, use the following command: To mark traffic of interest with a specific DSCP, use the following command: police conform-action set-dscp-transmit dscp exceed-action set-dscp-transmit dscp where dscp is the DSCP with which you want to mark the traffic. You can configure the police command with conform-action, with exceed-action, or with both:
If you configure conform-action but you do not configure exceed-action (for example, police conform-action set-dscp-transmit ef), exceed-action is set to its default setting and packets are dropped if they exceed the police rate. If you configure exceed-action but you do not configure conform-action (for example, police exceed-action set-dscp-transmit ef), conform-action is set to its default setting and packets are transmitted if they conform to the police rate.
You can implement QoS on a per-user basis (that is, to apply the QoS to traffic to and from a particular subscriber); on a per-user-service basis (that is, to apply the QoS to traffic to and from a particular subscriber and to a specific service); or on a combination of per-user and per-user-service basis. However, if you implement a combination of per-user QoS and per-user-service QoS, we recommend that you configure policing for either the per-user QoS profile or the per-user-service QoS profile, but not both.
Examples
The following example shows how to:

Set a police rate of 100 kbps with a 1000-byte burst. In packets that conform to the police rate, change the DSCP field in IP headers to EF DSCP (101110), then transmit the packets. In packets that exceed the police rate, change the DSCP field in IP headers to AF43 DSCP (100110), then transmit the packets.
ip csg qos profile CSG2QOS police rate 100000 burst 1000 police conform-action set-dscp-transmit ef exceed-action set-dscp-transmit af43
A-349
Appendix A police
Related Commands
Command ip csg qos profile qos profile (CSG2 billing) qos profile (CSG2 service)
Description Configures a Quality of Service (QoS) profile name for the CSG2, and enters CSG2 QoS profile configuration mode. Associates a Quality of Service (QoS) profile with a CSG2 billing plan. Associates a Quality of Service (QoS) profile with a CSG2 service.
A-350
OL-22840-05
Appendix A
CSG2 Command Reference policy (CSG2 content)
policy (CSG2 content)

To associate a CSG2 billing policy with a content, use the policy command in CSG2 content configuration mode. To delete a policy reference, use the no form of this command. policy policy-name [priority priority-number] no policy policy-name
Syntax Description
policy-name priority priority-number
Name of a configured CSG2 billing policy. (Optional) Priority of the policy. The priority specifies the order of preference of the policy. A lower number indicates a higher priority. If the current policy becomes unusable, the CSG2 uses the highest priority policy (that is, the policy with the lowest priority number) available. In the same content, all policies must have different priorities. Priorities for different policies do not have to be sequential. That is, you can have three policies with priorities 1, 5, and 10. The range of priorities is from 1 to 511.
Command Default
No policy is configured. If you do not specify a priority for the policy, no priority is configured. The CSG2 lists and prioritizes the policy sequentially, in the order in which it was configured.
Command Modes
Command History
Release 12.4(11)MD 12.4(15)MD
Modification This command was migrated from CSG1. Changes from CSG1: None. The priority keyword and the priority-number argument were added.
Usage Guidelines
If accounting records are to be generated for flows matching this policy, you must configure the accounting command in CSG2 policy configuration mode. If you do not want to bill for flows matching this policy, do not configure the accounting command. To reference more than one policy in a content configuration, use multiple policy commands. All policies in a given content configuration must be configured the same way, either all with priorities, or all without priorities. Policies in the same content configuration must have different priorities.
A-351
Appendix A policy (CSG2 content)
Examples
The following example shows how to reference policies with and without priorities:
ip csg content MOVIES policy COMEDY policy HORROR ip csg content MUSIC policy HIPHOP priority 1 policy COUNTRY priority 10000
Related Commands
Command ip csg content ip csg policy show ip csg
Description Configures content for CSG2 services, and enters CSG2 content configuration mode. Defines a policy for qualifying flows for the CSG2 accounting services, and enters CSG2 policy configuration mode. Displays information about the CSG2.
A-352
OL-22840-05
Appendix A
CSG2 Command Reference port (iSCSI)
port (iSCSI)
To specify the number of the port on which to listen for iSCSI traffic in the iSCSI target interface profile on the CSG2, use the port command in iSCSI configuration mode. To remove the port number, use the no form of the command. port port-number no port port-number
Syntax Description
port-number
Number of the port on which to listen for iSCSI traffic. We recommend that you use port 3260.
Command Default
Command Modes
iSCSI configuration
Command History
Release 12.4(15)MD
Examples
The following example configures an iSCSI target interface profile with the name targetA to a iSCSI target with which the CSG2 will communicate using port number 3260:
Related Commands
Description Specifies the IP address of an iSCSI target in the target interface profile on the CSG2. Defines the delay interval, in seconds, before draining packets from the Storage Area Network (SAN) connected to the Internet Small Computer Systems Interface (iSCSI) when the Billing Mediation Agent (BMA) becomes active. Defines the number of packets to be drained from the Storage Area Network (SAN) connected to the Internet Small Computer Systems Interface (iSCSI) per drain delay interval when the Billing Mediation Agent (BMA) becomes active.
A-353
Appendix A port (iSCSI)
Command ip csg iscsi profile ip iscsi target-profile name (iSCSI) session-timeout (iSCSI) target-portal (iSCSI)
Description Specifies the Internet Small Computer Systems Interface (iSCSI) target to be used as backup storage for the CSG2. Creates an iSCSI profile for an iSCSI target on the CSG2, and enters iSCSI configuration mode. Specifies the name of an iSCSI target in the target profile on the CSG2 Specifies the session timeout for an iSCSI target in the target interface profile on the CSG2. Specifies the portal group tag for an iSCSI target in the target interface profile on the CSG2.
A-354
OL-22840-05
Appendix A
CSG2 Command Reference qct (CSG2 service)
qct (CSG2 service)

To specify a quota consumption time (QCT) for a CSG2 service, use the qct command in CSG2 service configuration mode. To delete the QCT, use the no form of the command. qct qct no qct
Syntax Description
qct
QCT, in seconds, for the service. The range is from 0 to 4294967295.
Command Default
No QCT is specified for the service.
Command Modes
Command History
Release 12.4(24)MD
Usage Guidelines
When this command is configured and a subscriber is inactive, the CSG2 charges only for the QCT. Make sure the QCT does not exceed the service idle timeout value, set using the idle command in CSG2 service configuration mode. The qct command is applied to only those services that are configured with basis second. If the service is configured for dual basis, the first basis must be basis second. The qct command is mutually exclusive with the following commands:

meter exclude pause rtsp meter exclude svc-idle meter increment
If a quota server specifies a QCT in a Service Authorization Response, a Service Reauthorization Response, or a Quota Push message, the quota server QCT overrides the QCT specified using the qct command, as well as any prior quota server QCTs.
Examples
The following example shows how to specify a QCT of 20 seconds for service HTTP-SVC:
ip csg service HTTP-SVC qct 20
A-355
Appendix A qct (CSG2 service)
Related Commands
Command basis idle (CSG2 service) ip csg quota-server
Description Specifies the billing basis for a CSG2 content billing service. Specifies the minimum amount of time that the CSG2 maintains a service with no subscriber sessions. Configures a CSG2 content billing service, and enters CSG2 service configuration mode,.
A-356
OL-22840-05
Appendix A
CSG2 Command Reference qos profile (CSG2 billing)
qos profile (CSG2 billing)

To associate a Quality of Service (QoS) profile with a CSG2 billing plan, use the qos profile command in CSG2 billing configuration mode. To disassociate the QoS profile from the billing plan, use the no form of the command. qos profile qos-profile-name {network | subscriber} no qos profile qos-profile-name {network | subscriber}
Syntax Description
qos-profile-name network subscriber
Name of the QoS profile to associate with the billing plan. Apply the QoS profile to traffic in the network-to-subscriber direction. Apply the QoS profile to traffic in the subscriber-to-network direction.
Command Default
No QoS profile is associated with the billing plan.
Command Modes
Command History
Release 12.4(22)MD
Usage Guidelines
Configure this command to implement QoS on a per-user basis (that is, to apply the QoS to traffic to and from a particular subscriber). Configure the qos profile (CSG2 service) command in CSG2 service configuration mode to implement QoS on a per-user-service basis (that is, to apply the QoS to traffic to and from a particular subscriber and to a specific service). You can also implement a combination of per-user QoS and per-user-service QoS. For example, you can configure a QoS profile for a billing plan to rate-limit all of the traffic to and from the subscribers that use that plan, and you can configure other QoS profiles under specific services to mark those packets differently. However, if you implement a combination of per-user QoS and per-user-service QoS, we recommend that you configure policing for either the per-user QoS profile or the per-user-service QoS profile, but not both. If user traffic matches both a billing plan configured for QoS and a service configured for QoS, the CSG2 applies the per-user-service QoS police rate first, then the per-user QoS police rate. If the traffic passes the per-user-service check, but then fails the per-user check, the CSG2 takes the action configured for per-user Qos on the qos profile (CSG2 billing) command. Therefore, if the per-user-service check is more stringent than the per-user check (assuming there is no traffic hitting other services for this user), then all packets that pass the per-user-service check should also pass the per-user check.
A-357
Appendix A qos profile (CSG2 billing)
Examples
The following example shows how to associate QoS profile CSG2QOS with billing plan BwLtdPlan, applying CSG2QOS to traffic in the network-to-subscriber direction:
ip csg billing BwLtdPlan qos profile CSG2QOS network
Related Commands
Command entries user idle ip csg billing ip csg qos profile mode police qos profile (CSG2 service) service user-default
Description Sets the time after which entries for idle subscribers are deleted from the CSG2 User Table. Defines a CSG2 billing plan, and enters CSG2 billing configuration mode. Configures a Quality of Service (QoS) profile name for the CSG2, and enters CSG2 QoS profile configuration mode. Specifies the mode for a CSG2 billing plan. Configures rate limiting (policing) for a CSG2 Quality of Service (QoS) profile. Associates a Quality of Service (QoS) profile with a CSG2 service. Associates a service with a CSG2 billing plan. Designates a CSG2 billing plan as the default billing plan.
A-358
OL-22840-05
Appendix A
CSG2 Command Reference qos profile (CSG2 service)
qos profile (CSG2 service)

To associate a Quality of Service (QoS) profile with a CSG2 service, use the qos profile command in CSG2 service configuration mode. To disassociate the QoS profile from the service, use the no form of the command. qos profile qos-profile-name {network | subscriber} no qos profile qos-profile-name {network | subscriber}
Syntax Description
qos-profile-name network subscriber
Name of the QoS profile to associate with the service. Apply the QoS profile to traffic in the network-to-subscriber direction. Apply the QoS profile to traffic in the subscriber-to-network direction.
Command Default
No QoS profile is associated with the billing plan.
Command Modes
Command History
Release 12.4(22)MD
Usage Guidelines
Configure this command in CSG2 service configuration mode to implement QoS on a per-user-service basis (that is, to apply the QoS to traffic to and from a particular subscriber and to a specific service). Configure the qos profile (CSG2 billing) command in CSG2 billing configuration mode to implement QoS on a per-user basis (that is, to apply the QoS to traffic to and from a particular subscriber). You can also implement a combination of per-user QoS and per-user-service QoS. For example, you can configure a QoS profile for a billing plan to rate-limit all of the traffic to and from the subscribers that use that plan, and you can configure other QoS profiles under specific services to mark those packets differently. However, if you implement a combination of per-user QoS and per-user-service QoS, we recommend that you configure policing for either the per-user QoS profile or the per-user-service QoS profile, but not both. If user traffic matches both a billing plan configured for QoS and a service configured for QoS, the CSG2 applies the per-user-service QoS police rate first, then the per-user QoS police rate. If the traffic passes the per-user-service check, but then fails the per-user check, the CSG2 takes the action configured for per-user Qos on the qos profile (CSG2 billing) command. Therefore, if the per-user-service check is more stringent than the per-user check (assuming there is no traffic hitting other services for this user), then all packets that pass the per-user-service check should also pass the per-user check.
A-359
Appendix A qos profile (CSG2 service)
Examples
The following example shows how to associate QoS profile CSG2QOS with service BwLtdService, applying CSG2QOS to traffic in the network-to-subscriber direction:
ip csg service BwLtdService qos profile CSG2QOS network
Related Commands
Command ip csg qos profile ip csg service police qos profile (CSG2 billing) qos profile (CSG2 service)
Description Configures a Quality of Service (QoS) profile name for the CSG2, and enters CSG2 QoS profile configuration mode. Configures a CSG2 content billing service, and enters CSG2 service configuration mode. Configures rate limiting (policing) for a CSG2 Quality of Service (QoS) profile. Associates a Quality of Service (QoS) profile with a CSG2 billing plan. Associates a Quality of Service (QoS) profile with a CSG2 service.
A-360
OL-22840-05
Appendix A
CSG2 Command Reference quota-server (CSG2 header)
quota-server (CSG2 header)

To insert data from the Quota-Server TLV into a CSG2 header, use the quota-server command in CSG2 header configuration mode. To exclude the data from the header, use the no form of this command. quota-server no quota-server
Syntax Description
Command Default
The data from the Quota-Server TLV is not inserted into the CSG2 header.
Command Modes
Command History
Release 12.4(24)MD
Usage Guidelines
This command is optional for a CSG2 header.
Examples
The following example shows how to insert data from the Quota-Server TLV into a CSG2 header:
quota-server
Related Commands
A-361
Appendix A radius (CSG2 header)
radius (CSG2 header)

To specify a RADIUS attribute or vendor-specific attribute (VSA) subattribute, and to indicate where it is to be inserted into a CSG2 header, use the radius command in CSG2 header configuration mode. To remove the RADIUS attribute or VSA subattribute, use the no form of this command. radius {radius-attribute-number | vsa {vendor-id | 3gpp} radius-subattribute-number} no radius {radius-attribute-number | vsa {vendor-id | 3gpp} radius-subattribute-number}
Syntax Description
RADIUS attribute number. The range is from 1 to 255. Vendor-specific attribute (VSA). Vendor ID number. The range is from 1 to 16777215. Third Generation Partnership Project (3GPP) vendor ID. Subattribute number. The range is from 1 to 255.
Command Default
None
Command Modes
Command History
Release 12.4(24)MD
Usage Guidelines
This command is optional for a CSG2 header. You can insert up to 256 RADIUS attributes.
Note
Any information for the configured RADIUS attribute or VSA subattribute must be present in the incoming RADIUS Accounting-Start message.
Examples
The following example shows how to insert RADIUS attribute 234 into a CSG2 header:
radius 234
Related Commands
A-362
OL-22840-05
Appendix A
CSG2 Command Reference radius (CSG2 header)
Command ip csg radius binary attribute ip csg radius userid
Description Indicates that a RADIUS attribute or vendor-specific attribute (VSA) subattribute is in binary format. Specifies the RADIUS attribute or vendor-specific attribute (VSA) subattribute to be used to extract the user ID from a RADIUS record.
A-363
Appendix A radius (CSG2 user class)
radius (CSG2 user class)

To specify a user class match value for a RADIUS attribute or VSA subattribute, use the radius command in CSG2 user class configuration mode. To remove the match value, use the no form of the command. radius attribute-name { any | integer integer-value | ip [string] ipv4-address | ip [string] acl acl-name | ip [string] acl acl-number | string attribute-string } no radius attribute-name
Syntax Description
attribute-name any integer integer-value ip string ipv4-address acl acl-name acl acl-number string attribute-string
Name of a RADIUS attribute or VSA subattribute, as specified with the ip csg radius attribute command in global configuration mode. Matches the named RADIUS attribute or VSA subattribute if it is present, regardless of its value. Matches the named RADIUS attribute or VSA subattribute if its value matches the specified integer value. Matches the named RADIUS attribute or VSA subattribute if its value matches the specified IP address. (Optional) Indicates that the IPv4 address is in ASCII format. Matches the named RADIUS attribute or VSA subattribute if its value matches the specified IPv4 address. Matches the named RADIUS attribute or VSA subattribute if its value matches the specified simple access control list (ACL) name. Matches the named RADIUS attribute or VSA subattribute if its value matches the specified simple ACL number. Matches the named RADIUS attribute or VSA subattribute if its value fully matches the specified attribute-string.
Command Default
No match values are specified.
Command Modes
CSG2 user class configuration
Command History
Release 12.4(24)MD
A-364
OL-22840-05
Appendix A
CSG2 Command Reference radius (CSG2 user class)
Usage Guidelines
Use this command to specify a match value for a user class. You can use more than one radius command to define up to 64 RADIUS attributes or VSA subattributes for a given user class.
If each of a user classs match values matches at least one Attribute Value Pair (AVP) associated with a subscriber, then the match succeeds and the CSG2 uses the user class when making next-hop routing decisions. If even one of a user classs match values does not match an AVP associated with a subscriber, then the match fails and the CSG2 does not use the user class when making next-hop routing decisions.
If you change the match values for a user class, the change does not affect routing decisions for existing sessions, nor does it change the user classes selected for subscribers, until those subscriber records are affected by a user class selection event, such as a RADIUS Accounting Start or RADIUS Interim Accounting message.
Examples
The following example shows how to specify match values for user class 3G-LAPTOP:
ip csg user class 3G-LAPTOP radius RAT integer 1 radius IMEI string manufacturer1:LAPTOP1:ver1:serial1 radius UserName any radius RAT1 ip 5.5.5.5 radius RAT2 ip string 5.5.5.5 radius RAT3 ip acl 1 radius RAT4 ip string acl 1
Related Commands
Command ip csg radius attribute ip csg service ip csg user class
Description Specifies a name for a RADIUS attribute or VSA subattribute that is to be used in subsequent CSG2 configuration commands. Configures a CSG2 content billing service, and enters CSG2 service configuration mode. Defines a user class to be used by the CSG2 when making routing decisions, and enters CSG2 user class configuration mode.
A-365
Appendix A rating-group (CSG2 service)
rating-group (CSG2 service)

To configure a rating group for a CSG2 eG-CDR service, use the rating-group command in CSG2 service configuration mode. To remove the rating group from the service, use the no form of this command. rating-group rating-group-number no rating-group
Syntax Description
rating-group-number
Rating group number that this service is to report in eG-CDRs. The valid range is 1 to 4294967295.
Command Default
No rating group is configured for the service.
Command Modes
Command History
Release 12.4(24)MD
Examples
The following example shows how to configure a rating group of 3 for service HTTP-BILLING:
ip csg service HTTP-BILLING rating-group 3
Related Commands
Description Configures a CSG2 content billing service, and to enter CSG2 service configuration mode.
A-366
OL-22840-05
Appendix A
CSG2 Command Reference realm destination
realm destination
To specify the destination realm to be sent by Mobile PCC in initial CCRs to the PCRF, use the realm destination command in Mobile PCC profile configuration mode. To delete the destination realm, use the no form of this command. realm destination destination-realm-string no realm destination destination-realm-string
Syntax Description
destination-realm-string
Destination realm to be sent by Mobile Policy Control & Charging (PCC) in initial policy preload requests (CCRs) to the Policy and Charging Rule Function (PCRF). For subsequent CCRs, Mobile PCC uses the Origin-Realm Attribute Value Pair (AVP) received in the last policy preload response (CCA) as the destination realm.
Command Default
No destination realm is defined.
Command Modes
Mobile PCC profile configuration
Command History
Release 12.4(22)MDA
Usage Guidelines
If the realm destination command is not configured for a Mobile PCC profile, then the global destination realm, configured with the mpcc destination-realm command, is used.
Examples
The following example shows how to specify cisco.com as the destination realm:
realm destination cisco.com
Related Commands
Command mpcc destination-realm mpcc profile
Description Specifies a global destination realm to be sent by Mobile PCC in initial CCRs to the PCRF. Defines a Mobile Policy Control & Charging (PCC) profile to be used to send per-user requests to the Policy and Charging Rule Function (PCRF), and enters Mobile PCC profile configuration mode. Defines a method list to be used by Mobile Policy Control & Charging (PCC) for requests to Policy and Charging Rule Function (PCRF) for policy preloading.
pcrf policy-if
A-367
Appendix A reauthorization threshold
reauthorization threshold
To configure the CSG2 reauthorization threshold, use the reauthorization threshold command in CSG2 service configuration mode. To restore the default setting, use the no form of this command. reauthorization threshold threshold [dual dual-threshold] no reauthorization threshold
Syntax Description
threshold
Number of remaining quadrans or seconds to trigger reauthorization.
For fixed-cost billing (basis fixed) or volume-based billing (basis byte), the range (in quadrans) is from 0 to 10000000. The default is 10000000. For duration-based billing (basis second), the range (in seconds) is from 0 to 10000000. The default is 10.
dual dual-threshold
(Optional) Number of remaining quadrans or seconds to trigger reauthorization, for dual quota.
For fixed-cost billing (basis fixed) or volume-based billing (basis byte), the range (in quadrans) is from 0 to 10000000. The default is 10000000. For duration-based billing (basis second), the range (in seconds) is from 0 to 10000000. The default is 10.
Command Default
For fixed-cost billing (basis fixed) or volume-based billing (basis byte), the default reauthorization threshold is 10000000 quadrans. For duration-based billing (basis second), the default reauthorization threshold is 10 seconds. For fixed-cost billing (basis fixed) or volume-based billing (basis byte) for dual quota, the default reauthorization threshold is 10000000 quadrans. For duration-based billing (basis second) for dual quota, the default reauthorization threshold is 10 seconds.
Command Modes
Command History
Release 12.4(11)MD 12.4(22)MD
Modification This command was introduced. The dual keyword and dual-threshold argument were added.
Usage Guidelines
Setting the threshold to 0 means that reauthorization is triggered when there are no remaining quadrans or seconds. The quota server can override these settings.
A-368
OL-22840-05
Appendix A
CSG2 Command Reference reauthorization threshold
For services configured for fixed-cost billing (basis fixed), the reauthorization trigger is the smaller of the following values:

The threshold configured using the reauthorization threshold command 25% of the last quota grant returned from the quota server
For services configured for volume-based billing (basis byte), the reauthorization trigger is the smaller of the following values:

The threshold configured using the reauthorization threshold command 32 KB or 25% of the last quota grant returned from the quota server, whichever is larger
For services configured for duration-based billing (basis second), the reauthorization trigger is the threshold configured using the reauthorization threshold command.
Examples
The following example shows how to specify a reauthorization threshold of 75 quadrans, and a reauthorization threshold of 100 quadrans for dual basis:
ip csg service A1 reauthorization threshold 75 dual 100
Related Commands
Command basis ip csg service passthrough reauthorization timeout
Description Specifies the billing basis for a CSG2 content billing service. Configures a CSG2 content billing service, and enters CSG2 service configuration mode. Enables passthrough mode for a CSG2 service. Specifies the CSG2 reauthorization timeout.
A-369
Appendix A reauthorization timeout
reauthorization timeout
To specify the CSG2 reauthorization timeout, use the reauthorization timeout command in CSG2 service configuration mode. To restore the default setting, use the no form of this command. reauthorization timeout [initial initial-timeout] [maximum maximum-timeout] no reauthorization timeout
Syntax Description
initial initial-timeout
(Optional) Initial timeout, in seconds, for reauthorization after a quota grant of zero. The range is from 1 to 3600 seconds. The default is 4. The value specified for must be less than or equal to the value specified for maximum maximum-timeout.
maximum maximum-timeout
(Optional) Maximum timeout, in seconds, for reauthorization after a quota grant of zero. The range is from 1 to 3600 seconds. The default is 60.
Command Default
The default initial reauthorization timeout is 4 seconds. The default maximum reauthorization timeout is 60 seconds.
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
The quota server can override these settings. For every quota grant of zero, the reauthorization time doubles, until the maximum timeout is reached. For example, if the initial timeout is set to 30 seconds, and the maximum timeout is set to 250 seconds, the reauthorization times (assuming quota grants of zero) would be:

30 seconds 60 seconds 120 seconds 240 seconds 250 seconds 250 seconds
And so on.
A-370
OL-22840-05
Appendix A
CSG2 Command Reference reauthorization timeout
Examples
The following example shows how to specify an initial reauthorization timeout of 30 seconds and a maximum reauthorization timeout of 250 seconds:
ip csg service A1 reauthorization timeout initial 30 maximum 250
Related Commands
Command ip csg service reauthorization threshold
Description Configures a CSG2 content billing service, and enters CSG2 service configuration mode. Specifies the CSG2 reauthorization threshold.
A-371
Appendix A records delay
records delay
To specify the delay before the CSG2 is to send the HTTP Statistics CDR, use the records delay command in CSG2 content configuration mode. To restore the default setting, use the no form of this command. records delay seconds no records delay
Syntax Description
seconds
Time, in seconds, that the CSG2 is to delay before sending the HTTP statistics CDR. The range is from 0 to 1234 seconds. The default is 0 (no records delay).
Command Default
The default value is 0 (no records delay).
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
Specifying a records delay enables CSG2 accounting for retransmitted packets and ACKs after the transaction closes, but before the connection closes. When forwarding out-of-order packets, the CSG2 closes a transaction when the first response packet for the next transaction is received. For HTTP pipelined requests and for accelerated sessions, that can lead to an increase in bytes that are counted as unaccounted bytes (slop). To mitigate this situation, you can use the records delay command to specify a delay before the CSG2 generates HTTP transaction CDRs (and closes those transactions). We recommend a delay of at least 30 seconds. However, you might need to configure a longer delay, depending on your network conditions. If you configure QoS for subscribers or services that bill HTTP, you must configure a delay to ensure accurate reporting of byte and packet counts in the transaction CDRs. We recommend a delay of at least 30 seconds. However, you might need to configure a longer delay, depending on your network conditions and QoS parameters.
Examples
The following example shows how to specify a records delay of 5 seconds:

ip csg content MOVIES records delay 5
A-372
OL-22840-05
Appendix A
CSG2 Command Reference records delay
Related Commands
Command accelerate ip csg content
Description Enables acceleration for sessions that match a CSG2 content. Configures content for CSG2 services, and enters CSG2 content configuration mode.
A-373
Appendix A records granularity
records granularity
To specify the granularity at which CSG2 billing call detail records (CDRs) are to be generated, use the records granularity command in CSG2 service configuration mode. To restore the default granularity, use the no form of this command. records granularity {transaction | service {bytes bytes | seconds seconds | bytes bytes seconds seconds}} no records granularity
Syntax Description
transaction service bytes bytes
Generate CDRs for each transaction. This is the default setting. Generate summarized, service-level CDRs. Number of bytes of data, sent and received by a session, that triggers a CDR. The difference between bytes sent and bytes received in two records might not exactly equal the bytes argument, because updates must occur on packet boundaries. The range is from 5000 to 2147483647. If the bytes keyword is not specified, there is no maximum.
seconds seconds
Maximum time, in seconds, between billing records for a session. Records can be sent more frequently if the number of bytes is reached. When a record is sent because the maximum time has been reached, the byte counts reported in the record are approximate. The range is from 5 to 86400. If the time keyword is not specified, there is no time limit.
Command Default
If you do not specify the records granularity command, CDRs are generated for each transaction. If you specify records granularity service, you must also specify the bytes keyword, the seconds keyword, or both:

If you specify both the bytes keyword and the seconds keyword, a billing record is sent when either limit is reached. Then both limits are reset. If you specify only the bytes keyword and not the seconds keyword, there is no time limit between billing records for a session. If you specify only the seconds keyword and not the bytes keyword, there is no maximum number of bytes of data that triggers the sending of a billing record.
Command Modes
A-374
OL-22840-05
Appendix A
CSG2 Command Reference records granularity
Command History
Release 12.4(11)MD

The time keyword changed to seconds. The range for the seconds argument changed from 60 to 4294967295, to 5 to 86400.
Usage Guidelines
You can use this command to reduce the number of records for services for which transaction-level billing is not required. For example, if a subscriber is accessing the Internet, and the data is to be billed based only on volume, then generating records for each HTTP transaction is of little use. With service-level CDR summarization enabled, the CSG2 generates only consolidated records that contain service-level usage. To enable service-level CDR summarization in postpaid mode, you must specify that the associated billing plan is postpaid by using the mode postpaid command in CSG2 billing configuration mode. Service-level CDRs are generated only for subscribers with entries in the CSG2 User Table entry. If a subscriber does not have an entry in the User Table, the CSG2 generates transaction-level CDRs.
Examples
The following example shows how to specify a service granularity in both IP bytes and seconds:
ip csg service A1 records granularity service byte 10000 seconds 120
Related Commands
A-375
Appendix A records intermediate
records intermediate
To enable the generation of CSG2 intermediate CDRs, use the records intermediate command in CSG2 content configuration mode. To disable the generation of intermediate CDRs, use the no form of this command. records intermediate {bytes bytes | seconds seconds | bytes bytes seconds seconds} no records intermediate {bytes bytes | seconds seconds | bytes bytes seconds seconds}
Syntax Description
bytes bytes
Number of bytes of data, sent and received by a session, that triggers the sending of an intermediate CDR. The difference between bytes sent and received in two records might not exactly equal the bytes argument. A trigger can occur only on a packet boundary. Once triggered, a separate process captures a snapshot of the current byte counts for a session. Between the trigger and the snapshot, additional packets might be counted. The range is from 5000 to 4294967295. The default value, if the bytes keyword is not specified, is 0, indicating that the number of bytes sent and received will not trigger an intermediate record.
seconds seconds Maximum time, in seconds, between billing records for a session. Records can be sent more frequently if the number of bytes is reached. When a record is sent because the maximum time has been reached, the byte counts reported in the record are approximate. The range is from 5 to 86400. The default value, if the seconds keyword is not specified, is 0, indicating no time limit.
Command Default
If you do not specify the records intermediate command, or if you specify the records intermediate command for a content for a protocol handler that does not support intermediate statistics, intermediate CDRs are not generated. If you specify the bytes keyword but not the seconds keyword, the maximum time between billing records for a session is set to 0 seconds, indicating no time limit. If you specify the seconds keyword but not the bytes keyword, the number of bytes of data that triggers the sending of an intermediate CDR is set to 0 bytes, indicating that the number of bytes sent and received will not trigger an intermediate record. If you specify both the bytes keyword and the seconds keyword, a billing record is sent when either limit is reached. Then both limits are reset.
Command Modes
A-376
OL-22840-05
Appendix A
CSG2 Command Reference records intermediate
Command History
Release 12.4(11)MD

The configuration mode for this command changed from CSG accounting configuration to CSG2 content configuration. The time keyword changed to seconds. The range for the seconds argument changed from 5 to 65535, to 5 to 86400.
Usage Guidelines
The CSG2 supports intermediate CDRs for FTP, HTTP, IP, RTSP, SIP, TCP, and UDP. The CSG2 does not support intermediate CDRs for DNS, WAP, or e-mail protocols (such as IMAP, POP3, and SMTP).
Examples
The following example shows how to enable intermediate CDRs for the CSG2 content MOVIES. In this example, intermediate records are generated after 100,000 IP bytes of data are sent and received, or after 3600 seconds (1 hour) elapse, whichever occurs first:
ip csg content MOVIES records intermediate bytes 100000 seconds 3600
Related Commands
A-377
Appendix A refund
refund
To specify the refund policy for a CSG2 prepaid service, use the refund command in CSG2 service configuration mode. To disable the refund policy, use the no form of this command. refund policy-name no refund policy-name
Syntax Description
policy-name
Name of the refund policy.
Command Default
Refunding is not enabled.
Command Modes
Command History
Release 12.4(11)MD
Modification This command was migrated from CSG1. Changes from CSG1: The name of this command changed from refund-policy to refund.
Examples
The following example specifies refund policy COMPANY-REFUND:

ip csg service BILLBYVOLUME refund COMPANY-REFUND
Related Commands
Command ip csg refund ip csg service
Description Specifies the CSG2 refund policy to apply to the various services, and enters CSG2 refund configuration mode. Configures a CSG2 content billing service, and enters CSG2 service configuration mode.
A-378
OL-22840-05
Appendix A
CSG2 Command Reference relative
relative
To enable relative URI support for CSG2 URL matching, use the relative command in CSG2 content configuration mode. To disable relative URI support, use the no form of this command. relative no relative
Syntax Description
Command Default
Relative URL map matching is not enabled.
Command Modes
Command History
Release 12.4(22)MDA
Usage Guidelines
The CSG2 supports relative URIs for HTTP only.
Examples
The following example shows how to enable relative URI support for content MOVIES:
ip csg content MOVIES relative
Related Commands
Command ip csg content match url (CSG2 map)
Description Configures content for CSG2 services, and enters CSG2 content configuration mode. Specifies a URL match pattern for a CSG2 billing map.
A-379
Appendix A replicate (CSG2 content)
replicate (CSG2 content)

To replicate the connection state for all connections to the CSG2 content servers on the standby system, use the replicate command in CSG2 content configuration mode. To disable connection redundancy, use the no form of this command. replicate [delay seconds] no replicate [delay]
Syntax Description
delay seconds
(Optional) Number of seconds to delay state replication. The range is from 1 to 3600. The default value is no delay.
Command Default
Connection redundancy is not enabled. If you do not specify a delay, there is no delay.
Command Modes
Command History
Release 12.4(11)MD

The name of this command changed from replicate connection tcp to replicate. The delay seconds keyword and argument were added.
Usage Guidelines
Replication is not supported for the Domain Name System (DNS) protocol or the wireless application protocol 1.x (WAP 1.x). Therefore, the CSG2 generates an error message if either of the following situations occurs:

You have already configured DNS or WAP 1.x using the parse protocol command and you try to enter the replicate command. You have already configured replicate and you try to configure DNS or WAP 1.x using the parse protocol command.
For HTTP, the replicated session is treated as Layer 4. No HTTP parsing is performed when the replicated session on the standby CSG2 becomes active. The replicate command is not supported for DNS contents.
Examples
The following example shows how to enable replication for the CSG2 content MOVIES, and replication with a delay of 30 seconds for the CSG2 content GAMES:
ip csg content MOVIES replicate
A-380
OL-22840-05
Appendix A
CSG2 Command Reference replicate (CSG2 content)
ip csg content GAMES replicate delay 30
Related Commands
Command ip csg content ip csg replicate
Description Configures content for CSG2 services, and enters CSG2 content configuration mode. Enables state replication between redundant CSG2 systems.
A-381
Appendix A retcode
retcode
To specify the range of application return codes for which the CSG2 refunds quota for Prepaid Error Reimbursement, use the retcode command in CSG2 refund configuration mode. To disable this feature, use the no form of this command. retcode {ftp | http | imap | pop3 | sip | smtp | wap} rc-start [rc-end] no retcode {ftp | http | imap | pop3 | sip | smtp | wap} rc-start [rc-end]
Syntax Description
ftp http
The CSG2 refunds quota for FTP application return codes. The CSG2 refunds quota for HTTP and WAP 2.0 application return codes.
Note
The http keyword affects only HTTP and WAP 2.0. For WAP 1.x refunds, use the wap keyword.
imap pop3 sip
The CSG2 refunds quota for Internet Message Access Protocol (IMAP) application return codes. The CSG2 refunds quota for Post Office Protocol, version 3 (POP3) application return codes. The CSG2 refunds quota for Session Initiation Protocol (SIP) application return codes.
Note
For SIP calls, only the return code to the INVITE method is used. For SIP events, each event is a transaction associated with a single return code.
smtp wap
The CSG2 refunds quota for Simple Mail Transfer Protocol (SMTP) application return codes. The CSG2 refunds quota for WAP 1.x application return codes.
Note
The wap keyword affects only WAP 1.x. For WAP 2.0 refunds, use the http keyword.
rc-start rc-end
Specifies the beginning of the range of values for specific application return codes. The range is from 1 to 65535 (0xffff). (Optional) Specifies the end of the range of values for specific application return codes. The range is from the value of rc-start to 65535 (0xffff). If you are specifying a single value as the range, do not specify rc-end.
Command Default
None
Command Modes
CSG2 refund configuration
A-382
OL-22840-05
Appendix A
CSG2 Command Reference retcode
Command History
Release 12.4(11)MD 12.4(15)MD
Modification This command was migrated from CSG1. Changes from CSG1: None. The ftp and sip keywords were added.
Usage Guidelines
The CSG2 supports return code-based refunding for all protocols except RTSP. The return codes are protocol-specific. For IMAP, keep in mind the following considerations:

Only return code 554 is used. Return code 554 is used when a transaction ending in an IMAP tagged response was not flagged OK. The CSG2 does not support refunding for IMAP. If configured, refunding for IMAP has no effect.
Examples
The following example shows how to specify ranges of application return codes:
ip csg refund COMPANY-REFUND retcode http 500 509 retcode sip 300 999 retcode wap 0x44 0x50
Related Commands
Command flags ip csg refund
Description Specifies protocol flag bit masks and values for CSG2 Prepaid Error Reimbursement. Specifies the CSG2 refund policy to apply to the various services, and enters CSG2 refund configuration mode.
A-383
Appendix A sami rate all
sami rate all

To specify the bit rate limit to be used by the Cisco Service and Application Module for IP (SAMI) for each PowerPCs (PPCs) traffic, CSG2 use the sami rate all command in global configuration mode. Use the no form of this command to disable this feature. sami rate bits-per-second all no sami rate bits-per-second all
Syntax Description
bits-per-second
Number of bits per second that the Cisco SAMI rate-limiting code is to allow to be forwarded to an individual PPC. The range is from 1 bps to 2 Gbps (0x80000000). The default value is 1.9 Gbps (0x70000000).
Command Default
The default rate is 1.9 Gbps (0x70000000).
Command Modes
Command History
Release 12.4(11)MD
Examples
The following example shows how to specify a bit rate limit of 1 Gbps (0x40000000):
sami rate 0x40000000 all
A-384
OL-22840-05
Appendix A
CSG2 Command Reference service
service
To associate a service with a CSG2 billing plan, use the service command in CSG2 billing configuration mode. To remove the association, use the no form of this command. service service-name [mode {postpaid | prepaid virtual}] no service service-name [mode {postpaid | prepaid virtual}]
Syntax Description
service-name mode postpaid mode prepaid virtual
Name of a configured CSG2 billing service. (Optional) Specifies a postpaid service. (Optional) Specifies a virtual prepaid service.
Command Default
If you do not specify the mode postpaid or mode prepaid virtual option, the service is prepaid.
Command Modes
Command History
Release 12.4(11)MD 12.4(22)MD 12.4(22)MDA
Modification This command was migrated from CSG1. Changes from CSG1: None. The mode postpaid keywords were added. The prepaid virtual keywords were added.
Usage Guidelines
To associate more than one service with the same billing plan, use multiple service commands. To specify a postpaid service for a user with a prepaid billing plan, use the service command with the mode postpaid option. To specify a virtual prepaid service for a user with a prepaid billing plan, use the service command with the mode prepaid virtual option. You cannot configure a virtual prepaid service under a postpaid billing plan.
Examples
The following example shows how to associate services MOVIES and BROWSING with billing plan REGULAR:
ip csg billing REGULAR service MOVIES service BROWSING
The following example shows how to associate postpaid service PREPAID with billing plan PLAN:
ip csg billing PLAN service PREPAID mode postpaid
A-385
Appendix A service
The following example shows how to associate virtual prepaid service VPREPAID with billing plan VPLAN:
ip csg billing VPLAN service VPREPAID mode prepaid virtual
Related Commands
Command entries user idle ip csg billing ip csg service mode qos profile (CSG2 billing) user-default
Description Sets the time after which entries for idle subscribers are deleted from the CSG2 User Table. Defines a CSG2 billing plan, and enters CSG2 billing configuration mode. Configures a CSG2 content billing service, and enters CSG2 service configuration mode. Specifies the mode for a CSG2 billing plan. Associates a Quality of Service (QoS) profile with a CSG2 billing plan. Designates a CSG2 billing plan as the default billing plan.
A-386
OL-22840-05
Appendix A
CSG2 Command Reference session-timeout (iSCSI)
session-timeout (iSCSI)
To specify the session timeout for an iSCSI target in the target interface profile on the CSG2, use the session-timeout command in iSCSI configuration mode. To restore the default timeout, use the no form of the command. session-timeout duration no session-timeout
Syntax Description
duration
Number of seconds the iSCSI initiator waits for a response from the iSCSI target, after which it closes the iSCSI session. The range is from 1 to 600. The default setting is 1 second.
Command Default
The default iSCSI target session timeout is 60 seconds.
Command Modes
iSCSI configuration
Command History
Release 12.4(15)MD
Examples
The following example configures an iSCSI target interface profile with the name targetA with a SCSI session timeout of 120 seconds:
Related Commands
Description Specifies the IP address of an iSCSI target in the target interface profile on the CSG2. Defines the delay interval, in seconds, before draining packets from the Storage Area Network (SAN) connected to the Internet Small Computer Systems Interface (iSCSI) when the Billing Mediation Agent (BMA) becomes active. Defines the number of packets to be drained from the Storage Area Network (SAN) connected to the Internet Small Computer Systems Interface (iSCSI) per drain delay interval when the Billing Mediation Agent (BMA) becomes active.
A-387
Appendix A session-timeout (iSCSI)
Command ip csg iscsi profile ip iscsi target-profile name (iSCSI) port (iSCSI) target-portal (iSCSI)
Description Specifies the Internet Small Computer Systems Interface (iSCSI) target to be used as backup storage for the CSG2. Creates an iSCSI profile for an iSCSI target on the CSG2, and enters iSCSI configuration mode. Specifies the name of an iSCSI target in the target profile on the CSG2 Specifies the number of the port on which to listen for iSCSI traffic in the iSCSI target interface profile on the CSG2. Specifies the portal group tag for an iSCSI target in the target interface profile on the CSG2.
A-388
OL-22840-05
Appendix A
CSG2 Command Reference show ip csg
show ip csg
To display information about the CSG2, use the show ip csg command in privileged EXEC mode. show ip csg { billing [plan billing-plan-name] [user count] | bma | content [name content-name] [detail | internal] | database | dns map [{ipv4-address | ipv6 ipv6-address} {global | vrf vrf-name}] | domain group [name domain-group-name] | event-trace packet [ status | match action {dropped | forwarded | queued} | match error {parse} | match ip {[global | vrf vrf-name] [subscriber subscriber-acl] [network network-acl]) | match protocol { dns | ftp [control | data] | http | imap | other | pop3 | radius [monitor | proxy] | rtsp [control | data] | sip [control | data] | smtp | wap [connectionless | connection-oriented] | } ]| gtp | iscsi [session-id] | license warning | load [history] | map | policy | preload [ billing | content | domain group | header | header group | map | policy | qos | service ]| psd | quota-server |
A-389
Appendix A show ip csg
qos [name qos-profile-name] | radius [name radius-name] | service | sessions { database | gtp | imap | ipc | radius | replicate | user { [application [internal]] [{ipv4-address ipv4-mask | ipv6 ipv6-prefix}] | } }| stats [accel | protocol] | user class [name user-class-name] | users { {ipv4-address ipv4-mask | ipv6 ipv6-prefix} | all | gx | id user-name | map } [header [service service-name]] } [detail]
Syntax Description
billing plan billing-plan-name user count bma
Displays information about billing plans (those that were configured via CLI and those that were preloaded). (Optional) Displays information about only the specified billing plan. (Optional) Displays user counts for billing plans. Displays information about the Billing Mediation Agents (BMAs) to which the CSG2 sends billing records. BMA statistics are reported for each BMA, in addition to an aggregate count for all BMAs. Displays information about the CSG2 content table (those that were configured via CLI and those that were preloaded). (Optional) Displays information about only the specified content. (Optional) Displays detailed information about the CSG2 content.
content name content-name detail
A-390
OL-22840-05
Appendix A
internal
(Optional) Displays internal CSG2 data structure information for use in debugging. We recommend that you enter this keyword only when directed to do so by Cisco Technical Assistance Center (TAC) engineers.
database dns map ipv4-address global ipv4-address vrf vrf-name
Displays information about the server that answers CSG2 user ID queries. Displays information about the DNS IP Map Table. (Optional) Display IPv4 information starting with the first entry. (Optional) Display IPv4 information starting with the entry that matches the specified subscriber IPv4 address and Virtual Routing and Forwarding (VRF) table.
Note
ipv6 ipv6-address global ipv6 ipv6-address vrf vrf-name
(Optional) Display IPv6 information starting with the first entry. (Optional) Display IPv6 information starting with the entry that matches the specified subscriber IPv6 address and Virtual Routing and Forwarding (VRF) table.
Note
domain group name domain-group-name event-trace packet
Displays information about the CSG2 domain groups (those that were configured via CLI and those that were preloaded). (Optional) Displays information about only the specified domain group. Displays the contents of the packet buffer for a specific traffic processor (TP), if entered on a TP; or for all of the TPs, if entered on the control processor (CP). (Optional) Displays the current status of packet loggingwhether it is enabled, the size of the packet buffer or buffers, and which filters, if any, are in effect. (Optional) Displays only those logged packets that were dropped by the CSG2. (Optional) Displays only those logged packets that were forwarded by the CSG2. (Optional) Displays only those logged packets that were temporarily queued by the CSG2. (Optional) Displays only those logged packets that could not be parsed by the CSG2. (Optional) Displays only those logged packets that arrived on interfaces attached to the default routing table.
status
match action dropped match action forwarded match action queued match error parse match ip global
A-391
match ip vrf vrf-name
(Optional) Displays only those logged packets that arrived on interfaces attached to the Virtual Routing and Forwarding (VRF) table.
Note
match ip subscriber subscriber-acl
(Optional) Displays only those logged packets whose subscriber IP addresses were permitted by the simple access control list (ACL) subscriber-acl. (Optional) Displays only those logged packets whose network IP addresses were permitted by the simple access control list (ACL) network-acl. (Optional) Displays only those logged packets that matched a content configured with parse protocol dns. (Optional) Displays only those logged packets that matched a content configured with parse protocol ftp. (Optional) Displays only those logged packets that belonged to FTP control sessions. (Optional) Displays only those logged packets that belonged to FTP data sessions. (Optional) Displays only those logged packets that matched a content configured with parse protocol http. (Optional) Displays only those logged packets that matched a content configured with parse protocol imap. (Optional) Displays only those logged packets that matched a content configured with parse protocol other. (Optional) Displays only those logged packets that matched a content configured with parse protocol pop3. (Optional) Displays only those logged packets that matched a content configured with parse protocol radius. (Optional) Displays only those logged packets that belonged to RADIUS monitor sessions. (Optional) Displays only those logged packets that belonged to RADIUS proxy sessions. (Optional) Displays only those logged packets that matched a content configured with parse protocol rtsp. (Optional) Displays only those logged packets that belonged to RTSP control sessions. (Optional) Displays only those logged packets that belonged to RTSP data sessions. (Optional) Displays only those logged packets that matched a content configured with parse protocol sip. (Optional) Displays only those logged packets that belonged to SIP control sessions. (Optional) Displays only those logged packets that belonged to SIP data sessions. (Optional) Displays only those logged packets that matched a content configured with parse protocol smtp.
match ip network network-acl
match protocol dns match protocol ftp control data match protocol http match protocol imap match protocol other match protocol pop3 match protocol radius monitor proxy match protocol rtsp control data match protocol sip control data match protocol smtp
A-392
OL-22840-05
Appendix A
match protocol wap connectionless connection-oriented gtp header name header-name header group name header-group-name iscsi session-id license warning load history map policy preload billing content domain-group header header-group map qos policy
(Optional) Displays only those logged packets that matched a content configured with parse protocol wap. (Optional) Displays only those logged packets that belonged to WAP connectionless sessions. (Optional) Displays only those logged packets that belonged to WAP connection-oriented sessions. Displays information about the general packet radio service (GPRS) tunneling protocol (GTP). Displays information about the CSG2 headers (those that were configured via CLI and those that were preloaded). (Optional) Displays information about only the specified header. Displays information about the CSG2 header groups (those that were configured via CLI and those that were preloaded). (Optional) Displays information about only the specified header groups. Displays information about the Internet Small Computer Systems Interface (iSCSI). (Optional) Displays information for only the specified iSCSI session. Displays information about the configured subscriber threshold. Displays information about load management. (Optional) Displays histograms of recent load management activity. Displays information about maps (those that were configured via CLI and those that were preloaded). Displays information about policies (those that were configured via CLI and those that were preloaded). Displays information about all Gx policy preloaded objects. (Optional) information about the Gx policy preloaded billing plan definitions. (Optional) information about the Gx policy preloaded content definitions. (Optional) information about the Gx policy preloaded domain group definitions. (Optional) information about the Gx policy preloaded header definitions. (Optional) information about the Gx policy preloaded header group definitions. (Optional) information about the Gx policy preloaded map definitions. (Optional) information about the Gx policy preloaded Quality of Service (QoS) definitions. (Optional) information about the Gx policy preloaded policy definitions.
A-393
service psd quota-server radius service sessions database gtp imap ipc other pop3 qos name qos-profile-name radius name radius-name
(Optional) information about the Gx policy preloaded service definitions. Displays information about the Cisco Persistent Storage Device (PSD) functionality residing on the CSG2. Displays information about the quota servers. Displays information about RADIUS. Displays information about services (those that were configured via CLI and those that were preloaded). Displays information about sessions. Displays information about only the user database sessions. Displays information about only the GTP sessions. Displays information about only the Internet Message Access Protocol (IMAP) sessions. Displays information about only the Interprocessor Communication (IPC) sessions. Displays information about all other Layer 3 and Layer 4 sessions. Displays information about only the Post Office Protocol, version 3 (POP3) sessions. Displays information about the CSG2 QoS profiles (those that were configured via CLI and those that were preloaded). (Optional) Displays information about only the specified QoS profile. Displays information about only the RADIUS sessions. (Optional) Displays information about only the RADIUS sessions associated with the specified RADIUS attribute. If detail is also specified, displays detailed information about the RADIUS sessions, including a list of all user classes that reference the specified RADIUS attribute.
replicate smtp user
Displays information about only high availability (HA) sessions. Displays information about only the Simple Mail Transfer Protocol (SMTP) sessions. Displays information about only subscriber sessions.
A-394
OL-22840-05
Appendix A
application
(Optional) Displays information about only the specified application:

accel httpDisplays information about accelerated HTTP subscriber sessions. accel nbarDisplays information about accelerated NBAR subscriber sessions. accel otherDisplays information about other accelerated subscriber sessions, such as IP, TCP, or User Datagram Protocol (UDP) dnsDisplays information about DNS subscriber sessions. ftpDisplays information about FTP subscriber sessions. httpDisplays information about HTTP subscriber sessions. imapDisplays information about IMAP subscriber sessions. nbarDisplays information about subscriber sessions that were classified by Network Based Application Recognition (NBAR). otherDisplays information about other subscriber sessions. pop3Displays information about POP3 subscriber sessions. rtspDisplays information about RTSP subscriber sessions. sipDisplays information about SIP subscriber sessions. smtpDisplays information about SMTP subscriber sessions. wapDisplays information about WAP subscriber sessions.
internal
(Optional) Displays internal CSG2 data structure information for use in debugging. We recommend that you enter this keyword only when directed to do so by Cisco Technical Assistance Center (TAC) engineers.
ipv4-address ipv4-mask
(Optional) Displays information about only the specified subscriber IPv4 address and subscriber IPv4 address mask. Specify IPv4 address 0.0.0.0 to display information about all subscriber IPv4 addresses. Specify IPv4 address mask 0 to display information about all subscriber IPv4 address masks.
ipv6 ipv6-prefix
(Optional) Displays information about only the specified subscriber IPv6 prefix.
A-395
stats
Displays performance statistics for the CSG2. You can also use the following commands to monitor CSG2 high availability (HA) configurations: show redundancy state, show redundancy interdev, and show ipc sctp. For sample output for the show ip csg stats command, including descriptions of each displayed field, see the Field Descriptions for CSG2 Statistics section on page B-1.
accel protocol
(Optional) Displays performance statistics for accelerated sessions. (Optional) Displays performance statistics per protocol for the CSG2.

If entered on a traffic processor (TP), statistics are displayed for only that TP. If entered on the control processor (CP), statistics are displayed for the CP and all of the TPs.
The CSG2 displays statistics for only those protocols that were configured with a parse protocol command and that were brought in service. The statistics displayed are mean statistics, averaged over a configurable rate calculation interval. See the description of the ip csg statistics protocol interval command for more information.
Note
For the SIP protocol, the statistics are displayed under two separate headings, SIP control and SIP data. The CSG2 tracks each SIP call as a single transaction. To prevent confusion, the CSG2 reports the total number of SIP transactions only under the SIP control heading, in the Total Transactions field. The Total Transactions field under the SIP data heading always displays a value of zero.
user class name user-class-name users
Displays information about only the configured user classes. (Optional) Displays information about only the specified user class. Displays information about subscribers.
Note
If the basis second connect command is configured, the balance and consumed fields in the output of the show ip csg users command are updated only when there is a Service Reauthorization Request for new quota.
ipv4-address ipv4-mask
Displays information about only the specified subscriber IPv4 address and subscriber IPv4 address mask. Specify IPv4 address 0.0.0.0 to display information about all subscriber IPv4 addresses. Specify IPv4 address mask 0 to display information about all subscriber IPv4 address masks.
A-396
OL-22840-05
Appendix A
ipv6 ipv6-prefix all gx id user-name map header
Displays information about only the specified subscriber IPv6 prefix. Displays information about all subscribers. Displays information about the Gx charging rules. Displays information about the specified user ID. Displays the User Table mapping of IPv4 addresses for subscribers. (Optional) Displays the header insertion data that is to be inserted in requests for the specified subscriber IPv4 address and subscriber IPv4 address mask; for the specified user ID; or for all subscribers. The CSG2 displays any non-printable characters in two-digit hexadecimal format, preceded and followed by periods (.). For example, the CSG2 displays 08 as .08.
service service-name detail
(Optional) Displays the header insertion cache entries for only the specified service. (Optional) Displays more detailed information.
Command Default
None
Command Modes
Privileged EXEC
Command History
Release 12.4(11)MD

show ip csg accounting show module csg content show module csg stats
12.4(15)MD 12.4(22)MD 12.4(22)MDA
The billing, ftp, gtp, history, iscsi, load, plan, and sip keywords and billing-plan-name argument were added. The license warning keyword was added. The connectionless, connection-oriented, control, data, event-trace packet, gx, map, match action dropped, match action forwarded, match action queued, match error parse, match ip global, match ip network, match ip subscriber, match ip vrf, match protocol ftp, match protocol http, match protocol imap, match protocol other, match protocol pop3, match protocol radius, match protocol rtsp, match protocol sip, match protocol smtp, match protocol wap, monitor, policy, preload, protocol, proxy, service, and status keywords were added. The network-acl, subscriber-acl, and vrf-name arguments were added.
A-397
Release 12.4(24)MD
Modification The dns, dns map, domain group, name, radius, service, user class, and user count keywords were added. The domain-group-name, radius-name, service-name, and session-id arguments were added. The header and qos keywords were added for the preload keyword. The show ip csg sessions user command now accepts the dns keyword for the application argument. The output of the show ip csg content name command was updated to reflect domain groups. The output of the show ip csg stats command was updated to reflect DNS IP Map Table statistics. The output of the show ip csg users command was updated to reflect the eGGSN quota server mode of operation for each user.
12.4(24)MD1
The header, header group, and qos keywords were added. The header-name, header-group-name, and qos-profile-name arguments were added. The domain group and header group keywords were added for the preload keyword. The output of the show ip csg users detail command was updated to reflect the Subscriber Sign-On Timestamp and User Table Entry Creation Time fields.
12.4(24)MDA
The ipv6 keyword and ipv6-prefix argument were added for the dns map keyword. The ip keyword was removed for the dns map keyword. The ipv6 keyword and ipv6-prefix argument were added for the sessions keyword. The accel http, accel nbar, and accel other options were added for the sessions user keyword. The accel keyword was added for the stats keyword. The ipv6 and map keywords and the ipv6-prefix argument were added for the users keyword. The output of the following commands was updated to reflect support for IPv6 addresses:

show ip csg content show ip csg dns map show ip csg preload content show ip csg sessions show ip csg stats show ip csg users
A-398
OL-22840-05
Appendix A
Usage Guidelines
In the output of the show ip csg content command, the CSG2 might truncate some fields, such as the VRF name and the domain name. Entering the show ip csg users all command might flood your screen with output. If you want to display the contents of the packet buffer (using the event-trace packet option) and its sub-options, keep the following considerations in mind:
Before entering the show ip csg command, disable packet logging using the no form of the ip csg event-trace packet enable command. Otherwise, the CSG2 might log new packets at the same time it is displaying the contents of the packet buffer, resulting in output that might not be useful. Unless you are certain that you need the contents of the packet buffer on only one traffic processor (TP), enter the show ip csg command on the control processor (CP). Doing so displays the contents of all packet buffers on all of the TPs. To avoid flooding the console or virtual terminal with the contents of the packet buffers, consider redirecting the output of the show ip csg command to a file.
Examples
For sample output for the show ip csg stats command, including descriptions of each displayed field, see the Field Descriptions for CSG2 Statistics section on page B-1. The following example shows how to display the statistics count, rate, maximum rate, and maximum rate timestamp for the transaction, byte count, and packet count for each of the protocols that is configured on the CSG2; the statistics for HTTP are shown.
Router# show ip csg stats protocol Protocol http Stats: Total Transactions: 0 Transaction Rate: 0.000/sec Peak Transaction Rate: 0.000/sec Peak Transaction Rate Timestamp: 20090603-171440 Outgoing Traffic Subscriber to Network Total Packets: 0 Packet Rate: 0.000/sec Peak Packet Rate: 0.000/sec Peak Packet Rate Timestamp: 20090603-171440 Total Bytes: 0 Bit Rate: 0.000/sec Peak Bit Rate: 0.000/sec Peak Bit Rate Timestamp: 20090603-171440 Network to Subscriber Total Packets: 0 Packet Rate: 0.000/sec Peak Packet Rate: 0.000/sec Peak Packet Rate Timestamp: 20090603-171440 Total Bytes: 0 Bit Rate: 0.000/sec Peak Bit Rate: 0.000/sec Peak Bit Rate Timestamp: 20090603-171440
Note
For IP, TCP, and UDP accounting, the Transaction Rate fields display the Layer 4 transaction rates. For all other protocols, the Transaction Rate fields display the Layer 7 transaction rates. To configure the interval, in seconds, that the CSG2 is to use when calculating the rates for this command, use the ip csg statistics protocol interval command in global configuration mode.
A-399
The following example shows how to display the statistics and counters for CSG2 billing plan BILLPLAN:
Router# show ip csg billing plan BILL user count CSG billing plan - BILLPLAN Count = 6, Highwater Count = 9 preload = 0, mode = PREPAID idle = 0, offline = 1, flags = 0x0000 service = S, basis = IP bytes, reauth threshold = 10000000, mode = prepaid record granularity = transaction
The following example shows how to display the statistics and counters for CSG2 content:
Router# show ip csg content CSG content = CsgCg01, state = INSTALLED destination = 0.0.0.0/0:6000 protocol = UDP, vlan = ANY, domain group = all CSG content = CsgCg11, state = INSTALLED destination = 0.0.0.0/0:7000 protocol = UDP, vlan = ANY, domain group = all CSG content = CsgRadProxy1, state = INSTALLED destination = 10.15.20.152/32:0 protocol = UDP, vlan = ANY, domain group = all CSG content = DNS_CONTENT, state = INSTALLED destination = 0.0.0.0/0:53 protocol = UDP, vlan = ANY, domain group = all CSG content = HTTP6_CON, state = OUTOFSERVICE destination = [FC: :A1:C000/116]:80 protocol = TCP, vlan = ANY, domain group = all CSG content = HTTP_CON, state = INSTALLED destination = 0.0.0.0/0:80 protocol = TCP, vlan = ANY, domain group = all
The following example shows how to display detailed statistics and counters for the CSG2 HTTP content named HTTP:
Router# show ip csg content name HTTP detail CSG content = HTTP, state = OUTOFSERVICE destination = 0.0.0.0/0:80 protocol = TCP, vlan = ANY, domain group = all preload = 0, parse type = http:none, index = 7 idle = 300, pending = 30, replicate = None, max parse len = 4000 total sessions = 0, current sessions = 0, control-url = No ipv4 nexthop = 12.34.56.78 ipv4 nexthop reverse = 1.2.3.4 ipv6 nexthop = fc00: :1e:210f ipv6 nexthope reverse = fc00: :2c:101c nexthop override = FALSE replicate delay = 0, cdr delay = 0 interim bytes = 0, interim time = 0 regex memory usage = 0 subscriber paks = 0, network paks = 0 match attribute count = 0 match url count = 0 match method count = 0 match header count = 0
A-400
OL-22840-05
Appendix A
policy transactions priority --------------------------------------------(none) 0 0
The following example shows how to display information about the quota server:
Router# show ip csg quota-server charging gateway vrf priority state -------------------------------------------------------------------------10.18.28.10:3385 1 ACTIVE
The following example shows how to display information about sessions for FTP IPv4 subscriber 1.2.3.4/24:
Router# show ip csg sessions user ftp 1.2.3.4/24 subscriber = 1.2.3.22:38418 network = 10.15.20.101:80, prot = 6, state = ESTAB subscriber = 1.2.3.61:27746 network = 10.15.20.121:80, prot = 6, state = ESTAB
Note
The prot field displays the IPv4 protocol as described in the Assigned Numbers RFC. The following table lists and describes the possible states for all show ip csg sessions user commands: State1 INIT Description The session has been created but no packet has been processed. Short timer.2 SYN_SUB A SYN packet has been received from the subscriber interface. Short timer.2 SYN_NET A SYN packet has been received from the network interface. Short timer.2 SYN_BOTH The session has received a SYN packet from both the subscriber and network interfaces. Short timer.2 SETUP_ACK_SUB_WAIT The session has received a SYN-ACK from the network interface and is waiting for the ACK from the subscriber interface to complete the TCP 3-way handshake. Short timer.2 SETUP_ACK_NET_WAIT The session has received a SYN-ACK from the subscriber interface and is waiting for the ACK from the network interface to complete the TCP 3-way handshake. Short timer.2
A-401
State1 ESTAB
Description The TCP session has been established. UDP sessions enter this state on the first packet. This is the only state for UDP sessions after INIT.
FIN_SUB FIN_NET FIN_SUB_WAIT
The session has received a FIN from the subscriber interface The session has received a FIN from the network interface The session has received an ACK from the subscriber interface and is waiting for a FIN from the subscriber interface The session has received an ACK from the network interface and is waiting for a FIN from the network interface The session has received a FIN from both the subscriber and network interfaces The session has received a FIN-ACK or a FIN and an ACK from the subscriber interface and is waiting for the ACK from the network interface to close the connection. Short timer.2 The session has received a FIN-ACK or a FIN and an ACK from the network interface and is waiting for the ACK from the subscriber interface to close the connection. Short timer.2 The session is closed. Note that closed sessions are destroyed so it is very unlikely that show session will display a session in this state.
FIN_NET_WAIT
FIN_BOTH CLOSING_ACK_NET_WAIT
CLOSING_ACK_SUB_WAIT
CLOSED
1. TCP sessions use all these states. UDP sessions move from INIT state directly to ESTAB state. 2. Short timer indicates that the state uses a 5-second idle time regardless of what is configured in the content. All other states use the configured idle time.
The following example shows how to display information about sessions for FTP IPv6 subscriber 12AB:0000:0000:CD31:0000:0000:0000:0000/64:
Router# show ip csg sessions user ftp ipv6 12AB:0000:0000:CD31:0000:0000:0000:0000/64 subscriber = [12AB:0:0:CD31: :cc1a]:21443 network = [fc00: :1e:133f]:80, prot = 6, state = ESTAB
The following example shows how to display detailed information about sessions for HTTP subscribers:
Router# show ip csg sessions user http detail subscriber = 10.15.30.102:36112, vrf = myvrf network = 10.15.20.101:80, prot = 6, state = ESTAB downlink next-hop = , uplink next-hop = content = HTTP_CON, appl type = http
A-402
OL-22840-05
Appendix A
flags = 1C04A04, prot_type = TCP sub next seq num = 4071554747 net next seq num = 305219224 sub OOO queue depth = 0 net OOO queue depth = 0 sub Uncounted SN queue depth (main/aux) = 0 / 0 net Uncounted SN queue depth (main/aux) = 0 / 0 Setaside = Next trans id = 2 Trans id = 1, ip = 10.15.30.102 uid = PEACH Weight = 0, Usage = 0, TXN flags = 0x800 Policy = (0) none, Kut_svc = none Sub eoh eomb Net eoh eomb content-length content-type Sub sn beg = 0xF2AEFE95, end = 0xF2AEFEBB bytes tcp = 38, ip = 142, pkt = 2 Net sn beg = 0x12314591, end = 0x12314698, bytes tcp = 263, ip = 315, pkt = 1 Method = (0) Not available Url = (0) Not available
The following example displays detailed information about sessions for the subscriber at 188.57.37.198/32:
Router# show ip csg sessions users 188.57.37.198/32 detail subscriber = 188.57.37.198:49663, vrf = Cisco-Local network = 86.108.130.72:80, prot = 6, state = ESTAB downlink next-hop = 0.0.0.0, uplink next-hop = 0.0.0.0 content = INT-IC-HTTP1, appl type = http flags = 104A04, prot_type = TCP sub next seq num = 581407307 net next seq num = 2382871877 sub OOO queue depth = 0 net OOO queue depth = 0 sub Uncounted SN queue depth (main/aux) = 0 / 0 net Uncounted SN queue depth (main/aux) = 0 / 0 Setaside = Next trans id = 1 Trans id = 0, ip = 188.57.37.198, vrf = Cisco-Local uid = 905305147266 Weight = 1, Usage = 412141, TXN flags = 9000 Policy = (16) INT-IC-P88, Kut_svc = IPHONE_MTV_FREE Sub eoh eomb Net eoh eomb content-length content-type Sub sn beg = 0x22A7911D, end = 0x22A7924B bytes tcp = 301, ip = 6085, pkt = 111 Net sn beg = 0x8E01C4A5, end = 0x8E07BD45, bytes tcp = 391328, ip = 406056, pkt = 283 Method = (0) Not available URL = (0) Not available
The following table lists and describes all of the fields in the output for the show ip csg sessions users detail command: Field subscriber vrf network Description Subscribers IP address VRF table used for the session Network used for the session
A-403
Field prot state downlink next-hop uplink next-hop content appl type flags prot_type sub next seq num net next seq num sub OOO queue depth net OOO queue depth sub Uncounted SN queue depth (main/aux) net Uncounted SN queue depth (main/aux) Setaside Next trans id Trans id ip vrf uid Weight Usage TXN flags Policy Kut_svc sub eoh eomb net eoh eomb content-length content-type Sub sn beg Sub end Sub bytes tcp Sub bytes ip Sub pkt Net sn beg
Description IP protocol used by the session, as described in the Assigned Numbers RFC State of the session; see Table A-1 for descriptions of valid states Downlink next-hop IP address for the session Uplink next-hop IP address for the session Name of the content associated with the session Application type associated with the session Flags associated with the session Prototype associated with the session Next entry in the sessions subscriber-side sequence number queue Next entry in the sessions network-side sequence number queue Number of entries in the sessions subscriber-side out-of-order queue Number of entries in the sessions network-side out-of-order queue Number of entries in the sessions subscriber-side Uncounted SN (sequence number) queue Number of entries in the sessions network-side Uncounted SN (sequence number) queue Number of packets queued in the sessions setaside ID of the next transaction ID of the current transaction IP address of the transaction VRF table used by the transaction User ID of the transaction Weight assigned to the transaction Total number of IP bytes, subscriber-side and network-side, consumed by the transaction Flags associated with the transaction Policy associated with the transaction CS2 User Table service associated with the transaction Internal Cisco Use Internal Cisco Use Beginning subscriber-side sequence number for the transaction Ending subscriber-side sequence number for the transaction Number of subscriber-side TCP bytes consumed by the transaction Number of subscriber-side IP bytes consumed by the transaction Number of subscriber-side packets sent over the transaction Beginning network-side sequence number for the transaction
A-404
OL-22840-05
Appendix A
Field Net end Net bytes tcp Net bytes ip Net pkt Method URL
Description Ending network-side sequence number for the transaction Number of network-side TCP bytes consumed by the transaction Number of network-side IP bytes consumed by the transaction Number of network-side packets sent over the transaction Method associated with the transaction, if available URL associated with the transaction, if available
Table A-1 lists and describes the valid states for the show ip csg sessions user command:
Table A-1 Session States for the show ip csg users Command
State1 INIT SYN_SUB SYN_NET SYN_BOTH
Description The session has been created but no packet has been processed. Short timer.2 A SYN packet has been received from the subscriber interface. Short timer.2 A SYN packet has been received from the network interface. Short timer.2 The session has received a SYN packet from both the subscriber and network interfaces. Short timer.2 The session has received a SYN-ACK from the network interface and is waiting for the ACK from the subscriber interface to complete the TCP 3-way handshake. Short timer.2 The session has received a SYN-ACK from the subscriber interface and is waiting for the ACK from the network interface to complete the TCP 3-way handshake. Short timer.2 The TCP session has been established. UDP sessions enter this state on the first packet. This is the only state for UDP sessions after INIT.
SETUP_ACK_SUB_WAIT
SETUP_ACK_NET_WAIT
ESTAB
FIN_SUB FIN_NET FIN_SUB_WAIT FIN_NET_WAIT FIN_BOTH
The session has received a FIN from the subscriber interface The session has received a FIN from the network interface The session has received an ACK from the subscriber interface and is waiting for a FIN from the subscriber interface The session has received an ACK from the network interface and is waiting for a FIN from the network interface The session has received a FIN from both the subscriber and network interfaces
A-405
Table A-1
Session States for the show ip csg users Command
State1 CLOSING_ACK_NET_WAIT
Description The session has received a FIN-ACK or a FIN and an ACK from the subscriber interface and is waiting for the ACK from the network interface to close the connection. Short timer.2 The session has received a FIN-ACK or a FIN and an ACK from the network interface and is waiting for the ACK from the subscriber interface to close the connection. Short timer.2 The session is closed. Note that closed sessions are destroyed so it is very unlikely that show session will display a session in this state.
CLOSING_ACK_SUB_WAIT
CLOSED
1. TCP sessions use all these states. UDP sessions move from INIT state directly to ESTAB state. 2. Short timer indicates that the state uses a 5-second idle time regardless of what is configured in the content. All other states use the configured idle time.
The following example displays detailed information about the subscriber at 6.1.3.1/32:
Router# show ip csg users 6.1.3.1/32 detail 6.1.3.1 ixia100770 vrf = <VRF>, create time = 15:39:41 EST Nov 7 2010 sessions = 0, traffic proc id = 4 nexthop downlink ip = 0.0.0.0, flags = 0x00000401 nas = <NAS-IP>, vrf = <VRF>, geo_user = no idle = 86400, PoD = no billing = PREPAID, plan = <Billing-plan-name>, handoff timer OFF, idle timer ON bma: ip = 0.0.0.0, port = 0 quota-server: ip = <quota-server-ip>, port = 3386 affinity: state = OPEN, kut_seq = 1273491767, profile = (none) 3gpp_eps = 0, CoA: enabled = 0 Report attributes: R ,019:32343431313339 R ,010:00000000 R ,011:69782D66696C7465722D766572792D6C6F6E67 R ,012:000005DC R ,013:00000000 R ,014:C6120001 R ,015:00000000 R ,020:69786C6F61642D6B6F6C2D6C6F6E672D737472696E67 R ,030:313131383830 R ,031:313131383830 R ,041:00000001 R ,026:0000000901246E73643A6F7074696E5F636C6173733D6164635F747269616C... R ,026:0000000901266E73643A6F70746F75745F636C6173733D6164635F6F75742C... R ,008:06010301 R ,001:69786961313030373730 service = <service-name>, basis = IP bytes rating group = o verify = Disabled balance = 31449846, consumed = 7434 reserved = 0, pending = 0, trigger = 7864320 current time = 17:39:57 EST Jan 6 2010 quota expiry = 20:33:45 EST Jan 6 2010 idle expiry = 21:36:34 EST Jan 6 2010
A-406
OL-22840-05
Appendix A
earliest reauth = 17:39:57 EST Jan 6 2010 meter: imap = all exclude mms wap = 0 service id = 0x4B2997DD05D8B901, transactions = 0, flags = 0x0020 interval bytes up = 4792 interval bytes down = 2642 interval seconds = 170 interval first billable = 17:33:45 EST Jan 6 2010 interval last billable = 17:36:34 EST Jan 6 2010 service = <service-name2>, basis = IP bytes rating group = o verify = Disabled balance = 219926, consumed = 66794 reserved = 0, pending = 0, trigger = 71680 current time = 17:39:57 EST Jan 6 2010 quota expiry = 20:33:44 EST Jan 6 2010 idle expiry = 21:37:31 EST Jan 6 2010 earliest reauth = 17:39:57 EST Jan 6 2010 meter: imap = all exclude mms wap = 0 service id = 0x4B2997DD05D8B8A9, transactions = 0, flags = 0x0020 interval bytes up = 42081 interval bytes down = 24713 interval seconds = 227 interval first billable = 17:33:44 EST Jan 6 2010 interval last billable = 17:37:31 EST Jan 6 2010
The following table lists and describes all of the fields in the output for the show ip csg users detail command: Field 6.1.3.1 ixia100770 vrf create time sessions traffic proc id nexthop downlink ip nexthop uplink id flags nas vrf geo_user idle PoD billing plan handoff timer idle timer bma: ip bma: port Description IP address Mobile address VRF table used by the subscriber Date and time that the User Table entry for the subscriber was created Number of sessions currently associated with the subscriber Traffic Processor (TP) ID for the subscriber Downlink next-hop IP address for the subscriber Downlink next-hop IP address for the subscriber Flags associated with the subscriber NAS IP address for the subscriber VRF table used by the subscriber Geographical high availability redundancy setting for the subscriber Setting of the CSG2 User Table idle timer, in seconds PoD setting for the subscriber Type of billing plan associated with the subscriber Name of the billing plan associated with the subscriber Setting of the handoff timer for the subscriber Setting of the idle timer for the subscriber BMA IP address for the subscriber BMA port number for the subscriber
A-407
Field quota server: ip quota server: port affinity: state affinity: kut_seq affinity: profile 3gpp_eps CoA: enabled attributes:
Description Quota server IP address for the subscriber Quota server port number for the subscriber Affinity state for the subscriber Affinity User Table sequence number for the subscriber Affinity profile for the subscriber 3GPP EPS setting for the subscriber CoA setting for the subscriber RADIUS attributes and VSA subattributes reported for the subscriber

RThe CSG2 is to report the attribute in BMA and quota server GTP' messages. GThe attribute is for use by Gx interface.
service basis rating group verify balance consumed reserved pending trigger current time quota expiry idle expiry earliest reauth meter: imap service id transactions flags interval bytes up interval bytes down interval seconds interval first billable interval last billable
Name of a service associated with the subscriber Billing basis of the service Rating group of the eG-CDR service Service verification setting of the service Quota balance remaining for the service Quota consumed by the service Quota reserved by the service Pending quota for the service Quota reauthorization threshold for the service Current date and time, in Coordinated Universal Time (UTC) format Date and time, in Coordinated Universal Time (UTC) format, that the quota for the service will expire Date and time, in Coordinated Universal Time (UTC) format, that the idle timer for the service will expire Date and time, in Coordinated Universal Time (UTC) format, of the next quota authorization for the service Include setting for IMAP bytes for the service Service ID Current transactions associated with the service Transaction flags associated with the service Number of bytes uploaded for the service during the rate calculation interval Number of bytes downloaded for the interval during the rate calculation interval Rate calculation interval, in seconds Date and time, in Coordinated Universal Time (UTC) format, of the beginning of the most recent rate calculation interval for the service Date and time, in Coordinated Universal Time (UTC) format, of the end of the most recent rate calculation interval for the service
meter: exclude mms wap Exclude setting for WAP MMS bytes for the service
A-408
OL-22840-05
Appendix A
The following example displays detailed information about all subscribers:

Router# show ip csg users all detail user id: USER-A ip address = 10.15.30.114 create time = 12:50:08 UTC Mar 24 2010 sessions = 0, traffic proc id = 4, seq = 1269435008 nexthop downlink ip = NULL nexthop uplink ip = NULL nas = 80.80.97.181 flags = 0x00000001, geo_user = no, idle = 0, PoD = no billing = POSTPAID, plan = (none), handoff timer OFF, idle timer OFF bma: ip = 0.0.0.0, port = 0 quota-server: ip = 0.0.0.0, port = 0 affinity: state = OPEN, kut_seq = 1269435008, profile = (none) 3gpp_eps = 0, CoA: enabled = 0 user id:USER-B ip address = fc00:1010: : create time = 12:50:08 UTC Mar 24 2010 sessions = 0, traffic proc id = 4, seq = 1269435008 nexthop downlink ip = NULL nexthop uplink ip = NULL, nas = fc: :1010:1acc:a0 flags = 0x00000001, geo_user = no, idle = 0, PoD = no billing = POSTPAID, plan = (none), handoff timer OFF, idle timer OFF bma: ip = 0.0.0.0, port = 0 quota-server: ip = 0.0.0.0, port = 0 affinity: state = OPEN, kut_seq = 1269435008, profile = (none) 3gpp_eps = 0, CoA: enabled = 0
The following example displays information about the DNS IP Map Table:
Router# show ip csg dns map ----------- Slot 4/CPU 3, show ip csg dns map ----------------------- Slot 4/CPU 4, show ip csg dns map ------------Index IP Address ----------------16878 69.147.125.65 domain group = BIGBOYS, hits = 0, TTL = 9 sec 29539 2001:4860:b009: :63 domain group = BIGBOYS, hits = 0, TTL = 12 sec 52391 72.163.4.161 domain group = BIGBOYS, hits = 0, TTL = 18 sec ----------- Slot 4/CPU 5, show ip csg dns map ------------% DNS IP Map Table is empty ----------- Slot 4/CPU 6, show ip csg dns map ------------% DNS IP Map Table is empty ----------- Slot 4/CPU 7, show ip csg dns map ------------% DNS IP Map Table is empty ----------- Slot 4/CPU 8, show ip csg dns map ------------% DNS IP Map Table is empty
The following example displays information about domain group PARTNER:

Router# show ip csg domain group name PARTNER
A-409
Domain group = PARTNER, Priority = 10, Preloaded = 0 match = *VF.com match = *vf.com match = *partner.com
The following example displays information about CSG2 contents that have been preloaded:
Router# show ip csg preload content CSG content = UT_PRE_CONTENTA, state = OUTOFSERVICE destination = 1.1.1.1/32 protocol = Any, vlan = ANY, domain group = all preload = 1, parse type = other:none, index = 7 idle = 300, pending = 30, replicate = None, max parse len = 4000 total sessions = 0, current sessions = 0, control-url = No replicate delay = 0, cdr delay = 0 interim bytes = 0, interim time = 0 regex memory usage = 0 subscriber paks = 0, network paks = 0 match attribute count = 0 match url count = 0 match method count = 0 match header count = 0 policy transactions priority --------------------------------------------(none) 0 0
A-410
OL-22840-05
Appendix A
CSG2 Command Reference show ip iscsi
show ip iscsi
To display information about the iSCSI, use the show ip iscsi command in privileged EXEC mode. show ip iscsi {name | session [session-id] [detail] | stats [detail] | target}
Syntax Description
name session session-id detail stats detail target
Displays the name of an iSCSI initiator. Displays the status of iSCSI sessions on the CSG2. (Optional) Displays information for only the specified iSCSI session. (Optional) Displays detailed information about the iSCSI session. Displays iSCSI statistics. (Optional) Displays detailed iSCSI statistics. Displays information about an iSCSI target.
Command Default
Command Modes
Privileged EXEC
Command History
Release 12.4(15)MD
Examples
The following example shows output from the show ip iscsi name command:
Router# show ip iscsi name iSCSI initiator name: iqn.1987-07.com.cisco:wtbg-sup-09-3
The following example shows output from the show ip iscsi session command:
Router# show ip iscsi session ID TARGET STATE CONNECTIONS -------------------------------------------------------------12 LINUX Logged In 1
The following example shows output from the show ip iscsi session detail command:
Router# show ip iscsi session detail ID: 12 Profile: LINUX State: Logged In Connections: 1 First Burst Length: 16384 Max Burst Length: 16384 Max Recv Data Segment: 32768 Max Xmit Data Segment: 8192 Initial R2T: Yes Immediate data: Yes Data PDU in order: Yes Data PDU in order: Yes
A-411
Appendix A show ip iscsi
The following example shows output from the show ip iscsi stats command:
Router# show ip iscsi stats iSCSI Stats: Login Requests - 2, Login Responses - 2 Logout Requests - 0, Logout Responses - 0 Login Timeouts - 0, Logout Timeouts - 0 SCSI Commands - 27, SCSI Responses - 27 Data In PDUs - 25, Data Out PDUs - 0 Immed Data - 1, Unsolicited Data - 0 NOP Ins - 35, NOP Outs - 35 Async Requests - 0, Async Req Logout - 0 Async Drop Conn - 0, Async Drop Conns - 0 R2t Requests - 0, Rejects - 0 System Stats: TX Queue Overflow - 0, RX Queue Overflow - 0 Connection Resets - 0, Tasks aborted - 0 SCSI Stats: Total Requests - 27 Test Unit Ready Requests - 1, Test Unit Ready Failures - 0 Report Luns Requests - 1, Report Luns Failures - 0 Lun Inquiry Requests - 5, Lun Inquiry Failures - 0 Read Capacity Requests - 5, Read Capacity Failures - 0 Read Requests - 14, Read Failures - 0 Write Requests - 1, Write Failures - 0 Blocks Read- 49, Blocks Written - 8
The following example shows output from the show ip iscsi stats detail command:
Router# show ip iscsi stats detail iSCSI Stats: Login Requests - 2, Login Responses - 2 Logout Requests - 0, Logout Responses - 0 Login Timeouts - 0, Logout Timeouts - 0 SCSI Commands - 27, SCSI Responses - 27 Data In PDUs - 25, Data Out PDUs - 0 Immed Data - 1, Unsolicited Data - 0 NOP Ins - 36, NOP Outs - 36 Async Requests - 0, Async Req Logout - 0 Async Drop Conn - 0, Async Drop Conns - 0 R2t Requests - 0, Rejects - 0 System Stats: TX Queue Overflow - 0, RX Queue Overflow - 0 Connection Resets - 0, Tasks aborted - 0 SCSI Stats: Total Requests - 27 Test Unit Ready Requests - 1, Test Unit Ready Failures - 0 Report Luns Requests - 1, Report Luns Failures - 0 Lun Inquiry Requests - 5, Lun Inquiry Failures - 0 Read Capacity Requests - 5, Read Capacity Failures - 0 Read Requests - 14, Read Failures - 0 Write Requests - 1, Write Failures - 0 Blocks Read- 49, Blocks Written - 8
A-412
OL-22840-05
Appendix A
CSG2 Command Reference show ip iscsi
The following example shows output from the show ip iscsi target command:
Router# show ip iscsi target Target Profile= TARGET_LINUX IN_USE Target: name= iqn.2002-10.edu.unh.iol.iscsi.draft20-target:1 Target: ip= 10.76.43.233, port= 3260, portal group= 0 vrf= , sync read offset= 100, batch write= 100 write interval= 5 sec, file size= 100 MB #
A-413
Appendix A show mpcc
show mpcc
To display information about the various Mobile PCC components, use the show mpcc command in privileged EXEC mode. show mpcc { {errors | stats} | pcrf method-list-name {errors | stats} | preload {errors | stats | status} session {all | session-id} }
Syntax Description
errors stats pcrf method-list-name errors pcrf method-list-name stats preload errors preload stats preload status
Displays global error counters for Mobile Policy Control & Charging (PCC) requests and responses to the policy server. Displays global statistics counters for Mobile PCC requests and responses to the policy server. Displays error counters for the specified Mobile PCC Policy and Charging Rule Function (PCRF) method list name. Displays statistics counters for the specified Mobile PCC PCRF method list name. Displays the Mobile PCC policy preloading error counters. Displays the Mobile PCC policy preloading statistics counters. Displays the status of Mobile PCC policy preloading. You can use the status keyword to determine whether policy preloading is in progress.
session all session session-id
Displays session information for all currently active Mobile PCC subscribers. Displays information about the specified Mobile PCC session.
Command Default
None.
Command Modes
Privileged EXEC
Command History
Release 12.4(22)MDA
Examples
The following example shows how to display global error counters for Mobile PCC requests and responses to the policy server:
show mpcc errors Mobile PCC errors:
A-414
OL-22840-05
Appendix A
CSG2 Command Reference show mpcc
Failed to send CCR: 0 Failed to send RAA: 0 CCA Errors: 0 RAA Errors: 0 Duplicate requests: 0 Invalid mes-type errors: 0 Invalid req-type errors: 0 Invalid req-num errors: 0 Invalid req-status errors: 0 Invalid sess-id errors: 0 malloc errors: 0 chunk failures: 0 invalid meth list: 0 invalid preload obj type: 0 aaa author failures: 0 aaa req alloc failures: 0 aaa req author init failures: 0 aaa attr list alloc failures: 0 session sync failures: 0 preload sync failures: 0 sess hash tab create failures: 0 signal handler errors: 0 process watch errors: 0 process_create_errors: 0 crashblock_set_errors: 0
The following example shows how to display global statistics counters for Mobile PCC requests and responses to the policy server:
show mpcc stats Mobile PCC statistics: CCR-initial sent: 1 CCR-update sent: 0 CCR-final sent: 0 CCA received: 1 RAR received: 0 RAA sent: 0
The following example shows how to display error counters for PCRF method list web-method-list:
show mpcc pcrf web-method-list errors Failed to send CCR: 0 Failed to send RAA: 0 CCA errors: 0 RAA errors: 0 Duplicate requests: 0 Invalid mes-type errors: 0 Invalid req-type errors: 0 Invalid req-num errors: 0 Invalid req-status errors: 0 Invalid sess-id errors: 0
The following example shows how to display statistics counters for PCRF method list web-method-list:
show mpcc pcrf web-method-list stats CCR-initial sent: 0 CCR-update sent: 0 CCR-final sent: 0 CCA received: 0 RAR received: 0 RAA sent: 0 PCRF reboots: 0
A-415
Appendix A show mpcc
The following example shows how to display the Mobile PCC policy preloading error counters:
show mpcc preload error Inconsistent preload Data: 0 Missing Mandatory AVPs: 0 Failure due to Wrong Order: 0 Failure to enforce: 0 Conflict with static config: 0 Failed to send CCR: 0 Failed to send RAA: 0 CCA errors: 0 RAR errors: 0 Invalid req-type errors: 0 Invalid req-num errors: 0 Invalid req-status errors: 0 Invalid preload type errors: 0
The following example shows how to display the Mobile PCC policy preloading statistics counters:
show mpcc preload stats PCEF init preloading: 1 PCRF init preloading: 0 Policy Preload Req: 1 Policy Preload Res:1 Global Policy Push: 0 Global Policy Push Ack: 0
The following example shows how to check the status of Mobile PCC policy preloading:
show MPCC MPCC MPCC mpcc preload Preload Pull Last Preload Preload Push status status - timed out Pull status - timed out status - not initialized
The following example shows how to display information about all Mobile PCC sessions:
show mpcc session all Total Number of Sessions: 1 Session id: pcef1.cisco.com;0;1246556896 method list: GX-ML4 pcrf ip address: 13.1.1.2 destination host: cscp12c1.cisco.com destination realm: cisco.com Stats: CCR-initial Sent: 1 CCR-update Sent: 0 CCA received: 1 RAR received: 0 RAA sent: 0
A-416
OL-22840-05
Appendix A
CSG2 Command Reference show record-storage-module
show record-storage-module
To display information about the record storage module (RSM), use the show record-storage-module command in privileged EXEC mode. show record-storage-module {stats | target-info [all | target-profile profile-name] [detail]}
Syntax Description
stats target-info all target-profile profile-name detail
Displays current RSM statistics. Displays the number of RSM disks available, and their current status. (Optional) Displays statistics for all targets for which there are profiles. (Optional) Displays statistics for a specific profile. (Optional) Displays detailed information about the RSM drives.
Command Default
Command Modes
Privileged EXEC
Command History
Release 12.4(15)MD
Usage Guidelines
Use the show record-storage-module stats command to display RSM statistics.
Examples
The following example shows output from the show record-storage-module stats command:
Router# show record-storage-module stats RSM Appl Stats: requests: open= 1, read= 0, write= 0 ping= 0, close= 0 request fail: open= 0, read= 0, write= 0 ping= 0, close= 0 | ta alloc fail: appl info= 0, appl msg= 0, appl req= 0, data buffer= 0, drive= 0 RSM Clear: Statistics = 1
The following example shows output from the show record-storage-module target-info all detail command:
Router# show record-storage-module target-info all detail Target profile = TARGET_LINUX Application name = GGSN, Target State = Active, Disk = Usable Application id = 2, iSCSI handle = 2
A-417
Appendix A show record-storage-module
Number of drives = 5, Read drive = sda3, Write drive Active drives: Drive = sda3 File system id = 19 Descriptors: read = -1, write = -1, master = -1 Current File: bytes written = 0, bytes read = 0 Master file in memory: Drive full = No Write: dir = 1, file = 1 Read: dir = 1, file = 1, offset = 62675 Salvage file = 0, CRC = 0x91C816C0 Failed drives: Drive = sda0 Reason = Unexpected IFS error (Invalid DOS media or Drive = sda1 Reason = Unexpected IFS error (Invalid DOS media or Drive = sda2 Reason = Unexpected IFS error (Invalid DOS media or Drive = sda4 Reason = Unexpected IFS error (Invalid DOS media or
= sda3
no media in slot) no media in slot) no media in slot) no media in slot)
A-418
OL-22840-05
Appendix A
CSG2 Command Reference snmp-server enable traps csg
snmp-server enable traps csg

To enable Simple Network Management Protocol (SNMP) notification types that are available on the CSG2, use the snmp-server enable traps csg command in global configuration mode. To disable CSG2 notifications, use the no form of this command. snmp-server enable traps csg [bma [records | state] | database | license warning-enable | quota-server [records | state]] no snmp-server enable traps csg [bma [records | state] | database | license warning-enable | quota-server [records | state]]
Syntax Description
bma records state database license warning-enable quota-server records state
(Optional) Enables traps for only the Billing Mediation Agents (BMAs) to which the CSG2 sends billing records. (Optional) Enables only lost records traps for the BMAs. (Optional) Enables only state change traps for the BMAs. (Optional) Enables traps for only the database server that answers CSG2 user ID queries. (Optional) Enables traps when the CSG2 subscriber threshold is exceeded. (Optional) Enables traps for only the CSG2 quota servers. (Optional) Enables only lost records traps for the quota servers. (Optional) Enables only state change traps for the quota servers.
Command Default
If you do not enter the snmp-server enable traps csg command, no CSG2 notifications controlled by this command are sent. By default, the license warning-enable option is enabled and the CSG2 generates traps when the subscriber threshold is exceeded.
Command Modes
Command History
Release 12.4(11)MD

The bma, database, quota-server, records, and state keywords were added. The agent, database, and quota-server keywords were removed.
12.4(22)MD
The license warning-enable keywords were added.
Usage Guidelines
Entering the snmp-server enable traps csg command enables all CSG2 SNMP traps. If you then enter the snmp-server enable traps csg bma command, the BMA lost records and state change traps are enabled.
A-419
Appendix A snmp-server enable traps csg
If you then enter the snmp-server enable traps csg quota-server records command, the quota server lost records trap is enabled. To display the current setting of the SNMP trap variable, enter the following command on the host:
snmpget -v2c -c public ipv4-address oid
where:

ipv4-address is the host-side IPv4 address of the CSG2. oid is the oid.1 of the trap variable.
If the ip csg license warning-enable command is configured, and the license warning-enable option is enabled either explicitly or by default, and the number of concurrent subscribers accessing the network exceeds the configured subscriber threshold, the CSG2 generates a license-exceeded SNMP trap.
Examples
The following example shows how to enable SNMP traps:

snmp-server enable traps csg
The following example shows how to prevent the CSG2 from generating license-exceeded SNMP traps:
no snmp-server enable traps csg license warning-enable
Related Commands
Command clear ip csg ip csg license syslog enable ip csg license warning-enable ip csg snmp timer
Description Clears the CSG2. Enables the CSG2 to generate system (syslog) messages when the subscriber threshold is exceeded. Sets a subscriber threshold for the CSG2 to generate license-exceeded notifications. Defines Simple Network Management Protocol (SNMP) timers for lost CSG2 records, and enters CSG2 SNMP timer configuration mode.
A-420
OL-22840-05
Appendix A
CSG2 Command Reference string (CSG2 header)
string (CSG2 header)

To specify a text string and indicate where it is to be inserted into a CSG2 header, use the string command in CSG2 header configuration mode. To remove the string, use the no form of this command. string string-id string no string string-id string
Syntax Description
string-id string
Unique string identifier. The valid range is 1 to 65000. String to be inserted into the CSG2 header. The string can be from 1 to 40 characters long, and can include uppercase or lowercase letters (CSG2 changes all letters to uppercase), numbers (CSG2 converts all numbers to ASCII), and any special characters.
Command Default
None.
Command Modes
Command History
Release 12.4(24)MD
Usage Guidelines
This command is optional for a CSG2 header.
Examples
The following example shows how to insert string Hello world into a CSG2 header:
string 1 Hello world
Related Commands
A-421
Appendix A subscriber-ip http-header x-forwarded-for (CSG2 content)
subscriber-ip http-header x-forwarded-for (CSG2 content)

To specify that the CSG2 is to obtain the subscriber's IP address from the HTTP X-Forwarded-For header, use the subscriber-ip http-header x-forwarded-for command in CSG2 content configuration mode. To specify that the CSG2 is to obtain the subscriber's IP address from the IP header, use the no form of this command. subscriber-ip http-header x-forwarded-for [obscure] no subscriber-ip http-header x-forwarded-for
Syntax Description
obscure
(Optional) Overwrite the IP address in the X-Forwarded-For header with blanks.
Command Default
The CSG2 obtains the subscriber's IP address from the IP header. If you enter the subscriber-ip http-header x-forwarded-for command without the obscure keyword, the IP address in the X-Forwarded-For header is not obscured with blanks.
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
If the CSG2 is configured to obtain the subscriber's IP address from the HTTP X-Forwarded-For header, it also automatically recognizes the variant X-UP-Forwarded-For header. Only content that is configured with parse protocol http can be configured with subscriber-ip http-header x-forwarded-for. Single-TP mode is required for HTTP X-Forwarded-For operation.
Before configuring the CSG2 for X-Forwarded-For operation, configure the CSG2 for single-TP mode by entering the ip csg mode single-tp command, then performing a write memory, then restarting the CSG2. If the CSG2 is not operating in single-TP mode, and you attempt to enter the subscriber-ip http-header x-forwarded-for command, the CSG2 rejects the command and issues a warning message. If the CSG2 is operating in single-TP mode and you attempt to switch to multiple-TP mode, the CSG2 checks the configuration for the subscriber-ip http-header x-forwarded-for command. If the configuration does contain the command (that is, X-Forwarded-For operation is enabled), the CSG2 does not switch to multiple-TP mode, and it issues a warning message.
A-422
OL-22840-05
Appendix A
CSG2 Command Reference subscriber-ip http-header x-forwarded-for (CSG2 content)
To prevent exposure of potentially sensitive IP addresses, the CSG2 can obscure the contents of X-Forwarded-For headers, overwriting the contents with blanks.

If you want to obscure the contents of the X-Forwarded-For header, enter the subscriber-ip http-header x-forwarded-for command with the obscure keyword. If you do not want to obscure the contents of the X-Forwarded-For header, enter the subscriber-ip http-header x-forwarded-for command without the obscure keyword (the default setting). When obscuring the IP address in X-Forwarded-For headers, keep the following considerations in mind:
The CSG2 does not obscure the IP address in fragmented request packets that have
X-Forwarded-For headers, because the CSG2 does not reassemble the fragments and therefore cannot modify the packets.
The CSG2 does not obscure the X-Forwarded-For header for traffic that is downgraded from
Layer 7 inspection to Layer 4 inspection.

If the active CSG2 fails over to the standby CSG2, the standby CSG2 does not obscure the IP
address in X-Forwarded-For header for existing HTTP sessions. However, the standby CSG2 does obscure the IP address in X-Forwarded-For headers for new HTTP sessions.
If the subscriber sends more than one GET request with X-Forwarded-For headers, and the
content host fails to send a TCP acknowledgement within five seconds, the CSG2 resets the subscriber side connection. The CSG2 does not support IPv6 or dual-stack for X-Forwarded-For.
Examples
The following example configures the CSG2 to obtain the subscriber's IP address from the HTTP X-Forwarded-For header, and obscures the IP address in the X-Forwarded-For header:
ip csg content MOVIES parse protocol http subscriber-ip http-header x-forwarded-for obscure
Related Commands
Command ip csg content ip csg mode single-tp parse length (CSG2 content) parse protocol (CSG2 content)
Description Configures content for CSG2 services, and enters CSG2 content configuration mode. Enables the CSG2 to use a single TP instead of multiple TPs. Defines the maximum number of Layer 7 bytes that the CSG2 is to parse when attempting to assign a policy. Defines how the CSG2 is to parse traffic for a content.
A-423
Appendix A target-portal (iSCSI)
target-portal (iSCSI)
To specify the portal group tag for an iSCSI target in the target interface profile on the CSG2, use the target-portal command in iSCSI configuration mode. To remove the tag, use the no form of the command. target-portal tag no target-portal
Syntax Description
tag
Portal group tag for the iSCSI target. The iSCSI target portal group tag specifies the IP and TCP port numbers on which an iSCSI target is allowed to bind, and the interface on which the iSCSI target listens. The iSCSI initiator uses the portal group to connect to the target. The range is from 1, which means the iSCSI initiator can connect to the target on any interface, to 65535. The default setting is 1.
Command Default
The iSCSI initiator can connect to the target on any interface.
Command Modes
iSCSI configuration
Command History
Release 12.4(15)MD
Examples
The following example configures an iSCSI target interface profile with the name targetA with iSCSI target portal group tag 1:
Related Commands
Description Specifies the IP address of an iSCSI target in the target interface profile on the CSG2. Defines the delay interval, in seconds, before draining packets from the Storage Area Network (SAN) connected to the Internet Small Computer Systems Interface (iSCSI) when the Billing Mediation Agent (BMA) becomes active.
A-424
OL-22840-05
Appendix A
CSG2 Command Reference target-portal (iSCSI)
Command ip csg iscsi drain packet
Description Defines the number of packets to be drained from the Storage Area Network (SAN) connected to the Internet Small Computer Systems Interface (iSCSI) per drain delay interval when the Billing Mediation Agent (BMA) becomes active. Specifies the Internet Small Computer Systems Interface (iSCSI) target to be used as backup storage for the CSG2. Creates an iSCSI profile for an iSCSI target on the CSG2, and enters iSCSI configuration mode. Specifies the name of an iSCSI target in the target profile on the CSG2 Specifies the number of the port on which to listen for iSCSI traffic in the iSCSI target interface profile on the CSG2. Specifies the session timeout for an iSCSI target in the target interface profile on the CSG2.
ip csg iscsi profile ip iscsi target-profile name (iSCSI) port (iSCSI) session-timeout (iSCSI)
A-425
Appendix A timestamp (CSG2 header)
timestamp (CSG2 header)

To indicate where a timestamp is to be inserted into a CSG2 header, use the timestamp command in CSG2 header configuration mode. To remove the timestamp, use the no form of this command. timestamp no timestamp
Syntax Description
Command Default
None.
Command Modes
Command History
Release 12.4(24)MD
Usage Guidelines
This command is optional for a CSG2 header. The timestamp is the time, in Coordinated Universal Time (UTC) format, when CSG2 inserted the header data into the HTTP header. You cannot insert a timestamp within the encrypted portion of the header. That is, you cannot configure the timestamp command between the encrypt begin and encrypt end commands.
Examples
The following example shows how to insert a timestamp into a CSG2 header:
timestamp
Related Commands
A-426
OL-22840-05
Appendix A
CSG2 Command Reference user class (CSG2 service)
user class (CSG2 service)

To associate a user class with a CSG2 service, use the user class command in CSG2 service configuration mode. To remove the association, use the no form of this command. user class user-class-name {deny | permit} priority priority no user class user-class-name {deny | permit} priority priority
Syntax Description
user-class-name deny permit priority priority
Name of the user class to be associated with this service, as specified with the ip csg user class command in global configuration mode. Drop transactions that use this service. Allow transactions that use this service. Priority of the user class. The priority specifies the order of preference of the user classes. A lower number indicates a higher priority, and higher priority user classes are matched before lower priority user classes. Priorities for different user classes do not have to be sequential. That is, you can have three user classes with priorities 1, 5, and 10. The range of priorities is from 0 to 63.
Command Default
No user class is associated with the service.
Command Modes
Command History
Release 12.4(24)MD
Usage Guidelines
Use this command to associate a user class with a CSG2 service. The CSG2 uses the user class when making next-hop routing decisions for a service, based on RADIUS attribute and VSA subattribute values associated with a subscriber. You can use more than one user class command to associate up to 64 user classes with a given service. User classes associated with services are matched in order of priority. The first user class to be matched determines whether transactions are to be allowed (permit) or dropped (deny) for the service. If you change a user class associated with a service, the change does not affect routing decisions for existing sessions, nor does it change the user classes selected for subscribers, until those subscriber records are affected by a user class selection event, such as a RADIUS Accounting Start or RADIUS Interim Accounting message.
A-427
Appendix A user class (CSG2 service)
Examples
The following example shows how to associate user class 3G-LAPTOP with service MOVIES:
ip csg service MOVIES user class 3G-LAPTOP deny priority 4
Related Commands
Command ip csg user class ip csg service
Description Defines a user class to be used by the CSG2 when making routing decisions, and enter sCSG2 user class configuration mode. Configures a CSG2 content billing service, and enters CSG2 service configuration mode.
A-428
OL-22840-05
Appendix A
CSG2 Command Reference user-default
user-default
To designate a CSG2 billing plan as the default billing plan, use the user-default command in CSG2 billing configuration mode. To remove the default designation from the billing plan, use the no form of this command. user-default no user-default
Syntax Description
Command Default
There is no default billing plan.
Command Modes
Command History
Release 12.4(22)MD
Usage Guidelines
You can designate only one billing plan as the default billing plan. The default billing plan can be prepaid or postpaid. In order for the CSG2 to assign the default billing plan to the subscriber, an entry in the CSG2 User Table must be created for the subscriber by RADIUS or by the user database. Sticky user entries in the CSG2 User Table cannot use the default billing plan. If a subscriber is assigned to the default billing plan because there are no active quota servers, and a quota server then becomes active, the subscriber continues to use the default billing plan. To designate a different billing plan as the default billing plan, use the following procedure:
Step 1 Step 2
Remove the default designation from the old default billing plan, using the no form of the user-default command. Designate the new billing plan as the default billing plan, using the user-default command.
Examples
The following example specifies that billing plan USER-DEFAULT is to be the default billing plan:
ip csg billing USER-DEFAULT user-default
A-429
Appendix A user-default
Related Commands
Command entries user idle ip csg billing mode qos profile (CSG2 billing) service
Description Sets the time after which entries for idle subscribers are deleted from the CSG2 User Table. Defines a CSG2 billing plan, and enters CSG2 billing configuration mode. Specifies the mode for a CSG2 billing plan. Associates a Quality of Service (QoS) profile with a CSG2 billing plan. Associates a service with a CSG2 billing plan.
A-430
OL-22840-05
Appendix A
CSG2 Command Reference verify confirm
verify confirm
To configure a token for use in CSG2 service verification URL-rewriting, use the verify confirm command in CSG2 service configuration mode. To remove the token, use the no form of this command. verify confirm token no verify confirm token
Syntax Description
token
A string of up to 15 alphanumeric characters. The string is not case-sensitive. Acceptable characters include alphanumeric characters and any of the following special characters: $-_.+!*'(),?/:@&=;~%. To enter other special characters not listed, use the URL-escape format with the percent sign (%).
Command Default
None
Command Modes
Command History
Release 12.4(11)MD

The name of this command changed from verify confirmation to verify confirm. The configuration mode for this command changed from CSG user group configuration to CSG2 service configuration. The list of supported special characters changed.
Usage Guidelines
URL-rewriting allows a top-off server to append parameters to a URL in order to convey state information to the quota server during a Content Authorization Request. Whenever a Service Verification Response contains the forward action code, and the URL contains the verify confirmation token, the token and all trailing characters are removed from the URL before the request is forwarded to the network. The token is used for HTTP and wireless application protocol (WAP) service verification URL-rewriting. If the token uses the URL-escape format, the redirect URL to which the token is being matched must also use the URL-escape format.
A-431
Appendix A verify confirm
Examples
The following example specifies a token for service verification URL-rewriting:

ip csg service MOVIES aoc enable verify confirm ?CSG_VERIFY_OK
Related Commands
Command ip csg service verify enable
Description Configures a CSG2 content billing service, and enters CSG2 service configuration mode. Enables CSG2 service verification.
A-432
OL-22840-05
Appendix A
CSG2 Command Reference verify enable
verify enable
To enable CSG2 service verification, use the verify enable command in CSG2 service configuration mode. To disable this feature, use the no form of this command. verify enable no verify enable
Syntax Description
Command Default
None
Command Modes
Command History
Release 12.4(11)MD
Modification This command was migrated from CSG1. Changes from CSG1: The name of this command changed from verify to verify enable.
Usage Guidelines
If this command is configured, the CSG2 uses the Service Verification Request to perform the following actions:

Alert the quota server of a new transaction. Allow the quota server to direct the CSG2 to perform one of the following mutually exclusive actions:
DROPDrop all packets for this flow. FORWARDForward the flow without altering the destination (a weight might be specified). REDIRECT-URLRedirect subscriber requests to the URL provided by the quota server. The
CSG2 sends a Layer 7 redirect to the subscriber (for example, HTTP 302 response) that contains the redirect URL.
Examples
The following example specifies a token for service verification URL-rewriting:

ip csg service SERVICE_NAME verify enable
Related Commands
Command ip csg service verify confirm
Description Configures a CSG2 content billing service, and enters CSG2 service configuration mode. Configures a token for use in CSG2 service verification URL-rewriting.
A-433
Appendix A vlan (CSG2 content)
vlan (CSG2 content)

To restrict the CSG2 billing content to a single source VLAN, use the vlan command in CSG2 content configuration mode. To remove the restriction, use the no form of this command. vlan vlan-number no vlan
Syntax Description
vlan-number
Dot1q encapsulation VLAN number.
Command Default
None
Command Modes
Command History
Release 12.4(11)MD
Modification This command was migrated from CSG1. Changes from CSG1: The vlan-name argument was replaced with the vlan-number argument.
Usage Guidelines
The VLAN number is dependent on the CSG2 card that receives the content. When the content is downloaded to a CSG2 card, the vlan-number argument is mapped to a specific VLAN number.
Examples
The following example shows how to restrict the CSG2 content billing to single-source VLAN number 67:
ip csg content MOVIES_COMEDY vlan 67
Related Commands
A-434
OL-22840-05
Appendix A
CSG2 Command Reference vrf (CSG2 content)
vrf (CSG2 content)

To restrict the CSG2 content to packets within a single Virtual Routing and Forwarding (VRF) table, use the vrf command in CSG2 content configuration mode. To remove the restriction, use the no form of this command. vrf vrf-name no vrf
Syntax Description
vrf-name
VRF within which the content should match packets.

Note
Command Default
None
Command Modes
Command History
Release 12.4(11)MD
Usage Guidelines
VRF configuration and filtering cannot be used in conjunction with VLAN filtering. If you want to use VRF tables to restrict CSG2 content, we recommend that you define a VRF table for every content. If you do not configure a VRF table for a given content, then that content cannot match traffic to a VRF table, and you cannot use a global content to match traffic in different VRF tables.
Examples
The following example shows how to restrict the CSG2 content to packets within VRF table CONTENTVRF:
ip csg content MOVIES_COMEDY vrf CONTENTVRF
Related Commands
A-435
Appendix A vrf (CSG2 content)
A-436
OL-22840-05
A P P E N D I X
Field Descriptions for CSG2 Statistics

This appendix provides sample output for the show ip csg stats command in privileged EXEC mode. In this sample output, each block of output is followed by a table that describes each of the fields in that block. However, in the actual output for this command, the tables are not present. This appendix includes the following information:

CSG Replication Statistics, page B-2 CSG Clear Statistics, page B-3 IPC PPC Statistics, page B-3 CSG Distributed Configuration Statistics, page B-8 CSG Distributed Show Statistics, page B-8 CSG Clock Statistics (CP), page B-10 CSG Clock Statistics (TP), page B-10 CSG Background Configuration Statistics, page B-10 CSG Regex Statistics, page B-11 CSG Load Management Statistics, page B-12 CSG Buffer Management Statistics, page B-16 CSG User Database Statistics, page B-17 CSG Session Layer 4 Statistics, page B-18 CSG Fragment Statistics, page B-21 CSG Fragment Statistics, page B-21 CSG Packet Statistics, page B-22 CSG Distributed User Table Statistics, page B-24 CSG User Statistics, page B-26 CSG Session Statistics, page B-28 CSG ACCEL Statistics, page B-29 CSG LogGen Statistics, page B-32 GTP Application: CSG IPC, Local Port: 0, page B-33 GTP Application: CSG Billing Agent, Local Port: 16000, page B-34 GTP Application: CSG Quota Server, Local Port: 16001, page B-35
B-1
Appendix B CSG Replication Statistics
GTP Application: CSG PSD, Local Port: 0, page B-36 CSG RADIUS Statistics, page B-37 CSG OTHER Statistics, page B-40 CSG HTTP Statistics, page B-40 CSG RTSP Statistics, page B-42 CSG SIP Statistics, page B-44 CSG WAP Statistics, page B-47 CSG Mail Statistics, page B-48 CSG FTP Statistics, page B-49 CSG NBAR Statistics, page B-51 CSG QoS Statistics, page B-52 CSG Quota Server Statistics, page B-53 CSG Gx Handler Statistics, page B-56 CSG Policy Preload Statistics, page B-57 Timer Statistics, page B-59 DNS Stats, page B-60 DNS IP Map Table Stats, page B-61
CSG Replication Statistics

CSG Replication Stats: State: ACTIVE Transmit: Packets = 1725627, current sequence = 268220 Received: Packets = 12014, current sequence = 12015, errors = 0 Last Bulk Sync Sent: 07:15:01 UTC Jun 6 2007 Bulk sync in progress on: Processor 5 Processor 8 Dropped: Packets = 0 Rate: (max=0, cur=0) B/s
These fields detail the impact on memory of replication on the CSG2 The following table lists and describes all of the fields in the CSG Replication Stats output for the show ip csg stats command: Field STATE Transmit: Packet Transmit: current sequence Received: Packet Received: current sequence Received: errors Last Bulk Sync Sent Description HA state of this device (Active or Standby) Number of HA packets sent to peer Current sequence number to peer since initialization or last cold-bulk request Number of HA packets received from peer Current sequence number from peer since initialization Packets received out of sequence from peer Time at which the last bulk-sync was performed with the peer device
B-2
OL-22840-05
Appendix B
Field Descriptions for CSG2 Statistics CSG Clear Statistics
Field Bulk sync in progress on: Processor Dropped: Packets Rate: max Rate: cur
Description Processor on which the last bulk-sync was performed Number of packets dropped from peer waiting for NTP clock to sync Maximum rate (bytes per second) of HA bytes sent to peer Current rate (bytes per second) of HA bytes sent to peer
CSG Clear Statistics

CSG Clear Stats: counters = 0, kut = 0, sessions = 0
The following table lists and describes all of the fields in the CSG Clear Stats output for the show ip csg stats command: Field counters kut sessions Description Number of times the clear ip csg counters command was issued for counters Number of times the clear ip csg user command was issued for counters Number of times the clear ip csg sessions user command was issued for counters
IPC PPC Statistics

IPC PPC Stats: init alloc fail = 0 message block alloc fail = 0 message block alloc denied = 0 correlator alloc fail = 0 message blocks currently allocated = 5020, max allocated = 5200 message blocks currently queued = 5020, max queued = 5200 message blocks currently tx queued = 5020, max tx queued = 5200 message blocks currently hashed = 3600, max hashed = 3663 dropped messages = 0, null msgs = 0 failure to respond = 0 acks = 11251929, timed out responses = 231567 interrupt acks = 1898906, process acks = 25, no ack = 0 sent to peer unreliable sends = 0, unreliable send failures = 0 reliable sends = 436, reliable send failures = 0 request sends = 1902531, request send failures = 0 response sends = 11252888, response send failures = 0 received from peer unreliable = 51626, reliable = 97224994, request = 11254924, response = 1667364 unsupported ipc port = 0, unsupported ipc request port = 0 uncorrelated = 1138193 errors rtx list = 0, hash list = 0, dealloc = 0 msg type = 0, ack miss = 0, preemptive timeout responses = 0 -----------------------------destination = 127.1.0.4:0, localport = 0 connection failures = 0 priority = 0, ACTIVE packet rate = 351/sec, ack rate = 351/sec data packets sent = 3086282, retransmits = 76, failed acks = 0
B-3
Appendix B IPC PPC Statistics
queued = 0, highwater = 586, tx win = 32 unacked = 0, ack = 138, count = 4 -----------------------------destination = 127.1.0.5:0, localport = 0 connection failures = 0 priority = 0, ACTIVE packet rate = 304/sec, ack rate = 23/sec data packets sent = 1230533, retransmits = 523322, failed acks = 0 queued = 2490, highwater = 2669, tx win = 32 unacked = 32, ack = 5, count = 4 -----------------------------destination = 127.1.0.6:0, localport = 0 connection failures = 0 priority = 0, ACTIVE packet rate = 831/sec, ack rate = 831/sec data packets sent = 5280267, retransmits = 114, failed acks = 0 queued = 0, highwater = 191, tx win = 32 unacked = 0, ack = 14, count = 1 -----------------------------destination = 127.1.0.7:0, localport = 0 connection failures = 0 priority = 0, ACTIVE packet rate = 191/sec, ack rate = 191/sec data packets sent = 3339431, retransmits = 39339, failed acks = 0 queued = 0, highwater = 1649, tx win = 32 unacked = 0, ack = 105, count = 4 -----------------------------destination = 127.1.0.8:0, localport = 0 connection failures = 0 priority = 0, ACTIVE packet rate = 257/sec, ack rate = 0/sec data packets sent = 1281140, retransmits = 506285, failed acks = 0 queued = 2530, highwater = 2716, tx win = 31 unacked = 31, ack = 4, count = 0
The IPC system conveys messages between the CP and the TPs on the CSG2. The statistics that are displayed for a TP track only one en point, because the TPs communicate only with the CP. The statistics displayed for the CP track a connection for each TP, as well as cumulative statistics. The statistics displayed reflect only the state of the processor on which the show ip csg stats command was entered. The IPC can forward messages on a best-effort basis or a reliable basis. Some reliable messages require responses as well as ACKs. This is reflected in the statistics. The following table lists and describes all of the fields in the IPC PPC Stats output for the show ip csg stats command: Field init alloc fail message block alloc fail message block alloc denied correlator alloc fail Description Number of IPC-related allocations that failed during boot time Number of attempts to allocate a message that failed due to memory exhaustion Number of times load management refused to allow a message to be allocated Number of times the IPC system failed to allocate a correlator block. (When reliable messages that require a response are sent, the IPC system must allocate a correlator block to record the association between the sending code context and the response when it arrives.)
B-4
OL-22840-05
Appendix B
Field Descriptions for CSG2 Statistics IPC PPC Statistics
Field message blocks currently allocated message blocks max allocated message blocks currently queued message blocks max queued message blocks currently tx queued
Description Current number of message buffers that have been allocated, but not yet sent and queued for retry Maximum number of message buffers that have been allocated, but not yet sent and queued for retry Current number of message buffers that have been sent but not yet acknowledged, including signaling Maximum number of message buffers that have been sent but not yet acknowledged, including signaling Current number of application level message buffers that have been sent but not yet acknowledged, excluding signaling Maximum number of application level message buffers that have been sent but not yet acknowledged, excluding signaling Current number of correlators in the hash table. (When a message that requires a response is sent, a correlator is allocated.) Maximum number of correlators in the hash table. (When a message that requires a response is sent, a correlator is allocated.) Number of messages that could not be sent due to resource limitations Number of times a send API was invoked with a null message Number of times a message was received from another processor, forwarded to the client code designated to reference the message, and the client code returned an error indicating that it could not properly respond to the message Number of ACKs from remote endpoints Number of messages requiring a response for which a response was not received in a timely manner Number of interrupt ack messages. When a message that requires a response is received, it is passed to the client code while still in the interrupt context. If the client code processes the message immediately by sending a response, the ACK flows as part of the response. This is an interrupt ack message. Number of process ack messages. If the client code queues a message to process before creating a response, the IPC system sends a simple GTP-level ACK to prevent additional retries of the message, pending the actual response. This is a process ack message. Number of no ack messages. If a message is being deallocated, and it has been found not yet to be removed from the retry queues, it is counted as a no ack message.
message blocks max tx queued
message blocks currently hashed
message blocks max hashed
dropped messages null msgs failure to respond
acks timed out responses interrupt acks
process acks
no ack
B-5
Appendix B IPC PPC Statistics
Field sent to peer: unreliable sends sent to peer: unreliable send failures
Description For outgoing packets to all peers, number of messages sent best-effort For outgoing packets to all peers, number of packets that did not get sent due to a failure in the platform modules on which IPC depends For outgoing packets to all peers, number of messages sent requiring a simple ACK For outgoing packets to all peers, number of messages sent requiring a simple ACK that failed due to a failure in a platform module For outgoing packets to all peers, number of messages sent requiring a response For outgoing packets to all peers, number of messages sent requiring a response that failed due to a failure in a platform module For outgoing packets to all peers, number of response messages sent For outgoing packets to all peers, number of response messages sent that failed due to a failure in a platform module For outgoing packets to all peers, number of times a processor attempted to send an ACK for a corrupt IPC packet. Should always be zero. A non-zero value means an exception has occurred. For incoming messages from all peers, number of messages sent best-effort For incoming messages from all peers, number of messages sent requiring a response For incoming messages from all peers, number of messages sent requiring a simple ACK For incoming messages from all peers, number of response messages sent Number of incoming messages on an IPC port that does not require a response Number of incoming messages on an IPC port that does require a response (request) Number of times a response arrives with no request with the correct correlator for the response. This can occur if a response arrives after the request has timed out, or if a retry of a response arrives after the original response has been processed. Number of times a message was found to be in the retry list at the time it was deallocated. Might be a symptom of problems in the client code. Number of times a message was found to be in the correlation hash at the time it was deallocated. Might be a symptom of problems in the client code.
sent to peer: reliable sends sent to peer: reliable send failures
sent to peer: request sends sent to peer: request send failures
sent to peer: response sends sent to peer: response send failures
sent to peer: unsupported udp port
received from peer: unreliable received from peer: request received from peer: reliable received from peer: response unsupported ipc port unsupported ipc request port uncorrelated
errors: rtx list
errors: hash list
B-6
OL-22840-05
Appendix B
Field Descriptions for CSG2 Statistics IPC PPC Statistics
Field errors: dealloc
Description Number of times client code attempted to deallocate an empty message. Might be a symptom of problems in the client code. Number of messages that arrived with an unknown GTP message type. The most likely cause is corruption of the message. Number of messages that were ACKed but internal accounting for that message was been corrupted; ACK processing could not complete. There is a risk of leaking a sent message as it sits in the retry queue. Number of times a process was waiting for an IPC response event but got a direct event in error Internal address used to identify the far end of this communication channel. The last octet of the apparent IP address is the processor number of the target processor. Local port. Should always be zero. Number of times a connection was lost due to failure to receive ACKs Priority of the connection. Should always be zero. State of the connection: ACTIVE or FAILED Packet rate per second Approximate ACK rate per second Number of non-signalling packets sent Number of non-signalling retransmits Number of ACKs that arrived to find no message needing acknowledgment Number of messages waiting to be sent Highwater for the number of messages waiting to be sent Number of unACKed messages permitted before waiting for ACKs Number of unACKed sent messages Used for internal debugging Used for internal debugging Number of messages that failed to send via platform modules Number of deferred ACKs that failed to send. Typically, GTP sends an ACK for the client code. However, the client code might defer the ACK until some additional processing has taken place, and the attempt to send the ACK at a later time might fail. Number of IPC messages (reliable, request, or response) that were not ACKed after a certain number of retries and were discarded. Client code receives a timed out indication.
errors: msg type
errors: ack miss
preemptive timeout responses destination
localport connection failures priority ACTIVE packet rate ack rate data packets sent retransmits failed acks queued highwater tx win unacked ack count failed dispatch failed_def_ack_send
too many retries
B-7
Appendix B CSG Distributed Configuration Statistics
Field timed out queued
Description Number of request messages that were still in the GTP retry queue and were not sent at the end of an IPC request timeout Number of request messages that were sent at the end of an IPC request timeout, but no ACK was received Number of request messages that were sent at the end of an IPC request timeout and ACKed by the recipient, but no response message arrived
timed out sent timed out acked
CSG Distributed Configuration Statistics

CSG Distributed Config Stats: poll msgs rcvd = 12, online msgs sent = 6, ack rcvd = 6 ack not rcvd = 0 poll msg sent = 16, online msg rcvd = 5, ack sent = 5 ack not sent = 4, cmd distributed = 0, rollback = 0 'no' cmd success = 0, 'no' cmd failure = 0
The following table lists and describes all of the fields in the CSG Distributed Config Stats output for the show ip csg stats command: Field poll msgs rcvd online messages sent ack rcvd ack not rcvd poll msgs sent online messages rcvd ack sent ack not sent cmd distributed rollback no command success no command failure Description On TP, number of poll messages received On TP, number of online messages sent On TP, number of acks received On TP, number of acks not received On CP, number of poll messages sent On CP, number of online messages received On CP, number of acks sent On CP, number of acks not sent On CP, number of commands distributed On CP, number of commands rolled back On CP, number of no commands that succeeded On CP, number of no commands that failed
CSG Distributed Show Statistics

CSG Distributed Config Stats: Command allocation failure = 0 Failure to queue command for processing = 0 Pre-existing context for new command = 0 No context for continued command = 0 No context for continued command = 0 Context allocation failure = 0 TTY allocation failure = 0 Process allocation failure = 0 TTY not set on process = 0
B-8
OL-22840-05
Appendix B
Field Descriptions for CSG2 Statistics CSG Distributed Show Statistics
Command not queued to command process = 0 Command IPC response allocation failure = 0 Command IPC response send failure = 0 TP no msg for proc = 0 TP no msg, no tty = 0 Sync msg failed = 0 Process lookup failed = 0 Runaway process detected = 0
The following table lists and describes all of the fields in the CSG Distributed Show Stats output for the show ip csg stats command: Field Command allocation failure Failure to queue command for processing Pre-existing context for new command Description On TP, failure to allocate memory for DSHOW request On TP, failure to enqueue DSHOW request On TP, context exists for new commands (indicates an issue with context allocation and free) On TP, context does not exist when 'more' output is requested On TP, context does not exist when 'quit' is issued On TP, context allocation failed for DSHOW command On TP, TTY allocation failed (either all TTYs are in use or there is a TTY leak) On TP, creation of process to handle DSHOW command has failed On TP, cannot associate TTY to process that handles DSHOW command On TP, failed to send request to process that handles DSHOW command On TP, failed to allocate IPC response message On TP, failed to send IPC response message On TP, process woke up but did not find a message On TP, process woke up but no TTY was associated to it On TP, synchronous send of IPC message failed On TP, failed to get pid of process that handles DSHOW command On TP, runaway process is detected (indicates IPC message congestion between CP and TP)
No context for continued command No context for quit command Context allocation failure TTY allocation failure Process allocation failure TTY not set on process Command not queued to command process Command IPC response allocation failure Command IPC response send failure TP no msg for proc TP no msg, no tty Sync msg failed Process lookup failed Runaway process detected
B-9
Appendix B CSG Clock Statistics (CP)
CSG Clock Statistics (CP)

CSG Clock Stats (CP) csg_ntp_sync_completed=1, cp_ntp_configured=1 tp_dnld_flag[4]=3, tp_dnld_flag[5]=3, tp_dnld_flag[6]=3 tp_dnld_flag[7]=3, tp_dnld_flag[8]=3
These flags track the state of the NTP clock on the CP. The clear ip csg counters command does not clear these flags. The following table lists and describes all of the fields in the CSG Clock Stats (CP) output for the show ip csg stats command: Field csg_ntp_sync_completed cp_ntp_configured tp_dnld_flag[4] tp_dnld_flag[5] tp_dnld_flag[6] tp_dnld_flag[7] tp_dnld_flag[8] Description The CP and TPs have all have synced to the NTP server for clock: 1 = True, 0 = False NTP has a valid configuration: 1 = True, 0 = False Status of NTP and configuration on the TP. 3 indicates normal. Valid flags are:
#define TP_HEALTH_NTP_SYNC #define TP_HEALTH_NTP_CONFIG 0x00000001 0x00000002
CSG Clock Statistics (TP)

CSG Clock Stats_TP csg_ntp_sync_completed=1, tp_ntp_sync=1 cp_ntp_configured=1
These flags track the state of the NTP clock on the TP. The clear ip csg counters command does not clear these flags. The following table lists and describes all of the fields in the CSG Clock Stats_TP output for the show ip csg stats command: Field csg_ntp_sync_completed tp_ntp_sync cp_ntp_configured Description All TPs have synced to the NTP server for clock: 1 = True, 0 = False This TP has synced with NTP: 1 = True, 0 = False NTP has a valid configuration: 1 = True, 0 = False
CSG Background Configuration Statistics

CSG Background Config Stats startup config complete = true inservice contents = 0, queued = 0 inservice, failed = 0 cp request sent = 0, response rcvd = 0 tp request rcvd = 0, response sent = 0 rollback, failed = 0 cp sent = 0, tp rcvd = 0 content not found = 0
B-10
OL-22840-05
Appendix B
Field Descriptions for CSG2 Statistics CSG Regex Statistics
These are counters for Background Configuration module bringing contents inservice. The following table lists and describes all of the fields in the CSG Background Config Stats output for the show ip csg stats command: Field startup: startup config complete Description The Background Configuration module successfully brought all contents inservice during startup (true or false). The clear ip csg counters command does not clear this counter. startup: inservice contents startup: queued inservice: failed inservice: cp request sent inservice: cp response rcvd inservice: tp request rcvd inservice: cp response sent rollback: failed rollback: cp sent rollback: tp rcvd content not found Number of inservice contents during startup. The clear ip csg counters command does not clear this counter. Number of inservice contents yet to be processed during startup. The clear ip csg counters command does not clear this counter. Number of times failed to bring content inservice Number of content inservice requests sent by CP Number of content inservice responses received by CP Number of content inservice requests received by TP Number of times failed to rollback content inservice Number of times failed to rollback content inservice Number of rollback requests sent by CP Number of rollback requests received by TP Number of times Background Configuration module failed to lookup content
CSG Regex Statistics

CSG Regex Stats allocated = 4140888, used = 3798832, max = 104857600 peak allocated = 8009376, peak used = 4048464 heaps: created = 1502, destroyed = 1502 blocks: allocs = 3022, suballocs = 1690998, frees = 3022 longest chain = 0 default alloc size: 4052, upsized allocs: 0
These counters detail the memory impact of the deterministic finite automatons (DFAs) in the CSG2 regular expression (regex) Engine. The following table lists and describes all of the fields in the CSG Regex Stats output for the show ip csg stats command: Field allocated used Description Amount of memory allocated by the regex engine for DFA heaps. The clear ip csg counters command does not clear this counter. Amount of memory actually in use by the regex engine for active DFAs. The clear ip csg counters command does not clear this counter.
B-11
Appendix B CSG Load Management Statistics
Field max
Description Maximum amount of memory configured on the ip csg regex memory command for use by the regex engine for active DFAs. The clear ip csg counters command does not clear this counter. Highest amount of memory allocated by the regex engine for DFA heaps. The clear ip csg counters command does not clear this counter. Highest amount of memory actually in use by the regex engine for active DFAs. The clear ip csg counters command does not clear this counter. Number of DFA heaps allocated Number of DFA heaps destroyed. Several temporary heaps are created when moving a content into service while building the final machine DFA heap for regular expression matching. Number of heap blocks allocated for DFA use Number of sub-allocations of memory from a previously allocated memory block within a heap Number of heap blocks freed High-water mark for the number of blocks deleted from a single heap during the destruction of the heap Default block size for memory allocations in a heap. The clear ip csg counters command does not clear this counter. Number of times the default block size had to be increased to accommodate a malloc (memory allocation) request for a DFA that was larger than the default size. The clear ip csg counters command does not clear this counter.
peak allocated peak used
heaps: created heaps: destroyed
blocks: allocs blocks: suballocs blocks: frees blocks: longest chain default alloc size upsized allocs
CSG Load Management Statistics

CSG Load Management Stats: IPC queue size current/highwater/max = 0/83/50000 Radius Start: Total allowed count = 89370 30 second rate: recent 0/sec, max 4000/sec Throughput: Rate limit is 5000/sec on control processor rate limit denials = 0 lm(usec) = 0 lm(elapse) = 0 lm(rate_period) = 64 rate(0, 1F4) 30 second denial rate: recent 0/sec, max 0/sec 30 second periods above rate 0, max 0 IPC: denial begins when ipc queue size exceeds 10000 queue size denials = 0 30 second denial rate: recent 0/sec, max 0/sec Database Request: Total allowed count = 0 30 second rate: recent 0/sec, max 0/sec Throughput: Rate limit is 1800/sec per traffic processor rate limit denials = 0 lm(usec) = 0 lm(elapse) = 0 lm(rate_period) = 64 rate(0, B4) 30 second denial rate: recent 0/sec, max 0/sec 30 second periods above rate 0, max 0 IPC: denial begins when ipc queue size exceeds 10000
B-12
OL-22840-05
Appendix B
Field Descriptions for CSG2 Statistics CSG Load Management Statistics
queue size denials = 0 30 second denial rate: recent 0/sec, max 0/sec Session Create: Total allowed count = 0 30 second rate: recent 0/sec, max 0/sec IPC: denial begins when ipc queue size exceeds 18000 queue size denials = 0 30 second denial rate: recent 0/sec, max 0/sec BMA Messages: Total allowed count = 0 30 second rate: recent 0/sec, max 0/sec IPC: denial begins when ipc queue size exceeds 30000 queue size denials = 0 30 second denial rate: recent 0/sec, max 0/sec Quota Server Messages: Total allowed count = 0 30 second rate: recent 0/sec, max 4001/sec IPC: denial begins when ipc queue size exceeds 30000 queue size denials = 0 30 second denial rate: recent 0/sec, max 0/sec User Idle Timeout: Total allowed count = 0 30 second rate: recent 0/sec, max 0/sec Throughput: Rate limit is 1000/sec per traffic processor rate limit denials = 0 lm(usec) = 0 lm(elapse) = 0 lm(rate_period) = 3E8 rate(0, 3E8) 30 second denial rate: recent 0/sec, max 0/sec 30 second periods above rate 0, max 0 IPC: denial begins when ipc queue size exceeds 10000 queue size denials = 0 30 second denial rate: recent 0/sec, max 0/sec Gx Event Notification: Total allowed count = 0 30 second rate: recent 0/sec, max 0/sec Throughput: Rate limit is 200/sec per traffic processor rate limit denials = 0 lm(usec) = 0 lm(elapse) = 0 lm(rate_period) = 64 rate(0, 14) 30 second denial rate: recent 0/sec, max 0/sec 30 second periods above rate 0, max 0 IPC: denial begins when ipc queue size exceeds 10000 queue size denials = 0 30 second denial rate: recent 0/sec, max 0/sec Accel Flow Request: Total allowed count = 0 30 second rate: recent 0/sec, max 0/sec Throughput: Rate limit is 2400/sec per traffic processor rate limit denials = 0 lm(usec) = 0 lm(elapse) = 0 lm(rate_period) = 64 rate(0, F0) 30 second denial rate: recent 0/sec, max 0/sec 30 second periods above rate 0, max 0 PCI: denial buffer limit denial = 0 reason: rx:0, tx:0 (rx_max:0, tx_max:0) queue(delete:0, decel:0): missed: ipc rx=0, ctl=0 30 second denial rate: recent 0/sec, max 0/sec Accel IPv6 Flow Request: Total allowed count = 0 30 second rate: recent 0/sec, max 0/sec Throughput: Rate limit is 1000/sec per traffic processor rate limit denials = 0 lm(usec) = 0 lm(elapse) = 0 lm(rate_period) = 64 rate(0, 64) 30 second denial rate: recent 0/sec, max 0/sec 30 second periods above rate 0, max 0 PCI: denial
B-13
Appendix B CSG Load Management Statistics
buffer limit denial = 0 reason: rx:0, tx:0 (rx_max:0, tx_max:0) queue(delete:0, decel:0): missed: ipc rx=0, ctl=0 30 second denial rate: recent 0/sec, max 0/sec Delete Flow Request: Total allowed count = 0 30 second rate: recent 0/sec, max 0/sec PCI: denial buffer limit denial = 0 reason: rx:0, tx:0 (rx_max:0, tx_max:0) queue(delete:0, decel:0): missed: ipc rx=0, ctl=0 30 second denial rate: recent 0/sec, max 0/sec Decel Flow Request: Total allowed count = 0 30 second rate: recent 0/sec, max 0/sec PCI: denial buffer limit denial = 0 reason: rx:0, tx:0 (rx_max:0, tx_max:0) queue(delete:0, decel:0): missed: ipc rx=0, ctl=0 30 second denial rate: recent 0/sec, max 0/sec
There is a block of output for each type of transaction.

Radius Start Database Request Session Create BMA Messages Quota Server Messages User Idle Timeout Gx Event Notification Accel Flow Request Accel IPv6 Flow Request Delete Flow Request Decel Flow Request
For each type of transaction, there are two types of statistics, total and per second. A load management process runs on a 30-second interval and calculates the per second values based on that interval. The 30 second interval is periodic, not a sliding window. The following table lists and describes all of the fields in the CSG Load Management Stats output for the show ip csg stats command: Field IPC queue size current/highwater/max Total allowed count 30 second rate: recent 30 second rate: max Description Current, highwater, and maximum number of queued IPC messages. Total number of transactions allowed since the last clear ip csg counters command Number of transactions per second over the last 30-second period Highest number of transactions per second over a 30-second interval
B-14
OL-22840-05
Appendix B
Field Descriptions for CSG2 Statistics CSG Load Management Statistics
Field Throughput: Rate limit on control processor Throughput: rate limit denials Throughput: lm(usec) Throughput: lm(elapse) Throughput: lm(rate_period) 30 second denial rate: recent 30 second denial rate: max 30 second periods above rate: recent 30 second periods above rate: max IPC: denial begins when ipc queue size exceeds IPC: queue size denials IPC: 30 second denial rate: recent IPC: 30 second denial rate: max PCI: denial: buffer limit denial PCI: denial: reason: rx PCI: denial: reason: tx PCI: denial: reason: rx_max PCI: denial: reason: tx_max PCI: denial: queue: delete PCI: denial: queue: decel PCI: denial: queue: missed: ipc rx PCI: denial: queue: missed: ipc ctl PCI: 30 second denial rate: recent PCI: 30 second denial rate: max
Description Number of transactions allowed per second Total number of transactions denied due to rate limit since the last clear ip csg counters command Internal Cisco Use Internal Cisco Use Internal Cisco Use Transactions denied per second over the last 30-second interval, due to rate limit Highest number of transactions denied per second over a 30-second interval, due to rate limit Current number of 30-second intervals that exceeded the rate limit. Maximum number of 30-second intervals that exceeded the rate limit. Maximum number of queued IPC messages allowed by load management. Total number of transactions denied due to IPC queue depth since the last clear ip csg counters command Transactions denied per second over the last 30-second interval, due to IPC queue depth Highest number of transactions denied per second over a 30-second interval, due to IPC queue depth Total number of transactions denied due to PCI buffer depth since the last clear ip csg counters command Number of outgoing PCI packets dropped because the receiving buffer is over the limit Number of outgoing PCI packets dropped because the transmitting buffer is over the limit Maximum number of packets in the receiving PCI buffer Maximum number of packets in the transmitting PCI buffer Number of DELETE requests dropped due to insufficient PCI buffer Number of DECEL requests dropped due to insufficient PCI buffer Number of received PCI packets dropped due to buffer allocation failure Number of received PCI packets dropped due to context fastblock allocation failure Transactions denied per second over the last 30-second interval, due to PCI buffer depth Highest number of transactions denied per second over a 30-second interval, due to PCI buffer depth
B-15
Appendix B CSG Buffer Management Statistics
CSG Buffer Management Statistics

CSG Buffer Management Stats: Counter | RADIUS Application Fragment Unlimited -----------------------------------------------------------------------------Mem Max | 0 33554432 4194304 0 Mem Used | 0 0 0 1536 Pct Used | 0 0 0 0 Create | 0 0 49325 94 Copy | 0 0 0 0 Free | 0 0 49325 93 Alloc Fail| 0 0 0 0 Copy Fail | 0 0 0 0 Held | 0 0 0 1 Max Held | 0 0 8191 19 Denied | 0 0 0 0 Errors | 0 0 0 0
Buffer management limits the number of buffers that the CSG2 can allocate to specific categories. This prevents one component from starving the other components by consuming all the available buffers. There are 4 categories of managed buffers:

RADIUSThe RADIUS component must occasionally queue RADIUS packets before sending them. This category manages buffers used to queued RADIUS packets. ApplicationProtocol handlers that are parsing can only accept packets in order. TCP packets that arrive out of order are queued until the protocol handler is ready for them. This category manages buffers used to queue packets for protocol handlers. FragmentFragmented IP packets are collected and held until the entire fragment family has been collected. This category manages buffers that are used to hold fragment packets. UnlimitedThese are buffers that do not belong to any managed category. They are not limited by buffer management. They are counted and the statistics are presented for informational purposes.
The statistics for buffer management can be either normal or detailed based on the type of statistics requested. The following table lists and describes all of the fields in the CSG Buffer Management Stats detailed output for the show ip csg stats detail command for the CP (processor 3). The table is repeated for each of the TPs (processors 4 through 8). The CP table represents the aggregate counts for the CP and all of the TPs. Each TP report represents only the counts for that processor. Field Mem Max Mem Used Pct Used Description Maximum memory allowed by buffer management for this category, in bytes Number of bytes currently in use for this category Percent of allowed memory in use for this category: (Mem Used / Mem Max) * 100 = Pct Used If the Pct Used statistics approaches 100%, buffer management is likely to deny requests for that category. Create Copy Number of successful buffer allocations for the category Number of successful buffer copies for the category. A copy represents the creation of a buffer; however the Create counter is not incremented for copy operations.
B-16
OL-22840-05
Appendix B
Field Descriptions for CSG2 Statistics CSG User Database Statistics
Field Free
Description Number of buffer frees for the category. Each buffer that is created or copied must be freed before it can be used again. In a well running system, the Free counter should be very close to the total of the Create counter plus the Copy counter. Buffer allocations (Creates) that fail to get a buffer due to an out-of-buffer memory condition. This indicates a severe out-of-memory condition. If the Alloc Fail counter is not zero, at some point there was a significant unmanaged usage of buffers or overall saturation of buffers, creating a general buffer shortage. Buffer management was put in place to minimize the chance of this happening, but it can still occur in the following situations:

Alloc Fail
If there is very high buffer usage across all categories. If traffic is high and free buffers cannot be added back into the pools quickly enough.
Copy Fail
Buffer copies that fail to get a buffer due to an out-of-buffer memory condition. This indicates a severe out-of-memory condition. If the Copy Fail counter is not zero, at some point there was a significant unmanaged usage of buffers or overall saturation of buffers, creating a general buffer shortage. Buffer management was put in place to minimize the chance of this happening, but it can still occur in the following situations:

If there is very high buffer usage across all categories. If traffic is high and free buffers cannot be added back into the pools quickly enough. Create + Copy - Free = Held
Held Max Held Denied
Number of buffers currently in use for the category: Maximum value the Held counter has reached since the last clear ip csg counters command Number of buffer Create or Copy operations that have been denied due to buffer management. If the Deny counter is not zero, an overload condition has occurred. If the Deny counter is a significant percentage of the total of the Create and Copy counters, the overload condition is significant. If consecutive show ip csg stats commands indicate a growing Deny counter, the overload condition is ongoing.
Errors
Number of general errors in the buffer management module. Should always be zero. A non-zero value indicates that buffer management is losing track of buffers and will ultimately miss-manage the buffers.
CSG User Database Statistics

CSG User Database Stats: errors = 0
The following table lists and describes all of the fields in the CSG User Database Stats output for the show ip csg stats command: Field errors Description Number of errors encountered when populating the CSG2 user database.
B-17
Appendix B CSG Session Layer 4 Statistics
CSG Session Layer 4 Statistics

CSG Session L4 Stats: alloc fail ooo node = 0 alloc fail pak copy enqueue = 0 general errors = 0 FSM errors = 262 standby FSM errors = 0 count errors = 0 term idle = 838696 term short timer = 10179 alloc fail seq num node = 0 insert fail seq num node = 0 tmr check error = 0 Network interface: TCP packets = 266880460 TCP frags = 0 datagram packets = 4932124 datagram frags = 161 out of order = 93841 out of order get = 91870 out of order flushed = 1971 retransmitted = 94873 set aside = 56824 set aside get = 56412 set aside flushed = 412 term closed = 1003483 term RST = 10 term not SYN = 259 term mid SYN = 0 term error = 0 dropped OOW = 323808 dropped set aside = 292592 dropped queue size = 0 dropped error = 259 Seq Num queue depth hwm = 2 Seq Num queue depth exceeded = 0 lost pkt queue exceeded = 0 Subscriber interface TCP packets = 192907977 TCP frags = 0 datagram packets = 13347893 datagram frags = 0 out of order = 412 out of order get = 384 out of order flushed = 28 retransmitted = 485 set aside = 9504977 set aside get = 9418614 set aside flushed = 86222 term closed = 1362349 term RST = 457991 term not SYN = 0 term mid SYN = 0 term error = 0 dropped OOW = 0 dropped set aside = 692663 dropped queue size = 0 dropped error = 0 Seq Num queue depth hwm = 2 Seq Num queue depth exceeded = 0 lost pkt queue exceeded = 0
B-18
OL-22840-05
Appendix B
Field Descriptions for CSG2 Statistics CSG Session Layer 4 Statistics
CSG2 Layer 4 session statistics are divided into three categories:

General statistics Network interface statistics Subscriber interface statistics
The same fields are displayed for both the network and subscriber interface statistics, but the values of those fields might be different. The following table lists and describes all of the fields in the CSG Session L4 Stats output for the show ip csg stats command. Unless otherwise stated, the term packet in this table also refers to a fragment family. Field alloc fail ooo node alloc fail pak copy enqueue Description An out-of-order packet was being added to the out-of-order list and the allocation for the element failed. The session is ended. An attempt to requeue a packet failed. This problem can occur when a mid-flow SYN is received. The SYN is requeued and the session is ended. Non-specific errors. This problem can occur for one of the following reasons:

general errors
No session context during a session timeout Out-of-order packet insertion fails, or no out-of-order packet is provided (session ended) Frag reassembly fails (session ended) A protocol handler drives an FSM event that results in an error (protocol handler might end the session) A packet is set aside when a setaside packet already exists
FSM errors standby FSM errors count errors term idle term short timer alloc fail seq num node
An invalid state transition occurred in the session services FSM An invalid state transition occurred in the session services FSM. The error occurred while the blade was in standby mode. An error occurred while attempting to count packet bytes. Most protocol handlers end the session if a count error occurs. Number of sessions that ended due to idle timeout Number of sessions that ended due to short timer timeout (SYN or FIN timer) Number of allocation failures for out-of-order sequence number nodes. These are used when out-of-order forwarding is enabled or when QoS is enabled. Number of insertion failures for out-of-order sequence number nodes. These are used when out-of-order forwarding is enabled or when QoS is enabled. The number of freed session objects that might not have been properly destroyed Number of TCP packets processed at Layer 4 Number of TCP fragment families (not packets) processed at Layer 4
insert fail seq num node
tmr check error TCP packets TCP frags
B-19
Appendix B CSG Session Layer 4 Statistics
Field datagram packets datagram frags out of order
Description Number of non-TCP packets (such as UDP, ICMP, and so on) processed at Layer 4 Number of non-TCP fragment families (such as UDP, ICMP, and so on), not packets, processed at Layer 4 Number of TCP packets received out of order and queued. Out-of-order packets that are processed with out-of-order forwarding enabled are not counted. Number of queued out-of-order packets retrieved from the queue Number of queued out-of-order packets that are cleaned up when the queue is emptied, typically due to a session being destroyed Number TCP retransmitted packets processed at Layer 4 Number of packets queued in setaside by protocol handlers Number of packets dequeued from setaside Number of packets cleaned from setaside, typically due to a session being destroyed, but setaside is also flushed if a protocol handler injects a packet into a session (AoC) Number of sessions ended due to reaching CLOSED state due to FIN signaling Number of sessions ended due to reaching CLOSED state due to RST signal Number of sessions ended due to Layer 4 processing a non-SYN packet as the first packet received from an interface direction (subscriber or network) Number of sessions ended due to receiving a new SYN within a flow Number of sessions ended due to an unrecoverable error. Number of TCP packets dropped due to being out-of-window Number of packets dropped because there is a packet in set-aside Number of TCP out-o- order packets dropped because they cannot be queued due to the out of order queue being full Number of packets dropped due to a Layer 4 packet processing error Largest number of entries in the sequence number queue used for QoS and out-of-order forwarding.
Note
out of order get out of order flushed retransmitted set aside set aside get set aside flushed
term closed term RST term not SYN
term mid SYN term error dropped OOW dropped set aside dropped queue size dropped error Seq Num queue depth hwm
When statistics are displayed for the CP, this field displays the total number from the CP and from all TPs, and is not very useful. The number in this field is more useful when statistics are displayed for each individual TP.
Seq Num queue depth exceeded lost pkt queue exceeded
Number of times a new entry to the sequence number queue has failed due to the queue being full Number of failed sequence number insertions, for example, due to queue depth exceeded
B-20
OL-22840-05
Appendix B
Field Descriptions for CSG2 Statistics CSG Fragment Statistics
CSG Fragment Statistics

CSG Fragment Stats: locked = 0 lock errors = 0 unlock errors = 0 CSG IPv4 Fragment Stats creates = 161, destroys = 161, timeouts = 0, Leaders: rx = 161, tx = 161, dropped = 0, creates = 161 Trailers: rx = 966, tx = 966, dropped = 0, creates = 0 Reassemble: invalid = 0, max_payload_exceed = 0 alloc failures = 0, overlap = 0, missing leader = 0 failed tx = 0, requeues = 0, failed requeues = 0 missing trailer = 0
The following table lists and describes all of the fields in the CSG Fragment Stats output for the show ip csg stats command. Except as noted, all statistics are for IPv4 fragments. Field locked lock errors unlock errors creates destroys timeouts Leaders: rx Leaders: tx Leaders: dropped Leaders: creates Trailers: rx Trailers: tx Trailers: dropped Trailers: creates Reassemble: invalid Reassemble: max_payload_exceed Reassemble: alloc failures Reassemble: overlap Reassemble: missing leader Reassemble: failed tx Reassemble: requeues Reassemble: failed requeues Reassemble: missing trailer Description Number of IPv4 and IPv6 fragment families that were locked Number of IPv4 and IPv6 fragment family lock errors Number of IPv4 and IPv6 fragment family unlock errors Number of IPv4 fragment families detected Number of families destroyed Number of families that timed out before being completely reassembled Number of fragment leading packets received Number of fragment leading packets attempted to send Number of leaders dropped Number of leader memory creations Number of fragment trailer packets received Number of fragment trailer packets attempted to send Number of trailers dropped Number of trailer memory creations Number of failed reassembly attempts due to payload length conflict or lack of leader or trailers Number of invalid payload lengths detected Number of memory allocation failures Number of sequence number overlaps detected Number of families not completed due to no fragment leader Number of failed family sends Number of internal fragment family requeues Number of unexpected fragment family requeue failures Number of families not completed due to no frag trailer
B-21
Appendix B CSG IPv6 Fragment Statistics
CSG IPv6 Fragment Statistics

CSG IPv6 Fragment Stats: creates = 161, destroys = 161, timeouts = 0, Leaders: rx = 161, tx = 161, dropped = 0, creates = 161 Trailers: rx = 966, tx = 966, dropped = 0, creates = 0 Reassemble: invalid = 0, max_payload_exceed = 0 alloc failures = 0, overlap = 0, missing leader = 0 failed tx = 0, requeues = 0, failed requeues = 0 missing trailer = 0
The following table lists and describes all of the fields in the CSG IPv6 Fragment Stats output for the show ip csg stats command. All statistics are for IPv6 fragments. Field creates destroys timeouts Leaders: rx Leaders: tx Leaders: dropped Leaders: creates Trailers: rx Trailers: tx Trailers: dropped Trailers: creates Reassemble: invalid Reassemble: max_payload_exceed Reassemble: alloc failures Reassemble: overlap Reassemble: missing leader Reassemble: failed tx Reassemble: requeues Reassemble: failed requeues Reassemble: missing trailer Description Number of IPv6 fragment families detected Number of families destroyed Number of families that timed out before being completely reassembled Number of fragment leading packets received Number of fragment leading packets attempted to send Number of leaders dropped Number of leader memory creations Number of fragment trailer packets received Number of fragment trailer packets attempted to send Number of trailers dropped Number of trailer memory creations Number of failed reassembly attempts due to payload length conflict or lack of leader or trailers Number of invalid payload lengths detected Number of memory allocation failures Number of sequence number overlaps detected Number of families not completed due to no fragment leader Number of failed family sends Number of internal fragment family requeues Number of unexpected fragment family requeue failures Number of families not completed due to no frag trailer
CSG Packet Statistics

CSG Packet Stats: drop wait clock sync = 0 IPv4: packet rcv = 509381050, drop invalid = 0, protocol drop = 26408409, no handler = 0, no handler options = 0, drop no Gx rule = 0, no content = 3, no session = 31791002 wait preload = 0, drop no adjacency = 0, drop kill me = 0 local enqueue = 2187, local enqueue failed = 0
B-22
OL-22840-05
Appendix B
Field Descriptions for CSG2 Statistics CSG Packet Statistics
local enqueue copy = 18, punts = 0 packet send failures = 0, packet update queue fail = 0 addr alloc fail = 0 IPv6: packet rcv = 0, drop invalid = 0, protocol drop = 0, no handler = 0, no handler options = 0, drop no Gx rule = 0, no content = 0, no session = 0 wait preload = 0, drop no adjacency = 0, drop kill me = 0 drop no pak subblock = 0 local enqueue = 0, local enqueue failed = 0 local enqueue copy = 0, punts = 0 packet send failures = 0, packet update queue fail = 0 addr alloc fail = 0
The following table lists and describes all of the fields in the CSG Packet Stats output for the show ip csg stats command: Field drop wait clock sync IPv4: packet rcv IPv4: drop invalid IPv4: protocol drop IPv4: no handler IPv4: no handler options IPv4: drop no Gx content IPv4: no content IPv4: no session Description Number of IPv4 and IPv6 packets dropped because the system clock was not synchronized between the CP and TPs Total number of IPv4 packets received by the CSG2 Number of IPv4 packets dropped due to incomplete TCP headers Total number of IPv4 packets dropped by the protocol parsing code Number of IPv4 packets dropped because there was no protocol handler registered to parse the packet Subset of the no handler counter. Number of IPv4 packets with options. Number of IPv4 Gx packets dropped that did not match a content Number of IPv4 packets dropped that did not match a content Number of IPv4 packets dropped that matched a content but a session was not created (for example, the first packet in a TCP session did not have the SYN flag set) Number of IPv4 packets dropped after boot because the CSG2 was in policy preload. The CSG2 drops packets during the initial boot policy preload. Number of IPv4 packets dropped due to Layer 2 information for the next-hop not being found Number of IPv4 packets dropped because they were received on a session that was scheduled for asynchronous cleanup Number of CSG2-originated IPv4 packets that were enqueued to a special background task Number of failures in queuing to the special background task Number of times an IPv4 packet was copied to a public buffer (show buffer). This usually occurs prior to queuing the packet to a special background task. Number of IPv4 packets that were punted from the receive interrupt path to the IP process switch path. If this field is not zero, an exception has occurred. Number of failures to send an IPv4 packets out
IPv4: wait preload
IPv4: drop no adjacency IPv4: drop kill me IPv4: local enqueue IPv4: local enqueue failed IPv4: local enqueue copy
IPv4: punts
IPv4: packet send failures
B-23
Appendix B CSG Distributed User Table Statistics
Field IPv4: packet update queue fail IPv4: addr alloc fail IPv6: packet rcv IPv6: drop invalid IPv6: protocol drop IPv6: no handler IPv6: no handler options IPv6: drop no Gx content IPv6: no content IPv6: no session
Description Number of failures to update an internal (per-session) queue that tracks TCP sequence numbers Number of times the CSG2 failed to allocate space for an IPv4 address Total number of IPv6 packets received by the CSG2 Number of IPv6 packets dropped due to incomplete TCP headers Total number of IPv6 packets dropped by the protocol parsing code Number of IPv6 packets dropped because there was no protocol handler registered to parse the packet Subset of the no handler counter. Number of IPv6 packets with options. Number of IPv6 Gx packets dropped that did not match a content Number of IPv6 packets dropped that did not match a content Number of IPv6 packets dropped that matched a content but a session was not created (for example, the first packet in a TCP session did not have the SYN flag set) Number of IPv6 packets dropped after boot because the CSG2 was in policy preload. The CSG2 drops packets during the initial boot policy preload. Number of IPv6 packets dropped due to Layer 2 information for the next-hop not being found Number of IPv6 packets dropped because they were received on a session that was scheduled for asynchronous cleanup Number of IPv6 packets dropped because of allocation failures Number of CSG2-originated IPv6 packets that were enqueued to a special background task Number of failures in queuing to the special background task Number of times an IPv6 packet was copied to a public buffer (show buffer). This usually occurs prior to queuing the packet to a special background task. Number of IPv6 packets that were punted from the receive interrupt path to the IP process switch path. If this field is not zero, an exception has occurred. Number of failures to send an IPv6 packets out Number of failures to update an internal (per-session) queue that tracks TCP sequence numbers Number of times the CSG2 failed to allocate space for an IPv6 address
IPv6: wait preload
IPv6: drop no adjacency IPv6: drop kill me IPv6: drop no pak subblock IPv6: local enqueue IPv6: local enqueue failed IPv6: local enqueue copy
IPv6: punts
IPv6: packet send failures IPv6: packet update queue fail IPv6: addr alloc fail
CSG Distributed User Table Statistics

CSG Distributed KUT Stats: requests = 75197, responses = 62442, resends = 23430 timeouts = 11652, idle timeouts = 0, corr mismatch = 0
B-24
OL-22840-05
Appendix B
Field Descriptions for CSG2 Statistics CSG Distributed User Table Statistics
corr missing = 0, unknown IP = 11652 unknown ha vrf = 0, tx fail ipc = 0 qos display err = 0 Gx: no matching rule = 0, flow gating closed = 0, notify fail = 0, krec fail = 0, HA fail = 0 aff lookup fail = 0, invalid kut ipc reqtype = 0 alloc failures: kut = 0, kut_delete_event = 0, rad attr = 0 int_stats = 0, kut_svc = 0, svc_stats = 0 tariff = 0, redir_info = 0, passthru_grant = 0 refund = 0, txn_abort = 0, ipc = 0 basis = 0, tariff = 0, redir_info = 0 passthru_grant = 0, refund = 0, txn_abort = 0 ipc = 0 Gx: elem = 0, 3gpp filter = 0, cisco filer = 0 rule = 0, asid table = 0, asid txn = 0 svc status = 0, dia req ack = 0, pcc info = 0 kut cleanup failure = 0, duplicate txn open = 0
The following table lists and describes all of the fields in the CSG Distributed KUT Stats output for the show ip csg stats command: Field requests response resends timeouts idle timeouts corr mismatch corr missing unknown IP unknown ha vrf tx fail ipc qos display err Gx: no matching rule Gx: flow gating closed Gx: notify fail Gx: krec fail Gx: HA fail Gx: aff lookup fail Gx: invalid kut ipc reqtype alloc failures: kut alloc failures: kut_delete_event alloc failures: rad attr alloc failures: int_stats alloc failures: kut_svc alloc failures: svc_stats Description Number of user database queries Number of user database responses Number of user database query retries Number of user database query timeouts Number of user deletions by user idle timer Number of correlator mismatches on RADIUS Accounting Stop Number of no correlator in RADIUS Accounting Stops Number of user database responses with no user ID Number of user's VRF not found during HA Number of failed to send IPC message to CP Number of failed to show QoS information Number of traffic flows not matching any Gx rule Number of traffic flows dropped due to Gx rule flow status disabled Number of failed to send Gx notification IPC message to CP Number of failed to construct IPC message sent to CP Number of failed to replicate Gx user Number of failed to look up the Gx user on CP Number of unexpected IPC message request types Number of failed to allocate User Table element Number of failed to allocate User Table delete event Number of failed to allocate RADIUS attribute Number of failed to allocate interval statistics Number of failed to allocate User Table service Number of failed to allocate User Table service status
B-25
Appendix B CSG User Statistics
Field alloc failures: basis alloc failures: tariff alloc failures: redir_info alloc failures: passthru_grant alloc failures: refund alloc failures: txn_abort alloc failures: ipc alloc failures: Gx: elem alloc failures: Gx: 3gpp filter alloc failures: Gx: cisco filer alloc failures: Gx: rule alloc failures: Gx: asid table alloc failures: Gx: asid txn alloc failures: Gx: svc status alloc failures: Gx: dia req ack alloc failures: Gx: pcc info kut cleanup failure duplicate txn open
Description Number of failed to allocate User Table service basis Number of failed to allocate User Table service tariff switch Number of failed to allocate redirect information Number of failed to allocate passthrough grant Number of failed to allocate refund Number of failed to allocate transaction abort Number of failed to allocate IPC message Number of failed to allocate User Table Gx elem Number of failed to allocate 3GPP filter Number of failed to allocate Cisco filter Number of failed to allocate Gx rule Number of failed to allocate Accounting Session ID table Number of failed to allocate Accounting Session ID transaction Number of failed to allocate Gx service status Number of failed to allocate Diameter Request ACK IPC message Number of failed to allocate Gx PCC information Number of user clean up errors Number of transaction open errors due to duplicated transaction
CSG User Statistics

CSG User Stats: max = 300000, current = 148916, highwater = 169990 exceed-max = 0, aff_err = 0, rsp_nak = 0 kut current = 148916, kut highwater = 169990 sticky current = 0, sticky highwater = 318 Gx user current = 0, highwater = 0 rule current = 0, highwater = 0 unknown rcv = 0, continuation requested = 0 coa txn requested = 0, failed = 0 coa responses = 0 pcrf failure continue = 0, timeout continue = 0 ipc tx fail = 0, ipc response timeouts = 231557 route inject error = 0, route delete error = 0 pending radius drops = 0 aff dual-stack IPv4 conflicts = 0 alloc failures: aff_elem = 0, aff_key = 0, aff_podsrc = 0 aff_pend_event = 0, aff_del_event = 0 ipc = 0, gx stuff = 0, gx info = 0 gx req = 0, gx raa = 0, gx dgr event = 0 gx dgr name ref = 0, gx dgr report = 0 gx sess_info cleanup = 0, cisco event = 0 gx failed rule = 0, gx acc chrg id = 0 gx cr install = 0, gx cr install flow filter = 0 gx cr delete = 0, gx cr = 0, gx cr failure = 0 route inject = 0, route delete = 0 svc group event = 0
B-26
OL-22840-05
Appendix B
Field Descriptions for CSG2 Statistics CSG User Statistics
dual-stack: elem = 0, key = 0 ha receive drops: no aff = 0, unknown vrf = 0, state = 0 no gx stuff = 0, gx sess info alloc = 0 add alloc = 0
The following table lists and describes all of the fields in the CSG User Stats output for the show ip csg stats command: Field max current highwater exceed-ma aff_err rsp_nak kut current kut highwater sticky current sticky highwater Gx: user current Gx: highwater Gx: rule current Gx: highwater Gx: unknown rcv Gx: continuation requested Gx: coa txn requested Gx: failed Gx: coa responses Gx: pcrf failure continue Gx: timeout continue ipc tx fail ipc response timeouts route inject error route delete error pending radius drops aff dual-stack IPv4 conflicts alloc failures: aff_elem alloc failures: aff_key alloc failures: aff_podsrc alloc failures: aff_pend_event alloc failures: aff_del_event alloc failures: ipc Description Maximum number of users, configured via ip csg entries user maximum command Current number of users, including User Table and sticky Highwater number of users, including User Table and sticky Number of attempts to create more users than max Number of user state machine errors Number of failed requests due to internal error Current number of User Table users Highwater number of User Table users Current number of sticky users Highwater number of sticky users Current number of Gx users Highwater number of Gx users Current number of Gx rules Highwater number of Gx rules Number of unknown Gx IPC message Number of Gx IPC messages sent to request more Gx data Number of CoA sent for Gx Number of failed attempts to send CoA for Gx Number of CoA responses received Number of users created due to pcrf failure continue Number of users created due to pcrf timeout continue Number of failed to send IPC message to TP Number of IPC message timeouts Number of failed attempts for route injection Number of failed attempts for route deletion Number of dropped RADIUS messages Number of IPv4 address conflicts Number of failed to allocate CG Affinity Number of failed to copy CG Affinity IP address Number of failed to allocate PoD/CoA source IP address Number of failed to allocate CG Affinity pending event Number of failed to allocate CG Affinity delete event Number of failed to allocate IPC message
B-27
Appendix B CSG Session Statistics
Field alloc failures: gx stuff alloc failures: gx info alloc failures: gx req alloc failures: gx raa alloc failures: gx dgr event alloc failures: gx dgr name ref alloc failures: gx dgr report alloc failures: gx sess_info cleanup alloc failures: cisco event alloc failures: gx failed rule alloc failures: gx acc chrg id alloc failures: gx cr install alloc failures: gx cr install flow filter alloc failures: gx cr delete alloc failures: gx cr alloc failures: gx cr failure alloc failures: route inject alloc failures: route delete alloc failures: svc group event dual-stack: elem dual-stack: key ha receive drops: no aff ha receive drops: unknown vrf ha receive drops: state ha receive drops: no gx stuff ha receive drops: gx sess info alloc ha receive drops: add alloc
Description Number of failed to allocate Gx stuff Number of failed to allocate Gx information element Number of failed to allocate Gx message for CCR Number of failed to allocate Gx message for RAA Number of failed to allocate Gx DGR event Number of failed to allocate Gx DGR name reference Number of failed to allocate Gx DGR report Number of failed to allocate Gx sync session to clean up MPCC Number of failed to allocate element for Cisco event Number of failed to allocate element for failed Gx rule Number of failed to allocate element for Access Network Charging ID Number of failed to allocate element for installing rule Number of failed to allocate element for flow filters Number of failed to allocate element for deleting rule Number of failed to allocate element for rule Number of failed to allocate element for failed rule Number of failed to allocate element for route injection Number of failed to allocate element for route deletion Number of failed to allocate element for Service Group event Number of failed to allocate element for Dual Stack element Number of failed to copy Dual Stack IP address Number of failed to look up users during HA Number of failed to look up vrf during HA Number of user state machine errors during HA Number of Gx user with no Gx stuff during HA Number of failed to allocate Gx sync session during HA Number of failed to add allocate
CSG Session Statistics

CSG Session Stats: user sessions = 531, highwater = 169455, ha_overrun = 0 max limit = 0, wc fail = 0, no content = 0 appl fail = 30314998, denied = 1487001, ha no content = 0 ha no session = 17529, ha content oos = 0 Resets : subscriber = 46196262, network = 15603410 Alloc failures : wc = 0, session = 0 prof event = 0, resolve event = 0, pend quota = 0 pend aoc = 0 Resolve : no sess = 1, event fail = 3042, enq fail = 0 dup quota = 0, dup aoc = 0, aoc fail = 79 sess lookup fail = 0
B-28
OL-22840-05
Appendix B
Field Descriptions for CSG2 Statistics CSG ACCEL Statistics
The following table lists and describes all of the fields in the CSG Session Stats output for the show ip csg stats command: Field user sessions highwater ha_overrun max limit wc fail no content appl fail denied ha no content ha no session ha content oos Resets: subscriber Resets: network Alloc failures: wc Alloc failures: session Alloc failures: prof event Alloc failures: resolve event Alloc failures: pend quota Alloc failures: pend aoc Resolve: no sess Resolve: event fail Resolve: enq fail Resolve: dup quota Resolve: dup aoc Resolve: aoc fail Resolve: sess lookup fail Description Number of concurrent data sessions Highest number of data sessions Internal Cisco Use Number of a new session was denied because the processor was at the maximum number of sessions Internal Cisco Use Internal Cisco Use Number of times a protocol failed to initialize properly when setting up a new session Number of times a TCP session was not created because the first packet received was not a SYN Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use Fastblock memory depleted Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use Number of times the billing information could not be found for a subscriber Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use
CSG ACCEL Statistics

CSG ACCEL Stats: Requests: accel = 0, ppc decel = 0, ixp decel = 0, decel timeout = 0, ppc term = 0 Ack/Nack: accel intr = 0/0, decel = 0/0, term = 0/0 accel proc = 0/0 Misc: interm = 0, time rst = 0, naccel = 0, tr decel = 0, sn trigger = 0, sn only = 0,
B-29
Appendix B CSG ACCEL Statistics
norm = 0, tr no sess = 0, fsm no sess = 0, kill no acc = 0, tr_declined = 0, pend decel = 0, no sess = 0 Err: alloc = 0, misc = 0, fin trailer = 0, tr_alloc = 0, msg ptr = 0, msg id = 0, pci = 0, fmod = 0, bad trail = 0, cookie = 0 PCI: sent err = 0, rsp err = 0, timeout = 0, retry = 0, retry_succeed = 0, retry_failed = 0, delete rsp timeout = 0, decel rsp timeout = 0 Packet dest: hyp = 0, ixp1 = 0, ipx2 = 0 Flow Modify: reqs = 0, kill = 0, encap = 0 Accel Sessions = 0, Accel Pending = 0, Decel Pending = 0 Delete Pending = 0 IPC: fail = 0, timeout = 0 Decel Rsn: inv = 0, ppc = 0, idle = 0, time = 0, bytes = 0, seq = 0, frag = 0, tcp = 0, encap = 0, v4 opt = 0, v6 ext = 0, pre_trig = 0, unk = 0
The following table lists and describes all of the fields in the CSG ACCEL Stats output for the show ip csg stats command. These statistics are displayed only if at least one content has been enabled for accelerated sessions and placed in service. Field Requests: accel Requests: ppc decel Requests: ixp decel Requests: decel timeout Requests: ppc term Ack/Nack: accel intr Ack/Nack: decel Ack/Nack: term Ack/Nack: accel proc Misc: interm Misc: time rst Misc: naccel Misc: tr decel Misc: sn trigger Misc: sn only Misc: norm Misc: tr no sess Misc: fsm no sess Misc: kill no acc Description Number of acceleration request messages sent from the PPC Number of deceleration request messages sent from the PPC Number of deceleration request messages sent from the IPC Number of deceleration request timeouts Number of delete request messages sent from the PPC to cleanup an IXP flow record for a session Number of positive and negative replies to acceleration requests sent from the PPC Number of positive and negative replies to deceleration requests sent from the PPC Number of positive and negative replies sent to delete flow requests sent from the PPC Internal Cisco Use Number of intermediate updates from the IXP Number of last packet time rounding mismatches Number of sessions placed into don't attempt acceleration state Number of packets from the IXP containing a deceleration trailer Number of pre-acceleration trigger matches Number of packets containing serial numbers that did not trigger an action on the PPC Number of packets that did not contain a trailer or serial number Number of packet received that contained a trailer for which the PPC did not have a session Number of times the PPC acceleration Finite State Machine (FSM) was invoked with no corresponding session Number of flow modify messages sent to the IXP with the kill bit set
B-30
OL-22840-05
Appendix B
Field Descriptions for CSG2 Statistics CSG ACCEL Statistics
Field Misc: tr_declined Misc: pend decel Misc: no sess Err: alloc Err: misc Err: fin trailer Err: tr_alloc Err: msg ptr Err: msg id Err: pci Err: fmod Err: bad trail Err: sess_fsm_err Err: cookie PCI: sent err PCI: rsp err PCI: timeout PCI: retry PCI: retry_succeed PCI: retry_failed PCI: delete rsp timeout PCI: decel rsp timeout Packet dest: hyp Packet dest: ixp1 Packet dest: ipx2 Flow Modify: reqs Flow Modify: kill Flow Modify: encap Accel Sessions Accel Pending Decel Pending Delete Pending IPC: fail IPC: timeout Decel Rsn: inv Decel Rsn: ppc Decel Rsn: idle Decel Rsn: time
Description Number of packets with trailer that were declined by the PPC Number of deceleration requests sent by the PPC while in acceleration pending state Number of messages received from the IXP that did not correspond to an existing session on the PPC Number of memory allocation failures Number of various unexpected conditions Number of problems finalizing acceleration trailers Number of memory allocation failures of packet trailers Number of invalid PCI messages encountered Number of unknown message identifiers Number of general errors for PCI message handling Number of errors related to flow modify messages Number of badly formatted trailers received in packets from the IXP Number of acceleration state errors detected Number of session cookie mismatches between the PPC and the IXP Number of send request failures for PCI messages Number of response failures for PCI messages Number of PCI message timeouts Total number of PCI message retries Number of successful PCI message retries Number of unsuccessful PCI message retries Number of delete requests with no response from the IXP Number of deceleration requests with no response from the IXP Number of packets sent to the Hyperion (normal packet exit) Number of packets sent to IXP1 for additional handling Number of packets sent to IXP2 for additional handling Number of flow modify requests sent to the IXP Number of flow modify kill requests sent to the IXP Number of flow modify encap updates sent to the IXP Current number of accelerated sessions Current number of sessions in Accel Pending state Current number of sessions in Decel Pending state Current number of session in Delete Pending state Number of IPC acceleration message send failures Number of IPC acceleration message timeouts Number of sessions decelerated because they were invalid Number of sessions decelerated by the PPC Number of sessions decelerated because they idled out on the IXP Number of sessions decelerated because they exceeded the maximum time allowed on the IXP
B-31
Appendix B CSG LogGen Statistics
Field Decel Rsn: bytes Decel Rsn: seq Decel Rsn: frag Decel Rsn: tcp Decel Rsn: encap Decel Rsn: v4 opt Decel Rsn: v6 ext Decel Rsn: pre_trig Decel Rsn: unk
Description Number of sessions decelerated because they exceeded the maximum number of bytes allowed on the IXP Number of sessions decelerated because of problems with the TCP sequence number range Number of sessions decelerated because IP fragments were detected on the IXP Number of sessions decelerated because the TCP signaling bit was set (that is, FIN/RST) Number of sessions decelerated because of a change in encap value Number of sessions decelerated because of IPv4 packet options Number of sessions decelerated because of IPv6 packet extensions Number of sessions decelerated because a trigger was hit before the acceleration state was achieved Number of sessions decelerated for reasons that were not specified
CSG LogGen Statistics

alloc fail = 0, gtp reject = 0 Billing records: sent = 0, fail = 0, user = 0, svc lvl = 0 eG-CDR usage records: sent = 3, fail = 0 IPC: alloc fail = 0, sent = 0, fail = 0, rcv = 0
These statistics have to do with the sending of CDRs. The following table lists and describes all of the fields in the CSG LogGen Stats output for the show ip csg stats command: Field alloc fail gtp reject Billing records: sent Billing records: fail Billing records: user Billing records: svc lvl eG-CDR usage records: sent eG-CDR usage records: fail IPC: alloc fail IPC: sent IPC: fail IPC: rcv Description Number of times failed to allocate memory Number of times receiving GTP' Data Record Transfer Response with Reject Cause Code Number of CDRs sent to BMA Number of times failed to send CDRs to BMA Number of user termination CDRs sent to BMA Number of service-level CDRs sent to BMA Number of eG-CDRs sent to GGSN Number of times failed to send eG-CDRs to GGSN Number of times failed to allocate IPC buffers Number of CDRs sent by TP via IPC Number of times TP failed to send CDRs via IPC Number of CDRs received by CP via IPC
B-32
OL-22840-05
Appendix B
Field Descriptions for CSG2 Statistics GTP Application: CSG IPC, Local Port: 0
GTP Application: CSG IPC, Local Port: 0

GTP Application: CSG ipc, Local Port: 0 alloc failures = 0, no standby on CG failure = 0 packets sent = 15, received = 29611, failed acks = 0 packets dropped = 0, rejected = 0, retransmits = 0, no ip = 0 packets outstanding: current = 0, highwater = 2 bad records = 0, unknown CG = 0, CG failures = 0 send skipped = 0, records dropped during drain = 0 Charging Gateways: defined = 1, max active = 5 127.1.0.3:0 0 ACTIVE
The following table lists and describes all of the fields in the GTP Application: CSG ipc output for the show ip csg stats command: Field alloc failures no standby on CG failure packets sent received failed acks packets dropped rejected retransmits no ip packets outstanding: current packets outstanding: highwater bad records unknown CG CG failures send skipped Description Low available system memory caused a problem A failure occurred and there was no available standby Charging Gateway (CG) Number of GTP' packets sent Number of GTP' packets received Number of spurious acknowledgements received (no corresponding sent request in the CSG2) Number of packets dropped by the GTP' application Number of packets received with the Cause Code Rejected Number of retransmitted packets by the CSG2 All non-Data Transfer Requests that are dropped because the corresponding CG has no IP address Current number of packets sent to the CG that were not acknowledged Highwater number of packets sent to the CG that were not acknowledged Number of packet records with an unknown type Number of packets received from a non-configured CG Number of CG failures Number of unlikely but significant error conditions. If the send skipped counter is not zero, a significant error has occurred. Report this situation to the Cisco Technical Assistance Center (TAC). records dropped during drain echo req sent echo resp recv nodealive req sent nodealive resp recv Charging Gateways: defined Charging Gateways: max active Number of packets dropped during a drain from the CSG2 queue Number of echo requests Number of echo responses Number of node alive requests Number of node alive responses Number of charging gateways configured Number of active charging gateways
B-33
Appendix B GTP Application: CSG Billing Agent, Local Port: 16000
GTP Application: CSG Billing Agent, Local Port: 16000

GTP Application: CSG Billing Agent, Local Port: 16000 alloc failures = 0, no standby on CG failure = 0 packets sent = 0, received = 0, failed acks = 0 packets dropped = 0, rejected = 0, retransmits = 0, no ip = 0 packets outstanding: current = 0, highwater = 1 bad records = 0, unknown CG = 0, CG failures = 0 send skipped = 0, records dropped during drain = 0 echo req sent = 0, echo resp recv = 0 nodealive req sent = 88, nodealive resp recv = 0 Charging Gateways: defined = 1, max active = 1 172.18.12.214:4444 1 NAWAIT
The following table lists and describes all of the fields in the GTP Application: CSG Billing Agent output for the show ip csg stats command: Field alloc failures no standby on CG failure packets sent received failed acks packets dropped rejected retransmits no ip packets outstanding: current packets outstanding: highwater bad records unknown CG CG failures send skipped Description Low available system memory caused a problem A failure occurred and there was no available standby Charging Gateway (CG) Number of GTP' packets sent Number of GTP' packets received Number of spurious acknowledgements received (no corresponding sent request in the CSG2) Number of packets dropped by the GTP' application Number of packets received with the Cause Code Rejected Number of retransmitted packets by the CSG2 All non-Data Transfer Requests that are dropped because the corresponding CG has no IP address Current number of packets sent to the CG that were not acknowledged Highwater number of packets sent to the CG that were not acknowledged Number of packet records with an unknown type Number of packets received from a non-configured CG Number of failures Number of unlikely but significant error conditions. If the send skipped counter is not zero, a significant error has occurred. Report this situation to the Cisco Technical Assistance Center (TAC). records dropped during drain echo req sent echo resp recv nodealive req sent nodealive resp recv Number of packets dropped during a drain from the CSG2 queue Number of echo requests Number of echo responses Number of node alive requests Number of node alive responses
B-34
OL-22840-05
Appendix B
Field Descriptions for CSG2 Statistics GTP Application: CSG Quota Server, Local Port: 16001
Field Charging Gateways: defined Charging Gateways: max active
Description Number of charging gateways configured Number of active charging gateways
GTP Application: CSG Quota Server, Local Port: 16001

GTP Application: CSG Quota Server, Local Port: 16001 alloc failures = 0, no standby on CG failure = 81 packets sent = 4054366, received = 4054405, failed acks = 294 packets dropped = 2245665, rejected = 405, retransmits = 49, no ip = 0 packets outstanding: current = 9304, highwater = 10001 bad records = 0, unknown CG = 0, CG failures = 81 send skipped = 0, records dropped during drain = 0 echo req sent = 0, echo resp recv = 0 nodealive req sent = 0, nodealive resp recv = 0 Charging Gateways: defined = 1, max active = 1 172.18.12.214:4444 1 NAWAIT
The following table lists and describes all of the fields in the GTP Application: CSG Quota Server output for the show ip csg stats command: Field alloc failures no standby on CG failure packets sent received failed acks packets dropped rejected retransmits no ip packets outstanding: current packets outstanding: highwater bad records unknown CG CG failures send skipped Description Low available system memory caused a problem A failure occurred and there was no available standby Charging Gateway (CG) Number of GTP' packets sent Number of GTP' packets received Number of spurious acknowledgements received (no corresponding sent request in the CSG2) Number of packets dropped by the GTP' application Number of packets received with the Cause Code Rejected Number of retransmitted packets by the CSG2 All non-Data Transfer Requests that are dropped because the corresponding CG has no IP address Current number of packets sent to the CG that were not acknowledged Highwater number of packets sent to the CG that were not acknowledged Number of packet records with an unknown type Number of packets received from a non-configured CG Number of failures Number of unlikely but significant error conditions. If the send skipped counter is not zero, a significant error has occurred. Report this situation to the Cisco Technical Assistance Center (TAC). records dropped during drain Number of packets dropped during a drain from the CSG2 queue
B-35
Appendix B GTP Application: CSG PSD, Local Port: 0
Field echo req sent echo resp recv nodealive req sent nodealive resp recv Charging Gateways: defined Charging Gateways: max active
Description Number of echo requests Number of echo responses Number of node alive requests Number of node alive responses Number of charging gateways configured Number of active charging gateways
GTP Application: CSG PSD, Local Port: 0

GTP Application: CSG PSD, Local Port: 0 alloc failures = 0, no standby on CG failure = 0 packets sent = 0, received = 0, failed acks = 0 packets dropped = 0, rejected = 0, retransmits = 0, no ip = 0 packets outstanding: current = 0, highwater = 0 bad records = 0, unknown CG = 0, CG failures = 0 send skipped = 0, records dropped during drain = 0 echo req sent = 0, echo resp recv = 0 nodealive req sent = 0, nodealive resp recv = 0 Charging Gateways: defined = 0, max active = 1 172.18.12.214:4444 1 NAWAIT
The following table lists and describes all of the fields in the GTP Application: CSG PSD output for the show ip csg stats command: Field alloc failures no standby on CG failure packets sent received failed acks packets dropped rejected retransmits no ip packets outstanding: current packets outstanding: highwater bad records unknown CG CG failures Description Low available system memory caused a problem A failure occurred and there was no available standby Charging Gateway (CG) Number of GTP' packets sent Number of GTP' packets received Number of spurious acknowledgements received (no corresponding sent request in the CSG2) Number of packets dropped by the GTP' application Number of packets received with the Cause Code Rejected Number of retransmitted packets by the CSG2 All non-Data Transfer Requests that are dropped because the corresponding CG has no IP address Current number of packets sent to the CG that were not acknowledged Highwater number of packets sent to the CG that were not acknowledged Number of packet records with an unknown type Number of packets received from a non-configured CG Number of failures
B-36
OL-22840-05
Appendix B
Field Descriptions for CSG2 Statistics CSG RADIUS Statistics
Field send skipped
Description Number of unlikely but significant error conditions. If the send skipped counter is not zero, a significant error has occurred. Report this situation to the Cisco Technical Assistance Center (TAC).
records dropped during drain echo req sent echo resp recv nodealive req sent nodealive resp recv Charging Gateways: defined Charging Gateways: max active
Number of packets dropped during a drain from the CSG2 queue Number of echo requests Number of echo responses Number of node alive requests Number of node alive responses Number of charging gateways configured Number of active charging gateways
CSG RADIUS Statistics

CSG Radius Stats: starts = 2, stops = 0, other = 0 client msg rcv = 0, client msg sent = 0 incorrect authentication = 9 too frequent acct-on-off = 0 PoD/CoA packet too big = 0 alloc failures: billplan = 0, auth = 0, user info = 0 nas info = 0, pod port = 0, pod info = 0 proxy elem = 0, proxy port = 0, address = 0 no bill plan = 0, no svc = 0 no qs ip = 0, add bp err = 0 user alloc error = 0, add auth fail = 0 ipv6 addr type error = 0 dual stack key = 0 monitor errors: invalid message size = 0, invalid src/dest = 0 monitor for ip = 1.1.1.1:1813 client->server = 0, server->client = 0 parse errors = 0 proxy/end-point errors: invalid message size = 0, unable to find proxy/end-point blk = 0 proxy errors: unable to find client = 0, unable to send to client = 0 unable to send to server = 0, no elem found = 0 ipv6 addr cfg = 0, proxy source port = 1025 proxy CSG ip = 70.70.70.40, server ip = 88.88.88.30 client->server = 10, server->client = 1 parse errors = 9, pkt not proxied = 9 kut error = 0, drop packet = 0 packet queued = 0 endpoint CSG ip = 70.70.70.50 client->CSG = 0, CSG->client = 0 unable to send ACK = 0, parse errors = 0 no ack sent = 0, non-Acct-Req = 0 Gx attribute: 8 Gx attribute: 30
B-37
Appendix B CSG RADIUS Statistics
Gx Gx Gx Gx Gx Gx Gx Gx Gx Gx Gx Gx Gx Gx Gx
attribute: attribute: attribute: attribute: attribute: attribute: attribute: attribute: attribute: attribute: attribute: attribute: attribute: attribute: attribute:
31 44 97 vsa vsa vsa vsa vsa vsa vsa vsa vsa vsa vsa vsa
3gpp 3gpp 3gpp 3gpp 3gpp 3gpp 3gpp 3gpp 3gpp 3gpp 3gpp 3gpp
1 2 5 6 10 15 18 20 21 22 23 25
The following table lists and describes all of the fields in the CSG RADIUS Stats output for the show ip csg stats command: Field starts stops other client msg rcv client msg sent incorrect authentication too frequent acct-on-off Description Total RADIUS Accounting Starts Total RADIUS Accounting Stops Total RADIUS messages other than Accounting messages Total RADIUS messages received from client Total RADIUS messages sent to client Total RADIUS packets with incorrect key Total RADIUS Accounting On or RADIUS Accounting Off events dropped because they were received within 1 second on a given NAS. Total RADIUS PoD or CoA packets that are too large Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use
PoD/CoA packet too big alloc failures: billplan alloc failures: auth alloc failures: user info alloc failures: nas info alloc failures: pod port alloc failures: pod info alloc failures: proxy elem alloc failures: proxy port alloc failures: address alloc failures: no bill plan alloc failures: no svc alloc failures: no qs ip alloc failures: add bp err alloc failures: user alloc error alloc failures: add auth fail alloc failures: ipv6 addr type error alloc failures: dual stack key monitor errors: invalid message size
B-38
OL-22840-05
Appendix B
Field Descriptions for CSG2 Statistics CSG RADIUS Statistics
Field monitor errors: invalid src/dest monitor errors: monitor for ip monitor errors: client->server monitor errors: server->client monitor errors: parse errors proxy/end-point errors: invalid message size
Description Invalid source/destination in RADIUS packets Configured RADIUS monitor server address and port number at the CSG2 Total RADIUS packets seen from client to server Total RADIUS packets seen from server to client Total errors while parsing the RADIUS AVPs Internal Cisco Use
proxy/end-point errors: unable to find Internal Cisco Use proxy/end-point blk proxy errors: unable to find client proxy errors: unable to send to client proxy errors: no elem found proxy errors: ipv6 addr cfg proxy errors: proxy source port proxy CSG ip server ip client->server server->client parse errors pkt not proxied kut error drop packet packet queued endpoint CSG ip client->CSG CSG->client unable to send ACK parse errors no ack sent non-Acct-Req Gx attribute R attribute Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use Configured CSG proxy IP Configured actual RADIUS server IP Total RADIUS packets seen from client to server Total RADIUS packets seen from server to client Total RADIUS packets with errors while parsing the RADIUS AVPs Total RADIUS packets which were not proxied from the CSG2 to the actual server Total RADIUS packets with CSG2 User Table errors Total RADIUS packets dropped Total RADIUS packets queued Configured endpoint IP address at CSG Total RADIUS packets seen from client to the CSG2 endpoint Total RADIUS packets seen from the CSG2 to client Total number of times the CSG2 failed to acknowledge RADIUS packets from client Total errors while parsing the RADIUS AVPs Internal Cisco Use Total number of RADIUS non-Accounting requests from client RADIUS Gx attribute or subattribute RADIUS Report attribute or subattribute
proxy errors: unable to send to server Internal Cisco Use
B-39
Appendix B CSG OTHER Statistics
CSG OTHER Statistics

CSG OTHER Stats: total sessions = 40344, alloc fail = 0, drops = 0 aoc fail = 0, frags = 0, aborts = 6521, init fail = 2513 reports = 39937, standby no uid = 0, errors = 0 qos drops = 0
These statistics are collected for contents defined with the parse protocol other command. The following table lists and describes all of the fields in the CSG OTHER Stats output for the show ip csg stats command: Field total sessions alloc fail drops aoc fail frags aborts init fail reports standby no uid errors qos drops Description Total number of sessions allocated (cumulative) Number of times the CSG2 could not allocate memory for these sessions. This is usually a memory issue Number of packets dropped Number of times the CSG2 could not do proper AoC processing Number of fragmented packets Number of times sessions were ended prematurely for some reason Number of times the CSG2 could not initialize a session successfully Number of CDRs generated Number of times a session on the standby CSG2 failed to have an associated user Number of unexpected errors detected Number of packets dropped due to QOS denial
CSG HTTP Statistics

CSG HTTP Stats: sess = 18052044, txn = 22158257, set-aside resolved = 9367313 packets: sub new = 22418621, retx = 53, payload less = 164830871 net new = 238215919, retx = 94709, payload less = 22597153 billing reports: header = 6075882, stats = 79933600, stats term = 0 pre-policy header = 0, stats = 0, gx triggers = 0 alloc failures = 0 downgrade: parse failures = 8460, status code = 0 rsp > req = 0, 0.9 method = 3007 exceed max parse len = 0 fin terminated = 342, https = 20967, xf4 = 0 redirects = 450449, redirect failures = 1075 reset: error = 0, no user = 30295243, no quota = 10025299 no policy = 0, auth drop = 5577073 svc verify = 0, aoc = 6480351 unassigned bytes updates: no txn = 59360, downgrade = 26308, leak = 16082230 billing not resolved on standby = 0 qos drops = 0
B-40
OL-22840-05
Appendix B
Field Descriptions for CSG2 Statistics CSG HTTP Statistics
These statistics are collected for contents defined with the parse protocol http command. The following table lists and describes all of the fields in the CSG HTTP Stats output for the show ip csg stats command: Field sess gx txn set-aside resolved packets: sub: new packets: sub: retx packets: sub: payload less packets: net: new packets: net: retx packets: net: payload less billing reports: header billing reports: stats billing reports: stats term billing reports: pre-policy header billing reports: stats (pre-policy) billing reports: gx triggers alloc failures downgrade: parse failures downgrade: status code downgrade: rsp > req downgrade: 0.9 method downgrade: exceed max parse len fin terminated https Description Number of sessions created Number of sessions created for Gx user Number of transactions created Number of times transactions set aside to wait for responses from quota-server Number of packets with new TCP payload received on the subscriber side interface Number of packets with retransmitted TCP payload received on the subscriber side interface Number of TCP payload-less packets received on the subscriber side interface Number of packets with new TCP payload received on the network side interface Number of packets with retransmitted TCP payload received on the network side interface Number of TCP payload-less packets received on the network side interface Number of HTTP Header CDRs sent Number of HTTP Statistics CDRs sent Number of HTTP Statistics Termination CDRs sent Number of HTTP Header CDRs sent for transactions terminated before policy is assigned Number of HTTP Statistics CDRs sent for transactions terminated before policy is assigned Number of CCR sent to PCRF when volume or time threshold exceeded Number of times failed to allocate memory Number of times HTTP parsing failures with sessions downgraded to Layer 4 Number of times invalid HTTP Status Code received with sessions downgraded to Layer 4 Number of times more HTTP Responses than Requests received with sessions downgraded to Layer 4 Number of times HTTP method not GET for HTTP/0.9 with sessions downgraded to Layer 4 Number of times HTTP parsing exceeds content's parse length with sessions downgraded to Layer 4 Number of times HTTP stops parsing and counts all remaining bytes in the last transaction of the session Number of times HTTP method CONNECT received
B-41
Appendix B CSG RTSP Statistics
Field xf4 redirects redirect failures reset: error reset: no user reset: no quota reset: no policy reset: auth drop
Description Number of times HTTP header X-[Up]-Forwarded-For received Number of HTTP 302 Redirect sent Number of times failed to send HTTP 302 Redirect Number of times processing errors detected during session reset Number of times failed to find the user during session reset Number of times failed to resolve quota during session reset Number of times transactions not matching any policy and content block configured during session reset Number of times Service Verification Response or Content Authorization Response returns DROP Authorization Action during session reset Number of Service Verification Request sent Number of Content Authorization Request sent Number of times un-assigned bytes count updated due to no transactions Number of times un-assigned bytes count updated due to session downgraded to Layer 4 Number of times un-assigned bytes count updated due to memory leak Number of times failed to resolve user on Standby CSG2 Number of times packet dropped due to QoS
svc verify aoc unassigned bytes updates: no txn unassigned bytes updates: downgrade unassigned bytes updates: leak billing not resolved on standby qos drops
CSG RTSP Statistics

CSG RTSP Stats: Dyn Sess: add = 32386, fail = 32, delete = 32374, unused = 38 Gx Sess: control = 0, data = 0 Allocs: sessions = 8131, ctl_conns = 10405, streams = 16226, Timeouts: control = 10402, data = 31359, streams = 1 Misc: reuse = 0, reuse kills = 0, teardowns = 0 suspend = 96, patches = 0, interleaved = 0, sess = 0 http = 0, pauses = 0, no_policy = 0, mismatch = 0 ip frags = 0, retransmits = 29, resegments = 0 no user = 0, pre-policy = 0, aoc = 0 qos drops = 0 Errors: alloc = 0, dups = 0, ddrops = 0, cdrops = 32 patch = 0, parse = 0, aoc = 0, reject = 0 misc = 0 Reports: tcp = 10402, udp = 32336, stream = 16172, gx triggers = 0
B-42
OL-22840-05
Appendix B
Field Descriptions for CSG2 Statistics CSG RTSP Statistics
These statistics are collected for contents defined with the parse protocol rtsp command. The following table lists and describes all of the fields in the CSG RTSP Stats output for the show ip csg stats command: Field Dyn Sess: add Dyn Sess: fail Dyn Sess: delete Dyn Sess: unused Gx Sess: control Gx Sess: data Allocs: sessions Allocs: ctl conns Allocs: streams Timeouts: control Timeouts: data Timeouts: streams Misc: reuse Misc: reuse kills Misc: teardowns Misc: suspend Misc: patches Misc: interleaved Misc: sess Misc: http Misc: pauses Misc: no policy Misc: mismatch Misc: ip frags Misc: retransmits Misc: resegments Misc: no user Misc: pre-policy Misc: aoc Misc: qos drops Errors: alloc Errors: dup Errors: ddrops Errors: cdrops Errors: patch Errors: parse Description Cumulative number of dynamic data sessions Number of failed dynamic session creations Number of deleted dynamic sessions Number of dynamic sessions which had no data traffic Number of control sessions associated with a Gx user Number of data sessions associated with a Gx user Cumulative number of sessions Cumulative number of control sessions Cumulative number of streams blocks allocated Number of control sessions that timed out Number of data sessions that timed out Number of streams that timed out Number of data sessions that were reused within a single control session Number of terminated sessions due to reuse in a new control session Number of teardowns processed Number of UDP sessions suspended (packets dropped until time out) Number of TCP reassembled packets Number of data interleaved sessions Number of duplicate RTSP session IDs Number of interleaved HTTP sessions Number of RTSP pause requests Number of sessions not assigned a policy Number of unexpected data port mismatches for dynamic sessions Number of IP fragments Number of retransmitted packets Number of TCP resegmented packets Number of sessions not associated with a user Number of pre-policy packets (packets that cannot be associated with a policy) Number of AoC requests Number of packet drops due to AoC response Number of memory allocation failures Number of unexpected duplicate RTSP session IDs Number of unexpected packet drops on data sessions Number of unexpected packets drops on control sessions Number of failures to reassemble tcp packets Number of protocol parsing errors
B-43
Appendix B CSG SIP Statistics
Field Errors: aoc Errors: reject Errors: misc Reports: tcp Reports: udp Reports: stream Reports: gx triggers
Description Number of errors in AoC processing Number of rejected streams due to unexpected state condition Number of miscellaneous errors due to unexpected state conditions Number of TCP CDRs generated Number of UDP CDRs generated Number of stream CDRs generated Number of times a Gx trigger was hit
CSG SIP Statistics

CSG SIP Stats: Users: add = 0, delete = 0, idleout = 0, no kut = 0 Allocs: ctl = 0, calls = 0, events = 0, xacts = 0 Media: sess = 0, gx sess = 0, term = 0, fail = 0, mtimeout = 0, ctimeout 0, unused = 0, no match = 0 Misc: no user = 0, drops = 0, frags = 0, aoc = 0, refund = 0, ecdr = 0, ccdr = 0, suspend = 0, redirects = 0, neg rsp = 0, ctl sess = 0, ctl gx = 0 rexmits = 0, no policy = 0, sess reuse = 0, pre-policy = 0, contact ip = 0, pend drop = 0, regex = 0, stateless = 0, aborts = 0, qdrop = 0, txn idleout = 0, qos drops 0, gx triggers = 0 Wildcard: create = 0, match = 0 Reinvite: att = 0, complete = 0, term = 0, max = 0 Category: invites = 0, presence = 0, catchall = 0, misc = 0, register = 0, other = 0 Errors: alloc = 0, misc = 0, cdrops = 0, ddrops = 0, aoc = 0, sip msg = 0, non sip = 0, sip parse = 0, sip token = 0, sdp parse = 0, sdp token = 0, cseq = 0, redirect fail = 0, neg resp fail = 0 Performance: str alloc = 0, str alloc fail = 0, str dup = 0 str, dup fail = 0, hdr alloc = 0, hdr fail = 0, sip msg alloc = 0, sip msg fail = 0, sdp msg alloc = 0, sdp msg fail = 0, media alloc = 0, media fail = 0, str preserve = 0, hdr preserve = 0, sip msg preserve = 0 sdp msg preserve = 0, media preserve = 0, short copy = 0, long copy = 0 short cat = 0, long cat = 0,
These statistics are collected for contents defined with the parse protocol sip command. The following table lists and describes all of the fields in the CSG SIP Stats output for the show ip csg stats command: Field Users: add Users: delete Users: idleout Users: no kut Description Cumulative number of SIP users Cumulative number of SIP users that have been removed Number of users that have been cleaned up via the SIP idle timer Number of SIP users not associated with a User Table entry
B-44
OL-22840-05
Appendix B
Field Descriptions for CSG2 Statistics CSG SIP Statistics
Field Allocs: ctl Allocs: calls Allocs: events Allocs: xacts Media: sess Media: gx sess Media: term Media: fail Media: mtimeout Media: ctimeout Media: unused Media: no match Misc: no user Misc: drops Misc: frags Misc: aoc Misc: refund Misc: ecdr Misc: ccdr Misc: suspend Misc: redirects Misc: neg rsp Misc: ctl sess Misc: ctl gx Misc: rexmits Misc: no policy Misc: sess reuse Misc: pre-policy Misc: contact ip Misc: pend drop Misc: regex Misc: stateless Misc: aborts Misc: qdrop Misc: txn idleout
Description Number of allocated main control blocks Number of calls Number of events Number of transactions Number of media sessions Number of sessions associated with a Gx users Number of media sessions that have been terminated Number of failed media session creations due to port conflicts Number of media sessions that timed out Number of calls that timed out Number of media sessions for which no data was received Number of media header mismatches Number of failures due to no associated user Number of packet drops on control sessions Number of packets that were IP fragmented Number of AoC requests Number of refunded transactions Number of event CDRs generated Number of call CDRs generated Number of calls that were suspend due to authorization failure (that is, no quota) Number of redirects issued be CSG2 Number of negative responses generated by CSG2 Number of allocated control sessions Number of allocated control sessions associated with a Gx user Number of retransmitted request packets detected via SIP Number of transactions not assigned a policy Number of media sessions that were reused Number of pre-policy packets (packets that cannot be associated with a policy) that were passed Number of times the SDP contact IP did not match the subscriber IP Number of queued packets that were dropped due to quota pending Number of SIP/SDP headers that were truncated for regex matching Number of packets that did not create or match an existing transaction Number of sessions that were aborted Number of packets that were dropped due to lack of quota Number of transactions that idled out (did not complete normally)
B-45
Appendix B CSG SIP Statistics
Field Misc: qos drops Misc: gx triggers Wildcard: create Wildcard: match Reinvite: att Reinvite: complete Reinvite: term Reinvite: max Category: invites Category: presence Category: catchall Category: misc Category: register Category: other Errors: alloc Errors: misc Errors: cdrops Errors: ddrops Errors: aoc Errors: sip msg Errors: non sip Errors: sip parse Errors: sip token Errors: sdp parse Errors: sdp token Errors: cseq Errors: redirect fail Errors: neg resp fail Performance: str alloc Performance: str alloc fail Performance: str dup Performance: dup fail Performance: hdr alloc Performance: hdr fail Performance: sip msg alloc Performance: sip msg fail Performance: sdp msg alloc Performance: sdp msg fail
Description Number of packets that were dropped due to QoS Number of times a Gx trigger was hit Number of wildcard sessions that were created Number of wildcard sessions that were matched Number of reinvite attempts that were detected Number of attempts that completed successfully Number of reinvited calls that were terminated Number of reinvite packets dropped due to in progress state Number of Invite categories tracked Number of Presence categories tracked Number of Catchall categories tracked Number of Miscellaneous categories tracked Number of Register categories tracked Number of all other categories tracked not matching any of the above Number of memory allocation errors Number of various unexpected conditions Number of packets dropped on control sessions due to unexpected conditions Number of packets dropped on media sessions due to unexpected conditions Number of failures during AoC processing Number of SIP message errors during state processing Number of non-SIP message parsing errors Number of SIP message parsing errors Number of SIP token parsing errors Number of SDP parsing errors Number of SDP token parsing errors Number of unexpected CSEQs Number of failed redirect attempts Number of failed negative response attempts Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use
B-46
OL-22840-05
Appendix B
Field Descriptions for CSG2 Statistics CSG WAP Statistics
Field Performance: media alloc Performance: media fail Performance: str preserve Performance: hdr preserve Performance: sip msg preserve Performance: sdp msg preserve Performance: media preserve Performance: short copy Performance: long copy Performance: short cat Performance: long cat
Description Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use
CSG WAP Statistics

CSG WAP Stats: wap sessions = 978999, mms sessions = 0, gx sessions = 0 parses = 6026562, conn-oriented paks = 2629846, connectionless paks = 3396716 total trans = 2087358, incomplete trans = 2962 billing reports = 3755797, dup packets = 718748, redirects = 972 disconnects = 0, unknown packets = 98, concat packets = 0 parse err = 275, alloc fail = 0, refunds = 0 forced aborts = 19015, concat frags = 0, uid wait = 65571 seg att = 0, seg succ = 0, seg comp = 0, frags = 161 send fail = 0, send ok = 50279, no policy = 0 stateless = 732269, verifys = 0, cont fail = 0 user fail = 6458, err = 0, pre-policy = 0, gx triggers = 0 Aoc: reqs = 47923, drop = 14006, redir = 6778, fail = 0 Drops: err = 0, quota = 14290, block = 0, queue = 2521 qos = 0
These statistics are collected for contents defined with the parse protocol wap command, including both connectionless and connection-oriented sessions. The following table lists and describes all of the fields in the CSG WAP Stats output for the show ip csg stats command: Field wap sessions mms sessions gx sessions parses conn-oriented paks connectionless pak total trans incomplete trans billing reports dup packets Description Cumulative number of WAP sessions (not MMS) Cumulative number of MMS sessions Cumulative number of sessions associated with a Gx user Number of WAP packets that have been parsed Number of processed packets over connection-oriented sessions Number of processed packets over connectionless sessions Number of tracked transactions Number of transactions that timed out before completion Number of CDRs generated Number of retransmits detected
B-47
Appendix B CSG Mail Statistics
Field redirects disconnects unknown packets concat packets parse err alloc fail refunds forced aborts concat frags uid wait seg att seg succ seg comp frags send fail send ok no policy stateless verifys cont fail user fail err pre-policy gx triggers Aoc: reqs Aoc: drops Aoc: redirs Aoc: fail Drop: err Drop: quota Drop: block Drop: queue Drop: qos
Description Number of redirects issued by CSG2 Number of WAP disconnects sent by CSG2 Number of non-WAP packets detected Number of concatenated packets detected Number of protocol parsing errors detected Number of internal memory allocation failures Number of transactions that were refunded Number of transactions that were aborted by CSG2 Number of concatenated packets that were also IP fragmented Number of session queued waiting user ID resolution Number WA:P segment reassembly attempt Number of successful segment reassemblies Number of segment reassembly attempts that have completed Number of fragmented packets Number of sends that failed for CSG-generated packets Number of sends that were successful for CSG2-generated packets Number of transactions that were not assigned a policy Number of packets not able to be associated with a transaction Number of service verify requests Number of session failures due to lack of association with a content Number of failures due to lack of associating a user Number of unexpected error states hit Number of pre-policy packets (packets that cannot be associated with a policy) detected Number of times a Gx trigger was hit Number of AoC requests Number of packets dropped due to an AoC response Number of transaction redirected due to an AoC response Number of failed AoC attempts Number of packet drops due to a state error Number of packet drops due to last of quota Number of packet drops due to content block Number of packet drops due to maximum queue limits Number of packet drops due to QoS
CSG Mail Statistics

CSG Mail Stats: SMTP: messages = 457898, packets = 8701512, reports = 457898 fsm error = 0 POP3: messages = 0, packets = 0, reports = 0 fsm error = 0
B-48
OL-22840-05
Appendix B
Field Descriptions for CSG2 Statistics CSG FTP Statistics
IMAP: header fetches = 0, body fetches = 0 packets = 0, reports = 0, fsm error = 0 MAIL: ip frags = 0, aoc bypass = 0, alloc fails = 0 error = 0, no user = 6754, no policy = 0 txn drop = 0, aoc drop = 0, gx sessions = 0 gx triggers = 0
These statistics are collected for contents defined with the parse protocol imap, parse protocol pop3, parse protocol smtp command. The following table lists and describes all of the fields in the CSG Mail Stats output for the show ip csg stats command: Field SMTP: messages SMTP: packets SMTP: reports SMTP: fsm error POP3: messages POP3: packets POP3: reports POP3: fsm error IMAP: header fetches IMAP: body fetches IMAP: packets IMAP: reports IMAP: fsm error MAIL: ip frags MAIL: aoc bypass MAIL: alloc fails MAIL: error MAIL: no user MAIL: no policy MAIL: txn drop MAIL: aoc drop MAIL: gx sessions MAIL: gx triggers Description Number of SMTP e-mails Number of SMTP packets Number of SMTP CDRs Number of unexpected SMTP FSM errors Number of POP3 e-mails Number of POP3 packets Number of POP3 CDRs Number of unexpected POP3 FSM errors Number of IMAP header fetch requests Number of IMAP body fetch requests Number of IMAP packets Number of IMAP CDRs Number of unexpected IMAP FSM errors Number of IP fragmented packets Number of AoC processing errors Number of failed memory allocations Number of unexpected state conditions Number of sessions without an associated user Number of transactions without an assigned policy Number of packets dropped by the protocol handler Number of packets dropped via AoC response Number of sessions associated with a Gx user Number of times a Gx trigger was hit
CSG FTP Statistics

CSG FTP Stats: Ctl session: add = 1, gx = 0, init fail = 0 Data session: add/fail = 1/0, gx = 0, act = 1, passive = 0 extra = 0 Wildcards: add/fail = 0, extra = 0 Alloc fails: details = 0, data = 0 Misc fails: lookup = 0, user = 0, no ctl = 0, data xfer = 0 gx rule mismatch = 0, txn handling error = o
B-49
Appendix B CSG FTP Statistics
Misc: ip frags ctl = 0, ip frags data = 0, retrans = 0, resegs = 0, ctl drops = 0 data drops = 0, L4 cdrs = 2, data cdrs = 1 qos drops = 0, gx triggers = 0
These statistics are collected for contents defined with the parse protocol ftp command. The following table lists and describes all of the fields in the CSG FTP Stats output for the show ip csg stats command: Field Ctl session: add Ctl session: gx Ctl session: init fail Data session: add/fail Data session: g Data session: act Data session: passive Data session: extra WildCards: add/fail WildCards: extra Alloc fails: details Alloc fails: data Misc fails: lookup Misc fails: user Misc fails: no ctl Misc fails: extra data xfer Description Total number of control sessions created to date Total number of control sessions associated with a Gx charging rule Count of failures when initializing control sessions Total number of data sessions created to date/Total number of data session create failures Total number of data sessions associated with a Gx charging rule Total number of active FTP data sessions Total number of passive FTP data sessions Number of attempts to create a data session when a previous session already exists for that control session Total number of wildcard sessions created to date/Total number of wildcard session create failures Number of wildcard sessions created when a previous wildcard session already existed Number of memory allocation failures - Control Session DataStructure Number of memory allocation failures - Data Session DataStructure Number of failed attempts to obtain information pertaining to control/data/wildcard session Number of failed attempts to obtain subscriber information (such as a User Table element) Number of times creation of a data session failed as there was no corresponding control session Number of times a data transfer command was received on the control session when a previous data transfer command was not completed/aborted Number of times creation of a data session failed as it was not associated with the same Gx rule as its control session. Number of times transactions were not properly closed. This could lead to problems cleaning up a service instance or a User Table element. Total number of IPv4 fragments encountered in all control sessions to date Total number of IPv4 fragments encountered in all data sessions to date
Misc fails: gx rule mismatch Misc fails: txn handling err
Misc: ip frags ctl Misc: ip frags data
B-50
OL-22840-05
Appendix B
Field Descriptions for CSG2 Statistics CSG NBAR Statistics
Field Misc: retrans Misc: resegs Misc: ctl drops Misc: data drops Misc: L4 cdrs Misc: data cdrs Misc: qos drops Misc: gx triggers
Description Number of TCP complete retransmissions in all control sessions to date Number of TCP resegmentations (part retransmit data and part new data) in all control sessions to date Total number of control session packets dropped to date Total number of data session packets dropped to date Total number of TCP CDRs (for FTP control and data sessions) generated to date Total number of FTP CDRs (one for each data transfer) generated to date Total number of FTP packets dropped by the QoS function Total number of times a Gx charging rule volume/time usage trigger was pulled for FTP packets
CSG NBAR Statistics

CSG NBAR Stats: total sessions = 0, gx = 0, alloc fail = 0 aoc fail = 0, frags = 0, aborts = 0, init fail = 0 reports = 0, standby no uid = 0, errors = 0 qos drops = 0, frag_drops = 0, gx triggers = 0 Total: in-paks = 0, out-paks = 0 in-bytes = 0, out-bytes = 0 in-rate = 0, out-rate = 0 max in-rate = 0, max out-rate = 0
The following table lists and describes all of the fields in the CSG NBAR Stats output for the show ip csg stats command: Field total sessions gx alloc fail aoc fail frags aborts init fail reports standby no uid errors qos drops frag_drops Description Total number of Layer 4 sessions that hit NBAR content Total number of sessions associated with a Gx charging rule Count of failures to allocate NBAR structures Number of AoC failures Total number of IPv4 fragments hitting NBAR content Number of times an NBAR-parsed transaction (Layer 4 session) was aborted midway Number of failures when initializing an NBAR-parsed session Total number of NBAR CDRs generated Total number of failures to replicate an NBAR-parsed session on the standby CSG2 because the user ID information was not resolved at the time Number of general errors Total number of packets dropped by the QoS function Total number of IPv4 fragment families dropped (for example, due to fragments being reassembled incorrectly)
B-51
Appendix B CSG QoS Statistics
Field gx triggers Total: in-paks Total: out-paks Total: in-bytes Total: out-bytes Total: in-rate Total: out-rate Total: max in-rate Total: max out-rate
Description Number of times a Gx volume/time usage trigger was pulled for NBAR parsed sessions Number of packets coming into the CSG2 (both subscriber and network side) for all NBAR sessions Number of packets sent out from the CSG2 (both subscriber and network) for all NBAR sessions IPv4 byte count of traffic coming into the CSG2 (both subscriber and network) for all NBAR sessions IPv4 byte count of traffic sent out from the CSG2 (both subscriber and network) for all NBAR sessions Rate of incoming traffic for all NBAR sessions Rate of outgoing traffic for all NBAR sessions Maximum incoming rate for all NBAR sessions Maximum outgoing rate for all NBAR sessions
CSG QoS Statistics

CSG QoS Stats: Number of Profiles = 2 (2 in QoS database) alloc fail = 0, config error = 0 User QoS clone fail = 0, User-service QoS clone fail = 0
The following table lists and describes all of the fields in the CSG QoS Stats output for the show ip csg stats command: Field Number of Profiles Description Total number of QoS profiles consumed on this CPU. A QoS profile is consumed: A QoS profile instance is consumed:

Every time you configure a QoS profile, using the ip csg qos profile command. Every time a new CSG2 User Table entry or service is instantiated that uses a billing plan or service that is associated with a QoS profile. If the QoS profile applies in both the network-to-subscriber direction and the subscriber-to-network direction, that is two separate QoS profiles. Every time a new CSG2 User Table entry or service is instantiated that receives per-user QoS or per-user QoS from the quota server via the conditional QoS Rate Limit User TLV.
(in QoS database) alloc fail config error
Number of QoS profiles present in an internal database; should equal Number of Profiles Number of QoS profile allocation failures Number of QoS configuration errors
B-52
OL-22840-05
Appendix B
Field Descriptions for CSG2 Statistics CSG Quota Server Statistics
Field User QoS clone fail User-service QoS clone fail
Description Number of times the CSG2 failed to clone QoS (attached to the billing plan) for a particular user Number of times the CSG2 failed to clone QoS (attached to the service) for a particular service instance
CSG Quota Server Statistics

CSG QS Stats: alloc fail: req = 0, redir = 0, defer ack = 0, req token = 0 too frequent requests = 12129585, called on standby = 0 no defer ack data = 0, no cg affinity = 0 passthru = 7404738, response no kut svc = 969, no quota = 10034067 svc auth fail = 6, aoc-verify fail = 0 badly formatted message: aoc verify response = 0, cont auth redir = 458607 usr auth rsp = 0, svc auth rsp = 0 svc verify resp = 0, quota return accept = 0 svc stop req = 0, quota return req = 0 user disconnect req = 0, quota push req = 0 invalid svc ctrl req = 1 invalid req = 0, bad tlv = 0 rplan push = 0, no plan = 0, missing tlv = 0 QS requests received from QS: request = 0, fail to send to tp = 0 QS responses received from QS: response = 4053620, fail to send to tp = 0 no request = 0, missing request data = 0 invalid FUI redir info = 0 IPC: CP alloc fail = 0, sent = 11252881, fail = 0, rcv = 13790207 TP alloc fail = 0, sent = 13725076, fail = 0, rcv = 11186359 response no request = 0 user profile req = 862466, rsp = 181435 svc auth req = 2533171, re-auth req = 1151422, rsp = 1499012 quota return = 118566, quota return accept = 0 auth content req = 6528274, rsp = 1832535 svc verify req = 0, rsp = 0 svc stop = 2531177, fail to enqueue qm request process = 0 svc stop req = 0, user disconnect req = 0 quota return req = 0, quota push req = 0, rsp = 0 negative quota grant = 0, failed request = 1
The following table lists and describes all of the fields in the CSG QS Stats output for the show ip csg stats command: Field Alloc fail: req Alloc fail: redir Alloc fail: defer ack Description Number of memory allocation failures for quota server message requests Number of memory allocation failures for quota server redirects Number of memory allocation failures for quota server ACKs
B-53
Appendix B CSG Quota Server Statistics
Field Alloc fail: req token too frequent requests called on standby no defer ack data no cg affinity passthru response no kut svc no quota svc auth fail aoc-verify fail badly formatted message: aoc verify response
Description Number of memory allocation failures related to quota server tokens Number of quota fetch denials due to limiting requests via time intervals Number of unexpected quota server requests on the standby CSG2 Number of no data ACKs for quota push responses Number of no CG affinity Number of no active quota server found Number of service authorization responses with no associated User Table service Number of User Table service request drops due to no quota Number of service authorization failures during transaction open processing Number of failures incurred during AoC or service verify request processing Number of aoc verify response messages that contain parsing errors
badly formatted message: cont auth redir Number of cont auth redir messages that contain parsing errors badly formatted message: usr auth rsp badly formatted message: svc auth rsp badly formatted message: svc verify resp badly formatted message: quota return accept badly formatted message: svc stop req badly formatted message: quota return req badly formatted message: user disconnect req Number of usr auth rsp messages that contain parsing errors Number of svc auth rsp messages that contain parsing errors Number of svc verify rsp messages that contain parsing errors Number of quota return accept messages that contain parsing errors Number of svc stop req messages that contain parsing errors Number of quota return req messages that contain parsing errors Number of user disconnect req messages that contain parsing errors
badly formatted message: quota push req Number of quota push req messages that contain parsing errors badly formatted message: invalid svc ctrl req badly formatted message: invalid req badly formatted message: bad tlvs badly formatted message: rplan push badly formatted message: no plan Number of invalid svc ctrl req messages that contain parsing errors Number of invalid req messages that contain parsing errors Number of bad tlv messages that contain parsing errors Number of rplan push messages that contain parsing errors Number of no plan messages that contain parsing errors
B-54
OL-22840-05
Appendix B
Field Descriptions for CSG2 Statistics CSG Quota Server Statistics
Field badly formatted message: missing tlv QS requests received from QS: request QS requests received from QS: to send to tp
Description Number of missing tlv messages that contain parsing errors Number of message requests received from the quota server Number of failed requests sent to the TPs
QS responses received from QS: response Number of message responses received from the quota server QS responses received from QS: fail to send to tp QS responses received from QS: no request QS responses received from QS: missing request data QS responses received from QS: invalid fui redir info IPC CP: alloc fail IPC CP: sent IPC CP: fail IPC CP: rcv IPC TP: alloc fail IPC TP: sent IPC TP: fail IPC TP: rcv IPC TP: response no request QS messages counters: user profile: req QS messages counters: user profile: rsp QS messages counters: svc auth: req QS messages counters: svc auth: re-auth req QS messages counters: svc auth: rsp QS messages counters: svc auth: quota return QS messages counters: quota return accept QS messages counters: auth content: req QS messages counters: auth content: rsp QS messages counters: svc verify: req Number of failed responses sent to the TPs Number of IPC messages with no associated request Number of IPC messages with missing request information Number of IPC messages with invalid FUI redirection information Number of IPC memory allocation failures Number of IPC messages sent from the CP Number of IPC message send failures from the CP Number of IPC messages received on the CP Number of IPC memory allocation failures Number of IPC messages sent from the TPs Number of IPC message send failures from the TPs Number of IPC messages received on the TPs Number of IPC messages received with no associated request Number of quota server user profile request messages Number of quota server user profile response messages Number of quota server service authorization request messages Number of quota server service authorization reauthorization request messages Number of quota server service authorization response messages Number of quota server service authorization quota return messages Number of quota server service authorization quota return accept messages Number of quota server content authorization request messages Number of quota server content authorization response messages Number of quota server service verify request messages
B-55
Appendix B CSG Gx Handler Statistics
Field QS messages counters: svc verify: rsp QS messages counters: svc stop QS messages counters: fail to enqueue qm request process QS messages counters: svc stop req QS messages counters: user disconnect req QS messages counters: quota return req QS messages counters: quota push: req QS messages counters: quota push: rsp QS messages counters: negative quota grant QS messages counters: failed request
Description Number of quota server service verify response messages Number of quota server service stop messages Number of quota server fail to enqueue quota manager request process messages Number of quota server service stop request messages Number of quota server user disconnect request messages Number of quota server quota return request messages Number of quota server quota push request messages Number of quota server quota push response messages Number of quota server negative quota grant messages Number of quota server failed request messages
CSG Gx Handler Statistics

CSG Gx Handler Stats: alloc fail errors enqueue ccr errors enqueue raa errors enqueue sync errors enqueue ccr errors aaa attr set failures aaa list alloc failures invalid msg errors session id NULL errors destination host NULL errors destination realm NULL errors method list NULL errors preload info NULL errors ccr send failures missing mandatory avp errors duplicate avps mem pool create failures watch queue errors invalid queue errors process errors filter rule parse errors wrong length errors null name errors msg failures alloc sleep = = = = = = = = = = = = = = = = = = = = = = = = = 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
The following table lists and describes all of the fields in the CSG Gx Handler Stats output for the show ip csg stats command: Field alloc fail errors enqueue aaa errors Description Number of memory allocation errors in the Gx handler process Number of failures to enqueue AAA request to the Gx handler process
B-56
OL-22840-05
Appendix B
Field Descriptions for CSG2 Statistics CSG Policy Preload Statistics
Field enqueue ccr errors enqueue raa errors enqueue sync errors aaa attr set failures aaa list alloc failures invalid msg errors session id NULL errors destination host NULL errors destination realm NULL errors method list NULL errors preload info NULL errors ccr send failures missing mandatory avp errors duplicate avps mem pool create failures watch queue errors invalid queue errors process errors filter rule parse errors wrong length errors null name errors msg failures alloc sleep
Description Number of failures to enqueue CCR request to the Gx handler process Number of failures to enqueue RAA request to the Gx handler process Number of failures to enqueue mobile-PCC sync request to the Gx handler process Number of failures to add AAA attribute to Gx requests Number of failures to allocate AAA lists Number of unrecognized Gx messages Number of Gx requests received with session ID being null Number of Gx sync requests with destination host being null Number of Gx sync requests with destination realm being null Number of Gx sync requests with method list being null Number of Preload sync requests with Preload Information being null Number of failures to send CCR in the Gx handler process Number of missing mandatory AVP errors in requests/and responses from the PCRF Number of duplicate AVP errors in requests and responses from the PCRF Number of memory pool create failures in Gx handler Number of Gx handler process watch queue errors Number of errors enqueued to an invalid Gx queue Number of Gx handler process create failure errors Number of charging rule flow filter parsing errors Number of wrong length Gx AVP errors Number of AVPs with name string being null Number of Gx message failures Number of times sleep inducted for memory pool expansion
CSG Policy Preload Statistics

CSG Policy Preload Stats: content installed content removed content rolledback content install failed content remove failed content rollback failed service installed service removed service rolledback service install failed service remove failed service rollback failed policy map installed = = = = = = = = = = = = = 2 2 0 1 0 0 2 2 0 1 0 0 5
B-57
Appendix B CSG Policy Preload Statistics
policy map removed policy map rolledback policy map install failed policy map remove failed policy map rollback failed billing policy installed billing policy removed billing policy rolledback billing policy install failed billing policy remove failed billing policy rollback failed billing plan installed billing plan removed billing plan rolledback billing plan install failed billing plan remove failed billing plan rollback failed cp ipc req sent cp ipc res recd tp ipc req recd tp ipc res sent cp ha req sent cp ha res recd alloc fail enqueue errors misc errors mpcc sess sync fail preload req retries
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
2 0 0 0 0 2 2 0 1 0 0 2 2 0 1 0 0 115 115 115 115 0 0 0 0 0 0 0
The following table lists and describes all of the fields in the CSG Policy Preload Stats output for the show ip csg stats command: Field content installed content removed content rolledback content install failed content remove failed content rollback failed service installed service removed service rolledback service install failed service remove failed service rollback failed policy map installed policy map removed policy map rolledback policy map install failed policy map remove failed policy map rollback failed billing policy installed Description Number of successful content installations Number of successful content removals Number of successful content rollbacks Number of content installation failures Number of content removal failures Number of content rollback failures Number of successful service installations Number of successful service removals Number of successful service rollbacks Number of service installation failures Number of service removal failures Number of service rollback failures Number of successful policy map installations Number of successful policy map removals Number of successful policy map rollbacks Number of policy map installation failures Number of policy map removal failures Number of policy map rollback failures Number of successful billing policy installations
B-58
OL-22840-05
Appendix B
Field Descriptions for CSG2 Statistics Timer Statistics
Field billing policy removed billing policy rolledback billing policy install failed billing policy remove failed billing policy rollback failed billing plan installed billing plan removed billing plan rolledback billing plan install failed billing plan remove failed billing plan rollback failed cp ipc req sent cp ipc res recd tp ipc req recd tp ipc res sent cp ha req sent cp ha res recd alloc fail enqueue errors misc errors mpcc sess sync fail preload req retries
Description Number of successful billing policy removals Number of successful billing policy rollbacks Number of billing policy installation failures Number of billing policy removal failures Number of billing policy rollback failures Number of successful billing plan installations Number of successful billing plan removals Number of successful billing plan rollbacks Number of billing plan installation failures Number of billing plan removal failures Number of billing plan rollback failures Number of IPC messages sent from the CP Number of IPC messages received by the CP Number of IPC messages received on TPs Number of IPC messages sent from TPs Number of HA messages sent Number of HA messages received Number of memory allocation failures Number of errors related to internal queuing Number of miscellaneous unexpected conditions Number of failed attempts to sync backup CSG with preload config Number of retry attempts to initiate preloading from PCRF
Timer Statistics
Timer Stats: tmr_intialized = 1 tmr_ticks = 7160 tmr_starts = 4067359 tmr_stops = 3487837 tmr_timeouts = 574960 tmr_active = 4562 tmr_longest_chain = 505
The following table lists and describes all of the fields in the Timer Stats output for the show ip csg stats command: Field tmr_intialized tmr_ticks tmr_starts tmr_stops tmr_timeouts Description Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use Internal Cisco Use
B-59
Appendix B DNS Stats
Field tmr_active tmr_longest_chain
Description Internal Cisco Use Internal Cisco Use
DNS Stats
Sessions: sess = 0, gx sess = 0, tcp = 0, xact = 0 ipv6 sess = o Misc: gx triggers = 0, drops = 0, frags = 0, aborts = 0, cdrs = 0, tcp cdr = 0, stateless = 0, incomplete = 0, rev lookup = 0, multi query = 0 good patch = 0, pre-policy = 0, qos drops = 0 neg replies = 0, unknown queries = 0, referrals = 0 pipeline = 0, max parse = 0, max paks = 0, reseg = 0 retrans = 0, no quota = 0, refund = 0, quota block = 0 content block = 0, no policy = 0 Mappings: add = 0, fail = 0, update = 0, none = 0 Errors: alloc = 0, init = 0, parse = 0, misc = 0, patch = 0
The following table lists and describes all of the fields in the DNS Stats output for the show ip csg stats command: Field Sessions: sess Sessions: gx sess Sessions: tcp Sessions: xact Sessions: ipv6 sess Misc: gx triggers Misc: drops Misc: frags Misc: aborts Misc: cdrs Misc: tcp cdr Misc: stateless Misc: incomplete Misc: rev lookup Misc: multi query Misc: good patch Misc: pre-policy Misc: qos drops Misc: neg replies Misc: unknown queries Misc: referrals Description Number of accumulated Layer 4 DNS sessions Number of accumulated Gx sessions Number of accumulated TCP sessions Number of accumulated Gx sessions Number of accumulated IPv6 sessions Number of Gx triggers hit Number of packets dropped Number of IP fragmented packets Number of sessions that were aborted prematurely Total number of CDRs generated Total number of TCP CDRs generated Number of packets not matching a transaction Number of requests that did not receive a complete response Total number of CDRs generated Number of multi query requests Number of TCP packet reassembles Number of pre-policy packets (packets that cannot be associated with a policy) Number of packets dropped due to QoS Number of responses with non-zero return codes Number of unsupported queries received Number of referral responses
B-60
OL-22840-05
Appendix B
Field Descriptions for CSG2 Statistics DNS IP Map Table Stats
Field Misc: pipeline Misc: max parse Misc: max paks Misc: reseg Misc: retrans Misc: no quota Misc: refund Misc: quota block Misc: content block Misc: no policy Mappings Mappings: add Mappings: fail Mappings: update Mappings: none Errors: alloc Errors: init Errors: parse Errors: misc Errors: patch
Description Number of pipelined requests Number of times the maximum parse limit was reached Number of times the maximum packet limit was reached Number of TCP resegmented packets Number of retransmitted packets Number of packets dropped due to no quota Number of transactions that were refunded Number of packets that were dropped after quota expired Number of packets dropped due to content block option Number of transaction not assigned a policy Stats for updating the DNS IP Map Table(s) on the TP(s). Number of entries added to the DNS IP Map Table Number of memory allocation failures while adding entries to the DNS IP Map Table Number of entries updated in the DNS IP Map Table Number of domains in the DNS IP Map Table that did not match a configured match domain command Number of memory allocation errors Number of session initiation failures Number of parsing errors Number of miscellaneous errors detected Number of problems encountered when reassembling TCP packets
DNS IP Map Table Stats

Note
The CSG2 does not display DNS IP Map Table Stats unless at least one content configured with parse protocol dns is inservice.
DNS IP Map Table Stats: Hash Table size = 4096 (configured) IP Map Table: Total: Entries = 0, Collisions = 0 IPv6 Entries = 0 TP = 0: Entries = 0, Collisions = 0 IPv6 Entries = 0 TP = 1: Entries = 0, Collisions = 0 IPv6 Entries = 0 TP = 2: Entries = 0, Collisions = 0 IPv6 Entries = 0 TP = 3: Entries = 0, Collisions = 0 IPv6 Entries = 0 TP = 4: Entries = 0, Collisions = 0 IPv6 Entries = 0 Domain-Group: Domain Group = DNS_POLICY, Map Entries = 0, Flow hits = 0 Domain Group = WHITELIST, Map Entries = 0, Flow hits = 0
B-61
Appendix B DNS IP Map Table Stats
The following table lists and describes all of the fields in the DNS IP Map Table Stats output for the show ip csg stats command: Field Hash Table size IP Map Table: Total: Entries IP Map Table: Total: Collisions IP Map Table: Total: IPv6 Entries IP Map Table: TP = 0: Entries IP Map Table: TP = 0: Collisions IP Map Table: TP = 0: IPv6 Entries IP Map Table: TP = 1: Entries IP Map Table: TP = 1: Collisions IP Map Table: TP = 1: IPv6 Entries IP Map Table: TP = 2: Entries IP Map Table: TP = 2: Collisions IP Map Table: TP = 2: IPv6 Entries IP Map Table: TP = 3: Entries IP Map Table: TP = 3: Collisions IP Map Table: TP = 3: IPv6 Entries IP Map Table: TP = 4: Entries IP Map Table: TP = 4: Collisions IP Map Table: TP = 4: IPv6 Entries Domain Group: Domain Group Domain Group: Map Entries Domain Group: Flow hits Description Number of entries in the Hash Table. Total number of entries for all TPs in the IP Map Table. Total number of hash collisions for all TPs. Total number of IPv6 entries for all TPs. Number of entries for TP0 in the IP Map Table. Number of hash collisions for TP0. Number of IPv6 entries for TP0. Number of entries for TP1 in the IP Map Table. Number of hash collisions for TP1. Number of IPv6 entries for TP1. Number of entries for TP2 in the IP Map Table. Number of hash collisions for TP2. Number of IPv6 entries for TP2. Number of entries for TP3 in the IP Map Table. Number of hash collisions for TP3. Number of IPv6 entries for TP3. Number of entries for TP4 in the IP Map Table. Number of hash collisions for TP4. Number of IPv6 entries for TP4. Name of the domain group. Total number of IP Map Table entries for all TPs for the domain group. Number of times a new flow was mapped to the domain group, for all TPs.
B-62
OL-22840-05
A P P E N D I X
CSG2 Command HistoryCSG1 R7 to CSG2 R1

The following sections document the changes to commands between the CSG1 Release 7 and the CSG2 Release 1:

Unchanged Commands, page C-1 New Commands, page C-2 Deleted Commands, page C-3 Changed Commands, page C-5 Changes to Module CSG Configuration Mode, page C-10 Changes to Module CSG VLAN Configuration Mode, page C-10 Changes to Accounting Configuration Mode, page C-11 Changes to Billing Configuration Mode, page C-12 Changes to Block Configuration Mode, page C-12 Changes to Content Configuration Mode, page C-12 Changes to Map Configuration Mode, page C-13 Changes to Policy Configuration Mode, page C-13 Changes to Refund Configuration Mode, page C-14 Changes to Ruleset Configuration Mode, page C-14 Changes to Service Configuration Mode, page C-14 Changes to SNMP Timer Configuration Mode, page C-15 Changes to Transport-Type Configuration Mode, page C-15 Changes to User Group Configuration Mode, page C-16 Changes to Weight Configuration Mode, page C-17
Unchanged Commands
The following commands did not change between the CSG1 and the CSG2:

activation class (CSG2 service) flags
C-1
Appendix C New Commands
idle (CSG2 service) inservice (CSG2 content) ip (CSG2 content) ip csg billing ip csg content ip csg policy ip csg refund ip csg service meter increment meter initial meter minimum mode passthrough pending (CSG2 content) policy (CSG2 content) retcode service show ip csg
New Commands
The following commands are new for the CSG2:

aoc append url clear ip csg ip csg bma keepalive ip csg bma messages ip csg bma retransmit ip csg bma retries ip csg bma window ip csg case-sensitive ip csg entries fragment ip csg entries session user max ip csg entries user idle ip csg entries user max ip csg ipc crashdump ip csg ipc keepalive ip csg ipc retransmit ip csg ipc retries
C-2
OL-22840-05
Appendix C
CSG2 Command HistoryCSG1 R7 to CSG2 R1 Deleted Commands
ip csg mode single-tp ip csg psd drain delay ip csg psd drain packet ip csg psd keepalive ip csg psd margin ip csg psd retransmit ip csg psd retries ip csg psd window ip csg quota-server keepalive ip csg quota-server messages ip csg quota-server reassign ip csg quota-server retransmit ip csg quota-server retries ip csg quota-server window ip csg radius correlation ip csg replicate ip csg report smtp rfc2822 ip csg report wap actual-pdu ip csg subscriber match method (CSG2 map) meter exclude mms wap mode tcp parse length (CSG2 content) parse protocol (CSG2 content) reauthorization threshold reauthorization timeout records delay sami rate all subscriber-ip http-header x-forwarded-for (CSG2 content) vrf (CSG2 content)
Deleted Commands
The following CSG1 commands have been deleted from the CSG2:

accounting (module CSG2) alias (module CSG2 VLAN) assign clear module csg
C-3
Appendix C Deleted Commands
clear module csm client (CSG2 content) client-ip (CSG2 policy) content (CSG2 ruleset) copy entries failover ft group (module CSG2) gateway (module CSG2 VLAN) heartbeat-time hostname ip address (module CSG2 VLAN) ip csg accounting ip csg user-group ip csg weight keepalive module csg ping priority radius acct-port radius key radius monitor radius parse strict radius server records batch records http-statistics route (module CSG2 VLAN) ruleset show module csg arp show module csg billing show module csg clock show module csg conns show module csg ft show module csg status show module csg tech-support show module csg variable show module csg vlan table (module CSG2 VLAN)
C-4
OL-22840-05
Appendix C
CSG2 Command HistoryCSG1 R7 to CSG2 R1 Changed Commands
upgrade user-group variable (module csg) vlan (module csg) zero-quota abort type
Changed Commands
Table C-1 summarizes the changes made to commands between the CSG1 and the CSG2:
Table C-1 Commands That Changed Between CSG1 and CSG2
Command accounting (CSG2 policy) agent (CSG2 accounting) agent activate agent local-port aoc confirmation
Change from CSG1 All keywords and arguments except customer-string string were removed. The name of this command changed to ip csg bma. The vrf vrf-name keyword and argument were added. The name of this command changed to ip csg bma activate. The range of the number argument changed from 1 to 10, to 1 to 32. The name of this command changed to ip csg bma local-port. The name of this command changed to aoc confirm. The configuration mode for this command changed from CSG user group configuration to CSG2 service configuration. The list of supported special characters changed.
authorize content basis client-group (CSG2 content)
The name of this command changed to aoc enable. The exclude mms keyword was removed. The configuration mode for this command changed from CSG policy configuration to CSG2 content configuration. The range for the std-access-list-number argument increased from 1300 to 1999. The weight-name argument was replaced with the weight-value argument. The name of this command changed to ip csg database. The configuration mode for this command changed from CSG user group to global configuration. The vrf vrf-name and local-port keywords and arguments were added.
content (CSG2 service) database
debug ip csg
The acl number, configuration sync, detail, dump, error, frag, global, ha, http, interm, ipc, mail, other, packet, priority, qs, replicate, service, session event, session state, stats, and vrf vrf-name, keywords and arguments were added. The any, bma, ipc, psd, and quota-server keywords were added for the gtp keyword. The agent, api, cpu, module number, quota, prepaid, record storage slot, and timer keywords and arguments were removed.
entries idle (CSG2 billing)
The name of this command changed to entries user idle.
C-5
Appendix C Changed Commands
Table C-1
Commands That Changed Between CSG1 and CSG2 (continued)
Command header-map idle (CSG2 content) ip csg block
Change from CSG1 This command, along with the url-map command, was incorporated into map (CSG2 policy). The default setting for the duration argument changed from 3600 seconds to 300 seconds. The name of this command changed to block. The configuration mode for this command changed from global to CSG content configuration.
ip csg map ip csg snmp timer ip csg transport-type keepalive
The header and url keywords were removed. The psd keyword was added. The agent keyword was replaced with the bma keyword. The name of the command changed to ip csg transport-type assign. The ipv4-address and value arguments were added. The name of this command changed to ip csg bma keepalive. The configuration mode for this command changed from CSG accounting to global configuration.
match (header map)
The name of this command changed to match header (CSG2 map). The configuration mode for this command changed from CSG header map configuration to CSG2 map configuration. The protocol protocol and value keywords and arguments were removed. The pattern argument was replaced with the value argument.
match (url map)
The name of this command changed to match url (CSG2 map). The configuration mode for this command changed from CSG URL map configuration to CSG2 map configuration. The protocol protocol and method method keywords and arguments were removed.
meter exclude meter imap
The meter exclude command split into three new commandsmeter exclude mms wap, meter exclude pause rtsp, and meter exclude svc-idle. The name of this command changed to meter include imap. The body-header, body-only, and body-other keywords changed to body header, body only, and body other, respectively.
next-hop (CSG2 content)
The configuration mode for this command changed from CSG policy configuration to CSG2 content configuration. The reverse keyword was added. This command, along with the owner name command, was incorporated into owner (CSG2 service). This command, along with the owner id command, was incorporated into owner (CSG2 service) The name of this command changed to ip csg quota-server activate. The configuration mode for this command changed from CSG user group configuration to global configuration. The range for the number argument changed from 1 to 10, to 1 to 32.
owner id owner name quota activate
C-6
OL-22840-05
Appendix C
Table C-1
Command quota local-port
Change from CSG1

The name of this command changed to ip csg quota-server local-port. The configuration mode for this command changed from CSG user group
configuration to global configuration.

The range for the port-number argument changed from 1 to 65535, to
1024 to 65535. quota server The name of this command changed to ip csg quota-server. The configuration mode for this command changed from CSG user group configuration to global configuration. The vrf vrf-name keyword and argument were added. The reassign keyword was removed. radius ack error The radius ack error command split into two new commandsip csg radius ack error parse and ip csg radius ack error user. The configuration mode for this command changed from CSG user group configuration to global configuration. radius endpoint The name of this command changed to ip csg radius endpoint. The configuration mode for this command changed from module CSG configuration to global configuration. The vrf vrf-name and vrf sub-vrf-name keywords and arguments were added. The table table-name keyword and argument were removed. radius handoff The name of this command changed to ip csg radius handoff. The configuration mode for this command changed from CSG user group configuration to global configuration. radius pod attribute The name of this command changed to ip csg radius pod attribute. The configuration mode for this command changed from CSG user group configuration to global configuration. The 26 keyword was removed. radius pod nas The name of this command changed to ip csg radius pod nas. The configuration mode for this command changed from CSG user group configuration to global configuration. The vrf vrf-name keyword and argument were added. radius pod timeout The name of this command changed to ip csg radius pod timeout. The configuration mode for this command changed from CSG user group configuration to global configuration. radius proxy The name of this command changed to ip csg radius proxy. The configuration mode for this command changed from module CSG configuration to global configuration. The vrf vrf-name keyword and argument were added. The table table-name keyword and argument were removed.
C-7
Appendix C Changed Commands
Table C-1
Command radius start restart session-id
Change from CSG1 The name of this command changed to ip csg radius start restart session-id. The configuration mode for this command changed from module CSG configuration to global configuration. The 26 keyword was removed.
radius stop purge
The name of this command changed to ip csg radius stop purge. The configuration mode for this command changed from module CSG configuration to global configuration. The 26 keyword was removed.
radius userid
The name of this command changed to ip csg radius userid. The configuration mode for this command changed from module CSG configuration to global configuration.
records format
The name of this command changed to ip csg records format. The configuration mode for this command changed from CSG accounting configuration to global configuration. The variable-single-cdr keyword was replaced with the combined keyword. The http and wap keywords were added.
records granularity records intermediate
The time keyword changed to seconds. The range for the seconds argument changed from 60 to 4294967295, to 5 to 86400. The configuration mode for this command changed from CSG accounting configuration to CSG2 content configuration. The time keyword changed to seconds. The range for the seconds argument changed from 5 to 65535, to 5 to 86400.
records max
The name of this command changed to ip csg bma messages. The configuration mode for this command changed from CSG accounting configuration to global configuration.
record-storage
The name of this command changed to ip csg psd. The configuration mode for this command changed from CSG accounting configuration to global configuration. The vrf vrf-name keyword and argument were added.
record-storage local-port
The name of this command changed to ip csg psd local-port. The configuration mode for this command changed from CSG accounting configuration to global configuration.
redirect
The name of this command changed to ip csg redirect. The configuration mode for this command changed from CSG user group configuration to CSG2 service configuration. The interval seconds and maximum number keywords and arguments were added. The nat ipv4-address and port-number keyword and arguments were removed.
refund-policy
The name of this command changed to refund.
C-8
OL-22840-05
Appendix C
Table C-1
Command replicate connection tcp report http header
Change from CSG1 The name of this command changed to replicate (CSG2 content). The delay seconds keyword and argument were added. The name of this command changed to ip csg report http header. The configuration mode for this command changed from CSG accounting configuration to global configuration.
report radius attribute
The name of this command changed to ip csg report radius attribute. The configuration mode for this command changed from CSG accounting configuration to global configuration. The 26 keyword was removed.
report usage
The name of this command changed to ip csg report usage. The configuration mode for this command changed from CSG accounting configuration to global configuration.
show module csg accounting show module csg content show module csg stats snmp-server enable traps csg url-map user-profile server
This command, along with the show module csg content and show module csg stats commands, was incorporated into show ip csg. This command, along with the show module csg accounting and show module csg stats commands, was incorporated into show ip csg. This command, along with the show module csg accounting and show module csg content commands, was incorporated into show ip csg. The bma, database, quota-server, records, and state keywords were added. The agent, database, and quota-server keywords were removed. This command, along with the header-map command, was incorporated into map (CSG2 policy). The name of this command changed to ip csg entries user profile. The configuration mode for this command changed from CSG user group to global configuration.
verify verify confirmation
The name of this command changed to verify enable. The name of this command changed to verify confirm. The configuration mode for this command changed from CSG user group configuration to CSG2 service configuration. The list of supported special characters changed.
vlan (CSG2 content)
The vlan-name argument was replaced with the vlan-number argument.
C-9
Appendix C Changes to Module CSG Configuration Mode
Changes to Module CSG Configuration Mode

Table C-2 summarizations the changes to module CSG configuration mode between the CSG1 and the CSG2:
Table C-2 Summary of Changes to Module CSG Configuration Mode
Command Name module csg
Status in the CSG2 Removed. There is no module CSG configuration mode in the CSG2. The old module CSG configuration mode commands have been removed or replaced with global configuration mode commands.
accounting (module CSG) ft group (module CSG) hostname radius endpoint radius proxy ruleset variable vlan (module CSG)
Removed. Removed. Removed. ip csg radius endpoint ip csg radius proxy Removed. Removed. Removed.
Changes to Module CSG VLAN Configuration Mode

Table C-3 summarizations the changes to module CSG VLAN configuration mode between the CSG1 and the CSG2:
Table C-3 Summary of Changes to Module CSG VLAN Configuration Mode
Command Name vlan (module CSG)
Status in the CSG2 Removed. There is no module CSG VLAN configuration mode in the CSG2.
alias (module CSG VLAN) gateway (module CSG VLAN) ip address (module CDG VLAN) route (module CSG VLAN) table (module CSG VLAN)
Removed. Removed. Removed. Removed. Removed.
C-10
OL-22840-05
Appendix C
CSG2 Command HistoryCSG1 R7 to CSG2 R1 Changes to Accounting Configuration Mode
Changes to Accounting Configuration Mode

Table C-4 summarizations the changes to accounting configuration mode between the CSG1 and the CSG2:
Table C-4 Summary of Changes to Accounting Group Configuration Mode
Command Name ip csg accounting
Status in the CSG2 Removed. There is no accounting configuration mode in the CSG2. The old accounting configuration mode commands have been removed, moved to other configuration modes, or replaced with global configuration mode commands.
aoc confirmation database entries max ip csg entries user idle ip csg quota-server reassign quota activate quota local-port quota server radius acct-port radius ack error radius handoff radius key radius monitor radius parse strict radius pod attribute radius pod nas radius pod timeout radius server radius start restart session-id radius stop purge radius userid redirect user-profile server verify confirmation
aoc confirm Moved to CSG2 service configuration mode. ip csg database ip csg entries user max New for CSG2. New for CSG2. ip csg quota-server activate ip csg quota-server local-port ip csg quota-server Removed. ip csg radius ack error parse and ip csg radius ack error user ip csg radius handoff Removed. Removed. Removed. ip csg radius pod attribute ip csg radius pod nas ip csg radius pod timeout Removed. ip csg radius start restart session-id ip csg radius stop purge ip csg radius userid ip csg redirect ip csg entries user profile verify confirm
C-11
Appendix C Changes to Billing Configuration Mode
Changes to Billing Configuration Mode

Table C-5 summarizations the changes to billing configuration mode between the CSG1 and the CSG2:
Table C-5 Summary of Changes to Billing Configuration Mode
Command Name ip csg billing entries user idle mode service
Status in the CSG2 Same command name and configuration mode. New for CSG2. Same command name and configuration mode. Same command name and configuration mode.
Changes to Block Configuration Mode

Table C-6 summarizations the changes to block configuration mode between the CSG1 and the CSG2:
Table C-6 Summary of Changes to Block Configuration Mode
Command Name ip csg block
Status in the CSG2 block Moved to CSG2 content configuration mode.
Changes to Content Configuration Mode

Table C-7 summarizations the changes to content configuration mode between the CSG1 and the CSG2:
Table C-7 Summary of Changes to Content Configuration Mode
Command Name ip csg content block client (CSG content) client-group (CSG2 content) idle (CSG2 content) inservice (CSG2 content) ip (CSG2 content) mode tcp next-hop (CSG2 content) parse length (CSG2 content) parse protocol (CSG2 content) pending (CSG2 content) policy (CSG2 content)
Status in the CSG2 Same command name and configuration mode. Moved from block configuration mode. Removed. Moved from policy configuration mode. Same command name and configuration mode. Same command name and configuration mode. Same command name and configuration mode. New for CSG2. Moved from policy configuration mode. New for CSG2. New for CSG2. Same command name and configuration mode. Same command name and configuration mode.
C-12
OL-22840-05
Appendix C
CSG2 Command HistoryCSG1 R7 to CSG2 R1 Changes to Map Configuration Mode
Table C-7
Summary of Changes to Content Configuration Mode (continued)
Command Name records delay records intermediate replicate connection tcp
Status in the CSG2 New for CSG2. Moved from accounting configuration mode. replicate (CSG2 content)
subscriber-ip http-header x-forwarded-for New for CSG2. (CSG2 content) vlan (CSG2 content) vrf (CSG2 content) Same command name and configuration mode. New for CSG2.
Changes to Map Configuration Mode

Table C-8 summarizations the changes to map configuration mode between the CSG1 and the CSG2:
Table C-8 Summary of Changes to Map Configuration Mode
Command Name ip csg map match (header map) match method (CSG2 map) match (URL map)
Status in the CSG2 Same command name and configuration mode. match header (CSG2 map) Moved to CSG2 map configuration mode. New for CSG2. match url (CSG2 map) Moved to CSG2 map configuration mode.
Changes to Policy Configuration Mode

Table C-9 summarizations the changes to policy configuration mode between the CSG1 and the CSG2:
Table C-9 Summary of Changes to Policy Configuration Mode
Command Name ip csg policy accounting (CSG2 policy) client-ip (CSG policy) header-map next-hop (CSG2 content) url-map
Status in the CSG2 Same command name and configuration mode. Same command name and configuration mode. Removed. map (CSG2 policy) Moved to CSG2 content configuration mode. map (CSG2 policy)
client-group (CSG2 content) Moved to CSG2 content configuration mode.
C-13
Appendix C Changes to Refund Configuration Mode
Changes to Refund Configuration Mode

Table C-10 summarizations the changes to refund configuration mode between the CSG1 and the CSG2:
Table C-10 Summary of Changes to Refund Configuration Mode
Command Name ip csg refund flags retcode
Status in the CSG2 Same command name and configuration mode. Same command name and configuration mode. Same command name and configuration mode.
Changes to Ruleset Configuration Mode

Table C-11 summarizations the changes to ruleset configuration mode between the CSG1 and the CSG2:
Table C-11 Summary of Changes to Ruleset Configuration Mode
Command Name ip csg ruleset
Status in the CSG2 Removed.
Changes to Service Configuration Mode

Table C-12 summarizations the changes to service configuration mode between the CSG1 and the CSG2:
Table C-12 Summary of Changes to Service Configuration Mode
Command Name ip csg service activation aoc append url aoc confirm aoc enable authorize content basis class (CSG2 service) content (CSG2 service) idle (CSG2 service) meter exclude meter imap meter increment meter initial
Status in the CSG2 Same command name and configuration mode. Same command name and configuration mode. New for CSG2. Moved from user group configuration mode. New for CSG2. aoc enable Same command name and configuration mode. Same command name and configuration mode. Same command name and configuration mode. Same command name and configuration mode. Three new commands for CSG2: meter exclude mms wap, meter exclude pause rtsp, and meter exclude svc-idle. meter include imap Same command name and configuration mode. Same command name and configuration mode.
C-14
OL-22840-05
Appendix C
CSG2 Command HistoryCSG1 R7 to CSG2 R1 Changes to SNMP Timer Configuration Mode
Table C-12
Summary of Changes to Service Configuration Mode (continued)
Command Name meter minimum owner id owner name passthrough reauthorization threshold reauthorization timeout records granularity refund-policy verify verify confirm zero-quota abort type
Status in the CSG2 Same command name and configuration mode. owner (CSG2 service) owner (CSG2 service) Same command name and configuration mode. New for CSG2. New for CSG2. Same command name and configuration mode. refund verify enable New for CSG2. Removed.
Changes to SNMP Timer Configuration Mode

Table C-13 summarizations the changes to SNMP timer configuration mode between the CSG1 and the CSG2:
Table C-13 Summary of Changes to SNMP Timer Configuration Mode
Command Name ip csg snmp timer
Status in the CSG2 ip csg snmp timer
Changes to Transport-Type Configuration Mode

Table C-14 summarizations the changes to transport-type configuration mode between the CSG1 and the CSG2:
Table C-14 Summary of Changes to Transport-Type Configuration Mode
Command Name ip csg transport-type
Status in the CSG2 ip csg transport-type assign
C-15
Appendix C Changes to User Group Configuration Mode
Changes to User Group Configuration Mode

Table C-15 summarizations the changes to user group configuration mode between the CSG1 and the CSG2:
Table C-15 Summary of Changes to User Group Configuration Mode
Command Name ip csg user-group
Status in the CSG2 Removed. There is no user group configuration mode in the CSG2. The old user group configuration mode commands have been removed, moved to other configuration modes, or replaced with global configuration mode commands.
aoc confirmation database entries max ip csg entries user idle ip csg quota-server reassign quota activate quota local-port quota server radius acct-port radius ack error radius handoff radius key radius monitor radius parse strict radius pod attribute radius pod nas radius pod timeout radius server radius start restart session-id radius stop purge radius userid redirect user-profile server verify confirmation
aoc confirm Moved to CSG2 service configuration mode. ip csg database ip csg entries user max New for CSG2. New for CSG2. ip csg quota-server activate ip csg quota-server local-port ip csg quota-server Removed. ip csg radius ack error parse ip csg radius handoff Removed. Removed. Removed. ip csg radius pod attribute ip csg radius pod nas ip csg radius pod timeout Removed. ip csg radius start restart session-id ip csg radius stop purge ip csg radius userid ip csg redirect ip csg entries user profile verify confirm
C-16
OL-22840-05
Appendix C
CSG2 Command HistoryCSG1 R7 to CSG2 R1 Changes to Weight Configuration Mode
Changes to Weight Configuration Mode

Table C-16 summarizations the changes to weight configuration mode between the CSG1 and the CSG2:
Table C-16 Summary of Changes to Weight Configuration Mode
Command Name ip csg weight
Status in the CSG2 Removed.
C-17
Appendix C Changes to Weight Configuration Mode
C-18
OL-22840-05
A P P E N D I X


New Commands, page D-1 Deleted Commands, page D-2 Changed Commands, page D-2
New Commands
The following commands are new for the CSG2 Release 2:

clear ip iscsi statistics (privileged EXEC mode) clear record-storage-module stats (privileged EXEC mode) ip (iSCSI) (iSCSI configuration mode) ip csg iscsi drain delay (global configuration mode) ip csg iscsi drain packet (global configuration mode) ip csg iscsi profile (global configuration mode) ip csg radius monitor (global configuration mode) ip csg radius monitor nas (global configuration mode) ip csg radius on-off purge (global configuration mode) ip csg radius reauthorization attribute (global configuration mode) ip iscsi target-profile (global configuration mode)
D-1
Appendix D Deleted Commands
meter exclude control sip (CSG2 service configuration mode) meter exclude network-init sip (CSG2 service configuration mode) name (iSCSI) (iSCSI configuration mode) port (iSCSI) (iSCSI configuration mode) session-timeout (iSCSI) (iSCSI configuration mode) show ip iscsi (privileged EXEC mode) show record-storage-module (privileged EXEC mode) target-portal (iSCSI) (iSCSI configuration mode)
Deleted Commands
No CSG2 commands were deleted from the CSG2 Release 2.
Changed Commands
Table D-1 summarizes the changes made to commands between the CSG2 Release 1 and the CSG2 Release 2:
Table D-1 Commands That Changed Between CSG2 Release 1 and the CSG2 Release 2
Command accounting (CSG2 policy) basis clear ip csg debug ip csg ip csg bma retransmit ip csg bma retries ip csg entries user max
Change from CSG2 Release 1 Support for FTP was added. The transaction keyword was added. The ftp keyword was added. The crashinfo, ftp, iscsi, mail, and sip keywords were added. The range changed from 1 to 65535 to 2 to 65535. The packet keyword was added. The range was changed to reflect the differences between the 2 GB-SAMI and 1 GB-SAMI options:

For the 2 GB-SAMI option, the range is from 1 to 1250000. For the 1 GB-SAMI option, the range is from 1 to 500000.
ip csg entries user profile ip csg psd retries ip csg quota-server retries
The timeout keyword and timeout argument were added. The packet keyword was added. The packet keyword was added.
D-2
OL-22840-05
Appendix D
Table D-1
Commands That Changed Between CSG2 Release 1 and the CSG2 Release 2 (continued)
Command ip csg redirect match header (CSG2 map) match method (CSG2 map) match url (CSG2 map) next-hop (CSG2 content) policy (CSG2 content) retcode show ip csg
Change from CSG2 Release 1 The sip keyword and url argument were added. Support for Session Initiation Protocol (SIP) headers was added. Support for Session Initiation Protocol (SIP) methods was added. Support for Session Initiation Protocol (SIP) URLs was added. The subscriber and media keywords were added. The priority keyword and the priority-number argument were added. The ftp and sip keywords were added. The billing, ftp, gtp, history, iscsi, load, plan, and sip keywords and billing-plan-name argument were added.
parse protocol (CSG2 content) The ftp and sip keywords were added.
D-3
Appendix D Changed Commands
D-4
OL-22840-05
A P P E N D I X


New Commands, page E-1 Deleted Commands, page E-2 Changed Commands, page E-2
New Commands

class-map (CSG2 policy) (CSG2 policy configuration mode) control-url (CSG2 content configuration mode) ip csg count retransmit ip (global configuration mode) ip csg license syslog enable (global configuration mode) ip csg license warning-enable (global configuration mode) ip csg qos profile (global configuration mode) ip csg quota-server user-profile (global configuration mode) ip csg report 8bytetlv (global configuration mode) ip csg report tcp estab (global configuration mode) match attribute (CSG2 map) (CSG2 map configuration mode) next-hop override (CSG2 content) (CSG2 content configuration mode)
E-1
Appendix E Deleted Commands
police (CSG2 QoS profile configuration mode) qos profile (CSG2 billing) (CSG2 billing configuration mode) qos profile (CSG2 service) (CSG2 service configuration mode) user-default (CSG2 billing configuration mode)
Deleted Commands
Changed Commands
Table E-1 summarizes the changes made to commands between the CSG2 Release 2 and the CSG2 Release 3:
Table E-1 Commands That Changed Between CSG2 Release 2 and the CSG2 Release 3
Command basis clear ip csg debug ip csg parse length (CSG2 content) passthrough policy (CSG2 content) reauthorization threshold service show ip csg snmp-server enable traps csg
Change from CSG2 Release 2 The dual keyword was added. The license warning keywords were added. The nbar keyword was added. Support for NBAR was added. The dual keyword and dual-quota-grant argument were added. The range for the priority-number argument changed from 1 to 65535 to 1 to 511. The dual keyword and dual-threshold argument were added. The mode postpaid keywords were added. The license warning keyword was added. The license warning-enable keywords were added.
parse protocol (CSG2 content) The nbar keyword was added.
E-2
OL-22840-05
A P P E N D I X
CSG2 Command HistoryCSG2 R3 to CSG2 R3.5

The following sections document the changes to commands between the CSG2 Release 3 and the CSG2 Release 3.5:

New Commands, page F-1 Deleted Commands, page F-3 Changed Commands, page F-3
New Commands
The following commands are new for the CSG2 Release 3.5:

clear mpcc (privileged EXEC mode) clear mpcc session (privileged EXEC mode) csg start preload (privileged EXEC mode) debug mpcc (privileged EXEC mode) ip csg event-trace packet enable (global configuration mode) ip csg event-trace packet entries (global configuration mode) ip csg event-trace packet match action (global configuration mode) ip csg event-trace packet match error (global configuration mode) ip csg event-trace packet match ip (global configuration mode) ip csg event-trace packet match protocol (global configuration mode) ip csg geo-redundancy (global configuration mode)
F-1
Appendix F New Commands
ip csg pcc gx (global configuration mode) ip csg preload request (global configuration mode) ip csg radius coa nas (global configuration mode) ip csg radius coa timeout (global configuration mode) ip csg radius proxy timeout (global configuration mode) ip csg regex memory (global configuration mode) ip csg report content (global configuration mode) ip csg report policy (global configuration mode) ip csg select (global configuration mode) ip csg statistics protocol interval (global configuration mode) ip csg user profile (global configuration mode) mpcc destination-realm (global configuration mode) mpcc include avp destination-host (global configuration mode) mpcc preload (global configuration mode) mpcc preload policy-if (global configuration mode) mpcc preload timeout (global configuration mode) mpcc profile (global configuration mode) normalize-url (CSG2 content configuration mode) offline (CSG2 billing configuration mode) pcc gx (CSG2 user profile configuration mode) pcrf failure (CSG2 user profile configuration mode) pcrf policy-if (Mobile PCC profile configuration mode)
F-2
OL-22840-05
Appendix F
CSG2 Command HistoryCSG2 R3 to CSG2 R3.5 Deleted Commands
pcrf profile (CSG2 user profile configuration mode) pcrf timeout (CSG2 user profile configuration mode) realm destination (Mobile PCC profile configuration mode) relative (CSG2 content configuration mode) show mpcc (privileged EXEC mode)
Deleted Commands
No CSG2 commands were deleted from the CSG2 Release 3.5.
Changed Commands
Table F-1 summarizes the changes made to commands between the CSG2 Release 3 and the CSG2 Release 3.5:
Table F-1 Commands That Changed Between CSG2 Release 3 and the CSG2 Release 3.5
Command clear ip csg debug ip csg mode service show ip csg
Change from CSG2 Release 3 The event-trace packet and preload keywords were added. The event-trace packet, gx, and preload keywords were added. The virtual keyword was added. The prepaid virtual keywords were added. The connectionless, connection-oriented, control, data, event-trace packet, gx, map, match action dropped, match action forwarded, match action queued, match error parse, match ip global, match ip network, match ip subscriber, match ip vrf, match protocol ftp, match protocol http, match protocol imap, match protocol other, match protocol pop3, match protocol radius, match protocol rtsp, match protocol sip, match protocol smtp, match protocol wap, monitor, policy, preload, protocol, proxy, service, and status keywords were added. The network-acl, subscriber-acl, and vrf-name arguments were added.
F-3
Appendix F Changed Commands
F-4
OL-22840-05
A P P E N D I X
CSG2 Command HistoryCSG2 R3.5 to CSG2 R4

The following sections document the changes to commands between the CSG2 Release 3.5 and the CSG2 Release 4:

New Commands, page G-1 Deleted Commands, page G-3 Changed Commands, page G-3
New Commands

class (CSG2 header) (CSG2 header configuration mode) domain group (CSG2 content) (CSG2 content configuration mode) encrypt (CSG2 header) (CSG2 header configuration mode) header (CSG2 header-group) (CSG2 header-group configuration mode) header-group (CSG2 service) (CSG2 service configuration mode) insert header-group (CSG2 policy) (CSG2 policy configuration mode) ip csg domain group (global configuration mode) ip csg domain mining (global configuration mode) ip csg egcdr mode (global configuration mode) ip csg entries dns map hash size (global configuration mode) ip csg entries dns map interval (global configuration mode)
G-1
Appendix G New Commands
ip csg entries dns map ttl maximum (global configuration mode) ip csg entries dns map ttl minimum (global configuration mode) ip csg header (global configuration mode) ip csg header-group (global configuration mode) ip csg keys (global configuration mode) ip csg radius attribute (global configuration mode) ip csg radius binary attribute (global configuration mode) ip csg radius route inject (global configuration mode) ip csg radius start restart session-id (global configuration mode) ip csg report user logoff (global configuration mode) ip csg user class (global configuration mode) match domain (CSG2 domain group) (CSG2 domain group configuration mode) mining (CSG2 content) (CSG2 content configuration mode) name (CSG2 header) (CSG2 header configuration mode) qct (CSG2 service) (CSG2 service configuration mode) quota-server (CSG2 header) (CSG2 header configuration mode) radius (CSG2 header) (CSG2 header configuration mode) radius (CSG2 user class) (CSG2 user class configuration mode) rating-group (CSG2 service) (CSG2 service configuration mode) string (CSG2 header) (CSG2 header configuration mode) timestamp (CSG2 header) (CSG2 header configuration mode) user class (CSG2 service) (CSG2 service configuration mode)
G-2
OL-22840-05
Appendix G
CSG2 Command HistoryCSG2 R3.5 to CSG2 R4 Deleted Commands
Deleted Commands
Changed Commands
Table G-1 summarizes the changes made to commands between the CSG2 Release 3.5 and the CSG2 Release 4:
Table G-1 Commands That Changed Between CSG2 Release 3.5 and the CSG2 Release 4
Command clear ip csg debug ip csg
Change from CSG2 Release 3.5 The dns map keywords were added. For Cisco IOS Release 12.4(24)MDA:
The detail keyword was added for the users keyword. The dns keyword was added.
For Cisco IOS Release 12.4(24)MD:
flags ip csg event-trace packet match protocol ip csg quota-server
The dns keyword was added. The dns keyword was added. The eggsn keyword was added.
G-3
Appendix G Changed Commands
Table G-1
Commands That Changed Between CSG2 Release 3.5 and the CSG2 Release 4 (continued)
Command parse protocol (CSG2 content) show ip csg
Change from CSG2 Release 3.5 The dns and insert keywords were added. For Cisco IOS Release 12.4(24)MDA:

The header, header group, and qos keywords were added. The header-name, header-group-name, and qos-profile-name arguments were added. The domain group and header group keywords were added for the preload keyword. The output of the show ip csg users detail command was updated to reflect the Subscriber Sign-On Timestamp and User Table Entry Creation Time fields. The dns, dns map, domain group, name, radius, service, user class, and user count keywords were added. The domain-group-name, radius-name, service-name, and session-id arguments were added. The header and qos keywords were added for the preload keyword. The show ip csg sessions user command now accepts the dns keyword for the application argument. The output for the show ip csg content name command was updated to reflect domain groups. The output for the show ip csg stats command was updated to reflect DNS IP Map Table statistics. The output for the show ip csg users command was updated to reflect the eGGSN quota server mode of operation for each user.
For Cisco IOS Release 12.4(24)MD:

G-4
OL-22840-05
A P P E N D I X


New Commands, page H-1 Deleted Commands, page H-1 Changed Commands, page H-2
New Commands

accelerate (CSG2 content configuration mode) ip csg load accel rate (global configuration mode) ip csg report block (global configuration mode) ipv6 (CSG2 content) (CSG2 content configuration mode) lifetime (CSG2 service) (CSG2 service configuration mode)
Deleted Commands
H-1
Appendix H Changed Commands
Changed Commands
Table H-1 summarizes the changes made to commands between the CSG2 Release 4 and the CSG2 Release 5:
Table H-1 Commands That Changed Between CSG2 Release 4 and the CSG2 Release 5
Command clear ip csg
Change from CSG2 Release 4 The ipv6 keyword and ipv6-prefix argument were added for the sessions user and user keywords. The ip keyword was removed. The ipv6 keyword and std-ipv6-access-list-name argument were added. The accel and name keywords and acl-name argument were added. The ipv6 keyword and ipv6-address argument were added. The ipv6 keyword and ipv6-prefix argument were added for the dns map keyword. The ip keyword was removed for the dns map keyword. The ipv6 keyword and ipv6-prefix argument were added for the sessions keyword. The accel keyword was added for the sessions user keyword. The accel keyword was added for the stats keyword. The ipv6 and map keywords and the ipv6-prefix argument were added for the users keyword. The output of the following commands was updated to reflect support for IPv6 addresses:

client-group (CSG2 content) debug ip csg next-hop (CSG2 content) show ip csg
show ip csg content show ip csg dns map show ip csg preload content show ip csg sessions show ip csg stats show ip csg users
H-2
OL-22840-05
A P P E N D I X
Protocol Compliance Statements for the CSG2

This appendix provides protocol compliance statements for the CSG2. Any RFCs that are not explicitly listed are not supported.
Layer 4 Inspection (parse protocol=other)

The Cisco Content Services Gateway 2 (CSG2) differentiates TCP and User Datagram Protocol (UDP), and classifies all other protocols simply as IP. All protocols can be billed as TCP, UDP, or IP if further protocol-specific processing is not needed (or if deeper inspection for such protocols is not supported).
IPCompliant with RFC 791. The CSG2 IP volume counters are 8-byte counters that wrap at 0xFFFFFFFFFFFFFFFF (18446744073709552000 bytes). The volume counters are 64 bits unsigned. By default, the CSG2 reports volume usages in BMA records using 4-byte TLVs that wrap at 0xFFFFFFFF (4294967295 bytes). To enable the CSG2 to report volume usages using 8-byte TLVs instead of 4-byte TLVs, use the ip csg report 8bytetlv command in global configuration mode. The CSG2 supports IP fragmentation for generic Layer 4 flows, regardless of protocol and regardless of the order in which the flows arrive.
UDPCompliant with RFC 768. TCPCompliant with standard TCP (RFC 3168) and RFC 1323, with the following exception:
The CSG2 does not support the CLOSING or TIME-WAIT states for TCP connections. When
the final ACK is received, the connection is terminated, and the CSG2 does not count or process any out-of-order packets for the connection.
Layer 7 Inspection (parse protocol=specific protocol)
IPCompliant with RFC 791. The CSG2 IP volume counters are 8-byte counters that wrap at 0xFFFFFFFFFFFFFFFF (18446744073709552000 bytes). The volume counters are 64 bits unsigned. By default, the CSG2 reports volume usages in BMA records using 4-byte TLVs that wrap at 0xFFFFFFFF (4294967295 bytes). To enable the CSG2 to report volume usages using 8-byte TLVs instead of 4-byte TLVs, use the ip csg report 8bytetlv command in global configuration mode. The CSG2 supports IP fragmentation for all Layer 7 flows, regardless of protocol and regardless of the order in which the flows arrive.
I-1
Appendix I Layer 7 Inspection (parse protocol=specific protocol)
UDPCompliant with RFC 768. See the Layer 7 Inspection IP bullet for further restrictions. TCPCompliant with standard TCP (RFC 793), with the following exceptions:
When performing Layer 7 inspection of TCP-based protocols, the CSG2 buffers packets that are
received out of order, and processes and forwards them in the proper order.
The CSG2 does not support the CLOSING or TIME-WAIT states for TCP connections. When
the final ACK is received, the connection is terminated, and the CSG2 does not count or process any out-of-order packets for the connection. The CSG2 TCP volume counters are 8-byte counters that wrap at 0xFFFFFFFFFFFFFFFF (18446744073709552000 bytes). The volume counters are 64 bits unsigned. By default, the CSG2 reports volume usages in BMA records using 4-byte TLVs that wrap at 0xFFFFFFFF (4294967295 bytes). To enable the CSG2 to report volume usages using 8-byte TLVs instead of 4-byte TLVs, use the ip csg report 8bytetlv command in global configuration mode. See the Layer 7 Inspection IP bullet for further restrictions.
HTTPCompliant with RFC 1945 (HTTP 1.0) and RFC 2616 (HTTP 1.1), with the following exceptions:
1.
Each HTTP method must be initiated by the same endpoint that initiated the TCP connection (that is, by the same side that sent the TCP SYN). Impact: Subscriber requests transfer no data (that is, the requests hang). See the TO-TCP sub-bullet under the Layer 7 Inspection MMS for WAP 2.0 bullet for an example.
2.
HTTP request parsing is limited by the setting of the parse length command in CSG2 content configuration mode. Impact: If a header exceeds the configured limit, the session is ended and the header is not used in matching URL or header maps.
3.
If the HTTP network or subscriber causes improper parsing, the CSG2 reverts to Layer 4 billing for the remainder of the TCP connection. Examples of improper parsing include: - If an HTTP response does not begin with HTTP, the CSG2 increments a Layer 7 error statistic, Parse failures, and invokes Layer 4 billing. (The CSG2 requires that all HTTP responses begin with the string HTTP.) - If a response contains characters other than ASCII decimal digits (0x30 through 0x39), the CSG2 increments the Parse failures statistic and invokes Layer 4 billing. (When parsing the response for an HTTP return code, the CSG2 accepts only ASCII decimal digits.) - If the CSG2 cannot parse the status line in the response, it invokes Layer 4 billing for all subsequent traffic.
4.
HTTP status 101 (switching protocols) is not supported. The CSG2 expects all subsequent requests to be unencrypted and parsable by HTTP rules (see the Layer 7 Inspection HTTPS bullet for further restrictions). Impact: The CSG2 increments the Status code statistic and invokes Layer 4 billing. Error codes 204, 205, and 304 do not require a body. If a response contains one of these error codes, the CSG2 ignores Content-Type:, Content-Length:, and Transfer-Encoding:chunked headers that might be present in error. An HTTP message that has a Content-Type: header, but no Content-Length: or Transfer-Encoding:chunked header, causes the CSG2 to invoke Layer 4 billing. If there are multiple responses for one request, the CSG2 invokes Layer 4 billing.
5.
6. 7.
I-2
OL-22840-05
Appendix I
Protocol Compliance Statements for the CSG2 Layer 7 Inspection (parse protocol=specific protocol)
8.
Multipart content is supported. The CSG2 supports the standard RANGE header as well as the earlier byterange directive on the URI. In both cases, the Content-Type: multipart... header must be present in order for the CSG2 to consider the stream for multipart parsing. The particular subtype in the header does not matter, as long as multipart is specified as the type. If multipart is not specified in the Content-Type: header, the CSG2 parses the data as regular HTTP and reverts to Layer 4 billing if any errors in the format are detected.
Compliant with RFC 2774 (HTTP Extension Framework), subject to the restrictions above. See the Layer Inspection TCP bullet for further restrictions.
HTTPSBecause HTTPS URLs and other headers are encrypted, the CSG2 cannot provide Layer 7 information for HTTPS requests. Also, switching from HTTP to HTTPS within the same persistent connection is subject to the following restrictions:
Switching via the Connect method (RFC 2817) is supported. The CSG2 detects the Connect
method and invokes Layer 4 billing for the remainder of the TCP connection. This Layer 4 charging is reported via the HTTP statistics CDR for the Connect transaction. The CSG2 will not discern any additional transactions after the Connect method is detected. If a method map is configured for the Connect method, the traffic is charged against the matching policy. If no policy exists with the method map, the CSG2 passes the traffic without charge.
Switching via the Upgrade header (RFC 2817) is ignored. The CSG2 attempts to parse the
traffic as normal HTTP. When parsing fails, the CSG2 invokes Layer 4 billing for all subsequent traffic on the TCP connection, charging against the last matching policy. See the Layer 7 Inspection HTTP bullet for further restrictions.
WAP 2.0The CSG2 supports the billing of WAP 2.0 over clear text HTTP and the differential billing of Multimedia Messaging Service (MMS) over WAP 2.0 over clear text HTTP (see the Layer 7 Inspection MMS for WAP 2.0 for details) as specified by the WAP Forum, with the following exceptions:
The CSG2 cannot bill Transport Layer Security (TLS) (encrypted connections) as WAP 2.0
flows. In WAP-235-PushOTA-20010425-a, TLS is referenced as OTA-HTTP-TLS.

See the Layer 7 Inspection HTTPS bullet for restrictions on switching from HTTP to HTTPS
within the same persistent connection. WAP-219-TLS-20010411-a specifies that only the Connect method is supported (that is, portions of RFC 2817 pertaining to Upgrade requests or responses are not supported by WAP 2.0 subscribers). See the Layer 7 Inspection HTTP 1.1, HTTPS, and WP-TCP bullets for further restrictions.
MMS for WAP 2.0 (HTTP transport)At present the Multimedia Messaging Service (MMS) standard is very incomplete.
For MMS differentiation, the CSG2 requires that the Content-Type header in the request be
set to application/vnd.wap.mms-message on all MMS, WAP 2.0, and HTTP exchanges, except for message retrieval requests.
For message retrieval, the Content-Type header is not present in the GET request, so the
CSG2 uses the URL in the GET request and ignores the Content-Type header in the response. This method provides reasonable differentiation, although examining the Content-Type in the response is the preferred technique for MMS differentiation, in accordance with the standard. MMS over WAP 2.0 allows three types of notification:
1.
Short Message Service (SMS) notification carrying the Uniform Resource Identifier (URI) for the MMS. The handset then initiates a GET request to that URI to retrieve the information.
I-3
2.
TO-TCP, which starts with SMS but provides only the IP address of the Push Proxy Gateway (PPG). The terminal must then open a TCP connection and wait for an HTTP request from the PPG. This HTTP request is an OPTIONS method and must succeed before the handset can retrieve the notification. PO-TCP, which is similar to TO-TCP, except the TCP connection is opened by the PPG and is followed by the OPTIONS method.
3.
The CSG2 Layer 7 billing for MMS relies entirely on notification types 1 and 3. The CSG2 does not support TO-TCP. If a terminal reuses a persistent PO-TCP to initiate a new method request, the packets are dropped and the PO-TCP connection appears to be hung until the TCP retry attempts expire. See the Layer 7 Inspection WAP 2.0 bullet for further restrictions.
POP3Compliant with RFC 1939. The CSG2 reports the RFC 2822 (Internet Message Format) headers in the body of the POP3 message. See the Layer Inspection TCP bullet for further restrictions. IMAP4Compliant with RFC 3501. See the Layer Inspection TCP bullet for further restrictions. SMTPCompliant with RFC 2821. Reports headers in the SMTP are body formatted in accordance with RFC 2822 - Internet Message Format. The CSG2 does not support SMTP command pipelining as defined in RFC 2920 - SMTP Service Extension for Command Pipelining. Impact: Everything is charged for the first e-mail, and incomplete or no SMTP envelopes and RFC 2822 headers are reported (depending on the e-mail content). See the Layer Inspection TCP bullet for further restrictions. FTPCompliant with RFC 959. The CSG2 requires that the control connection use port 21 on the server. See the Layer Inspection TCP bullet for further restrictions. RTSPCompliant with RFC 2326, except that the RFC allows RTSP control flows on either TCP or UDP, but the CSG2 supports RTSP control flows only on TCP. The CSG2 does not parse Synchronized Multimedia Integration Language (SMIL) or Streaming Data Protocol (SDP) files, so correlation is not supported across multiple elements in the file. For Interleaved RTSP (in which Control and Stream both share the control connection), the CSG2 parses only the first two SETUP commands. For I RTSP over HTTP:554 (with policy of type=rtsp), the CSG2 parses only the first SETUP command. See the Layer Inspection TCP bullet for further restrictions. WAP 1.xCompliant with the following specifications:
1. 2. 3. 4.
WAP-100, Wireless Application Protocol Architecture Specification (WAP-100-WAPArch-19980430-a) WAP-165, Push Architectural Overview (WAP-165-PushArchOverview-19991108-a) WAP-203, Wireless Session Protocol Specification (WAP-203-WSP-20000504-a) WAP-201, Wireless Transaction Protocol Specification (WAP-201-WTP-20000219-a)
MMS for Wireless Session Protocol (WSP) is identified via WSP Content Type value 0X3E or via an application/vnd.wap.mms-message.
I-4
OL-22840-05
Appendix I
Protocol Compliance Statements for the CSG2 Layer 7 Inspection (parse protocol=specific protocol)
See the Layer 7 Inspection UDP bullet for further restrictions.
RADIUSCompliant with RFC 2865 and RFC 2866. The CSG2 can inspect RADIUS Access and RADIUS Accounting messages. For RADIUS inspection, the CSG2 does not support messages that exceed an Ethernet frame size (approximately 1470 bytes). Also, the CSG2 does not police the attributes that it does not use.
Specific to RFC 2865Base RADIUS specification:
In order to parse information in the Access-Accept message (from the real server), the CSG2 requires attribute 1 (User-Name) or 31 (Calling-Station-Id), as configured. Page 63 of RFC 2865 shows a summary of the attributes for each of the RADIUS messages. It shows that attribute 31 is not included in the RADIUS Access-Accept message, while Attribute 1 can be. The description of attribute 31 says, It is only used in Access-Request packets. There is no mention of MUST/SHALL/etc. For VSA subattribute parsing, we require the String contents to be encoded as a sequence of vendor type / vendor length / value fields. This is a recommendation (SHOULD) on page 48 of RFC 2865. If subattribute parsing is not configured, this restriction does not apply.
Specific to RFC 2866Accounting:
When operating as a RADIUS Accounting Endpoint, the RADIUS Accounting-Response generated by the CSG2 does not include any attributes, as per page 9 of the RFC: A RADIUS Accounting-Response is not required to have any attributes in it. However, on page 5, step 3, of the RFC: The remote server logs the accounting-request (if desired), copies all Proxy-State attributes in order and unmodified from the request to the response packet, and sends the accounting-response to the forwarding server. The CSG2 is not compliant with this latter statement, though it is not clear if this is a required element of the RFC.
Specific to RFC 2882Extended practices:
The CSG2 supports the RADIUS Disconnect messages defined in this RFC: 40 Disconnect Request 41 Disconnect Ack 42 Disconnect Nak
Specific to RFC 3576Dynamic extensions:
This RFC notes specific ports to which the Disconnect Request is to be sent. The CSG2 allows the customer to configure the NAS port. Also, note specific actions to be taken when the Ack or Nak is receivedThe CSG2 uses the Ack or Nak only to determine whether it is to send the Request. The CSG2 does not use, process, or report any attributes included in the Ack or Nak. Attributes that the CSG2 sends in the Request are defined by the customer. The CSG2 does not support any other message types in this RFC. See the Layer 7 Inspection UDP bullet for further restrictions.
SIPCompliant with RFC 3261 and RFC 4566.

Individual SIP/SDP headers are not parsed beyond the first 256 characters. You must enter the long form of the header name when configuring maps for SIP. The CSG2
does not support the short form of the header name.
I-5
Domain names used in headers are not resolved to IP addresses. If domain names are used in
headers for which IP addresses are required (such as media connect headers), the CSG2 cannot correctly identify and correlate the SIP media traffic.
The CSG2 cleans up media sessions for SIP calls when a positive response to a BYE request is
processed (200 ok). Media packets that flow after the 200 ok are not associated with the media session.
DNSCompliant with RFC 1034 and RFC 1035. See the Layer Inspection TCP bullet for further restrictions.
I-6
OL-22840-05
A P P E N D I X
CSG2 System Messages

This appendix lists and describes Cisco CSG2, Cisco SAMI, and iSCSI system messages. The system software sends these messages to the console (and, optionally, to a logging server on another system) during operation. Not all system messages indicate problems with your system. Some are purely informational, and others may help diagnose problems with communications lines, internal hardware, or the system software. This appendix also includes messages that appear when the system crashes. In these messages, %s indicates a variable text string. For example, the following message: GTP state change: %s Can be displayed as: GTP state change: Communication with CSG Billing Agent 19.19.19.19:2007 established GTP state change: Communication with CSG Billing Agent 19.19.19.19:2007 failed This appendix includes the following information:

CSG2 System Messages, page J-1 Cisco SAMI System Messages, page J-8 iSCSI System Messages, page J-11

Message: Configuration download error: %s
Explanation
An unexpected condition was detected in the configuration sync module.

Mnemonic
CFG_DOWNLOAD_ER
Severity
LOG_EMERG - Sev 0
J-1
Appendix J CSG2 System Messages
Message: %s
Explanation
An unexpected condition was detected in the configuration module.

Mnemonic
CFG_ERROR
Severity
LOG_WARNING - Sev 4
Message: Startup configuration completed.

Explanation
Startup configuration is completed. Traffic is now allowed. This indicates CSG2 is done applying startup configuration.
Mnemonic
CFG_STARTUP_DONE
Severity
LOG_NOTICE- Sev 5
Message: Configuration Sync error: %s

Explanation
An unexpected condition was detected in the configuration sync module. If you see this message after entering the no form of a command, continue to retry the command until it succeeds.
Mnemonic
CFG_SYNC_ERROR
Severity
LOG_WARNING - Sev 4
Message: %s
Explanation
An unexpected condition was detected in the CSG2 CG Affinity component.

Mnemonic
CG_AFF_ERROR
J-2
OL-22840-05
Appendix J
Severity
LOG_WARNING - Sev 4
Message: %s packet drop: queue size %d reached, record storage %s is currently %s

Explanation
An unexpected condition was detected while performing CSG2 operation.

Mnemonic
GTP_CDR_DROP
Severity
LOG_ERR - Sev 3
Message: GTP error: %s

Explanation
An error condition was detected while performing GTP operation. This indicates serious problems within the CSG2 GTP component.
Mnemonic
GTP_ERROR
Severity
LOG_ERR - Sev 3
Message: GTP received reject cause code %d from %i:%u

Explanation
The server rejected a message sent by the CSG2. This indicates that the CSG2 received a reject.
Mnemonic
GTP_REJECT
Severity
LOG_ERR - Sev 3
J-3
Message: GTP state change: %s

Explanation
A service affecting state change has occurred in the IPC component. This indicates problems with communications links between the IOS processors on this module. No action is necessary unless IOS functions are impacted due to unavailability of the IPC links. This message might reflect normal changes in IOS configuration or external network conditions between IOS and the charging gateways. If IPC communications links are being lost and regained frequently, it is important to investigate.
Mnemonic
GTP_STATE_CHANGE
Severity
LOG_WARNING - Sev 4
Message: IPC is link failed to processor %u, state = %u, software reloading card now.
Explanation
A failure in the internal messaging path between the processors on this card has been detected. Configure no ip csg ipc crashdump to prevent this action in the future This indicates a serious problem with communications between the processors on the Cisco SAMI. The CSG2 might not be able to correctly bill traffic in this state. Crashing will induce an HA failover. If this is not the desired behavior consider configuring no ip csg ipc crashdump or configure a longer interval for ip csg ipc crashdump tolerance seconds.
Mnemonic
IPC_DROP_CRASH
Severity
LOG_WARNING - Sev 4
Message: %s
Explanation
A service affecting state change has occurred in the IPC component. This might indicate a serious problem with communications between the processors on the Cisco SAMI, if IPC links are lost and do not recover.
Mnemonic
IPC_STATE_CHANGE
Severity
LOG_WARNING - Sev 4
J-4
OL-22840-05
Appendix J
Message: iSCSI device %i:%u is full

Explanation
The iSCSI is full. This indicates that there is no more disk space on the iSCSI disk.
Mnemonic
iSCSI_FULL
Severity
LOG_ERR - Sev 3
Message: ISCSI state change: %s

Explanation
A service affecting state change has occurred in the ISCSI component. This indicates problems with communications link with the ISCSI device. If link with remote ISCSI device are being lost and regained frequently it is important to investigate.
Mnemonic
ISCSI_STATE_CHANGE
Severity
LOG_WARNING - Sev 4
Message: %s transaction discarded due to high load.

Explanation
The CSG2 has run out of capacity to service new transactions, the most likely cause of this is system overload due to network activity. Statistics on allowed/denied transactions are under show ip csg stats. This indicates that CSG2 is being overloaded in the customer's network, as a result subscriber packets, and billing information might be lost.
Mnemonic
LOAD_MGMT
Severity
LOG_WARNING - Sev 4
J-5
Message: Failed to set %s local port. Either there are no IP addresses configured or port %u is in use.
Explanation
Failed to obtain local port. Either there are no IP addresses configured or the port is in use. This indicates an issue with reserving a local port for a CSG2 component.
Mnemonic
LOCAL_PORT
Severity
LOG_WARNING - Sev 4
Message: Lock depth %u has crossed threshold.

Explanation

Mnemonic
LOCKDEPTH
Severity
LOG_WARNING - Sev 4
Message: CSG NTP synchronization is complete

Explanation
CSG2 NTP synchronization is complete.

Mnemonic
NTP_SYNC_COMPLE
Severity
LOG_NOTICE- Sev 5
J-6
OL-22840-05
Appendix J
Message: Error: %s
Explanation
CSG2 detects the clock for the TP is not in sync with SUP. This might indicate problems with NTP association between TP and SUP due to mis-configuration of NTP on CP or Supervisor.
Mnemonic
NTP_SYNC_ERROR
Severity
LOG_WARNING - Sev 4
Message: PSD device %i:%u is full

Explanation
The PSD is full. There is no more disk space on the PSD.

Mnemonic
PSD_FULL
Severity
LOG_ERR - Sev 3
Message: CSG replicate condition: %s

Explanation
An unexpected condition was detected while performing CSG2 replication operation.

Mnemonic
REPLICATE
Severity
LOG_WARNING - Sev 4
J-7
Appendix J Cisco SAMI System Messages
Message: Error: %s
Explanation
An unexpected error occurred while performing CSG2 operation.

Mnemonic
UNEXPECTED
Severity
LOG_WARNING - Sev 4
Message: Unexpected condition: %s

Explanation

Mnemonic
WARNING
Severity
LOG_WARNING - Sev 4
Cisco SAMI System Messages

This section lists Cisco SAMI messages (prefix SAMI) alphabetically by mnemonic.
Message: Nvram CRC Failure: %d\n

Explanation
NVRAM Corruption.
Mnemonic
NVRAM_CRC_FAILU
Severity
LOG_INFO - Sev 6
J-8
OL-22840-05
Appendix J
CSG2 System Messages Cisco SAMI System Messages
Message: Nvram Erase Failure: handle 0x%x, offset 0x%x, error %s

Explanation
NVRAM Erase Failure.

Mnemonic
NVRAM_ERASE_FAI
Severity
LOG_INFO - Sev 6
Message: Nvram Init Failure of flash device at %d:%s

Explanation
Unable to initialize flash device.

Mnemonic
NVRAM_INIT_FAIL
Severity
LOG_INFO - Sev 6
Message: Nvram Init Failure: %s

Explanation
Unable to initialize flash device: Low Memory.

Mnemonic
NVRAM_INIT_MEMO
Severity
LOG_INFO - Sev 6
Message: Nvram Magic Corrupt: Present %d Expected %d\n

Explanation
NVRAM Corruption.
Mnemonic
NVRAM_MAGIC_COR
Severity
LOG_INFO - Sev 6
J-9
Appendix J Cisco SAMI System Messages
Message: Nvram Write Failure: handle 0x%x, offset 0x%x, numbytes 0x%x error %s
Explanation
NVRAM Write Failure.

Mnemonic
NVRAM_WRITE_BLO
Severity
LOG_INFO - Sev 6
Message: Nvram Write Config Failure: \n

Explanation
NVRAM Write Failure.

Mnemonic
NVRAM_WRITE_CON
Severity
LOG_INFO - Sev 6

Explanation
An unexpected condition was detected while performing Cisco SAMI Platform operation.
Mnemonic
UNEXPECTED
Severity
LOG_WARNING - Sev 4

Explanation
An unexpected condition was detected while performing Cisco SAMI Platform operation.
Mnemonic
WARNING
Severity
LOG_WARNING - Sev 4
J-10
OL-22840-05
Appendix J
CSG2 System Messages iSCSI System Messages
iSCSI System Messages

This section lists iSCSI messages (prefix ISCSI) alphabetically by mnemonic.
Message: Error: %s
Explanation
An unexpected condition was detected in the Record Storage Module.

Mnemonic
ERROR
Severity
LOG_ERR - Sev 3
Message: Error: %s
Explanation
An unexpected error occurred while performing Record Storage Module.

Mnemonic
UNEXPECTED
Severity
LOG_WARNING - Sev 4
Message: Warning: %s
Explanation
An unexpected condition was detected in the Record Storage Module.

Mnemonic
WARNING
Severity
LOG_ERR - Sev 3
J-11
Appendix J iSCSI System Messages
J-12
OL-22840-05
A P P E N D I X
This appendix describes enabling and monitoring CSG2 SNMP notifications in order to manage CSG2-related issues. SNMP uses notifications to report events on a managed device. The notifications are traps or informs for different events.
Note
This appendix covers enabling and monitoring CSG2 SNMP notifications only. Additional types of SNMP notifications can be enabled on your Cisco router. For more information about the types of SNMP notifications you can enable, see the Cisco IOS Configuration Fundamentals, Release 12.4 documentation. Additionally, to display a list of notifications available on your Cisco router, enter the snmp-server enable traps ? command. This appendix contains the following sections:

SNMP Overview, page K-1 Configuring MIB Support, page K-6 Enabling SNMP Support, page K-8 Enabling and Disabling SNMP Notifications, page K-9
SNMP Overview
The Simple Network Management Protocol (SNMP) is an application-layer protocol that provides a standardized framework and a common language used for monitoring and managing devices in a network. The SNMP framework has three parts:
SNMP managerA system used to control and monitor the activities of network hosts using SNMP. The most common managing system is called a Network Management System (NMS). The term NMS can be applied to either a dedicated device used for network management, or the applications used on a network-management device. A variety of network management applications are available for use with SNMP. These features range from simple command-line applications to feature-rich graphical user interfaces (such as the CiscoWorks2000 line of products).
K-1
Appendix K SNMP Overview
SNMP agentA software component in a managed device that maintains the data for the device and reports the data, as needed, to managing systems. The agent and MIB reside on the routing device (router, access server, or switch). To enable the SNMP agent on a managed device, you must define the relationship between the manager and the agent (see the Enabling SNMP Support section on page K-8). Management Information Base (MIB)Collection of network-management information, organized hierarchically.
Instead of defining a large set of commands, SNMP places all operations in a get-request, get-next-request, and set-request format. For example, an SNMP manager can get a value from an SNMP agent or set a value in that SNMP agent.
MIB Description
A Management Information Base (MIB) is a collection of network-management information, organized hierarchically. The MIB consists of collections of managed objects identified by object identifiers. MIBs are accessed using a network-management protocol such as SNMP. A managed object (sometimes called a MIB object or an object) is one of a number of characteristics of a managed device, such as a router. Managed objects comprise one or more object instances, which are essentially variables. The Cisco implementation of SNMP uses the definitions of MIB II variables described in RFC 1213. MIBs can contain two types of managed objects:

Scalar objectsDefine a single object instance (for example, ifNumber in the IF-MIB and bgpVersion in the BGP4-MIB). Columnar objectsDefines a MIB table that contains no rows or more than one row, and each row can contain one or more scalar objects, (for example, ifTable in the IF-MIB defines the interface). Accessing a MIB variableFunction is initiated by the SNMP agent in response to a request from the NMS. The agent retrieves the value of the requested MIB variable and responds to the NMS with that value. Setting a MIB variableFunction is initiated by the SNMP agent in response to a message from the NMS. The SNMP agent changes the value of the MIB variable to the value requested by the NMS.
System MIB variables are accessible through SNMP as follows:
For a list of all MIBs supported by the CSG2 Release 2, see the MIB Support section on page 1-6.
SNMP Notifications
An SNMP agent can notify the manager when important system events occur, such as the following:

An interface or card starts or stops running Temperature thresholds are crossed Authentication failures occur Logs information about the time, type, and severity of the condition Generates a notification message, which it then sends to a designated IP host
When an agent detects an alarm condition, the agent:

K-2
OL-22840-05
Appendix K
Monitoring Notifications SNMP Overview
SNMP notifications are sent as either:

TrapsUnreliable messages, which do not require receipt acknowledgment from the SNMP manager. InformsReliable messages, which are stored in memory until the SNMP manager issues a response. Informs use more system resources than traps.
Note
Many commands use the word traps in the command syntax. Unless there is an option in the command to select either traps or informs, the keyword traps refers to either traps, informs, or both. Use the snmp-server host command to specify whether to send SNMP notifications as traps or informs.
When an agent detects an alarm condition, it logs information about the time, type, and severity of the condition and generates a notification message, which it then sends to a designated IP host. SNMP notifications can be sent as either traps or informs. See the Enabling SNMP Support section on page K-8 for instructions on how to enable traps on the CSG2. The Cisco implementation of SNMP uses the definitions of SNMP traps described in RFC 1215.
SNMP Versions
Cisco IOS software supports the following versions of SNMP:

SNMPv1The Simple Network Management Protocol: An Internet standard, defined in RFC 1157. Security is based on community strings. SNMPv2cThe community-string based administrative framework for SNMPv2. SNMPv2c is an update of the protocol operations and data types of SNMPv2p (SNMPv2 classic), and uses the community-based security model of SNMPv1. SNMPv3Version 3 of SNMP. SNMPv3 uses the following security features to provide secure access to devices:
Message integrityEnsuring that a packet has not been tampered with in transit. AuthenticationDetermining that the message is from a valid source. EncryptionScrambling the contents of a packet to prevent it from being learned by an
unauthorized source.
SNMPv1 and SNMPv2c

Both SNMPv1 and SNMPv2c use a community-based form of security. The community of managers who are able to access the agent MIB is defined by an IP address Access Control List and password. SNMPv2c support includes a bulk-retrieval mechanism and more detailed error message reporting to management stations. The bulk-retrieval mechanism supports the retrieval of tables and large quantities of information, minimizing the number of round-trip transmissions required. SNMPv2c improved error handling support includes expanded error codes that distinguish different kinds of error conditions; these conditions are reported through a single error code in SNMPv1. Error return codes now report the error type.
K-3
Appendix K SNMP Overview
Three kinds of exceptions are also reported:

no such object exceptions no such instance exceptions end of MIB view exceptions
SNMPv3
SNMPv3 provides the following security models and security levels:

Security modelAuthentication strategy that is set up for a user and the group in which the user resides. Security levelPermitted level of security within a security model.
A combination of a security model and a security level determines the security mechanism to be employed when handling an SNMP packet.
SNMP Security Models and Levels

Table 11-1 describes the security models and levels provided by the different SNMP versions.
Table 11-1 SNMP Security Models and Levels
Model v1 v2c v3 v3
Level noAuthNoPriv noAuthNoPriv noAuthNoPriv authNoPriv
Authentication Community string Community string Username MD5 or SHA
Encryption No No No No
Description Uses match on community string for authentication. Uses match on community string for authentication. Uses match on username for authentication. Provides authentication based on HMAC-MD5 or HMAC-SHA algorithm. Provides authentication based on HMAC-MD5 or HMAC-SHA algorithm. Also provides DES 56-bit encryption based on CBC-DES (DES-56) standard.
v3
authPriv
MD5 or SHA
DES
You must configure the SNMP agent to use the version of SNMP supported by the management station. An agent can communicate with multiple managers; for this reason, you can configure the Cisco IOS software to support communications with one management station using the SNMPv1 protocol, one using the SNMPv2c protocol, and another using SMNPv3.
Requests for Comments

MIB modules are written in the SNMP MIB module language, and are typically defined in Request For Comments (RFC) documents submitted to the Internet Engineering Task Force (IETF). RFCs are written by individuals or groups for consideration by the Internet Society and the Internet community as a whole.
K-4
OL-22840-05
Appendix K
Monitoring Notifications SNMP Overview
Before being given RFC status, recommendations are published as Internet Draft (I-D) documents. RFCs that have become recommended standards are also labeled as standards (STD) documents. For more information, see the Internet Society and IETF websites (http://www.isoc.org and http://www.ietf.org). We provide private MIB extensions with each Cisco system. Cisco enterprise MIBs comply with the guidelines described in the relevant RFCs unless otherwise noted in the documentation.
Object Identifiers
An object identifier (OID) uniquely identifies a MIB object on a managed network device. The OID identifies the MIB objects location in the MIB hierarchy, and provides a means of accessing the MIB object in a network of managed devices:

Standard RFC MIB OIDs are assigned by the Internet Assigned Numbers Authority (IANA) Enterprise MIB OIDs are assigned by Cisco Assigned Numbers Authority (CANA).
Each number in the OID corresponds to a level of MIB hierarchy. For example, the OID 1.3.6.1.4.1.9.9.xyz represents the xyz-MIB whose location in the MIB hierarchy is as follows. Note that the numbers in parentheses are included only to help show correspondence to the MIB hierarchy. In actual use, OIDs are represented as numerical values only. iso(1).org(3).dod(6).internet(1).private(4).enterprises(1).cisco(9).ciscoMgt(9).nn-MIB You can uniquely identify a managed object, such as ifNumber in the IF-MIB, by its object name (iso.org.dod.internet.mgmt.enterprises.interfaces.ifNumber) or by its OID (1.3.6.1.2.1.2.1). For a list of OIDs assigned to MIB objects, go to the following URL: ftp://ftp.cisco.com/pub/mibs/oid/
Related Information and Useful Links

The following URL provides access to general information about Cisco MIBs. Use the links on this page to access MIBs for download, and to access related information (such as application notes and OID listings).
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
TAC Information and FAQs

The following URLs provide access to SNMP information developed by the Cisco Technical Assistance Center (TAC):

http://www.cisco.com/warp/public/477/SNMP/index.html is the Cisco TAC page for SNMP. It provides links to general SNMP information and tips for using SNMP to gather data. http://www.cisco.com/warp/public/477/SNMP/mibs_9226.shtml is a list of frequently asked questions (FAQs) about Cisco MIBs.
SNMP Configuration Information

The following URLs provide information about configuring SNMP:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/fun_c/fcprt3/fcmonitr.htm provides general information about configuring SNMP support. It is part of the Cisco IOS Configuration Fundamentals Configuration Guide.
K-5
Appendix K Configuring MIB Support
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/fun_r/frprt3/frmonitr.htm provides information about SNMP commands. It is part of the Cisco IOS Configuration Fundamentals Command Reference.
Configuring MIB Support

This chapter describes how to configure SNMP and MIB support on a Cisco router. It includes the following sections:

Determining MIBs Included for Cisco IOS Releases, page K-6 Downloading and Compiling MIBs, page K-6 Enabling SNMP Support, page K-8
Determining MIBs Included for Cisco IOS Releases

Follow these steps to determine which MIBs are included in the Cisco IOS release you are using:
Step 1 Step 2
Go to the Feature Navigator home page http://tools.cisco.com/ITDIT/MIBS/servlet/index. Click MIB Locator to launch the application. The MIB Locator application allows you to find a MIB in the following three ways:
a.
By release, platform family, and feature setFrom the MIB Locator page:

Click the drop-down menu and select the desired Cisco IOS software release. From the Platform Family menu, select 7600-SAMI. If you select the platform first, the system displays only those releases and feature sets that apply to the platform you have selected. From the Feature Set menu, select the appropriate CSG2 release.
b. c.
By image nameFrom the MIB Locator page, enter the CSG2 image name you are using in the Search by Image Name field and click Submit. By MIB nameFrom the MIB Locator page, search for the MIB from the list of MIBs in the Search for a MIB menu. You can select one, or for a multiple selection, hold down the CTRL key, then click Submit.
Note
After you make a selection, follow the links and instructions.
Downloading and Compiling MIBs

The following sections provide information about how to download and compile MIBs for the CSG2:

Considerations for Working with MIBs Downloading MIBs Compiling MIBs
K-6
OL-22840-05
Appendix K
Monitoring Notifications Configuring MIB Support
Considerations for Working with MIBs

While working with MIBs, consider the following:
Mismatches on Datatype Definitions
Mismatches on datatype definitions might cause compiler errors or warning messages. Although Cisco MIB datatype definitions are not mismatched, standard RFC MIBs do mismatch. For example:
MIB A defines: SomeDatatype : := INTEGER(0. .100) MIB B defines: SomeDatatype : := INTEGER(1. .50)
This example is considered to be a trivial error and the MIB loads successfully with a warning message. The next example is considered a nontrivial error (even though the two definitions are essentially equivalent), and the MIB is not successfully parsed.
MIB A defines: SomeDatatype : := DisplayString MIB B defines: SomeDatatype : := OCTET STRING (SIZE(0. .255))
If your MIB compiler treats these as errors, or you want to delete the warning messages, edit one of the MIBs that define this same datatype so that the definitions match.
Many MIBs import definitions from other MIBs. If your management application requires MIBs to be loaded, and you experience problems with undefined objects, you might want to load the following MIBs in this order: SNMPv2-SMI.my SNMPv2-TC.my SNMPv2-MIB.my RFC1213-MIB.my IF-MIB.my CISCO-SMI.my CISCO-PRODUCTS-MIB.my CISCO-TC.my
For additional information and SNMP technical tips, from the Locator page, click SNMP MIB Technical Tips and follow the links or go to the following URL: http://www.cisco.com/pcgi-bin/Support/browse/psp_view.pl?p=Internetworking:SNMP&s=Imple mentation_and_Configuration#Samples_and_Tips
For a list of SNMP object identifiers (OIDs) assigned to MIB objects, go to the following URL and click on SNMP Object Navigator and follow the links: http://tools.cisco.com/ITDIT/MIBS/servlet/index
Note
You must have a Cisco CCO name and password to access the MIB Locator. For information about how to download and compile Cisco MIBs, go to the following URL: http://www.cisco.com/warp/public/477/SNMP/mibcompilers.html
K-7
Appendix K Enabling SNMP Support
Downloading MIBs
Follow these steps to download the MIBs onto your system if they are not already there:
Step 1 Step 2
Review the considerations in the previous section (Considerations for Working with MIBs). Go to one of the following Cisco URLs. If the MIB you want to download is not there, try the other URL; otherwise, go to one of the URLs in Step 5.

ftp://ftp.cisco.com/pub/mibs/v2 ftp://ftp.cisco.com/pub/mibs/v1
Click the link for a MIB to download that MIB to your system. Select File > Save or File > Save As to save the MIB on your system. You can download industry-standard MIBs from the following URLs:

http://www.ietf.org http://www.atmforum.com
Compiling MIBs
If you plan to integrate the Cisco router with an SNMP-based management application, then you must also compile the MIBs for that platform. For example, if you are running HP OpenView on a UNIX operating system, you must compile platform MIBs with the HP OpenView Network Management System (NMS). For instructions, see the NMS documentation.
Enabling SNMP Support

The following procedure summarizes how to configure the Cisco router for SNMP support. For detailed information about SNMP commands, see the following Cisco documents:
Cisco IOS Release 12.3 Configuration Fundamentals Configuration Guide, Monitoring the Router and Network section, available at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/ffun_c/index.htm Cisco IOS Release 12.3 Configuration Fundamentals Command Reference, Part 3: System Management Commands, Router and Network Configuration Commands section, available at the the following URL: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/ffun_r/index.htm
To configure the Cisco router for SNMP support, you must set up your basic SNMP configuration through the command line interface (CLI) on the router.
Note
These basic configuration commands are for SNMPv2c. For SNMPv3, you must also set up SNMP users and groups. (See the preceding list of documents for command and setup information.)
K-8
OL-22840-05
Appendix K
Monitoring Notifications Enabling and Disabling SNMP Notifications
Step 1
Define SNMP read-only and read-write communities:

Router (config)# snmp-server community Read_Only_Community_Name ro Router (config)# snmp-server community Read_Write_Community_Name rw
Step 2
Configure SNMP views (to limit the range of objects accessible to different SNMP user groups):
Router (config)# snmp-server view view_name oid-tree {included | excluded}
Enabling and Disabling SNMP Notifications

To enable and disable SNMP Notifications, perform the tasks in the following sections:

Enabling and Disabling CSG2 Notifications via the CLI, page K-9 Enabling and Disabling CSG2 SNMP Notifications via SNMP, page K-10
Enabling and Disabling CSG2 Notifications via the CLI

To use the command line interface (CLI) to enable the Cisco router to send CSG2 SNMP notifications (traps or informs), perform the following steps.
Step 1 Step 2
Make sure SNMP is configured on the router (see the Enabling SNMP Support section on page K-8). Identify (by IP address) the host to receive traps from the Cisco router:
Router(config)# snmp-server host host-address version SNMP version community/user(V3) udp-port <UDP port No>
Step 3
Enable CSG2 SNMP notifications on the Cisco router using the following command (enter a separate command for each type of notification you want to enable):
Router(config)# snmp-server enable traps csg [bma [records | state] | database | quota-server [records | state]]
Where:
bmaEnables traps for only the Billing Mediation Agents (BMAs) to which the CSG2 sends billing records.
recordsEnables only lost records traps for the BMAs. stateEnables only state change traps for the BMAs.
databaseEnables traps for only the database server that answers CSG2 user ID queries. quota-serverEnables traps for only the CSG2 quota servers.
recordsEnables only lost records traps for the quota servers. stateEnables only state change traps for the quota servers.
Note
Entering the snmp-server enable traps csg command without a keyword option enables all CSG2 SNMP notifications.
K-9
Appendix K Enabling and Disabling SNMP Notifications
Step 4
To disable CSG2 SNMP notifications on the Cisco router, enter the following command.
Router(config)# no snmp-server enable traps csg
If you omit the notification type keyword (csg in this example), all notifications are disabled.
Enabling and Disabling CSG2 SNMP Notifications via SNMP

Note
The set operation is not yet valid for these objects. We recommend that you use the CLI to enable and disable CSG2 SNMP notifications. Additionally, CSG2 SNMP Notifications can be enabled or disabled by setting the following objects to true(1) or false(2).

ccsBMAStateChangeNotifEnabledEnables/disables the generation of the Billing Mediation Agent (BMA) state change notification (ciscoContentServicesBMAStateChange) ccsQuotaMgrStateChangeNotifEnabledEnables/disables the generation of the Quota Manager state change notification (ciscoContentServicesQuotaMgrStateChange) ccsUserDbStateChangeNotifEnabledEnables/disables the generation of the User Database Server state change notification (ciscoContentServicesUserDbStateChange) ccsBMALostRecordEventNotifEnabledEnables/disables the generation of the Billing Mediation Agent Lost Reocrd notification (ciscoContentServicesBMALostRecordEvent) ccsQuotaMgrLostRecordEventNotifEnabledEnables/disables the generation of the Quota Manager Lost Record notification (ciscoContentServicesQuotaMgrLostRecordEvent) ccsLicenseKutLimitExceededNotifEnabledEnables/disables the generation of the License KUT Limit Exceeded state change notification (ciscoContentServicesLicenseKutLimitExceeded)
K-10
OL-22840-05

CSG2 Rel5

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

CSG2 Rel5

Enviado por

Direitos autorais:

Formatos disponíveis

Cisco Content Services Gateway 2nd Generation Release 5.

0 Installation and Configuration Guide

Text Part Number: OL-22840-05

Configuring the CSG2

Saving and Restoring CSG2 Configurations

Configuring BMA Support Configuring a BMA

Configuring the BMA Local Port

Configuring the BMA GTP Message Buffer

Reporting the Billing Plan ID to the BMA

Configuring Quota Server Support Configuring a Quota Server

Configuring the Quota Server Local Port

Configuring the Quota Server GTP Message Buffer

Replacing Quota Balance Asynchronous Quota Return

Delaying Quota Reauthorization

Reducing the Number of Services Configuration Example

Configuring Service Support

5-1 5-2 5-2

Configuring a Service Idle Time Configuring a Service Lifetime

Support for eG-CDRs with GGSN

Enabling a Refund Policy for a Service Configuring Content Access Control

Configuring IPC Support

6-1 6-1 6-1 6-2 6-2

Configuring PSD Support Configuring the PSD

Configuring the PSD Local Port

Configuring the PSD GTP Message Buffer

Configuring iSCSI Support iSCSI Overview

9-1 9-2 9-3 9-4 9-4 9-6

Configuring RADIUS Packet of Disconnect Configuring RADIUS Monitor

Configuring RADIUS Change of Authorization

10-1 10-3 10-3 10-5

Enabling Gx on the CSG2 Configuring a User Profile

Cisco 7600 LTE Integration

Volume and Duration Triggers Service Flow Detection Triggers

Per-Subscriber Volume and Time Thresholds

Gx Event Trigger Usage Reporting Gx Service Groups

Billing Plan Assignment and Modification PDP Context QoS Signaling

Secondary PDP Context Activation PCRF Failure Handling Restrictions for Gx

Configuring Prepaid Support

12-1 12-1 12-2

Configuring a Postpaid Service for a Prepaid Billing Plan

Configuring Mobile PCC Support Per-User PCC

Handling Redundancy in PCC

CSG2 Command Reference

CSG Background Configuration Statistics

CSG IPv6 Fragment Statistics

CSG Distributed User Table Statistics

CSG Session Statistics

GTP Application: CSG IPC, Local Port: 0

DNS IP Map Table Stats

Changes to Module CSG VLAN Configuration Mode

C-13 C-13 C-14 C-14 C-14

Layer 7 Inspection (parse protocol=specific protocol)

CSG2 System Messages CSG2 System Messages

About This Book

Document Revision History

Added the following features:

About This Book

Date May 24, 2010

Change Summary Added the following features:

May 24, 2010

About This Book

About This Book