Table Of Contents
Release Notes for Cisco Content Services Gateway 3.1(3)C5(14) for Cisco IOS Release 12.2(18)SXD
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)
Determining the Software Version
Upgrading to a New CSG Release
Saving and Restoring Configurations
Additional Installation Instructions
CSG Release 3.1(3)C5(14) - Open Caveats
CSG Release 3.1(3)C5(14) - Closed Caveats
CSG Release 3.1(3)C5(13) - Open Caveats
CSG Release 3.1(3)C5(13) - Closed Caveats
CSG Release 3.1(3)C5(12) - Open Caveats
CSG Release 3.1(3)C5(12) - Closed Caveats
CSG Release 3.1(3)C5(11) - Open Caveats
CSG Release 3.1(3)C5(11) - Closed Caveats
CSG Release 3.1(3)C5(9a) - Open Caveats
CSG Release 3.1(3)C5(9a) - Closed Caveats
CSG Release 3.1(3)C5(9) - Open Caveats
CSG Release 3.1(3)C5(9) - Closed Caveats
CSG Release 3.1(3)C5(8a) - Open Caveats
CSG Release 3.1(3)C5(8a) - Closed Caveats
CSG Release 3.1(3)C5(8) - Open Caveats
CSG Release 3.1(3)C5(8) - Closed Caveats
CSG Release 3.1(3)C5(7) - Open Caveats
CSG Release 3.1(3)C5(7) - Closed Caveats
CSG Release 3.1(3)C5(6) - Open Caveats
CSG Release 3.1(3)C5(6) - Closed Caveats
CSG Release 3.1(3)C5(5) - Open Caveats
CSG Release 3.1(3)C5(5) - Closed Caveats
CSG Release 3.1(3)C5(4.67) - Open Caveats
CSG Release 3.1(3)C5(4.67) - Closed Caveats
CSG Release 3.1(3)C5(4.48) - Open Caveats
CSG Release 3.1(3)C5(4.48) - Closed Caveats
CSG Release 3.1(3)C5(4.44) - Open Caveats
CSG Release 3.1(3)C5(4.44) - Closed Caveats
CSG Release 3.1(3)C5(4.18) - Open Caveats
CSG Release 3.1(3)C5(4.18) - Closed Caveats
CSG Release 3.1(3)C5(4) - Open Caveats
CSG Release 3.1(3)C5(4) - Closed Caveats
CSG Release 3.1(3)C5(3) - Open Caveats
CSG Release 3.1(3)C5(3) - Closed Caveats
CSG Release 3.1(3)C5(2) - Open Caveats
CSG Release 3.1(3)C5(2) - Closed Caveats
CSG Release 3.1(3)C5(1) - Open Caveats
CSG Release 3.1(3)C5(1) - Closed Caveats
Documentation and Technical Assistance
Obtaining Documentation and Submitting a Service Request
Release Notes for Cisco Content Services Gateway 3.1(3)C5(14) for Cisco IOS Release 12.2(18)SXD
Revised: March 24, 2009
Current Release—3.1(3)C5(14)
This publication describes the requirements, dependencies, and caveats for the Cisco Content Services Gateway (CSG) Release 3.1(3)C5(14).
Note
CSG Release 3.1(3)C5(14) is intended to be the last CSG maintenance release for 3.1(3)C5(5). For ongoing maintenance releases, Cisco recommends that you migrate to CSG Release 3.1(3)C6(5) or later.
Contents
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
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:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
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)C5(14)
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)SXB3.1(3)C5(13)
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)SXB3.1(3)C5(12)
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)SXB3.1(3)C5(11)
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)SXB3.1(3)C5(9a)
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)SXB3.1(3)C5(9)
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)SXB3.1(3)C5(8a)
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)SXB3.1(3)C5(8)
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)SXB3.1(3)C5(7)
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)SXB3.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)SXB3.1(3)C5(5)
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)SXB3.1(3)C5(4.67)
SC-SVC-CSG-B-5.0
SC-SVC-CSG-P-5.0SUP2-MSFC2
12.2(18)SXD
7.6.1
12.2(17b)SXB
3.1(3)C5(4.48)
SC-SVC-CSG-B-5.0
SC-SVC-CSG-P-5.0SUP2-MSFC2
12.2(18)SXD
7.6.1
12.2(17b)SXB
3.1(3)C5(4.44)
SC-SVC-CSG-B-5.0
SC-SVC-CSG-P-5.0SUP2-MSFC2
12.2(18)SXD
7.6.1
12.2(17b)SXB
3.1(3)C5(4.18)
SC-SVC-CSG-B-5.0
SC-SVC-CSG-P-5.0SUP2-MSFC2
12.2(18)SXD
7.6.1
12.2(17b)SXB
3.1(3)C5(4)
SC-SVC-CSG-B-5.0
SC-SVC-CSG-P-5.0SUP2-MSFC2
12.2(18)SXD
7.6.1
12.2(17b)SXB
3.1(3)C5(3)
SC-SVC-CSG-B-5.0
SC-SVC-CSG-P-5.0SUP2-MSFC2
12.2(18)SXD
7.6.1
12.2(17b)SXB
3.1(3)C5(2)
SC-SVC-CSG-B-5.0
SC-SVC-CSG-P-5.0SUP2-MSFC2
12.2(17d)SXB
7.6.1
12.2(17b)SXB
3.1(3)C5(1)
SC-SVC-CSG-B-5.0
SC-SVC-CSG-P-5.0SUP2-MSFC2
12.2(17d)SXB
7.6.1
12.2(17b)SXB
3.1(3)C4(11)
SC-SVC-CSG-B-4.0
SC-SVC-CSG-P-4.0SUP2-MSFC2
12.2(17d)SXB 12.2(14)ZA24
7.6.1
12.2(17b)SXB
3.1(3)C4(10)
SC-SVC-CSG-B-4.0
SC-SVC-CSG-P-4.0SUP2-MSFC2
12.2(17d)SXB 12.2(14)ZA24
7.6.1
12.2(17b)SXB
3.1(3)C4(9)
SC-SVC-CSG-B-4.0
SC-SVC-CSG-P-4.0SUP2-MSFC2
12.2(17d)SXB 12.2(14)ZA24
7.6.1
12.2(17b)SXB
3.1(3)C4(8)
SC-SVC-CSG-B-4.0
SC-SVC-CSG-P-4.0SUP2-MSFC2
12.2(17d)SXB 12.2(14)ZA24
7.6.1
12.2(17b)SXB
3.1(3)C4(7)
SC-SVC-CSG-B-4.0
SC-SVC-CSG-P-4.0SUP2-MSFC2
12.2(17d)SXB 12.2(14)ZA24
7.6.1
12.2(17b)SXB
3.1(3)C4(6)
SC-SVC-CSG-B-4.0
SC-SVC-CSG-P-4.0SUP2-MSFC2
12.2(17d)SXB 12.2(14)ZA24
7.6.1
12.2(17b)SXB
3.1(3)C4(5)
SC-SVC-CSG-B-4.0
SC-SVC-CSG-P-4.0SUP2-MSFC2
12.2(17d)SXB 12.2(14)ZA24
7.6.1
12.2(17b)SXB
3.1(3)C4(4)
SC-SVC-CSG-B-4.0
SC-SVC-CSG-P-4.0SUP2-MSFC2
12.2(17d)SXB 12.2(14)ZA24
7.6.1
12.2(17b)SXB
3.1(3)C4(3)
SC-SVC-CSG-B-4.0
SC-SVC-CSG-P-4.0SUP2-MSFC2
12.2(17d)SXB 12.2(14)ZA24
7.6.1
12.2(17b)SXB
3.1(3)C4(2)
SC-SVC-CSG-B-4.0
SC-SVC-CSG-P-4.0SUP2-MSFC2
12.2(17d)SXB 12.2(14)ZA24
7.6.1
12.2(17b)SXB
3.1(3)C4(1)
SC-SVC-CSG-B-4.0
SC-SVC-CSG-P-4.0SUP2-MSFC2
12.2(17d)SXB 12.2(14)ZA24
7.6.1
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.
4 The Cisco IOS 12.2ZA early deployment release has migrated to 12.2SXB and is no longer available.
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
See the Cisco Content Services Gateway Installation and Configuration Guide for more information about installing the CSG.
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)C5(14)
This section lists and describes all caveats, both open and closed, that affect CSG software release 3.1(3)C5(14).
For information about open caveats in the Content Services Gateway 3.1(3)C5(14) 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)C5(14) - Open Caveats
The following list identifies open caveats in CSG Release 3.1(3)C5(14).
•
When using a CSG policy with accounting type http and a client using HTTP pipelining, client browsing speed might be reduced.
Sample packet (pkt) sequence:
a.
b.
c.
d.
e.
f.
For this problem to occur, all of the following conditions must be met:
–
–
–
–
Workaround: None.
•
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:
–
–
Workaround: None.
•
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 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.
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)C5(14) - Closed Caveats
The following section lists bugs that are closed in CSG Release 3.1(3)C5(14).
•
The CSG might not parse multiple RADIUS subattributes encoded in a single VSA in a RADIUS Access-Accept message.
•
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:
–
–
–
Caveats for 3.1(3)C5(13)
This section lists and describes all caveats, both open and closed, that affect CSG software release 3.1(3)C5(13).
For information about open caveats in the Content Services Gateway 3.1(3)C5(13) 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)C5(13) - Open Caveats
The following list identifies open caveats in CSG Release 3.1(3)C5(13).
•
When using a CSG policy with accounting type http and a client using HTTP pipelining, client browsing speed might be reduced.
Sample packet (pkt) sequence:
a.
b.
c.
d.
e.
f.
For this problem to occur, all of the following conditions must be met:
–
–
–
–
Workaround: None.
•
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:
–
–
Workaround: None.
•
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 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.
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)C5(13) - Closed Caveats
The following section lists bugs that are closed in CSG Release 3.1(3)C5(13).
•
The CSG might not forward an HTTPS packet.
For this problem to occur, all of the following conditions must be met:
When an HTTP stream containing the CONNECT method, for an HTTPS port, matches a content and policy with accounting type http and a policy with header map exists under the content, then CSG does not forward the HTTPS packet.
–
–
–
•
Entering the no inservice command followed by the inservice command in CSG accounting configuration mode can cause the CSG to crash with the following message displayed on the Supervisor console: "% No ICC response for TLV type 555 from CSM linecard."
•
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:
–
–
–
–
–
•
The Session reused while valid counter in the TCP IXP statistics is non-zero.
For this problem to occur, all of the following conditions must be met:
–
–
–
•
The Session reused while valid counter in the TCP IXP statistics is non-zero.
For this problem to occur, all of the following conditions must be met:
–
–
–
–
Caveats for 3.1(3)C5(12)
This section lists and describes all caveats, both open and closed, that affect CSG software release 3.1(3)C5(12).
For information about open caveats in the Content Services Gateway 3.1(3)C5(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)C5(12) - Open Caveats
The following list identifies open caveats in CSG Release 3.1(3)C5(12).
•
When using a CSG policy with accounting type http and a client using HTTP pipelining, client browsing speed might be reduced.
Sample packet (pkt) sequence:
a.
b.
c.
d.
e.
f.
For this problem to occur, all of the following conditions must be met:
–
–
–
–
Workaround: None.
•
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 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:
–
–
Workaround: None.
•
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.
Workaround: None.
CSG Release 3.1(3)C5(12) - Closed Caveats
The following section lists bugs that are closed in CSG Release 3.1(3)C5(12).
•
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 following enhancements allow better control of CSG memory usage:
–
–
–
Router# show module csg 3 tech-support utilizationResource Utilization:MemoryAvailable Memory 61% 153MAllocated Memory 31% 79MOS Static Memory 8% 22MLowest Memory Available 153M THU MAR 23 21:53:31 2006•
The CSG might send duplicate statistics when an HTTP session is downgraded from Layer 7 inspection is downgraded to Layer 4 inspection.
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:
–
–
•
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 the active CSG's memory becomes depleted, it can failover to the standby CSG. This fix helps prevent the failover by preventing the active CSG from allocating new storage to perform required billing functions.
In addition, you can help prevent this problem by limiting the CSG's memory usage:
–
–
–
•
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:
–
–
•
The CSG does not forward fragments of incomplete HTTP pipelined requests.
For this problem to occur, all of the following conditions must be met:
–
–
–
Caveats for 3.1(3)C5(11)
This section lists and describes all caveats, both open and closed, that affect CSG software release 3.1(3)C5(11).
For information about open caveats in the Content Services Gateway 3.1(3)C5(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)C5(11) - Open Caveats
The following list identifies open caveats in CSG Release 3.1(3)C5(11).
•
When using a CSG policy with accounting type http and a client using HTTP pipelining, client browsing speed might be reduced.
Sample packet (pkt) sequence:
a.
b.
c.
d.
e.
f.
For this problem to occur, all of the following conditions must be met:
–
–
–
–
Workaround: None.
•
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
Workaround: If you see any of these messages, you need to reduce the maximum number of billing records that the CSG is allowed to buffer in memory. To do so, set the records max command in CSG accounting configuration mode to a smaller value, such as 10,000.
•
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:
–
–
Workaround: None.
•
The CSG might count lost records incorrectly even though the records are written, processed, and counted correctly by the PSD.
Workaround: None.
•
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.
Workaround: None.
•
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:
–
–
Workaround: None.
CSG Release 3.1(3)C5(11) - Closed Caveats
The following section lists bugs that are closed in CSG Release 3.1(3)C5(11).
•
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.
•
SNMP requests to a Catalyst 6000 family switch chassis might fail when the CSG hangs without rebooting.
•
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.
•
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.
•
CSG needs to be able to copy coredumps using RCP.
•
When AoC is configured within a postpaid service definition, SMTP traffic hangs or does not complete properly.
•
Add a CSG command to show encapsulation, for troubleshooting packets that were sent to a wrong station.
Syntax: show encap ip-address netmask
Examples:
Router# show encap 172.18.45.1 255.255.255.255172.18.45.1 /32 00-d0-00-33-a8-0aRouter# show encap 10.1.0.0 255.0.0.010.1.0.0 /08 00-80-1c-a8-a8-80This command cannot display encapsulation information for locally defined interfaces. If you enter this command for a locally defined interface, the CSG displays the message, "Attempted to get info on RESERVED encap," as shown in the following example:
Router# show encap 10.10.28.88 255.255.255.255Attempted to get info on RESERVED encap.10.10.28.88 /32 encap not found!•
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
•
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 active CSG might fail over to the backup CSG when Layer 7 inspection is downgraded to Layer 4 inspection.
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:
–
–
–
•
The CSG might drop the first HTTP GET request if it is pipelined.
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:
–
–
–
•
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.
•
TCP byte counts might be off by one byte when one of the following conditions occurs:
–
–
•
Taking accounting out of service, then placing it back in service while the CSG is processing RTSP connections, might cause the CSG to fail to clean up those connections after the RTSP connection completes.
For this problem to occur, all of the following conditions must be met:
–
–
–
•
For flows that match a CSG policy with accounting type http, if the response from the server spans multiple packets, and the CSG downgrades to Layer 4 inspection, the CSG might generate incorrect CDRs.
For this problem to occur, all of the following conditions must be met:
–
–
–
–
–
•
With some RTSP players, the CSG does not report the end of all flows in an RTSP stream precisely when the stream ends. That can result in the following problems:
–
–
For this problem to occur, all of the following conditions must be met:
–
–
–
•
For flows that match a CSG policy with accounting type http, some client browsers/servers that generate pipelined request/responses can cause an incorrect download byte count for the last analyzed policy or an abnormal termination of the session.
For this problem to occur, all of the following conditions must be met:
–
–
–
•
For RTSP, the CSG might set byte counts to zero in intermediate CDRs that are configured with fixed-format billing.
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
•
The CSG generates a high volume of CDRs for an HTTP application that sends a Content Length header that exceeds 0x0FFFFFFF. If billing is prepaid, the CSG might request additional quota.
For this problem to occur, all of the following conditions must be met:
–
–
•
When parsing HTTP client data, if a HEAD method is preceded by whitespace, the CSG might incorrectly parse subsequent HTTP messages on the same session.
•
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:
–
–
•
When there are retransmitted SYNs and SYN/ACKs for an RTSP control session, the CSG can receive a SYN after seeing a SYN/ACK. This might result in the CSG reporting a zero TCP byte count for the RTSP CDR.
•
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:
–
–
–
–
•
When configuring more than one CSG content service with the same 3-bit IP address for different protocols, the CSG might log the following message when it attempts to install the static route for the specified IP address:
%CSM_SLB-3-ERROR: Module 1 error: lcsc_vlan_add_static_route: route exist -route(ff0000ff) mask(ffffffff) gateway(46000004)
You can ignore this message.
•
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
•
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 61% 153MAllocated Memory 31% 79MOS Static Memory 8% 22MLowest Memory Available 153M THU MAR 23 21:53:31 2006CSG CPU Utilization: 1m (0.0%), 5m (0.0%)To disable debugging output for CPU Utilization, 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 length and body are in separate packets, then the CSG might drop the first HTTP POST request.
•
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 v 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:
–
–
–
•
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:
–
–
Caveats for 3.1(3)C5(9a)
This section lists and describes all caveats, both open and closed, that affect CSG software release 3.1(3)C5(9a).
For information about open caveats in the Content Services Gateway 3.1(3)C5(9a) 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)C5(9a) - Open Caveats
The following list identifies open caveats in CSG Release 3.1(3)C5(9a).
•
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 using a CSG policy with accounting type http and a client using HTTP pipelining, client browsing speed might be reduced.
Sample packet (pkt) sequence:
a.
b.
c.
d.
e.
f.
For this problem to occur, all of the following conditions must be met:
–
–
–
–
Workaround: None.
•
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.
•
TCP byte counts can be off by one byte in the following situations:
–
–
Workaround: None.
CSG Release 3.1(3)C5(9a) - Closed Caveats
The following section lists bugs that are closed in CSG Release 3.1(3)C5(9a).
•
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:
–
–
–
–
Caveats for 3.1(3)C5(9)
This section lists and describes all caveats, both open and closed, that affect CSG software release 3.1(3)C5(9).
For information about open caveats in the Content Services Gateway 3.1(3)C5(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)C5(9) - Open Caveats
The following list identifies open caveats in CSG Release 3.1(3)C5(9).
•
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 using a CSG policy with accounting type http and a client using HTTP pipelining, client browsing speed might be reduced.
Sample packet (pkt) sequence:
a.
b.
c.
d.
e.
f.
For this problem to occur, all of the following conditions must be met:
–
–
–
–
Workaround: None.
•
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.
•
TCP byte counts can be off by one byte in the following situations:
–
–
Workaround: None.
CSG Release 3.1(3)C5(9) - Closed Caveats
The following section lists bugs that are closed in CSG Release 3.1(3)C5(9).
•
WAP1 billing for CONNECT transactions might not be accurate. When a WAP CONNECT transaction completes before the service authorization response is received for that transaction, the CONNECT transaction is rolled into the first content-based transaction that follows. If the first content-based transaction is a GET/POST, then the CONNECT bytes are charged as if they were part of the GET/POST transaction.
•
The CDRs for one stream of an RTSP session were delayed in comparison to another stream
•
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:
–
–
–
•
WAP1-WSP concatenation does not work when used with a CSG policy containing a next-hop configuration. Traffic is not sent to the desired next hop.
For this problem to occur, all of the following conditions must be met:
–
–
–
•
The RTSP parsing for the return code from the server is incorrect. This results in an RTSP billing record with an invalid RTSP return code.
For this problem to occur, all of the following conditions must be met:
–
–
•
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.
•
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 might 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 Catalyst 6000 family switch performance and might lead to an IOS crash.
•
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.
•
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
•
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.
•
The CSG might report incorrect download bytes in the billing record. If the traffic is IP fragmented, the CSG reports somewhere in the range of the total bytes downloaded all against one record of the pipelined request. If the traffic is not IP fragmented, the CSG reports a very large download record (0xFFFFxxxx).
For this problem to occur, all of the following conditions must be met:
–
–
–
•
With the HTTPS Connect method, the download bytes of the response packet from the proxy server are not counted.
For this problem to occur, all of the following conditions must be met:
–
–
–
This problem occurs when the proxy server sends the response for the CONNECT request in two packets: "HTTP/1.0 200 Connection established" in the first packet and "Proxy-Agent" header in the second packet. The result is that the CSG does not count the first packet in the TCP download byte count.
•
The CSG does not block WAP 1.X traffic when the user is known but the billing plan is UNKNOWN.
For this problem to occur, all of the following conditions must be met:
–
–
–
•
When using a CSG policy with accounting type http, if two server packets reach the CSG almost simultaneously the CSG might stop analyzing the packets and stop forwarding server responses.
Sample packet (pkt) sequence:
a.
b.
c.
d.
e.
f.
For this problem to occur, all of the following conditions must be met:
–
–
–
•
The CSG might generate a CDR that contains an invalid Content-Provider TLV, or subsequent TLVs following the Content-Provider TLV might be corrupted. The exact conditions leading to this issue are still unknown. This issue does occur in CSG firmware in which CSCsa94380 is already resolved.
•
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.
Sample packet (pkt) sequence:
a.
b.
c.
d.
e.
f.
Since the FIN (pkt3) arrived at the CSG before it forwarded pkt2, the CSG erroneously excluded the byte count for pkt1 from the charging.
For this problem to occur, all of the following conditions must be met:
–
–
–
•
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. the external symptom is that the HTTP transaction does not complete.
For this problem to occur, all of the following conditions must be met:
–
–
–
If the above conditions are met, the CSG sends a TCP ACK to trigger the client to send the second packet containing the remaining HTTP headers. The problem occurs because the CSG does not forward the continuation packet to the server and the session subsequently times out.
•
HTTP inspection of IP fragmented traffic might undercharge when the fragments split the HTTP headers in the client request. Buffer counts in the CSG show tech are not correct.
For this problem to occur, all of the following conditions must be met:
–
–
–
–
•
When pipelined HTTP requests spanning multiple packets are fragmented, IP fragmented HTTP traffic might cause the user session to hang and reset.
For this problem to occur, all of the following conditions must be met:
–
–
–
–
•
The SMTP CDR might contain a different error code than the one generated by the mail server.
For this problem to occur, all of the following conditions must be met:
–
–
When the mail server returns an error code to one of the mail commands, the CSG might not include that exact error code in the CDR, but instead uses the generic error code 554.
•
When 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.
For this problem to occur, all of the following conditions must be met:
–
–
–
–
•
If an RTSP stream is interrupted, and if the session stays idle for 10 seconds, 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:
–
–
–
•
The CSG might not forward a multipart POST to the server, and might RST the session.
For this problem to occur, all of the following conditions must be met:
–
–
–
•
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:
–
–
–
•
During normal operation, the CSG crashes with error PPC exception type 666 on 'PktDrv Wdog.
•
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).
Caveats for 3.1(3)C5(8a)
This section lists and describes all caveats, both open and closed, that affect CSG software release 3.1(3)C5(8a).
For information about open caveats in the Content Services Gateway 3.1(3)C5(8a) 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)C5(8a) - Open Caveats
The following list identifies open caveats in CSG Release 3.1(3)C5(8a).
•
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.
•
WAP1 billing for CONNECT transactions might not be accurate. When a WAP CONNECT transaction completes before the service authorization response is received for that transaction, the CONNECT transaction is rolled into the first content-based transaction that follows. If the first content-based transaction is a GET/POST, then the CONNECT bytes are charged as if they were part of the GET/POST transaction.
Workaround: None.
•
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 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:
–
–
–
Workaround: None.
•
The RTSP parsing for the return code from the server is incorrect. This results in an RTSP billing record with an invalid RTSP return code.
For this problem to occur, all of the following conditions must be met:
–
–
Workaround: None.
•
The CDRs for one stream of an RTSP session were delayed in comparison to another stream
Workaround: Use the content idle timer to limit the length of time the UDP sessions remain open after traffic goes idle. If doing byte-based or fixed billing, this delays the stream/UDP CDRs by the length of the idle time. If doing time-based billing, the charge includes the length of the idle time, which might not be desirable. However, the CDR that is generated includes a timeout field to indicate that the session idled out. you can use this indicator to deduct or refund the user by the amount of the idle.
•
WAP1-WSP concatenation does not work when used with a CSG policy containing a next-hop configuration. Traffic is not sent to the desired next hop.
For this problem to occur, all of the following conditions must be met:
–
–
–
Workaround: None, if the customer requires accounting type wap and next-hop for the same flow.
•
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 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.
•
With the HTTPS Connect method, the download bytes of the response packet from the proxy server are not counted.
For this problem to occur, all of the following conditions must be met:
–
–
–
This problem occurs when the proxy server sends the response for the CONNECT request in two packets: "HTTP/1.0 200 Connection established" in the first packet and "Proxy-Agent" header in the second packet. The result is that the CSG does not count the first packet in the TCP download byte count.
Workaround: None.
•
The CSG does not block WAP 1.X traffic when the user is known but the billing plan is UNKNOWN.
For this problem to occur, all of the following conditions must be met:
–
–
–
Workaround: None.
•
When using a CSG policy with accounting type http, if two server packets reach the CSG almost simultaneously the CSG might stop analyzing the packets and stop forwarding server responses.
Sample packet (pkt) sequence:
a.
b.
c.
d.
e.
f.
For this problem to occur, all of the following conditions must be met:
–
–
–
Workaround: None.
•
The CSG might generate a CDR that contains an invalid Content-Provider TLV, or subsequent TLVs following the Content-Provider TLV might be corrupted. The exact conditions leading to this issue are still unknown. This issue does occur in CSG firmware in which CSCsa94380 is already resolved.
Workaround: None.
•
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.
Sample packet (pkt) sequence:
a.
b.
c.
d.
e.
f.
Since the FIN (pkt3) arrived at the CSG before it forwarded pkt2, the CSG erroneously excluded the byte count for pkt1 from the charging.
For this problem to occur, all of the following conditions must be met:
–
–
–
Workaround: None.
•
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. the external symptom is that the HTTP transaction does not complete.
For this problem to occur, all of the following conditions must be met:
–
–
–
If the above conditions are met, the CSG sends a TCP ACK to trigger the client to send the second packet containing the remaining HTTP headers. The problem occurs because the CSG does not forward the continuation packet to the server and the session subsequently times out.
Workaround: None.
•
HTTP inspection of IP fragmented traffic might undercharge when the fragments split the HTTP headers in the client request. Buffer counts in the CSG show tech are not correct.
For this problem to occur, all of the following conditions must be met:
–
–
–
–
Workaround: None, if accounting type http is required.
•
When pipelined HTTP requests spanning multiple packets are fragmented, IP fragmented HTTP traffic might cause the user session to hang and reset.
For this problem to occur, all of the following conditions must be met:
–
–
–
–
Workaround: None, if accounting type http is required.
•
The SMTP CDR might contain a different error code than the one generated by the mail server.
For this problem to occur, all of the following conditions must be met:
–
–
When the mail server returns an error code to one of the mail commands, the CSG might not include that exact error code in the CDR, but instead uses the generic error code 554.
Workaround: None.
•
When 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.
For this problem to occur, all of the following conditions must be met:
–
–
–
–
Workaround: None, if accounting type http 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)C5(8a) - Closed Caveats
The following section lists bugs that are closed in CSG Release 3.1(3)C5(8a).
•
The CSG crashes with the following log message:
%CSM_SLB-3-UNEXPECTED: Module 7 unexpected error: IXP3 exception encountered
If a backup CSG is present, the backup takes over.
•
The CSG encounters an FPGA hang and crashes with the following console message:
IXP3 Software exception on task 'IXP3 SA-CORE (Ex 18)(00000000h)'
•
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.
Caveats for 3.1(3)C5(8)
This section lists and describes all caveats, both open and closed, that affect CSG software release 3.1(3)C5(8).
For information about open caveats in the Content Services Gateway 3.1(3)C5(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)C5(8) - Open Caveats
The following list identifies open caveats in CSG Release 3.1(3)C5(8).
•
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 CDRs for one stream of an RTSP session were delayed in comparison to another stream
Workaround: If a content idle timer is used, then the disassociated session is destroyed after the timer expires and the CDRs are generated.
•
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 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.
•
With the HTTPS Connect method, the download bytes of the response packet from the proxy server are not counted.
For this problem to occur, all of the following conditions must be met:
–
–
–
This problem occurs when the proxy server sends the response for the CONNECT request in two packets: "HTTP/1.0 200 Connection established" in the first packet and "Proxy-Agent" header in the second packet. The result is that the CSG does not count the first packet in the TCP download byte count.
Workaround: None.
CSG Release 3.1(3)C5(8) - Closed Caveats
The following section lists bugs that are closed in CSG Release 3.1(3)C5(8).
•
WAP1 connectionless buffers might be leaked with 0 quota and the exclude mms option configured.
•
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.
•
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.
•
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 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.
•
HTTP transaction CDRs might be generated when using a user database, even though service-level CDRs are configured.
•
Correlators ID in Content Authorization Request and the related SMTP CDR do not match exactly.
•
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)'."
•
CSG diagnostic messages of the form TRAP xxxx appear even if TRAP is not enabled, and even if no other side effects are present.
•
This problem manifests itself in the following ways:
a.
b.
This problem occurs when there is a large amount of internal messaging within the CSG. For example, this problem can occur in the following situations:
–
–
- Removal of Ruleset and Accounting configurations.
- Reduction of IDLE timer definition that causes a number of idle connection to immediately trigger for timeout.
- Introduction of new billing rules that cause large numbers of existing sessions to close.
The issue is timing-dependent and does not appear all the time.
•
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.
•
When performing RTSP downloads over TCP or HTTP, the TCP upload byte count for an RTSP interleaved connection is under-reported by one byte.
•
Some of the information stored in a core dump might be truncated when displayed using the show tech command.
•
The username TLV is not located in a WAP CDR, or the first transaction of a WAP session is not associated with a service. The first flow for a WAP transaction is fragmented, or it is not a packet that typically initiates a WAP transaction (that is, the first flow is not a CONNECT, GET, POST, or PUSH).
•
Under stress, memory buffers for FTP data connections might not be freed.
•
When running HTTP-type traffic through an HTTP-type content (filter type HTTP), some buffers might leak. Even under stress, this is a slow leak. The leak occurs when the CSG receives a server reset immediately following HTTP response data packets which the CSG determines need to be analyzed to determine content length. Normal FIN-terminated connections do not see any buffer leaks.
•
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.
•
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.
•
When a client is pipelining, it sends packets that contain two or more requests. The last request in such a packet could be a partial request. When the CSG receives such a packet, it forwards it to the server. However, sometimes when packets are delayed or dropped, the CSG waits for the client to send the remaining part of the request. Because the client is pipelining, it should send the next packet, which contains the remaining part. A client could become circumspect and stop pipelining if there is packet loss in the network which results in retransmits. If the client expects an ACK for the previous packet and it does not receive an ACK, it keeps retransmitting the previous packet. After timeout, the client gives up.
•
The CSG sends CDRs to the BMA server that might contain Content-Provider TLVs that contain incorrect data and are not structured correctly.
•
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 erroneously 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.
•
When an HTTP connections converts to HTTPS via the Connect Method, uploaded TCP bytes of continuation packets might not get counted. The connection succeeds, but the bytes are undercharged.
•
The CSG reports incorrect downLoadBytesTCP 1501767. This problem occurs when a TCP session for HTTP is closed in one direction (server-to-mobile) and the Mobile is sending a TCP RST.
Caveats for 3.1(3)C5(7)
This section lists and describes all caveats, both open and closed, that affect CSG software release 3.1(3)C5(7).
For information about open caveats in the Content Services Gateway 3.1(3)C5(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)C5(7) - Open Caveats
The following list identifies open caveats in CSG Release 3.1(3)C5(7).
•
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 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.
CSG Release 3.1(3)C5(7) - Closed Caveats
The following section lists bugs that are closed in CSG Release 3.1(3)C5(7).
•
The CSG mistakenly responds to GET and GETNEXT requests for the CISCO-SLB_MIB.
•
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 CSG's User Table 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.
•
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.
•
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.
•
FTP control session packets might not be forwarded 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.
•
An RTSP stream download may hang or fail to complete.
•
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.
•
When using the Sanyo S750 handset, HTTP web pages with multiple embedded objects can fail to load.
Caveats for 3.1(3)C5(6)
This section lists and describes all caveats, both open and closed, that affect CSG software release 3.1(3)C5(6).
For information about open caveats in the Content Services Gateway 3.1(3)C5(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)C5(6) - Open Caveats
The following list identifies open caveats in CSG Release 3.1(3)C5(6).
•
The CSG mistakenly responds to GET and GETNEXT requests for the CISCO-SLB_MIB.
Workaround: For normal polling of IOS SLB MIB variables, do not configure your management system to poll the CSG. This reduces the number of cases where this is an issue. The issue remains in the event of a MIB walk; there is no workaround for that condition.
CSG Release 3.1(3)C5(6) - Closed Caveats
The following section lists bugs that are closed in CSG Release 3.1(3)C5(6).
•
New features added in CSG R5 have resulted in a performance drop of approximately 15%, compared to CSG R4.
•
The CSG supports only port 554 for RTSP; the CSG blocks the configuration of other ports during initial configuration. However, after the initial configuration, the CSG mistakenly allows you to configure an RTSP policy with a port other than 554.
•
The URL map does not match without a wildcard (*). A wildcard might have to be added to the end of the match command.
For example, when matching "bond.mm.wdss.ntc.nokia.com:443", the following match command:
match protocol http method CONNECT url bond.mm.wdss.ntc.nokia.com:443
does not match, even though it appears to be an exact match.
•
The CSG might send a billing plan ID TLV with a zero-length billing plan ID. This problem might occur for postpaid users who are not subscribed to a billing plan.
•
HTTP_Stats records show bytes up/down as 0/0. Appears to be specific to sites that have servers that cannot handle client requests with multiple GETs in a single packet. In such cases, the server responds only to the first request, then closes the connection. For each request that the server does not respond to, the CSG correctly reports 0 bytes downloaded, but mistakenly reports 0 bytes uploaded, resulting in an undercharge for the upload portion. The first request, which was properly responded to by the server, is correctly reported.
•
When performing interleaved RTSP (that is, all data is downloaded over a TCP control connection), the CSG sometimes ignores the allotted quota, allowing it to be exceeded.
•
After the CSG redirected a WAP 1.2 request, it forwarded a WTP acknowledgement from the WAP client to the WAP gateway. The CSG should have dropped the acknowledgement.
•
Stateful failover is not working for CSG policies that are configured with accounting type ftp. During failover, FTP connections that are open either hang or reset.
•
After a token is stripped and the GET is allowed through, the CSG drops any additional GETs on that same connection. Subsequent GETs on a new connection are allowed through.
•
If a service configured with records granularity bytes is active for a user when a CSG failover occurs, the CSG might generate one or more time-based service_usage records before the service idles out. Also, the CSG resets to 0 the sequence numbers for records generated after the failover.
•
The second packet in an RTSP stream initiated from the server might be dropped if it arrives very soon after the first packet.
•
In duration-based billing, if a user runs out of quota during the download of RTSP content, the user is note cut off and the download is allowed to complete. However, the user is not allowed to start a new session without quota.
•
By default, the RTSP control session is mapped to the first policy under the RTSP content definition. This prevents the flexibility of assigning a policy other than those used for URL mapping.
•
If the CSG is configured for RADIUS POD, and a failover occurs, the new standby CSG's User Table might display the POD attributes multiple times.
•
The CSG's baseline performance is improved relative to CSG R5.5.
•
If a RADIUS handoff timer is configured, then a connect time billing service adds this timer amount to the usage in the service_stop.
•
The RADIUS proxy "parse error" counter increments when no error has occurred.
•
When an HA failover occurs on the standby CSG, the CSG prepaid service might idle out before the configured idle time has passed. For time-based billing, this might result in reduced billing.
•
If fault-tolerant CSGs are being load-balanced with the CMX director, and a user connects using a handset that sends a concatenated Connect-Get, the CSG splits the packet, first sending the Connect, then sending the Get. The CSG uses its own MAC address when sending these packets instead of the alias MAC address, which causes the FWLB to route the packets to the wrong CSG.
•
If a proxy or gateway multiplexes users over a single TCP connection and pipelines their HTTP requests, the CSG might not bill the users correctly.
•
If multiple RADIUS proxies are configured, and a NAS client uses the multiple RADIUS proxies with the same port number, one RADIUS proxy might respond with the source IP of another RADIUS proxy.
•
If a SYN hits an RTSP/FTP content and the server does not respond, the CSG creates a connection that does not time out.
•
PacketVideo Server's FastTrack progressive download mechanism uses "Content-Type: multipart", and includes additional headers that are not reflected in the content size header. This causes the CSG to report lower byte counts in the Usage TLV than were actually transferred, because the CSG notices that there is data beyond the spot where it thought the payload should end.
•
The CSG returns an incorrect quota when acknowledgements are received out of order as a result of to retransmission at the client.
•
Traceback messages issued by the CSG are not rate-limited.
•
The CSG might miscalculate the number of TCP download bytes when traffic is HTTP and persistent, but the server closes the session after the first GET.
•
The CSG incorrectly reports the CPU utilization for the TCP IXP as 100%.
•
The output of the show module csg all content detail command for FTP contents shows 0 total connections, 0 client packets, and 0 server packets, even if many connections have completed.
•
HSRP requires you to configure either a route or default gateway for the HSRP standby/virtual IP. This enables the CSG to actively monitor the HSRP HELLO message to track the physical IP and MAC addresses of the HSRP devices. This HSRP monitoring enabled the CSG to forward the return traffic to the standby/virtual HSRP address.
This change eliminates the need to configure the route or default gateway for HSRP, if you use next-hop to direct return traffic to the standby/virtual HSRP address.
•
In a Catalyst 6500 with a CSM module installed using bridge mode, with span enabled on the port channel to the CSM or any of the VLANs that the CSM is bridging, If the switch receives a corrupt packet on one of the VLANs (most likely a packet with an invalid IP length field), the following symptoms might be observed:
–
–
–
–
•
When configuring a CSG for accounting RTSP sessions, the most-significant 48 bits in the CDR's Correlator value are identical for all streams associated with a given RTSP control session. For the control session itself, the least-significant 16 bits are 0x0000. For each new stream associated with this session, the Correlator value should increase by two. However, the Correlator value might incorrectly increase by more than two, and the two CDRs associated with the two UDP streams might incorrectly carry the same Correlator value.
Caveats for 3.1(3)C5(5)
This section lists and describes all caveats, both open and closed, that affect CSG software release 3.1(3)C5(5).
For information about open caveats in the Content Services Gateway 3.1(3)C5(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)C5(5) - Open Caveats
The following list identifies open caveats in CSG Release 3.1(3)C5(5).
•
New features added in CSG R5 have resulted in a performance drop of approximately 15%, compared to CSG R4.
Workaround: None.
•
The CSG supports only port 554 for RTSP; the CSG blocks the configuration of other ports during initial configuration. However, after the initial configuration, the CSG mistakenly allows you to configure an RTSP policy with a port other than 554.
Workaround: None.
•
The URL map does not match without a wildcard (*). A wildcard might have to be added to the end of the match command.
For example, when matching "bond.mm.wdss.ntc.nokia.com:443", the following match command:
match protocol http method CONNECT url bond.mm.wdss.ntc.nokia.com:443
does not match, even though it appears to be an exact match.
Workaround: Add a wildcard to end of match command:
match protocol http method CONNECT url bond.mm.wdss.ntc.nokia.com:443*
•
The CSG mistakenly responds to GET and GETNEXT requests for the CISCO-SLB_MIB.
Workaround: For normal polling of IOS SLB MIB variables, do not configure your management system to poll the CSG. This reduces the number of cases where this is an issue. The issue remains in the event of a MIB walk; there is no workaround for that condition.
•
The CSG might send a billing plan ID TLV with a zero-length billing plan ID. This problem might occur for postpaid users who are not subscribed to a billing plan.
Workaround: None.
•
HTTP_Stats records show bytes up/down as 0/0. Appears to be specific to sites that have servers that cannot handle client requests with multiple GETs in a single packet. In such cases, the server responds only to the first request, then closes the connection. For each request that the server does not respond to, the CSG correctly reports 0 bytes downloaded, but mistakenly reports 0 bytes uploaded, resulting in an undercharge for the upload portion. The first request, which was properly responded to by the server, is correctly reported.
Workaround: None.
•
Stateful failover is not working for CSG policies that are configured with accounting type ftp. During failover, FTP connections that are open either hang or reset.
Workaround: Remove replicate connection tcp from all contents with accounting type ftp.
CSG Release 3.1(3)C5(5) - Closed Caveats
The following section lists bugs that are closed in CSG Release 3.1(3)C5(5).
•
One of the following problems is seen:
–
–
–
Caveats for 3.1(3)C5(4.67)
This section lists and describes all caveats, both open and closed, that affect CSG software release 3.1(3)C5(4.67).
For information about open caveats in the Content Services Gateway 3.1(3)C5(4.67) 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)C5(4.67) - Open Caveats
The following list identifies open caveats in CSG Release 3.1(3)C5(4.67).
•
New features added in CSG R5 have resulted in a performance drop of approximately 15%, compared to CSG R4.
Workaround: None.
CSG Release 3.1(3)C5(4.67) - Closed Caveats
The following section lists bugs that are closed in CSG Release 3.1(3)C5(4.67).
•
WAP1 connectionless buffers might be leaked with 0 quota and the exclude mms option configured.
•
WAP1 billing for CONNECT transactions might not be accurate. When a WAP CONNECT transaction completes before the service authorization response is received for that transaction, the CONNECT transaction is rolled into the first content-based transaction that follows. If the first content-based transaction is a GET/POST, then the CONNECT bytes are charged as if they were part of the GET/POST transaction.
•
CSG diagnostic messages of the form TRAP xxxx appear even if TRAP is not enabled, and even if no other side effects are present.
•
If a next-hop IP address is defined in the WAP policy being used, WAP 1.x packets might be dropped.
•
The username TLV is not located in a WAP CDR, or the first transaction of a WAP session is not associated with a service. The first flow for a WAP transaction is fragmented, or it is not a packet that typically initiates a WAP transaction (that is, the first flow is not a CONNECT, GET, POST, or PUSH).
•
When an RTSP control session is created but no corresponding UDP data sessions are ever established, the RTSP session pool might contain a non zero in-use value after all RTSP p sessions have terminated and cleaned up. This is a buffer leak.
•
Traceback issued on console. Double free of RTSP memory.
•
WAP1-WSP concatenation does not work when used with a CSG policy containing a next-hop configuration. Traffic is not sent to the desired next hop.
For this problem to occur, all of the following conditions must be met:
–
–
–
•
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 needs to be able to copy coredumps using RCP.
•
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.
•
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 erroneously 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.
•
The CSG does not block WAP 1.X traffic when the user is known but the billing plan is UNKNOWN.
For this problem to occur, all of the following conditions must be met:
–
–
–
•
The CSG might generate a CDR that contains an invalid Content-Provider TLV, or subsequent TLVs following the Content-Provider TLV might be corrupted. The exact conditions leading to this issue are still unknown. This issue does occur in CSG firmware in which CSCsa94380 is already resolved.
•
The SMTP CDR might contain a different error code than the one generated by the mail server.
For this problem to occur, all of the following conditions must be met:
–
–
When the mail server returns an error code to one of the mail commands, the CSG might not include that exact error code in the CDR, but instead uses the generic error code 554.
Caveats for 3.1(3)C5(4.48)
This section lists and describes all caveats, both open and closed, that affect CSG software release 3.1(3)C5(4.48).
For information about open caveats in the Content Services Gateway 3.1(3)C5(4.48) 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)C5(4.48) - Open Caveats
The following list identifies open caveats in CSG Release 3.1(3)C5(4.48).
•
New features added in CSG R5 have resulted in a performance drop of approximately 15%, compared to CSG R4.
Workaround: None.
CSG Release 3.1(3)C5(4.48) - Closed Caveats
The following section lists bugs that are closed in CSG Release 3.1(3)C5(4.48).
•
Traffic on an RTSP data session might be blocked or not associated with the RTSP content definition.
•
FTP control session packets might not be forwarded when next-hop routing is specified.
•
An RTSP stream download may hang or fail to complete.
•
In a Catalyst 6500 with a CSM module installed using bridge mode, with span enabled on the port channel to the CSM or any of the VLANs that the CSM is bridging, If the switch receives a corrupt packet on one of the VLANs (most likely a packet with an invalid IP length field), the following symptoms might be observed:
–
–
–
–
Caveats for 3.1(3)C5(4.44)
This section lists and describes all caveats, both open and closed, that affect CSG software release 3.1(3)C5(4.44).
For information about open caveats in the Content Services Gateway 3.1(3)C5(4.44) 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)C5(4.44) - Open Caveats
The following list identifies open caveats in CSG Release 3.1(3)C5(4.44).
•
New features added in CSG R5 have resulted in a performance drop of approximately 15%, compared to CSG R4.
Workaround: None.
CSG Release 3.1(3)C5(4.44) - Closed Caveats
The following section lists bugs that are closed in CSG Release 3.1(3)C5(4.44).
•
The CSM is hanging on an "ICMP destination unreachable" message.
•
When headers cause a CDR to split, all Continue messages containing RADIUS attributes are flagged as the last.
•
In a situation in which the CSG must "steal" buffers for new subscribers exceeding the configured limit, the CSG might leak some buffers. This is a very slow leak (10 days to 2 weeks), even under extreme stress.
•
The URL map does not match without a wildcard (*). A wildcard might have to be added to the end of the match command.
For example, when matching "bond.mm.wdss.ntc.nokia.com:443", the following match command:
match protocol http method CONNECT url bond.mm.wdss.ntc.nokia.com:443
does not match, even though it appears to be an exact match.
•
When traffic is high, the CSG might hang or crash as a result of an improper session list.
When running in a stateful and prepaid configuration, with enough diverse traffic to push it to or above its limit, the CSG might crash.
•
If the CSG is processing an Authorize content request and the User Table is nearing or is at capacity, the CSG might crash.
•
The backup CSG might crash after becoming active after a failover (when the active CSG fails or is reset) with a high volume of WAP connection/connectionless traffic.
•
When running prepaid HTTP traffic with AoC configured and Quota Server Cause code 3, the redirect fails.
•
After the CSG redirected a WAP 1.2 request, it forwarded a WTP ACK from the WAP client to the WAP gateway. The correct behavior should be to drop the ACK.
•
Stateful failover is not working for CSG policies configured with accounting type = ftp. Billing information is not replicated and FTP connections that are open during a failover hang or reset.
•
If a service with records granularity bytes configured is active for a user when a CSG failover occurs, one or more time-based service_usage records might be generated before the service idles out. Because no timer value has been configured, no time-based service_usage records should be sent by CSG. Also, records generated after the failover have the sequence number reset to 0.
•
When an HA failover occurs on the standby CSG, the CSG prepaid service might idle out before the configured idle time has passed. For time-based billing, this might result in reduced billing.
•
If fault-tolerant CSGs are being load-balanced with the CMX director, and a user connects using a handset that sends a concatenated Connect-Get, the CSG splits the packet, first sending the Connect, then sending the Get. The CSG uses its own MAC address when sending these packets instead of the alias MAC address, which causes the FWLB to route the packets to the wrong CSG.
•
After a failover a new duration service/session might show 103 years of consumption.
•
The reserved quota field on the backup CSG's User Table 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.
•
The CSG running might crash with Billingstack SUSPEND. This can occur when the user agent field in an HTTP header exceeds 160 bytes.
•
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 configuring a CSG for accounting RTSP sessions, the most-significant 48 bits in the CDR's Correlator value are identical for all streams associated with a given RTSP control session. For the control session itself, the least-significant 16 bits are 0x0000. For each new stream associated with this session, the Correlator value should increase by two. However, the Correlator value might incorrectly increase by more than two, and the two CDRs associated with the two UDP streams might incorrectly carry the same Correlator value.
•
The CSM might core-dump while processing an ICMP destination-unreachable packet.
–
–
–
Caveats for 3.1(3)C5(4.18)
This section lists and describes all caveats, both open and closed, that affect CSG software release 3.1(3)C5(4.18).
For information about open caveats in the Content Services Gateway 3.1(3)C5(4.18) 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)C5(4.18) - Open Caveats
The following list identifies open caveats in CSG Release 3.1(3)C5(4.18).
•
New features added in CSG R5 have resulted in a performance drop of approximately 15%, compared to CSG R4.
Workaround: None.
CSG Release 3.1(3)C5(4.18) - Closed Caveats
The following section lists bugs that are closed in CSG Release 3.1(3)C5(4.18).
•
Multiple media files can be streamed one after the other. The customer sees that with a certain phone, and only with PacketVideo, the CSG generates a usage record containing the bytes and packets of all of the separate media files added together and reported with just the URL of the first media file.
•
The RTSP Stream record shows the URL of the stream in a URL TLV. The URL is not reported correctly (it is garbled) when HTTP is used for the transport of the streaming media.
•
CDR counts for FTP data channel may be incorrect when the CSG fails over. The count could be either more or less than the number of bytes actually transferred.
•
There is a slow memory leak.
•
WAP 1.2 requests with the WSP HEAD method (0x42) are incorrectly reported by source CSG as the GET (0x40) method in a BMA/QS WSP PDU Type TLV.
•
The CSG might become unresponsive if the accounting group configuration is removed from under the ruleset on the CSG card level configuration while users are being created and deleted.
•
If the customer-string is configured with the maximum number of characters (16) extra characters might be included in the CDR, or storage might be corrupted, leading to a crash.
•
The CSG might go offline intermittently after an RPR+ supervisor switchover. This has been seen most frequently when forcing RPR+ switchover by physically pulling the active Supervisor card from the chassis without shutting it down first. Other failures are seen with other Supervisor failures, though less frequently.
•
The CSG can hang when processing IP fragments for WAP.
•
Subscriber traffic passing through the CSG might not be redirected when the user is denied access to a prepaid service. This problem might occur when the quota server grants 0 quadrans in a Service Authorization Response and specifies a cause code of 0x03. The service must have a quota balance greater than 0.
•
The amount of quota returned by the CSG for a service might be incorrect. This problem occurs when the quota return is triggered by a Service List TLV in the Service Authorization Response.
•
During a persistent HTTP session with an HTTP request that spans more than one packet, only the first packet of the request might get forwarded, and the session eventually is terminated. This issue might occur when running L7 (http) traffic with type HTTP policies if an HTTP request spans more than one TCP packet and is not the first request on a persistent HTTP connection.
•
In rare situations, the CSG might not count a packet in the CDR or prepaid information for an e-mail transfer.
•
When the CSG_HTTP_1_0_OPERATION variable is set, the CSG does not translate the HTTP 1.1 transactions to HTTP 1.0 transactions, and TCP checksum failures can occur.
•
When using the CSG in a redundancy setup, the backup CSG can hang.
Caveats for 3.1(3)C5(4)
This section lists and describes all caveats, both open and closed, that affect CSG Release 3.1(3)C5(4).
For information about open caveats in the Content Services Gateway 3.1(3)C5(4) release, see the Cisco Bug Toolkit at the following URL:
http://www.cisco.com/pcgi-bin/Support/Bugtool/home.pl.
CSG Release 3.1(3)C5(4) - Open Caveats
The following list identifies open caveats in CSG Release 3.1(3)C5(4).
•
New features added in CSG R5 have resulted in a performance drop of approximately 15%, compared to CSG R4.
Workaround: None.
CSG Release 3.1(3)C5(4) - Closed Caveats
The following section lists bugs that are closed in CSG Release 3.1(3)C5(4).
•
When there are two CSGs configured to perform stateful backup in a single chassis, and RPR+ failover occurs, it is possible for both CSGs to become active.
•
CSG is sending unexpected RST packets
•
If the service timeout TLV value is zero, and CSG receives a large quadran value, such as 0x7FFFFFFF (2147483647 quadrans), in a Service Authorization Response message, the subscriber balance entry might overrun to a negative value.
•
During high stress, some sessions might get stuck in an active state, even though the session has closed. If interim records is enabled, CSG periodically sends CDRs for these sessions to the BMA.
•
When internal processes fail, CSG might stop passing traffic and might not failover to the backup CSG.
•
If you session into the primary CSG and upgrade the image, the standby CSG becomes active and both CSGs are active until the upgrade completes.
•
Enabling or disabling certain commands on a live system can cause existing User Table entries to become out-of-sync between the active and standby CSGs. The commands that are known to cause problems are replicate under a content and ip csg block.
•
Removing the usergroup configuration from accounting while CSG is running under load can cause a CSG crash.
•
If there is a firewall between CSG and the server, the client port numbers in the setup response might be overwritten with port numbers other than the ones in the SETUP request. This stops the download and resets the TCP connection supporting the RTSP control.
•
The CSG stops forwarding traffic and does not fail over. This issue might occur over time if running L7 (HTTP) traffic with type HTTP policies due to error events, such as the client or server issuing a TCP reset, prior to the first HTTP GET request.
•
Under heavy data traffic load, CSG might overrun its internal stack while sending large numbers of CDRs, resulting in a machine check.
•
There is an Intel hardware bug on the IXP1200 series that causes a catastrophic failure when an RTN or JUMP instruction immediately follows a Class 3 instruction. Software must be changed to avoid this sequence, therefore avoiding the failure.
•
If RTSP content inspection is configured, CSG might crash due to a timerwheel exception.
•
CSG can crash in BillingStack under stress.
•
When the CSG performs URL redirection with WAP1.2 traffic, if the total length of the URL is greater than 127 bytes, the packets might become corrupted. The problem occurs with the CSG_WAP_APPEND_AOC_URL variable set to either 0 or 1.
•
CSG might exhaust its pool of small buffers over time. This error is specific to traffic that uses accounting type SMTP or POP3 when error conditions occur during client/server TCP session setup.
•
When a user is postpaid but no postpaid billing plan is configured, the Username TLV is omitted from the IP, UDP, or HTTP_header CDR.
•
If a BMA or quota server becomes inactive, any Continue messages saved in the GTP retransmit queue are not sent when the BMA or quota server becomes active again. Additionally, any other messages in the retransmit queue might take a very long time to be sent, as the Continue messages are deleted - one per attempt to drain the retransmit queue.
•
CSG stops forwarding traffic and does not fail over. This issue might occur over time if running traffic with type WAP, SMTP, or POP3 policies. It is more likely to occur when the traffic contains IP fragmentation.
•
When multiple URLs are downloaded over the same UDP session, the CSG might not report all of the URLs. This problem is applicable to RTSP streams that use UDP flows.
•
Removing the active Supervisor Engine 2 card on one chassis, then replacing it, can cause the active or standby CSG card to go offline.
•
When using time-based services, issuing the show module csg accounting users all detail command causes the CSG to reload.
Caveats for 3.1(3)C5(3)
This section lists and describes all caveats, both open and closed, that affect CSG Release 3.1(3)C5(3).
For information about open caveats in the Content Services Gateway 3.1(3)C5(3) release, see the Cisco Bug Toolkit at the following URL:
http://www.cisco.com/pcgi-bin/Support/Bugtool/home.pl.
CSG Release 3.1(3)C5(3) - Open Caveats
The following list identifies open caveats in CSG Release 3.1(3)C5(3).
•
When there are two CSGs configured to perform stateful backup in a single chassis, and RPR+ failover occurs, it is possible for both CSGs to become active.
Workaround: set the "failover" time to greater than the length of time it takes RPR+ failover to occur (about 1 minute).
•
CSG is sending unexpected RST packets
Workaround: None.
•
If the service timeout TLV value is zero, and CSG receives a large quadran value, such as 0x7FFFFFFF (2147483647 quadrans), in a Service Authorization Response message, the subscriber balance entry might overrun to a negative value.
Workaround: Limit quota grants in Service Authorization Response messages from the quota server to 0x40000000.
•
New features added in CSG R5 have resulted in a performance drop of approximately 15%, compared to CSG R4.
Workaround: None.
•
During high stress, some sessions might get stuck in an active state, even though the session has closed. If interim records is enabled, CSG periodically sends CDRs for these sessions to the BMA.
Workaround: None.
•
If you session into the primary CSG and upgrade the image, the standby CSG becomes active and both CSGs are active until the upgrade completes.
Workaround: Use the CSG console to perform the upgrade, or, to perform the upgrade on the backup CSG and reset the primary CSG, which makes the primary CSG the backup CSG, then perform the upgrade.
•
Enabling or disabling certain commands on a live system can cause existing User Table entries to become out-of-sync between the active and standby CSGs. The commands that are known to cause problems are replicate under a content and ip csg block.
Workaround: Do not change a fault-tolerant configuration or enter the ip csg block command on a system with existing User Table entries. Reboot the system after making such changes.
CSG Release 3.1(3)C5(3) - Closed Caveats
The following section lists bugs that are closed in CSG Release 3.1(3)C5(3).
•
A host-specific route statement is required when there is a 32-bitmask virtual server to force the CSG to ARP for that IP address.
•
CSG might crash when trying to handle a number of WAP connectionless packets that far exceed its performance specification.
•
CSG crashed while removing the CSG module config via no mod csg 6.
•
The CSG can hang when stressed with heavy FTP traffic.
•
The output of show mod csg n conn may show an incorrect state. This is cosmetic and does not affect the true state of the connection.
•
Under stress, if the active CSG fails, the standby CSG might become active, but then hang.
•
CSG might stop forwarding traffic after messages of the following form appear in show logging output:
%CSM_SLB-3-UNEXPECTED: Module <m> unexpected error:
SLB-REGEX: Assertion failed on line <n> of file...
•
The IP upload/download and packet counts might be off slightly in the TCP record generated for the FTP control connection.
•
A deadlock can occur when multiple show commands are issued simultaneously from multiple consoles.
•
When accessing web pages using browsers that pipeline HTTP requests, the CSG might crash. The crash appears to be very rare and only encountered with some web pages. The crash has not been encountered if the CSG_HTTP_1_0_OPERATION variable is enabled.
•
In module CSG configuration mode, if accounting is unconfigured and then configured, CSG debugs are unconfigured.
•
CSG Release 5.2 enables you to configure a client to send both HTTP and HTTPS traffic over port 80. However, the ability to perform billing differentiation was lost because the CONNECT method is not method map-able.
•
A CSG user's billing plan information might not be replicated to the standby CSG in a fault-tolerant configuration. This problem occurs only for billing plans configured with mode postpaid.
•
CSG produces records for each transaction. Under heavy traffic, this can overwhelm the billing mediation device (BMA). This fix allows aggregation of records at the service level, such that multiple records can be summarized in a single record.
•
A session can get stuck in CSG. Output from the sho mod csg all conn command shows no sessions registered with CSG, but User Table output shows one session. This situation can occur when data and FIN arrives in quick succession from the server.
•
In a stateful backup configuration, the backup can crash if there is a user-group configured on the primary, but not on the backup.
•
Configuring match protocol http url string with a string length more than 128 characters reloads the CSG module.
•
A temporary sticky entry in the CSG User Table, created by unknown traffic for the purpose of CDR transfer, is timed out even when more CDRs are being transmitted.
•
The Quota Return Notification should include a service start timestamp. This timestamp is present in all appropriate messages except the Quota Return Notification. Addition of this timestamp does not impact any quota server that implements the interface per the specification.
•
The "HTTP Intermediate Stats" billing record contains Application RetCode TLV, but it should not.
Caveats for 3.1(3)C5(2)
This section lists and describes all caveats, both open and closed, that affect CSG Release 3.1(3)C5(2).
For information about open caveats in the Content Services Gateway 3.1(3)C5(2) release, see the Cisco Bug Toolkit at the following URL:
http://www.cisco.com/pcgi-bin/Support/Bugtool/home.pl.
CSG Release 3.1(3)C5(2) - Open Caveats
The following list identifies open caveats in CSG Release 3.1(3)C5(2).
•
When there are two CSGs configured to perform stateful backup in a single chassis, and RPR+ failover occurs, it is possible for both CSGs to become active.
Workaround: set the "failover" time to greater than the length of time it takes RPR+ failover to occur (about 1 minute).
•
CSG might crash when trying to handle a number of WAP connectionless packets that far exceed its performance specification.
Workaround: Limit the amount of WAP traffic sent to CSG.
•
New features added in CSG R5 have resulted in a performance drop of approximately 15%, compared to CSG R4.
Workaround: None.
•
During high stress, some sessions might get stuck in an active state, even though the session has closed. If interim records is enabled, CSG periodically sends CDRs for these sessions to the BMA.
Workaround: None.
•
Under stress, if the active CSG fails, the standby CSG might become active, but then hang.
Workaround: None.
•
The IP upload/download and packet counts might be off slightly in the TCP record generated for the FTP control connection.
Workaround: None.
•
A deadlock can occur when multiple show commands are issued simultaneously from multiple consoles.
Workaround: Do not issue multiple CSG commands simultaneously from multiple consoles.
•
When accessing web pages using browsers that pipeline HTTP requests, the CSG might crash. The crash appears to be very rare and only encountered with some web pages. The crash has not been encountered if the CSG_HTTP_1_0_OPERATION variable is enabled.
Workaround: Enable the CSG_HTTP_1_0_OPERATION variable if all browsers in your network support the negotiation to non-pipelined mode.
CSG Release 3.1(3)C5(2) - Closed Caveats
The following section lists bugs that are closed in CSG Release 3.1(3)C5(2).
•
Under heavy load, CSG might hang in FPGA1 or FPGA2. Typically, if this occurs, the TCP microcode statistic "Session Queue Overflow" is high and increasing. Check for this condition by entering either the show tech command or the show mod csg slot-number tech proc 2 command, then search the output for the text "Session Queue Overflow".
This condition is pervasive in CSG release 3.1(3)C5(1) and later, with multiple different external symptoms. The problem is most common in configurations with RADIUS processing or prepaid functionality. In releases of CSG prior to 3.1(3)C5(1), this condition rarely occurs.
•
If Catalyst has CSG and CSM and the command debug ip csg cpu is given, then undebug all, the undebug all is mistakenly sent to CSM causing CSMX: Unknown TLV type 600 error and a Request Process Failure.
•
Upon connection termination, after server sends a FIN packet, the CSG forwards it to client and afterwards also one RST packet for the same connection, with the same sequence number.
Subsequent FIN/ACK packets from client are not forwarded to server or replied, causing the client to retransmit several times, allocating wireless network resources.
•
Add variables to allow additional tuning of CSG behavior:
CSG_FTP_PWD to disable injection of PWD command into FTP control connection.
CSG_PERSISTENT_PARSE to disable parsing for multiple requests in persistent HTTP connections.
•
Right after configuration for a test, an automated script was checking the status of the BMA (show ip csg acc agent). At that time the CSG crashed in TimerWheel.
•
Large HTTP GET requests which span more than one packet may fail over established persistent sessions.
•
In most cases, when you try to change the basis policy, CSG ignores the change and prompts you to set accounting to no inservice before making the change. However, if you are changing the basis policy from volume/fixed to duration basis, or vice versa, you can make the change without setting accounting to no inservice. If this occurs, and a user is currently stored in the User Table, the basis type is not updated, but the balance is depleted according to the new basis policy, and show commands display incorrect user billing information.
•
After CSG issues an HTTP Redirect for a low-quota or zero-quota user, it RSTs subsequent connection attempts by that user until a SvcReAuth timer pops. If the user is downloading a webpage with multiple images (for example, if there are five images to be downloaded, and CSG sends a redirect on the first image), then the browser follows the redirect to the top-up web page. However, the browser continues to request the rest of the images, with the end result that either an error is displayed, or the original index page is displayed with broken links.
•
On loss of a configured Standby BMA, and after recovery, the Standby BMA does not send a SYSLOG message. An event occurs for recovery if the state is active.
•
CSG does not support prepaid services for SMTP connections that match a policy configured for accounting type smtp.
•
When radius server is configured, CSG can support up to 93 clients (IP address, port). If a new client sends a RADIUS message, CSG drops the message, and does not forward it to the RADIUS server.
A new CSG variable, CSG_RADIUS_PROXY_CLIENT_REUSE, is introduced to allow control structures for idle clients to be reused. CSG_RADIUS_PROXY_CLIENT_REUSE specifies the number of seconds the client must be idle before it is reused for a new client.
The default value is 7200 seconds (2 hours).
A value of 0 specifies that control structures should not be reused. This is the current behavior. Therefore, if you do not want to reuse control structures, you must specify CSG_RADIUS_PROXY_CLIENT_REUSE with a value of 0.
•
When the first URL in a sequence does not match a policy, but later URLs do match a policy, packets containing GET request in a persistent HTTP connection are dropped by the CSG module. The affected packets appear in a persistent connection and follow the server response with 302 redirect.
•
CSG is sending the Continuation TLV as 0x00b1. It should be 0x0031 with the high order bit set: 0x8031.
•
If a policy that is configured for accounting type pop3 is matched, and CSG generates multiple POP3 records (due to multiple POP3 RETR or TOP commands) for a single TCP session, a 0-length Report String Attribute TLV might be generated.
•
CSG issues a traceback due to an attempted double-free of an RTSP stream.
•
If the User Table is full, and an element is reused for a new user, and the element contains RADIUS attributes, the storage for the attributes is not freed.
•
If the single segment or leading segment that contains the HTTP request with the URL that is to be rewritten is greater than 1476 bytes in length, CSG URL-rewriting for an HTTP request during content authorization fails.
•
The CSG may leak buffer if a RST is received from the server in response to a SYN initiated for a TCP connection on CSG. The CSG may stop responding to new TCP connections after leaking 20K buffers.
•
When using multiple concurrent downloads for FTP, CSG might hang if the number of FTP downloads, plus the number of RTSP streams, plus the number of configured Content rules, exceeds 127.
•
CSG can reset after running RTSP traffic.
•
If a client sends second SYN for a connection that is already established, CSG responds with an RST.
•
CSG can hang after unexpected error tracebacks.
•
When the client uses the same server and port for both HTTP proxy and SSL proxy (for example, HTTP proxy to port 80 and SSL proxy to port 80, to the same host), L7 billing results in session failure.
This condition occurs because the L7 CSG virtual server that is associated with the L7 content match tries to parse all of the URLs for the session. However, since the HTTPS post-CONNECT traffic is encrypted, the parse fails, and the session fails.
•
A new TLV, Service Start Timestamp, has been added to the following BMA records:
–
–
–
–
Service Start Timestamp is also included in the following quota server messages:
–
–
–
•
The mandatory TLV "URL" is missing from the RTSP Stream CDR. The problem occurs in interleaved or HTTP-tunneled RTSP mode.
•
For RTSP tunneled over HTTP, the RTSP Flow TLV appears before the HTTP headers. Since the space reservation for the RTSP Flow TLV is before the HTTP headers, this condition can lead to data corruption if the RTSP Stream record is split across multiple GTP' packets.
•
RTSP byte counts are off for interleaved TCP mode.
Caveats for 3.1(3)C5(1)
This section lists and describes all caveats, both open and closed, that affect CSG Release 3.1(3)C5(1).
For information about open caveats in the Content Services Gateway 3.1(3)C5(1) release, see the Cisco Bug Toolkit at the following URL:
http://www.cisco.com/pcgi-bin/Support/Bugtool/home.pl.
CSG Release 3.1(3)C5(1) - Open Caveats
The following list identifies open caveats in CSG Release 3.1(3)C5(1).
•
When there are two CSGs configured to perform stateful backup in a single chassis, and RPR+ failover occurs, it is possible for both CSGs to become active.
Workaround: set the "failover" time to greater than the length of time it takes RPR+ failover to occur (about 1 minute).
•
If Catalyst has CSG and CSM and the command debug ip csg cpu is given, then undebug all, the undebug all is mistakenly sent to CSM causing CSMX: Unknown TLV type 600 error and a Request Process Failure.
Workaround: none needed as no failure to csg are csm to process date is noted.
•
Upon connection termination, after server sends a FIN packet, the CSG forwards it to client and afterwards also one RST packet for the same connection, with the same sequence number.
Subsequent FIN/ACK packets from client are not forwarded to server or replied, causing the client to retransmit several times, allocating wireless network resources.
Workaround: None.
•
Add variables to allow additional tuning of CSG behavior:
CSG_FTP_PWD to disable injection of PWD command into FTP control connection.
CSG_PERSISTENT_PARSE to disable parsing for multiple requests in persistent HTTP connections.
•
Right after configuration for a test, an automated script was checking the status of the BMA (show ip csg acc agent). At that time the CSG crashed in TimerWheel.
Workaround: none
•
Large HTTP GET requests which span more than one packet may fail over established persistent sessions.
Workaround: disable persistence using CSG configuration variables as follows:
CSG_HTTP_1_0_OPERATION 1
CSG_HTTP_PERSISTENCE_DISABLE 1
•
The CSG may leak buffer if a RST is received from the server in response to a SYN initiated for a TCP connection on CSG. The CSG may stop responding to new TCP connections after leaking 20K buffers.
Workaround: None.
CSG Release 3.1(3)C5(1) - Closed Caveats
The following section lists bugs that are closed in CSG Release 3.1(3)C5(1).
•
HTTP requests that are pipelined (persistent HTTP1.1 GETs where a GET is sent out before a response is received for the previous GET) do not work with CSG.
Only the first GET request is processed correctly.
The pipelined GET that failed is not processed correctly until a timeout period (about 20 seconds), at which time the CSG sends a RST. At that time the client device retries the GET that was previously pipelined, which completes successfully.
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
•
•
Obtaining Documentation and Submitting a Service Request
For information on obtaining documentation, submitting a service request, and gathering additional information, 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
Subscribe to the What's New in Cisco Product Documentation as a Really Simple Syndication (RSS) feed and set content to be delivered directly to your desktop using a reader application. The RSS feeds are a free service and Cisco currently supports RSS version 2.0.
This document is to be used in conjunction with the documents listed in the "Related Documentation" section.
CCDE, CCENT, Cisco Eos, Cisco HealthPresence, the Cisco logo, Cisco Lumin, Cisco Nexus, Cisco StadiumVision, Cisco TelePresence, Cisco WebEx, 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, 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. (0812R)
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 © 2009 Cisco Systems, Inc. All rights reserved.
Guest
