Table Of Contents
Release Notes for Cisco Voice Switch Service Module (VXSM) Release 5.3
Table of Contents
About Release 5.3.00
New Features in Release 5.3.00
Firmware Images
Upgrading from an Earlier VXSM Release
Interrupted Procedure Recovery
Feature Clarifications
Call Rate Performance Support
MIB for RTCPXR statistics collection
Online Diagnostic feature as applied to VXSM.
DSP Resources under Mixed Codec Conditions
Configuring Switching and Trunking Applications
VXSM Management Information Base
Service Module Support By Platform
Compatibility
Caveats for VXSM Release 5.3.00
Open Caveats in Release 5.3.00
Resolved Caveats in Release 5.3.00
Removed Caveats in Release 5.3.00
Related Documentation
Obtaining Documentation
Cisco.com
Documentation DVD
Ordering Documentation
Documentation Feedback
Cisco Product Security Overview
Reporting Security Problems in Cisco Products
Obtaining Technical Assistance
Cisco Technical Support Website
Submitting a Service Request
Definitions of Service Request Severity
Obtaining Additional Publications and Information
Release Notes for Cisco Voice Switch Service Module (VXSM) Release 5.3
These release notes are part number OL-10285-01 Rev. A0, May 5, 2006.
The Voice Switch Service Module (VXSM) product is supported by the MGX 8880 Media Gateway and the MGX 8850 Multiservice Switch. Refer to their respective release notes for platform and version level support guidelines.
The VXSM software release notes are supported by the Cisco Voice Switch Services (VXSM) Configuration Guide, Release 5.3 and the Cisco Voice Switch Services (VXSM) Command Reference, Release 5.3, both of which are available on cisco.com.
Table of Contents
About Release 5.3.00
The VXSM Release 5.3.00 follows VXSM Release 5.2.10.201
New Features in Release 5.3.00
Release 5.3.00 is a significant release with several major new software features over Release 5.2.10.201. This release has no new VXSM hardware features. These new software features are:
Voice Quality Monitoring
The VXSM Voice Quality Monitoring (VQM) feature provides the ability to monitor, collect, and report a set of voice quality metrics to the remote Media Gateway. Together, the values of the collected metrics represent a measure of the quality of voice calls transmitted across the network. Service providers can use these metrics to observe and diagnose quality problems and to provide a measure for Service Level Agreements between the provider and its customers.
Virtual Gateways
For H.248 switched applications, a VXSM card has the capability of being partitioned into a number of Virtual Media Gateways (VMGs) where each VMG is a logical entity residing within a physical VXSM card. This feature can be used in applications in which a single Media Gateway Controller (MGC) does not have the capacity to control one VXSM gateway. By partitioning the VXSM card into several VMGs, the control of VXSM's physical and ephemeral terminations can be distributed among several Media Gateway Controllers.
SS7 - Signaling Gateway
A VXSM Release 5.3 card in an MGX 8880 and functioning as a media gateway can also be configured to provide the functions of a signaling gateway between SS7 and IP networks. By this means, communication can be established between entities, such as Signaling End Points, on a SS7 network and Application Servers, such as a Media Gateway Controller, on an IP network.
VXSM supports one instance of a Signaling Gateway that can operate concurrently with one or several instances of Media Gateways.
Additional Backhauling Protocols
For applications in which the signaling lines or channels are connected directly to VXSM, VXSM can be configured to relay the signaling messages to the Media Gateway Controller (MGC) for call control processing. This relay function, known as Backhauling, consists of extracting the level 3 signaling message from the level 2 transport protocol, encapsulating it into the IP protocol stack, and relaying it onto the MGC.
In order to meet the requirements of various Service Provider networks, VXSM Release 5.3 now supports a number of additional TDM side and IP side protocol stacks for this purpose. VXSM supported backhaul protocols are shown in the following table.
TDM Network Side
|
IP Network Side
|
ISDN D-channel (Q.931, Q.921)
|
UDP, RUDP
|
ISDN D-channel (Q.931, Q.921)
|
SCTP, IUA
|
SCTP = Streaming Control Transmission Protocol
RUDP = Reliable UDP
IUA = ISDN Q921-User Adaptation
AXSM Configurable Alarm Integration Parameter
For VXSM applications in which the interface to the packet network is an AXSM card (for example, AAL2 Trunking), the configure line (cnfln) command on the AXSM card now has a parameter to configure the Alarm Integration Time.
This parameter, intgTime, is basically a Loss of Signal alarm integration timer. The timer has a range from 100 ms to 2500 ms in increments of 100 ms. Under a line alarm condition, the Loss of Signal is checked for duration against the value of the intgTime parameter. If Loss of Signal exists for the intgTime value or more, the line is declared as Los of signal. The port will go down and hence e-ais is generated. The default value for intgTime is 2500 milliseconds (2.5 sec).
The syntax for the AXSM cnfln command is now:
For a SONET line:
cnfln -sonet <bay.line> -slt <LineType> -clk <clockSource> -intgTime <alarm integration time>
For a T3 line:
cnfln -ds3 <bay.line> -len <LineLength> -clk <clockSource> -lt <LineType> -oof <OOFCriteria>
-cb <AIScBitsCheck> -rfeac <RcvFEACValidation> -intgTime <alarm integration time>
For an E3 line:
cnfln -ds3 <bay.line> -len <LineLength> -clk <clockSource> -txtrace <TraceString>
-intgTime <alarm integration time>
In each case, the intgTime parameter is an integer in the range of 100 to 2500 ms, in increments of 100.
The configured value can be displayed using the dspln command, for example:
Unknown.1.AXSM.a > dspln -sonet 1.1
Admin Status : Up Alarm Status : Clear
Loopback : NoLoop APS enabled : Disable
Frame Scrambling : Enable Number of ports : 0
Xmt Clock source : localTiming Number of partitions: 0
Line Type : sonetStm1 Number of SPVC : 0
Medium Type(SONET/SDH) : SDH Number of SPVP : 0
Medium Time Elapsed : 81902 Number of SVC : 0
Medium Valid Intervals : 91 AlarmIntgTime (msec): 1000
The intgTime value is stored in the RAM and DB. Hence on reset of the AXSM card the configured value will be retained. Also, modified value will be updated on to the standby card. Hence on switchredcd the new active AXSM card will have modified value.
Extended Bearer Trace Capability
The number of bearer trace probes has been increased (see following table)
VXSM Probes, Release 5.2
|
VXSM Probes, Release 5.3
|
1 = PCM Input from TDM network
2 = PCM Output to the TDM network.
5 = Output from echo canceller (Ecan/Sout)
6 = Voice Playout Unit - Jitter buffer
7 = T.38 information at the Decoder - level 1
|
1 = PCM Input from TDM network
2 = PCM Output to the TDM network.
3 = Input from the packet network
4 = Output to the packet network
5 = Output from echo canceller (Ecan/Sout)
6 = Voice Playout Unit - Jitter buffer events
7 = T.38 information at the Decoder - level 1
8 = T.38 information at the Decoder - level 2
9 = DIM Message Trace to and from DSP
10 = Voice Playout Unit - segments
|
H.248 Congestion and Overload
VXSM supports the H.248.10 Congestion Control Package, and the H.248.11, Overload Control Package.
The H.248.10 MG Congestion Control Package is used to exchange congestion information between the MG and the MGC. VXSM reports congestion events to the MGC if congestion control has been enabled and MG detects a congestion event.
The H.248.11 MG Overload Control feature protects VXSM from processing overload that prevents the timely execution of H.248.1 transactions. MG Overload happens when the utilization of resources crosses a threshold and MG is close to being unable to respond to MGC transactions in a sufficiently timely manner to avoid the calling customer abandoning the call in setup.
T.38 Fax with H.248
VXSM 5.3 supports Call Agent (CA) controlled T.38 Fax Relay with H248 call signaling protocol. This is in addition to the previously supported Gateway controlled T.38 Fax Relay feature. CA controlled T.38 relay is based on packages defined in H.248.2
Support for new H.248 packages
The following new H.248 packages are now supported:
GRI, DS, BCG, Detailed Termination Information, H.248.30, H.248.2 and H.248.11
Codec Negotiation:
VXSM now supports codec negotiation in H.248. Codec Negotiation allows two GWs to agree on a single codec to use for the new call that is being setup. The codec selected depends on the capabilities of each of the gateways and the order of priority of each codec on that specific GW, as well as the resources available on the GW when the call is being setup.
New Codecs Support
VXSM now supports the G.723.1, dual rate speech codec standard from ITU-T for compresssing toll quality speech. VXSM supports G.723 H, G.723 AH, G.723 L and G.723 AL which specify different rate of the codec with or without silence suppression. G.723.1 is supported for both H.248 and MGCP protocols but not in AAL2 trunking. VXSM support a maximum of 3024 G.723.1 calls on an OC3 card, and 1152 such calls on a 48E1/T1 card due to the complexity of this codec requiring increased DSP resources.
Enhancements to VBD support in H.248
VXSM now supports low speed modems (V.21, V.23,Bell MOdem, Bell 202 and V.8Bis) and TTY in H.248 mode. VXSM also supports V.32Ext Modems. VXSM has added support detecting tones on the IP side for 2100 Hz, 2100 PR and Bell Modem tones.
Extended Statistics Commands
VXSM 5.3 has a number of new statistics commands for the displaying and clearing of several statistics counters. These new statistics provide information on number of connected media streams per codec, number of H.248 messages, bearer PVC utilization, call durations and number of calls, response time per each command category, and number of fax modem calls on the system.
Firmware Images
For each VXSM card type (OC-3, T1/E1, or T3), two firmware images are available, namely, Non-CALEA and CALEA. At order time, the user must specify whether a Non-CALEA or CALEA image is required.
The Non-CALEA image supports three Media Gateway Call Control (MGC) protocols, namely, H.248, MGCP, and TGCP. However, the image supports only one protocol at a time. The user must choose between the H.248, MGCP, and TGCP versions when the image is first loaded from the PXM using the setrev command.
The CALEA image supports TGCP and MGCP only. The protocol must be explicitly selected when the image is loaded from the PXM using the setrev command.
Upgrading from an Earlier VXSM Release
VXSM can be gracefully upgraded (configuration is preserved) from any VXSM Release 5.2.x.x so long as the original and the upgraded images are of the same version (for example Non-CALEA, TGCP to Non-CALEA, TGCP). When loading or upgrading a boot or runtime image to a VXSM card, users must observe the following caution.
Warning 
Many of the commands involved in loading or upgrading boot and runtime images can take several minutes to execute completely. If the user resets or otherwise disturbs the VXSM card during a loading or upgrading process, the card can easily be damaged even to the extent that it must be returned to the factory for repair.
In particular:
Do not reset VXSM or PXM cards manually or through commands such as resetcd or resetsys
Do not save all MGX configurations with commands such as saveallcnfs.
Do not toggle primary/secondary cards through commands such as switchredcd, delred
Do not change the name of software image before or during the upgrade
Do not change any configuration of active primary card during the upgrade
THE REAPPEARANCE OF THE COMMAND PROMPT AFTER A COMMAND IS ENTERED DOES NOT INDICATE THAT THE IMAGE LOAD OR UPGRADE HAS BEEN COMPLETED.
After the execution of the burnboot, clrsmcnf, loadrev, or setrev commands, the user must execute either a dspcds or dsprev command periodically to verify that the state of the VXSM card being loaded or upgraded is either Active, Standby, or Failed.
ONLY WHEN THE CARD IS DISPLAYED TO BE IN ONE OF THESE STATES IS IT SAFE TO GO TO THE NEXT STEP.
If the upgrade procedure is interrupted for reasons outside the control of the user (for example, a power outage), see "Interrupted Procedure Recovery" below for instructions.
Interrupted Procedure Recovery
In the event that a VXSM software upgrade procedure is interrupted (for example, power outage), and both Primary and Secondary are stuck in 'Failed-U' state, perform the following procedure
Step 1 Execute the abortrev command:
abortrev <PrimarySlot> <NewImageRevision>
Step 2 If the primary VXSM becomes "Failed/Active" (out of Failed-U/Active"), then execute the resetcd command
resetcd <PrimarySlot> (
Step 3 If the secondary VXSM becomes "Failed/Active" (out of Failed-U/Active"), then execute the resetcd command:
resetcd <SecondarySlot>
Step 4 Both primary and secondary VXSM cards should now have their original SW image and original DB
Feature Clarifications
Call Rate Performance Support
VXSM OC3 card supports the following call rates:
•In MGCP, the maximum CPS supported is 60 (without signaling). If signaling (M3UA/IUA/RUDP) is configured, then the maximum supported CPS is 35.
•In H.248, the maximum CPS supported is 65 (without signaling). If signaling (M3UA/IUA) is configured, then the maximum supported CPS is 35.
MIB for RTCPXR statistics collection
The current design of VXSM Release 5.3 cRtcpXrProfileTable in the CISCO-RTCPXR-EXT-MIB contains both VBD and CODEC threshold settings for RTCPXR statistics collection. To accommodate new CODEC support in future releases, this design will be changed to separate CODEC threshold settings into a new MIB table in the next VXSM release.
For this reason, the CISCO-RTCPXR-EXT-MIB file is not being posted to CCO for Release 5.3. The traps related to the objects defined in CISCO-RTCPXR-EXT-MIB are in the Release 5.3 and these traps will be supported without any change in the next VXSM release.
If any Network Management System would like to implement the trap manager receiving these traps in Release 5.3, the MIB can be provided by the VXSM team upon request.
Online Diagnostic feature as applied to VXSM.
The online diagnostics feature as implemented on the PXM45 card is supported on VXSM. When enabled, using the PXM45 cnfdiag command, this feature performs non-intrusive diagnostic tests that use four of the VXSM's DSP codecs.
If the user executes the VXSM dspdspcodecpools command, the resulting display shows the four codecs being used (for diagnostics) and subtracts them from the remaining available codecs (see example below).
ns1_knodar.3.VXSM.a > dspdspcodecpools
=====================================================================
=====================================================================
Codec pool Current utilized Current available
capacity (#DSP chans) capacity (#DSP chans)
========== ===================== =====================
G711 family/HDLC 179 7885
G729/G726/T.38 family 0 3919
The online diagnostics feature does not reduce the maximum number of 8064 codecs available for calls on the VXSM card. If the number of call requests on the VXSM is sufficiently high, the online diagnostic feature is disabled automatically and the four codecs are made available for active calls.
DSP Resources under Mixed Codec Conditions
When the same codec is used to setup calls on the gateway the available DSP resources will be fully utilized. However when different codecs are used to setup calls the amount of utilizable DSP resources may be limited in certain cases due to fragmentation.
Fragmentation is said to have occurred when the available capacities on two different DSP resources have enough available capacity to support a call of a particular codec type but cannot support that codec type individually.
Consider two DSP resources whose available capacity is 1 unit each making the total available capacity 2 units. However a codec that requires 2 units cannot be supported in the system because the available capacities have been fragmented across the individual DSP resources.
The DSP allocation algorithm on VXSM does make an attempt to smooth the effects of fragmentation but towards the end, fragmentation could happen as the future pattern of calls cannot be predicted beforehand.
Configuring Switching and Trunking Applications
The simultaneous operation of mixed applications (Switched VoIP applications and Non-switched Trunking applications) is now supported on the same VXSM card.
VXSM Management Information Base
The VXSM Management Information Base (MIB) Version 5.3 is available by request through your Cisco VXSM product marketing representative.
Alternatively, users with CCO accounts can access the MIB and VXSM software on-line at:
http://www.cisco.com/public/sw-center/sw-wan.shtml
The procedure is:
Step 1 Log on to http://www.cisco.com/public/sw-center/sw-wan.shtml
Step 2 Locate the VXSM platform (either VXSM 8880 or VXSM 8850) and click the down arrow to expand the "Select Release Level" drop down menu.
Step 3 Select the desired MIB release level (for example, Release 5300) to display a list of downloadable files.
Step 4 Click on the desired file (for example, mgx8850-fw-5300.tar).
Step 5 Read the license agreement and, if approved, click Accept.
Step 6 In the Software Download dialog box, click on Download: filename (where filename is the name of the file selected for download). This step starts the download procedure.
Step 7 Follow the normal file download procedure for your computer.
Step 8 When the file has been downloaded, untar or unzip the downloaded file. The MIB file is included in the downloaded file and is listed as a tar file (for example mgx8850rel5300mib.tar).
Step 9 Untar the MIB file to display its contents.
Service Module Support By Platform
Service Module
|
MGX8880
|
MGX8850
|
PXM45/C
|
PXM1
|
PXM45/A
|
PXM45/B
|
PXM45/C
|
PXM1E
|
MGX-RPM-XF-512
|
Yes
|
|
|
Yes
|
Yes
|
|
VISM-PR
|
Yes
|
Yes
|
|
Yes
|
Yes
|
Yes
|
AXSM-1-2488/B
|
Yes
|
|
|
Yes
|
Yes
|
|
AXSM-16-155/B
|
Yes
|
|
|
Yes
|
Yes
|
|
AXSM-4-622/B
|
Yes
|
|
|
Yes
|
Yes
|
|
AXSM-16-T3/E3/B
|
Yes
|
|
|
Yes
|
Yes
|
|
AXSM-32-T1E1-E
|
Yes
|
|
|
Yes
|
Yes
|
|
MGX-VXSM-155
|
Yes
|
|
|
Yes
|
Yes
|
|
MGX-VXSM-T1E1
|
Yes
|
|
|
Yes
|
Yes
|
|
MGX-VXSM-T3
|
Yes
|
|
|
Yes
|
Yes
|
|
MPSM-T3E3-155
|
|
|
|
Yes
|
Yes
|
Yes
|
RCON-1TO5-8850
|
Yes
|
|
|
|
|
|
Compatibility
Note VXSM Release 5.3.00 is supported only with PXM-45.
VXSM software interoperability with the MGX 8880 Media Gateway or the Cisco MGX 8850 (PXM45) Multiservice Switch platform software is listed in Table 1.
Table 1 VXSM Software Interoperability
Product
|
Latest Firmware
|
Min. Firmware
|
PXM45
|
5.3.00
|
5.3.00
|
MGX-RPM-XF-512
|
12.4(6)T1
|
12.4(6)T1
|
CWM
|
15.1.50P1
|
15.1.50P1
|
CTM
|
7.0
|
7.0
|
VISM-PR
|
3.3.25
|
3.3.25
|
AXSM-1-2488/B
|
5.3.00
|
5.3.00
|
AXSM-16-155/B
|
5.3.00
|
5.3.00
|
AXSM-4-622/B
|
5.3.00
|
5.3.00
|
AXSM-16-T3/E3/B
|
5.3.00
|
5.3.00
|
AXSM-32-T1E1-E
|
5.3.00
|
5.3.00
|
AXSM-XG OC3
|
5.3.00
|
5.3.00
|
MPSM-T3E3-155
|
5.3.00
|
5.3.00
|
BTS
|
4.5
|
4.5
|
PGW
|
9.5.2
|
9.5.2
|
Cisco 2600 Series Routers
|
c2600-ipvoice-mz.123-9.13.T
|
c2600-ipvoice-mz.123-9.13.T
|
Cisco 2600 for use as an
IP Transfer Point
|
c2600-itp-mz.122-21.SW bin
|
c2600-itp-mz.122-21.SW bin
|
Cisco 3700 Series Routers
|
c3725-ipvoice-mz,123-9.13.T
|
c3725-ipvoice-mz,123-9.13.T
|
Cisco ATA 188
|
3.2.0 for SIP/MGCP/H323
|
3.2.0 for SIP/MGCP/H323
|
Linksys PAP2 Phone Adapter
|
Version 2.0.6 (LS)
|
Version 2.0.6 (LS)
|
Linksys RT31 Router
|
Version 1.27.01
|
Version 1.27.01
|
Sipura 2100 ATA
|
Version 3.2.3
|
Version 3.2.3
|
Table 2 describes the software images available for Release 5.3.00 for VXSM.
Table 2 Software Images for Release 5.3.00 for VXSM
Board Pair
|
Latest Boot Code Version
|
Minimum Boot Code Version
|
Firmware
|
MGX-VXSM-155, CALEA
|
vxsm_005.003.000.200_bt.fw
|
vxsm_005.003.000.200_bt.fw
|
vxsm_005.053.000.200.fw
|
MGX-VXSM-155, Non-CALEA
|
vxsm_005.003.000.200_bt.fw
|
vxsm_005.003.000.200_bt.fw
|
vxsm_005.003.000.200.fw
|
MGX-VXSM-T1E1, CALEA
|
vxsm_005.003.000.200_bt.fw
|
vxsm_005.003.000.200_bt.fw
|
vxsm_005.053.000.200.fw
|
MGX-VXSM-T1E1, Non-CALEA
|
vxsm_005.003.000.200_bt.fw
|
vxsm_005.003.000.200_bt.fw
|
vxsm_005.003.000.200.fw
|
MGX-VXSM-T3, CALEA
|
vxsm_005.003.000.200_bt.fw
|
vxsm_005.003.000.200_bt.fw
|
vxsm_005.053.000.200.fw
|
MGX-VXSM-T3, Non-CALEA
|
vxsm_005.003.000.200_bt.fw
|
vxsm_005.003.000.200_bt.fw
|
vxsm_005.003.000.200.fw
|
Caveats for VXSM Release 5.3.00
This section describes software caveats for Release 5.3.00
Open Caveats in Release 5.3.00
Table 3 describes the open caveats in VXSM Release 5.3.00
Table 3 Open Software Caveats for VXSM Release 5.3.00
DDTS Issue
|
Description
|
CSCek39941
|
Headline: irmProxy exception error after s/o
Symptom: After multiple manual "quick" switchovers, the redundant STANDBY card may encounter an irmProxy exception and the card will reset 3 times
before settling into FAILED state. A "quick" switchover is defined as the case where a manual switchover is issued immediately after the redundant card comes up in STANDBY state (i.e., within 10 sec after the redundant STBY card comes up).
Conditions: This exception will likely occur if a quick manual switchover is issued as soon as the redundant STANDBY card comes up.
Workaround: Customer must wait at least 2-3 minutes after the redundant STANDBY card comes up before attempting to switch over the cards again. This will minimize the chances of this exception from occurring in the system. However, if this error does occur, the only way to recover is to reset both ACTIVE and STANDBY cards.
|
CSCek40564
|
Headline: IUA:VXSM OC3 reset w/SCTPRxTask running away on CPU
Symptom: Cisco VXSM VoIP gateway may get reset due to SctpRxTask running away.
Conditions: VXSM configured for IUA with multihoming (having two IP address configured on AS - addl2as CLI) on VXSM side may see this problem.
Workaround: Remove multihoming on VXSM side. (in addl2as CLI, just configure one IP address).
|
CSCek40488
|
Headline: Performing switchredcd with G723 codec causes card failure
Symptom: VXSM card goes into Failed State or switches over if redundancy is configured.
Conditions: The card must be running calls with G.723 codec at close to 30 cps and a switchover must have taken place.
Workaround: Do not use G.723.
|
CSCek41065
|
Headline: Stdby card fails if switchover attempted immediately after bulk sync.
Symptoms: Swictchover immediately after the standby card comes as standby puts the newly Active card in failed state.
Conditions: Bulk sync with calls on a large number of endpoints happens just before the switchover
Workaround: After the card goes standby wait for 1 minute and then perform the switchover
|
CSCek36473
|
Headline: delxgcpendptcons * doesn't delete activeCcbs if ft,mt events requested
Symptoms: MGC requested events should not cleared when issuing user commands to delete specific connections. But issuing "delxgcpendptcons *" , if issued twice removes the requested events.
Conditions: Happens only when issuing "delxgcpendptcons *" twice consecutively.
Workaround: Use "cnfgwoos 2" and then "cnfgwis" to delete connections and events if absolutely needed. Otherwise issue the CLI "delxgcpendptcons *" only once.
|
CSCek38508
|
Headline: VXSM sends back partial RCD to MGC, in cases it should not
Symptom:
(i) When toolkit sends response to Add/Modify command, it doesn't include o=,s= and t= lines.
(ii) NSE/NTE payload information is received in remote desc in add/modify command, while sending the response these parameters are not included.
Conditions: Issue (i) can happen with any profile while issue (ii) will happen with only CISCO_TGW profile
Workaround: None.
|
CSCek39101
|
Headline: Failed to re-add vifterms on second g/w link
Symptom: cnfvifterm may fail, after 2 switchover and add / delete VGWs and their associated vifterms.
Conditions: This problem happens only with the following sequence of commands.
1. Configure 3 virtual gateways (VGW) and a set of DS1 associated with each VGW.
For example, 1.1.1.1.1 with VGW 1, 1.1.1.2.1 with VGW 2, and 1.1.1.3.1 with
VGW 3.
2. Add 1:1 redundancy
3. Issue 'cnfh248is' to bring all VGWs in service.
4. Issue 'cnfh248oos' to bring VGW 2 out of service. Delete the 2nd VGW and remove its vifterms in 1.1.1.2.1.
5. Issue a switchover
6. Now add a new VGW with ID 12 and cnfvifterm to add 1.1.1.2.1 to the new VGW. Bring up some calls on association ID 12.
7. Do a switchover.
8. Delete calls on VGW 12. Remove vifterm on 1.1.1.2.1 and delete VGW 12.
9. Delete VGW 1 and 3 and remove their associated vifterms.
10. Delete redundancy
11. Add VGW 1 with vifterm 1.1.1.1.1
12. Add VGW 2 with vifterm 1.1.1.2.1, and the command 'cnfvifterm' failed with "Failed to add SCN termination!"
Workaround: None
|
CSCek39109
|
Headline: ds1Callback failure when re-adding vifterms
Symptom: The standby card may go into failed state after adding and deleting VMGs and their associated vifterms many times.
Conditions: This problem may happen after executing the following sequence of commands.
1) Add 4 VMGs and allocate a set of vifterms with each VMG, and put all gateways in service.
2) Start call-rate setup on each VMG.
3) cnfh248oos to put VMG 2 out of service forcefully.
4) cnfh248oos to put VMG 1 out of service forcefully.
5) Stop call-rate on VMG 1 & 2.
6) cnfh248is to put VMG 1 in service. Start call-rate setup. cnfh248is to put VMG 2 in service. Start call-rate setup.
7) Issue cnfvifterm to add 61 vifs in VMG1 starting from 1.3.3.2.1.
8) Issue cnfvifterm to delete 65 vifs in VMG2 starting from 1.1.1.3.1.
9) cnfh248oos to put VMG 2 out of service. Stop call-rate.
10)Issue cnfvifterm to delete 65 vifs in VMG2 starting from 1.1.1.3.1.
11)Issue cnfvifterm to add 2 vifs in VMG2 starting from 1.1.1.3.1.
12)cnfh248is to put VMG 2 in service. Start call-rate setup.
13)Issue cnfvifterm again to add the same 2 vifterms in VMG 2 starting from 1.1.1.3.1.
14)Issue cnfvifterm to delete 65 vifs starting from 1.1.1.3.1.
15)Issue cnfvifterm to delete vif 1.1.2.4.1 in VMG 1.
16)Issue cnfvifterm to delete vif 1.1.2.6.2 in VMG 2.
17)Issue cnfvifterm to delete vif 1.1.2.4.1.
18)Issue cnfvifterm to delete vif 1.1.2.6.2.
19)cnfh248oos to put VMG 2 out of service.
20)cnfh248is to put VMG 2 in service.
21)Issue cnfvifterm to delete 65 vifs starting from 1.1.2.6.2.
22)Issue cnfvifterm to add 61 vifs starting from 1.3.3.2.1.
23)Issue cnfvifterm to delete 61 vifs starting from 1.3.3.2.1.
24)cnfh248oos to put VMG 1 out of service.
25)Delete H248 association 2.
26)Issue cnfvifterm to delete vif 1.3.3.2.1.
27)Issue cnfvifterm to delete 61 vifs starting from 1.3.3.6.1.
28)Delete h248 association 1.
29)Add H248 association 1.
30)Issue cnfvifterm to add 61 vifs starting from 1.3.3.2.1.
Workaround: None.
|
CSCek39688
|
Headline: Call rejections (H.248.11) is not reflected in CLI dpsh248cnt
Symptom: The counter of Failed ADD command for CLI dsph248cnt -cmd does not include the rejected ADDs due to resource congestion.
Conditions: The CLI never shows the rejected ADD commands.
Workaround: The rejected ADD commands can be checked with CLI dspcdropcnt(s). Currently the two CLIs can be used to check the failed ADDs in different area, described as below:
a) The CLI dspcdropcnts shows the counts of call rejection due to resource congestion, and it is in system-wise, not per virtual gateway (per association).
b) The CLI dsph248cnt -cmd <assoc_id> is for the failed commands in H.248 application with a specified association (per virtual gateway). It is for the command processing failure due to any reason (e.g., 433 error) other than the resource congestion.
|
CSCek39648
|
Headline: GW T38 fails after switchover when handle mode for v21Tone is none
Symptom: On active card, call is setup with L:fxr/gw option to use Gateway mode for T38. And after switchover, when fax is started, call doesn't switch to T38 mode on detecting V21Fax tone
Conditions: This happens only if HandleMode for V21FaxTone is set to none in eventmapping CLI.
Workaround: For GW controlled T38 option, VXSM uses NSEs to indicate to the other end of the call to switch to T38, keep the HandleMode for V21Tone to nse in eventmapping CLI.
|
CSCen99415
|
Headline: cnfcon fails to increase PCR value less than 10
Symptom: Increasing PCR or SCR by less than 10 causes CACing failure.
Conditions: One scenario of this problem was created in AAL2 trunking where CIDs are added to connections. One test case where PCR was reduced from 201 to 199 by cnfcon command and then addcid was failing which is expected. Then the PCR is increased from 199 to 201 CPS and then addcid command is executed and then it still fails even though the BW requirements for that CID type was only 201. Basically, increasing PCR or SCR by less than 10 causes CACing issue.
Workaround: When PCR or SCR needs to be increased then use a value greater than 10.
Further Problem Description: This problem is a side effect of fixing CSCek11823 bug where PUs are less than 100 and PCR/SCRs are odd values. To calculate effective BW, PU is multiplied by PCR for CBR connections and by SCR for VBR connections. During this multiplication, rounding down occurs on the PNNI side and some code has been added to account for this round down. So basically, when PCR or SCR values are increased by less than 10 then this value is not updated to CRML in order to handle this error case. For detailed explanation of this problem refer to CSCek11823 bug.
Now, this problem will be fixed when PU value is 100 but for other values, the delta of 10 will still be there to handle the other error condition. But note that, this condition is only for boundary cases where the last CID needs to be added to the connection. Most of the applications have more than 24 CIDs in a connection so most likely this problem will not exist but the workaround can be when PCR or SCR needs to be increased then use a value greater than 10 when PU is not 100.
|
CSCen99446
|
Headline: Utilized BW for G.729A for 210 profile is incorrect
Symptom: Utilized Bandwidth is not as per expected cell rate for G.729a with custom profile 210.
Conditions: It happens when the following conditions are met -
1. Configure VXSM for AAL2.
2. Add 10 cids with G729a as voice codec for Custom profile 210.
Workaround: None.
|
CSCek40276
|
Headline: V34 modem call, Term. side downspeeds when inact. timer set to 0
Symptom: When inactivity timer in vbdprofile is set to 0, silence won't be detected and call should remain in upspeed mode once fax/modem passtrhough is attempted. But one end of the call downspeeds.
Condition: Inactivity timer is set to 0.
Workaround: None
|
CSCek40353
|
Headline: dsprscutil average out-of-range [min, max]
Symptom: Some of the average resource util output for CLI dsprscutil(s) are out of range.
Conditions: Whenever the CLI is issued
Workaround: None.
|
CSCek40477
|
Headline: Internal gateway err while re-adding a TDM termination to a context
Symptom: After add and delete of a TDM term with ECAN ON re-add of a TDM term with ECAN ON into the context returns "Internal gateway error"
Conditions: One other TDM termination exists in the context with ECAN off.
Workaround: Re-add the TDM with ECAN OFF and then send a Modify command to change the ECAN to ON instead of directly adding with ECAN ON.
|
CSCek27498
|
Headline: After switchover, VXSM returns ERR for ASPAC for 2nd ASP.
Symptom: On Cisco VXSM card, if a switch over the AS may remain in down state.
Conditions: If there are two ASPs configured in the AS, and if the switch over occurs; and if call agent does not send ASP UP and ASP ACTIVE message on the previously ACTIVE ASP, the AS on VXSM will not become ACTIVE.
Workaround: Have ASP that was ACTIVE before the switch over send the ASP UP and ASP ACTIVE messages again.
|
CSCek32056
|
Headline: dspqu XNQ stats do not clear when clear statistics option is used
Symptom: Stats do not clear after clear option issued
Conditions: XNQ stats 12
dspqu 1.1.2.1.1 1 -stats 12 1
Workaround: None
Further problem description: Currently there is a fix checked which will block
dspqu stat reset for RTCPXR and XNQ
|
CSCek33012
|
Headline: VQM RFC3611 Dup pkts(1 in 100) cause incorrect loss rate 99.6%
Symptom: RTCPXR Loss rate metric in the output of dspquerydspstats CLI shows 99.6% and VXSM sends Network Packet Loss Rate in H.248.30 package as 255, even when the loss in the network is not 99.6%.
Conditions: This happens only when there are duplicate packets received by VXSM and the # of duplicate packets received exceeds the # of packets lost.
Workaround: None.
|
CSCek40818
|
Headline: Call forward callflow crashes the standby card
Symptoms: Call forwarding callflow with TDM termination ECAN off crashes the standby card
Conditons:: Redundancy is configured when call forwarding is performed with at least 1 TDM termination with ECAN off.
Workaround: Setup all the TDM terminations involved in the call forwarding flow with ECAN ON
|
CSCek39878
|
Headline: The co1 tone doesn't stop and is being played on after the timeout
Symptom: CO1 tone doesn't stop after 3S timeout.
Conditions: CO1 tone is implemented as OO (On-OFF) event on VXSM. Therefore the default timeout (3S) is not supported. Due to the limitation of DSP, CO1 tone can't be changed to TO (TIMEOUT) event in the current release.
Workaround: None
|
CSCek40361
|
Symptom: Ecan not disabled on hs modem upspeed on tdm hairpin call
Symptom: Ecan remains enabled on a TDM hairpin call with a High speed modem that has "automode" T.38 is enabled in the event mapping table
Conditions: T.38 is enabled in the event mapping table. A tdm hairpin call is placed
Workaround: Remove T.38 fax from the Eventmapping table. Faxes will go through in the pass through mode.
|
CSCek40572
|
Headline: Fax upspeed fails after modifying H248 call to a new codec
Symptom: When fax is attempted second time on the same voice call, call doesn't switch to Data mode.
Conditions: Voice codec is changed (sending Modify commands to both the ends) before the second fax attempt.
Workaround: None
|
CSCeh56654
|
Headline: AAL2MP:VSIC-2-VSIMAJORERR on VXSM-RED after PXM45 reset
Symptom: VSI error log on the system
Conditions: This error is for releasing TCB buffers and it happens when PXM card gets reset in the shelf without having redundancy for PXM card.
Workaround: The error is harmless but needs to be identified
|
CSCeh91387
|
Headline: T.38 calls fail in mixed voice/fax setup with G711 as voice codec
Symptom: Some T.38 fax attempts fail when original voice codec has been used is G.711.
Conditions: This problem happens under the following two conditions,
1) When the VXSM card is almost fully loaded with calls (say, approx. less than 252 DSP channels are left)
2) Voice codec for the T.38 calls is a low-complexity one - G.711(A/U)
Workaround:
1) Use high complexity codec (G.729/G.726 family) as voice codec for those T.38 calls - to stop any call failure or
2) Do not load the card fully with calls (leave approx. 300-400 channels - depends on the call setup/teardown pattern too) to reduce the probability of failure (to 0 or close to 0).
|
CSCeh92932
|
Headline: V.34 Modem Upspeed Fails with voice pp 30 and higher
Symptom: V.34 modem calls with fixed mode negotiation train up at a compromised speed. of 28800/28800 instead of 33600/33600.
Conditions: Original voice call must have been set up with packetization period (pp) of 30 ms or above.
Workaround: While setting up voice calls, use a lower packetization period (<30 ms)
|
CSCei25313
|
Headline: R1.5MR->R2.0 in-service upgrade: max_cps == 20cps
Symptom: During an in-service graceful upgrade, the standby VXSM will go into Failed State.
Conditions: VXSM card supports in-service graceful upgrade. If upgrade is performed from a previous release (5.0 or 5.1) to (5.2) the call load on the system must not exceed 20 cps. If the call load is higher than 20 cps during upgrade, this particular problem will be observed.
Workaround: Make sure that the call load on the system is at a maximum of 20 cps when upgrade is being performed. It is recommended that upgrade is performed on the system when the traffic load is at its minimum.
|
CSCej23510
|
Headline: SRT2.0: Err logs received and long duration calls not successful
Symptom: Following error message are received for long run CAS calls for cable DSP image and some CAS calls fail.
1) ssiSemGive failed in CIL:
SSI_SEMID 0x1001c is not owned by giving task. It is owned by task 0xffffffff.
2) CIL SLHeaderChunk memory full
3) SCIL Request Node Chunk memory is full
Condition: This problem happens under heavy call load, running OI/BLV calls together with E911 and SS7 calls. The situation is intermittent.
Workaround: None
|
CSCin98779
|
Headline: Utilized Cell rate for G726-32,pkt:30ms differs from expected value.
Symptom: Utilized cell rate for G726-32, pp 30msec (only for this combination) takes 1 cps more than the expected value (The expected value is what is obtained from
the integer math column of the VXSM CAC bandwidth calculator)
Condition: This will happen for every call made in H.248/xGCP protocols. No pre-conditions are required.
Workaround: Use the "BW aggregate" row value in the VXSM CAC bandwidth calculator for all bandwidth calculations
|
CSCek24508
|
Headline: Standby card goes into Failed State due to IPC Failure.
Symptom: The standby card resets randomly in a trunking configuration.
Condition: The logs indicate that the standby card is reset because IPC communication is lost to the card. It is not clear under which condition this problem is encountered, except that the problem happens in trunking configuration.
Workaround: None.
|
CSCej40538
|
Headline: Ping Num Packets stops on lost packets
Symptoms: Ping stops before expected number of packets sent.
Conditions: Ping with num_packets used
Workaround: No workaround
|
CSCej41224
|
Headline: Bearer ping not capable of delivering Num_Packets 0 and 65535 (max)
Symptoms: Ping ends before complete and no statistics are reported
Conditions: ping forever or ping greater than 600
Workaround:
1) The first workaround is to do something on the session like maybe press enter. The idle timeout mechanism will reset if there's any activity from the user side. So if after 10 seconds of no activity, the user presses the enter key, it will reset the time. Thus we can witness the end of the ping command if we reset the idle timer.
2) The second workaround is to disable the idle timeout mechanism. This is done on the PXM by calling the shellConn command "cliTimeout 0". This completely disables the idle timeout mechanism.
3) Use less than 600 pings
Further problem description:
The defect in this case is the idle timeout mechanism. If it detects that a telnet session has been idle for a configurable amount of time it will close that session. Unfortunately the maximum configurable idle timeout is longer than the maximum ping duration. So if both are configured to their maximum settings, the idle timeout mechanism will trigger and kick off the user before the ping ends.
Reason for 3:
The reason that we don't want to reduce the maximum ping duration and remove the infinite ping option is because the mechanism measures the idle time. If the user is not idle during that time period then the ping will run to completion because the session hasn't been disconnected.
|
CSCej70827
|
Headline: CPU goes up, RUDP session flaps when many (>4K) DLCXs rcvd
Symptom: On Cisco VXSM card, RUDP session (used for PRI backhauling) may flap - causing the LAPD channels to go down, and calls to fail.
Conditions: If MGC under any circumstances, sends a flood of DLCXs to delete all connections, CPU Utilization on VXSM will go up, causing the RUDP session to flap.
Workaround: Prevent the flood of DLCXs being sent from MGC to VXSM.
|
CSCek21089
|
Headline: Many VSIC-5-VSICGENERR messages logged by tVsiSlave task on vxsm-155
Symptom: VSI error messages being logged into log file for VXSM. VSICORE: VsiErr:Passthrough Rsp Processing failed, 0xa004,348,0,0,2,2,5,0,0,0,0,0
Conditions: Topology discovery messages will be sent by PXM to each VSI slave to query links information.VXSM does not recognize this protocol and thus generates an error.
Workaround: There is no workaround to suppress the message.This message is not harmful.It is just an indication that VXSM VSI slave is ignoring the protocol ID for Topology Discovery feature in PXM.
|
CSCek33825
|
Headline: Standby VXSM goes to Failed-U state on removing Active VXSM
Symptom:During the graceful image upgrade to a 1:1 redundant VXSM pair, after "loadrev"
CLI issued to upgrade image to the standby VXSM and before "commitrev" CLI to commit the new image, if the active VXSM gets reset by user manually or other failure, the standby VXSM goes to "Failed-U" state.
Condition: In any VXSM card type and any of control protocols.
Workaround: Don't do "resetcd" to either active VXSM or standby VXSM before the upgrade process is complete (before "commitrev" CLI is invoked). If a failure occurs in the active VXSM to lead "Failed-U" state in the standby VXSM, following the following steps to get out the situation:
(1) Issue the CLI "abortrev <PrimarySlot> <NewImageVersion>"
(2) Wait the state of the standby VXSM changes from "Failed-U/Active" to
"Failed/Active", then do "resetcd <StandbySlot>"
By doing this, both primary and secondary slots have OldImageVersion and previsou configurations before upgrade.
|
CSCek35586
|
Headline: cnfh248oos forced does not clean up calls, card Fails as a result
Symptom: VXSM card can no clean up all the active calls, or VXSM card reboots or VXSM card switches over to the standby card if redundancy is configured.
Condition: Call agent must be sending subtracts at the rate of thousands a second, leading to congestion on the card. This subtract avalanche is not handled by the congestion routines
Workaround: It has been agreed with the current call agents that VXSM works with that it is the call agent's responsibility to throttle the rate of subtracts which are sent to the VXSM card. Reducing the rate of subtracts to our supported rate of not more than (7 transaction /call * 60 cps) 420 transactions/sec will resolve the problem.
|
CSCek39964
|
Headline: VXSM 2.0->2.5 Graceful Upgrade Fails On T3 Cards
Sympton: If you have T3 VXSM card with the image version 5.2(10.205), the VXSM card state will go to "Failed" state after you invoke PXM CLI "loadrev" to upgrade VXSM image to the newer release image 5.3 or later releases.
Condition: The "Failed" graceful upgrade happens only when the T3 VXSM is currently running H248 application. The graceful upgrade won't fail if the T3 VXSM is currently running MGCP or TGCP application.
Workaround: Use PXM CLI "clrsmcnf" to delete all existing configuration in T3 VXSM card, then invoke PXM CLI "setrev" to execute VXSM T3 upgrade.
|
.
Resolved Caveats in Release 5.3.00
Table 4 describes the caveats that were open in Release 5.2.10.201 but are now resolved in VXSM Release 5.3.00
Table 4 Software Caveats Resolved in VXSM Release 5.3.00
DDTS Issue
|
Description
|
CSCeh20283
|
Headline: AAL2 CPS pkts with bad LI cause Repeater PLD to freeze.
|
CSCeh25926
|
Headline: No digit detect for the ltd hairpin call
|
CSCei32747
|
Headline: In T.38 call with L:fxr/fx:gw;t38 NTFY gwfax(start) rcvd after DLCX
|
CSCei53902
|
Headline: Stuck calls on VXSM (crml_nw_reserve_cac failures)
|
CSCei68726
|
Headline: Incorrect sensor shown in AlarmTrap on configuring temp-volt values
|
CSCei68739
|
Headline: Card reset during pcm trace with invalid ftp password.
|
CSCei73487
|
Headline: Executing "cnfgwis" doesn't bring the line back into service.
|
CSCei74287
|
Headline: Request Event List gets deleted on sending DLCX
|
CSCej06027
|
Headline: RT2.0: upgrade fr 1.5MR Patch to 2.0 failed RDM-a-APP_CALLBACK_EXE
|
CSCej14688
|
Headline: Unsupported packages M, H, R appear as supported in cnf/dspxgcppkgs.
|
CSCek18206
|
Headline: addconip fails and renders CLI interface unusable.
|
CSCek26432
|
Headline: syncram DB takes more than 15% CPU in 60cps
|
CSCek27035
|
Headline: Running mix codec g711 and g729 crashed blade VXSM
|
CSCek27212
|
Headline: xgcpendpts are showing down after issuing a loopback on VXSM.
|
CSCek31980
|
Headline: DSP crashed in AAL2 trunking customer network.
|
CSCin98678
|
Headline: Ecan ON during upspd, GClear upspd codec for V17, V21, V22, V22bis, V23
|
CSCek28085
|
Headline: Default profile codec always picked up for v23Modem
|
CSCek29349
|
Headline: CA Controlled T38,ced and fax mode as none, no NTFY from GW.
|
.
Removed Caveats in Release 5.3.00
Table 5 lists caveats that were listed as open in Release 5.2.10.201 but have been removed because they are unreproducible or otherwise invalid.
Table 5 Release 5.2 (or later) Caveats that are removed in Release 5.3.00
DDTS Issue
|
Description
|
CSCej17721
|
Headline: Error logs for long run/Switchover reported in dsplog
|
CSCej41250
|
Headline: E911 call released and VXSM sends RSIP to reset endpoints.
|
CSCek17512
|
Headline: VXSM card resets while bulk configuring AAL2 cnfvifec and addvif.
|
.
The MGX-VXSM-155 card is also known as the MGX-VXSM-4OC card.
The MGX-VXSM-T1/E1 card is also known as the MGX-VXSM-48T1/E1 card.
The MGX-VXSM-T3 card is also known as the MGX-VXSM-6T3 card.
Related Documentation
The following documents contains information that may be useful to software Release 5.3 for VXSM:
•Cisco MGX 8850 (PXM1E/PXM45), Cisco MGX 8950, and Cisco MGX 8830 Hardware Installation Guide, Releases 2 Through 5.3
•Cisco ATM Services (AXSM) Configuration Guide and Command Reference for MGX Switches, Release 5.2
•Cisco MGX Route Processor Module (RPM-XF) Installation and Configuration Guide, Release 4
•Cisco MGX 8880 Media Gateway, Release 5.3: A Guide to User Documentation.
•Release Notes for Cisco MGX 8850 (PXM1E/PXM45), Cisco MGX 8950, and Cisco MGX 8830 Switches, Release 5.3
Obtaining Documentation
Cisco documentation and additional literature are available on Cisco.com. Cisco also provides several ways to obtain technical assistance and other technical resources. These sections explain how to obtain technical information from Cisco Systems.
Cisco.com
You can access the most current Cisco documentation at this URL:
http://www.cisco.com/univercd/home/home.htm
You can access the Cisco website at this URL:
http://www.cisco.com
You can access international Cisco websites at this URL:
http://www.cisco.com/public/countries_languages.shtml
Documentation DVD
Cisco documentation and additional literature are available in a Documentation DVD package, which may have shipped with your product. The Documentation DVD is updated regularly and may be more current than printed documentation. The Documentation DVD package is available as a single unit.
Registered Cisco.com users (Cisco direct customers) can order a Cisco Documentation DVD (product number DOC-DOCDVD=) from the Ordering tool or Cisco Marketplace.
Cisco Ordering tool:
http://www.cisco.com/en/US/partner/ordering/
Cisco Marketplace:
http://www.cisco.com/go/marketplace/
Ordering Documentation
You can find instructions for ordering documentation at this URL:
http://www.cisco.com/univercd/cc/td/doc/es_inpck/pdi.htm
You can order Cisco documentation in these ways:
•Registered Cisco.com users (Cisco direct customers) can order Cisco product documentation from the Ordering tool:
http://www.cisco.com/en/US/partner/ordering/
•Nonregistered Cisco.com users can order documentation through a local account representative by calling Cisco Systems Corporate Headquarters (California, USA) at 408 526-7208 or, elsewhere in North America, by calling 1 800 553-NETS (6387).
Documentation Feedback
You can send comments about technical documentation to bug-doc@cisco.com.
You can submit comments by using the response card (if present) behind the front cover of your document or by writing to the following address:
Cisco Systems
Attn: Customer Document Ordering
170 West Tasman Drive
San Jose, CA 95134-9883
We appreciate your comments.
Cisco Product Security Overview
Cisco provides a free online Security Vulnerability Policy portal at this URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html
From this site, you can perform these tasks:
•Report security vulnerabilities in Cisco products.
•Obtain assistance with security incidents that involve Cisco products.
•Register to receive security information from Cisco.
A current list of security advisories and notices for Cisco products is available at this URL:
http://www.cisco.com/go/psirt
If you prefer to see advisories and notices as they are updated in real time, you can access a Product Security Incident Response Team Really Simple Syndication (PSIRT RSS) feed from this URL:
http://www.cisco.com/en/US/products/products_psirt_rss_feed.html
Reporting Security Problems in Cisco Products
Cisco is committed to delivering secure products. We test our products internally before we release them, and we strive to correct all vulnerabilities quickly. If you think that you might have identified a vulnerability in a Cisco product, contact PSIRT:
•Emergencies — security-alert@cisco.com
•Nonemergencies — psirt@cisco.com
Tip We encourage you to use Pretty Good Privacy (PGP) or a compatible product to encrypt any sensitive information that you send to Cisco. PSIRT can work from encrypted information that is compatible with PGP versions 2.x through 8.x.
Never use a revoked or an expired encryption key. The correct public key to use in your correspondence with PSIRT is the one that has the most recent creation date in this public key server list:
http://pgp.mit.edu:11371/pks/lookup?search=psirt%40cisco.com&op=index&exact=on
In an emergency, you can also reach PSIRT by telephone:
•1 877 228-7302
•1 408 525-6532
Obtaining Technical Assistance
For all customers, partners, resellers, and distributors who hold valid Cisco service contracts, Cisco Technical Support provides 24-hour-a-day, award-winning technical assistance. The Cisco Technical Support Website on Cisco.com features extensive online support resources. In addition, Cisco Technical Assistance Center (TAC) engineers provide telephone support. If you do not hold a valid Cisco service contract, contact your reseller.
Cisco Technical Support Website
The Cisco Technical Support Website provides online documents and tools for troubleshooting and resolving technical issues with Cisco products and technologies. The website is available 24 hours a day, 365 days a year, at this URL:
http://www.cisco.com/techsupport
Access to all tools on the Cisco Technical Support Website requires a Cisco.com user ID and password. If you have a valid service contract but do not have a user ID or password, you can register at this URL:
http://tools.cisco.com/RPF/register/register.do
Note Use the Cisco Product Identification (CPI) tool to locate your product serial number before submitting a web or phone request for service. You can access the CPI tool from the Cisco Technical Support Website by clicking the Tools & Resources link under Documentation & Tools. Choose Cisco Product Identification Tool from the Alphabetical Index drop-down list, or click the Cisco Product Identification Tool link under Alerts & RMAs. The CPI tool offers three search options: by product ID or model name; by tree view; or for certain products, by copying and pasting show command output. Search results show an illustration of your product with the serial number label location highlighted. Locate the serial number label on your product and record the information before placing a service call.
Submitting a Service Request
Using the online TAC Service Request Tool is the fastest way to open S3 and S4 service requests. (S3 and S4 service requests are those in which your network is minimally impaired or for which you require product information.) After you describe your situation, the TAC Service Request Tool provides recommended solutions. If your issue is not resolved using the recommended resources, your service request is assigned to a Cisco TAC engineer. The TAC Service Request Tool is located at this URL:
http://www.cisco.com/techsupport/servicerequest
For S1 or S2 service requests or if you do not have Internet access, contact the Cisco TAC by telephone. (S1 or S2 service requests are those in which your production network is down or severely degraded.) Cisco TAC engineers are assigned immediately to S1 and S2 service requests to help keep your business operations running smoothly.
To open a service request by telephone, use one of the following numbers:
Asia-Pacific: +61 2 8446 7411 (Australia: 1 800 805 227)
EMEA: +32 2 704 55 55
USA: 1 800 553-2447
For a complete list of Cisco TAC contacts, go to this URL:
http://www.cisco.com/techsupport/contacts
Definitions of Service Request Severity
To ensure that all service requests are reported in a standard format, Cisco has established severity definitions.
Severity 1 (S1)—Your network is "down," or there is a critical impact to your business operations. You and Cisco will commit all necessary resources around the clock to resolve the situation.
Severity 2 (S2)—Operation of an existing network is severely degraded, or significant aspects of your business operation are negatively affected by inadequate performance of Cisco products. You and Cisco will commit full-time resources during normal business hours to resolve the situation.
Severity 3 (S3)—Operational performance of your network is impaired, but most business operations remain functional. You and Cisco will commit resources during normal business hours to restore service to satisfactory levels.
Severity 4 (S4)—You require information or assistance with Cisco product capabilities, installation, or configuration. There is little or no effect on your business operations.
Obtaining Additional Publications and Information
Information about Cisco products, technologies, and network solutions is available from various online and printed sources.
•Cisco Marketplace provides a variety of Cisco books, reference guides, and logo merchandise. Visit Cisco Marketplace, the company store, at this URL:
http://www.cisco.com/go/marketplace/
•Cisco Press publishes a wide range of general networking, training and certification titles. Both new and experienced users will benefit from these publications. For current Cisco Press titles and other information, go to Cisco Press at this URL:
http://www.ciscopress.com
•Packet magazine is the Cisco Systems technical user magazine for maximizing Internet and networking investments. Each quarter, Packet delivers coverage of the latest industry trends, technology breakthroughs, and Cisco products and solutions, as well as network deployment and troubleshooting tips, configuration examples, customer case studies, certification and training information, and links to scores of in-depth online resources. You can access Packet magazine at this URL:
http://www.cisco.com/packet
•iQ Magazine is the quarterly publication from Cisco Systems designed to help growing companies learn how they can use technology to increase revenue, streamline their business, and expand services. The publication identifies the challenges facing these companies and the technologies to help solve them, using real-world case studies and business strategies to help readers make sound technology investment decisions. You can access iQ Magazine at this URL:
http://www.cisco.com/go/iqmagazine
•Internet Protocol Journal is a quarterly journal published by Cisco Systems for engineering professionals involved in designing, developing, and operating public and private internets and intranets. You can access the Internet Protocol Journal at this URL:
http://www.cisco.com/ipj
•World-class networking training is available from Cisco. You can view current offerings at this URL:
http://www.cisco.com/en/US/learning/index.html
CCSP, CCVP, the Cisco Square Bridge logo, Follow Me Browsing, and StackWise are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, and iQuick Study are service marks of Cisco Systems, Inc.; and Access Registrar, Aironet, BPX, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Fast Step, FormShare, GigaDrive, GigaStack, HomeLink, Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, LightStream, Linksys, MeetingPlace, MGX, the Networkers logo, Networking Academy, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, ProConnect, RateMUX, ScriptShare, SlideCast, SMARTnet, The Fastest Way to Increase Your Internet Quotient, and TransPath are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or Website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0601R)
Copyright © 2006, Cisco Systems, Inc.
All rights reserved.
Feedback
