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.

Cisco Transport Manager Release 6.0 User Guide

 

78-16845-01

J-99

 

Page 99
Image 99
Cisco Systems 78-16845-01 appendix Appendix J Troubleshooting Connection Management Problems