user manual

J-131
Cisco Transport Manager Release 6.0 User Guide
78-16845-01
Appendix J Troubleshooting
J.10.13 Miscellaneous Problems
Remote node 11 ....—The remote endpoint.
MsgType=100—The message type. The mapping is as follows:
FEEDER_ADDUPD = 100,
MASTER_SPVC_ADDUPD = 101,
SLAVE_SPVC_ADDUPD = 102,
SINGLEENDSPVC_ADDUPD = 103,
PTOMPSPVC_ADDUPD = 104,
MASTER_PVC_ADDUPD = 105,
SLAVE_PVC_ADDUPD = 106,
MASTER_LOCALDAX_ADDUPD = 107,
SLAVE_LOCALDAX_ADDUPD = 108,
FEEDER_DEL = 109,
MASTER_SPVC_DEL = 110,
SLAVE_SPVC_DEL = 111,
SINGLEENDSPVC_DEL = 112,
SLAVE_SPVC_DEL = 111,
SINGLEENDSPVC_DEL = 112,
PTOMPSPVC_DEL = 113,
MASTER_PVC_DEL = 114,
SLAVE_PVC_DEL = 115,
MASTER_LOCALDAX_DEL = 116,
SLAVE_LOCALDAX_DEL = 117,
WILDCARD_DEL = 121,
grep conObjId xxxxxx dmd<dmd_id>Msg*
grep <NotifyDataBroker> .*node x slot y .* sub1 v sub2 w ooemc* < for more EM queries see EM>
b. If the DMD received the message but it is not reflected in the database, identify which databroker
module caused the error. First check the DMD to see if it forwarded the message. If it did not check
for the reason. The format may be wrong or there could be other similar problems. Try to search/
grep node/slot/port/vpi/vci. This is output every time a cache query is done.
grep "DROP MSG: validation error" dmd<dmd_id>.<pid>.* - prints out dropped messages.
c. If the message made it to DMD, you need to see if the sdbroker received the message.
grep "node <node_id> slot <slot#> .* port <logical port> sCh1 <vpi/dlci> sCh2 <vci>"
sdbroker*Msg*
d. If it looks like the message was received by the sdbroker but the database does not reflect the change,
then you should verify if there is an inconsistency between the databroker cache and the database.
To dump the cache, enter:
$ psg sdbroker
The process ID of the sdbroker will be returned.
$ kill -USR1 <process ID returned from the previous command>