Cisco Systems 78-16845-01 appendix You should see something like the following

Appendix J Troubleshooting

J.10.4 Equipment Management Problems

•VxsmCrr Trap

•VxsmTone Trap

•VxsmAs Trap

•VxsmAsp Trap

•VxsmAs Trap

•VxsmLapd Trap

•VismABCDBitTemplate Trap

Review the log messages using the traplist command and decide how you can grep the messages according to your needs. In the above example, there is another key word ("PROCESSED") that indicates that the trap has been processed. This gives you the starting point in the log file so that you can study the log messages. If the database is not populated correctly, then the subsequent log messages should provide you information on the database inconsistency problems. Some trap processing may invoke SNMP data upload. From the log messages, you can verify whether the uploaded data is correct or not. Other possible reasons for database inconsistency are:

•SNMP upload failure and maximum retries is exceeded; SNMP timeout; or throttle error. You can verify the problem in the snmpcomm log files.

•Database operation error. You can verify the problem in the ooemc log files.

If you do not know exactly what trap sequence is sent by the switch to CTM, you should try a working scenario and study the log for the trap sequence, or you can use HPOV to determine the trap sequence.

Step 3 To verify whether or not a trap has been received from the switch and forwarded to ooemc, refer to the nts log. If the trap has been buffered in the trap queue, the possible reasons are:

•Node is syncing due to regular node resync or due to -2 trap.

•Card is syncing and the trap is related to the card. The traps will be buffered in the queue until card resync completes.

•Summary alarm trap is processed. Summary alarm is being uploaded or parsed. You can grep the log files for information related to summary alarm traps.

To verify that the trap has been put into the queue, you can do the following:

grep EMC_TrapQueue_c::append ooemc_log grep trap_num

You should see something like the following:

INFO: <EMC_TrapQueue_c::append> entering. ======> append trap# 60303 to trap queue; getHdlrLevel=5, getTrapLevel=5, #=174

Defect information—Collect ooemc, nts, and snmpcomm log files from the /opt/svplus/log directory.

Possible alternative workaround—Manually resync the node. If the problem persists, perform a coldstart. If the problem is still not resolved, collect the log files and report the problem.

Cisco Transport Manager Release 6.0 User Guide

J-52 78-16845-01