user manual

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