J-100
Cisco Transport Manager Release 6.0 User Guide
78-16845-01
AppendixJ 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.