|
|
Table Of Contents
CSG Features Introduced Prior to CSG R4.1
CSG Features Introduced in CSG R4.1—3.1(3)C4(1)
CSG Feature Introduced in CSG R4.8—3.1(3)C4(8)
CSG Feature Introduced in CSG R4.9—3.1(3)C4(9)
CSG Features Introduced in CSG R5.1—3.1(3)C5(1)
CSG Feature Introduced in CSG R5.2—3.1(3)C5(2)
CSG Feature Introduced in CSG R5.3—3.1(3)C5(3)
CSG Feature Introduced in CSG R5.4—3.1(3)C5(4)
CSG Features Introduced in CSG R5.5—3.1(3)C5(5)
CSG Features Introduced in CSG R6.2—3.1(3)C6(2)
CSG Features Introduced in CSG R6.3—3.1(3)C6(3)
CSG Features Introduced in CSG R6.9—3.1(3)C6(9)
CSG Features Introduced in CSG R7.1—3.1(3)C7(1)
Determining the Software Version
Upgrading to a New CSG Release
Saving and Restoring Configurations
Additional Installation Instructions
CSG Release 3.1(3)C7(7) - Open Caveats
CSG Release 3.1(3)C7(7) - Closed Caveats
CSG Release 3.1(3)C7(6) - Open Caveats
CSG Release 3.1(3)C7(6) - Closed Caveats
CSG Release 3.1(3)C7(5) - Open Caveats
CSG Release 3.1(3)C7(5) - Closed Caveats
CSG Release 3.1(3)C7(4) - Open Caveats
CSG Release 3.1(3)C7(4) - Closed Caveats
CSG Release 3.1(3)C7(3) - Open Caveats
CSG Release 3.1(3)C7(3) - Closed Caveats
CSG Release 3.1(3)C7(2) - Open Caveats
CSG Release 3.1(3)C7(2) - Closed Caveats
CSG Release 3.1(3)C7(1) - Open Caveats
CSG Release 3.1(3)C7(1) - Closed Caveats
Documentation and Technical Assistance
Obtaining Documentation, Obtaining Support, and Security Guidelines
Release Notes for Cisco Content Services Gateway 3.1(3)C7(7) for Cisco IOS Release 12.2(18)SXF or Cisco IOS Release 12.2(18)SRA
Revised: December 28, 2007
Current Release—3.1(3)C7(7)
This publication describes the requirements, dependencies, and caveats for the Cisco Content Services Gateway (CSG) Release 3.1(3)C7(7).
Contents
•
Features
•
•
•
•
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)C7(1).
To see the software part numbers associated with each CSG release; the Supervisor hardware required by each CSG release; the minimum Cisco IOS release required for new features in each CSG release, the minimum CatOS/Hybrid level supported by each CSG release; and the minimum IOS level supported by each CSG release, see the "Software Requirements" section.
•
•
•
•
•
•
•
•
•
•
•
•
•
CSG Features Introduced Prior to CSG R4.1
The following features were introduced Prior to CSG R4.1:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
CSG Features Introduced in CSG R4.1—3.1(3)C4(1)
The following features were introduced in CSG R4.1, and require IOS release 12.2(14)ZA1 or later:
•
•
•
•
The following features were introduced in CSG R4.1, and require IOS release 12.2(14)ZA2 or later:
•
•
•
•
•
•
•
•
Note
CSG Feature Introduced in CSG R4.8—3.1(3)C4(8)
The following feature was introduced in CSG R4.8, and requires IOS release 12.2(14)ZA2 or later:
•
Note
CSG Feature Introduced in CSG R4.9—3.1(3)C4(9)
The following feature was introduced in CSG R4.9, and requires IOS release 12.2(14)ZA2 or later:
•
Note
CSG Features Introduced in CSG R5.1—3.1(3)C5(1)
The following features were introduced in CSG R5.1, and require IOS release 12.2(17d)SXB or later:
•
–
–
Note
•
•
•
•
•
•
•
•
•
•
•
•
•
CSG Feature Introduced in CSG R5.2—3.1(3)C5(2)
The following feature was introduced in CSG R5.2, and requires IOS release 12.2(17d)SXB or later:
•
CSG Feature Introduced in CSG R5.3—3.1(3)C5(3)
The following feature was introduced in CSG R5.3, and requires IOS release 12.2(18)SXD1 or later:
•
CSG Feature Introduced in CSG R5.4—3.1(3)C5(4)
The following feature was introduced in CSG R5.4, and requires IOS release 12.2(18)SXD1 or later:
•
CSG Features Introduced in CSG R5.5—3.1(3)C5(5)
The following features were introduced in CSG R5.5, and require IOS release 12.2(18)SXD1 or later:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
CSG Features Introduced in CSG R6.2—3.1(3)C6(2)
The following features were introduced in CSG R6.2, and require IOS release 12.2(18)SXE or later:
•
•
•
•
•
•
•
•
•
•
•
•
CSG Features Introduced in CSG R6.3—3.1(3)C6(3)
The following feature was introduced in CSG R6.3, and requires IOS release 12.2(18)SXE or later:
•
CSG Features Introduced in CSG R6.9—3.1(3)C6(9)
The following feature was introduced in CSG R6.9, and requires IOS release 12.2(18)SXE or later:
•
CSG Features Introduced in CSG R7.1—3.1(3)C7(1)
The following features were introduced in CSG R7.1, and require Cisco IOS release 12.2(18)SXF1 or later, or Cisco IOS release 12.2(18)SRA 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 supervisor engines, and a module with ports to connect server and client networks:
•
•
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)C7(7)
SC-SVC-CSG-B-7.0
SC-SVC-CSG-P-7.0
SC-SVC-CSG-EP-7.0SUP720-MSFC3-BXL SUP32-MSFC2A and PFC3B
12.2(18)SXF1
or 12.2(18)SRA7.6.1
12.2(18)SXF1
or 12.2(18)SRA3.1(3)C7(6)
SC-SVC-CSG-B-7.0
SC-SVC-CSG-P-7.0
SC-SVC-CSG-EP-7.0SUP720-MSFC3-BXL SUP32-MSFC2A and PFC3B
12.2(18)SXF1
or 12.2(18)SRA7.6.1
12.2(18)SXF1
or 12.2(18)SRA3.1(3)C7(5)
SC-SVC-CSG-B-7.0
SC-SVC-CSG-P-7.0
SC-SVC-CSG-EP-7.0SUP720-MSFC3-BXL SUP32-MSFC2A and PFC3B
12.2(18)SXF1
or 12.2(18)SRA7.6.1
12.2(18)SXF1
or 12.2(18)SRA3.1(3)C7(4)
SC-SVC-CSG-B-7.0
SC-SVC-CSG-P-7.0
SC-SVC-CSG-EP-7.0SUP720-MSFC3-BXL SUP32-MSFC2A and PFC3B
12.2(18)SXF1
or 12.2(18)SRA7.6.1
12.2(18)SXF1
or 12.2(18)SRA3.1(3)C7(3)
SC-SVC-CSG-B-7.0
SC-SVC-CSG-P-7.0
SC-SVC-CSG-EP-7.0SUP720-MSFC3-BXL SUP32-MSFC2A and PFC3B
12.2(18)SXF1
or 12.2(18)SRA7.6.1
12.2(18)SXF1
or 12.2(18)SRA3.1(3)C7(2)
SC-SVC-CSG-B-7.0
SC-SVC-CSG-P-7.0
SC-SVC-CSG-EP-7.0SUP720-MSFC3-BXL SUP32-MSFC2A and PFC3B
12.2(18)SXF1
or 12.2(18)SRA7.6.1
12.2(18)SXF1
or 12.2(18)SRA3.1(3)C7(1)
SC-SVC-CSG-B-7.0
SC-SVC-CSG-P-7.0
SC-SVC-CSG-EP-7.0SUP720-MSFC3-BXL SUP32-MSFC2A and PFC3B
12.2(18)SXF1
or 12.2(18)SRA7.6.1
12.2(18)SXF1
or 12.2(18)SRA
1 Do not use the minimums listed in this table to infer supervisor hardware support. Consult the Cisco IOS Upgrade Planner to determine which IOS releases support the desired supervisor hardware.
2 If running Hybrid, make sure the appropriate IOS Hybrid image is available at this level.
3 The feature set is limited to those features that can be configured at this IOS level.
The following table lists the supported hardware and software for the CSG:
When using the CSG with some IOS images, you might see the following warning message:
%PM_SCP-SP-4-UNK_OPCODE: Received unknown unsolicited message from module n, opcode 0x330
You can ignore this message.
Determining the Software Version
To determine the version of Cisco IOS software that is currently running on your Cisco network device, log in to the device and enter the show version EXEC command.
To show CSG versions, use the show module command in privileged EXEC mode.
To provide meaningful problem determination information, use the show tech-support command in privileged EXEC mode.
Upgrading to a New CSG Release
For the latest upgrade procedures for the CSG, see the "Configuring the Content Services Gateway" chapter of the Cisco Content Services Gateway Installation and Configuration Guide.
Saving and Restoring Configurations
For information about saving and restoring configurations, see the Catalyst 6000 Family IOS Software Configuration Guide or to the Cisco 7600 Series Cisco IOS Software Configuration Guide.
Additional Installation Instructions
For more information about installing the CSG, see the Cisco Content Services Gateway Installation and Configuration Guide.
Prerequisites
For the latest prerequisites for the CSG, see the "Overview" chapter of the Cisco Content Services Gateway Installation and Configuration Guide.
Restrictions
For the latest restrictions for the CSG, see the "Overview" chapter of the Cisco Content Services Gateway Installation and Configuration Guide.
Caveats for 3.1(3)C7(7)
This section lists and describes all caveats, both open and resolved, that affect CSG software release 3.1(3)C7(7).
For information about open or unresolved caveats in the Content Services Gateway 3.1(3)C7(7) release, refer to the Cisco Bug Toolkit at the following URL:
http://www.cisco.com/cgi-bin/Support/Bugtool/home.pl.
CSG Release 3.1(3)C7(7) - Open Caveats
The following list identifies open caveats in CSG Release 3.1(3)C7(7).
•
The CSG does not allow the user to configure a content that includes a policy with accounting type http, and a policy that does not include an accounting statement.
Workaround: None.
•
The CSG closes all open sessions during a Reauthorization Delay (RD) "wait" state (that is, action code = wait in Reauthorization Delay TLV in most recent Service Authorization Response, Service Reauthorization Response, Quota Push Request, Quota Return Accept, or Service Verification Response message) for a service that is configured with basis second service when the quota for that service expires during the wait period.
Workaround: None.
•
A small buffer leak occurs when running SMTP traffic.
Workaround: Change the policy under the SMTP content from accounting type smtp to accounting type other.
•
The show module csg arp command shows some of the ARP entries as LEARNED, DOWN instead of the correct VSERVER, LOCAL. There is no operational impact.
Workaround: None.
•
When the multiprotocol (HTTP, FTP, RTSP, TCP and WAP) traffic load is high, the standby CSG might receive the following message:
Tack! invalid appl ptr 17ad0/203
17ad0/203 src: 40.40.40.2:20 dst: 31.31.11.3:20921 prot: 6
kut index: ip= 31.31.11.3, uid= user22818
flags: NETWORK_INIT POSTPAID TCP_ADJ_NEEDED BACKUP_NEEDED
prepaid: ip bytes up = 0, ip bytes down = 0
tcp bytes up = 0, tcp bytes down = 0
bytes granted = 0, quads consumed = 0
flags = <none>Workaround: None.
•
When the usage for a transaction is greater than 2147483647 quadrans, the CSG might report a negative value for quadrans in the BMA CDR.
Workaround: Clear the affected user.
•
The CSG might report a negative value for Total Usage in a Service Stop.
For this problem to occur, all of the following conditions must be met:
–
–
Workaround: Clear the affected user.
•
MIB entity entPhysicalSoftwareRev does not reflect the current CSG version after a CSG image upgrade.
Workaround: The MIB is updated after the Supervisor Engine reloads.
•
The CSG might seem to resend Quota Service Reauthorization Requests in an endless loop for a specific user and a specific service.
The "Reserved" value seen in show ip csg accounting users is a signed integer. When this value exceeds 2147483647, tis problem can occur.
Workaround: Clear the affected user.
•
The CSG coredumps and resets after a switchover.
For this problem to occur, all of the following conditions must be met:
–
–
–
Workaround: Make sure every user has a unique IP address.
•
The RTSP data traffic does not match the correct policy.
For this problem to occur, all of the following conditions must be met:
–
–
–
–
–
–
Workaround: None.
•
By default, the CSG sends a retry to a CG for an unacknowledged request every 4 seconds. However, in some cases, the retry interval might be less than the configured interval.
Workaround: None.
•
A CSG might reset when running CSG Release 7.6. The following error is observed:
%CSM_SLB-3-UNEXPECTED: Module 4 unexpected error: Traceback - 0x001F93E0 0x001F8EBC 0x001F865C 0x001FA1F8 0x001AD250
%CSM_SLB-3-UNEXPECTED: Module 4 unexpected error: FPGA1 exception encountered.
%CSM_SLB-3-UNEXPECTED: Module 4 unexpected error: Diag - 02000.02000.00001.00001.00001 FPGA5 transmit FIFO full
%CSM_SLB-3-UNEXPECTED: Module 4 unexpected error: Rebooting...Workaround: None.
•
You might see the following traceback on the standby CSG:
0x001EB5E4 0x0025FFF4 0x001EA320 0x001EAEEC 0x001DD37C 0x001EA1 5C 0x001F35E8 0x0020694C 0x0002984C 0x000522B0 0x0004ADD8 0x001AD250
0x001EB5E4 0x0025FFF4 0x001EA320 0x001F35F4 0x0020694C 0x000298 4C 0x000522B0 0x0004ADD8 0x001AD250
Workaround: None.
•
Under heavy load, the CSG might trigger the following false alarm:
Retry Timer is not running for CSG Billing Agent 4.4.4.15:3386 in ACTIVE state
Workaround: Reset the CSG_CHECK_RETRY_TIMER environmental variable to 0 (zero).
CSG Release 3.1(3)C7(7) - Closed Caveats
The following section lists bugs that are closed in CSG Release 3.1(3)C7(7).
•
The CSG crashes and generates a core dump as a result of a timing issue in the IXPs. The core dump indicates that the network processor was waiting for a memory read operation to complete. The health monitor determined that the IXP was no longer communicating with the PPC, and the PPC forced a reset to prevent a card hang condition.
•
When changes are being made to a URL map in a standby CSG, it might become active, leading to an active/active collision.
•
For RTSP, the CSG might report an incorrect TCP volume, far above the reported IP byte volume, in CDR usage corresponding to the TCP session. (The reported IP byte volume is correct.)
•
The configurable CSG_CHECK_RETRY_TIMER environment variable is added to the CSG. This variable enables (1) or disables (0) the retry timer, which the CSG uses to check the status of all of the configured CGs every five minutes. The default setting for this variable is 1 (enabled).
To set this variable, use the variable command in module CSG configuration mode.
•
In a CSG with prepaid users, there are many GTP resends. This occurs more often with tariff switching during peak hours.
For this problem to occur, all of the following conditions must be met:
–
–
–
•
The Queued Count for a BMA or quota server might increase when under heavy load, and might remain at the higher level. If the max records setting is reached, the CSG drops all the new requests to the BMA or quota server.
Caveats for 3.1(3)C7(6)
This section lists and describes all caveats, both open and resolved, that affect CSG software release 3.1(3)C7(6).
For information about open or unresolved caveats in the Content Services Gateway 3.1(3)C7(6) release, refer to the Cisco Bug Toolkit at the following URL:
http://www.cisco.com/cgi-bin/Support/Bugtool/home.pl.
CSG Release 3.1(3)C7(6) - Open Caveats
The following list identifies open caveats in CSG Release 3.1(3)C7(6).
•
The CSG does not allow the user to configure a content that includes a policy with accounting type http, and a policy that does not include an accounting statement.
Workaround: None.
•
The CSG closes all open sessions during a Reauthorization Delay (RD) "wait" state (that is, action code = wait in Reauthorization Delay TLV in most recent Service Authorization Response, Service Reauthorization Response, Quota Push Request, Quota Return Accept, or Service Verification Response message) for a service that is configured with basis second service when the quota for that service expires during the wait period.
Workaround: None.
•
A small buffer leak occurs when running SMTP traffic.
Workaround: Change the policy under the SMTP content from accounting type smtp to accounting type other.
•
The show module csg arp command shows some of the ARP entries as LEARNED, DOWN instead of the correct VSERVER, LOCAL. There is no operational impact.
Workaround: None.
•
The CSG crashes and generates a core dump as a result of a timing issue in the IXPs. The core dump indicates that the network processor was waiting for a memory read operation to complete. The health monitor determined that the IXP was no longer communicating with the PPC, and the PPC forced a reset to prevent a card hang condition.
Workaround: None.
•
When the multiprotocol (HTTP, FTP, RTSP, TCP and WAP) traffic load is high, the standby CSG might receive the following message:
Tack! invalid appl ptr 17ad0/203
17ad0/203 src: 40.40.40.2:20 dst: 31.31.11.3:20921 prot: 6
kut index: ip= 31.31.11.3, uid= user22818
flags: NETWORK_INIT POSTPAID TCP_ADJ_NEEDED BACKUP_NEEDED
prepaid: ip bytes up = 0, ip bytes down = 0
tcp bytes up = 0, tcp bytes down = 0
bytes granted = 0, quads consumed = 0
flags = <none>Workaround: None.
CSG Release 3.1(3)C7(6) - Closed Caveats
The following section lists bugs that are closed in CSG Release 3.1(3)C7(6).
•
CSG-related traps are not being sent to the NMS agent. These are the traps related to changes in states for the BMAs, quota servers, and user database, as well as traps that are generated when records to the BMAs or quota servers are lost.
The CSG cannot generate V1 traps.
•
Under certain conditions, the CSG might reset both the client and the server.
For this problem to occur, the following conditions must all be met:
–
–
–
•
When the FTP traffic load is high, the standby CSG might receive the following message:
Tack! invalid appl ptr 1fbb12/21e
1fbb12/21e src: 34.0.3.143:28458 dst: 40.40.40.2:21 prot: 6
kut index: <none>
flags: BACKUP_PEND
prepaid: ip bytes up = 0, ip bytes down = 0
tcp bytes up = 0, tcp bytes down = 0
bytes granted = 0, quads consumed = 0
flags = <none>•
Under heavy load running RTSP traffic, some tracebacks can be seen on the CSG console.
•
The persistence flag should be set in the ipv4flow (IPv4 L4 Flow TLV in the CDR) for e-mail protocols for all transactions that end but do not terminate the TCP session. The NOT CLOSED flag should also be set in this same condition, as it is for HTTP.
•
The CSG resets continuously with "error in installing ruleset." This condition can occur if there are VLAN configurations under contents, but the actual VLANs do not exist.
•
When running automated FTP tests, 5 to 10% of all tested FTP sessions are prematurely disconnected by the CSG.
•
In IPS3.0, when a user has an unknown billing plan due to loss of communication with the CSG, the HTTP statistics CDR might be generated with 0 bytes counted.
•
The CSG console requires a packet log utility. This utility enables the CSG to log WAP, RTSP, and RADIUS packets (normal and errors).
The packet log utility can log up to 4096 packets and consumes 6756 KB of memory (allocated as a block, not incrementally).
To select the packets to be logged, use the pktlog set console command, with the following options:
–
–
–
–
–
–
To stop logging selected packets, use the pktlog clear console command, with the following options:
–
–
–
–
–
–
–
To display the packet logs, use the pktlog show console command, with the following options:
–
–
–
–
–
–
–
–
By default, the packet log utility is disabled. To enable the packet log utility, the configurable PKTLOG_ENABLE environment variable is added to the CSG. This variable enables (1) or disables (0) the packet log utility. The default setting is 0 (disabled).
The configurable PKTLOG_OVERWRITE environment variable is also added to the CSG. This variable enables the CSG to overwrite packet logs when the buffer is full. To enable the CSG to overwrite packet logs, specify 1 (the default setting). To prevent the CSG from overwriting packet logs, specify 0.
To set these variables, use the variable command in module CSG configuration mode.
•
The CSG might report a small IP download bytes undercharge for a transaction with accounting type http.
For this problem to occur, the following conditions must all be met:
–
–
•
Under heavy load conditions, while trying to TFTP the CSG software, an Active/Active collision condition might occur. Traffic is disrupted until the duplicate IP address conflict is resolved.
•
If debug ip csg cpu has been enabled, entering the show cpu command on the CSG console or the show module csg tech-support utilization command on the Supervisor displays CPU utilization information even after all debugs have been turned off using the undebug all command.
•
The CSG might drop RADIUS messages after configuring or unconfiguring accounting.
•
The following CSG traceback error might occur on an active CSG:
%CSM_SLB-3-UNEXPECTED: Module 5 unexpected error: Traceback - 0x0025CB8C 0x002029E0 0x00241BE8 0x0020013C 0x00200B0C 0x0004A038 0x001AAE6C
•
The standby CSG slowly leaks memory, leading to an eventual crash.
•
The following traceback appears in the logs:
%CSM_SLB-3-UNEXPECTED: Module 4 unexpected error:
Traceback - 0x0025CB8C 0x001F6518 0x0025E48C 0x0025E794 0x0025E838 0x001AAE6C•
The CSG crashes when running under maximum CPU and maximum memory conditions for a period of 2 to 48 hours.
•
A user might end up with a large positive quadrans balance when the quota server sends a Service Authorization Response with negative quadrans (-1) for a CSG service.
•
The CSG does not forward HTTP POSTs that span multiple packets completely.
For this problem to occur, the following conditions must all be met:
–
–
–
•
The show tech and show mod csg tech-support commands might display Resource Utilization twice.
•
The CSG might drop GET requests under certain timing conditions.
For this problem to occur, the following conditions must all be met:
–
–
•
The CSG is allowing WAP 1.x traffic to pass through even if the quota server is denying the service (Quota = 0 quadrans, Cause = 3, Service Denied).
For this problem to occur, the following conditions must all be met:
–
–
–
•
The active CSG might not fail over to the standby CSG when buffer pools are corrupted with the default value of CSG_MEM_ERR_THRESHOLD.
•
The CSG might report an overcharge in the CDR TLV "Service TCP Usage Cumulative Bytes Down". The overcharge can be up to 20 more then the actual TCP/IP data transferred for a service transaction.
For this problem to occur, the following conditions must all be met:
–
–
–
•
The queued count of a quota server might increase if the CSG stops retransmitting unacknowledged data requests. This might result in dropped new requests if the queued count reaches the configured maximum records limit.
For this problem to occur, the following conditions must all be met:
–
–
•
The CSG might overcharge download bytes for the first transaction with pipelined GETs after an abnormal termination.
For this problem to occur, the following conditions must all be met:
–
–
–
–
•
WAP 1.0 redirect does not work if the server sends an ACK before sending a REPLY.
For this problem to occur, the following conditions must all be met:
–
–
–
•
The CSG might resend Quota Service Reauthorization Requests in an endless loop for a specific user and a specific service.
•
The CSG might crash with the following crash signature:
!!!CORE DUMP Tue Aug 28 11:31:37 2007
!!!Version: 3.1(3)C7(5)
FPGA1 exception 999 IXIC_ICPAS - iPacket passthrough. ecmd wants to sync.Caveats for 3.1(3)C7(5)
This section lists and describes all caveats, both open and resolved, that affect CSG software release 3.1(3)C7(5).
For information about open or unresolved caveats in the Content Services Gateway 3.1(3)C7(5) release, refer to the Cisco Bug Toolkit at the following URL:
http://www.cisco.com/cgi-bin/Support/Bugtool/home.pl.
CSG Release 3.1(3)C7(5) - Open Caveats
The following list identifies open caveats in CSG Release 3.1(3)C7(5).
•
The CSG closes all open sessions during a Reauthorization Delay (RD) "wait" state (that is, action code = wait in Reauthorization Delay TLV in most recent Service Authorization Response, Service Reauthorization Response, Quota Push Request, Quota Return Accept, or Service Verification Response message) for a service that is configured with basis second service when the quota for that service expires during the wait period.
Workaround: None.
•
CSG-related traps are not being sent to the NMS agent. These are the traps related to changes in states for the BMAs, quota servers, and user database, as well as traps that are generated when records to the BMAs or quota servers are lost.
Workaround: None.
•
The CSG might reset both the client and the server. The problem seems to be related to the timing of the second auth_content_resp from the quota server.
Workaround: None.
•
Under heavy load running RTSP traffic, some tracebacks can be seen on the CSG console.
Workaround: None.
•
The CSG resets continuously with "error in installing ruleset." This condition can occur if there are VLAN configurations under contents, but the actual VLANs do not exist.
Workaround: Either create the VLANs included under the content, or remove the contents with faulty configurations from the ruleset.
•
When running automated FTP tests, 5 to 10% of all tested FTP sessions are prematurely disconnected by the CSG.
Workaround: None.
•
In IPS3.0, when a user has an unknown billing plan due to loss of communication with the CSG, the HTTP statistics CDR might be generated with 0 bytes counted.
Workaround: Configure the BMA to drop the HTTP statistics CDR if this occurs.
•
The CSG might report a small IP download bytes undercharge for a transaction with accounting type http.
For this problem to occur, the following conditions must all be met:
–
–
Workaround: None.
•
Under heavy load conditions, while trying to TFTP the CSG software, an Active/Active collision condition might occur. Traffic is disrupted until the duplicate IP address conflict is resolved.
Workaround: Perform CSG software upgrades during off-peak hours.
•
If debug ip csg cpu has been enabled, entering the show cpu command on the CSG console or the show module csg tech-support utilization command on the Supervisor displays CPU utilization information even after all debugs have been turned off using the undebug all command.
Workaround: Explicitly turn off the debugs using the no debug ip csg cpu command.
•
The CSG might drop RADIUS messages after configuring or unconfiguring accounting.
Workaround: Reload the CSG.
•
The following CSG traceback error might occur on an active CSG:
%CSM_SLB-3-UNEXPECTED: Module 5 unexpected error: Traceback - 0x0025CB8C 0x002029E0 0x00241BE8 0x0020013C 0x00200B0C 0x0004A038 0x001AAE6C
Workaround: None.
•
A small buffer leak occurs when running SMTP traffic.
Workaround: Change the policy under the SMTP content from accounting type smtp to accounting type other.
•
The show module csg arp command shows some of the ARP entries as LEARNED, DOWN instead of the correct VSERVER, LOCAL. There is no operational impact.
Workaround: None.
•
The standby CSG slowly leaks memory, leading to an eventual crash.
Workaround: None.
•
The following traceback appears in the logs:
%CSM_SLB-3-UNEXPECTED: Module 4 unexpected error:
Traceback - 0x0025CB8C 0x001F6518 0x0025E48C 0x0025E794 0x0025E838 0x001AAE6CWorkaround: None.
CSG Release 3.1(3)C7(5) - Closed Caveats
The following section lists bugs that are closed in CSG Release 3.1(3)C7(5).
•
When the CSG has exceeded its CPU capacity, it might drop GTP' ACKs and lose communication with the BMA or the PSD.
As part of the CSG's health monitoring process, the CSG monitors itself for low CPU conditions.
–
%CSM_SLB-3-ERROR: Module 3 error: WARN - CSG cpu exceeded 90.0%(91.1%)
By default, the CSG issues this warning message when CPU usage exceeds 90%. (The second number is the current CSG CPU one-minute average usage.) To change that threshold, change the setting of the CSG_CPU_WARN_THRESHOLD variable. The range for this variable is 1 to 95; the default setting is 90.
By default, the CSG issues this warning message once a minute after the threshold has been exceeded. To change the time between warning messages, change the setting of the CSG_CPU_WARN_FREQUENCY variable. The range for the variable is 1 to 95; the default setting is 5.
–
%CSM_SLB-3-ERROR: Module 3 error: CRITICAL - CSG max cpu reached 95.0%(96.1%)
By default, the CSG issues this depletion message when CPU usage exceeds 95%. (The second number is the current CSG CPU one-minute average usage.) To change that threshold, change the setting of the CSG_CPU_MAX_THRESHOLD variable. The range for this variable is 1 to 95; the default setting is 95.
By default, the CSG issues this depletion message once a minute after the threshold has been exceeded. To change the time between depletion messages, change the setting of the CSG_CPU_MAX_FREQUENCY variable. The range for the variable is 1 to 95; the default setting is 1.
To set these variables, use the variable command in module CSG configuration mode.
•
The RADIUS monitor error counters unable to send to client and unable to send to server might be incremented even when there is no SEND failure.
•
To enable the CSG to display all messages to the CSG console in the current session, use the capture command on the CSG console.
–
–
•
A malformed RADIUS message might cause the CSG to crash.
•
The CSG might be unable to parse a RADIUS VSA if the format does not follow RFC 2865. This might result in a user not being added to the User Table.
•
As part of the BMA recovery process, the CSG drains CDRs from the PSD and forwards them to the BMA. In a high-traffic environment, this drainage might degrade the throughput of incoming traffic, and could even bring down the CSG.
To help avoid this problem, the configurable CSG_GTP_DRAIN_DELAY environment variable is added to the CSG. This variable enables the user to adjust the GTP PSD drain delay. The range is 0 seconds to 3 seconds. The default setting is 1 second.
The configurable CSG_GTP_DRAIN_PKT environment variable is also added to the CSG. This variable enables the user to specify how many packets the CSG is to drain for each delay. The range is 1 packet to 100 packets. The default setting is 2 packets.
To set these variables, use the variable command in module CSG configuration mode.
•
RADIUS monitor support is enhanced to allow a ping request to be forwarded to the configured server (if there is a configured content to match the flow).
•
The CSG might receive a partial coredump when detecting an internal error.
•
Changes to the CSG CPU normalization factor trigger the reporting of higher than expected CPU utilization values.
•
Under heavy traffic and heavy user activation and deactivation, the CSG generates trace messages and billing queue overflow messages.
•
The CSG resets while adding or modifying policies in a live network.
For this problem to occur, the following conditions must all be met:
–
–
•
The CSG does not process requests from the quota server if the source port in the request packet is not the quota server port configured in the CSG.
•
For WAP 1.x traffic that matches a CSG content-policy pair that is configured for accounting type wap, the CSG might report a large value, or an incorrect value, for "Interval Usage Seconds" in the Service Stop message.
–
–
Caveats for 3.1(3)C7(4)
This section lists and describes all caveats, both open and resolved, that affect CSG software release 3.1(3)C7(4).
For information about open or unresolved caveats in the Content Services Gateway 3.1(3)C7(4) release, refer to the Cisco Bug Toolkit at the following URL:
http://www.cisco.com/cgi-bin/Support/Bugtool/home.pl.
CSG Release 3.1(3)C7(4) - Open Caveats
The following list identifies open caveats in CSG Release 3.1(3)C7(4).
•
The CSG closes all open sessions during a Reauthorization Delay (RD) "wait" state (that is, action code = wait in Reauthorization Delay TLV in most recent Service Authorization Response, Service Reauthorization Response, Quota Push Request, Quota Return Accept, or Service Verification Response message) for a service that is configured with basis second service when the quota for that service expires during the wait period.
Workaround: None.
•
CSG-related traps are not being sent to the NMS agent. These are the traps related to changes in states for the BMAs, quota servers, and user database, as well as traps that are generated when records to the BMAs or quota servers are lost.
Workaround: None.
•
The CSG might reset both the client and the server. The problem seems to be related to the timing of the second auth_content_resp from the quota server.
Workaround: None.
•
Under heavy traffic and heavy user activation and deactivation, the CSG generates trace messages and billing queue overflow messages.
Workaround: None.
•
Under heavy load running RTSP traffic, some tracebacks can be seen on the CSG console.
Workaround: None.
•
The CSG resets while adding or modifying policies in a live network.
For this problem to occur, the following conditions must all be met:
–
–
Workaround: Add or modify policies during off-peak hours.
•
The CSG resets continuously with "error in installing ruleset." This condition can occur if there are VLAN configurations under contents, but the actual VLANs do not exist.
Workaround: Either create the VLANs included under the content, or remove the contents with faulty configurations from the ruleset.
•
When running automated FTP tests, 5 to 10% of all tested FTP sessions are prematurely disconnected by the CSG.
Workaround: None.
•
The CSG does not process requests from the quota server if the source port in the request packet is not the quota server port configured in the CSG.
Workaround: Ensure that the quota server uses the configured port as the source port when sending requests to the CSG.
•
In IPS3.0, when a user has an unknown billing plan due to loss of communication with the CSG, the HTTP statistics CDR might be generated with 0 bytes counted.
Workaround: Configure the BMA to drop the HTTP statistics CDR if this occurs.
•
The CSG might report a small IP download bytes undercharge for a transaction with accounting type http.
For this problem to occur, the following conditions must all be met:
–
–
Workaround: None.
•
Under heavy load conditions, while trying to TFTP the CSG software, an Active/Active collision condition might occur. Traffic is disrupted until the duplicate IP address conflict is resolved.
Workaround: Perform CSG software upgrades during off-peak hours.
•
For WAP 1.x traffic that matches a CSG content-policy pair that is configured for accounting type wap, the CSG might report a large value, or an incorrect value, for "Interval Usage Seconds" in the Service Stop message.
–
–
Workaround: Configure accounting type other for the WAP policy.
CSG Release 3.1(3)C7(4) - Closed Caveats
The following section lists bugs that are closed in CSG Release 3.1(3)C7(4).
•
When the CSG is operating in half-proxy mode (accounting type http), it is necessary to advertise a Maximum Segment Size (MSS) value when establishing a TCP connection with the client. Once the first HTTP transaction is received, the CSG then establishes a TCP connection with the server. If the server returns an MSS value less than initially advertised by the CSG to the client, datagrams with a size in excess of what the server can handle might be sent by the client. These datagrams are then dropped by the server.
To help avoid this problem, the configurable CSG_SET_MSS environment variable is added to the CSG. This variable enables the user to set the MSS, in bytes. The range is 1 byte to 1432 bytes. The default setting is 1432 bytes.
To set this variable, use the variable command in module CSG configuration mode.
•
A server- initiated data connection for FTP (active FTP) and RTP stream (RTP sessions initiated from the server) might not work when an FTP or RTSP policy is configured for next hop.
For this problem to occur, the following conditions must all be met:
–
–
–
–
•
The CSG sends Service Reauthorization Request messages too frequently for a prepaid subscriber, even when there is unused quota. Such behavior can overwhelm the quota server and interrupt service. The problem occurs when HTTP 1.1 pipelined traffic with the wrong Content-length is transferred over the user session.
•
When you remove the gateway command from the CSG's client VLAN, the next hop specified in the command is also removed from the ARP table. Normal traffic does not restore the ARP entry.
This problem could not be reproduced.
•
When an HTTP stream containing a mix of fragmented and non-fragmented IP packets matches a content and policy with accounting type http, the CSG might experience a buffer leak and drop all traffic.
For this problem to occur, the following conditions must all be met:
–
–
–
•
If variable CSG_FTP_PWD = 1 is configured, the CSG resets the FTP data connection after a failover.
•
If there is a large amount of backpressure from the Cisco Catalyst 6500 series switch backplane, resulting in "TX Window full" and "TX FIFO full" statistics incrementing on the show mod csm tech proc command, the NAT processor might stop handling traffic, causing an eventual core dump.
•
The CSG can behave unpredictably when certain types of TCP packets are received.
TCP packets with the following TCP flags can cause problems:
–
–
–
–
Also, packets in which the IP packet length is less than sum of the IP header length and the TCP header length can cause problems.
•
If variable CSG_FTP_PWD is set to its default value (0), the CSG does not process buffered packets during PWD command transaction. If the buffered command is PORT from the client, then one of the following conditions might occur:
–
–
For this problem to occur, the following conditions must all be met:
–
–
–
•
The CSG might send a TCP reset for an HTTP request that spans more than one packet.
For this problem to occur, the following conditions must all be met:
–
–
–
•
When WAP 1.x/WSP traffic matches a content and policy with accounting type wap, the CSG might crash, with the system logs showing "PPC exception".
For this problem to occur, one of the following sets of conditions must be met:
Condition 1:
–
–
–
–
Condition 2.
–
–
–
–
To help avoid this problem, the configurable CSG_MEM_ERR_THRESHOLD environment variable is added to the CSG. This variable enables the user to set the number of memory errors to allow before failing over to the backup CSG. When the threshold is reached, the CSG dumps the memory that is in error to the logs and dumps the buffer pools to the CSG console. The range is 0 errors to 10000 errors. The default setting is 5 errors.
The configurable DUMP_BAD_WAP_PACKET environment variable is also added to the CSG. This variable enables the CSG to dump WAP packets that cannot be parsed to the system logs, if debugging is enabled from the VENUS# console. We recommend that you configure this variable only when directed to do so by Cisco Technical Assistance Center (TAC) engineers. The range is 0 (do not dump any WAP packets to the system logs) to 100 (dump the first 100 WAP packets that cannot be parsed). The default setting is 5 (dump the first 5 WAP packets that cannot be parsed).
To set these variables, use the variable command in module CSG configuration mode.
•
In some situations, the CSG is overcharging for WAP2/HTTP traffic.
•
When WAP 1.x/WSP traffic matches a content and policy with accounting type wap, the CSG might lose memory gradually.
For this problem to occur, the following conditions must all be met:
–
–
–
–
•
The user cannot send large HTTP POSTs (larger than 1000 KB).
For this problem to occur, the following conditions must all be met:
–
–
–
To help avoid this problem, the configurable CSG_MAX_POST_LENGTH environment variable is added to the CSG. This variable enables the user to set the maximum HTTP POST size, in bytes, to be buffered by the CSG. The range is 0 byte to 10485760 bytes. The default setting is 65536 bytes.
To set this variable, use the variable command in module CSG configuration mode.
•
The CSG cannot forward some traffic or session/connection failures, especially for HTTP and WAP 2.0.
•
The CSG does not always send an ACK to a client with windows-size set to 8192.
For this problem to occur, the following conditions must all be met:
–
–
•
The CSG overcharges slightly for a transaction in IP download bytes reported with accounting type http. The overcharge is for the IP downlink bytes; the TCP downlink bytes are charged correctly.
For this problem to occur, the following conditions must all be met:
–
–
•
An HTTP server stream with fragmented IP packets might be downgraded to Layer 4 accounting.
For this problem to occur, the following conditions must all be met:
–
–
–
–
•
In normal operation, the CSG does not print a warning message when it drops packets that cannot be forwarded as a result of parsing errors.
To enable the CSG to print warning messages, the configurable CSG_WARN_PKTDROP_ERR environment variable is added to the CSG. If the CSG_WARN_PKTDROP_ERR variable is enabled (set to 1), the CSG prints a warning message when it drops packets that cannot be parsed. Otherwise (set to 0, the default setting), the CSG does not print a warning messages.
The configurable CSG_PKTDROP_WARN_FREQUENCY environment variable is also added to the CSG. If the CSG_WARN_PKTDROP_ERR variable is enabled (set to 1), this variable enables the user to set the frequency of packet drop warning messages, in seconds. The range is 60 seconds (log one message every minute) to 86400 seconds (log one message every 24 hours). The default setting is 300 seconds (log one message every five minutes).
To set these variables, use the variable command in module CSG configuration mode.
Caveats for 3.1(3)C7(3)
This section lists and describes all caveats, both open and resolved, that affect CSG software release 3.1(3)C7(3).
For information about open or unresolved caveats in the Content Services Gateway 3.1(3)C7(3) release, refer to the Cisco Bug Toolkit at the following URL:
http://www.cisco.com/cgi-bin/Support/Bugtool/home.pl.
CSG Release 3.1(3)C7(3) - Open Caveats
The following list identifies open caveats in CSG Release 3.1(3)C7(3).
•
The CSG closes all open sessions during a Reauthorization Delay (RD) "wait" state (that is, action code = wait in Reauthorization Delay TLV in most recent Service Authorization Response, Service Reauthorization Response, Quota Push Request, Quota Return Accept, or Service Verification Response message) for a service that is configured with basis second service when the quota for that service expires during the wait period.
Workaround: None.
•
A server- initiated data connection for FTP (active FTP) and RTP stream (RTP sessions initiated from the server) might not work when an FTP or RTSP policy is configured for next hop.
For this problem to occur, the following conditions must all be met:
–
–
–
–
Workaround: To avoid this problem, take the following steps:
a.
b.
ip csg policy PFTPaccounting type ftp customer-string ftp-stringclient-group CInext-hop 150.76.50.110!ip csg policy PFTP_SIaccounting type ftp customer-string ftp-stringip access-list standard CIpermit 50.76.50.0 0.0.0.255With this configuration, the control session (initiated from the client) matches PFTP, the policy that is configured with next hop, and the data session (initiated from the server) matches PFTP_SI, the policy that is configured without next hop.
•
The CSG might reset both the client and the server. The problem seems to be related to the timing of the second auth_content_resp from the quota server.
Workaround: None.
•
The CSG sends Service Reauthorization Request messages too frequently for a prepaid subscriber, even when there is unused quota. Such behavior can overwhelm the quota server and interrupt service. The problem occurs when HTTP 1.1 pipelined traffic with the wrong Content-length is transferred over the user session.
Workaround: None.
•
When you remove the gateway command from the CSG's client VLAN, the next hop specified in the command is also removed from the ARP table. Normal traffic does not restore the ARP entry.
Workaround: Ping the attached device from the CSG to populate the ARP table with the ARP entry.
•
Under heavy traffic and heavy user activation and deactivation, the CSG generates trace messages and billing queue overflow messages.
Workaround: None.
•
If variable CSG_FTP_PWD = 1 is configured, the CSG resets the FTP data connection after a failover.
Workaround: Remove variable CSG_FTP_PWD = 1 from the configuration.
•
The CSG can behave unpredictably when certain types of TCP packets are received.
TCP packets with the following TCP flags can cause problems:
–
–
–
–
Also, packets in which the IP packet length is less than sum of the IP header length and the TCP header length can cause problems.
Workaround: To avoid the TCP flag problem, install a firewall in front of the CSG to drop malformed packets. There is no workaround for the packet length problem.
•
Under heavy load running RTSP traffic, some tracebacks can be seen on the CSG console.
Workaround: None.
•
If variable CSG_FTP_PWD is set to its default value (0), the CSG does not process buffered packets during PWD command transaction. If the buffered command is PORT from the client, then one of the following conditions might occur:
–
–
For this problem to occur, the following conditions must all be met:
–
–
–
Workaround: Configure variable CSG_FTP_PWD = 1.
CSG Release 3.1(3)C7(3) - Closed Caveats
The following section lists bugs that are closed in CSG Release 3.1(3)C7(3).
•
If you are running RTSP traffic (RTP UDP) through the CSG with RTSP filtering configured, and you take accounting out-of-service while there are active RTSP session, the CSG can crash.
•
Out-of-order HTTP packets from the server might result in an overcharge.
For this problem to occur, all of the following conditions must be met:
–
–
–
–
•
When the CSG receives RTSP packets that do not end with Ctrl-F Ctrl-F, the CSG might crash while cleaning up these improper RTSP flow connections. This can also occur when all of the RTSP flows use the same session ID.
If this occurs, the log shows the following messages:
%CSM_SLB-3-UNEXPECTED: Module 4 unexpected error: PPC exception encountered.
%CSM_SLB-3-UNEXPECTED: Module 4 unexpected error:
Rebooting....
•
Redirect might fail with WAP 1.x connection-oriented sessions when a user is out of balance.
For this problem to occur, the following conditions must all be met:
–
–
–
•
When handling RADIUS, WAP, and HTTP traffic with IP fragmentation, the CSG might stop forwarding traffic when it runs out of buffers.
•
If the FTP data connection is running in passive mode, the CSG might drop FTP data packets when the FTP server retransmits the PASV response during the data connection handshake.
•
A CSG running Release 3.1(3)C7(2) and SUP720 Release 12.2(18)SXF6 used in Layer 7 Traffic Authorization mode can crash with the next crash error:
!!!CORE DUMP WED OCT 25 05:23:27 2006
!!!Version: 3.1(3)C7(2)
FPGA1 exception 999 IXIC_ICPAS - iPacket passthrough. ecmd wants to sync.
Even when running in fault-tolerant mode, both CSGs can crash immediately.
•
The CSG does not forward some HTTP requests.
For this problem to occur, the following conditions must all be met:
–
–
–
To help avoid this problem, the configurable CSG_MULTIPART_DISABLE environment variable is added to the CSG. In normal operation, the CSG analyzes and buffers a multipart POST completely before forwarding it to the server. When the CSG_MULTIPART_DISABLE variable is enabled (set to 1), the CSG downgrades HTTP multipart sessions to Layer 4 accounting, and the CSG stops analyzing the POST when it identifies the the "Content-Type: multipart" header.
The configurable CSG_CHUNKED_DISABLE environment variable is also added to the CSG. In normal operation, the CSG analyzes and buffers a chunked transfer encoding POST completely before forwarding it to the server. When the CSG_CHUNKED_DISABLE variable is enabled (set to 1), the CSG downgrades HTTP chunked transfer encoding sessions to Layer 4 accounting, and the CSG stops analyzing the POST when it identifies the "Transfer-Encoding:chunked" header.
The CSG_MULTIPART_DISABLE and CSG_CHUNKED_DISABLE variables are useful when clients and servers do not conform to the RFC, or when servers are not able to keep up with the complete POST that the CSG sends. We recommend that you keep these variables disabled (set to 0, the default setting) unless multipart or chunked transfer encoding POSTs are not going through.
To set these variables, use the variable command in module CSG configuration mode.
•
With accounting-type HTTP configured for the relevant content, the CSG sends an ACK to the client with zero window size.
•
When processing HTTP 1.1 pipelining traffic, the CSG can undercharge both upload and download IP byte counts. The CSG might not be able to analyze the server responses to pipelined requests when it encounters the following types of packets:
–
–
–
•
The CSG might send a Service Reauthorization even if there is sufficient quota available. This can occur when a quota server sends a Reauthorization Delay along with non-zero granted quadrans in one of the following messages:
–
–
–
In this situation, the CSG cannot handle the delay properly.
•
The CSG might charge IP bytes to a previous policy for HTTP "Transfer-Encoding:chunked" packets. This can occur when the CSG receives HTTP Transfer-Encoding:chunked" packets DATA0, DATA1, DATA2, DATA3 in sequence from the server. DATA0 contains the HTTP header and the chunk length for a chunk of data that spans DATA1, DATA2 and part of DATA3. In this situation, the CSG charges the IP header of DATA0 and DATA3 to the current policy, and charges DATA1 and DATA2 to the previous policy.
•
The CSG CPU load is extremely high (85%) with a low number of subscribers and low traffic.
•
The CSG crashes with WAP/UDP traffic with IP fragmentation. This crash can occur in either of the following scenarios:
–
–
•
When the CSG handles pipelined HTTP GET requests with more than 16 GET's, and a retransmitted packet arrives that precedes the last 16 GET's, the CSG goes into a loop, stops forwarding traffic, crashes, and resets.
•
The CSG can crash when it encounters spurious memory accesses. The CSG does not crash when it encounters a NULL pointer access, so when the code does not check the NULL pointer, the CSG can encounter a random memory corruption and crash.
•
The CSG can crash when it encounters WAP/UDP traffic with IP fragmentation. The crash can occur when the header fragment and the trailer fragment arrive at the CSG almost simultaneously.
Caveats for 3.1(3)C7(2)
This section lists and describes all caveats, both open and resolved, that affect CSG software release 3.1(3)C7(2).
For information about open or unresolved caveats in the Content Services Gateway 3.1(3)C7(2) release, refer to the Cisco Bug Toolkit at the following URL:
http://www.cisco.com/cgi-bin/Support/Bugtool/home.pl.
CSG Release 3.1(3)C7(2) - Open Caveats
The following list identifies open caveats in CSG Release 3.1(3)C7(2).
•
If you are running RTSP traffic (RTP UDP) through the CSG with RTSP filtering configured, and you take accounting out-of-service while there are active RTSP session, the CSG can crash.
Workaround: Do not take accounting out-of-service while there are active RTSP sessions.
•
A server- initiated data connection for FTP (active FTP) and RTP stream (RTP sessions initiated from the server) might not work when an FTP or RTSP policy is configured for next hop.
For this problem to occur, the following conditions must all be met:
–
–
–
–
Workaround: To avoid this problem, take the following steps:
a.
b.
ip csg policy PFTPaccounting type ftp customer-string ftp-stringclient-group CInext-hop 150.76.50.110!ip csg policy PFTP_SIaccounting type ftp customer-string ftp-stringip access-list standard CIpermit 50.76.50.0 0.0.0.255With this configuration, the control session (initiated from the client) matches PFTP, the policy that is configured with next hop, and the data session (initiated from the server) matches PFTP_SI, the policy that is configured without next hop.
•
Out-of-order HTTP packets from the server might result in an overcharge.
For this problem to occur, all of the following conditions must be met:
–
–
–
–
Workaround: None.
•
When you remove the gateway command from the CSG's client VLAN, the next hop specified in the command is also removed from the ARP table. Normal traffic does not restore the ARP entry.
Workaround: Ping the attached device from the CSG to populate the ARP table with the ARP entry.
CSG Release 3.1(3)C7(2) - Closed Caveats
The following section lists bugs that are closed in CSG Release 3.1(3)C7(2).
•
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.
•
A retransmitted RADIUS Stop might cause the CSG to remove a user entry from the User Table when the entry should not be removed.
To avoid this problem, the CSG must be able to associate a session correlator from the RADIUS Start message with a user entry in the User Table, and compare that correlator with the correlator in the RADIUS Stop message. If the correlators match, the CSG deletes the user entry; otherwise, the CSG retains the entry in the User Table.
The CSG can use the Acct-Session-Id (attribute 44) as the correlator, or it can use the following new vendor-specific attribute (VSA) subattribute (attribute 26, Vendor-Id 9, subattribute 1):
csg:user_session_correlator=<string>
If both attributes are included in the RADIUS Start or RADIUS Stop message, the CSG uses the VSA subattribute.
To enable this capability, the configurable CSG_RADIUS_CORRELATOR environment variable is added to the CSG:
–
–
If there is no correlator saved in the User Table entry, the CSG deletes the entry.
If there is a correlator saved in the User Table entry, the CSG compares it to the correlator in the RADIUS Stop. If the correlators match, the CSG deletes the entry; if they do not match, or if there is no correlator in the RADIUS Stop, the CSG retains the entry in the User Table.
To set this variable, use the variable command in module CSG configuration mode.
•
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.
For this problem to occur, all of the following conditions must be met:
–
–
–
•
Intermediate billing records are generated with larger byte counts than configured.
•
The CSG must support the plus sign (+) in match patterns for CSG billing maps, enabling matches to one or more occurrences of the preceding character. For example, the CSG must allow a match pattern such as:
/music(/+)sheet.html
which matches the following character strings:
/music/sheet.hml
/music//sheet.html
/music///////sheet.htmlTo enable this support, the configurable CSG_REGEX_PLUS environment variable is added to the CSG:
–
–
Note
To set this variable for a content, take the content out of service, use the variable command in module CSG configuration mode, then return the content to service. You can reset the CSG after setting this variable.
Note
The setting of the CSG_REGEX_PLUS variable affects the following CSG commands:
–
–
•
Core dumps created by a release prior to CSG 3.1(3)C7(2) are not readable by CSG 3.1(3)C7(2) or later releases, and core dumps created by CSG 3.1(3)C7(2) or later releases are not readable by releases prior to CSG 3.1(3)C7(2). If you need to read a core dump, reload the image that generated the core dump.
•
The CSG might go offline during Supervisor 32 switchover in stateful switchover (SSO) mode and stop passing traffic.
For this problem to occur, all of the following conditions must be met:
–
–
•
The CSG generates the following incorrect warning message if a user attempts to configure an HTTP content on an basis byte ip service.
% Warning, HTTP traffic is metered "basis byte tcp" for policy PHTTP in service SERVICE2.
For this problem to occur, all of the following conditions must be met:
–
–
•
The following syslog messages contain the deprecated, hidden command show ip slb memory
%CSM_SLB-3-UNEXPECTED: Module # unexpected error:
SLB-LCSC: There was an error downloading the configuration to hardware
SLB-LCSC: due to insufficient memory. Use the `show ip slb memory'
SLB-LCSC: command to gather information about memory usage.•
In a Cisco Mobile Exchange (CMX) configuration in which the GGSN acts as a quota server for a postpaid user and the CSG provides content billing (the CSG treats the user as prepaid), the CSG might not send a Quota Return in response to a Quota Return Request.
For this problem to occur, all of the following conditions must be met:
–
–
–
•
A WAP 1.x DISCONNECT transaction is not charged via prepaid. If a WAP DISCONNECT packet is the first packet received for a WAP transaction, the CSG forwards the packet without charge. This is most likely to occur if the client is idle longer than the content idle time configured on the WAP content definition. Thus, the content idle timer expires and the WAP session state information is cleaned up on the CSG. When the user exits the browser, a DISCONNECT flows to the server. The CSG processes and forwards the DISCONNECT but does not charge the user.
•
If an active FTP is used between an FTP client and an FTP server, and the CSG classifies the FTP control and data TCP connections as FTP connections (via accounting type ftp), and if data traffic is flowing over the FTP data connection when a CSG failover occurs, the newly active CSG sends a TCP RST to the FTP client, resulting in the TCP connection for FTP data being closed.
•
If the passthrough command is configured on at least one service, and the CSG receives a RADIUS Start for a prepaid user while the quota server is down, when the quota server recovers, the CSG charges the first session for that user after the quota server recovers as postpaid. Subsequent sessions for that user are charged correctly.
•
If an IMAP fetch is in progress between an IMAP client and an IMAP server when a CSG failover occurs, and the CSG classifies the IMAP TCP connection as IMAP (via accounting type imap), the newly active CSG does not forward the frames associated with the IMAP fetch.
•
The CSG might go offline during Supervisor switchover in stateful switchover (SSO) mode and stop passing traffic.
For this problem to occur, all of the following conditions must be met:
–
–
•
A session with session_id 0 occurs and the following messages are received:
pkt_drv_bill_send_check: invalid session Id (0)
pkt_drv_bill_send_check: invalid session Id (0)
pkt_drv_bill_send_check: invalid session Id (0)
pkt_drv_bill_send_check: invalid session Id (0)
pkt_drv_bill_send_check: invalid session Id (0)•
If passthrough mode and the no quota server reassign command are configured for two or more quota servers, and one of the quota servers fails, passthrough might also fail.
•
If no quota server reassign is configured, and a quota server has failed, but the CSG has not yet marked the quota server as FAILED, the CSG might send GTP transfer requests to an incorrect ACTIVE quota server.
•
The CSG might not include the Extended UserIndex TLV in the HTTP header and statistics BMA records. This problem can occur in a Cisco Mobile Exchange (CMX) service-aware configuration when an HTTP transaction is performed for a GPRS user.
•
The CSG might reload when handling high RTSP traffic load.
•
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 CSG is sending report string attribute values other than 0x00, 0x01 and 0x02 in RTSP CDRs. The reported attribute values are reserved by Cisco for future use.
•
The CSG supports the following Quota Reauthorization TLV additions:
–
–
•
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 CSG might not parse multiple RADIUS subattributes encoded in a single VSA in a RADIUS Access-Accept message.
•
If the CSG loses communication with all BMAs, it might not retrieve records from the PSD when one or more BMAs recover.
When communication with the BMAs is lost, the CSG sends records to the PSD. When communication with one or more BMAs is recovered, the CSG fails to retrieve records from the PSD and forward them to the BMA, even though the CSG maintains the PSD in an active state. Echo requests and write requests continue to be processed correctly, and the CSG shows no pending read requests in its record storage statistics.
•
Quota refund for FTP timeout is not working.
•
When memory usage is greater than 98%, the CSG memory pools might continue to grow, leaving the CSG at less than 2 percent memory.
•
When a high rate of traffic flows through the CSG, the PPC might incorrectly mark the FPGA as hung, and the CSG might crash and reload.
•
When using a CSG policy with accounting type http, the CSG might not forward the first HTTP request for a session, and the HTTP transaction might not complete.
For this problem to occur, all of the following conditions must be met:
–
–
–
•
The CSG might fail to resend HTTP packets from the client after the CSG receives the FIN from the client.
For this problem to occur, all of the following conditions must be met:
–
–
–
–
–
•
The CSG might send a gratuitous ARP request (that is, an ARP request in which the CSG advertises the IP address as its own IP address) for an IP address defined as a match criteria in a CSG content. The CSG sends the gratuitous ARP on exactly one VLAN. The VLAN depends on the configuration.
For this problem to occur, all of the following conditions must be met:
–
–
•
The CSG might not forward header or out-of-order trailer IP fragments for a UDP packet.
•
If the quota server does not respond to a User Authorization Request, the CSG might forward traffic, even if no passthrough is configured on the CSG.
•
Under heavy traffic conditions and stress levels of user activation and deactivation, the CSG might crash, generate a core dump, and fail over to the standby CSG.
•
When the show module csg tech-support command is entered, the CSG might report an incorrect value for the in-use buffer with NoKUT. The reported value might register 4294967295 continually.
•
The CSG might failover to the standby CSG when a new HTTP request or response is out of order and has the SYN bit set.
For this problem to occur, all of the following conditions must be met:
–
–
Caveats for 3.1(3)C7(1)
This section lists and describes all caveats, both open and resolved, that affect CSG software release 3.1(3)C7(1).
For information about open or unresolved caveats in the Content Services Gateway 3.1(3)C7(1) release, refer to the Cisco Bug Toolkit at the following URL:
http://www.cisco.com/cgi-bin/Support/Bugtool/home.pl.
CSG Release 3.1(3)C7(1) - Open Caveats
The following list identifies open caveats in CSG Release 3.1(3)C7(1).
•
Intermediate billing records are generated with larger byte counts than configured.
Workaround: None.
•
If you are running RTSP traffic (RTP UDP) through the CSG with RTSP filtering configured, and you take accounting out-of-service while there are active RTSP session, the CSG can crash.
Workaround: Do not take accounting out-of-service while there are active RTSP sessions.
CSG Release 3.1(3)C7(1) - Closed Caveats
The following section lists bugs that are closed in CSG Release 3.1(3)C7(1).
•
If the first character of a configured HTTP header name is lowercase, the CSG does not match the header fields in the header map.
•
If the CSG is configured for prepaid, and there are ore than 20,000 users in the User Table, and traffic is running, removing the user group configuration from an accounting group might cause the CSG to reload.
This problem could not be reproduced.
•
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:
–
–
•
When the user tries to delete a ruleset which has been applied to modules, the ruleset is deleted but the ruleset name is still visible under module CSG.
For this problem to occur, all of the following conditions must be met:
–
–
•
If SETUP or SETUP REPLY command methods on the RTSP control channel span more than 2 TCP packets, then RTSP data stream traffic does not map to the RTSP content definition. Instead, it maps to a catchall content definition, if one is configured.
•
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.
Documentation and Technical Assistance
This section contains the following information:
•
Related Documentation
For more detailed installation and configuration information, see the following publications:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml
•
•
Cisco IOS Documentation Set
Cisco IOS Configuration Guides and Command References, Release 12.1(12c)E4—Use these publications to help you configure the Cisco IOS software that runs on the MSFC and on the MSM and ATM modules.
Obtaining Documentation, Obtaining Support, and Security Guidelines
For information on obtaining documentation, obtaining support, providing documentation feedback, security guidelines, and also recommended aliases and general Cisco documents, see the monthly What's New in Cisco Product Documentation, which also lists all new and revised Cisco technical documentation, at:
http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html
This document is to be used in conjunction with the documents listed in the "Related Documentation" section.
CCVP, the Cisco logo, and Welcome to the Human Network are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn is a service mark of Cisco Systems, Inc.; and Access Registrar, Aironet, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, LightStream, Linksys, MeetingPlace, MGX, Networkers, Networking Academy, Network Registrar, PIX, ProConnect, ScriptShare, SMARTnet, StackWise, The Fastest Way to Increase Your Internet Quotient, and TransPath 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. (0711R)
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 © 2007, Cisco Systems, Inc. All rights reserved.
Posted: Fri Dec 28 08:55:54 PST 2007
All contents are Copyright © 1992--2007 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.
