Release Notes for Cisco LTE PDN Gateway Release 1.3.7e on the Cisco SAMI, Cisco IOS Release 12.4(24)T35f
Available Languages
Table Of Contents
Hardware and Software Requirements
Determining the Software Version
Upgrading to a New Software Release
Limitations, Restrictions, and Important Notes
New Implementations and Behavior Changes in Cisco IOS Release 12.4(24)T32f
New Implementations and Behavior Changes in Cisco IOS Release 12.4(24)T3f
Lookup Thread Health Monitoring
Write Memory Command Disabled on the TCOPs
New Implementations and Behavior Changes in Cisco IOS Release 12.4(24)T3e
Restart Counter Change Syslog Message
Displaying Enhanced Service Control Message Statistics
Throttling GTP Request Reenqueues
Clearing Bearer/PDP Sessions on a TCOP
New Implementations and Behavior Changes in Cisco IOS Release 12.4(24)T3c
New Implementations and Behavior Changes in Cisco IOS Release 12.4(24)T3b
New Implementations and Behavior Changes in Cisco IOS Release 12.4(24)T3a1
Configuring Local Service Record Information Generation
Configuring Specification Compliance
Caveats - Cisco LTE PGW Release 1.3.7e, Cisco IOS Release 12.4(24)T35f
Caveats - Cisco LTE PGW Release 1.3.7d, Cisco IOS Release 12.4(24)T34f
Caveats - Cisco LTE PGW Release 1.3.7c, Cisco IOS Release 12.4(24)T33f
Caveats - Cisco LTE PGW Release 1.3.7b, Cisco IOS Release 12.4(24)T32f
Caveats - Cisco LTE PGW Release 1.3.7a, Cisco IOS Release 12.4(24)T31f
Caveats - Cisco LTE PGW Release 1.3.7, Cisco IOS Release 12.4(24)T3f
Caveats - Cisco LTE PGW Release 1.3.6, Cisco IOS Release 12.4(24)T3e
Caveats - Cisco LTE PGW Release 1.3.5, Cisco IOS Release 12.4(24)T35c
Caveats - Cisco LTE PGW Release 1.3.4, Cisco IOS Release 12.4(24)T34d
Caveats - Cisco LTE PGW Release 1.3, Cisco IOS Release 12.4(24)T3c
Caveats - Cisco LTE PGW Release 1.2, Cisco IOS Release 12.4(24)T3b
Caveats - Cisco LTE PGW Release 1.1, Cisco IOS Release 12.4(24)T3a1
Caveats - Cisco LTE PGW Release 1.0, Cisco IOS Release 12.4(24)T3a
Obtaining Documentation and Submitting a Service Request
Release Notes for Cisco LTE PDN Gateway Release 1.3.7e on the Cisco SAMI,
Cisco IOS Software Release 12.4 (24)T35f
Latest Publication Date: July 30, 2012, Cisco IOS Release 12.4(24)T35f
Last Publication Date: July 6, 2012, Cisco IOS Release 12.4(24)T34f
This release note describes the requirements, dependencies, and caveats for the Cisco Long Term Evolution (LTE) Packet Data Network (PDN) Gateway (PGW) Release 1.x on the Cisco Service and Application Module for IP (SAMI). These release notes are updated as needed.
For a list of the software caveats that also apply to Cisco LTE PGW, see the "Caveats" section and Caveats for Cisco IOS Release 12.4 T. The caveats document is updated for every maintenance release and is located on Cisco.com and the Documentation CD-ROM.
Use these release notes with Cross-Platform Release Notes for Cisco IOS Release 12.4 located on Cisco.com.
Contents
This release note includes the following information:
•
MIBs
•
•
Cisco LTE PGW Overview
The following sections provide a brief overview of the Cisco LTE PGW:
LTE Evolved Packet Core
The Cisco LTE PGW is a service designed for LTE Evolved Packet Core (EPC). The EPC is the main component of the System Architecture Evolution (SAE). 3GPP designed SAE as a migration path for 3GPP systems. The SAE is the core network architecture of LTE communication and is the evolution of the General Packet Radio Service (GPRS) and Universal Mobile Telecommunication System (UMTS) that provides a migration path for 3GPP systems with the following differences:
•
•
•
•
The LTE EPC is made up of the following primary elements:
•
•
•
Figure 1 shows the interworking (and interfaces) of the LTE EPC with different radio access technologies.
Note
Figure 1 LTE Network Components with SGWs and PGWs Implemented on the Cisco Service and Application Module for IP in the Cisco 7600 Series Router
The following is a list of acronyms used in Figure 1.
•
•
•
•
•
•
•
•
•
•
•
•
•
Cisco LTE PGW Description
For each UE associated with the EPC, there is at least one PGW providing access to the requested PDN. If a UE is accessing multiple PDNs, there could be more than one PGW for that UE.
The Cisco LTE PGW Release 1.0 and later provides the following support:
•
–
–
•
–
–
–
–
–
•
–
–
–
–
•
–
–
–
–
–
–
–
•
–
–
–
–
–
•
–
–
–
–
–
–
–
•
–
–
–
–
–
–
•
–
–
–
•
–
–
•
–
–
–
•
–
–
–
–
–
–
The Cisco LTE PGW runs on the Cisco Service and Application Module for IP (SAMI). The Cisco SAMI is a new-generation high performance service module for the Cisco 7600 Series Router platform.
For more information about the Cisco SAMI, see the Cisco Service and Application Module for IP User Guide.
System Requirements
This section describes the system requirements for Cisco LTE PGW Release 1.x and includes the following sections:
•
•
•
For hardware requirements, such as power supply and environmental requirements and hardware installation instructions, see the Cisco Service and Application Module for IP User Guide.
Memory Recommendations
Hardware and Software Requirements
Implementing a Cisco LTE PGW Release 1.x and later on the Cisco 7600 series internet router platform requires the following hardware and software.
•
•
–
–
–
–
–
Or one of the following Cisco 7600 series Route Switch Processors running Cisco IOS Release 15.0(1)S or later:
–
–
–
For details on upgrading the Cisco IOS release running on the supervisor engine, refer to the "Upgrading to a New Software Release" section in the Release Notes for Cisco IOS Release 15.0S. For information about verifying and upgrading the LCP ROMMON image on the Cisco SAMI, refer to the Cisco Service and Application Module for IP User Guide.
Note
•
Note
•
•
–
–
Determining the Software Version
To determine the version of Cisco IOS Software running on your Cisco SAMI, log in to PPC3 and enter the show version EXEC command:
PGW# show versionCisco IOS Software, SAMI Software (SAMI-L3IK9S-M), Version 12.4(20110919:095523)Copyright (c) 1986-2011 by Cisco Systems, Inc.Compiled Thu 22-Sep-11 17:06 byROM: System Bootstrap, Version 12.4(24r)MDB, RELEASE SOFTWARE (fc1)PGW uptime is 6 hours, 49 minutesSystem returned to ROM by address error at PC 0x977A0A4, address 0x977A0A4 at 11:24:24 UTC Thu Sep 22 2011System restarted at 17:13:18 IST Thu Sep 22 2011...PGW#Upgrading to a New Software Release
For information on upgrading to a new software release, see the product bulletin Cisco IOS Software Upgrade Ordering Instructions at:
http://www.cisco.com/warp/public/cc/pd/iosw/prodlit/957_pp.htm
Upgrading the Cisco SAMI Software
For information on upgrading the Cisco SAMI software, see the Cisco Service and Application Module for IP User Guide:
Note
MIBs
To view a list of MIBs supported by Cisco IOS Release 12.4(24)T33f, see the Cisco LTE PDN Gateway Configuration Guide.
Limitations, Restrictions, and Important Notes
When configuring the Cisco LTE PGW, note the following:
•
•
Table 2 lists the maximum number the Cisco SAMI with the 2-GB memory option can support:
Table 2 Number of Bearers/PDPs Supported in 2-GB SAMI
GTPv2 bearer (IPv4 and IPv6)
380,000
GTPv1 PDP (IPv4 and IPv6)
800,000
When the maximum allowable number of bearers/PDP contexts is reached, the PGW refuses new mobile sessions until sessions are available.
•
–
–
–
!interface Virtual-Template1description GGSN-VTip unnumbered Loopback0encapsulation gtpno logging event link-statusgprs access-point-list gprsendFor Mobile Express Forwarding (MEF) support, configure the redirect all command under the APN.
•
New and Changed Information
The following sections document new features and behavior changes introduced in Cisco IOS Releases 12.4(24)T3 releases.
•
•
•
•
•
•
New Implementations and Behavior Changes in Cisco IOS Release 12.4(24)T32f
With Cisco IOS Release 12.4(24)T32f, the show gprs gtp status command displays the "Total initiated GTPv2 bearers" field, as seen in bold text in the following sample output:
PGW#sh gprs gtp statusGTP status:Total activated GTPv0 PDPs 0Total activated GTPv1 PDPs 0Total activated GTPv2 EPS bearers 0Total initiated GTPv2 bearers 0Total activated sessions 0Total activated GTPv0 v6 PDPs 0Total activated GTPv1 v6 PDPs 0Total activated GTPv2 v6 EPS bearers 0Total activated IPv6 sessions 0Total activated GTPv1 v4v6 PDPs 0Total activated GTPv2 v4v6 EPS bearers 0Total activated IPv4v6 sessions 0Total activated PPP regen PDPs 0Total activated PPP PDPs 0Total GTP direct tunnel PDPs 0Service-aware Status:Prepaid PDPs 0Postpaid PDPs 0PGW#The "Total initiated GTPv2 bearers" field displays the sum of active GTPv2 bearers and the new GTPv2 session requests that are processing.
Note
New Implementations and Behavior Changes in Cisco IOS Release 12.4(24)T3f
Cisco LTE PGW Release 1.3.7, Cisco IOS Release 12.4(24)T3f introduces the following enhancements, new implementations, and behavior changes:
•
•
Enhanced show Command Output
The following show commands have been enhanced in Cisco IOS Release 12.4(24)T3f:
show gprs charging statistics
The gprs charging statistics command output has been enhanced to include the following charging counters:
Total Number of Containers sent in CDR output msgs 0Total Number of Services sent in CDR output msgs 0* CDR Closed with causeNormal Release: 0 Abnormal Release: 0Volume Limit: 0Time Limit: 0SGSN Change: 0Management Intervention: 0 Management Intervention Partial: 0RAT Change: 0QOS Change: 0ULI Change: 0DT Change: 0Tariff Time Change: 0MS TimeZone Change: 0Container Count: 0Service Record Limit: 0Collection Timeout 0SGSN PLMN-ID Change: 0SGSN and PLMN-ID Change: 0
Note
show tech
The show tech command has been enhanced to include output for the show ip traffic command and the show sctp statistics command. Additionally, "dma controller statistics" are collected as part of the show platform command and displayed in the enhanced show tech command output.
Note
show gprs gtp statistics
The show gprs gtp statistics command output has been enhanced to include the following QoS counters (in bold) in the Debug info section:
Debug info:Path fail local del PDP 1208633616 Ver upgrade local del 0No SGSN/SGW local del PDP 0 Ver fallback local del 0No wait SGSN/SGW local del PDP 0 No req SGSN/SGW local del PDP 0Create collide with delete 0 Version changes 0Rcvd retransmit create req 0 Create as update 2Del recd for del session 0 Incorrect Ref Count State 0Total v2 restart txn tmr expiry 19v2 restart txn exp with no PDP 0v2 restart txn exp with not v2 PDP 0Restart txn cancelled for other proc 0CoA delayed for retry 19Max backoff retries failed 1Create session req reassign 0Table 3 describes the new fields.
Note
Lookup Thread Health Monitoring
The Cisco SAMI IXP has more than 50 lookup threads. In prior releases, if a few threads failed, the system did not report the failure right away, but continued to operate in a degraded mode.
Cisco IOS Release 12.4(24)T3f introduces a new mechanism that monitors the health of the lookup threads every second to ensure that the threads are functioning properly. If eight threads report a failure, the mechanism resets the system.
The following syslog message is printed to the PPC if the monitor mechanism detects a stuck thread:
SAMI 3/3: Oct 28 07:22:57.771: %PLATFORM-3-DP_IXP_THR_WARN: IXP:0 thread blocked. me:10 thr:7 num_consecutive_fail:3Once eight threads become stuck, the monitor mechanism prints the following syslog message and reloads the card:
SAMI 3/3: Oct 28 07:22:57.771: %PLATFORM-0-DP_IXP_MULT_THR_FAIL: IXP:0 multiple:8 threads hungBy default, the lookup thread monitor mechanism is enabled for both Cisco SAMI IXPs. To disable the monitor mechanism, use the no sami ixp monitor enable command. To reenable the monitor mechanism, use the sami ixp monitor enable command.
Note
Write Memory Command Disabled on the TCOPs
With Cisco IOS Release 12.4(24)T3f, the write memory command is disabled on the Cisco SAMI Traffic and Control Plane processors (TCOPs). Disabling the write memory command on the TCOPs prevents unnecessary and redundant writes to NVRAM that previously occurred when using schedule jobs (cron table jobs) that executed the write memory command.
Note
SNMP Changes
In the CISCO-GGSN-EXT-MIB, the SNMP GetNext (snmpgetnext, snmpwalk) and the SNMP GetBulk (snmpbulkget) requests are disabled for the GGSN Subscriber table (cGgsnExtSubscriberTable). The entries of the GGSN Subscriber table are now available only through an SNMP GetOne request (snmpget).
Note
New Implementations and Behavior Changes in Cisco IOS Release 12.4(24)T3e
Cisco LTE PGW Release 1.3.6 introduces support for the following:
•
•
•
Restart Counter Change Syslog Message
Cisco LTE PGW Release 1.3.6 introduces the following syslog messages, which indicate that a restart counter change has occurred that caused an SGSN/SGW to reload and deleted all of the contexts linked to that SGSN/SGW.
SAMI 4/5: 000686: Nov 14 00:36:47: %GTP-4-RESTART_COUNTER_CHANGED: GSN: 198.228.216.76, Sig src addr: 135.211.6.144, TID: 1340019236686654, SGSN 135.211.6.144 Restart counter changed from 74 to 75, -Traceback= 0x44307C18z 0x442FCAA0z 0x442FD85Cz 0x45990878z 0x45993F7CzSAMI 3/4: %LTE_GTPV2-4-LTE_RESTART_COUNTER_CHANGED: GSN: 6.6.6.1, Sig src addr: 12.12.12.36, TID: 1111051000000021, SGW: 12.12.12.36 Restart counter changed from 10 to 2, -Traceback= 0x9DC6904z 0x9E65E24z 0x9E948F4z 0x9E91804z 0x9E1CB2Cz 0xA279560z 0xA2795D0z 0x9E16654z 0x9E91584z 0x9E808A4z 0x9E88EECz 0x9E93F3Cz 0x830D7C0z 0x99C1DB8z 0x99C54BCzWhere,
•
•
•
•
•
•
The traceback is harmless and associated with the syslog message.
Displaying Enhanced Service Control Message Statistics
With Cisco LTE PGW Release 1.3.6, the show ggsn csg statistics command supports a detailed keyword option that enables operators to display detailed service usage message processing on the quota server interface.
To display additional information about the service control requests (SCRs) and service control usage (SCU) messages that the PGW exchanges with the Cisco CSG2 on the quota server interface, use the following command while in privileged EXEC mode and specify the detailed keyword option:
Router# show ggsn csg statistics [detailed]
Displays detailed information about the service control messages exchanged on the quota server interface.
Example 1
The following is the output for the show ggsn csg statistics command with the detailed keyword option specified. The additional fields that display when you specify the detailed keyword option are in bold text.
PGW# show ggsn csg statistics detailedGGSN CSG path statistics:CSG Group Name: csg2CSG Path statistics:Outbound msg count: 967Outbound byte count: 6760Inbound msg count: 966Inbound byte count: 6770CSG Path msg statistics:Service Auth Req: 0Service Auth Resp: 0Service Reauth Req: 0Quota Return: 0Quota Return Req: 0Quota Return Accept: 0Service Stop: 0Service Stop Req: 0Quota Push: 0Quota Push resp: 0GTP' Acks: 0Service Control Message Statistics:Service Control Req: 0Total sent: 0 Retransmits: 0Enhanced Radius Interim msg: 0Enhanced Radius Stop msg: 0Service Control Req Ack: 0Immediate: 0 Delayed: 0Service Control Req Nack: 0Immediate: 0 Delayed: 0Service Control Usage: 0Parse errors: 0 Invalid user: 0No user: 0 Internal fail: 0Usage outside upper seq win: 0Usage outside lower seq win: 0Sync Service Control Usage: 0No matching req: 0 Processing error: 0Async Service Control Usage: 0No service info: 0 Processing error: 0Service Control Usage Ack: 0Service Control Usage Nack: 0Expected sequence SCU msgs: 0Async msgs: 0Svc Records added: 0 Failed: 0Sync msgs for SCR: 0Svc Records added: 0 Failed: 0Sync msgs for radius interim: 0Svc Records added: 0 Failed: 0Sync msgs for radius stop: 0Svc Records added: 0 Failed: 0Out of order sequence msgs: 0Async msgs: 0Sync msgs for SCR: 0Sync msgs for radius interim: 0Sync msgs for radius stop: 0Out of order msgs processed: 0Async msgs: 0Svc Records added: 0 Failed: 0Sync msgs for SCR: 0Svc Records added: 0 Failed: 0Sync msgs for radius interim: 0Svc Records added: 0 Failed: 0Sync msgs for radius stop: 0Svc Records added: 0 Failed: 0On process all: 0 On usage: 0User Sequence skips: 0User sequence window slides: 0Attempts: 0 User Seq skips: 0User sequence window wraps: 0No SCU recd: 0For service control req: 0For enhanced radius interim: 0For enhanced radius stop: 0SCR fail to send: 0No Ack for SCR: 0Enhanced Radius Interim msg fail to send: 0Enhanced Radius Stop msg fail to send: 0SCR correlation skips on peer: 0PGW#
Note
Throttling GTP Request Reenqueues
If there is a GTP request that the PGW must service for an existing bearer/PDP, and a pending request for that bearer/PDP exists, the PGW cannot immediately service the new request.
In some cases the GTP request is reenqueued in the GTP queue until the bearer/PDP is ready to be updated/created. The PGW should service all such GTP requests within a few reenqueues. If for some reason it cannot, and a request is continuously reenqueued, the PGW attempts to process the same request again and again, which causes a high CPU.
With Cisco LTE PGW Release 1.3.6, you can throttle the number of times a GTP request can be reenqueued.
To configure the number of times a GTP request can be reenqueued in the GTP queue, use the following command while in global configuration mode:
Using the no form of this command resets the value to the default (10).
Note
To display reenqueue statistics, use the following command while in privileged EXEC mode:
For example, issuing the show gprs gtp request re-enqueue statistics command displays the following:
PGW# show gprs gtp request re-enqueue statisticsGTP Req re-enqueue first_time 1 GTP Req re-enqueue total 1GTP Req re-enqueue dropped 1PGW#To clear the re-enqueue statistics counters, use the following command while in privileged EXEC mode:
Router# clear gprs gtp request re-enqueue statistics
Clears the counters for the reenqueue statistics.
When configuring the GTP request reenqueue throttle, note the following:
•
SAMI 1/4: Jul 5 22:06:21.079: GPRS:1231230000000010:A GTP Req Packet has reached limit 0 for re-enqueue. Queue GTP msg, Re-enqueue reason:Delete Before RecreateSAMI 1/4: Jul 5 22:06:21.079: GPRS:1231230000000010:TID: 1231230000000010, PDP Internal Flags:40440001, PDP Update Flags:00000000, PDP Delete Flags:00000000, MCB Flags:00020008, APN: mani.com, Packet App flags 00000000, PDP:0x425B767C, MCB 0x4A423534•
Note
Clearing Bearer/PDP Sessions on a TCOP
From the Cisco SAMI Remote Console and Logging (RCAL) interface, use the execute-on command while in privileged EXEC mode from the PCOP to collect and display show and debug command output from the TCOPs. Additionally, use the execute-on command to propagate most clear commands to the TCOPs.
With Cisco PGW Release 1.3.6, the clear gprs gtp pdp-context command supports clearing a specific number of sessions on a TCOP. This enhancement enables operators to implement controlled bearer/PDP flushes.
To clear a specific number of bearer/PDP sessions on a TCOP, use the following command while in privileged EXEC mode:
Note
New Implementations and Behavior Changes in Cisco IOS Release 12.4(24)T3c
Cisco LTE PGW Release 1.3 introduces support for the following PCO options:
•
•
•
•
•
Note
New Implementations and Behavior Changes in Cisco IOS Release 12.4(24)T3b
Per CR 225, with Cisco LTE PGW Release 1.2, the Tracking Area Identity (TAI) and User Location Information (ECGI) are included in the change report action information element (IE), according to the received event trigger, in the following messages:
•
•
•
•
•
Note
New Implementations and Behavior Changes in Cisco IOS Release 12.4(24)T3a1
The following new feature and compliance change have been introduced in Cisco LTE PGW Release 1.1, Cisco IOS Release 12.4(24)T3a1:
•
•
Configuring Local Service Record Information Generation
By default, the Cisco LTE PGW obtains service record information from the Cisco CSG2. With Cisco LTE PGW Release 1.1, Cisco IOS Release 12.4(24)T3a1, service record information can be generated locally, without the Cisco CSG2.
Service Record Generation with a Cisco CSG2
When generating service record information with a Cisco CSG2, the following configuration must exist:
•
•
•
With the service record generation with a Cisco CSG2 implementation, the Cisco CSG2 sends the service record information to the Cisco LTE PGW, which then adds it to the CDR.
Service Record Generation without a Cisco CSG2
When generating service record information without a Cisco CSG2, the following configuration must exist:
•
•
•
With the service record without a Cisco CSG2 implementation, the PGW generates the service information and adds it to the CDR.
Note
To enable the PGW to generate service record information locally, complete the following tasks while in charging profile configuration mode.
Note
Configuring Specification Compliance
Support for the following 3GPP specification change requests (CRs) records for 29.274 has been introduced in Cisco LTE PGW Release 1.1, Cisco IOS Release 12.4(24)T3a1:
•
•
•
•
•
•
Additionally, commands to configure backward compliance have been added for the following 29.274 CRs:
•
•
•
To configure compliance for the above CR, complete the following tasks:
•
Creating a Compliance Profile
Operators can create a compliance profile in which they configure CR compliance. Once a compliance profile has been created, it can be applied to a path group to a remote node. For information on creating a path group to a remote node, see"Creating a Remote Path Group" section.
To create a compliance profile and its CR configuration, complete the following tasks, beginning in global configuration mode:
Creating a Remote Path Group
Once a compliance profile has been configured, operators can create a path group. In the path group, the address of the remote node is configured and as well as the compliance profile to use.
To create a path group, complete the following tasks, beginning in global configuration mode:
Caveats
This section contains the caveats for the following releases:
•
•
•
•
•
•
•
•
•
•
•
•
•
Caveats describe unexpected behavior in Cisco IOS Software releases. Severity 1 caveats are the most serious caveats; severity 2 caveats are less serious. Severity 3 caveats are moderate caveats, and only select severity 3 caveats are included in the caveats document.
All caveats in Cisco IOS Release 12.4 and Cisco IOS Release 12.4 T are also in Cisco IOS Release 12.4(24)T33f.
For information on caveats in Cisco IOS Release 12.4, see Caveats for Cisco IOS Release 12.4.
For information on caveats in Cisco IOS Release 12.4 T, see Caveats for Cisco IOS Release 12.4T, which lists severity 1 and 2 caveats and select severity 3 caveats and is located on Cisco.com and the Documentation CD-ROM.
Using the Bug Navigator II
If you have an account with Cisco.com, you can use Bug Navigator II to find caveats the most current list of caveats of any severity for any software release. To reach Bug Navigator II, log in to Cisco.com and click Software Center: Cisco IOS Software: Cisco Bugtool Navigator II. Another option is to go directly to http://www.cisco.com/support/bugtools.
Note
Caveats - Cisco LTE PGW Release 1.3.7e, Cisco IOS Release 12.4(24)T35f
This section lists the open, resolved and unreproducible caveats that pertain to Cisco LTE PGW Release 1.3.7e, Cisco IOS Release 12.4(24)T35f.
Open Caveats
Note
The following sections document possible unexpected behavior and describe only severity 1 and 2 caveats and select severity 3 caveats.
Cisco LTE PGW Caveats
The following Cisco LTE PGW caveats are open in Cisco IOS Release 12.4(24)T35f.
•
During the creation of a session, if a failure response from the IXP occurs while the session is being deleted under a specific timing window (for example, the IXP might already have an entry), the PGW might reload.
This is a timing condition between the completion of accounting start and the deletion of a session under a specific timing window.
Workaround: There is currently no known workaround.
•
The Cisco LTE PGW/SGW might drop an update PDP context requests because of an International Mobile Subscriber Identity (IMSI) mandatory information element (IE) missing error. This condition occurs during a GTPv0-to-GTPv1 handoff or during a GTPv2-to-GTPv1 handoff if the IMSI is not present in the update PDP context request. The PGW/SGW considers this a mandatory IE instead of an optional ID, and drops the incoming request.
Workaround: There is currently no known workaround.
•
Not all GTPv1 PDPs are cleared on newly active PGW when the restart counter is changed and a failover occurs at the same time.
Workaround: There is currently no known workaround.
•
Incorrect values for APN counters display when a PDP is reassigned to a different Traffic and Control Plane processor (TCOP).
This condition occurs only when a PDP is reassigned to a different TCOP.
Workaround: There is currently no known workaround.
•
The following syslog message might seen:
%IPC-3-SAMI_SM_FAIL_DUP_MSISDN: Unexpected condition: TCOP in IMSI-Sticky doesn't match with MSISDN-Sticky.This message might be seen with one of the following:
a.
b.
The message does not appear to impact any functionality.
Workaround: There is currently no known workaround.
•
When polling of cGgsnExtSubscriberTable for GTPv2 calls, the trailing zeros of mobile station ISDNs (MSISDNs) are ignored.
When there are calls whose MSISDN has trailing zeros, snmpget appears to function properly, even if the zeros are omitted, as seen in the following example command output:
pgw-03#show gprs gtp pdp-context msisdnTID MS Addr Source SGW Addr SGSN Addr MSISDN APN2233445566110010 10.0.3.230 LOCAL 111.111.111.13 N/A 2233445566110000 broadbandAlthough there is only one session, the following snmpget returns same value:
snmpget -v 2c 130.130.0.10 -c abc cGgsnExtSubscriberTid.12.50.50.51.51.52.52.53.53.54.54.49.49CISCO-GGSN-EXT-MIB::cGgsnExtSubscriberTid."223344556611" = STRING: 2233445566110010snmpget -v 2c 130.130.0.10 -c abc cGgsnExtSubscriberTid.14.50.50.51.51.52.52.53.53.54.54.49.49.48.48CISCO-GGSN-EXT-MIB::cGgsnExtSubscriberTid."22334455661100" = STRING: 2233445566110010snmpget -v 2c 130.130.0.10 -c abc cGgsnExtSubscriberTid.16.50.50.51.51.52.52.53.53.54.54.49.49.48.48.48.48CISCO-GGSN-EXT-MIB::cGgsnExtSubscriberTid."2233445566110000" = STRING: 2233445566110010Workaround: Ensure that the scenario like below does not occur (two calls with the same MSISDN, minus two trailing zeros at the end of one):
pgw-03#show gprs gtp pdp-context msisdnTID MS Addr Source SGW Addr SGSN Addr MSISDN APN2233445566110010 10.0.3.230 LOCAL 111.111.111.13 N/A 2233445566110000 broadband9933445566113314 10.0.3.250 LOCAL 111.111.111.13 N/A 22334455661100 broadband•
Negative values for global and path statistics are retrieved by the Mobile Wireless Transport Manager (MWTM) when polling standby gateway.
This condition occurs when the MWTM polls the GTP-MIB and the GTPv2-MIB on the standby gateway.
Workaround: There is currently no known workaround.
•
Spurious memory access tracebacks are observed when a GTPv2 session is handed off to a GTPv1 PDP while the session is waiting for an update bearer response. While a traceback is observed, the GTPv2-to-GTPv1 handoff is successful and no impact to functionality is observed.
This condition occurs only when a GTPv2-to-GTPv1 handoff is occurring while the GTPv2 session is waiting for an update bearer response.
Workaround: There is currently no known workaround.
•
There are no counters present to verify the drops from pending_requestQ per PDP.
A maximum of 16 PDPs can be queued for processing. Currently, there are no counters to check the current status of the queue, and to see if any messages are dropped from the queue.
Workaround: There is currently no known workaround.
•
The Cisco LTE gateways print the following error message to the console if they receive a Version Not Supported message from the charging gateway.
%GTP-0-CORRUPTED_GTP_BYTE_STREAM: Corrupted byte stream, GSN: 172.16.57.15, Closing socket%GTP-0-PACKETPARSINGERROR: GSN: 172.16.78.83, TID: 00, APN: NULL, Reason: LFN in CHRG msg should be set%GTP-0-PACKETPARSINGERROR: GSN: 172.16.57.15, TID: 00, APN: NULL, Reason: Unexpected message 0x1AThis condition occurs because the Cisco LTE gateways are unable to parse the Version Not Supported packet. The TCP connection between LTE gateways and the charging gateway is re-established to recover from this condition.
Workaround: There is currently no known workaround.
•
The Cisco Mobile Wireless Transport Manager (MWTM) is unable to scale with the number of entries provided by the GTPv2 MIB path table.
This condition occurs when GTPv2 reporting is enabled on the MWTM.
Workaround: Disable GTPv2 reporting on the MWTM.
•
The primary charging gateway is active on the Proxy Control Processor (PCOP) and the secondary charging gateway is active on the Traffic and Control Plane processors (TCOPs).
This condition occurs when the Version Not Support message is received on the gateway PCOP.
Workaround: The workaround for this condition is present in the code. The PCOP detects the mismatch of charging gateways on different processors and disconnects and reestablishes the TCP connection with the primary charging gateway.
•
The standby PGW might not update session QoS correctly after a policy control and charging rules function (PCRF) Re-Auth-Request (RAR).
This condition occurs only when the PGW receives an update bearer request due to a PCRF RAR and a modify bearer request from an SGW due to a UE X2 handoff at the same time. If the messages are received sequentially with proper responses, the condition does not occur.
Workaround: There is currently no known workaround.
Cisco SAMI Caveats
The following Cisco SAMI caveats are open with Cisco IOS Release 12.4(24)T35f.
•
In a redundant implementation, one of the Cisco SAMIs remains in a STANDBY-COLD state indefinitely. When in a STANDBY-COLD state, sessions are not sychronized to the standby Cisco SAMI.
This condition is seen on occasions when both of the Cisco SAMIs that are a part of a redundant implementation are reloaded at very close times.
Workaround: Reload the Cisco SAMI that is in STANDBY-COLD state.
•
On rare occasions, a Cisco SAMI coming up as a standby (in a redundant implementation) reloads immediately after booting up because of IXP network processor health monitoring failures.
These IXP health monitoring failures are only seen on Cisco SAMIs coming up as the standby gateway in a redundant implementation.
Workaround: The Cisco SAMI reloads correctly on its own on the next attempt.
•
The Cisco SAMI reloads due to an LCP-to-PPC health monitoring failure.
This reload occurs only when the very rare condition of a flash operation happening at the same time a software issues causes a crash.
Workaround: There is currently no known workaround.
•
The Cisco SAMI reboots with following logs displaying at the supervisor console:
Card in module slot_num, is being power-cycled off (Module not responding to Keep Alive polling)After the reload, the dir core: in LCP does not contain any logs that indicate the reason for the reload.
It is not clear what conditions trigger this error since there were no specific activities going through the LCP at the time the reload occurred.
Workaround: There is currently no known workaround.
Resolved Caveats
The following sections list the caveats that have been resolved in Cisco LTE PGW Release 1.3.7e, Cisco IOS Release 12.4(24)T35f.
Cisco LTE PGW Caveats
The following caveat has been resolved with with Cisco IOS Release 12.4(24)T35f.
•
Update PDP context request fails due to Quality of Service (QoS) negotiation.
The gateway does not support a check for the "No QOS Negotiation" flag.
QoS is negotiatied even though the common flag is set to "No QOS Negotiation" and the gateway sends the SGW/SGSN negotitated QOS value.
•
The LTE gateway supports up to 4K GTPv1-U data paths. Therefore, session creation attempts from new SGSN/MME fail if the total GTPv1-U data paths on the LTE GW exceeds 4K.
Cisco SAMI Caveats
There are no Cisco SAMI caveats newly resolved with Cisco IOS Release 12.4(24)T35f.
Caveats - Cisco LTE PGW Release 1.3.7d, Cisco IOS Release 12.4(24)T34f
This section lists the open, resolved and unreproducible caveats that pertain to Cisco LTE PGW Release 1.3.7d, Cisco IOS Release 12.4(24)T34f.
Open Caveats
Note
The following sections document possible unexpected behavior and describe only severity 1 and 2 caveats and select severity 3 caveats.
Cisco LTE PGW Caveats
The following Cisco LTE PGW caveats are open in Cisco IOS Release 12.4(24)T34f.
•
During the creation of a session, if a failure response from the IXP occurs while the session is being deleted under a specific timing window (for example, the IXP might already have an entry), the PGW might reload.
This is a timing condition between the completion of accounting start and the deletion of a session under a specific timing window.
Workaround: There is currently no known workaround.
•
The Cisco LTE PGW/SGW might drop an update PDP context requests because of an International Mobile Subscriber Identity (IMSI) mandatory information element (IE) missing error. This condition occurs during a GTPv0-to-GTPv1 handoff or during a GTPv2-to-GTPv1 handoff if the IMSI is not present in the update PDP context request. The PGW/SGW considers this a mandatory IE instead of an optional ID, and drops the incoming request.
Workaround: There is currently no known workaround.
•
Not all GTPv1 PDPs are cleared on newly active PGW when the restart counter is changed and a failover occurs at the same time.
Workaround: There is currently no known workaround.
•
Incorrect values for APN counters display when a PDP is reassigned to a different Traffic and Control Plane processor (TCOP).
This condition occurs only when a PDP is reassigned to a different TCOP.
Workaround: There is currently no known workaround.
•
The following syslog message might seen:
%IPC-3-SAMI_SM_FAIL_DUP_MSISDN: Unexpected condition: TCOP in IMSI-Sticky doesn't match with MSISDN-Sticky.This message might be seen with one of the following:
a.
b.
The message does not appear to impact any functionality.
Workaround: There is currently no known workaround.
•
When polling of cGgsnExtSubscriberTable for GTPv2 calls, the trailing zeros of mobile station ISDNs (MSISDNs) are ignored.
When there are calls whose MSISDN has trailing zeros, snmpget appears to function properly, even if the zeros are omitted, as seen in the following example command output:
pgw-03#show gprs gtp pdp-context msisdnTID MS Addr Source SGW Addr SGSN Addr MSISDN APN2233445566110010 10.0.3.230 LOCAL 111.111.111.13 N/A 2233445566110000 broadbandAlthough there is only one session, the following snmpget returns same value:
snmpget -v 2c 130.130.0.10 -c abc cGgsnExtSubscriberTid.12.50.50.51.51.52.52.53.53.54.54.49.49CISCO-GGSN-EXT-MIB::cGgsnExtSubscriberTid."223344556611" = STRING: 2233445566110010snmpget -v 2c 130.130.0.10 -c abc cGgsnExtSubscriberTid.14.50.50.51.51.52.52.53.53.54.54.49.49.48.48CISCO-GGSN-EXT-MIB::cGgsnExtSubscriberTid."22334455661100" = STRING: 2233445566110010snmpget -v 2c 130.130.0.10 -c abc cGgsnExtSubscriberTid.16.50.50.51.51.52.52.53.53.54.54.49.49.48.48.48.48CISCO-GGSN-EXT-MIB::cGgsnExtSubscriberTid."2233445566110000" = STRING: 2233445566110010Workaround: Ensure that the scenario like below does not occur (two calls with the same MSISDN, minus two trailing zeros at the end of one):
pgw-03#show gprs gtp pdp-context msisdnTID MS Addr Source SGW Addr SGSN Addr MSISDN APN2233445566110010 10.0.3.230 LOCAL 111.111.111.13 N/A 2233445566110000 broadband9933445566113314 10.0.3.250 LOCAL 111.111.111.13 N/A 22334455661100 broadband•
Negative values for global and path statistics are retrieved by the Mobile Wireless Transport Manager (MWTM) when polling standby gateway.
This condition occurs when the MWTM polls the GTP-MIB and the GTPv2-MIB on the standby gateway.
Workaround: There is currently no known workaround.
•
Spurious memory access tracebacks are observed when a GTPv2 session is handed off to a GTPv1 PDP while the session is waiting for an update bearer response. While a traceback is observed, the GTPv2-to-GTPv1 handoff is successful and no impact to functionality is observed.
This condition occurs only when a GTPv2-to-GTPv1 handoff is occurring while the GTPv2 session is waiting for an update bearer response.
Workaround: There is currently no known workaround.
•
There are no counters present to verify the drops from pending_requestQ per PDP.
A maximum of 16 PDPs can be queued for processing. Currently, there are no counters to check the current status of the queue, and to see if any messages are dropped from the queue.
Workaround: There is currently no known workaround.
•
The Cisco LTE gateways print the following error message to the console if they receive a Version Not Supported message from the charging gateway.
%GTP-0-CORRUPTED_GTP_BYTE_STREAM: Corrupted byte stream, GSN: 172.16.57.15, Closing socket%GTP-0-PACKETPARSINGERROR: GSN: 172.16.78.83, TID: 00, APN: NULL, Reason: LFN in CHRG msg should be set%GTP-0-PACKETPARSINGERROR: GSN: 172.16.57.15, TID: 00, APN: NULL, Reason: Unexpected message 0x1AThis condition occurs because the Cisco LTE gateways are unable to parse the Version Not Supported packet. The TCP connection between LTE gateways and the charging gateway is re-established to recover from this condition.
Workaround: There is currently no known workaround.
•
The Cisco Mobile Wireless Transport Manager (MWTM) is unable to scale with the number of entries provided by the GTPv2 MIB path table.
This condition occurs when GTPv2 reporting is enabled on the MWTM.
Workaround: Disable GTPv2 reporting on the MWTM.
•
The primary charging gateway is active on the Proxy Control Processor (PCOP) and the secondary charging gateway is active on the Traffic and Control Plane processors (TCOPs).
This condition occurs when the Version Not Support message is received on the gateway PCOP.
Workaround: The workaround for this condition is present in the code. The PCOP detects the mismatch of charging gateways on different processors and disconnects and reestablishes the TCP connection with the primary charging gateway.
•
The standby PGW might not update session QoS correctly after a policy control and charging rules function (PCRF) Re-Auth-Request (RAR).
This condition occurs only when the PGW receives an update bearer request due to a PCRF RAR and a modify bearer request from an SGW due to a UE X2 handoff at the same time. If the messages are received sequentially with proper responses, the condition does not occur.
Workaround: There is currently no known workaround.
Cisco SAMI Caveats
The following Cisco SAMI caveats are open with Cisco IOS Release 12.4(24)T34f.
•
In a redundant implementation, one of the Cisco SAMIs remains in a STANDBY-COLD state indefinitely. When in a STANDBY-COLD state, sessions are not sychronized to the standby Cisco SAMI.
This condition is seen on occasions when both of the Cisco SAMIs that are a part of a redundant implementation are reloaded at very close times.
Workaround: Reload the Cisco SAMI that is in STANDBY-COLD state.
•
On rare occasions, a Cisco SAMI coming up as a standby (in a redundant implementation) reloads immediately after booting up because of IXP network processor health monitoring failures.
These IXP health monitoring failures are only seen on Cisco SAMIs coming up as the standby gateway in a redundant implementation.
Workaround: The Cisco SAMI reloads correctly on its own on the next attempt.
•
The Cisco SAMI reloads due to an LCP-to-PPC health monitoring failure.
This reload occurs only when the very rare condition of a flash operation happening at the same time a software issues causes a crash.
Workaround: There is currently no known workaround.
•
The Cisco SAMI reboots with following logs displaying at the supervisor console:
Card in module slot_num, is being power-cycled off (Module not responding to Keep Alive polling)After the reload, the dir core: in LCP does not contain any logs that indicate the reason for the reload.
It is not clear what conditions trigger this error since there were no specific activities going through the LCP at the time the reload occurred.
Workaround: There is currently no known workaround.
Resolved Caveats
The following sections list the caveats that have been resolved in Cisco LTE PGW Release 1.3.7d, Cisco IOS Release 12.4(24)T34f.
Cisco LTE PGW Caveats
The following caveat has been resolved with with Cisco IOS Release 12.4(24)T34f.
•
The CPU usage spikes on both the Proxy Control Processor (PCOP) and the Traffic and Control Plane processors (TCOPs) when there are large number of GTP paths on the gateway.
This increased CPU usage occurs with the following conditions:
a.
b.
c.
Cisco SAMI Caveats
There are no Cisco SAMI caveats newly resolved with Cisco IOS Release 12.4(24)T34f.
Caveats - Cisco LTE PGW Release 1.3.7c, Cisco IOS Release 12.4(24)T33f
This section lists the open, resolved and unreproducible caveats that pertain to Cisco LTE PGW Release 1.3.7c, Cisco IOS Release 12.4(24)T33f.
Open Caveats
Note
The following sections document possible unexpected behavior and describe only severity 1 and 2 caveats and select severity 3 caveats.
Cisco LTE PGW Caveats
The following Cisco LTE PGW caveats are open in Cisco IOS Release 12.4(24)T33f.
•
During the creation of a session, if a failure response from the IXP occurs while the session is being deleted under a specific timing window (for example, the IXP might already have an entry), the PGW might reload.
This is a timing condition between the completion of accounting start and the deletion of a session under a specific timing window.
Workaround: There is currently no known workaround.
•
The Cisco LTE PGW/SGW might drop an update PDP context requests because of an International Mobile Subscriber Identity (IMSI) mandatory information element (IE) missing error. This condition occurs during a GTPv0-to-GTPv1 handoff or during a GTPv2-to-GTPv1 handoff if the IMSI is not present in the update PDP context request. The PGW/SGW considers this a mandatory IE instead of an optional ID, and drops the incoming request.
Workaround: There is currently no known workaround.
•
Not all GTPv1 PDPs are cleared on newly active PGW when the restart counter is changed and a failover occurs at the same time.
Workaround: There is currently no known workaround.
•
Incorrect values for APN counters display when a PDP is reassigned to a different Traffic and Control Plane processor (TCOP).
This condition occurs only when a PDP is reassigned to a different TCOP.
Workaround: There is currently no known workaround.
•
The following syslog message might seen:
%IPC-3-SAMI_SM_FAIL_DUP_MSISDN: Unexpected condition: TCOP in IMSI-Sticky doesn't match with MSISDN-Sticky.This message might be seen with one of the following:
a.
b.
The message does not appear to impact any functionality.
Workaround: There is currently no known workaround.
•
When polling of cGgsnExtSubscriberTable for GTPv2 calls, the trailing zeros of mobile station ISDNs (MSISDNs) are ignored.
When there are calls whose MSISDN has trailing zeros, snmpget appears to function properly, even if the zeros are omitted, as seen in the following example command output:
pgw-03#show gprs gtp pdp-context msisdnTID MS Addr Source SGW Addr SGSN Addr MSISDN APN2233445566110010 10.0.3.230 LOCAL 111.111.111.13 N/A 2233445566110000 broadbandAlthough there is only one session, the following snmpget returns same value:
snmpget -v 2c 130.130.0.10 -c abc cGgsnExtSubscriberTid.12.50.50.51.51.52.52.53.53.54.54.49.49CISCO-GGSN-EXT-MIB::cGgsnExtSubscriberTid."223344556611" = STRING: 2233445566110010snmpget -v 2c 130.130.0.10 -c abc cGgsnExtSubscriberTid.14.50.50.51.51.52.52.53.53.54.54.49.49.48.48CISCO-GGSN-EXT-MIB::cGgsnExtSubscriberTid."22334455661100" = STRING: 2233445566110010snmpget -v 2c 130.130.0.10 -c abc cGgsnExtSubscriberTid.16.50.50.51.51.52.52.53.53.54.54.49.49.48.48.48.48CISCO-GGSN-EXT-MIB::cGgsnExtSubscriberTid."2233445566110000" = STRING: 2233445566110010Workaround: Ensure that the scenario like below does not occur (two calls with the same MSISDN, minus two trailing zeros at the end of one):
pgw-03#show gprs gtp pdp-context msisdnTID MS Addr Source SGW Addr SGSN Addr MSISDN APN2233445566110010 10.0.3.230 LOCAL 111.111.111.13 N/A 2233445566110000 broadband9933445566113314 10.0.3.250 LOCAL 111.111.111.13 N/A 22334455661100 broadband•
Negative values for global and path statistics are retrieved by the Mobile Wireless Transport Manager (MWTM) when polling standby gateway.
This condition occurs when the MWTM polls the GTP-MIB and the GTPv2-MIB on the standby gateway.
Workaround: There is currently no known workaround.
•
Spurious memory access tracebacks are observed when a GTPv2 session is handed off to a GTPv1 PDP while the session is waiting for an update bearer response. While a traceback is observed, the GTPv2-to-GTPv1 handoff is successful and no impact to functionality is observed.
This condition occurs only when a GTPv2-to-GTPv1 handoff is occurring while the GTPv2 session is waiting for an update bearer response.
Workaround: There is currently no known workaround.
•
There are no counters present to verify the drops from pending_requestQ per PDP.
A maximum of 16 PDPs can be queued for processing. Currently, there are no counters to check the current status of the queue, and to see if any messages are dropped from the queue.
Workaround: There is currently no known workaround.
•
The Cisco LTE gateways print the following error message to the console if they receive a Version Not Supported message from the charging gateway.
%GTP-0-CORRUPTED_GTP_BYTE_STREAM: Corrupted byte stream, GSN: 172.16.57.15, Closing socket%GTP-0-PACKETPARSINGERROR: GSN: 172.16.78.83, TID: 00, APN: NULL, Reason: LFN in CHRG msg should be set%GTP-0-PACKETPARSINGERROR: GSN: 172.16.57.15, TID: 00, APN: NULL, Reason: Unexpected message 0x1AThis condition occurs because the Cisco LTE gateways are unable to parse the Version Not Supported packet. The TCP connection between LTE gateways and the charging gateway is re-established to recover from this condition.
Workaround: There is currently no known workaround.
•
The Cisco Mobile Wireless Transport Manager (MWTM) is unable to scale with the number of entries provided by the GTPv2 MIB path table.
This condition occurs when GTPv2 reporting is enabled on the MWTM.
Workaround: Disable GTPv2 reporting on the MWTM.
•
The primary charging gateway is active on the Proxy Control Processor (PCOP) and the secondary charging gateway is active on the Traffic and Control Plane processors (TCOPs).
This condition occurs when the Version Not Support message is received on the gateway PCOP.
Workaround: The workaround for this condition is present in the code. The PCOP detects the mismatch of charging gateways on different processors and disconnects and reestablishes the TCP connection with the primary charging gateway.
•
The standby PGW might not update session QoS correctly after a policy control and charging rules function (PCRF) Re-Auth-Request (RAR).
This condition occurs only when the PGW receives an update bearer request due to a PCRF RAR and a modify bearer request from an SGW due to a UE X2 handoff at the same time. If the messages are received sequentially with proper responses, the condition does not occur.
Workaround: There is currently no known workaround.
Cisco SAMI Caveats
The following Cisco SAMI caveats are open with Cisco IOS Release 12.4(24)T33f.
•
In a redundant implementation, one of the Cisco SAMIs remains in a STANDBY-COLD state indefinitely. When in a STANDBY-COLD state, sessions are not sychronized to the standby Cisco SAMI.
This condition is seen on occasions when both of the Cisco SAMIs that are a part of a redundant implementation are reloaded at very close times.
Workaround: Reload the Cisco SAMI that is in STANDBY-COLD state.
•
On rare occasions, a Cisco SAMI coming up as a standby (in a redundant implementation) reloads immediately after booting up because of IXP network processor health monitoring failures.
These IXP health monitoring failures are only seen on Cisco SAMIs coming up as the standby gateway in a redundant implementation.
Workaround: The Cisco SAMI reloads correctly on its own on the next attempt.
•
The Cisco SAMI reloads due to an LCP-to-PPC health monitoring failure.
This reload occurs only when the very rare condition of a flash operation happening at the same time a software issues causes a crash.
Workaround: There is currently no known workaround.
•
The Cisco SAMI reboots with following logs displaying at the supervisor console:
Card in module slot_num, is being power-cycled off (Module not responding to Keep Alive polling)After the reload, the dir core: in LCP does not contain any logs that indicate the reason for the reload.
It is not clear what conditions trigger this error since there were no specific activities going through the LCP at the time the reload occurred.
Workaround: There is currently no known workaround.
Resolved Caveats
The following sections list the caveats that have been resolved in Cisco LTE PGW Release 1.3.7c, Cisco IOS Release 12.4(24)T33f.
Cisco LTE PGW Caveats
There are no Cisco LTE PGW caveats newly resolved with Cisco LTE PGW Release 1.3.7c, Cisco IOS Release 12.4(24)T33f.
Cisco SAMI Caveats
There are no Cisco SAMI caveats newly resolved with Cisco LTE PGW Release 1.3.7c, Cisco IOS Release 12.4(24)T33f.
Caveats - Cisco LTE PGW Release 1.3.7b, Cisco IOS Release 12.4(24)T32f
This section lists the open, resolved and unreproducible caveats that pertain to Cisco LTE PGW Release 1.3.7b, Cisco IOS Release 12.4(24)T32f.
Open Caveats
Note
The following sections document possible unexpected behavior and describe only severity 1 and 2 caveats and select severity 3 caveats.
Cisco LTE PGW Caveats
The following Cisco LTE PGW caveats are open in Cisco IOS Release 12.4(24)T32f.
•
During the creation of a session, if a failure response from the IXP occurs while the session is being deleted under a specific timing window (for example, the IXP might already have an entry), the PGW might reload.
This is a timing condition between the completion of accounting start and the deletion of a session under a specific timing window.
Workaround: There is currently no known workaround.
•
The Cisco LTE PGW/SGW might drop an update PDP context requests because of an International Mobile Subscriber Identity (IMSI) mandatory information element (IE) missing error. This condition occurs during a GTPv0-to-GTPv1 handoff or during a GTPv2-to-GTPv1 handoff if the IMSI is not present in the update PDP context request. The PGW/SGW considers this a mandatory IE instead of an optional ID, and drops the incoming request.
Workaround: There is currently no known workaround.
•
Not all GTPv1 PDPs are cleared on newly active PGW when the restart counter is changed and a failover occurs at the same time.
Workaround: There is currently no known workaround.
•
Incorrect values for APN counters display when a PDP is reassigned to a different Traffic and Control Plane processor (TCOP).
This condition occurs only when a PDP is reassigned to a different TCOP.
Workaround: There is currently no known workaround.
•
The following syslog message might seen:
%IPC-3-SAMI_SM_FAIL_DUP_MSISDN: Unexpected condition: TCOP in IMSI-Sticky doesn't match with MSISDN-Sticky.This message might be seen with one of the following:
a.
b.
The message does not appear to impact any functionality.
Workaround: There is currently no known workaround.
•
When polling of cGgsnExtSubscriberTable for GTPv2 calls, the trailing zeros of mobile station ISDNs (MSISDNs) are ignored.
When there are calls whose MSISDN has trailing zeros, snmpget appears to function properly, even if the zeros are omitted, as seen in the following example command output:
pgw-03#show gprs gtp pdp-context msisdnTID MS Addr Source SGW Addr SGSN Addr MSISDN APN2233445566110010 10.0.3.230 LOCAL 111.111.111.13 N/A 2233445566110000 broadbandAlthough there is only one session, the following snmpget returns same value:
snmpget -v 2c 130.130.0.10 -c abc cGgsnExtSubscriberTid.12.50.50.51.51.52.52.53.53.54.54.49.49CISCO-GGSN-EXT-MIB::cGgsnExtSubscriberTid."223344556611" = STRING: 2233445566110010snmpget -v 2c 130.130.0.10 -c abc cGgsnExtSubscriberTid.14.50.50.51.51.52.52.53.53.54.54.49.49.48.48CISCO-GGSN-EXT-MIB::cGgsnExtSubscriberTid."22334455661100" = STRING: 2233445566110010snmpget -v 2c 130.130.0.10 -c abc cGgsnExtSubscriberTid.16.50.50.51.51.52.52.53.53.54.54.49.49.48.48.48.48CISCO-GGSN-EXT-MIB::cGgsnExtSubscriberTid."2233445566110000" = STRING: 2233445566110010Workaround: Ensure that the scenario like below does not occur (two calls with the same MSISDN, minus two trailing zeros at the end of one):
pgw-03#show gprs gtp pdp-context msisdnTID MS Addr Source SGW Addr SGSN Addr MSISDN APN2233445566110010 10.0.3.230 LOCAL 111.111.111.13 N/A 2233445566110000 broadband9933445566113314 10.0.3.250 LOCAL 111.111.111.13 N/A 22334455661100 broadband•
Negative values for global and path statistics are retrieved by the Mobile Wireless Transport Manager (MWTM) when polling standby gateway.
This condition occurs when the MWTM polls the GTP-MIB and the GTPv2-MIB on the standby gateway.
Workaround: There is currently no known workaround.
•
Spurious memory access tracebacks are observed when a GTPv2 session is handed off to a GTPv1 PDP while the session is waiting for an update bearer response. While a traceback is observed, the GTPv2-to-GTPv1 handoff is successful and no impact to functionality is observed.
This condition occurs only when a GTPv2-to-GTPv1 handoff is occurring while the GTPv2 session is waiting for an update bearer response.
Workaround: There is currently no known workaround.
•
There are no counters present to verify the drops from pending_requestQ per PDP.
A maximum of 16 PDPs can be queued for processing. Currently, there are no counters to check the current status of the queue, and to see if any messages are dropped from the queue.
Workaround: There is currently no known workaround.
•
The Cisco LTE gateways print the following error message to the console if they receive a Version Not Supported message from the charging gateway.
%GTP-0-CORRUPTED_GTP_BYTE_STREAM: Corrupted byte stream, GSN: 172.16.57.15, Closing socket%GTP-0-PACKETPARSINGERROR: GSN: 172.16.78.83, TID: 00, APN: NULL, Reason: LFN in CHRG msg should be set%GTP-0-PACKETPARSINGERROR: GSN: 172.16.57.15, TID: 00, APN: NULL, Reason: Unexpected message 0x1AThis condition occurs because the Cisco LTE gateways are unable to parse the Version Not Supported packet. The TCP connection between LTE gateways and the charging gateway is re-established to recover from this condition.
Workaround: There is currently no known workaround.
•
The Cisco Mobile Wireless Transport Manager (MWTM) is unable to scale with the number of entries provided by the GTPv2 MIB path table.
This condition occurs when GTPv2 reporting is enabled on the MWTM.
Workaround: Disable GTPv2 reporting on the MWTM.
•
The primary charging gateway is active on the Proxy Control Processor (PCOP) and the secondary charging gateway is active on the Traffic and Control Plane processors (TCOPs).
This condition occurs when the Version Not Support message is received on the gateway PCOP.
Workaround: The workaround for this condition is present in the code. The PCOP detects the mismatch of charging gateways on different processors and disconnects and reestablishes the TCP connection with the primary charging gateway.
•
The standby PGW might not update session QoS correctly after a policy control and charging rules function (PCRF) Re-Auth-Request (RAR).
This condition occurs only when the PGW receives an update bearer request due to a PCRF RAR and a modify bearer request from an SGW due to a UE X2 handoff at the same time. If the messages are received sequentially with proper responses, the condition does not occur.
Workaround: There is currently no known workaround.
Cisco SAMI Caveats
The following Cisco SAMI caveats are open with Cisco IOS Release 12.4(24)T32f.
•
In a redundant implementation, one of the Cisco SAMIs remains in a STANDBY-COLD state indefinitely. When in a STANDBY-COLD state, sessions are not sychronized to the standby Cisco SAMI.
This condition is seen on occasions when both of the Cisco SAMIs that are a part of a redundant implementation are reloaded at very close times.
Workaround: Reload the Cisco SAMI that is in STANDBY-COLD state.
•
On rare occasions, a Cisco SAMI coming up as a standby (in a redundant implementation) reloads immediately after booting up because of IXP network processor health monitoring failures.
These IXP health monitoring failures are only seen on Cisco SAMIs coming up as the standby gateway in a redundant implementation.
Workaround: The Cisco SAMI reloads correctly on its own on the next attempt.
•
The Cisco SAMI reloads due to an LCP-to-PPC health monitoring failure.
This reload occurs only when the very rare condition of a flash operation happening at the same time a software issues causes a crash.
Workaround: There is currently no known workaround.
•
The Cisco SAMI reboots with following logs displaying at the supervisor console:
Card in module slot_num, is being power-cycled off (Module not responding to Keep Alive polling)After the reload, the dir core: in LCP does not contain any logs that indicate the reason for the reload.
It is not clear what conditions trigger this error since there were no specific activities going through the LCP at the time the reload occurred.
Workaround: There is currently no known workaround.
Resolved Caveats
The following sections list the caveats that have been resolved in Cisco LTE PGW Release 1.3.7b, Cisco IOS Release 12.4(24)T32f.
Cisco LTE PGW Caveats
The following PGW caveats are resolved in Cisco IOS Release 12.4(24)T32f.
•
The Cisco LTE PGW crashes while sending data traffic when a 4G-to-3G handoff is in progress. This crash is seen only during a race condition when data traffic is being switched during a 4G-to-3G handoff. This condition is rare and exists in Release 1.3.7a and prior releases.
Workaround: There is currently no known workaround.
•
Currently, when a PowerPC (PPC) crash due to a BUS error occurs, the PPC does not store the address access that caused the BUS error. This condition occurs when there is a machine check exception.
•
Cisco PGW might report the DFP weight as zero (0) to the Cisco SLB and get throttled. This happens when the bearer metric value reported by TCOPs on a PGW is 0. This issue is seen only when a very high number of GTPv2 to GTPv1 handoffs are occurring and the sum of current active sessions plus the GTPv2-to-GTPv1 handoff counts exceeds the maximum configured bearer capacity of PGW.
Cisco SAMI Caveats
The following Cisco SAMI caveat is resolved with Cisco LTE PGW Release 1.3.7b, Cisco IOS Release 12.4(24)T32f.
•
After a reload, the show version command output displays the reload reason as "System returned to ROM by error - Bus Error, PC 0x0." This condition occurs when a PPC encounters a machine check exception due to a PC bus error.
•
The show version command output after a Cisco SAMI reload displays the Proxy Control Processor (PCOP) reload reason as "reloaded by admin" when a Traffic and Control Processor (TCOP) reloads because of a machine check exception (PC bus error). This condition exists with a Cisco SAMI reload due to the machine check exception (PC bus error) seen in a TCOP.
•
Crashinfo and Debuginfo contains only one single line. This condition is not specific to any crash and can occur because of an RF-induced reload, software crash, health monitoring failure, etcetera.
•
When a crash (RF-Induced reload/HM-failure) occurs, the "Crashinfo_proc/debuginfo_proc" is missing in the crashinfo_collection.tar file.
Unreproducible Caveats
The following caveats have not been reproduced with Cisco LTE PGW Release 1.3.7b, Cisco IOS Release 12.4(24)T32f.
•
A Traffic and Control Plane processor (TCOP) triggers RF-induced reload of the standby.
This condition occurs due to an "Out of Window" data reception in the TCOP.
•
The Cisco SAMI reloads with the following error message:
%SAMI-2-SAMI_SYSLOG_CRIT: SAMI 1/0: %SAMI-2-443001: System experienced fatal failure.Service name:System Manager (core-server)(30380) has terminated on receiving signal 11,reloading systemAs part of the crash info, the core file "qnx_1_io-net_114693_core" is generated. "114693" is the process ID for network I/O support (io-net), and might vary from case to case.
Conditions that might cause this reload are not known.
•
A few sessions are dropped during a 3G-to-4G handoff.
This condition occurs when there are a large number of sessions (~10000) for which there is a 3G-to-4G handoff occurring with continuous data transfer. The dropped sessions are not seen with fewer number of sessions (~1000) or when continuous data transfer is not occurring during handoff.
Caveats - Cisco LTE PGW Release 1.3.7a, Cisco IOS Release 12.4(24)T31f
This section lists the open, resolved and unreproducible caveats that pertain to Cisco LTE PGW Release 1.3.7a, Cisco IOS Release 12.4(24)T31f.
Open Caveats
Note
The following sections document possible unexpected behavior and describe only severity 1 and 2 caveats and select severity 3 caveats.
Cisco LTE PGW Caveats
The following Cisco LTE PGW caveats are open in Cisco IOS Release 12.4(24)T31f.
•
During the creation of a session, if a failure response from the IXP occurs while the session is being deleted under a specific timing window (for example, the IXP might already have an entry), the PGW might reload.
This is a timing condition between the completion of accounting start and the deletion of a session under a specific timing window.
Workaround: There is currently no known workaround.
•
The Cisco LTE PGW/SGW might drop an update PDP context requests because of an International Mobile Subscriber Identity (IMSI) mandatory information element (IE) missing error. This condition occurs during a GTPv0-to-GTPv1 handoff or during a GTPv2-to-GTPv1 handoff if the IMSI is not present in the update PDP context request. The PGW/SGW considers this a mandatory IE instead of an optional ID, and drops the incoming request.
Workaround: There is currently no known workaround.
•
The counters for the G-PDU bits in the Cisco Mobile Wireless Transport Manger (MWTM) display a negative value.
Workaround: There is currently no known workaround.
•
Not all GTPv1 PDPs are cleared on newly active PGW when the restart counter is changed and a failover occurs at the same time.
Workaround: There is currently no known workaround.
•
Incorrect values for APN counters display when a PDP is reassigned to a different Traffic and Control Plane processor (TCOP).
This condition occurs only when a PDP is reassigned to a different TCOP.
Workaround: There is currently no known workaround.
•
The following syslog message might seen:
%IPC-3-SAMI_SM_FAIL_DUP_MSISDN: Unexpected condition: TCOP in IMSI-Sticky doesn't match with MSISDN-Sticky.This message might be seen with one of the following:
a.
b.
The message does not appear to impact any functionality.
Workaround: There is currently no known workaround.
•
When polling of cGgsnExtSubscriberTable for GTPv2 calls, the trailing zeros of mobile station ISDNs (MSISDNs) are ignored.
When there are calls whose MSISDN has trailing zeros, snmpget appears to function properly, even if the zeros are omitted, as seen in the following example command output:
pgw-03#show gprs gtp pdp-context msisdnTID MS Addr Source SGW Addr SGSN Addr MSISDN APN2233445566110010 10.0.3.230 LOCAL 111.111.111.13 N/A 2233445566110000 broadbandAlthough there is only one session, the following snmpget returns same value:
snmpget -v 2c 130.130.0.10 -c abc cGgsnExtSubscriberTid.12.50.50.51.51.52.52.53.53.54.54.49.49CISCO-GGSN-EXT-MIB::cGgsnExtSubscriberTid."223344556611" = STRING: 2233445566110010snmpget -v 2c 130.130.0.10 -c abc cGgsnExtSubscriberTid.14.50.50.51.51.52.52.53.53.54.54.49.49.48.48CISCO-GGSN-EXT-MIB::cGgsnExtSubscriberTid."22334455661100" = STRING: 2233445566110010snmpget -v 2c 130.130.0.10 -c abc cGgsnExtSubscriberTid.16.50.50.51.51.52.52.53.53.54.54.49.49.48.48.48.48CISCO-GGSN-EXT-MIB::cGgsnExtSubscriberTid."2233445566110000" = STRING: 2233445566110010Workaround: Ensure that the scenario like below does not occur (two calls with the same MSISDN, minus two trailing zeros at the end of one):
pgw-03#show gprs gtp pdp-context msisdnTID MS Addr Source SGW Addr SGSN Addr MSISDN APN2233445566110010 10.0.3.230 LOCAL 111.111.111.13 N/A 2233445566110000 broadband9933445566113314 10.0.3.250 LOCAL 111.111.111.13 N/A 22334455661100 broadband•
Negative values for global and path statistics are retrieved by the Mobile Wireless Transport Manager (MWTM) when polling standby gateway.
This condition occurs when the MWTM polls the GTP-MIB and the GTPv2-MIB on the standby gateway.
Workaround: There is currently no known workaround.
•
Spurious memory access tracebacks are observed when a GTPv2 session is handed off to a GTPv1 PDP while the session is waiting for an update bearer response. While a traceback is observed, the GTPv2-to-GTPv1 handoff is successful and no impact to functionality is observed.
This condition occurs only when a GTPv2-to-GTPv1 handoff is occurring while the GTPv2 session is waiting for an update bearer response.
Workaround: There is currently no known workaround.
•
There are no counters present to verify the drops from pending_requestQ per PDP.
A maximum of 16 PDPs can be queued for processing. Currently, there are no counters to check the current status of the queue, and to see if any messages are dropped from the queue.
Workaround: There is currently no known workaround.
•
The Cisco LTE gateways print the following error message to the console if they receive a Version Not Supported message from the charging gateway.
%GTP-0-CORRUPTED_GTP_BYTE_STREAM: Corrupted byte stream, GSN: 172.16.57.15, Closing socket%GTP-0-PACKETPARSINGERROR: GSN: 172.16.78.83, TID: 00, APN: NULL, Reason: LFN in CHRG msg should be set%GTP-0-PACKETPARSINGERROR: GSN: 172.16.57.15, TID: 00, APN: NULL, Reason: Unexpected message 0x1AThis condition occurs because the Cisco LTE gateways are unable to parse the Version Not Supported packet. The TCP connection between LTE gateways and the charging gateway is re-established to recover from this condition.
Workaround: There is currently no known workaround.
•
The Cisco Mobile Wireless Transport Manager (MWTM) is unable to scale with the number of entries provided by the GTPv2 MIB path table.
This condition occurs when GTPv2 reporting is enabled on the MWTM.
Workaround: Disable GTPv2 reporting on the MWTM.
•
The primary charging gateway is active on the Proxy Control Processor (PCOP) and the secondary charging gateway is active on the Traffic and Control Plane processors (TCOPs).
This condition occurs when the Version Not Support message is received on the gateway PCOP.
Workaround: The workaround for this condition is present in the code. The PCOP detects the mismatch of charging gateways on different processors and disconnects and reestablishes the TCP connection with the primary charging gateway.
•
A few sessions are dropped during a 3G-to-4G handoff.
This condition occurs when there are a large number of sessions (~10000) for which there is a 3G-to-4G handoff occurring with continuous data transfer. The dropped sessions are not seen with fewer number of sessions (~1000) or when continuous data transfer is not occurring during handoff.
Workaround: There is currently no known workaround.
•
The Cisco LTE PGW crashes while sending data traffic when a 4G-to-3G handoff is in progress.
This crash is seen only during a race condition when data traffic is being switched during a 4G-to-3G handoff. This condition is rare and exists in Release 1.3.7a and prior releases.
Workaround: There is currently no known workaround.
Cisco SAMI Caveats
The following Cisco SAMI caveats are open with Cisco IOS Release 12.4(24)T31f.
•
In a redundant implementation, one of the Cisco SAMIs remains in a STANDBY-COLD state indefinitely. When in a STANDBY-COLD state, sessions are not sychronized to the standby Cisco SAMI.
This condition is seen on occasions when both of the Cisco SAMIs that are a part of a redundant implementation are reloaded at very close times.
Workaround: Reload the Cisco SAMI that is in STANDBY-COLD state.
•
On rare occasions, a Cisco SAMI coming up as a standby (in a redundant implementation) reloads immediately after booting up because of IXP network processor health monitoring failures.
These IXP health monitoring failures are only seen on Cisco SAMIs coming up as the standby gateway in a redundant implementation.
Workaround: The Cisco SAMI reloads correctly on its own on the next attempt.
•
A Traffic and Control Plane processor (TCOP) triggers RF-induced reload of the standby.
This condition occurs due to an "Out of Window" data reception in the TCOP.
Workaround: There is currently no known workaround.
•
The Cisco SAMI reloads due to an LCP-to-PPC health monitoring failure.
This reload occurs only when the very rare condition of a flash operation happening at the same time a software issues causes a crash.
Workaround: There is currently no known workaround.
•
The Cisco SAMI reboots with following logs displaying at the supervisor console:
Card in module slot_num, is being power-cycled off (Module not responding to Keep Alive polling)After the reload, the dir core: in LCP does not contain any logs that indicate the reason for the reload.
It is not clear what conditions trigger this error since there were no specific activities going through the LCP at the time the reload occurred.
Workaround: There is currently no known workaround.
•
The Cisco SAMI reloads with the following error message:
%SAMI-2-SAMI_SYSLOG_CRIT: SAMI 1/0: %SAMI-2-443001: System experienced fatal failure.Service name:System Manager (core-server)(30380) has terminated on receiving signal 11,reloading systemAs part of the crash info, the core file "qnx_1_io-net_114693_core" is generated. "114693" is the process ID for network I/O support (io-net), and might vary from case to case.
Conditions that might cause this reload are not known.
Workaround: There is currently no known workaround.
•
Crashinfo and Debuginfo contains only one single line. This condition is not specific to any crash and can occur because of an RF-induced reload, software crash, health monitoring failure, etcetera.
Workaround: There is currently no known workaround.
Resolved Caveats
The following sections list the caveats that have been resolved with Cisco LTE PGW Release 1.3.7a, Cisco IOS Release 12.4(24)T31f.
Cisco LTE PGW Caveats
The following PGW caveats are resolved with Cisco LTE PGW Release 1.3.7a, Cisco IOS Release 12.4(24)T31f.
•
The show gprs gtp pdp tid command output might display a "Rcvd byte count" and "Sent byte count" that do not match the "MEF uplink bytes" and "MEF downlink bytes" respectively in the same output. This condition occurs when the P-CDR is closed due to size limit or service record limit or the S-CDR is closed due to size limit or traffic volume container limit.
CDRs generated subsequently for volume limit might contain less bytes than the configured limit. This condition occurs when the continuous volume trigger is not configured and CDRs are generated for an MS timezone change, followed by volume limit.
•
cgprsAccPtActivePdps is not incrementing for GTPv2 sessions. This condition is seen when GTPv2 sessions are created and an SNMP query to cgprsAccPtActivePdps does not return the active PDP count.
•
On the Cisco LTE PGW, a memory leak might be observed while PGW processes an Update Bearer Response (UBR) with reject cause from the SGW.
This memory leak is observed only if the UBR is rejected by the SGW. If the UBR is successful, the memory leak does not occur.
•
A memory leak on PGW occurs in the QoS policing structure and in the Packet Filter structure.
This memory leak occurs with the following:
a.
b.
Cisco SAMI Caveats
The following Cisco SAMI caveat is resolved with Cisco LTE PGW Release 1.3.7a, Cisco IOS Release 12.4(24)T31f.
•
After certain types of reloads (specified below), the Proxy Control Processor (PCOP) reports the reload reason as "Returned to Rommon due to PC Bus Error 0x0." The Debuginfo collected for the PCOP as part of the reload is truncated.
This condition occurs with the following:
a.
b.
c.
Miscellaneous Caveats
The following miscellaneous caveats are resolved with Cisco LTE PGW Release 1.3.7a, Cisco IOS Release 12.4(24)T31f.
•
Cisco IOS Software contains four vulnerabilities related to Cisco IOS Zone-Based Firewall features. These vulnerabilities are as follows:
–
–
–
–
Workarounds that mitigate these vulnerabilities are not available.
Cisco has released free software updates that address these vulnerabilities.
This advisory is available at the following link:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120328-zbfw
•
A vulnerability in the Multicast Source Discovery Protocol (MSDP) implementation of Cisco IOS Software and Cisco IOS XE Software could allow a remote, unauthenticated attacker to cause a reload of an affected device. Repeated attempts to exploit this vulnerability could result in a sustained denial of service (DoS) condition.
Cisco has released free software updates that address this vulnerability. Workarounds that mitigate this vulnerability are available. This advisory is available at the following link:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120328-msdp
•
The Secure Shell (SSH) server implementation in Cisco IOS Software and Cisco IOS XE Software contains a denial of service (DoS) vulnerability in the SSH version 2 (SSHv2) feature. An unauthenticated, remote attacker could exploit this vulnerability by attempting a reverse SSH login with a crafted username. Successful exploitation of this vulnerability could allow an attacker to create a DoS condition by causing the device to reload. Repeated exploits could create a sustained DoS condition.
The SSH server in Cisco IOS Software and Cisco IOS XE Software is an optional service, but its use is highly recommended as a security best practice for the management of Cisco IOS devices. Devices that are not configured to accept SSHv2 connections are not affected by this vulnerability.
Cisco has released free software updates that address this vulnerability. This advisory is available at the following link:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120328-ssh
•
A vulnerability exists in the Cisco IOS Software that may allow a remote application or device to exceed its authorization level when authentication, authorization, and accounting (AAA) authorization is used. This vulnerability requires that the HTTP or HTTPS server is enabled on the Cisco IOS device.
Products that are not running Cisco IOS Software are not vulnerable.
Cisco has released free software updates that address these vulnerabilities.
The HTTP server may be disabled as a workaround for the vulnerability described in this advisory.
This advisory is available at the following link:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120328-pai
•
The Cisco IOS Software Internet Key Exchange (IKE) feature contains a denial of service (DoS) vulnerability.
Cisco has released free software updates that address this vulnerability. This advisory is available at the following link:
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20120328-ike
Unreproducible Caveats
The following PGW caveats have not been reproduced with Cisco LTE PGW Release 1.3.7a, Cisco IOS Release 12.4(24)T31f.
•
The Cisco SAMI running the Cisco LTE PGW image displays a current balance delete credit that is more than the maximum credit in the show gprs gtp status command output.
The following actions result in this condition:
a.
b.
c.
d.
e.
f.
•
The Cisco SAMI running the Cisco LTE PGW image might end up with stuck sessions after multiple switchovers. This condition occurs when there is a lot of data traffic over 10,000 sessions and then the clear gprs gtp pdp-context all command is executed along with multiple switchovers.
•
After multiple redundancy switchovers, stuck GTPv1 PDPs are observed.
This condition occurs when the PGW is at full GTPv1 PDP capacity (800,000). After performing multiple switchovers (reloading the active PGW), some stuck sessions are observed on the PGW.
•
The Cisco SAMI running a Cisco LTE PGW image crashes during an active-to-standby transition when the active gateway is reloaded after the clear gprs gtp pdp-context all command has been issued.
The following actions result in this condition:
a.
b.
c.
At this point, upon a standby-to-active transition, the crash might occur. If it does not, repeating these steps eventually results in a crash.
•
During a standby to active state transition, the following message is seen:
%PLATFORM-3-UNFORESEEN: Free PDP already sent for indexThis message is seen only when the standby gateway transitions to active while PDPs in the currently active gateway are in deleting state.
Caveats - Cisco LTE PGW Release 1.3.7, Cisco IOS Release 12.4(24)T3f
This section lists the open, resolved and unreproducible caveats that pertain to Cisco LTE PGW Release 1.3.7, Cisco IOS Release 12.4(24)T3f.
Open Caveats
Note
The following sections document possible unexpected behavior and describe only severity 1 and 2 caveats and select severity 3 caveats.
Cisco LTE PGW Caveats
The following Cisco LTE PGW caveats are open in Cisco IOS Release 12.4(24)T3f.
•
During the creation of a session, if a failure response from the IXP occurs while the session is being deleted under a specific timing window (for example, the IXP might already have an entry), the PGW might reload.
This is a timing condition between the completion of accounting start and the deletion of a session under a specific timing window.
Workaround: There is currently no known workaround.
•
The Cisco SAMI running the Cisco LTE PGW image displays a current balance delete credit that is more than the maximum credit in the show gprs gtp status command output.
The following actions result in this condition:
a.
b.
c.
d.
e.
f.
Workaround: There is currently no known workaround.
•
The Cisco SAMI running the Cisco LTE PGW image might end up with stuck sessions after multiple switchovers. This condition occurs when there is a lot of data traffic over 10,000 sessions and then the clear gprs gtp pdp-context all command is executed along with multiple switchovers.
Workaround: There is currently no known workaround.
•
The Cisco LTE PGW/SGW might drop an update PDP context requests because of an International Mobile Subscriber Identity (IMSI) mandatory information element (IE) missing error. This condition occurs during a GTPv0-to-GTPv1 handoff or during a GTPv2-to-GTPv1 handoff if the IMSI is not present in the update PDP context request. The SGW considers this a mandatory IE instead of an optional ID, and drops the incoming request.
Workaround: There is currently no known workaround.
•
The Cisco SAMI running a Cisco LTE PGW image crashes during an active-to-standby transition when the active gateway is reloaded after the clear gprs gtp pdp-context all command has been issued.
The following actions result in this condition:
a.
b.
c.
At this point, upon a standby-to-active transition, the crash might occur. If it does not, repeating these steps eventually results in a crash.
Workaround: There is currently no known workaround.
•
The counters for the G-PDU bits in the Cisco Mobile Wireless Transport Manger (MWTM) display a negative value.
Workaround: There is currently no known workaround.
•
Not all GTPv1 PDPs are cleared on newly active PGW when the restart counter is changed and a failover occurs at the same time.
Workaround: There is currently no known workaround.
•
Incorrect values for APN counters display when a PDP is reassigned to a different Traffic and Control Plane processor (TCOP). This condition occurs only when a PDP is reassigned to a different TCOP.
Workaround: There is currently no known workaround.
•
The following syslog message might seen:
%IPC-3-SAMI_SM_FAIL_DUP_MSISDN: Unexpected condition: TCOP in IMSI-Sticky doesn't match with MSISDN-Sticky.This message might be seen with one of the following:
a.
b.
The message does not appear to impact any functionality.
Workaround: There is currently no known workaround.
•
RF-induced reloads are triggered by the Traffic and Control Plane processors (TCOPs). This condition occurs in an Active/Standby redundant implementation.
Workaround: There is currently no known workaround.
Cisco SAMI Caveats
The following Cisco SAMI caveats are open with Cisco IOS Release 12.4(24)T3f.
•
In a redundant implementation, one of the Cisco SAMIs remains in a STANDBY-COLD state indefinitely. When in a STANDBY-COLD state, sessions are not sychronized to the standby Cisco SAMI.
This condition is seen on occasions when both of the Cisco SAMIs that are a part of a redundant implementation are reloaded at very close times.
Workaround: Reload the Cisco SAMI that is in STANDBY-COLD state.
•
On rare occasions, a Cisco SAMI coming up as a standby (in a redundant implementation) reloads immediately after booting up because of IXP network processor health monitoring failures.
These IXP health monitoring failures are only seen on Cisco SAMIs coming up as the standby gateway in a redundant implementation.
Workaround: Reload the Cisco SAMI. The module usually reloads correctly on the next attempt.
•
The Cisco SAMI reloads because of a health monitoring failure and the following syslog message is generated:
%PLATFORM-4-DP_HM_WARN: Failed to receive response from IXP1 in 22 retries, systemwill reboot if it continues to fail receiving response in another 8 retries (i.e. inthe next 80 secs.) Check `sami health-monitoring' configuration and see `show samihealth-monitoring' for more infoThis condition occurs when the Cisco SAMI network processor (IXP) fails to respond to health monitor messages sent from a PowerPC (PPC).
Workaround: There is currently no known workaround.
Resolved Caveats
The following sections list the caveats that have been resolved with Cisco LTE PGW Release 1.3.7, Cisco IOS Release 12.4(24)T3f.
Cisco LTE PGW Caveats
This section lists the PGW caveats that are resolved with Cisco LTE PGW Release 1.3.7, Cisco IOS Release 12.4(24)T3f.
•
With the single IP architecture, when a local IP address pool contains just a few IP addresses (for example, less than 10), the block count on the Cisco SAMI Proxy Control Processor (PCOP) increments (viewable using the show ip local pool privileged EXEC command) even though there are some addresses available in the pool.
•
When an snmpwalk is run on a complete Management Information Base (MIB) Object Identifier (OID) tree against an SGW or PGW that has no bearers/PDPs, the CPU usage is approximately 20 percent. With 50,000 create and delete session requests, but no snmpwalk running, the CPU usage is approximately 20 percent. However, when an snmpwalk and the 50,000 create and delete session requests are combined, the CPU usage climbs to 99 percent.
The high CPU condition is seen when the 50,000 create and delete session requests and an snmpwalk of the entire MIB tree occur at the same time.
•
The SNMP-ENGINE process might leak memory on the PGW/SGW gateways when the path history table is polled.
•
GTP Version 1 (GTPv1) PDPs become stuck during standby-to-active switchover.
This condition occurs with the Cisco LTE SGW or Cisco LTE PGW when PDPs are being deleted because of a new recovery information element (IE) value in the active gateway, which indicates a path restart, while the standby gateway is coming up and starts receiving bulk synchronization for create PDPs from the active gateway.
The active gateway immediately reloads after the bulk synchronization when there are PDPs remaining on the restarting path of the active gateway.
•
A high CPU is seen on the PGW when the maximum CPU is taken by the SNMP engine single IP stats A process.
This condition is seen on the PGW when the PGW had 1600 GTP paths and the Cisco Mobile Wireless Transport Manager (MWTM) polls the following SNMP tables:
–
- cGtpPathTable
- cGtpPathStatisticsTable
–
- cGtpPathGtpv2StatisticsTable
- cGtpPathGtpv2ReqMsgTable
- cGtpPathGtpv2RspMsgTable
•
The Cisco Mobile Wireless Transport Manager (MWTM) has negative values for PDP activation statistics
This condition is seen when the MWTM polls the standby PGW for the following objects:
–
–
•
In a redundant implementation, the following traceback appears on the active gateway for a brief period of time during the bootup.
%IDMGR-3-INVALID_ID: bad id in id_delete (id: 0xD0D0D0C),This condition occurs only in a redundant implementation when the redundancy state of a GGSN is not yet "ACTIVE." Once the gateway state is "ACTIVE," the traceback stops displaying.
•
A high CPU is seen on the Cisco LTE gateway (PGW or SGW) with an SNMP GetBulk request on an object identifier (OID) polls the subscriber table.
•
The gateway crashes when displaying path history tables. The path history tables are not empty and entries change simultaneously when the show gprs gtp path history command is executed.
Cisco SAMI Caveats
The following Cisco SAMI caveats are resolved with Cisco LTE PGW Release 1.3.7, Cisco IOS Release 12.4(24)T3f.
•
A specific configuration sequence causes a configuration download/parse error on the SAMI.
The condition is logged as follows:
SAMI 1/3: Feb 18 09:27:43.779: %IPC-0-CFG_DOWNLOAD_ERROR: Configurationdownload/parse error: Failed to download config on one or more processors,traffic will get blocked -Process= "Init", ipl= 0, pid= 3If inter-device redundancy is configured, a peer SAMI might reload with the redundancy framework (RF)/Cisco IOS Hot Standby Routing Protocol (HSRP) state broken.
The following configuration sequence causes the configuration download/parse error:
a.
b.
c.
d.
After the reload, the SAMI receives the configuration download/parse error.
•
A configuration download error occurs with the following message:
%IPC-0-CFG_DOWNLOAD_ERROR: Configuration download/parse error: Failed to downloadconfig on one or more processors, traffic will get blocked -Process= "Init", ipl= 0,pid= 3This condition occurs when the erase bootflash command is issued on the PCOP.
•
When the Cisco SAMI IXP statistics counters increase to larger values, writing those values to print buffer causes the following traceback:
SAMI 2/3: 000049: Sep 17 22:08:58: %SAMI-4-WARNING: Unexpected condition: Badstring length, output truncated -Process= "Virtual Exec", ipl= 0, pid= 243, -Traceback= 0x4586BB38z 0x4586BC28z 0x4586F7B8z 0x448A9B0Cz 0x44888930z0x4585E9ACz 0x44888A98z 0x448A9B0Cz 0x448D06F0z 0x459906F8z0x45993DFCzATTSGW52#This traceback is visible when the show tech command or show sami ixp statistics command is executed. Additionally, this traceback causes no functional impact and is more likely to occur if the Cisco SAMI has been up for multiple days.
•
Cisco Mobile Wireless Transport Manager (MWTM) displays negative values for PDP activation statistics when the MWTM polls the standby node for the "cgprsAccPtTotRmtInitCreateBearers" and "cgprsAccPtSuccRmtInitCreateBearers" objects.
•
While debugging, it is observed on rare occasions that all of the lookup threads become stuck, resulting in the IXP not processing any packets. The Cisco SAMI IXP has more than 50 look threads. If a few threads fail, the system might not report the failure right away, but continue to work in degraded mode.
•
Scheduled jobs (cron table jobs) execute the write memory command on the Cisco SAMI Traffic and Control Plane processors (TCOPs). The cron job is a distributed command, which means it is propagated to the TCOPs.
The Cisco SAMI single IP architecture does not use TCOP configuration files in NVRAM. The TCOP configurations are driven by the PCOP, which retrieves the configuration file from the supervisor. Executing the write memory command in the TCOPs saves the configuration in the TCOP NVRAM. This is an unnecessary and redundant write to NVRAM.
With this fix, the write memory command is disabled at the TCOPs.
Caveats - Cisco LTE PGW Release 1.3.6, Cisco IOS Release 12.4(24)T3e
This section lists the open, resolved and unreproducible caveats that pertain to Cisco LTE PGW Release 1.3.6, Cisco IOS Release 12.4(24)T3e.
Open Caveats
Note
The following sections document possible unexpected behavior and describe only severity 1 and 2 caveats and select severity 3 caveats.
Cisco LTE PGW Caveats
The following Cisco LTE PGW caveats are open in Cisco IOS Release 12.4(24)T3e.
•
When an snmpwalk is run on a complete Management Information Base (MIB) Object Identifier (OID) tree against an SGW or PGW that has no bearers/PDPs, the CPU usage is approximately 20 percent. With 50,000 create and delete session requests, but no snmpwalk running, the CPU usage is approximately 20 percent. However, when an snmpwalk and the 50,000 create and delete session requests are combined, the CPU usage climbs to 99 percent.
The high CPU condition is seen when the 50,000 create and delete session requests and an snmpwalk of the entire MIB tree occur at the same time.
Workaround: There is currently no known work around.
•
The Cisco SAMI reloads because of a health monitoring failure and the following syslog message is generated:
%PLATFORM-4-DP_HM_WARN: Failed to receive response from IXP1 in 22 retries, system will reboot if it continues to fail receiving response in another 8 retries (i.e. in the next 80 secs.) Check `sami health-monitoring' configuration and see `show sami health-monitoring' for more infoThis condition occurs when the Cisco SAMI network processor (IXP) fails to respond to health monitor messages sent from a PowerPC (PPC).
Workaround: There is currently no known workaround.
•
GTP Version 1 (GTPv1) PDPs become stuck during standby-to-active switchover.
This condition occurs with the Cisco LTE SGW or Cisco LTE PGW when PDPs are being deleted because of a new recovery information element (IE) value in the active gateway, which indicates a path restart, while the standby gateway is coming up and starts receiving bulk synchronization for create PDPs from the active gateway.
The active gateway immediately reloads after the bulk synchronization when there are PDPs remaining on the restarting path of the active gateway.
Workaround: There is currently no known workaround.
•
A high CPU is seen on the PGW when the maximum CPU is taken by the SNMP engine single IP stats A process.
This condition is seen on the PGW when the PGW had 1600 GTP paths and the Cisco Mobile Wireless Transport Manager (MWTM) polls the following SNMP tables:
–
- cGtpPathTable
- cGtpPathStatisticsTable
–
- cGtpPathGtpv2StatisticsTable
- cGtpPathGtpv2ReqMsgTable
- cGtpPathGtpv2RspMsgTable
Workaround: Use the following configuration to block the SNMP object identifiers (OIDs) so that they are not available for SNMP polling:
–
–
–
–
–
–
–
–
•
Cisco Mobile Wireless Transport Manager (MWTM) displays negative values for PDP activation statistics when the MWTM polls the standby node for the "cgprsAccPtTotRmtInitCreateBearers" and "cgprsAccPtSuccRmtInitCreateBearers" objects.
Workaround: Configure MWTM to use the Hot Standby Router Protocol (HSRP) IP address to poll the gateways instead of the physical interface addresses of individual gateways.
•
The counters for the G-PDU bits in the Cisco Mobile Wireless Transport Manger (MWTM) display a negative value.
Workaround: There is currently no known workaround.
Cisco SAMI Caveats
There are no known Cisco SAMI caveats open with Cisco IOS Release 12.4(24)T3e.
Resolved Caveats
The following sections list the caveats that have been resolved with Cisco LTE PGW Release 1.3.6, Cisco IOS Release 12.4(24)T3e.
Cisco LTE PGW Caveats
This section lists the PGW caveats that are resolved with Cisco LTE PGW Release 1.3.6, Cisco IOS Release 12.4(24)T3e.
•
The Cisco LTE PGW crashes when handling a RADIUS Change of Authorization (CoA) message from the Cisco CSG2 under stress conditions with a slow Policy and Charging Rules Function (PCRF).
This issue occurs under the following conditions:
–
–
–
•
The QoS class identifier (QCI) and allocation retention priority (ARP) values in the SGW and PGW are out of sync.
This condition exists when a GTPv2 create request with a Policy and Charging Rules Function (PCRF) responding with a different set of QoS than the User Equipment requested QoS.
•
The PGW crashes during a GTPv0 create when a GTPv0 PDP exists with the same tunnel ID (TID) under a different access-point (APN).
This condition is seen only when there is an APN-related failure while creating a GTPv0 PDP. The list of such failures are as follows:
–
–
–
–
–
•
The following error messages might appear on the PGW:
SAMI 6/5: 000105: Jun 21 06:53:27: %GPRSFLTMG-4-CHARGING: GSN: , TID: 0000000000000000, APN: NULL, Reason: 0, unexpected CSG usage report cause -Traceback= 0x443D37E8z 0x4435C498z 0x4435C7FCz 0x4435D40Cz 0x44352010z 0x44352EC8z 0x4435327Cz 0x4598BB78z 0x4598F27CzThis condition occurs whenever a PGW-initiated QoS update request fails as is indicated by the appearance of the following syslog message.
SAMI 6/4: 000182: Jun 22 10:06:48: %GPRSFLTMG-4-GTPv1_PDP_UPDATE_FAIL: GSN: 135.211.131.2, TEID: 232189D, APN: testbroadbandvtccz3, Reason: 1, SGSN does not support GGSN initiated PDP QOS updateWhen charging is enabled and the PGW is generating P-CDRs, this condition will also occur as the result of the addition of service containers to the ListOfServiceData with a serviceChangeCondition value of "0".
•
Cisco CSG2 link flapping is seen because out of sequence messages from the CSG2 are received. The flap is observed when a PGW failover occurs and an out of user sequence service control usage (SCU) message is received.
The condition occurs in a Gx topology (PGW+CSG2+Policy and Charging Rules Function [PCRF]) when a PGW failover occurs, the Cisco CSG2 sends out of user sequence SCU message to the PGW, and the PGW does not acknowledge that it has received the SCU.
•
The Cisco PGW quota server interface sends a GTP reject cause code to the Cisco CSG2 for several conditions where the PGW decides to discard service usage, for example, with retransmitted usage when the received usage is outside the expected sequence window or the user is not found.
With this fix, the PGW sends the reject cause code for the usage only when the actual sanity of the service control message fails (for example, with parse error codes). Otherwise, the PGW sends an acknowledgement to the service control message because there is no defect with the message.
With this fix, a detailed keyword option has been added to the show ggsn csg statistics command (show ggsn csg statistics [detailed]), which enables you to display enhanced statistics for the service control message processing on the quota server interface.
•
A stale PDP is seen on the standby PGW when the bearer/PDP is sychronized to the standby while it is in a deleting state.
•
The number of service records buffered counter does not decrement.
This condition occurs when there is no call detail record (CDR) opened for the service record buffered.
•
When path table cGtpPathGtpv2ReqMsgTable or cGtpPathGtpv2RspMsgTable is polled frequently while PDP contexts are being created and deleted on the PGW, sometimes SNMP lexicographical ordering breaks and an Index with a much lesser value leading to an SNMP loop is received.
The issues occurs under the following conditions:
a.
b.
•
The PGW crashes when a 3G-to-4G handoff occurs when a 3G procedure that has been initiated by the PGW is pending, and is followed by a 4G session delete or failure.
•
A high CPU occurs during the creation of a GTPv0 PDP over an existing GTPv1 PDP.
The high CPU is seen only when an existing GTPv1 PDP is waiting for an update to be completed and a GTPv0 create request is initiated.
The fix for the particular symptom is in CSCtr31369. Additionally, the fix committed with CSCtr30916 resolves this condition by freeing the CPU by dropping the new create request.
•
High CPU occurs during the creation of GTPv0 PDPs over existing GTPv1 PDPs.
This condition is seen only when the existing GTPv1 PDP is waiting for an update to be completed and a GTPv0 create request is initiated.
•
Lawful interception fails to do provision a mediation device (MD) and an snmpset request returns a "No-Creation" error. Additionally, an snmpwalk returns nothing from the SNMP Mediation Table.
This condition occurs only when the incorrect ifIndex is used in snmpset.
•
The%GPRSFLTMG-6-GPRS_CHARGING_NO_CDR message displays on the newly active PGW after a switchover.
This message might be seen during a standby to active PGW switchover when there are active subscriber sessions with service-awareness enabled.
•
For unknown reasons, the Cisco LTE PGW displays "NO_CDR" syslog when a CDR closes.
This condition occurs on the active PGW.
•
A CPU usage spike of more than 90 percent occurs when polling cIpLocalPoolAllocTable objects.
This condition occurs when polling the cIpLocalPoolAllocTable or an snmp getbulk is executed against the ciscoIpLocalPoolMIB, which can internally poll cIpLocalPoolAllocTable objects.
•
Cisco LTE PGW crashes during a PDP cleanup.
This condition occurs when:
a.
b.
c.
Cisco SAMI Caveats
This section lists the Cisco SAMI caveats that are resolved with Cisco LTE PGW Release 1.3.6, Cisco IOS Release 12.4(24)T3e.
•
The ucdump -t command does not recognize VLAN and L2VD tables as valid arguments.
This condition only relates to the display of the VLAN and L2VD tables using the ucdump -t command from the IXP console. The tables are setup correctly and traffic is forwarded successfully based on these tables.
•
The Cisco SAMI IXP micro-engine threads used to configure data paths might take a lock on tables and not freeing it, thereby holding the lock indefinitely.
This fix catches these issues for debugging purposes. Use the ucdump -t LOCK command to dump debugging information when a lock is held infinitely.
•
Continuous IXP IPC failure error messages are seen from the Cisco SAMI:
%PLATFORM-3-SAMI_IPC_IXP_FAIL: IPC timed out for IXP<ixp no> for Msgcode <msg>, Num tries: <tries>This condition typically occurs when the Cisco SAMI IXP stops processing IPC messages from the Cisco SAMI processors.
•
The syslog messages "PLATFORM-3-SAMI_IPC_IXP_FAIL:" is observed when the Cisco SAMI IXP receives out of order configuration messages, for example, when the IXP receives a modify PDP request before a create PDP request or after a free PDP message.
•
The Cisco SAMI reloads with the following syslog error message
"%PLATFORM-1-DP_HM_FAIL: Failed to receive response from IXP<1/2>. Check `sami health-monitoring' configuration and see `show sami health-monitoring' for more info"The condition occurs when the network processor (IXP) fails to respond to Health Monitoring (HM) messages sent by the SAMI PowerPCs (PPCs).
The IXP maintains packets, including HM messages, in DRAM buffers. The pointers to these buffers (also known as the buffer handles) are maintained by q-arrays. Expected behavior is that the q-arrays provide valid buffer handles, however, when a Null (invalid) buffer handle is de-queued by q-array, the hardware assist, which maintains the q-array buffer becomes corrupted and the IXP reaches a state where it does not process incoming packets any longer.
Caveats - Cisco LTE PGW Release 1.3.5, Cisco IOS Release 12.4(24)T35c
This section lists the open, resolved and unreproducible caveats that pertain to Cisco LTE PGW Release 1.3.5, Cisco IOS Release 12.4(24)T35c.
Open Caveats
Note
The following sections document possible unexpected behavior and describe only severity 1 and 2 caveats and select severity 3 caveats.
Cisco LTE PGW Caveats
This section lists the PGW caveats that are open with Cisco LTE PGW Release 1.3.5, Cisco IOS Release 12.4(24)T35c.
•
The Cisco LTE PGW crashes when handling a RADIUS Change of Authorization (CoA) message from the Cisco CSG2 under stress conditions with a slow Policy and Charging Rules Function (PCRF).
This issue occurs under the following conditions:
–
–
–
Workaround: There is currently no known workaround.
•
In a redundant implementation, the standby PGW undergoes a self-induced reload when there is a lot of synchronization activity from the active PGW that was triggered by the creation of sessions due to create session requests and the deletion of sessions due to failure of either the bearer resource command (BRC) or the modify bearer command (MBC) procedures.
This condition occurs only when there are a high number of failures resulting from either BRC or MBC procedures.
Workaround: There is currently no known workaround.
Cisco SAMI Caveats
This section lists the SAMI caveats that are open with Cisco LTE PGW Release 1.3.5, Cisco IOS Release 12.4(24)T35c.
•
For dual stack sessions belonging to APNs with Mobile Express Forwarding (MEF) switching enabled, the "MEF uplink packets / links" field displays some non zero values immediately after the sessions come up.
This condition occurs when sessions belonging to an APN, which has dual stack configured (using the gtp bearer dual-addr access-point configuration command) and has MEF switching enabled. The show gprs gtp pdp-context tid command output displays some non zero values in the "MEF uplink packets / links" field.
Workaround: There is currently no known workaround.
Resolved Caveats
The following sections list the caveats that have been resolved with Cisco LTE PGW Release 1.3.5, Cisco IOS Release 12.4(24)T35c.
Cisco LTE PGW Caveats
This section lists the PGW caveats that are resolved with Cisco LTE PGW Release 1.3.5, Cisco IOS Release 12.4(24)T35c.
•
In a redundant implementation, the Cisco LTE PGW rejects a RADIUS Change of Authorization (CoA) because of an existing CoA outstanding error message on newly active PGW after switchover.
This condition is seen for existing sessions on the newly active PGW after a switchover with Cisco LTE PGW releases prior to Release 1.3.5.
•
The pre Release 8 Quality of Service (QoS) status counters are not incremented in the output of the show gprs qos status privileged EXEC command.
This condition occurs when a GTPv1 PDP context is created on a UMTS QoS class.
•
The Cisco LTE PGW does not delete PDP contexts after an idle PDP context timeout occurs.
This condition occurs when the session idle timeout is configured and a GTPv0 PDP is created and left idle. When the timeout occurs, the PDP is not deleted.
•
When the limit volume yyy command is configured under a charging profile, the limit volume yyy reset command does not work, and vice versa.
This condition occurs when the values for the two commands are not the same.
•
When a BSM Resource Controller (BRC) is sent to the Cisco LTE PGW to replace the existing uplink (UL) and downlink (DL) install filters, the PGW replaces the UL filter, but it adds the filter received from the Policy Control and Charging Rules Function (PCRF) on the DL instead of replacing it.
This condition occurs when a Policy and Charging Control (PCC) session is created using the default settings and a BRC is sent to the PGW to replace existing filters.
•
Spurious memory access is seen on the Cisco LTE PGW when a GTPv2 session is created over GTPv0 because incorrect data structure is being accessed.
•
In a redundant implementation, the standby gateway has some stale sessions but the active gateway has none. The standby sessions should be in a "deleting" state.
•
On the Cisco LTE PGW a traceback occurs with the following message:
%SYS-2-BADSHARE: Bad refcount in datagram_don while session deletion•
In a redundant implementation, a new standby gateway crashes during bulk sychronization.
This condition occurs when Quality of Service (QoS) profile on the Policy and Charging Rules Function (PCRF) is configured to initiate dedicated bearers.
•
The Cisco LTE PGW reloads.
This condition occurs after hours of 4G traffic running at high create/delete sessions per second rate (approximately 500 create/deletes per second) and a continuous fail/re-enable Policy and Charging Rules Function (PCRF).
•
The Cisco LTE PGW sends the incorrect SGSN address in the service container after an SGW handover.
This condition is seen when both the Cisco LTE SGW and a public land mobile network (PLMN) change occurs.
•
When a GTPv1 to GTPv2 handoff request is received for a GTPv1 PDP that is in the process of being deleted and waiting on the final SCU, the Cisco LTE PGW might crash.
This condition is seen under the following circumstances:
1.
2.
3.
•
In a redundant implementation, the active gateway does not synchronize Quality of Service (QoS) values that are received from the Policy and Charging Rules Function (PCRF) during negotiation to the standby gateway. This causes inconsistent redundant setups for QoS values and the standby will apply the default QoS values on the subscriber traffic after a switchover occurs.
This condition is seen on the standby gateway in a redundant implementation when the active gateway receives QoS values from PCRF during negotiation.
•
In a redundant implementation, the active gateway does not synchronize Maximum Bit Rate (MBR)/Guaranteed Bit Rate (GBR) uplink/downlink values negotiated by Policy and Charging Rules Function (PCRF) to the standby gateway. Therefore, the values are not reflected on the standby gateway.
This condition occurs on the standby gateway in a redundant implementation when the active gateway receives Quality of Service (QoS) values from PCRF.
•
When the default (empty) policy-profile is applied to an APN, the Cisco LTE PGW applies the Aggregate Maximum Bit Rate (AMBR) values to a GTPv1 session after a GTPv2 to GTPv1 handover occurs. Use the show gprs gtp pdp-context tid tid qos police privileged EXEC command to display the values applied to the session.
This condition occurs when policing is configure on an APN.
•
When a Tracking Area Identifier (TAI) change occurs from a User Location Information (ULI) type other than TAI or Routing Area Identifier (RAI), call detail records (CDRs) are closed with a public land mobile network (PLMN) ID change as the cause.
This condition occurs when the PGW receives a create session request with an ULI type other than TAI/RAI, and then receives a modify bearer request or delete session request with TAI/RAI.
•
After an enhanced quota server interface is unconfigured by using the ggsn quota-server server-name service-msg global configuration command, PDP contexts become stuck in a "deleting" state after issuing the clear gprs gtp pdp all privileged EXEC command.
This condition occurs when service-aware sessions exist, the enhanced quota server interface is unconfigured, and then the clear gprs gtp pdp context command is issued. Instead of being deleted, the service-aware PDP contexts become stuck in a deleting state.
•
In a redundant implementation, when the Cisco CSG2 path is down, stuck sessions are seen on the active PGW when the peer restarts and sends a new create request for an existing session.
This condition occurs only when the Cisco CSG2 path is down, there is an existing GTPv1 PDP context, and then the peer restarts and sends a new create request for the existing PDP.
•
GTPv1 PDP contexts remained stuck and are not deleted even after attempting to manually clear them when the path between the Cisco LTE PGW and Cisco CSG2 is flapping and Service Control Requests (SCRs) are being sent at a rate high enough to cause more than 12500 outstanding SCRs per Traffic and Control Plane processor (TCOP).
This condition occurs only when SCRs are timing out because the path between the PGW and CSG2 is flapping and a large number of pending SCRs exist in the system (more than 12500 SCRs per TCOP).
•
In a redundant implementation, PDP contexts are deleted after two switchovers occur.
This condition can be seen when a GTPv1 PDP is created, the active gateway reloads, a handoff from GTPv1 to GTPv2 occurs, and the active gateway reloads once again. The PDP context is not created on the standby gateway, but the PDP context exists on the active gateway.
•
In a redundant implementation, a traceback occurs on the active PGW during a switchover.
This condition occurs when a redundancy state changes when a GTPv2 PDP is in a half-created state.
•
The show gprs charging profile command displays an incorrect value for the Continue Option for Volume Limit trigger. The value displays as Enabled when it is Disabled, and vice versa.
The continuity trigger for duration should be enabled if continuity trigger for volume is disabled and the continuity trigger for duration should be disabled if continuity trigger for volume is enabled.
•
In a redundant implementation, when a standby to active switchover occurs when there are existing PDP contexts waiting on the final SCU to be received from the Cisco CSG2, the final usage might be lost.
This condition occurs when the newly active PGW does not wait on the SCU and deletes the PDP contexts as soon as the its redundancy state changes to active. This issue is seen only when PGW switchover occurs and there are PDPs contexts waiting for final SCU from the Cisco CSG2.
•
On the Cisco LTE PGW, the following syslog message might appear:
Syslog %GPRSFLTMG-3-GPRS_CHARGING_NO_CDR: No Open CDRThis condition occurs when the quota server interface on the PGW is overloaded, or in any other situation where "Out of Order Usage Messages" (SCUs) are received by the PGW.
The usage reporting reason is falsely interpreted on the PGW. If the usage report reason is interpreted as PDP closure, the existing CDR might be closed, and all subsequent usage for the PDP context might not be reported and the syslog message appears.
Cisco SAMI Caveats
This section lists the Cisco SAMI caveats that are resolved with Cisco LTE PGW Release 1.3.5, Cisco IOS Release 12.4(24)T35c.
•
When two Cisco SAMIs are configured as an active standby pairs, any unexpected reload of one of the processors in the standby SAMI can cause the active SAMI to reload because of an RF induced self-reload.
This condition occurs if the HSRP priority of the standby SAMI is greater than the priority of the active SAMI, either because of explicit configuration or based on the IP address of the active and standby SAMIs.
•
Upstream data packets are dropped in the Cisco SAMI IXP network processor path. Issuing the show gprs gtp pdp-context tid tid privileged EXEC command displays the number of Mobile Express Forwarding (MEF) dropped packets incrementing.
This condition occurs when the L2/MAC address to redirect address (Cisco CSG2) is not resolved.
Miscellaneous Caveats
This section lists a miscellaneous Cisco IOS software caveat that is resolved with Cisco LTE PGW Release 1.3.5, Cisco IOS Release 12.4(24)T35c.
•
A Cisco IOS device might experience an unexpected reload as a result of mtrace packet processing
Unreproducible Caveats
This section lists caveats that are unreproducible in Cisco LTE PGW Release 1.3.5, Cisco IOS Release 12.4(24)T35c.
•
After a system reload, both gateways in a redundant implementation might end up in an active or active-drain state. This condition is rarely seen, and only occurs when both gateways in a redundant implementation are reloaded at almost the same time. This condition is more likely to occur when the Stream Control Transmission Protocol (SCTP) connectivity for the redundant configuration is lost.
•
An SNMP getmany request triggered on ciscoGprsAccPtMIB from an SNMP manager on the gateway times out without receiving a response for a objects in ciscoGprsAccPtMIB.
This condition occurs when the SNMP getmany request is continuously triggered (in a loop) on the ciscoGprsAccPtMIB.
•
When Remote Console and Logging (RCAL) is enabled on the Cisco SAMI, the RCAL show proc cpu and the show proc memory commands cause the Traffic and Control Plane processor (TCOP) CPU to become stuck at 99% usage.
This CPU issue is observed after a few hours of experiencing the following conditions:
a.
b.
c.
d.
show proc cpu | include five seconds
show gprs gtp status | inc activated session
show gprs gtp status | inc activated sessions
show proc mem | include Processor
show proc mem | include I/O
Caveats - Cisco LTE PGW Release 1.3.4, Cisco IOS Release 12.4(24)T34d
This section contains open and resolved caveats that pertain to Cisco LTE PGW Release 1.3.4, Cisco IOS Release 12.4(24)T34d.
Open Caveats
Note
The following sections document possible unexpected behavior and describe only severity 1 and 2 caveats and select severity 3 caveats.
Cisco LTE PGW Caveats
There are no known PGW caveats open in Cisco LTE PGW Release 1.3.4, Cisco IOS Release 12.4(24)T34d.
Cisco SAMI Caveats
This section lists the SAMI caveats that are open with Cisco LTE PGW Release 1.3.4, Cisco IOS Release 12.4(24)T34d.
•
For dual stack sessions belonging to APNs with Mobile Express Forwarding (MEF) switching enabled, the "MEF uplink packets / links" field displays some non zero values immediately after the sessions come up.
This condition occurs when sessions belonging to an APN, which has dual stack configured (using the gtp bearer dual-addr access-point configuration command) and has MEF switching enabled. The show gprs gtp pdp-context tid command output displays some non zero values in the "MEF uplink packets / links" field.
Workaround: There is currently no known workaround.
Resolved Caveats
The following sections list the caveats that have been resolved with Cisco LTE PGW Release 1.3.4, Cisco IOS Release 12.4(24)T34d.
Cisco LTE PGW Caveats
This section lists the PGW caveats that are resolved with Cisco LTE PGW Release 1.3.4, Cisco IOS Release 12.4(24)T34d.
•
When Remote Console and Logging (RCAL) is enabled on the Cisco Service and Application Module for IP (SAMI), the following error messages displays when a create context request is received, or a GTPv2 to GTPv1 handoff occurs on the PGW with the Radio Access Technology Type (RAT) type "5" (HSPA EVOLUTION):
SAMI 1/4: Jun 8 04:47:42.859: %GTP-0-NORESOURCE: GSN: 0.0.0.0, TID: 00, APN: NULL, Reason: Invalid RAT value for recommended RAT IEThe RAT type is set to null.
•
The Cisco SAMI running the Cisco LTE PGW Release 1.3.4 image might not generate service records as part of the call detail record (CDR) contents.
This condition occurs when the PGW has a configuration under the APNs to generate local P-CDRs (no service aware command and charging record type pcdr command configuration), and there should be some PDP session establishments taking place with these APNs.
•
The active and standby gateways have a mismatch in the number of sessions after some create PDP context failures, or PDP contexts are deleted in the active gateway.
•
The Cisco LTE PGW might see constant high CPU usage (>90%) and could possibly not recover from that condition.
This condition might occur when a GTPv0 create request is received on an existing GTPv1 PDP while that GTPv1 PDP is waiting to be deleted.
When PDP contexts are being deleted at a high rate, some PDP contexts are in a delete pending queue waiting to be deleted. If a GTPv0 create request is received for one of these GTPv1 PDPs in the delete pending queue, the create request continuously gets enqueued for processing in a loop, and causes the high CPU on the PGW.
•
After a mediation device (MD) is attached to the Cisco LTE PGW, an "SNMP QFULL_ERR" error message is received if MD statistics are polled from the PGW.
This condition occurs when the ifIndex on the Proxy Control Processor (PCOP) and Traffic and Control Plane processors (TCOPs) becomes out of sync when the snmp-server ifindex persist command is configure and interfaces are added or removed at the PCOP.
When an MD attach occurs with the PCOP interface ifIndex, the MD entry is created at the PCOP. If the same ifIndex is not valid on the TCOPs, the MD creation fails at the TCOPs. Upon an MD statistics query, the PGW attempts to aggregate values per TCOP. Since the MD entry is not present at the TCOPs, they do not respond to the aggregation process, and the process times out after approximately 10 seconds. During this 10 second, a lot of SNMP packets are queued and queue overflow occurs, which results in a "SNMP QFULL_ERR" error.
•
The LTE SGW or LTE PGW might log "Active Charging Gateway NOT matching on Processors"
This condition occurs when the Cisco SAMI is running the Cisco LTE SGW Release 1.x or the Cisco LTE PGW Release 1.x images.
•
An "INVALID_ID: bad id in id_get (Out of IDs!) (id: 0x0)" syslog message is generated on the standby SGW/PGW. This syslog message is a generic one and does not always indicate the issue.
This condition occurs when more that 16384 paths are created (but do not necessarily exist simultaneously) and are synchronized to the standby gateway.
If on the standby gateway, the show gprs redundancy command output displays a count more than 16384 in the Path Setup messages field, this is probably the issue.
Cisco SAMI Caveats
There are no Cisco SAMI caveats newly resolved with Cisco LTE PGW Release 1.3.4, Cisco IOS Release 12.4(24)T34d.
Caveats - Cisco LTE PGW Release 1.3, Cisco IOS Release 12.4(24)T3c
This section contains open and resolved caveats that pertain to Cisco LTE PGW Release 1.3, Cisco IOS Release 12.4(24)T3c.
Open Caveats
Note
The following sections document possible unexpected behavior and describe only severity 1 and 2 caveats and select severity 3 caveats.
Cisco LTE PGW Caveats
There are no known PGW caveats open in Cisco LTE PGW Release 1.3, Cisco IOS Release 12.4(24)T3c.
Cisco SAMI Caveats
This section lists the SAMI caveats that are open with Cisco LTE SPW Release 1.3, Cisco IOS Release 12.4(24)T3c.
•
For dual stack sessions belonging to APNs with Mobile Express Forwarding (MEF) switching enabled, the "MEF uplink packets / links" field displays some non zero values immediately after the sessions come up.
This condition occurs when sessions belonging to an APN, which has dual stack configured (using the gtp bearer dual-addr access-point configuration command) and has MEF switching enabled. The show gprs gtp pdp-context tid command output displays some non zero values in the "MEF uplink packets / links" field.
Workaround: There is currently no known workaround.
Resolved Caveats
The following sections list the caveats that have been resolved with Cisco LTE PGW Release 1.3, Cisco IOS Release 12.4(24)T3c.
Cisco LTE PGW Caveats
This section lists the PGW caveats that are resolved with Cisco LTE PGW Release 1.3, Cisco IOS Release 12.4(24)T3c.
•
The Cisco LTE PGW crashes because of incorrect routing.
Because of an increased latency in setting up a Policy and Charging Control (PCC) session, the SGSN performs a GTP version fallback from GTPv1 to GTPv0. In this scenario, the PGW attempts to clean up the pending GTPv1 session and create a GTPv0 context. While cleaning up the GTPv1 session, the PGW crashes.
•
The Cisco GGSN/Cisco LTE PGW crashes when an snmpwalk is made over cGtpPathStatisticsTable. This condition occurs when paths are created and removed (PDPs are created and deleted, or charging gateways are configured and unconfigured) during the snmpwalk.
•
Rulebase IDs are not synchronized between the active and standby PGWs.
This condition occurs because the active PGWs sychronize the rulebase IDs only when the APNs are configured for service-aware charging. Therefore, rulebase IDs are not synchronized for APNs without the service-aware configuration.
•
The standby PGW crashes during a 4G session creation for an existing 3G session.
This condition occurs when there is an existing GTPv1 session and the PGW receives a GTPv2 session with the same International Mobile Subscriber Identity (IMSI) and attempts to sychronize the newly arrived GTPv2 session to the standby PGW.
•
The Cisco LTE SGW and Cisco LTE PGW ignore the User Location Information (ULI) information element (IE) when it is sent in a delete session request.
•
The standby PGW crashes during the create IPv6 default and dedicated bearer process.
This condition occurs when the rulebase IDs are sychronized from the active PGW to the standby PGW because of a null pointer access during the attribute decode.
•
An infinite loop causes the watchdog timer to reload the PGW.
This condition occurs while the PGW is constructing a GTPv1 update response packet for a PDP on a service aware APN.
•
Traceback for a GTPv1 PDP update with service aware charging enabled.
This condition occurs when service aware billing is configured and the PGW sends an update request to the SGSN and illegal memory access occurs.
•
An AAA access-request returns with an internal error, and on the Cisco GGSN or Cisco LTE PGW the following unconditional bug information is printed: "AAA had an unexpected return."
This condition occurs when an access-request is sent to the AAA server during periods of stress conditions on the client process and a failure to build the RADIUS packet occurs.
•
SNMP query for entPhysicalParentRelPos returns an incorrect value. This condition occurs because the SNMP query returns negative values because of an error in initialization of the data structure containing the processor details.
•
SNMP query for cpmCPUTotalPhysicalIndex returns an incorrect value. This condition occurs when the SNMP query is made for cpmCPUTotalPhysicalIndex 1, and an invalid value of 0 (zero) is returned instead of 2 because of an initialization error of the related table.
•
Crash occurs while executing a show command for a PDP that is in a deleting state.
This condition occurs when the user issues a show command for a PDP that is already being deleted and waits on the "more" prompt while the contents of the PDP are deleted, and then continues with the show command, which attempts to access the freed PDP contents.
•
PDP becomes stuck when the RADIUS connection with the Cisco CSG2 is lost during the deleting state.
This condition occurs when the reply from the Cisco CSG2 is delayed or lost.
Cisco SAMI Caveats
There are no Cisco SAMI caveats newly resolved with Cisco LTE PGW Release 1.2, Cisco IOS Release 12.4(24)T3c.
Caveats - Cisco LTE PGW Release 1.2, Cisco IOS Release 12.4(24)T3b
This section contains open and resolved caveats that pertain to Cisco LTE PGW Release 1.2, Cisco IOS Release 12.4(24)T3b.
Open Caveats
Note
The following sections document possible unexpected behavior and describe only severity 1 and 2 caveats and select severity 3 caveats.
Cisco LTE PGW Caveats
There are no known Cisco LTE PGW caveats open in Cisco LTE PGW Release 1.2, Cisco IOS Release 12.4(24)T3b.
Cisco SAMI Caveats
This section lists the SAMI caveat that is open with Cisco LTE SPW Release 1.2, Cisco IOS Release 12.4(24)T3b.
•
For dual stack sessions belonging to APNs with Mobile Express Forwarding (MEF) switching enabled, the "MEF uplink packets / links" field displays some non zero values immediately after the sessions come up.
This condition occurs when sessions belonging to an APN, which has dual stack configured (using the gtp bearer dual-addr access-point configuration command) and has MEF switching enabled. The show gprs gtp pdp-context tid command output displays some non zero values in the "MEF uplink packets / links" field.
Workaround: There is currently no known workaround.
Resolved Caveats
The following sections list the caveats that have been resolved with Cisco LTE PGW Release 1.2, Cisco IOS Release 12.4(24)T3b.
Cisco LTE PGW Caveats
This section lists the PGW caveats that are resolved with Cisco LTE PGW Release 1.2, Cisco IOS Release 12.4(24)T3b.
•
During a GTPv2 to GTPv1 handoff, the radio access technology (RAT) type from the GTPv2 session is copied into the GTPv1 session without verifying if the GTPv2 RAT type is valid for the GTPv1 session. Therefore, the interim accounting messages are sent with an invalid RAT type for the GTPv1 session.
This condition occurs when the RAT type is E-UTRAN and a handover from GTPv2 to GTPv1 occurs.
•
The following error message displays on the console and some IPv6 addresses are not released into the pool after a session deletion, however, the addresses are assigned in subsequent session creations.
IPC-3-SAMI_IPV6_POOL_FAIL: Unexpected condition: Malloc Failure for IPv6 Pool Mgmt ModuleThis condition occurs when the Cisco LTE PGW is configured with 500 APNs, all of which have different VRFs and accounting and charging enabled, and the PGW receives continuous session create, modify, and delete requests at 750 calls per second (cps).
•
A Traffic and Control Plane Processor (TCOP) spikes for a long time during an SNMP query with 192K static traffic, 192K create/delete requests, and 192K create at 1200 cps.
This condition occurs with the following sequence of events:
a.
b.
c.
d.
e.
Issue the show processor cpu command to display that the Proxy Control Processor (PCOP) stays at 98% for a long time.
•
Some sessions are not synchronized to the standby Cisco LTE PGW when Gx is enabled for dual stack sessions with the DHCP option.
When the PGW is configured with 500 APNs, all of which have different VRFs, Policy and Charging Control (PCC), accounting, charging, and DHCP proxy address allocation for IPv4 addresses, and redundancy configured, this condition occurs after approximately 38,000 sessions are created.
•
The Cisco LTE PGW reports that the Dynamic Feedback Protocol (DFP) high threshold has been reached and is congested due to low processor memory.
This condition occurs after a switchover with 800K GTPv1 Gx sessions with charging enabled (time trigger set at five minutes and the volume trigger 1 Mb).
•
When the Cisco LTE PGW dynamically assigns IPv6 prefixes to the UEs from a local pool or from a RADIUS pool name or RADIUS prefix in response to a IPv6 router solicitation from the UE, the PGW must send an IPv6 router advertisement with the UE's prefix information with the lower 64 bits of the IPv6 address in the prefix extension set to zero. The PGW incorrectly sends the non zero UE's interface ID in the lower 64 bits.
This condition occurs with an IPv6 solicitation from a UE using an IPv6 address.
•
Lawful Intercept does not intercept GTPv0 Intercept Related Information (IRI) and Content of Communication (CC) packets. A show wire issued on the Cisco LTE PGW displays that no packets are being intercepted for the generic stream. The mediation device (MD) also does not show any HI2_IRI or HI3_CC packets intercepted when context requests and date were sent to a specific International Mobile Subscriber Identity (IMSI) session.
•
When IPv6 primary and secondary DNS addresses are configured under an APN in the Active PGW, and an IPv6 session is created, the primary and secondary DNS addresses for that session are not synchronized to Standby PGW.
This condition occurs when IPv6 DNS addresses are configured in the APN in the Active PGW, and an IPv6 session is synchronized to the Standby PGW.
•
The charging characteristics received in a GTPv2 message do no get synchronized from the Active to the Standby Cisco LTE PGW.
This condition applies to all GTPv2 PDP contexts.
•
In compliance with the Release 8.2.0 Create Session Request, the first byte of the mobile station ISDN (MSISDN) number is removed.
•
Downstream traffic fails at the Cisco LTE PGW for IPv6 PDP contexts.
This issue is seen in all Cisco LTE PGW and Cisco GGSN releases when the IPv6 address is dynamically allocated, and the UE modifies the interface ID.
•
The Cisco LTE PGW clears the Autonomous bit while installing the MS prefix in the Interface Data Block (IDB), which causes the IPv6 ND RA message to be sent with the Autonomous bit not set.
This condition occurs only when the UE requests dynamic IPv6 prefix allocation from the Cisco LTE PGW.
Cisco SAMI Caveats
This section lists the Cisco SAMI caveats that are resolved with Cisco LTE PGW Release 1.2, Cisco IOS Release 12.4(24)T3b.
•
The UE is unable to acquire an IPv6 address.
This condition occurs when the Cisco LTE PGW dynamically assigns IPv6 prefixes from the UEs from a local pool or from a RADIUS pool name or RADIUS prefix. The IPv6 router solicitation from the UE is lost and therefore, the UE is unable to acquire its IPv6 address.
•
Data packets to or from the MSs are dropped for APNs with VRFs when IXP switching is enabled (the default).
This condition occurs when the Cisco LTE PGW is configured with 500 APNs, all of which are configured with a different VRF and the redirect all ip command. Traffic for MSs from some of the 500 APNs is dropped at the IXP. The show mef access-point command displays an all zeros MAC address, for example, Redirect MAC Address: 0000.0000.0000.
•
When the PGW is switching traffic at a high data rate (approximately 1.2 mpps) for more than 48 hours, the following error message along with a traceback is seen,
%PLATFORM-3-SAMI_INTRHOG: DMA interrupt is running for (xxx)usecs, more than (xxx)usecs.This condition occurs when the PGW is connected to a Cisco CSG2 and there are 380K enabled sessions distributed over 500 APNs, all of which are configured with a different VRF, and the Gx and PCC features enabled, and the PGW is switching upstream and downstream data to these sessions at a high rate (1.2 million packets per second [mpps]) for more than 48 hours.
Caveats - Cisco LTE PGW Release 1.1, Cisco IOS Release 12.4(24)T3a1
This section contains open and resolved caveats that pertain to Cisco LTE PGW Release 1.1, Cisco IOS Release 12.4(24)T3a1.
Open Caveats
Note
The following sections document possible unexpected behavior and describe only severity 1 and 2 caveats and select severity 3 caveats.
Cisco LTE PGW
The following PGW caveats are open in Cisco LTE PGW Release 1.1, Cisco IOS Release 12.4(24)T3a1.
•
The following error message displays on the console and some IPv6 addresses are not released into the pool after a session deletion, however, the addresses are assigned in subsequent session creations.
IPC-3-SAMI_IPV6_POOL_FAIL: Unexpected condition: Malloc Failure for IPv6 Pool Mgmt ModuleThis condition occurs when the Cisco LTE PGW is configured with 500 APNs, all of which have different VRFs and accounting and charging enabled, and the PGW receives continuous session create, modify, and delete requests at 750 cps.
Workaround: There is currently no known workaround, however, the addresses that were not deleted in the pool are not leaked since they are assigned to new users on subsequent session creations.
•
Some sessions are not synchronized to the standby PGW, when Gx is enabled for dual stack sessions with the DHCP option.
When the PGW is configured with 500 APNs, all of which have VRF, Policy and Charging Control (PCC), accounting, charging, and DHCP proxy address allocation for IPv4 addresses, and redundancy configured, this condition occurs after approximately 38,000 sessions are created.
Workaround: There is currently no known workaround.
Cisco SAMI
This section lists the SAMI caveats that are open with Cisco LTE PGW Release 1.1, Cisco IOS Release 12.4(24)T3a1.
•
For dual stack sessions belonging to APNs with MEF switching enabled, "MEF uplink packets / links" field displays some non zero values immediately after the session comes up.
This condition occurs when sessions belonging to an APN, which has dual stack configured (using the gtp bearer dual-addr access-point configuration command) and has MEF switching enabled (using the redirect all ip access-point command). The show gprs gtp pdp-context tid command output displays some non zero values in the "MEF uplink packets / links" field.
Workaround: There is currently no known workaround.
•
Data packets to or from the mobiles are dropped for APNs with VRF when IXP switching is enabled (the default).
This condition occurs when the PGW is configured with 500 APNs, all of which are configured with a different VRF and the redirect all ip command. Traffic for mobiles from some of the 500 APNs is dropped at the IXP. The show mef access-point command displays an all zeros MAC address, for example, Redirect MAC Address: 0000.0000.0000.
Workaround: Before any sessions are open for mobiles under an APN, issuing the ping command to the redirect addresses configured under the affected APNs triggers an Address Resolution Protocol (ARP) request that resolve the issue. Alternately, if there are a huge number of APNs with redirect addresses configured, saving the configuration and reloading the PGW resolves the issue.
•
When the PGW is switching traffic at a high data rate (approximately 1.2 million packets per seconds [mpps]) for more than 48 hours, the following error message along with a traceback is seen,
%PLATFORM-3-SAMI_INTRHOG: DMA interrupt is running for (xxx)usecs, more than (xxx)usecs.This condition occurs when the PGW is connected to a Cisco CSG2 and there are 380K enabled sessions distributed over 500 APNs, all of which are configured with a different VRF, and the Gx and PCC features enabled, and the PGW is switching upstream and downstream data to these sessions at a high rate (1.2 mpps) for more than 48 hours.
Workaround: There is currently no known workaround.
Resolved Caveats
The following sections list caveats that have been resolved with Cisco LTE PGW Release 1.1, Cisco IOS Release 12.4(24)T3a1. Only severity 1 and 2 caveats and select severity 3 caveats are listed.
Cisco LTE PGW
The following PGW caveats are resolved in Cisco LTE PGW Release 1.1, Cisco IOS Release 12.4(24)T3a1.
•
A fatal error occurs on the active PGW after the virtual-template interface is modified and sessions are cleared using the clear gprs gtp pdp-context command.
•
A traceback is seen on the Cisco LTE PGW. This condition occurs with downstream traffic greater than 1500 over IPv6 PDPs.
•
The show sami sm imsi output fails to display existing PDP sessions. Additionally, after some time, the gprs gtp pdp tid command output also displays nothing.
This condition occurs with IPv6 create requests with different restart counters.
•
Tracebacks are observed with GTP Version 0 (GTPv0) PDPs on IPv6 transport handoffs to GTPv1 on IPv4 transport, and again with handoffs to GTPv0 on IPv4 transport.
This condition occurs only when the handoff is between different IPv6/IPv4 transport.
Cisco SAMI
There are no SAMI caveats resolved with Cisco LTE PGW Release 1.1, Cisco IOS Release 12.4(24)T3a1.
Caveats - Cisco LTE PGW Release 1.0, Cisco IOS Release 12.4(24)T3a
This section contains the following types of caveats that pertain to Cisco LTE PGW Release 1.0, Cisco IOS Release 12.4(24)T3a.
Open Caveats—Cisco LTE PGW
This section documents possible unexpected behavior by Cisco LTE PGW Release 1.0, Cisco IOS Release 12.4(24)T3a and describes only severity 1 and 2 caveats and select severity 3 caveats.
•
Some sessions are deleted on the new standby PGW during the bulk synchronization after a switchover occurs.
This condition occurs with IPv6 transport, and IPv6 neighbor discovery for the next hop fails for approximately three minutes after the reload.
Workaround: Configure a static neighbor-to-IPv6 address mapping for the nexthop address for all GTP paths (for example ipv6 1:1:1:1::1 GigabitEthernet0/0.100 0022.3344.5566).
•
A fatal error occurs on the active PGW after the virtual-template interface is modified and sessions are cleared using the clear gprs gtp pdp-context command.
Workaround: There is currently no known workaround.
•
A traceback is seen on the Cisco LTE PGW. This condition occurs with downstream traffic greater than 1500 over IPv6 PDPs.
Workaround: There is currently no known workaround.
•
The show sami sm imsi output fails to display existing PDP sessions. Additionally, after some time, the gprs gtp pdp tid command output also displays nothing.
This condition occurs with IPv6 create requests with different restart counters.
Workaround: There is currently no known workaround.
•
Tracebacks are observed with GTP Version 0 (GTPv0) PDPs on IPv6 transport handoffs to GTPv1 on IPv4 transport, and again with handoffs to GTPv0 on IPv4 transport.
This condition occurs only when the handoff is between different IPv6/IPv4 transport.
Workaround: There is currently no known workaround.
Open Caveats—Cisco SAMI
This section lists the SAMI caveats that are open with Cisco LTE PGW Release 1.0, Cisco IOS Release 12.4(24)T3a.
•
The Cisco LTE gateway allows out of sequence traffic. This condition occurs when sending upstream traffic with the sequence number set to FFFF only with Mobile Express Forwarding (MEF). With Cisco Express Forwarding (CEF), the packets are dropped as designed.
Workaround: Use CEF instead of MEF.
Related Documentation
Except for feature modules, documentation is available as printed manuals or electronic documents. Feature modules are available online on Cisco.com.
Use these release notes with these documents:
•
Release-Specific Documents
The following documents are specific to Cisco IOS Release 12.4 and are located at Cisco.com:
•
Documentation > Cisco IOS Software > Cisco IOS Software Releases 12.4 Mainline > Release Notes
•
Documentation > Cisco IOS Software > Cisco IOS Software Releases 12.4 T > Release Notes
Note
•
Documentation > Cisco IOS Software > Cisco IOS Software Releases 12.4 Mainline
Platform-Specific Documents
These documents are available for the Cisco 7600 series router platform on Cisco.com and the Documentation CD-ROM:
•
•
–
–
–
•
The Cisco IOS software documentation set consists of the Cisco IOS configuration guides, Cisco IOS command references, and several other supporting documents that are shipped with your order in electronic form on the Documentation CD-ROM, unless you specifically ordered the printed versions.
Documentation Modules
Each module in the Cisco IOS documentation set consists of two books: a configuration guide and a corresponding command reference guide. Chapters in a configuration guide describe protocols, configuration tasks, Cisco IOS Software functionality, and contain comprehensive configuration examples. Chapters in a command reference guide list command syntax information. Use each configuration guide with its corresponding command reference. On Cisco.com at:
Documentation > Cisco IOS Software > Cisco IOS Software Releases 12.4 Mainline > Command References
Documentation > Cisco IOS Software > Cisco IOS Software Releases 12.4 Mainline > Configuration Guides
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 Cisco LTE PGW Configuration Guide and the Cisco LTE PGW Command Reference publications.
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R)
Copyright © 2012, Cisco Systems, Inc.
All rights reserved.
Feedback