After upgrading from to version 9.1, or doing a switchcc in 9.1, there is connection database corruption. You can type the dspcon command on one end, but the dspcon command output on the other end shows the connection doesn't exist. The same is true with the dspchstats command output. Cards that previously had no connections, may have new connections.
The problem occurs when a DAX connection is deleted from a node, and the logical channel number (LCN) and Other-End-LCN values are not reset to zero. When a new connection is added, it uses one of those LCN values, and the next new connection uses the remaining value. This creates two connections with the same LCN value.
Specifically, the node must have used all the indexes in the virtual circuit (VC) table, and restarted with previously used VCs (unless you use the copycons command, which reproduces the bug). At that time, a residual value in the LCN.oe field will cause corruption of the VC. This corruption is benign until a switchcc occurs, which deletes connections and creates phantom connections.
Connections may be auto-deleted.
In the case where phantom connections appear, the customer traffic on the real connection will not pass traffic. In observing the connections (using the dspcons command), the customer sees both the real and phantom connections, which list the same terminating endpoint. When the customer displays the LCN value (using the dcct command), the LCN.oe value is non-zero.
In the case of connections that were auto-deleted, add the connections back.
In the case of phantom connections and/or non-zero LCN.oe values:
Delete the offending connection(s).
Reset the standby processor card.
After the standby processor card returns to standby state, execute the switchcc command.
Add the real connection(s) back.
Note:?In release 9.1.15 and higher, the LCN and Other-End-LCN values are initialized to zero when the connection is deleted, so the potential to encounter this problem does not exist. However, before going to these releases, make sure that there are no non-zero LCN.oe values or the problem will be seen immediately after the run revision is complete (because all the nodes do a swithcc).
Note:?This issue can be resolved during an upgrade to release 9.1.15 or higher without first cleaning up the databases. When the first load revision is complete and the standby card is running the new code, use the vt stbybcc command to enter the rbldcondb command on the Standby BCC. This command will check the databases and remove any inconsistencies. This command does exist in releases prior to 9.1.15, but it is unsafe to use.
This defect has Cisco bug ID CSCdm10213. To follow the bug ID link below and see detailed bug information, you must be a registered user and you must be logged in.