Table Of Contents
Release Notes for Cisco Content Services Gateway 3.1(3)C6(12) for Cisco IOS Release 12.2(18)SXE
CSG Features Introduced Prior to CSG R4.1
CSG Features Introduced in CSG R4.1—3.1(3)C4(1)
CSG Feature Introduced in CSG R4.8—3.1(3)C4(8)
CSG Feature Introduced in CSG R4.9—3.1(3)C4(9)
CSG Features Introduced in CSG R5.1—3.1(3)C5(1)
CSG Feature Introduced in CSG R5.2—3.1(3)C5(2)
CSG Feature Introduced in CSG R5.3—3.1(3)C5(3)
CSG Feature Introduced in CSG R5.4—3.1(3)C5(4)
CSG Features Introduced in CSG R5.5—3.1(3)C5(5)
CSG Features Introduced in CSG R6.2—3.1(3)C6(2)
CSG Features Introduced in CSG R6.3—3.1(3)C6(3)
CSG Features Introduced in CSG R6.9—3.1(3)C6(9)
Determining the Software Version
Upgrading to a New CSG Release
Saving and Restoring Configurations
Additional Installation Instructions
CSG Release 3.1(3)C6(12) - Open Caveats
CSG Release 3.1(3)C6(12) - Closed Caveats
CSG Release 3.1(3)C6(11) - Open Caveats
CSG Release 3.1(3)C6(11) - Closed Caveats
CSG Release 3.1(3)C6(10) - Open Caveats
CSG Release 3.1(3)C6(10) - Closed Caveats
CSG Release 3.1(3)C6(9) - Open Caveats
CSG Release 3.1(3)C6(9) - Closed Caveats
CSG Release 3.1(3)C6(8) - Open Caveats
CSG Release 3.1(3)C6(8) - Closed Caveats
CSG Release 3.1(3)C6(7) - Open Caveats
CSG Release 3.1(3)C6(7) - Closed Caveats
CSG Release 3.1(3)C6(6) - Open Caveats
CSG Release 3.1(3)C6(6) - Closed Caveats
CSG Release 3.1(3)C6(5) - Open Caveats
CSG Release 3.1(3)C6(5) - Closed Caveats
CSG Release 3.1(3)C6(4) - Open Caveats
CSG Release 3.1(3)C6(4) - Closed Caveats
CSG Release 3.1(3)C6(3) - Open Caveats
CSG Release 3.1(3)C6(3) - Closed Caveats
CSG Release 3.1(3)C6(2) - Open Caveats
CSG Release 3.1(3)C6(2) - Closed Caveats
Documentation and Technical Assistance
Obtaining Documentation, Obtaining Support, and Security Guidelines
Release Notes for Cisco Content Services Gateway 3.1(3)C6(12) for Cisco IOS Release 12.2(18)SXE
Revised: November 11, 2008
Current Release—3.1(3)C6(12)
This publication describes the requirements, dependencies, and caveats for the Cisco Content Services Gateway (CSG) Release 3.1(3)C6(12).
Contents
•
Upgrading to a New CSG Release
•
•
•
•
Introduction
The CSG is a high-speed processing module that brings content billing and user awareness to the Cisco Catalyst® 6500 series switch and Cisco 7600 series router platforms. The CSG is typically located at the edge of a network in an ISP POP, or Regional Data Center.
Features
This section lists the CSG features, the CSG release in which the feature was introduced, and the minimum CSG release required to support the feature. For full descriptions of all of these features, see the Cisco Content Services Gateway Installation and Configuration Guide, Release 3.1(3)C6(2).
To see the software part numbers associated with each CSG release; the Supervisor hardware required by each CSG release; the minimum Cisco IOS release required for new features in each CSG release, the minimum CatOS/Hybrid level supported by each CSG release; and the minimum IOS level supported by each CSG release, see the "Software Requirements" section.
•
•
•
•
•
•
•
•
•
•
•
•
CSG Features Introduced Prior to CSG R4.1
The following features were introduced Prior to CSG R4.1:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
CSG Features Introduced in CSG R4.1—3.1(3)C4(1)
The following features were introduced in CSG R4.1, and require IOS release 12.2(14)ZA1 or later:
•
•
•
•
The following features were introduced in CSG R4.1, and require IOS release 12.2(14)ZA2 or later:
•
•
•
•
•
•
•
•
Note
CSG Feature Introduced in CSG R4.8—3.1(3)C4(8)
The following feature was introduced in CSG R4.8, and requires IOS release 12.2(14)ZA2 or later:
•
Note
CSG Feature Introduced in CSG R4.9—3.1(3)C4(9)
The following feature was introduced in CSG R4.9, and requires IOS release 12.2(14)ZA2 or later:
•
Note
CSG Features Introduced in CSG R5.1—3.1(3)C5(1)
The following features were introduced in CSG R5.1, and require IOS release 12.2(17d)SXB or later:
•
–
–
Note
•
•
•
•
•
•
•
•
•
•
•
•
•
CSG Feature Introduced in CSG R5.2—3.1(3)C5(2)
The following feature was introduced in CSG R5.2, and requires IOS release 12.2(17d)SXB or later:
•
CSG Feature Introduced in CSG R5.3—3.1(3)C5(3)
The following feature was introduced in CSG R5.3, and requires IOS release 12.2(18)SXD1 or later:
•
CSG Feature Introduced in CSG R5.4—3.1(3)C5(4)
The following feature was introduced in CSG R5.4, and requires IOS release 12.2(18)SXD1 or later:
•
CSG Features Introduced in CSG R5.5—3.1(3)C5(5)
The following features were introduced in CSG R5.5, and require IOS release 12.2(18)SXD1 or later:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
CSG Features Introduced in CSG R6.2—3.1(3)C6(2)
The following features were introduced in CSG R6.2, and require IOS release 12.2(18)SXE or later:
•
•
•
•
•
•
•
•
•
•
•
•
CSG Features Introduced in CSG R6.3—3.1(3)C6(3)
The following feature was introduced in CSG R6.3, and requires IOS release 12.2(18)SXE or later:
•
CSG Features Introduced in CSG R6.9—3.1(3)C6(9)
The following feature was introduced in CSG R6.9, and requires IOS release 12.2(18)SXE or later:
•
System Requirements
This section describes the following memory, hardware, and software requirements for CSG:
•
Memory Requirements
The CSG memory is not configurable.
Hardware Supported
Use of the CSG requires one of the following platforms:
•
•
•
The WS-SVC-CSG-1 CSG is not fabric-enabled, but the module can operate in a fabric-enabled chassis like any other non-fabric-enabled module.
Caution
Power Supply
The CSG operates on power supplied by the chassis. Therefore, you can place the CSG in any slot in the Catalyst 6500 series switch or Cisco 7600 series router chassis, except those occupied by the supervisor engine and the standby supervisor engine.
Environmental Requirements
The following table lists the environmental requirements for the CSG:
Software Requirements
The following table lists the software part numbers for each CSG release; the Supervisor hardware required by each CSG release; the minimum Cisco IOS release required for new features in each CSG release, the minimum CatOS/Hybrid level supported by each CSG release; and the minimum IOS level supported by each CSG release:
3.1(3)C6(12)
SC-SVC-CSG-B-6.0
SC-SVC-CSG-P-6.0SUP720-MSFC3-BXL SUP2-MSFC2
12.2(18)SXE
7.6.1
12.2(18)SXD
3.1(3)C6(11)
SC-SVC-CSG-B-6.0
SC-SVC-CSG-P-6.0SUP720-MSFC3-BXL SUP2-MSFC2
12.2(18)SXE
7.6.1
12.2(18)SXD
3.1(3)C6(10)
SC-SVC-CSG-B-6.0
SC-SVC-CSG-P-6.0SUP720-MSFC3-BXL SUP2-MSFC2
12.2(18)SXE
7.6.1
12.2(18)SXD
3.1(3)C6(9)
SC-SVC-CSG-B-6.0
SC-SVC-CSG-P-6.0SUP720-MSFC3-BXL SUP2-MSFC2
12.2(18)SXE
7.6.1
12.2(18)SXD
3.1(3)C6(8)
SC-SVC-CSG-B-6.0
SC-SVC-CSG-P-6.0SUP720-MSFC3-BXL SUP2-MSFC2
12.2(18)SXE
7.6.1
12.2(18)SXD
3.1(3)C6(7)
SC-SVC-CSG-B-6.0
SC-SVC-CSG-P-6.0SUP720-MSFC3-BXL SUP2-MSFC2
12.2(18)SXE
7.6.1
12.2(18)SXD
3.1(3)C6(6)
SC-SVC-CSG-B-6.0
SC-SVC-CSG-P-6.0SUP720-MSFC3-BXL SUP2-MSFC2
12.2(18)SXE
7.6.1
12.2(18)SXD
3.1(3)C6(5)
SC-SVC-CSG-B-6.0
SC-SVC-CSG-P-6.0SUP720-MSFC3-BXL SUP2-MSFC2
12.2(18)SXE
7.6.1
12.2(18)SXD
3.1(3)C6(4)
SC-SVC-CSG-B-6.0
SC-SVC-CSG-P-6.0SUP720-MSFC3-BXL SUP2-MSFC2
12.2(18)SXE
7.6.1
12.2(18)SXD
3.1(3)C6(3)
SC-SVC-CSG-B-6.0
SC-SVC-CSG-P-6.0SUP720-MSFC3-BXL SUP2-MSFC2
12.2(18)SXE
7.6.1
12.2(18)SXD
3.1(3)C6(2)
SC-SVC-CSG-B-6.0
SC-SVC-CSG-P-6.0SUP720-MSFC3-BXL SUP2-MSFC2
12.2(18)SXE
7.6.1
12.2(18)SXD
3.1(3)C5(6)
SC-SVC-CSG-B-5.0
SC-SVC-CSG-P-5.0SUP720-MSFC3-BXL SUP2-MSFC2
12.2(18)SXD
7.6.1
SUP720: 12.2(18)SXD1
SUP2: 12.2(17b)SXB
1 Do not use the minimums listed in this table to infer supervisor hardware support. Consult the Cisco IOS Upgrade Planner to determine which IOS releases support the desired supervisor hardware.
2 If running Hybrid, make sure the appropriate IOS Hybrid image is available at this level.
3 The feature set is limited to those features that can be configured at this IOS level.
The following table lists the supported hardware and software for the CSG:
When using the CSG with some IOS images, you might see the following warning message:
%PM_SCP-SP-4-UNK_OPCODE: Received unknown unsolicited message from module n, opcode 0x330
You can ignore this message.
Determining the Software Version
To determine the version of Cisco IOS software that is currently running on your Cisco network device, log in to the device and enter the show version EXEC command.
To show CSG versions, use the show module command in privileged EXEC mode.
To provide meaningful problem determination information, use the show tech-support command in privileged EXEC mode.
Upgrading to a New CSG Release
For the latest upgrade procedures for the CSG, see the "Configuring the Content Services Gateway" chapter of the Cisco Content Services Gateway Installation and Configuration Guide.
Saving and Restoring Configurations
For information about saving and restoring configurations, see the Catalyst 6000 Family IOS Software Configuration Guide or to the Cisco 7600 Series Cisco IOS Software Configuration Guide.
Additional Installation Instructions
For more information about installing the CSG, see the Cisco Content Services Gateway Installation and Configuration Guide.
Dependencies and Restrictions
For the latest dependencies and restrictions for the CSG, see the "Overview" chapter of the Cisco Content Services Gateway Installation and Configuration Guide.
Caveats for 3.1(3)C6(12)
This section lists and describes all caveats, both open and resolved, that affect CSG software release 3.1(3)C6(12).
For information about open or unresolved caveats in the Content Services Gateway 3.1(3)C6(12) release, refer to the Cisco Bug Toolkit at the following URL:
http://www.cisco.com/pcgi-bin/Support/Bugtool/home.pl.
CSG Release 3.1(3)C6(12) - Open Caveats
The following list identifies open caveats in CSG Release 3.1(3)C6(12).
•
The CSG might report a negative value for Total Usage in a Service Stop.
For this problem to occur, all of the following conditions must be met:
–
–
Workaround: Clear the affected user.
•
When handling prepaid, if the quota server returns a disconnect, the CSG sends a PoD too early.
Workaround: None.
•
When memory usage reaches 8k, the CSG crashes as a result of a stack overflow.
Workaround: None.
CSG Release 3.1(3)C6(12) - Closed Caveats
The following section lists bugs that are closed in CSG Release 3.1(3)C6(12).
•
When WAP 1.x/WSP traffic matches a content and policy with accounting type wap, the WAP concatenation packet might be dropped.
For this problem to occur, all of the following conditions must be met:
–
–
–
–
•
When the usage for a transaction is greater than 2147483647 quadrans, the CSG might report a negative value for quadrans in the BMA CDR.
•
The CSG might block traffic that should match the default policy under a content, even if the ip csg block command is not configured. This problem can occur if the client command is configured and then unconfigured for a content and traffic is sent that does not match any of the configured policies for the content.
•
When memory usage reaches 8k, the CSG crashes as a result of a stack overflow.
Caveats for 3.1(3)C6(11)
This section lists and describes all caveats, both open and resolved, that affect CSG software release 3.1(3)C6(11).
For information about open or unresolved caveats in the Content Services Gateway 3.1(3)C6(11) release, refer to the Cisco Bug Toolkit at the following URL:
http://www.cisco.com/pcgi-bin/Support/Bugtool/home.pl.
CSG Release 3.1(3)C6(11) - Open Caveats
The following list identifies open caveats in CSG Release 3.1(3)C6(11).
•
When WAP 1.x/WSP traffic matches a content and policy with accounting type wap, the WAP concatenation packet might be dropped.
For this problem to occur, all of the following conditions must be met:
–
–
–
–
Workaround: Configure Layer 4 billing for this content.
•
When the usage for a transaction is greater than 2147483647 quadrans, the CSG might report a negative value for quadrans in the BMA CDR.
Workaround: Clear the affected user.
•
The CSG might report a negative value for Total Usage in a Service Stop.
For this problem to occur, all of the following conditions must be met:
–
–
Workaround: Clear the affected user.
•
The CSG might block traffic that should match the default policy under a content, even if the ip csg block command is not configured. This problem can occur if the client command is configured and then unconfigured for a content and traffic is sent that does not match any of the configured policies for the content.
Workaround: There are several different workarounds:
–
Removing the content removes all of the content policy pairs that use the content from all associated services, so when you reconfigure the content you must also add the content policy pairs to all associated services.
Removing the content also removes it from any associated rulesets, so you must add the reconfigured content to those rulesets, too.
–
For example, for HTTP traffic you can configure a catch-all policy with accounting type http for a content, such that all traffic that does not match any of the other configured policies for that content matches the catch-all policy and generates BMA CDRs.
–
CSG Release 3.1(3)C6(11) - Closed Caveats
The following section lists bugs that are closed in CSG Release 3.1(3)C6(11).
•
The CSG closes all open sessions during a Reauthorization Delay (RD) "wait" state (that is, action code = wait in Reauthorization Delay TLV in most recent Service Authorization Response, Service Reauthorization Response, Quota Push Request, Quota Return Accept, or Service Verification Response message) for a service that is configured with basis second service when the quota for that service expires during the wait period.
•
A small buffer leak occurs when running SMTP traffic.
•
A CSG in redundant fault-tolerant mode can crash with the following message:
PPC exception type 512 on 'core_usage
•
The CSG continually resends Quota Service Reauthorization Requests for a specific user and service.
•
The CSG coredumps and resets after a switchover.
For this problem to occur, all of the following conditions must be met:
–
–
–
•
The advertise downlink next-hop command is not sufficient to enable the CSG to route mobile-to-mobile traffic to the correct GGSN processor. This problem can occur for APN subscribers that use pre-allocated static addresses to make them available to traffic from other subscribers.
•
The configurable CSG_EXTRA_TRACELOG_ENABLE environment variable is added to the CSG. This variable enables (1) or disables (0) additional tracelog statistics in the output for the show tech command. The default setting for this variable is 0 (disabled).
To set this variable, use the variable command in module CSG configuration mode.
•
The configurable CSG_CHECK_RETRY_TIMER environment variable is added to the CSG. This variable enables (1) or disables (0) the retry timer, which the CSG uses to check the status of all of the configured CGs every five minutes. The default setting for this variable is 1 (enabled).
To set this variable, use the variable command in module CSG configuration mode.
•
In a CSG with prepaid users, there are many GTP resends. This occurs more often with tariff switching during peak hours.
For this problem to occur, all of the following conditions must be met:
–
–
–
•
By default, the CSG sends a retry to a CG for an unacknowledged request every 4 seconds. However, in some cases, the retry interval might be less than the configured interval.
•
Under heavy load, the CSG might trigger the following false alarm:
Retry Timer is not running for CSG Billing Agent 4.4.4.15:3386 in ACTIVE state
•
An active or standby CSG with outstanding CDRs on its associated PSD might stop or fail to drain the CDRs when reset
•
If no quota server reassign is configured and the quota server fails while an unacknowledged ServiceStop request is in the queue for that quota server, the CSG might assign the ServiceStop request to an alternate quota server.
•
The CSG might send BMA CDRs with no RADIUS attributes included.
For this problem to occur, all of the following conditions must be met:
–
–
–
–
•
When an HTTP stream matches a content and policy with accounting type http, the CSG might crash with the below signature:
!!!CORE DUMP MON APR 21 16:17:29 2008
!!!Version: 3.1(3)C7(7)
IXP3 Software exception on task 'IXP3 SA-CORE (Ex 18)(00000000h)'For this problem to occur, all of the following conditions must be met:
–
–
•
The CSG might not relay some packets in the downlink direction, causing retransmits in the case of TCP (although the problem might not be limited to the downlink direction or to TCP).
For this problem to occur, all of the following conditions must be met:
–
–
•
When an HTTP stream matches a content and policy with accounting type http, the CSG might crash with the following signature:
!!!CORE DUMP SAT MAY 17 19:04:51 2008
!!!Version: 3.1(3)C7(7)
FPGA1 exception 999 IXIC_ICPAS - iPacket passthrough. ecmd wants to sync.For this problem to occur, all of the following conditions must be met:
–
–
–
Caveats for 3.1(3)C6(10)
This section lists and describes all caveats, both open and resolved, that affect CSG software release 3.1(3)C6(10).
For information about open or unresolved caveats in the Content Services Gateway 3.1(3)C6(10) release, refer to the Cisco Bug Toolkit at the following URL:
http://www.cisco.com/pcgi-bin/Support/Bugtool/home.pl.
CSG Release 3.1(3)C6(10) - Open Caveats
The following list identifies open caveats in CSG Release 3.1(3)C6(10).
•
The CSG closes all open sessions during a Reauthorization Delay (RD) "wait" state (that is, action code = wait in Reauthorization Delay TLV in most recent Service Authorization Response, Service Reauthorization Response, Quota Push Request, Quota Return Accept, or Service Verification Response message) for a service that is configured with basis second service when the quota for that service expires during the wait period.
Workaround: None.
•
A small buffer leak occurs when running SMTP traffic.
Workaround: Change the policy under the SMTP content from accounting type smtp to accounting type other.
•
When WAP 1.x/WSP traffic matches a content and policy with accounting type wap, the WAP concatenation packet might be dropped.
For this problem to occur, all of the following conditions must be met:
–
–
–
–
Workaround: Configure Layer 4 billing for this content.
•
A CSG in redundant fault-tolerant mode can crash with the following message:
PPC exception type 512 on 'core_usage
Workaround: None.
•
When the usage for a transaction is greater than 2147483647 quadrans, the CSG might report a negative value for quadrans in the BMA CDR.
Workaround: Clear the affected user.
•
The CSG might report a negative value for Total Usage in a Service Stop.
For this problem to occur, all of the following conditions must be met:
–
–
Workaround: Clear the affected user.
•
The CSG coredumps and resets after a switchover.
For this problem to occur, all of the following conditions must be met:
–
–
–
Workaround: Make sure every user has a unique IP address.
•
The advertise downlink next-hop command is not sufficient to enable the CSG to route mobile-to-mobile traffic to the correct GGSN processor. This problem can occur for APN subscribers that use pre-allocated static addresses to make them available to traffic from other subscribers.
Workaround: Add a static route to the configuration, pointing to the subscriber GGSN (if known in advance).
CSG Release 3.1(3)C6(10) - Closed Caveats
The following section lists bugs that are closed in CSG Release 3.1(3)C6(10).
•
RADIUS monitor support is enhanced to allow a ping request to be forwarded to the configured server (if there is a configured content to match the flow).
•
The CSG sends a SYN to the server to set up the half-proxy. The server responds with a SYN/ACK. The CSG sends the first request to the server, but the server does not receive the request. The server retransmits the SYN/ACK, which the CSG forwards to the client. (The CSG should drop the retransmitted SYN/ACK.)
For this problem to occur, the following conditions must all be met:
–
–
•
The CSG crashes with the following message at the Supervisor Engine console:
% No ICC response for TLV type 555 from CSM linecard.
For this problem to occur, the following conditions must all be met:
–
–
–
•
The CSG might reset both the client and the server. The problem seems to be related to the timing of the second auth_content_resp from the quota server.
•
When the FTP traffic load is high, the standby CSG might receive the following message:
Tack! invalid appl ptr 1fbb12/21e
1fbb12/21e src: 34.0.3.143:28458 dst: 40.40.40.2:21 prot: 6
kut index: <none>
flags: BACKUP_PEND
prepaid: ip bytes up = 0, ip bytes down = 0
tcp bytes up = 0, tcp bytes down = 0
bytes granted = 0, quads consumed = 0
flags = <none>•
Under heavy load running RTSP traffic, some tracebacks can be seen on the CSG console.
•
The persistence flag should be set in the ipv4flow (IPv4 L4 Flow TLV in the CDR) for e-mail protocols for all transactions that end but do not terminate the TCP session. The NOT CLOSED flag should also be set in this same condition, as it is for HTTP.
•
After deleting a VLAN from the configuration, the CSG resets continuously with "error in installing ruleset." This is working as designed, for contents that are configured in active rulesets.
When the VLAN is deleted, the CSG takes all contents that reference the VLAN out of service. However, if a content is configured in an active ruleset, the CSG does not remove the content from the ruleset. Then, when the CSG reboots, the ruleset configuration fails and the CSG remains offline.
To resolve this issue, you must remove the content from the ruleset, then reboot the CSG.
•
The CSG drops packets due to buffer exhaustion, but no alarm is generated.
For this problem to occur, one of the following counters (in TCP Statistics) must be non-zero:
Slowpath(low pri) buffer alloc failures 0 0Slowpath(high pri) buffer alloc failures 0 0Block alloc failures 0 0Small buffer allocs failures 0 0Medium buffer allocs failures 0 0Large buffer allocs failures 11553 355Session table allocs failures 0 0A non-zero value on of these counters indicates that the CSG might have dropped some packets as a result of buffer exhaustion.
•
In IPS3.0, when a user has an unknown billing plan due to loss of communication with the CSG, the HTTP statistics CDR might be generated with 0 bytes counted.
•
The CSG console requires a packet log utility. This utility enables the CSG to log WAP, RTSP, and RADIUS packets (normal and errors).
The packet log utility can log up to 4096 packets and consumes 6756 KB of memory (allocated as a block, not incrementally).
To select the packets to be logged, use the pktlog set console command, with the following options:
–
–
–
–
–
–
To stop logging selected packets, use the pktlog clear console command, with the following options:
–
–
–
–
–
–
–
To display the packet logs, use the pktlog show console command, with the following options:
–
–
–
–
–
–
–
–
By default, the packet log utility is disabled. To enable the packet log utility, the configurable PKTLOG_ENABLE environment variable is added to the CSG. This variable enables (1) or disables (0) the packet log utility. The default setting is 0 (disabled).
The configurable PKTLOG_OVERWRITE environment variable is also added to the CSG. This variable enables the CSG to overwrite packet logs when the buffer is full. To enable the CSG to overwrite packet logs, specify 1 (the default setting). To prevent the CSG from overwriting packet logs, specify 0.
To set these variables, use the variable command in module CSG configuration mode.
•
The CSG might drop RADIUS messages after configuring or unconfiguring accounting.
•
The CSG crashes when running under maximum CPU and maximum memory conditions.
•
A user might end up with a large positive balance when a quota server sends a Service Authorization Response with negative quadrans (-1) for a CSG service. This can occur when the quota server uses negative quadrans in the Service Authorization Response.
•
The CSG might not forward an HTTP POST that spans multiple packets.
For this problem to occur, all of the following conditions must be met:
–
–
–
•
If CSG is configured for accounting type rtsp, the CSG might crash as a result of a buffer overrun when performing a show tech csg.
•
The show tech and show mod csg tech-support commands might display Resource Utilization twice.
•
The CSG might drop GET requests under certain timing conditions.
For this problem to occur, the following conditions must all be met:
–
–
•
The CSG is allowing WAP 1.x traffic to pass through even if the quota server is denying the service (Quota = 0 quadrans, Cause = 3, Service Denied).
For this problem to occur, the following conditions must all be met:
–
–
–
•
The active CSG might not fail over to the standby CSG when buffer pools are corrupted with the default value of CSG_MEM_ERR_THRESHOLD.
•
The CSG might report an overcharge in the CDR TLV "Service TCP Usage Cumulative Bytes Down". The overcharge can be up to 20 more then the actual TCP/IP data transferred for a service transaction.
For this problem to occur, the following conditions must all be met:
–
–
–
•
When the no radius proxy command is entered, the CSG crashes with the following message on the Supervisor Engine console:
No ICC response for TLV type 660 from CSM linecard
For this problem to occur, the following conditions must all be met:
–
–
–
•
The queued count of a quota server might increase if the CSG stops retransmitting unacknowledged data requests. This might result in dropped new requests if the queued count reaches the configured maximum records limit.
For this problem to occur, the following conditions must all be met:
–
–
•
The CSG might overcharge download bytes for the first transaction with pipelined GETs after an abnormal termination.
For this problem to occur, the following conditions must all be met:
–
–
–
–
•
WAP 1.0 redirect does not work if the server sends an ACK before sending a REPLY.
For this problem to occur, the following conditions must all be met:
–
–
–
•
The CSG might resend Quota Service Reauthorization Requests in an endless loop for a specific user and a specific service.
•
When changes are being made to a URL map in a standby CSG, it might become active, leading to an active/active collision.
Caveats for 3.1(3)C6(9)
This section lists and describes all caveats, both open and resolved, that affect CSG software release 3.1(3)C6(9).
For information about open or unresolved caveats in the Content Services Gateway 3.1(3)C6(9) release, refer to the Cisco Bug Toolkit at the following URL:
http://www.cisco.com/pcgi-bin/Support/Bugtool/home.pl.
CSG Release 3.1(3)C6(9) - Open Caveats
The following list identifies open caveats in CSG Release 3.1(3)C6(9).
•
The CSG sends a SYN to the server to set up the half-proxy. The server responds with a SYN/ACK. The CSG sends the first request to the server, but the server does not receive the request. The server retransmits the SYN/ACK, which the CSG forwards to the client. (The CSG should drop the retransmitted SYN/ACK.)
For this problem to occur, the following conditions must all be met:
–
–
Workaround: None.
•
The CSG closes all open sessions during a Reauthorization Delay (RD) "wait" state (that is, action code = wait in Reauthorization Delay TLV in most recent Service Authorization Response, Service Reauthorization Response, Quota Push Request, Quota Return Accept, or Service Verification Response message) for a service that is configured with basis second service when the quota for that service expires during the wait period.
Workaround: None.
•
Under heavy load running RTSP traffic, some tracebacks can be seen on the CSG console.
Workaround: None.
•
A small buffer leak occurs when running SMTP traffic.
Workaround: Change the policy under the SMTP content from accounting type smtp to accounting type other.
•
When WAP 1.x/WSP traffic matches a content and policy with accounting type wap, the WAP concatenation packet might be dropped.
For this problem to occur, all of the following conditions must be met:
–
–
–
–
Workaround: Configure Layer 4 billing for this content.
CSG Release 3.1(3)C6(9) - Closed Caveats
The following section lists bugs that are closed in CSG Release 3.1(3)C6(9).
•
Changes to the CSG CPU normalization factor trigger the reporting of higher than expected CPU utilization values.
•
Under heavy traffic and heavy user activation and deactivation, the CSG generates trace messages and billing queue overflow messages.
•
When WAP 1.x/WSP traffic matches a content and policy with accounting type wap, it can trigger a traceback that is not reported in the CDR.
For this problem to occur, all of the following conditions must be met:
–
–
–
Caveats for 3.1(3)C6(8)
This section lists and describes all caveats, both open and resolved, that affect CSG software release 3.1(3)C6(8).
For information about open or unresolved caveats in the Content Services Gateway 3.1(3)C6(8) release, refer to the Cisco Bug Toolkit at the following URL:
http://www.cisco.com/pcgi-bin/Support/Bugtool/home.pl.
CSG Release 3.1(3)C6(8) - Open Caveats
The following list identifies open caveats in CSG Release 3.1(3)C6(8).
•
The CSG sends a SYN to the server to set up the half-proxy. The server responds with a SYN/ACK. The CSG sends the first request to the server, but the server does not receive the request. The server retransmits the SYN/ACK, which the CSG forwards to the client. (The CSG should drop the retransmitted SYN/ACK.)
For this problem to occur, the following conditions must all be met:
–
–
Workaround: None.
•
The CSG closes all open sessions during a Reauthorization Delay (RD) "wait" state (that is, action code = wait in Reauthorization Delay TLV in most recent Service Authorization Response, Service Reauthorization Response, Quota Push Request, Quota Return Accept, or Service Verification Response message) for a service that is configured with basis second service when the quota for that service expires during the wait period.
Workaround: None.
•
Under heavy traffic and heavy user activation and deactivation, the CSG generates trace messages and billing queue overflow messages.
Workaround: None.
•
Under heavy load running RTSP traffic, some tracebacks can be seen on the CSG console.
Workaround: None.
•
A small buffer leak occurs when running SMTP traffic.
Workaround: Change the policy under the SMTP content from accounting type smtp to accounting type other.
•
When WAP 1.x/WSP traffic matches a content and policy with accounting type wap, the WAP concatenation packet might be dropped.
For this problem to occur, all of the following conditions must be met:
–
–
–
–
Workaround: Configure Layer 4 billing for this content.
CSG Release 3.1(3)C6(8) - Closed Caveats
The following section lists bugs that are closed in CSG Release 3.1(3)C6(8).
•
When the CSG is operating in half-proxy mode (accounting type http), it is necessary to advertise a Maximum Segment Size (MSS) value when establishing a TCP connection with the client. Once the first HTTP transaction is received, the CSG then establishes a TCP connection with the server. If the server returns an MSS value less than initially advertised by the CSG to the client, datagrams with a size in excess of what the server can handle might be sent by the client. These datagrams are then dropped by the server.
To help avoid this problem, the configurable CSG_SET_MSS environment variable is added to the CSG. This variable enables the user to set the MSS, in bytes. The range is 1 byte to 1432 bytes. The default setting is 1432 bytes.
To set this variable, use the variable command in module CSG configuration mode.
•
When the CSG has exceeded its CPU capacity, it might drop GTP' ACKs and lose communication with the BMA or the PSD.
As part of the CSG's health monitoring process, the CSG monitors itself for low CPU conditions.
–
%CSM_SLB-3-ERROR: Module 3 error: WARN - CSG cpu exceeded 90.0%(91.1%)
By default, the CSG issues this warning message when CPU usage exceeds 90%. (The second number is the current CSG CPU one-minute average usage.) To change that threshold, change the setting of the CSG_CPU_WARN_THRESHOLD variable. The range for this variable is 1 to 95; the default setting is 90.
By default, the CSG issues this warning message once a minute after the threshold has been exceeded. To change the time between warning messages, change the setting of the CSG_CPU_WARN_FREQUENCY variable. The range for the variable is 1 to 95; the default setting is 5.
–
%CSM_SLB-3-ERROR: Module 3 error: CRITICAL - CSG max cpu reached 95.0%(96.1%)
By default, the CSG issues this depletion message when CPU usage exceeds 95%. (The second number is the current CSG CPU one-minute average usage.) To change that threshold, change the setting of the CSG_CPU_MAX_THRESHOLD variable. The range for this variable is 1 to 95; the default setting is 95.
By default, the CSG issues this depletion message once a minute after the threshold has been exceeded. To change the time between depletion messages, change the setting of the CSG_CPU_MAX_FREQUENCY variable. The range for the variable is 1 to 95; the default setting is 1.
To set these variables, use the variable command in module CSG configuration mode.
•
A malformed RADIUS message might cause the CSG to crash.
•
The CSG might be unable to parse a RADIUS VSA if the format does not follow RFC 2865. This might result in a user not being added to the User Table.
•
As part of the BMA recovery process, the CSG drains CDRs from the PSD and forwards them to the BMA. In a high-traffic environment, this drainage might degrade the throughput of incoming traffic, and could even bring down the CSG.
To help avoid this problem, the configurable CSG_GTP_DRAIN_DELAY environment variable is added to the CSG. This variable enables the user to adjust the GTP PSD drain delay. The range is 0 seconds to 3 seconds. The default setting is 1 second.
The configurable CSG_GTP_DRAIN_PKT environment variable is also added to the CSG. This variable enables the user to specify how many packets the CSG is to drain for each delay. The range is 1 packet to 100 packets. The default setting is 2 packets.
To set these variables, use the variable command in module CSG configuration mode.
•
The CSG might receive a partial coredump when detecting an internal error.
•
The CSG forwards HTTP traffic without requesting quota from the quota server.
For this problem to occur, all of the following conditions must be met:
–
–
–
•
A CSG user configured for prepaid service can encounter a traceback message and might see high CPU usage as a result.
•
Quota refund for FTP timeout is not working.
•
Redirect might fail with WAP 1.x connection-oriented sessions when a user is out of balance.
For this problem to occur, the following conditions must all be met:
–
–
–
•
A CSG running Release 3.1(3)C7(2) and SUP720 Release 12.2(18)SXF6 used in Layer 7 Traffic Authorization mode can crash with the next crash error:
!!!CORE DUMP WED OCT 25 05:23:27 2006
!!!Version: 3.1(3)C7(2)
FPGA1 exception 999 IXIC_ICPAS - iPacket passthrough. ecmd wants to sync.
Even when running in fault-tolerant mode, both CSGs can crash immediately.
•
With accounting-type HTTP configured for the relevant content, the CSG sends an ACK to the client with zero window size.
•
The CSG might send a Service Reauthorization even if there is sufficient quota available. This can occur when a quota server sends a Reauthorization Delay along with non-zero granted quadrans in one of the following messages:
–
–
–
In this situation, the CSG cannot handle the delay properly.
•
The CSG CPU load is extremely high (85%) with a low number of subscribers and low traffic.
•
If variable CSG_FTP_PWD = 1 is configured, the CSG resets the FTP data connection after a failover.
•
The CSG crashes with WAP/UDP traffic with IP fragmentation. This crash can occur in either of the following scenarios:
–
–
•
If there is a large amount of backpressure from the Cisco Catalyst 6500 series switch backplane, resulting in "TX Window full" and "TX FIFO full" statistics incrementing on the show mod csm tech proc command, the NAT processor might stop handling traffic, causing an eventual core dump.
•
The CSG can behave unpredictably when certain types of TCP packets are received.
TCP packets with the following TCP flags can cause problems:
–
–
–
–
Also, packets in which the IP packet length is less than sum of the IP header length and the TCP header length can cause problems.
•
The CSG can crash when it encounters spurious memory accesses. The CSG does not crash when it encounters a NULL pointer access, so when the code does not check the NULL pointer, the CSG can encounter a random memory corruption and crash.
•
If variable CSG_FTP_PWD is set to its default value (0), the CSG does not process buffered packets during PWD command transaction. If the buffered command is PORT from the client, then one of the following conditions might occur:
–
–
For this problem to occur, the following conditions must all be met:
–
–
–
•
When WAP 1.x/WSP traffic matches a content and policy with accounting type wap, the CSG might crash, with the system logs showing PPC exception.
For this problem to occur, one of the following sets of conditions must be met:
Condition 1:
–
–
–
–
Condition 2.
–
–
–
–
To help avoid this problem, the configurable CSG_MEM_ERR_THRESHOLD environment variable is added to the CSG. This variable enables the user to set the number of memory errors to allow before failing over to the backup CSG. When the threshold is reached, the CSG dumps the memory that is in error to the logs and dumps the buffer pools to the CSG console. The range is 0 errors to 10000 errors. The default setting is 5 errors.
The configurable DUMP_BAD_WAP_PACKET environment variable is also added to the CSG. This variable enables the CSG to dump WAP packets that cannot be parsed to the system logs, if debugging is enabled from the VENUS# console. We recommend that you configure this variable only when directed to do so by Cisco Technical Assistance Center (TAC) engineers. The range is 0 (do not dump any WAP packets to the system logs) to 100 (dump the first 100 WAP packets that cannot be parsed). The default setting is 5 (dump the first 5 WAP packets that cannot be parsed).
To set these variables, use the variable command in module CSG configuration mode.
•
The CSG resets while adding or modifying policies in a live network.
For this problem to occur, the following conditions must all be met:
–
–
•
When WAP 1.x/WSP traffic matches a content and policy with accounting type wap, the CSG might lose memory gradually.
For this problem to occur, the following conditions must all be met:
–
–
–
–
•
The user cannot send large HTTP POSTs (larger than 1000 KB).
For this problem to occur, the following conditions must all be met:
–
–
–
To help avoid this problem, the configurable CSG_MAX_POST_LENGTH environment variable is added to the CSG. This variable enables the user to set the maximum HTTP POST size, in bytes, to be buffered by the CSG. The range is 0 byte to 10485760 bytes. The default setting is 65536 bytes.
To set this variable, use the variable command in module CSG configuration mode.
•
The CSG does not process requests from the quota server if the source port in the request packet is not the quota server port configured in the CSG.
•
For WAP 1.x traffic that matches a CSG content-policy pair that is configured for accounting type wap, the CSG might report a large value, or an incorrect value, for "Interval Usage Seconds" in the Service Stop message.
–
–
•
When an HTTP stream matches a content and policy with accounting type http, the CSG might encounter a buffer leak and drop all traffic.
For this problem to occur, all of the following conditions must be met:
–
–
–
Caveats for 3.1(3)C6(7)
This section lists and describes all caveats, both open and resolved, that affect CSG software release 3.1(3)C6(7).
For information about open or unresolved caveats in the Content Services Gateway 3.1(3)C6(7) release, refer to the Cisco Bug Toolkit at the following URL:
http://www.cisco.com/pcgi-bin/Support/Bugtool/home.pl.
CSG Release 3.1(3)C6(7) - Open Caveats
The following list identifies open caveats in CSG Release 3.1(3)C6(7).
•
The CSG sends a SYN to the server to set up the half-proxy. The server responds with a SYN/ACK. The CSG sends the first request to the server, but the server does not receive the request. The server retransmits the SYN/ACK, which the CSG forwards to the client. (The CSG should drop the retransmitted SYN/ACK.)
For this problem to occur, the following conditions must all be met:
–
–
Workaround: None.
•
The CSG closes all open sessions during a Reauthorization Delay (RD) "wait" state (that is, action code = wait in Reauthorization Delay TLV in most recent Service Authorization Response, Service Reauthorization Response, Quota Push Request, Quota Return Accept, or Service Verification Response message) for a service that is configured with basis second service when the quota for that service expires during the wait period.
Workaround: None.
CSG Release 3.1(3)C6(7) - Closed Caveats
The following section lists bugs that are closed in CSG Release 3.1(3)C6(7).
•
In a Cisco Mobile Exchange (CMX) configuration in which the GGSN acts as a quota server for a postpaid user and the CSG provides content billing (the CSG treats the user as prepaid), the CSG might not send a Quota Return in response to a Quota Return Request.
For this problem to occur, all of the following conditions must be met:
–
–
–
•
If an active FTP is used between an FTP client and an FTP server, and the CSG classifies the FTP control and data TCP connections as FTP connections (via accounting type ftp), and if data traffic is flowing over the FTP data connection when a CSG failover occurs, the newly active CSG sends a TCP RST to the FTP client, resulting in the TCP connection for FTP data being closed.
•
If the passthrough command is configured on at least one service, and the CSG receives a RADIUS Start for a prepaid user while the quota server is down, when the quota server recovers, the CSG charges the first session for that user after the quota server recovers as postpaid. Subsequent sessions for that user are charged correctly.
•
If an IMAP fetch is in progress between an IMAP client and an IMAP server when a CSG failover occurs, and the CSG classifies the IMAP TCP connection as IMAP (via accounting type imap), the newly active CSG does not forward the frames associated with the IMAP fetch.
•
The CSG might reload when handling high RTSP traffic load.
•
The CSG is sending report string attribute values other than 0x00, 0x01 and 0x02 in RTSP CDRs. The reported attribute values are reserved by Cisco for future use.
•
The CSG might not parse multiple RADIUS subattributes encoded in a single VSA in a RADIUS Access-Accept message.
•
If the CSG loses communication with all BMAs, it might not retrieve records from the PSD when one or more BMAs recover.
When communication with the BMAs is lost, the CSG sends records to the PSD. When communication with one or more BMAs is recovered, the CSG fails to retrieve records from the PSD and forward them to the BMA, even though the CSG maintains the PSD in an active state. Echo requests and write requests continue to be processed correctly, and the CSG shows no pending read requests in its record storage statistics.
•
When memory usage is greater than 98%, the CSG memory pools might continue to grow, leaving the CSG at less than 2 percent memory.
•
When a high rate of traffic flows through the CSG, the PPC might incorrectly mark the FPGA as hung, and the CSG might crash and reload.
•
When using a CSG policy with accounting type http, the CSG might not forward the first HTTP request for a session, and the HTTP transaction might not complete.
For this problem to occur, all of the following conditions must be met:
–
–
–
•
The CSG might fail to resend HTTP packets from the client after the CSG receives the FIN from the client.
For this problem to occur, all of the following conditions must be met:
–
–
–
–
–
•
The CSG might send a gratuitous ARP request (that is, an ARP request in which the CSG advertises the IP address as its own IP address) for an IP address defined as a match criteria in a CSG content. The CSG sends the gratuitous ARP on exactly one VLAN. The VLAN depends on the configuration.
For this problem to occur, all of the following conditions must be met:
–
–
•
The CSG might not forward header or out-of-order trailer IP fragments for a UDP packet.
•
Under heavy traffic conditions and stress levels of user activation and deactivation, the CSG might crash, generate a core dump, and fail over to the standby CSG.
•
When the CSG receives RTSP packets that do not end with Ctrl-F Ctrl-F, the CSG might crash while cleaning up these improper RTSP flow connections. This can also occur when all of the RTSP flows use the same session ID.
If this occurs, the log shows the following messages:
%CSM_SLB-3-UNEXPECTED: Module 4 unexpected error: PPC exception encountered.
%CSM_SLB-3-UNEXPECTED: Module 4 unexpected error:
Rebooting....
•
When the show module csg tech-support command is entered, the CSG might report an incorrect value for the in-use buffer with NoKUT. The reported value might register 4294967295 continually.
•
When handling RADIUS, WAP, and HTTP traffic with IP fragmentation, the CSG might stop forwarding traffic when it runs out of buffers.
•
If the FTP data connection is running in passive mode, the CSG might drop FTP data packets when the FTP server retransmits the PASV response during the data connection handshake.
•
The CSG crashes when running HTTPS traffic.
For this problem to occur, all of the following conditions must be met:
–
–
–
Caveats for 3.1(3)C6(6)
This section lists and describes all caveats, both open and resolved, that affect CSG software release 3.1(3)C6(6).
For information about open or unresolved caveats in the Content Services Gateway 3.1(3)C6(6) release, refer to the Cisco Bug Toolkit at the following URL:
http://www.cisco.com/pcgi-bin/Support/Bugtool/home.pl.
CSG Release 3.1(3)C6(6) - Open Caveats
The following list identifies open caveats in CSG Release 3.1(3)C6(6).
•
The CSG sends a SYN to the server to set up the half-proxy. The server responds with a SYN/ACK. The CSG sends the first request to the server, but the server does not receive the request. The server retransmits the SYN/ACK, which the CSG forwards to the client. (The CSG should drop the retransmitted SYN/ACK.)
For this problem to occur, the following conditions must all be met:
–
–
Workaround: None.
•
The CSG closes all open sessions during a Reauthorization Delay (RD) "wait" state (that is, action code = wait in Reauthorization Delay TLV in most recent Service Authorization Response, Service Reauthorization Response, Quota Push Request, Quota Return Accept, or Service Verification Response message) for a service that is configured with basis second service when the quota for that service expires during the wait period.
Workaround: None.
•
If the passthrough command is configured on at least one service, and the CSG receives a RADIUS Start for a prepaid user while the quota server is down, when the quota server recovers, the CSG charges the first session for that user after the quota server recovers as postpaid. Subsequent sessions for that user are charged correctly.
Workaround: None.
CSG Release 3.1(3)C6(6) - Closed Caveats
The following section lists bugs that are closed in CSG Release 3.1(3)C6(6).
•
In response to a GTP reject cause code message from BMA, the CSG sends a log message to the Supervisor. In some cases, the CSG could flood the Supervisor with many log messages and deplete EOBC buffers:
%EOBC-3-NOEOBCBUF: No EOBC buffer available. Dropping the packet.
This might result in degradation of CAT6k performance and might lead to an IOS crash.
•
In the CDRs for POP3 and SMTP, the CSG reports 0 duration.
•
The CSG might not forward HTTPS packets for an HTTP stream for an HTTPS port.
For this problem to occur, all of the following conditions must be met:
–
–
–
•
Intermediate records might not be generated when they should be, based on the configured bytes. Or the records are generated, but with bytes counts larger than the amount configured.
•
If the CSG is configured for prepaid, and there are ore than 20,000 users in the User Table, and traffic is running, removing the user group configuration from an accounting group might cause the CSG to reload.
•
When server-initiated FTP or RTSP traffic is received from an unknown MAC address for more than 8 sessions, the CSG hangs, causing a reload.
•
If the quota server fails, and a RADIUS Start adds a user to the User Table, and the CSG sends a RST when the client attempts an HTTP connection, then the final eight bytes of the Connection Timestamp TLV are incorrect.
•
For a time-based service, the CSG might send an incorrect interval usage value.
•
While running RTSP traffic containing UDP as the transport protocol, one set of UDP data traffic maps to CATCHALL policy of type OTHER.
For this problem to occur, all of the following conditions must be met:
–
–
•
The CSG might hang when its memory is depleted or fragmented, or when it is trying to download a complex URL map. If this occurs, the CSG hangs, stops passing traffic, and stops responding to user commands, and the console stops responding.
To help avoid this problem, the following configurable environment variables are added to the CSG:
–
–
–
To set these variables, use the variable command in module CSG configuration mode.
•
When the CSG detects a BMA failure, it might leave the associated CDRs in the to-be-sent queue forever, even after the BMA becomes active.
•
An RTSP proxy in the network might send a different set of client ports, which could lead to a different session being created. As a result, RTSP traffic might be blocked, or might map to a catchall policy of accounting type other if one is configured.
•
The CSG might hang or become unresponsive while running RTSP traffic in either prepaid or postpaid mode.
For this problem to occur, all of the following conditions must be met:
–
–
–
•
The active CSG might fail over to the standby CSG when a new HTTP request/response follows the FIN from the client/server.
For this problem to occur, all of the following conditions must be met:
–
–
–
–
–
Caveats for 3.1(3)C6(5)
This section lists and describes all caveats, both open and resolved, that affect CSG software release 3.1(3)C6(5).
For information about open or unresolved caveats in the Content Services Gateway 3.1(3)C6(5) release, refer to the Cisco Bug Toolkit at the following URL:
http://www.cisco.com/pcgi-bin/Support/Bugtool/home.pl.
CSG Release 3.1(3)C6(5) - Open Caveats
The following list identifies open caveats in CSG Release 3.1(3)C6(5).
•
If the CSG is configured for prepaid, and there are ore than 20,000 users in the User Table, and traffic is running, removing the user group configuration from an accounting group might cause the CSG to reload.
Workaround: Take accounting out of service before removing the user group from the accounting configuration.
•
The CSG sends a SYN to the server to set up the half-proxy. The server responds with a SYN/ACK. The CSG sends the first request to the server, but the server does not receive the request. The server retransmits the SYN/ACK, which the CSG forwards to the client. (The CSG should drop the retransmitted SYN/ACK.)
For this problem to occur, the following conditions must all be met:
–
–
Workaround: None.
•
When server-initiated FTP or RTSP traffic is received from an unknown MAC address for more than 8 sessions, the CSG hangs, causing a reload.
Workaround: Make sure proper routing is defined such that the CSG learns source MAC addresses on the return path. You can do this by routing the return traffic through routers that are defined as gateways in the CSG.
•
If the quota server fails, and a RADIUS Start adds a user to the User Table, and the CSG sends a RST when the client attempts an HTTP connection, then the final eight bytes of the Connection Timestamp TLV are incorrect.
Workaround: None.
•
The CSG might send an incorrect interval usage value for a time-based service.
Workaround: None.
CSG Release 3.1(3)C6(5) - Closed Caveats
The following section lists bugs that are closed in CSG Release 3.1(3)C6(5).
•
ICMP type 3/4 messages are not forwarded by the CSG back to the server. This affects the path MTU discovery protocol, and might result in the server sending packets that are too large for the network.
•
If the first character of a configured HTTP header name is lowercase, the CSG does not match the header fields in the header map.
•
CSGs installed on different chassis and configured for fault tolerance might failover to the standby CSGs during SSO switchover of the Supervisor Engine 720 with an MSFC3-BXL. The CSGs might also go offline.
•
Some browsers do not follow RFC2616 and use just a line feed (LF) in HTTP headers rather than carriage return and line feed (CRLF). The CSG does not handle HTTP messages which use LF as end-of-line.
•
The CSG can obscure the contents of the X-Forwarded-For header, overwriting it with blanks.
–
–
If your configuration is fault-tolerant, keep the following considerations in mind:
–
–
•
If you enter the radius start restart session-id command in CSG user group configuration mode, and a RADIUS Interim-Update is processed, the CSG might end the user's sessions, delete the existing User Table entry, and create a new User Table entry.
•
If you enter more than 10 CSG IP or TCP refund flags, the system might become unresponsive and display the following error message:
%SYS-3-CPUHOG: Task is running for
(2000)msecs, more than (2000)msecs (49/45),process = Exec.
-Traceback= 41A28B24 402A12B0 4020E488 401E2BEC 401E2D00 401D6EB8
40524DD4 401E6090 402AD22C 402AD218•
When the Billing Mediation Agent (BMA) is down, the CSG continues to forward traffic and generate billing records, and the billing records continue to be buffered into the GTP storage pool. Depending on the user's configuration and traffic load, the resulting combination of a large records max value, many User Table entries, and a high session count can deplete the CSG's memory and cause it to reload or failover to the standby CSG.
As part of the CSG's health monitoring process, the CSG monitors itself for low memory conditions.
–
%CSM_SLB-3-ERROR: Module 3 error: WARN - CSG memory usage exceeded 85% (29M/256M)
By default, the CSG issues this warning message when memory usage exceeds 85%. To change that threshold, change the setting of the CSG_MEM_WARN_THRESHOLD variable (using the variable command in module CSG configuration mode). The range for this variable is 1 to 98; the default setting is 85.
By default, the CSG issues this warning message once a minute after the threshold has been exceeded. To change the time between warning messages, change the setting of the CSG_MEM_WARN_FREQUENCY variable. The range for the variable is 1 to 99; the default setting is 1.
–
%CSM_SLB-3-ERROR: Module 3 error: CRITICAL - CSG max memory reached 98% (4M/256M)
By default, the CSG issues this depletion message when memory usage exceeds 98%. To change that threshold, change the setting of the CSG_MEM_MAX_THRESHOLD variable. The range for this variable is 1 to 98; the default setting is 98.
By default, the CSG issues this depletion message once a minute after the threshold has been exceeded. To change the time between depletion messages, change the setting of the CSG_MEM_MAX_FREQUENCY variable. The range for the variable is 1 to 99; the default setting is 1.
–
%CSM_SLB-3-ERROR: Module 3 error: FAILOVER - CSG memory usage exceeded 98% (1M/256M)
By default, the CSG does not perform a core dump or failover, nor does it issue this failover message. If you want the CSG to take these actions, you must set a failover threshold by setting the CSG_MEM_FAILOVER_THRESHOLD variable. The range for the variable is 0 to 98; the default setting is 0 (no core dump, failover, or message).
Note
•
The active CSG might fail over to the backup CSG when a new HTTP request/response follows the FIN from the client and server.
For this problem to occur, all of the following conditions must be met:
–
–
–
•
The CSG drops a UDP trailer fragment if a UDP fragment is the first packet of a UDP connection on the CSG.
For this problem to occur, all of the following conditions must be met:
–
–
–
•
When an HTTP stream containing a POST message matches a content and policy with accounting type http, and the connection ends before the POST is completed, the CSG charges the entire transaction in upload bytes, even though the actual bytes transferred might be less.
For this problem to occur, all of the following conditions must be met:
–
–
–
•
The CSG might generate high volume CDRs, overcharging for a Layer 4 inspection, or for Layer 7 inspection downgraded to Layer 4 inspection.
For this problem to occur, all of the following conditions must be met:
–
–
–
•
When a new session is created on a UDP fragment packet, the final or intermediate download statistics might be incorrect.
For this problem to occur, all of the following conditions must be met:
–
–
•
SNMP requests to a Catalyst 6000 family switch chassis might fail when the CSG hangs without rebooting.
•
The CSG might generate high volume CDRs, overcharging for a Layer 4 inspection, or for Layer 7 inspection downgraded to Layer 4 inspection.
For this problem to occur, all of the following conditions must be met:
–
–
–
•
If the value configured on the records max command in CSG accounting configuration mode is very high, the CSG might crash or be unable to communicate with IOS when its memory is exhausted. The following message might appear on the syslog:
%ICC-4-HEARTBEAT: Card 9 failed to respond to heartbeat
•
When the CSG is performing HTTP deep packet inspection (accounting type http) for an HTTP session, and the client sends a POST with an invalid content length, the CSG might drop some packets and the session might hang.
For this problem to occur, all of the following conditions must be met:
–
–
•
The active CSG might fail over to the backup CSG when Layer 7 inspection of an HTTP pipelined connection is downgraded to Layer 4 inspection.
For this problem to occur, all of the following conditions must be met:
–
–
–
–
•
If the CSG is configured for Layer 7 HTTP deep packet inspection, and the server sends an IP fragmented reply, the last packet in the reply is not part of a fragment, then the CSG might drop the packet and might not free buffers.
For this problem to occur, all of the following conditions must be met:
–
–
–
•
The active CSG fails over to the standby CSG when processing UDP fragments, or when processing many small HTTP transactions in a burst.
•
If a GET request is sent on the same TCP connection on which a token-stripping event has occurred, the CSG drops the GET request.
For this problem to occur, all of the following conditions must be met:
–
–
–
–
–
•
The CSG does not send a content authorization request for the RTSP data stream.
For this problem to occur, all of the following conditions must be met:
–
–
–
–
RTSP/1.0 200 OK\r\n
Transport: RTP/AVP/TCP;unicast;interleaved=0-1;ssrc=28c07001;mode=PLAY\r\n
•
The CSG might not forward a packet that has both the IP and TCP option fields set to 32 bytes or more. The affected session might hang or reset.
For this problem to occur, all of the following conditions must be met:
–
–
•
For flows that match a CSG policy with accounting type http, HTTP packets that are IP fragmented and that have the RESET bit set in the TCP header cause the CSG to fail to report the terminal statistic.
For this problem to occur, all of the following conditions must be met:
–
–
•
If the Transport header in the REPLY from the server to a client SETUP request contains only a single server or client port, then while running RTSP traffic using UDP transport, the UDP packets map to a default policy configured with accounting type other.
•
All CSG usage information has been consolidated into one number, CSG CPU Utilization, which presents a good overall picture of CSG capacity.
To display CSG CPU Utilization, first enable debugging output for the CPU, using the debug ip csg cpu command in privileged EXEC mode, then enter the show module csg slot tech-support utilization command.
Router# debug ip csg cpuCSG CPU Utilization debugging is onRouter# show module csg 3 tech-support utilizationResource Utilization:MemoryAvailable Memory 62% 155MAllocated Memory 31% 78MOS Static Memory 9% 22MCSG CPU Utilization: 1m (0.0%), 5m (0.0%)To disable debugging output for the CPU, enter the no debug ip csg cpu command in privileged EXEC mode.
•
UDP flows for a prepaid customer, with multiple fragment families, allow more bytes than the permitted quota.
For this problem to occur, all of the following conditions must be met:
–
–
–
•
When the CSG is configured to run WAP or other prepaid traffic, under heavy load with large numbers of quota server responses, the CSG might become unresponsive to commands and might no reload.
•
If the URL provided by the client in the TEARDOWN message is longer than the "presentation" URL, provided by the client in the DESCRIBE message, then the CSG does not tear down all associated UDP sessions to an RTSP stream. The CDRs are generated for one session (stream-id=0) when the client tears down the stream, but for the other session (stream-id=1) the CDRs are generated when the flow's idle timeout occurs.
•
Packets sent to a CSG virtual MAC address might be forwarded to other active CSGs. For example, if the CSGs use the same client and server VLANs, and the switch does not have an entry for the virtual MAC address in the mac-address-table, the packet is sent to all ports in the VLAN. As a result, multiple active CSGs might parse the same message. For instance, a RADIUS Accounting Start message might be processed by two active CSGs, even though it was directed to the virtual MAC address of only one of the CSGs. This creates duplicate subscriber entries in the User Tables of the active CSGs.
•
If the first HTTP request is split across packets, such that chunk-length and chunk-body are in separate packets, then the CSG might drop the first HTTP POST request with transfer-encoding:chunked.
•
A parsing failure in a pipelined GET request might cause some of the responses to be charged to the last policy. As a result, the CSG might not charge all packets to the correct HTTP deep packet inspection (accounting type http) policy.
•
When the CSG parses an HTTP POST request that spans one packet and part of another, the CSG stops parsing HTTP and downgrades the traffic flow to Layer 4 inspection.
For this problem to occur, all of the following conditions must be met:
–
–
–
•
The standby CSG can leak memory when processing FTP sessions. (The active CSG processes the FTP sessions correctly.) If the standby CSG processes enough FTP sessions, it can exhaust memory and crash.
•
The CSG might count lost records incorrectly even though the records are written, processed, and counted correctly by the PSD.
•
When running HTTP deep packet Layer 7 inspection, the CSG's TCP IXP module might leak buffers if a session is downgraded to Layer 4 inspection, reducing the pool of free buffers. The downgraded session might then fail and reset.
For this problem to occur, all of the following conditions must be met:
–
–
•
The CSG undercharges the byte count for a WAP transaction.
While awaiting the final ACK for a transaction from the client, the CSG might close out the transaction prematurely and generate a billing record. The CSG allows the final ACK from the client to pass without charge.
•
When a TCP stream matches a policy with accounting type other and there are out-of-order IP fragments, the active CSG might failover to the standby CSG.
For this problem to occur, all of the following conditions must be met:
–
–
Caveats for 3.1(3)C6(4)
This section lists and describes all caveats, both open and resolved, that affect CSG software release 3.1(3)C6(4).
For information about open or unresolved caveats in the Content Services Gateway 3.1(3)C6(4) release, refer to the Cisco Bug Toolkit at the following URL:
http://www.cisco.com/pcgi-bin/Support/Bugtool/home.pl.
CSG Release 3.1(3)C6(4) - Open Caveats
The following list identifies open caveats in CSG Release 3.1(3)C6(4).
•
If the first character of a configured HTTP header name is lowercase, the CSG does not match the header fields in the header map.
Workaround: Configure the first character of the header-name in uppercase, regardless of the case in the packet.
•
CSGs that are configured for fault-tolerance in different chassis might change state from active to standby when a Supervisor SSO switchover occurs. In some cases, the CSG module might go offline.
Workaround: None. Reset the offline module to bring it back into service.
•
When an HTTP stream containing a POST message matches a content and policy with accounting type http, and the connection terminates before the POST can complete, the CSG charges the entire transaction in upload bytes, even though the actual bytes transferred might be less.
For this problem to occur, the following conditions must all be met:
–
–
–
HTTP Layer 7 charging is based on the inspection of TCP sequence numbers. The CSG tracks the beginning sequence number of each transaction and scans for the ending sequence number. The Content_Length header tells the CSG how many bytes it can skip before restarting analysis. This allows the CSG to off load forwarding of payload that it does not need to analyze.
Workaround: The FLAG field in the CDRs indicates that the session was abnormally terminated; this might be used by back-end systems to remove the charge.
•
If the CSG is configured for prepaid, and there are ore than 20,000 users in the User Table, and traffic is running, removing the user group configuration from an accounting group might cause the CSG to reload.
Workaround: Take accounting out of service before removing the user group from the accounting configuration.
•
When the CSG is performing Layer 7 inspection of an HTTP session, if the client sends a POST with an invalid content length, the CSG might drop some packets and the session might hang.
Workaround: This is a violation of the protocol. If possible, remove the client from the network. In order for the CSG to pass this type of session correctly, it must be configured for Layer 4 inspection of HTTP traffic.
•
The CSG sends a SYN to the server to set up the half-proxy. The server responds with a SYN/ACK. The CSG sends the first request to the server, but the server does not receive the request. The server retransmits the SYN/ACK, which the CSG forwards to the client. (The CSG should drop the retransmitted SYN/ACK.)
For this problem to occur, the following conditions must all be met:
–
–
Workaround: None.
•
If the CSG is configured for Layer 7 HTTP inspection, and the server sends a reply with IP fragments, and the last packet in the reply is not part of a fragment, then the packet might be dropped, and a buffer on the CSG might not be freed.
To view outstanding buffers, enter the show module csg x tech-support processor 2 command, where x is the module number of the CSG. The outstanding buffers are displayed near the bottom of the output. These numbers fluctuate in a live network. Buffer allocate failures could be a sign of a buffer leak.
Workaround: Either run without server-side IP fragmentation, or reconfigure the CSG for Layer 4 inspection.
CSG Release 3.1(3)C6(4) - Closed Caveats
The following section lists bugs that are closed in CSG Release 3.1(3)C6(4).
•
The timerwheel crashes during a specific sequence of configuring, testing, unconfiguring, and configuring, as follows:
a.
b.
c.
d.
e.
•
When using a CSG policy with accounting type http, and the client uses HTTP pipelining, the client's browsing speed might be reduced.
Sample packet sequence:
a.
b.
c.
d.
e.
For this problem to occur, the following conditions must all be met:
–
–
–
–
•
A heavy load of TCP connection cleanup processing can trigger a timing error in the CSG FIN/RST termination logic, and can cause the CSG to reboot. If the CSG is part of a stateful pair, the primary CSG fails over to the backup CSG.
•
The CSG encounters an FPGA hang and crashes. The console displays the message: IXP3 Software exception on task 'IXP3 SA-CORE (Ex 18)(00000000h)'.
For this problem to occur, all of the following conditions must be met:
–
–
–
–
–
Typical RTSP prepaid does not experience the error, as the key is that the quota server responses must be very slow for this error to occur.
•
A CSG PPC exception or machine check can occur, followed by a failover to the backup.
For this problem to occur, all of the following conditions must be met:
–
–
This defect can also be triggered if the HTTP headers contain carriage-return and line-feed (CRLF) in the field-name of the message-header (ref: RFC 2616) due to erroneous handling of CRLF.
•
The CSG needs to be able to copy coredumps using RCP.
•
The CSG logs an unexpected PPC exception. The CSG reboots and fails over to its standby. A core dump analysis shows a tag sequence error for FPGA 2.
•
After a fault-tolerance failover, the console shows the following traceback for the standby-to-active CSG:
CSG Quota Manager 10.0.250.153:3386 is active.State Transition Standby -> Active
Standby is Active now (no heartbeat from active unit)
Traceback - 0x001D4D54 0x001F4924 0x001F5900 0x00049BF8 0x001A73F4
•
The CSG might failover to the backup.
For this problem to occur, all of the following conditions must be met:
–
–
For example, the CSG sends an ACK to a client if the CSG has received a packet containing HTTP headers, but the headers continue into a subsequent packet that the client has not yet sent. If the CSG needs to resend this packet because it was lost in transit to the server, a failover might occur.
•
SMTP traffic hangs or does not complete properly when AoC is configured within a postpaid service definition.
•
The CSG might report 0 TCP Uploaded Bytes for an HTTP GET/RESPONSE transaction.
•
The CSG fails over to the backup CSG during heavy connection setup/cleanup load.
When many TCP connections are open and idle, and all need to be cleaned up simultaneously, the internal CSG TCP cleanup process might become overloaded, causing the primary CSG to fail and restart. The issue has a higher probability of occurring with idle connections matching a policy configured with accounting type http, but can occur with other TCP accounting types as well.
This issue might also occur if the CSG is driven with a large burst of TCP connection initiations beyond its performance limits
•
Add a CSG console command to show encap for troubleshooting packets was sent to a wrong station.
Syntax: show encap ip-address netmask
Examples:
CSG> show encap 172.18.45.1 255.255.255.255
172.18.45.1 /32 00-d0-00-33-a8-0aCSG> show encap 20.0.0.0 255.0.0.0
20.0.0.0 /08 00-80-1c-a8-a8-80CSG> show encap 10.10.28.88 255.255.255.255
Attempted to get info on RESERVED encap.10.10.28.88 /32 encap not found!This command does not show the encap for the local defined interfaces. If you try to do so, you receive the "Attempted to get info on RESERVED encap" response.
•
The CSG might report negative byte counts for HTTP.
For this problem to occur, all of the following conditions must be met:
–
–
The CSG should detect the miscalculation and zero the byte counts for this transaction, thereby avoiding the negative value. Two statistics counters are added to the show tech command output to indicate that this code path is being triggered:
–
–
This caveat is similar to CSCej34444, except that CSCej29778 is for accounting type http and CSCej34444 is for any other TCP accounting type.
•
The CSG reports negative TCP byte counts.
For this problem to occur, the flow must match a CSG content configured with a policy with an accounting type configured, and the timing of the internal processing must be such that the packet sequence numbers are subtracted incorrectly.
For this problem to occur, all of the following conditions must be met:
–
–
The CSG should detect the miscalculation and zero the byte counts for this transaction, thereby avoiding the negative value. Two statistics counters are added to the show tech command output to indicate that this code path is being triggered:
–
–
This caveat is similar to CSCej29778, except that CSCej29778 is for accounting type http and CSCej34444 is for any other TCP accounting type.
•
When a transaction is content-authorized and NAT-redirected to an AoC server, and the second transaction is originated by the client over the same TCP connection, and the CSG does content authorization again, the HTTP transaction gets stuck in the CSG.
•
When using HTTP pipelined traffic matching CSG Content Rules with accounting type http, if the CSG receives a FIN/ACK from the server side before all the data is received from the server, the CSG might report incorrect download bytes in the billing record.
•
When using a client configured to pipeline HTTP requests, if a server response spans multiple fragmented packets, the CSG might not forward all of the server's fragmented response packets and then sends a RST to both the client and server.
For this problem to occur, the following conditions must all be met:
–
–
–
•
If an RTSP stream is interrupted, and if the session stays idle for 10 seconds, then the CSG times out and closes the session, even if the idle timer for the content is configured with a higher value. this problem occurs on low speed 2G mobile, when there are many interruptions downloading the stream.
•
During duration-based billing, the RTSP stream continues to play beyond the allocated quota.
For this problem to occur, all of the following conditions must be met:
–
–
–
–
•
When an HTTP stream containing a multipart POST message matches a content and policy with accounting type http and a header map, then the CSG does not forward the POST to the server and RSTs the session.
•
The CSG reports large overcharge and negative quota usage when a TCP FIN is received before the end of data.
For this problem to occur, all of the following conditions must be met:
–
–
–
•
TCP byte counts can be off by one byte in the following situations:
–
–
•
The CSG might report huge usage for an RTSP or FTP control session, if the control session times out without seeing a packet from the server.
•
The CSG might overcharge pipelined HTTP transactions under certain connection failure scenarios.
For this problem to occur, all of the following conditions must be met:
–
–
–
–
The overcharge applies to the next transaction (n+1) and is equal to the number of downloaded bytes for the previous transaction (n).
•
The CSG might drop IP fragments that use UDP as the transport protocol.
For this problem to occur, all of the following conditions must be met:
–
–
–
•
An IXP3 software exception occurs on task 'IXP3 SA-CORE (Ex 18)(00000000h).
For this problem to occur, all of the following conditions must be met:
–
–
–
•
The CSG crashes with the following message:
!!!CORE DUMP <day> <date> <time>
!!!Version: 3.1(3)C<x>(<y>)
FPGA3 exception 64 IC_WAITIX - icmd waiting to sync with ePacket.
For this problem to occur, all of the following conditions must be met:
–
–
–
–
•
With certain players, the CSG does not correctly report the end of all flows in an RTSP stream when the stream ends. As a result, the following conditions occur:
–
–
For this problem to occur, all of the following conditions must be met:
–
–
–
A teardown can be used to terminate all streams or an individual stream. If the teardown is intended for all streams, the URL is the presentation URL reported in the DESCRIBE; otherwise, the URL specifically matches the URL of an individual stream. In the latter case, the player is not sending a DESCRIBE message at the beginning of the RTSP session. Therefore, the CSG does not have a presentation URL. However, the TEARDOWN message appears to be a presentation URL. Since the CSG does not have a presentation URL to match against, the CSG does not terminate all of the streams. The RTSP RFC is vague in this area.
•
When there are retransmitted SYNs and SYN/ACKs for an RTSP control session, the CSG can receive a SYN after receiving a SYN/ACK. This might result in the CSG reporting a zero TCP byte count for the RTSP CDR.
Caveats for 3.1(3)C6(3)
This section lists and describes all caveats, both open and resolved, that affect CSG software release 3.1(3)C6(3).
For information about open or unresolved caveats in the Content Services Gateway 3.1(3)C6(3) release, refer to the Cisco Bug Toolkit at the following URL:
http://www.cisco.com/pcgi-bin/Support/Bugtool/home.pl.
CSG Release 3.1(3)C6(3) - Open Caveats
The following list identifies open caveats in CSG Release 3.1(3)C6(3).
•
If the first character of a configured HTTP header name is lowercase, the CSG does not match the header fields in the header map.
Workaround: Configure the first character of the header-name in uppercase, regardless of the case in the packet.
•
CSGs that are configured for fault-tolerance in different chassis might change state from active to standby when a Supervisor SSO switchover occurs. In some cases, the CSG module might go offline.
Workaround: None. Reset the offline module to bring it back into service.
•
The CSG support was omitted from 12.2(18)SXE1 images for SUP720-MSFC3-BXL for IP Service.
Workaround: Run s72033-adventerprisek9_wan-mz.122-18.SXE1.
•
The CSG might report 0 TCP Uploaded Bytes for an HTTP GET/RESPONSE transaction.
Workaround: None.
•
When using a CSG policy with accounting type http, and the client uses HTTP pipelining, the client's browsing speed might be reduced.
Sample packet sequence:
a.
b.
c.
d.
e.
For this problem to occur, the following conditions must all be met:
–
–
–
–
Workaround: None.
•
The CSG encounters an FPGA hang and crashes. The console displays the message: IXP3 Software exception on task 'IXP3 SA-CORE (Ex 18)(00000000h)'.
For this problem to occur, all of the following conditions must be met:
–
–
–
–
–
Typical RTSP prepaid does not experience the error, as the key is that the quota server responses must be very slow for this error to occur.
Workaround: None, if prepaid volume-based RTSP billing is needed. The issue does not occur for duration-based nor event-based RTSP billing.
•
When a transaction is content-authorized and NAT-redirected to an AoC server, and the second transaction is originated by the client over the same TCP connection, and the CSG does content authorization again, the HTTP transaction gets stuck in the CSG.
Workaround: Use URL-redirect instead of NAT-redirect.
•
When using HTTP pipelined traffic matching CSG Content Rules with accounting type http, if the CSG receives a FIN/ACK from the server side before all the data is received from the server, the CSG might report incorrect download bytes in the billing record.
Workaround: None, if accounting type http is required.
•
When using a client configured to pipeline HTTP requests, if a server response spans multiple fragmented packets, the CSG might not forward all of the server's fragmented response packets and then sends a RST to both the client and server.
For this problem to occur, the following conditions must all be met:
–
–
–
Workaround: None.
•
If an RTSP stream is interrupted, and if the session stays idle for 10 seconds, then the CSG times out and closes the session, even if the idle timer for the content is configured with a higher value. this problem occurs on low speed 2G mobile, when there are many interruptions downloading the stream.
Workaround: None.
•
During duration-based billing, the RTSP stream continues to play beyond the allocated quota.
For this problem to occur, all of the following conditions must be met:
–
–
–
–
Workaround: None, if accounting type rtsp is required.
•
When an HTTP stream containing a multipart POST message matches a content and policy with accounting type http and a header map, then the CSG does not forward the POST to the server and RSTs the session.
Workaround: None, if accounting type http is required.
CSG Release 3.1(3)C6(3) - Closed Caveats
The following section lists bugs that are closed in CSG Release 3.1(3)C6(3).
•
WAP1 connectionless buffers might leak with 0 quota and exclude configured MMS options.
•
If a CSG prepaid service is configured for basis fixed, and one or more new user transactions are processed while the CSG is gathering usage information for ongoing transactions, the CSG might use quota that should be returned to the quota server.
•
The CSG might undercharge bytes and seconds for FTP control connections. The problem occurs when FTP control connections are mapped to a service that undergoes a quota return or tariff-switch. The CSG stops charging for usage after the time of the quota return or tariff switch for FTP control connections that start before the time of the quota return or tariff switch.
•
When performing RTSP downloads over TCP or HTTP, the TCP upload byte count for an RTSP interleaved connection is under-reported by one byte.
•
The CSG might immediately request additional quota via a service reauthorization request after the quota server grants quota in a service authorization response. The CSG might repeat this action indefinitely.
•
The username TLV is not located in a WAP CDR, or the first transaction of a WAP session is not associated with a service.
•
When an RTSP control session is created, but no corresponding UDP data sessions are established, the RTSP session block might leak. The RTSP session pool contains a non zero in-use value after all RTSP sessions have terminated and cleaned up.
•
When a second movie is downloaded by the same client before the UDP sessions for the first movie clean up or timeout, and the client and server both reuse the same UDP ports for the second movie, the UDP content for the second movie is either blocked or is not billed as RTSP traffic.
•
When running HTTP type traffic through an HTTP type content (filter type HTTP), some buffers might leak. Even under some stress, this appears to be a slow leak. The leak is caused when the CSG receives a server reset immediately following HTTP response data packets which the CSG determines need analysis to detect content length. This problem does not occur on normal FIN-terminated connections.
•
Non-WAP traffic billed as type wap is passed through the CSG without charge. Non-WAP traffic is sent to WAP port 9200 or 9201, which is configured to be billed as WAP1 traffic.
To deal with this issue, we have added a new environment variable called CSG_WAP_DROP_UNKNOWN_PACKETS. When configured, the CSG drops all traffic that does not contain a valid WTP or WSP PDU type. Valid type values are defined in the WAP WTP/WSP specifications.
•
When using a CSG policy with accounting type http, the CSG does not account uplink traffic for the HTTP Head method.
For this problem to occur, all of the following conditions must be met:
–
–
–
•
CSG R5.8 replaces the destination IP in the IP header with the IP Address of the next-hop of the policy.
•
When the RTSP flow matches a content and policy configured with accounting type rtsp, the RTSP parsing for the return code from the server is incorrect. This results in an RTSP billing record being generated with an invalid RTSP return code.
•
In response to a GTP reject cause code message from BMA, the CSG sends a log message to the Supervisor. In some cases, the CSG could flood the Supervisor with many log messages and deplete EOBC buffers:
%EOBC-3-NOEOBCBUF: No EOBC buffer available. Dropping the packet.
This might result in degradation of CAT6k performance and might lead to an IOS crash.
•
If there is no User Table entry when data traffic for the user reaches the CSG, a sticky entry is created when a CDR is sent to the BMA. If a RADIUS message is received, the sticky entry is converted to a normal entry. The User Profile Request is sent to the quota server as part of the conversion processing, but the RADIUS attributes are not included.
•
If you add a second user-group and accounting service to a configuration in prepaid mode, the CSG cannot retrieve the MIB quota server stats properly by either a manual MIB walk or by SNMP messaging. This is true for all the quota servers that are configured in both of the configured user-groups.
•
If you add a second user-group and accounting service to a configuration in prepaid mode, the CSG cannot retrieve the MIB quota server stats properly by either a manual MIB walk or by SNMP messaging. This is true for all the quota servers that are configured in both of the configured user-groups.
•
The CSG sporadically crashes, reporting an IXP3 crash. The show tech command shows IXP3 Software exception on task 'IXP3 SA-CORE (Ex 18)(00000000h)'.
•
When a TCP session for HTTP is closed in one direction (server-to-mobile) and that Mobile is sending a TCP RST, the CSG reports incorrect downLoadBytesTCP 1501767.
•
The CSG does not block WAP 1.X traffic when the user is known but the billing plan is UNKNOWN.
•
The CSG might sporadically generate a CDR that contains an invalid Content-Provider TLV, or subsequent TLVs following the Content-Provider TLV might be corrupt.
•
When using a CSG policy with accounting type http, the CSG might not count all the volume of an HTTP request if the FIN is received before the CSG can forward the entire client request to the server.
•
When using a CSG policy with accounting type http, HTTP Post requests with "Content-Type: multipart" that have long headers spanning more than one packet are not forwarded. External symptom is that the HTTP transaction does not complete.
•
When no radius ack error is configured and data traffic is sent, some RADIUS Access Requests are dropped in the CSG.
•
HTTP inspection of IP fragmented traffic might undercharge when the fragments split the HTTP headers in the client request. Buffer counts in CSG Show Tech are incorrect.
•
When HTTP pipelined requests spanning multiple packets are IP-fragmented, the user session might hang and reset.
•
If the initial transmit of a segment is lost in the CSG-to-server path, the CSG does not retransmit to the server all the fragments of a request which it has ACKed. This causes the session to hang and timeout.
•
If pipelined HTTP requests are fragmented and a request spans multiple TCP segments, the head fragment might not be forwarded by the CSG, and the user session might hang and reset.
Caveats for 3.1(3)C6(2)
This section lists and describes all caveats, both open and resolved, that affect CSG software release 3.1(3)C6(2).
For information about open or unresolved caveats in the Content Services Gateway 3.1(3)C6(2) release, refer to the Cisco Bug Toolkit at the following URL:
http://www.cisco.com/pcgi-bin/Support/Bugtool/home.pl.
CSG Release 3.1(3)C6(2) - Open Caveats
The following list identifies open caveats in CSG Release 3.1(3)C6(2).
•
If the first character of a configured HTTP header name is lowercase, the CSG does not match the header fields in the header map.
Workaround: Configure the first character of the header-name in uppercase, regardless of the case in the packet.
•
CSGs that are configured for fault-tolerance in different chassis might change state from active to standby when a Supervisor SSO switchover occurs. In some cases, the CSG module might go offline.
Workaround: None. Reset the offline module to bring it back into service.
•
The CSG might undercharge bytes and seconds for FTP control connections.
The problem occurs when FTP control connections are mapped to a service that undergoes a quota return or tariff-switch. The CSG stops charging for usage after the time of the quota return or tariff switch for FTP control connections that start before the time of the quota return or tariff switch.
Workaround: Use a CSG release earlier than CSG R6.
•
The CSG support was omitted from 12.2(18)SXE1 images for SUP720-MSFC3-BXL for IP Service.
Workaround: Run s72033-adventerprisek9_wan-mz.122-18.SXE1.
•
When a transaction is content-authorized and NAT-redirected to an AoC server, and the second transaction is originated by the client over the same TCP connection, and the CSG does content authorization again, the HTTP transaction gets stuck in the CSG.
Workaround: Use URL-redirect instead of NAT-redirect.
•
The CSG might report incorrect download bytes in the billing record. When pipelining, if the CSG receives a FIN/ACK from the server side before all the data is received from the server, the CSG creates an incorrect download bytes billing record.
Workaround: None.
•
The CSG might not include RADIUS attributes in User Profile Request.
If there is no User Table entry when data traffic for the user reaches the CSG, the CSG creates a sticky entry when a CDR is sent to the BMA. If a RADIUS message is received, the sticky entry is converted to a normal entry. The User Profile Request is sent to the Quota Server as part of the conversion processing, but the RADIUS attributes are not included.
The problem can also occur if the user database is used in conjunction with RADIUS inspection and the user database response is received before the RADIUS message arrives.
Workaround: RADIUS Start should be received by the CSG before user traffic.
•
If you add a second user-group and accounting service to a configuration in prepaid mode, the CSG cannot retrieve the MIB quota server stats properly by either a manual MIB walk or by SNMP messaging. This is true for all the quota servers that are configured in both of the configured user-groups.
Workaround: Make sure all configurations for all the user-groups and accounting services are present before booting the switch. If you encounter this issue, resetting the CSGs corrects the problem. Taking both accounting services might also fix the problem.
•
If you add a second user-group and accounting service to a configuration in prepaid mode, the CSG cannot retrieve the MIB quota server stats properly by either a manual MIB walk or by SNMP messaging. This is true for all the quota servers that are configured in both of the configured user-groups.
Workaround: Make sure all configurations for all the user-groups and accounting services are present before booting the switch. If you encounter this issue, resetting the CSGs corrects the problem. Taking both accounting services might also fix the problem.
•
If a CSG prepaid service is configured for basis fixed, and one or more new user transactions are processed while the CSG is gathering usage information for ongoing transactions, the CSG might use quota that should be returned to the quota server.
Workaround: None.
CSG Release 3.1(3)C6(2) - Closed Caveats
The following section lists bugs that are closed in CSG Release 3.1(3)C6(2).
•
Cisco Internetwork Operating System (IOS) software is vulnerable to a Denial of Service (DoS) and potentially an arbitrary code execution attack from a specifically crafted IPv6 packet. The packet must be sent from a local network segment. Only devices that have been explicitly configured to process IPv6 traffic are affected. Upon successful exploitation, the device may reload or be open to further exploitation.
Cisco has made free software available to address this vulnerability for all affected customers.
More details can be found in the security advisory that is posted at http://www.cisco.com/warp/public/707/cisco-sa-20050729-ipv6.shtml.
•
When using the CSG for prepaid billing of FTP sessions between the Windows XP FTP Client with a Bison FTP Server, additional quota might be reserved at the end of an FTP data session.
•
If the server sends fragmented IP packets, and those packets arrive at the CSG out of order, the CSG might crash. This issue can occur with a VPN gateway that was not configured to avoid IP fragmentation, and with HTTP or other servers as well.
•
If the forward action is set and the service verify disable bit is set, the service verify token is not stripped.
•
The reserved quota field on the backup CSGs KUT might be set to a value even though it should be 0.
•
CSG users who use HSRP must configure a route or default gateway for the HSRP standby/virtual IP address. This enables the CSG to actively monitor the HSRP HELLO message, to track the physical IP and MAC addresses of the HSRP devices. With this HSRP monitoring, the CSG can properly forward the return traffic to the standby/virtual HSRP IP address.
•
If the variable CSG_FTP_PWD is set to 1, the IP and TCP byte counts are incorrect for the CDR generated for the FTP control connection. The byte counts are less than they should be. The CDR for the data connection is correct.
•
In a configuration with next-hop addresses in both the client-to-server and server-to-client directions, RTSP data traffic utilizing UDP transport is not forwarded from the server to the client.
•
If there is an HTTP 1.0 request, and the response has a body, but no content-length, then the TCP downloaded bytes can be 0 for an HTTP1.0 connection.
•
Traffic on an RTSP data session might be blocked or not associated with the RTSP content definition. RTSP control traffic for specific methods (that is, SETUP/SETUP RSP) must extend into multiple IP packets, and the packet boundaries must split the method between the start of method and the transport header in the case of a SETUP request.
•
If an HTTP1.0 client receives multiple responses from the HTTP server and there is no content-length field specified in those response, only the first response TCP download bytes are counted. The rest are not. None of the responses are counted for TCP download bytes. HTTP1.1 works fine.
•
RTSP content objects that are no longer being used might be displayed in the output of a show command. Storage for these objects might not be freed.
•
The CSG might not forward FTP control session packets when next-hop routing is specified.
•
If the server initiates a connection teardown (that is, the server sends the first FIN), and the Content-Length field in the HTTP response is incorrect, the CSG might incorrectly charge for the TCP bytes downloaded in an HTTP Stats record.
•
The CSG might bill incorrectly when viewing pages on older Web servers. Some older Web servers end HTTP headers with an LF character, rather than a CRLF character. Under some conditions, this can lead to improper parsing by the CSG. Any further traffic on the same session is billed to the preceding properly parsed policy.
•
For SMTP traffic that encounters a service configured for content authorization (AoC), user traffic is not stopped when quota is exceeded.
•
The CSG crashes if accounting is taken out-of-service while RTSP traffic is flowing.
•
The standby CSG might reload when existing HTTP1.1 sessions are failing over from the primary CSG during a period with a high rate of connection establishment.
•
The CSG might undercharge TCP bytes for fragmented traffic if the flows match a Layer 4 policy/content. The CSG reports low TCP upload byte counts if the fragments are received on the client side, and low TCP download byte counts if the fragments are received on the server side.
•
With no radius ack error enabled, existing User Table entries can be stolen when the User Table is full and a new Start is received.
•
When performing AoC with RTSP data, a timing situation can cause the download to fail. If the AoC request/reply for a stream completes before traffic for the second UDP data session (corresponding to the stream) is seen, the UDP session can hang, preventing traffic from following on that session.
•
Correlators ID in Content Authorization Request and the related SMTP CDR do not match exactly.
•
Uplink/downlink byte counts in quota server messages and service-level CDRs cannot be mapped to client and server bytes. Traditionally, uplink bytes are bytes from the initiator of the session. The server-init flag in CDRs is used to determine direction and thus client/server bytes can be deduced. However, in quota server messages and service-level CDRs a server-init flag cannot be used, as information from multiple sessions is reported. As a result, client/server bytes cannot be deduced from these messages/CDRs.
•
The CSG crashes. Output indicates:
!!!CORE DUMP FRI APR 01 16:37:50 2005
!!!Version: 3.1(3)C5(6)
PPC exception type 512 on 'LaminarStack(...)'
•
The CSG crashes and generates a core dump. The Message shown is "PPC exception type 512 on 'TimerWheel(0D984A78h)'."
•
When the CSG is under stress and intermediate report is configured with a small byte count or time interval, the CSG might generate many stats messages and reloads.
•
If a next-hop IP address is defined in the WAP policy being used, WAP 1.x packets might be dropped.
•
When the FTP control connection is reset by the client or server, the TCP timeout flag in the IPv4l4Flow TLV might be set in FTP TCP records, when the connection was actually reset and did not time out.
•
The CSG might report 0 TCP Uploaded Bytes for an HTTP GET/RESPONSE transaction.
•
The CSM might core-dump while processing an ICMP destination-unreachable packet.
–
–
–
•
When using the CSG for FTP connection accounting, the CSG is still counting TCP SYN and FIN packets as one byte each in the FTP control sessions byte-count.
•
Out of Order packets can cause the CSG to miscalculate byte counts.
•
When there is RTSP traffic flowing through a CSG, and client attempts to start 3 or more streams per TCP control session, the CSG might fail to associate the actual UDP RTP traffic with the RTSP control session, and therefore might fail to set the correct correlator values in the UDP CDRs.
•
When parsing HTTP headers that span more than one packet, the CSG generates an ACK to request the next packet. If the server has already sent data for a previous request in the persistent connection, the ACK is sent with the wrong (old) TCP sequence number. Most clients accept the ACK anyway, but some ignore it and retransmit their requests. The CSG subsequently drops these retransmits rather than attempting to ACK them.
•
HTTP web pages with multiple embedded objects occasionally fail to load with the Sanyo S750 handset.
•
If a TCP packet which is sourced by the CSG is not acknowledged by the receiving endpoint, the CSG fails to retransmit the packet. This occurs only for HTTP flows that match an HTTP Layer 7 (accounting type http) policy. Packets that the CSG has sourced include SYN/ACK to the client, SYN to the server, and any HTTP packet for which CSG has built and sent its own ACK. An example of the latter case is an HTTP request (GET, POST, and so on) that was ACKed by the CSG to the client to trigger sending of more packets for further header analysis and was later forwarded by the CSG to the server. By building its own ACK, the CSG takes ownership of the packet and must retransmit if delivery to the server fails.
•
The CSG might report cumulative values as Interval Usage Seconds.
•
A PPC exception type 666 on BillingStack is seen while performing Layer 7 WAP inspection of non-WAP traffic that contains IP fragments. For example, WAP inspection might be attempted on encrypted WAP traffic, which cannot be done.
•
The CSG sends CDRs to the BMA server that might contain Content-Provider TLVs that contain incorrect data and are not structured correctly.
Documentation and Technical Assistance
This section contains the following information:
•
Related Documentation
For more detailed installation and configuration information, see the following publications:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
•
•
Cisco IOS Documentation Set
Cisco IOS Configuration Guides and Command References, Release 12.1(12c)E4—Use these publications to help you configure the Cisco IOS software that runs on the MSFC and on the MSM and ATM modules.
Obtaining Documentation, Obtaining Support, and Security Guidelines
For information on obtaining documentation, obtaining support, providing documentation feedback, security guidelines, and also recommended aliases and general Cisco documents, see the monthly What's 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
This document is to be used in conjunction with the documents listed in the "Related Documentation" section.
CCDE, CCENT, Cisco Eos, Cisco Lumin, Cisco Nexus, Cisco StadiumVision, Cisco TelePresence, the Cisco logo, DCE, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn and Cisco Store are service marks; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or Website 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. (0807R)
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.
Copyright © 2008, Cisco Systems, Inc. All rights reserved.
Guest
