user manual

J-130
Cisco Transport Manager Release 6.0 User Guide
78-16845-01
Appendix J Troubleshooting
J.10.13 Miscellaneous Problems
Note All ports in the database and the messages are 0-based, and all ports on the switch CLI are
1-based. Therefore, if the switch shows port 3, then you should query for port 2.
a. Query the user_connection table for one of the connections in question. For example, if the
connection has a local endpoint of node = n, slot = s, logical port = p, vpi/dlci = s1, vci = s2, then
the query would look like this:
SELECT * from user_connection where l_node_id = n, l_slot = s, l_logical_port = p,
l_subchnl_1 = s1, l_subchnl_2 = s2
If you are unsure which side is local and which is remote, try a query with both l_node_id = n and
r_node_id = n (and slot, port, and so on). If this row in the database is inconsistent with the same
information on the switch, more investigation is required.
b. Verify that the databroker has received all traps from the EMs. To do this, view the columns
inseg_tbl_1, inseg_tbl_2 and inseg_tbl_3. If the flag is set to '1' then all traps for the given segment
have been received. A flag tells you if the databroker received an add message for the given segment.
If it is set to 0 it means the segment trap has not been processed by the databroker. If the flag is set
to 2 or 3, that means only one end of the segment has been processed.
Note If the connection does not have three segments, the unused segments default to 1.
c. You should now check the EM connection tables for the connections in question. If you see that the
segment tables are correct and the user_connection table is not, or if the inseg_tbl_x flags are not
all = '1', you should continue testing, see J.10.13.2.2 Inconsistent Connection Status, page J-132. If
you see that the segment tables are also incorrect, go to step 3.
Step 3 In some cases a more detailed review of the message flow between EM, DMD, and sdbroker is necessary
to determine the source of the error:
a. Verify that DMD received the message from EM. Search the message log for the connection. This
search is on the DMD first, followed by the sdbroker and xdbroker (xpvc only). The search is either
by connection object ID or node/slot/port/vpi/vci. The DMD logs are checked, and if no messages
are found, then the ooemc or other EM processes are checked. If the message is found, or the logs
are incomplete, then you need to look deeper into the databroker processes. If the DMD or the EM
logs are complete and the message was not sent to DMD, then it is most likely an EM issue.
Find the DMD by using the command /opt/svplus/dbcmap -d <node_id>. The output will provide
you with the DMD whose logs need to be queried.
grep "node <node_id> slot <slot #> .* port <logical_port> .* sCh1 <vpi or dlci> sCh2
<vci>" dmd<dmd_id #>Msg*
Each output line is similar to this:
( 7) 21:49:43 1058910582 MsgType=100 connObjId 65665 connStatus 1 secStatus 1
upperLevelAlrm0 oamStatus 0 channelNo -4272512 termination 1 masterFlag 0 wildCardFlag
0 controllerType 0 subType 55 lPercUtil 100 rPercUtil 100 persistentSlave 1
prefRouteId 0 directRouteFlag 0 Local node 11 slot 15 line -1 port 0 logPort 0 sCh1 1
sCh2 37 type 1 subType 0 nni -1 netprefix Remote node 11 slot 14 line -1 port 0
logPort 0 sCh1 32 sCh2 234 type 1 subType 0 nni 0 netprefix
Items of interest in the above example are:
21:49:43—The time at which the event occurred.
Local node11 slot 15 .... sCh1 1 sCh2 37—The local endpoint.