Cisco MGX 8220 Firmware

March 27, 2003

Products Affected

Problem Description

Data stops on soft permanent virtual circuits (SPVCs) traversing from RPM/Bs or RPM-PRs (Route Processor Module-PRemium) to Enhanced ATM Switching Service Module (AXSM) ports after an upgrade from software release 2.1.80 to 3.0.20. In addition, data traversing from an RPM/B or RPM-PR to AXSM or AXSM/B is interrupted for a short period of time.

This anomaly only affects the SPVCs which have one or both endpoints terminated on RPM-PR card. The bug does not affect the RPM LVCs or Control VCs. UBR connections are also not affected by this anomaly. MGX-RPM-XF-512 SPVCs are not affected by this anomaly as the MGX-RPM-XF-512 has a different VSI-Slave implementation.

Background

This anomaly occurs for any upgrade from release 2.1 to release 3.0.00, 3.0.10 or 3.0.20. A field called CLR exists, but is not used, in 2.1 releases. When loadrev 3.0.20 is issued, the Standby PXM45 converts the 2.1 connection database to 3.0.20 format. Because the CLR field in the original 2.1 database was not initialized correctly, some values of the CLR field are not accepted by 3.0 releases. Invalid CLR values in 3.0 result in rejection of the SPVC on the Standby PXM45.

When the Standby PXM45 becomes active after the runrev command is issued, the connections with invalid CLR field values will fail. However, on the AXSM and AXSM/B cards (not Enhanced AXSMEs) the CLR field handling is corrected by the VSI-Master routine which successfully recommits the connection on the VSI-Slave.

On the AXSME cards, the VSI-Slave does not handle the recommit properly. After two attempts to recommit SPVCs with misprogrammed CLR values, the VSI-Master will stop attempting to recommit. As a result, the AXSME will continue to experience complete loss of data until the user intervenes.

Problem Symptoms

The SPVCs that stop passing data on AXSME cards show no alarm. The first symptom is that network users will experience loss of connectivity to remote resources. Remote user sessions will drop and may not recover. The test delay tstdelay will fail.

The SPVCs on AXSM and AXSM/B cards will show failure from the time the runrev 3.0.x0 completes to the time the SPVCs is reprogrammed. This failure may last up to 60 seconds in extreme cases. During the period the affected SPVCs are marked as failed, users will also experience loss of connectivity to remote resources.

Network Engineers may proactively search for failed connections after an upgrade from 2.1 to 3.0 by following these steps:

1. Log into PXM45 shell.

2. Issue the command vsiDspConnCnt and look for discrepancies.

On Active 2.1.80 card enter shell.

pxm45>vsiDspConnCnt
vsiDspConnCnt
No. of SVC: 2
No. of SPVC: 204                   <<<<< note this value
No. of routed/derouted SPVC: 202/2 <<<<< note this value

On 3.0(20.0) standby card (without fix) enter shell.

pxm45>vsiDspConnCnt
vsiDspConnCnt
No. of SVC: 2
No. of SPVC: 1                   <<<<< should be 204 not 1
No. of routed/derouted SPVC: 0/1 <<<<< should be 202/2 not 0/1
No. of MCast R/R'/L: 0/0/0
No. of VcMerge R/L'/L: 0/0/0

On 3.0(20.100) standby card (with fix) enter shell

pxm45>vsiDspConnCnt
vsiDspConnCnt
No. of SVC: 2
No. of SPVC: 204                   <<<< number matches with active PXM running 2.1.80
No. of routed/derouted SPVC: 202/2 <<<< number matches PXM with 2.1.80
No. of MCast R/R'/L: 0/0/0
No. of VcMerge R/L'/L: 0/0/0

Note:?Entering the PXM45 shell is not normally recommended. The shell is normally accessed for debugging purposes. Careless or erroneous command entry may inflict harm to the switch.

Workaround/Solution

When this issue is encountered, the workaround is to issue the dnport, and then upport commands on the affected port or ports.

Note:?This workaround is required on Enhanced AXSM cards only since the AXSM and AXSM/B will recover the failed SPVCs within 60 seconds.

If it is determined that not all connections on a given port are broken, this failure may be cleared by deleting and re-adding only the affected SPVCs.

The solution is to upgrade to software release 3.0.23 or later, as it contains the fix for this anonmaly. Monitor the bug listed below for availability of the fix.

DDTS

To follow the bug ID link below and see detailed bug information, you must be a registered user and you must be logged in.

For More Information

If you require further assistance, or if you have any further questions regarding this field notice, please contact the Cisco Systems Technical Assistance Center (TAC) by one of the following methods:

• Open a service request on Cisco.com
• By email
• By telephone

Receive Email Notification For New Field Notices

Product Alert Tool - Set up a profile to receive email updates about reliability, safety, network security, and end-of-sale issues for the Cisco products you specify.