Cisco Content Services Gateway - 2nd Generation Release 2.0 Installation and Configuration Guide, for Cisco IOS Release 12.4(15)MD - Configuring the CSG2 [Cisco Content Services Gateway]

Table Of Contents

Configuring the CSG2

Preparing to Install the CSG2 Software

Installing the CSG2 Software

Upgrading the CSG2 Software

Saving and Restoring CSG2 Configurations

Configuring the CSG2

Configuring the User Database

Configuring the CSG2 User Table

Configuring the Fragment Database

Configuring the Session Table

Configuring URL-Redirect

Configuring Policies and Traffic Types

Configuring a Content Billing Service

Configuring Content

Configuring Single-TP Mode

Configuring Fixed, Variable, or Combined Format CDR Support

Fixed CDR Support for HTTP and WAP

Fixed CDR Support for IMAP

Fixed CDR Support for RTSP

Single CDR Support for HTTP and WAP

Specifying the CDR Format

Configuring a Refund Policy on the CSG2

Configuring HTTP Header Reporting

Configuring SMTP CDR Header Removal

Configuring Supplemental Usage Reporting

Configuring Actual PDU Reporting for WAP

Configuring Maps for Pattern-Matching

Configuring Connection Redundancy

Configuring High Availability

Components That Provide HA

Enabling HA

Configuring a Secondary IP Address for HA

Synchronizing Clocks for HA

Modifying an HA Configuration

Distributed Crash Data Collection

Configuring HA for CSG2s in Different Chassis

Classifying Data Traffic

Configuring a CSG2 Subscriber Interface

Configuring Case Sensitivity

Configuring WAP and WSP Support

Counting Bytes and Packets

Incomplete WAP Transactions

Multimedia Messaging Service

Blocking Ports

Configuring SNMP Timers

Configuring the SAMI Bit Rate Limit

Configuring the SNMP Notification Types

CSG2 Configuration Examples

Sample Configuration for Subscriber-to-Subscriber Traffic

Configuring Next-Hop for a Subscriber-to-Subscriber Content

Configuring Reverse Next-Hop for a Subscriber-to-Subscriber Content

Configuring Prepaid Subscriber-to-Subscriber Contents for a Service

Sample Configuration for HTTP X-Forwarded-For

Sample Configuration for High Availability

HA Configuration on the Active CSG2

HA Configuration on the Standby CSG2

Sample Configuration for HA Peer Connectivity

Sample Configuration for Supervisor Engine Side 1

Sample Configuration for CSG2 Side 1

Sample Configuration for Supervisor Engine Side 2

Sample Configuration for CSG2 Side 2

Displaying Port-Channel Information for One Side

Configuring CSG2 Network/Subscriber Traffic

Configuring the CSG2

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

•Preparing to Install the CSG2 Software

•Installing the CSG2 Software

•Upgrading the CSG2 Software

•Saving and Restoring CSG2 Configurations

•Configuring the CSG2

•CSG2 Configuration Examples

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 Supervisor Engines:

–Supervisor Engine 720 with an MSFC3-BXL (SUP720-MSFC3-BXL) running Cisco IOS Release 12.2(33)SRB1 or later.

–Cisco 7600 Series Supervisor Engine 32, with a Multilayer Switch Feature Card, running Cisco IOS Release 12.2(33)SRC or later and LCP ROMMON Version 12.2[121] or later

–Cisco Route Switch Processor 720 with Distributed Forwarding Card DFC3CXL, 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 Service and Application Module for IP (SAMI), and before running or upgrading the CSG2 on the 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). 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.

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

Step 4 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]]
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 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:

•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.

Step 9 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 mask
where:

•ip-address is the primary IP address.

•mask is the CSG2 mask for the associated IP subnet.

Step 12 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 mask secondary
where:

•ip-address is the secondary IP address.

•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]
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.

•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.

Step 15 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:

•x is the slot in which the Supervisor Engine is installed.

•y identifies the Supervisor Engine—1 for Supervisor Engine 720.

Step 16 Establish a static route for traffic to the CSG2, by entering the following command in global configuration mode:
csg2(config)# ip route prefix mask ip-address
where:

•prefix is the IP route prefix for the destination.

•mask is the prefix mask for the destination.

•ip-address is the IP address of the next hop that can be used to reach that network.

Step 17 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.

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 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:

•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.

Step 3 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
For more information about saving and restoring configurations, see the Cisco 7600 Series Cisco IOS Software Configuration Guide.

Configuring the CSG2

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

•Configuring the CSG2 User Table

•Configuring the Fragment Database

•Configuring the Session Table

•Configuring URL-Redirect

•Configuring Policies and Traffic Types

•Configuring a Content Billing Service

•Configuring Content

•Configuring Single-TP Mode

•Configuring Fixed, Variable, or Combined Format CDR Support

•Configuring a Refund Policy on the CSG2

•Configuring HTTP Header Reporting

•Configuring SMTP CDR Header Removal

•Configuring Supplemental Usage Reporting

•Configuring Actual PDU Reporting for WAP

•Configuring Maps for Pattern-Matching

•Configuring Connection Redundancy

•Configuring High Availability

•Classifying Data Traffic

•Configuring a CSG2 Subscriber Interface

•Configuring Case Sensitivity

•Configuring WAP and WSP Support

•Blocking Ports

•Configuring SNMP Timers

•Configuring the SAMI Bit Rate Limit

•Configuring the SNMP Notification Types

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

Purpose
csg2(config)# ip csg database 
[vrf vrf-name] ip-address 
port-number local-port
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.
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.

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. If the User Table contains an entry with a matching source IP address, the CSG2 uses that entry for charging and for CDR generation.

2. 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.

3. 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.

4. 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.

To configure the User Table, enter the following command in global configuration mode:
Command

Purpose
csg2(config)# ip csg entries user profile 
{quota-server | radius {pass | remove | 
timeout timeout}}
Specifies the location from which the CSG2 is to obtain the subscriber profile and billing plan when generating entries for the User Table.
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.

To set a global User Table idle timer, enter the following command in global configuration mode:
Command

Purpose
csg2(config)# ip csg entries user idle duration [pod]
(Optional) 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

Purpose
csg2(config-csg-billing)# entries user idle duration [pod]
(Optional) 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

Purpose
csg2(config)# ip csg entries user max entries
(Optional) 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

Purpose
csg2(config)# ip csg entries fragment 
{idle duration | maximum entries-number}
(Optional) 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.

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

Purpose
csg2(config)# ip csg entries session user max entries
(Optional) 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 subscriber's 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 subscriber's quota is exhausted.

•The ip csg redirect sip command redirects subscriber SIP flows to the specified alternate URL when the subscriber's 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 subscriber's quota is exhausted.

For example, if all of the following conditions are met:

•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.

•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 subscriber's 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

Purpose
csg2(config)# ip csg redirect {http url | 
interval seconds | maximum number | sip url | 
wap url}
(Optional) Redirects subscriber flows to an alternate IP address when the subscriber's 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

Purpose
Step 1
csg2(config)# ip csg policy policy-name
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)# map map-name
References a header, method, or URL map that is part of a CSG2 billing policy.

The conditions specified in the referenced 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.
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 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.

If the content configuration does not match any service listed under a subscriber's billing plan, the CSG2 considers the service to be either free or postpaid, and the CSG2 does not try to authorize the subscriber with the quota server.

To configure content for a CSG2 accounting service, enter the following commands beginning in global configuration mode:
Command

Purpose
Step 1
csg2(config)# ip csg content content-name
Configures content for CSG2 accounting services, and enters CSG2 content configuration mode.
Step 2
csg2(config-csg-content)# client-group 
{std-access-list-number | std-access-list-name}
References a standard access list that is part of a CSG2 content.
Step 3
csg2(config-csg-content)# ip 
{any | ip-address [netmask]} 
[any | protocol [port-number [last-port-number]]]
Defines the subset of Layer 3 and Layer 4 flows that can be processed by the CSG2 accounting services.

You can define port-number as a single value or as a range of numbers.
Step 4
csg2(config-csg-content)# parse protocol 
{ftp | http | imap | other | pop3 | rtsp | sip | 
smtp | 
wap {connection-oriented | connectionless}}
Defines how the CSG2 is to parse traffic for a content.
Step 5
csg2(config-csg-content)# policy policy-name 
[priority priority-number]
References a CSG2 billing policy.
Step 6
csg2(config-csg-content)# mode tcp 
{datagram | transparent [zero]}
(Optional) Specifies the mode for CSG2 TCP sessions.
Step 7
csg2(config-csg-content)# next-hop ip-address 
[reverse] [subscriber media]
(Optional) Defines a next-hop IP address.

Note You can configure one forward next-hop, and one reverse next-hop.

Even if you have defined a next-hop IP address, traffic that matches the "default" content might not be routed with next-hop.

If you specify the subscriber media keywords, this command defines the IP address of the next hop for Session Initiation Protocol (SIP) media sessions (used for subscriber-to-subscriber traffic).
Step 8
csg2(config-csg-content)# block
(Optional) Forces the CSG2 to drop packets that do not match a configured billing policy.
Step 9
csg2(config-csg-content)# idle duration
(Optional) Specifies the minimum amount of time that the CSG2 maintains an idle content connection.
Step 10
csg2(config-csg-content)# parse length number
(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 is also configured.
Step 11
csg2(config-csg-content)# pending timeout
(Optional) Sets the pending connection timeout.
Step 12
csg2(config-csg-content)# records delay seconds
(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 13
csg2(config-csg-content)# records intermediate 
{bytes bytes | seconds seconds | 
bytes bytes seconds seconds}
(Optional) Enables the generation of intermediate billing records.

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 billing records.
Step 14
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 RTSP 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 15
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.
Step 16
csg2(config-csg-content)# vlan vlan-number
(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 17
csg2(config-csg-content)# vrf vrf-name
(Optional) Restricts the CSG2 content to packets within a single Virtual Routing and Forwarding (VRF) table.
Step 18
csg2(config-csg-content)# inservice
Activates the content service on each CSG2.
Configuring Single-TP Mode

In normal multiple-TP mode, the CSG2 distributes subscriber traffic among all of the TPs, based on each subscriber's 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

Purpose
csg2(config)# ip csg mode single-tp
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.

This section contains the following information:

•Fixed CDR Support for HTTP and WAP

•Fixed CDR Support for IMAP

•Fixed CDR Support for RTSP

•Single CDR Support for HTTP and WAP

•Specifying the CDR Format

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

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.

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

Purpose
csg2(config)# ip csg records format 
[fixed | variable [combined {http | wap}]]
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

Purpose
Step 1
csg2(config)# ip csg refund
(Optional) Specifies a refund policy to apply to the various services, and enters CSG2 refund configuration mode.
Step 2
csg2(config-csg-refund)# retcode 
{ftp | http | imap | pop3 | sip | smtp | wap}
rc-start [rc-end]
(Optional) Specifies the range of application return codes for which the CSG2 refunds quota for Prepaid Error Reimbursement. The return codes are protocol-specific.
Step 3
csg2(config-csg-refund)# flags 
{ip mask| tcp mask| wap} value
(Optional) Specifies IP, TCP, or wireless application protocol (WAP) flag bit masks and values for CSG2 Prepaid Error Reimbursement.
For information about enabling a refund policy for a service, see the "Enabling a Refund Policy for a Service" section on page 5-18.

Configuring HTTP Header Reporting

The CSG2 allows you to include multiple HTTP request headers in the CSG2 HTTP_Header CDR.

To define HTTP reporting on the CSG2, enter the following command in global configuration mode:
Command

Purpose
csg2(config)# ip csg report http header x-header
(Optional) 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-Priority¹

•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

Purpose
csg2(config)# ip csg report smtp rfc2822
(Optional) 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
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

Purpose
csg2(config)# ip csg report usage 
{bytes ip | seconds}
(Optional) 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

Purpose
csg2(config)# ip csg report wap actual-pdu
(Optional) Specifies whether actual PDUs are to be reported in CSG2 WAP CDRs.
Configuring Maps for Pattern-Matching

The CSG2 maps are used to match URLs or headers against a pattern, to determine whether flows will be processed by the CSG2 accounting services.

To define the CSG2 billing content filters (URL maps and header maps), follow these steps:
Command

Purpose
Step 1
csg2(config)# ip csg map map-name
(Optional) Defines the CSG2 billing content filters (header, method, and URL maps), and enters CSG2 map configuration mode.
Step 2
csg2(config-csg-map)# match header 
header-name value
(Optional) Specifies a header match pattern for a CSG2 billing map.
Step 3
csg2(config-csg-map)# match method 
method-name
(Optional) Specifies a method match pattern for a CSG2 billing map.
Step 4
csg2(config-csg-map)# match url pattern
(Optional) Specifies a URL match pattern for a CSG2 billing map.
Note For WAP, the CSG2 supports only URL maps. Header maps and method maps are not supported.

For more information, including how to specify match patterns and how the CSG2 matches those patterns, see the descriptions of the map, match header, match method, and match url 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.

For high availability (HA), keep the following consideration in mind:

•When CSG2s are firewall 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 device's perspective) when a switchover occurs.

•HA does not support the use of the standby preempt command in interface configuration mode.

•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 CSG2—now 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.

This section contains the following information:

•Components That Provide HA

•Enabling HA

•Configuring a Secondary IP Address for HA

•Synchronizing Clocks for HA

•Modifying an HA Configuration

•Distributed Crash Data Collection

•Configuring HA for CSG2s in Different Chassis

Components That Provide HA

Table 2-1 lists the components that interact to provide CSG2 HA.

Table 2-1 Components That Provide HA

Component

Description

Redundancy Facility (RF)

IOS redundancy facility used to coordinate active and standby HA systems and their state progressions.

RF for Interdevice redundancy (RF Interdev)

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.

Hot Standby Routing Protocol (HSRP)

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.

Stream Control Transmission Protocol (SCTP)

Reliable communications protocol used by RF Interdev for messaging between systems.

CSG2 Internet Exchange Point (IXP)

Classifies ingress packets for delivery to the correct SAMI processor, and directs CSG2 HA stateful messages to the six TPs based on the destination port of the inbound messages.

CSG2 Demultiplexor

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.

CSG2 HA—RF Interface

RF client that listens for state transition signals and instructions to bulk_sync (dump the CSG2 state table to the remote system).

CSG2 HA—Messaging

Handles the dump process on the CSG2 and maps incoming messages to the correct receiver routine in other CSG2 HA-aware components.

CSG2 HA—HA-Aware Components

CSG2 software that sends or receives HA messages through the CSG2 HA component.

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

To enable HA state replication between redundant CSG2 systems, enter the following command in global configuration mode:
Command

Purpose
csg2(config)# ip csg replicate [vrf vrf-name] 
local-ip remote-ip base-port
(Optional) Enables HA state replication between redundant CSG2 systems.
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.

•To synchronize the CSG2 clocks, configure the Cisco Network Time Protocol (NTP) on each 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 SAMI, and ensure that the timestamps are identical.

•To display the clock timestamps for all of the 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:
csg2(config)# write memory
Step 3 Reload the CSG2:
Router# reload
Step 4 Modify the CSG2 configuration.

Step 5 Reconfigure the standby scheme configured in inter-device configuration mode, if necessary.

Step 6 Save the configuration changes to memory again:
csg2(config)# write memory
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

•Debugging information from all of the non-failed processors

The processors use the following format when creating the crash and debugging information files:

designator_processornumber_timestamp

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 CSG2's Line Card Processor (LCP) collects each TP's 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.

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

Purpose
csg2(config)# ip csg transport-type assign 
ip-address value
(Optional) 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

Purpose
Router# ip csg subscriber
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 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

Purpose
Router# ip csg case-sensitive
(Optional) Specifies whether the CSG2 is to treat header, method, and URL match patterns as case-sensitive.
To disable case-sensitivity for CSG2 match patterns, enter the following command in global configuration mode:
Command

Purpose
Router# no ip csg case-sensitive
(Optional) Specifies that the CSG2 is to treat 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

•Incomplete WAP Transactions

•Multimedia Messaging Service

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.

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 7070
 next-hop 10.10.10.1
 policy RTSP-BLOCK
 inservice
!
ip csg content BLOCK80
 ip 1.1.1.0 255.255.255.0 tcp 80
 next-hop 10.10.10.1
 policy RTSP-BLOCK
 inservice
!
ip csg content BLOCK8080
 ip 1.1.1.0 255.255.255.0 tcp 8080
 next-hop 10.10.10.1
 policy RTSP-BLOCK
 inservice
!
ip csg content RTSPCONTSERVER
 ip 1.1.1.0 255.255.255.0 tcp 554
 idle 50
 replicate
 policy RTSP
 inservice
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

Purpose
csg2(config)# ip csg snmp timer 
{bma | psd | quota-server} [interval]
(Optional) Defines Simple Network Management Protocol (SNMP) timers for lost CSG2 records.
Configuring the SAMI Bit Rate Limit

To specify the bit rate limit to be used by the Service and Application Module for IP (SAMI) for each PowerPC's (PPC's) traffic, enter the following command in global configuration mode:
Command

Purpose
csg2(config)# sami rate bits-per-second all
(Optional) Specifies the bit rate limit to be used by the SAMI for each PPC's 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

Purpose
csg2(config)# snmp-server enable traps csg 
[bma [records | state] | database | 
quota-server [records | state]]
(Optional) Enables SNMP notification types that are available on the CSG2.
CSG2 Configuration Examples

This section provides the following sample configurations for CSG2:

•Sample Configuration for Subscriber-to-Subscriber Traffic

•Sample Configuration for HTTP X-Forwarded-For

•Sample Configuration for High Availability

•Sample Configuration for HA Peer Connectivity

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.

•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.

where:

•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 subscriber's 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.

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.

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:
ip csg content SUB-TO-SUB
 ip 11.0.0.0 255.0.0.0 any
 next-hop 10.5.1.100
 policy ANY-MS
 vlan 301
 inservice
When configuring the next-hop configuration, keep the following considerations in mind:

•The next-hop configuration applies to traffic that flows in the same direction as the packet that initiates the session.

•In this example, VLAN 301 is a subscriber-side VLAN.

•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 Reverse Next-Hop for a Subscriber-to-Subscriber Content

On each CSG2 that handles subscriber-to-subscriber traffic, you must configure reverse subscriber-to-subscriber content using the next-hop reverse command:
ip csg content REV-SUB-TO-SUB
 ip 11.0.0.0 255.0.0.0 any
 next-hop 10.5.1.100 reverse
 policy ANY-MS
 vlan 501
 inservice
When configuring the next-hop configuration, keep the following considerations in mind:

•The next-hop reverse configuration applies to traffic that flows in the opposite direction of the packet that initiates the session. For example, if the session is initiated by a packet arriving in the network-to-subscriber direction, the next-hop reverse configuration applies to packets received on a subscriber interface.

•In this example, VLAN 501 is a network-side VLAN.

•Configure the IP address of the Supervisor Engine in which the CSG2 is installed as the next-hop reverse 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 reverse IP address.

•We recommend that you configure the next-hop reverse command for any contents that handle sessions that are initiated in the server-to-client direction, including subscriber-to-subscriber sessions, peer-to-peer sessions, and network-to-mobile or application-to-mobile sessions.

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 REV-SUB-TO-SUB policy ANY-MS
 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
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

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
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).

This section includes the following information"

•Sample Configuration for Supervisor Engine Side 1

•Sample Configuration for CSG2 Side 1

•Sample Configuration for Supervisor Engine Side 2

•Sample Configuration for CSG2 Side 2

•Displaying Port-Channel Information for One Side

•Configuring CSG2 Network/Subscriber Traffic

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

¹Presence of this header depends on the contents of the SMTP header.