user manual

J-99
Cisco Transport Manager Release 6.0 User Guide
78-16845-01
Appendix J Troubleshooting
J.10.8 Connection Management Problems
Provisioning fails and the following error messages are displayed:
• "No more vpi/vci available for local trunk end" and "Remote trunk"
• "Local end of the connection already exists," "Remote end," and "Both end"
• "Vpcon already exists for Local Vpi," "Remote Vpi," and "Both ends"
Each of these error messages identifies the reason for the failure of provisioning. They sometimes can
be displayed in error. The reason is a mismatch between the switch and the DMD's cache. To find out if
a mismatch has occurred, dump the DMD cache, using the command pkill -USR1 dmd and compare the
values in the cache with those on the switch for endpoints associated with the error.
Defect Information—If the switch and DMD cache are not in sync, you will need the DMD logs,
message logs, DMD cache dump, and the EM logs for the node in question. You will also need the switch
CLI screen shot of the connection in question.
Possible alternative workaround—If there is a cache inconsistency, the only workaround is a complete
cache resync (/opt/svplus/tools/CacheResync). If there is no DMD cache inconsistency, it is a normal
operational scenario. Different connection add parameters should be chosen.
J.10.8.4.7 Cmgrd—Sdbroker Addition Errors: Adding a Connection Results in "EndPoint Exists Local/Remote/Both end of the
connection already exists." Error
Related key index entries: cmgrd, sdbroker, endpoint exists
During an add connection request, the cmgrd will request intermediate endpoint vpi/vci from sdbroker.
If the sdbroker incorrectly chooses endpoints that are already in use by the switch the cmgrd will try to
provision these endpoints and return the error "endpoint exists" to the user.
Step 1 Determine which of the endpoints already exist on the switch. (If it is the intermediate endpoints then it
is an sdbroker problem.)
a. When provisioning hybrid connections the CMGRD requests intermediate endpoints from the
sdbroker. The sdbroker then requests them from DMD and then sends them back to CMGRD. First
use the dbcmap command (/opt/svplus/tools/dbcmap) to identify the DMD that is used to process
the node. Then dump that DMD's cache. Verify that the DMD does not contain the endpoints in
question in its cache.
b. Determine why the DMD doesn't have the information on endpoints that exist on a switch. You first
need to determine if the EM sent the add message to the DMD. See J.10.13.2.1 Connection
Inconsistency Between the Switch and GUI, page J-129. If the add message is not found and the logs
do not go back to coldstart, then you will need to check to see if the EM has done any processing of
this endpoint. Check for the endpoint in the xxx_Connection table. If the endpoint is not there, check
the EM to determine why it did not process the endpoint. If the endpoint is in the xxx_connection
table, you know that the EM processed it, but you do not know if it forwarded it to the DMD.
Defect Information:
• If the problem is an intermediate endpoint and it is on the switch, but the EM didn't process it or
didn't' send the message to DMD, check the EM log and nts log from /opt/svplus/log.
• If the problem is within the DMD you will need the DMD logs, DMD message logs, and the DMD
cache dump.
Possible alternative workaround—None.