Cisco Systems 78-16845-01 appendix Cmgrd Errors, 100

Appendix J Troubleshooting

J.10.8 Connection Management Problems

J.10.8.4.8 Cmgrd—Sdbroker Modification/Deletion Errors: Modifying or Deleting a Connection Results in "sDatabroker Could not lock connection entry." Error

Related key index entries: cmgrd, sdbroker, lock connection

During a modify or delete connection request, this error could result if sdbroker cannot find the connection in its cache.

All scenarios of modify/delete connection failures display the same error. To determine exactly what happened you must view the /opt/svplus/log/sdbrokerX.XXXX.log file.

Step 1 Search for the error "<sDbkr_CmgrdModConn_c::Process> INTERFACE ERROR" near the end of the file. A detailed reason for the error will follow on the same line.

Note For delete connection requests, search for sDbkr_CmgrdDelConn_c::Process instead of sDbkr_CmgrdModConn_c::Process.

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 logs and nts logs 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.

J.10.8.4.9 Cmgrd Errors

During an addition request, cmgrd could return errors which cmgrd has received from snmpcomm or the switch itself.

J.10.8.4.10 Cmgrd—Addition, Modification, and Deletion Errors: Provisioning a Connection Results in "Fail due to Switch Timeout" Error

Related key index entries: cmgrd, timeout

When any add, modify, or delete connection request is made, cmgrd issues a request to the switch with an SNMP community string, either a SET or GET string. These community strings are overwritten by the process snmpcomm. This process uses the values of the strings which are present in the node_info table. Thus, when a provisioning request times out from the switch, one possible problem is that the node's community string in the node_info table does not match the string on the node itself.

The problem can be researched by checking the community strings on the node and the node_info table.

Step 1 Check the community strings on the nodes by issuing the command dsnmp.

Step 2 Check the community string in the node_info table based on node_id. The strings are encrypted, so use the decrypt binary, which displays the string in the Clear format.

Step 3 Once the strings are cross-referenced and you have determined that a discrepancy is indeed present., then you can change the strings in either of the following ways:

•Issue the command cnfsnmp on the node and change the community strings to match that of the CTM.

	Cisco Transport Manager Release 6.0 User Guide
J-100	78-16845-01