D Supplemental Information For Procedure 8, Step 2

Samples of Message from Convertstp Action for Act-Upgrade Command

The following are illustrative of the messages displayed on the user terminal during the semantic check of the upgrade command in STP Conversion, step 3. Headers have been removed for brevity.

IMT Bus Check Started

IMT Bus Check Completed Successfully.

;

Hardware Validation Test Started

Hardware Validation Test Completed Successfully.

;

IP Route Conflict Validation Report

No conflicts with Eagle PVN and FCN found

End IP Route Conflict Validation Report.

;

Using inactive standby partitions for OAM conversion (disk=xxxxx)

The following are illustrative of the messages to be seen on the console during STP Conversion, step 3 of the upgrade procedure if the fixed disk is used for OAM conversion workspace. Headers and messages not directly output by upgrade have been omitted.

Using inactive standby partitions for OAM conversion (dest=fixed)

;

ACT-UPGRADE: MASP A - BLIXP GPL processing.

;

ACT-UPGRADE: MASP A - GPL uploaded.

;

Starting to format the Standby TDM...

;

Format-disk of standby fixed disk complete.

;

Starting to copy GPLs to Standby TDM from removable...

;

GPLs copy completed.

;

Tables conversion started...

;

NOTICE: Converting XXXX.TBL

;

Starting to copy system tables to Standby TDM from Active TDM...

;

Converting Standby OAM System partition.

Preserving the source-release DB version.

Conversion of Standby TDM has completed

;

Marking Standby TDM Upgrade Phase = 2...

;

Swapping Active and Inactive partition on Standby...

;

Standby MASP has not finished initializing - please wait...

;

SYSTEM TREE REBALANCING STARTED

;

Table xxxxxxx.tbl: REBALANCING COMPLETED

;

Table yyyyyyy.tbl: REBALANCING COMPLETED

;

12576 OF 12576 TREES REBALANCED

13 OF 13 TABLES REBALANCED

SYSTEM TREE REBALANCING COMPLETED

;

Standby MASP has not finished initializing - please wait...

;

Starting to backup Standby TDM...

;

ACT-UPGRADE: MASP B - Active MASP will reboot and be converted for upgrade.

;

Starting to format the Standby TDM...

;

Format disk in progress

;

Format-disk of standby fixed disk complete.

;

Starting to copy GPLs to Standby TDM from removable...

;

NOTICE: Converting XXXX.TBL

;

Starting to copy system tables to Standby TDM from Active TDM...

;

Converting Standby OAM System partition.

Preserving the source-release DB version.

Conversion of Standby TDM has completed

;

Marking Standby TDM Upgrade Phase = 2...

;

Swapping Active and Inactive partition on Standby...

;

Standby MASP has not finished initializing - please wait...

;

Starting to backup Standby TDM...

;

ACT-UPGRADE: OAM upgrade complete

ACT-UPGRADE: prepare to initialize network cards

;

Starting network conversion...

;

Upgrading n of m <APPL> cards [XXXX]

;

Command in Progress : Network conversion in progress

;

ACT-UPGRADE: Network conversion complete

;

ACT-UPGRADE: Network upgrade complete

;

Command Complete : Upgrade action completed successfully

;

INFO: Provisioning subsystem is in duplex mode.

;

Determination and Recovery of DDL Hunt During Upgrade

Note:

The following section should be completed with the assistance of My Oracle Support (MOS).

After loading its GPL and database tables, the last step required by an MTP card is to crossload its dynamic database (DDB) from adjacent cards. The DDB contains the status of all routes, linksets, and links provisioned in the system. The Dynamic Data Load (DDL) is the process where a loading MTP card obtains the current view of the network via downloading it from an already IS-NR network card. In order for a network card to download a proper view of the network status, the network must remain quiescent during the download. If an update to the DDB occurs, then the download aborts and restarts. Depending on the size of the network, it may take as long as 4 seconds to complete this process. Please note that the network must remain stable (no changes) during this phase for the download to complete successfully.

The card reports its PST as IS-ANR and its SST as DDL Hunt:

Card Failure: Card 1101 did not return to IS-NR.
Status of card 1101:  PST:  IS-ANR         SST:  DDL Hunt   AST:  -----

Please note this appendix addresses DDL during Upgrade. Refer to References for recovery in full function mode.

A system is considered unstable when provisioned and configured devices are cycling from an alarmed state to a clear state. Bouncing links, link congestion and discard, and DPC|Route transition have the most impact on the DDL Hunt state. The table below lists these conditions by UAM number and describes the recovery steps.

The guideline to determine if DDL Hunt is possible when a card boots and tries to reload is based on the number of DDB events, which causes network management messages to be generated. An event is one cycle of alarming and clearing:

1237.0236 ** SLK 1201,A1  tklclset   REPT-LKF: not aligned
    1240.0200    SLK 1201,A1             RCVRY-LKF: link available

One event consists of two transactions, which generates two network management messages. Eight events in one minute causes sixteen messages which averages to a stability period of less than four seconds. This can range from eight events per one device to one event per eight devices.

Table D-1 Recovery from DDL Hunt by UAM

UAM Device Condition Recovery
0236|0200 SLK Bouncing Link

A) Issue DDB checksum SEND-MSG per internal References

B) Issue CANC-SLK to deactivate the affected link

0264 – 0269 SLK Link Congestion

A) Issue DDB checksum SEND-MSG per internal References

B) Investigate the far-end and fix the far-end

C) Issue CANC-SLK to deactivate the affected link

0270 – 0275 SLK Link Discard

A) Issue DDB checksum SEND-MSG per internal References

B) Investigate the far-end and fix the far-end

C) Issue CANC-SLK to deactivate the affected link

0311 – 0313 Route DPC Transition

A) Issue DDB checksum SEND-MSG per internal References

B) Investigate the far-end and fix the far-end

C) Issue CANC-SLK to deactivate the affected link

0314 – 0316 Route Route Transition

A) Issue DDB checksum SEND-MSG per internal References

B) Investigate the far-end and fix the far-end

C) Issue CANC-SLK to deactivate the affected link

Note:

If the front-end switches activity, device may return to previous state.

SWOPS Sign Off.

Table D-2 Discrepancy List

Date Test Case Description of Failures and/or Issues. Any CSRs / RMAs issued during Acceptance. Discrepancy Resolution and Upgrade Center Engineer Responsible Resolution Date: