Cisco Systems 78-16845-01 appendix Process ID of the sdbroker will be returned, 131

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>

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