|
|
This appendix describes problems you might experience while using IPM and suggests ways to resolve those problems. The information in this appendix is divided into the following major sections:
The command-line switches for the runipm command, shown in Table C-1, allow you to generate log files when running IPM.
| Switch | Meaning |
| -l | Starts IPM with logging set on. Log files accumulate in usr/cwb-ipm/logs. |
| -D | Starts IPM with debugging set on. |
| -V | Starts IPM with verbose debugging set on. Please be aware that verbose debugging produces a tremendous level of output and consumes a large amount of disk space. |
To collect log data, start IPM in debugging mode with logging set on by issuing the following command:
runrtr -D -l
This section describes Cisco IOS debugging commands that you can use from the router. To use these commands, you must first log into the router.
Use the debug rtr error command to enable logging of IPM runtime errors. The no form of this command disables debugging output, including the debug rtr trace command.
[no] debug rtr error [collector]
| collector | (Optional) Number of the collector in the range 0 to 31. |
The debug rtr error command displays runtime errors. If you specify a collector number other than 0, all runtime errors for that collector are displayed when the collector is active. If you specify a collector number of 0, all runtime errors relating to the RTR scheduler process are displayed. If no collector number is specified, all runtime errors for all active collectors configured on the router and collector control are displayed. The RTR scheduler process is responsible for starting and stopping collectors and managing the database.
The trace output generated by the debug rtr trace command uses the same control mechanism as debug rtr error. Therefore, the no debug rtr error command disables both logging and tracing.
Figure C-1 shows sample debug rtr error output. All debug output for the RTR (including debug rtr trace) has the format shown in Figure C-1.
router# debug rtr error 1 RTR 1: Error Return Code - LU0 RTR Collector 1 in echoTarget on call luReceive LuApiReturnCode of InvalidHandle - invalid host name or API handle
Table C-2 describes the variable fields and messages shown in Figure C-1, above.
| Field | Description |
|---|---|
| RTR 1 | Number of the collector generating the message. |
| Error Return Code | Message identifier indicating the error type (or error itself). |
| LU0 RTR Collector 1 | Name of the process generating the message. |
| in echoTarget on call luReceive LuApiReturnCode of InvalidHandle - invalid host name or API handle | Supplemental messages that pertain to the message identifier. |
Use the debug rtr trace command to trace the execution of an RTR collector. The no form of this command disables trace debugging output (but not debug rtr error output).
[no] debug rtr [collector]
| collector | (Optional) Number of the collector in the range 0 to 31. |
The debug rtr trace command can generate a large number of debug messages. First, use the debug rtr error command and then use the debug rtr trace on a per collector basis.
If you specify a collector number other than 0, execution for that collector is traced. If you specify a collector number of 0, the RTR scheduler process is traced. If no collector number is specified, all active collectors and every collector control is traced. The RTR scheduler process is responsible for starting and stopping collectors and managing the database.
The debug rtr trace command also enables debug rtr error for the specified collector. However, the no debug rtr trace command does not disable the debug rtr error command. You must manually disable the command by using the no debug rtr error command.
All debug output (including debug rtr error) has the format shown in Figure C-2.
Figure C-2 shows a partial sample of debug rtr trace output. In this example, a collector is traced through a single operation attempt: the setup of a connection to the target (LU0), the attempt at an echo, and the closing of the connection on the echo attempt.
router# debug rtr RTR 1: Calling getRttMonOperState (check pending) - LU0 RTR Collector 1 RTR 1: Calling getRttMonOperState (check death) - LU0 RTR Collector 1 RTR 1: Starting An Echo Operation - LU0 RTR Collector 1 RTR 1: setting receiveFinished to FALSE - LU0 RTR Collector 1 in dependLuEchoApplication RTR 1: openConnection called - LU0 RTR Collector 1 Calling rttMonHopConnected RTR 1: calling luT0orT2Open - LU0 RTR Collector 1 RTR 1: Dumping luT0orT2Open Result - LU0 RTR Collector 1 applicationHandle: inRttMonCtrlAdminQItem = 13920808 receiveFinished = FALSE currentLUHandle = 14199576 maxRespBufferLen = 52 receivedBufferLen = 0 aHostName = CWBC02 locAddr = 1 eApplNameLen = 7 ApplName = D5E2D7C5C3C8D60 eModeName = 4040404040404040 userDataLen = 14 userData = D5E2D7C5C3C8D61 sysSense = 0 userSense = 0 bindDataLen = 64 bindData = D5E2D7C5C3C8D61 bindDataCount = 14 RTR 1: Calling rttMonSetConnectionHandle - LU0 RTR Collector 1 RTR 1: Calling rttMonSetHopConnectedState to TRUE - LU0 RTR Collector 1 RTR 1: Calling rttMonSetDiagText - LU0 RTR Collector 1 RTR 1: setupPathInfo called - LU0 RTR Collector 1 Calling rttMonStartUpdatePath RTR 1: Calling rttMonUpdatePath - LU0 RTR Collector 1 for Target CWBC02 NSPECHO RTR 1: Calling rttMonEndUpdatePath - LU0 RTR Collector 1 RTR 1: Calling rttMonUpdateNumberOfEchosAttempted - LU0 RTR Collector 1 RTR 1: performEcho called - LU0 RTR Collector 1 applicationHandle: inRttMonCtrlAdminQItem = 13920808 receiveFinished = FALSE currentLUHandle = 14199576 maxRespBufferLen = 52 receivedBufferLen = 0 echoTimeout (milliseconds) = 5000 sequenceNum = 886 rttMonEchoAdminTargetAddress is CWBC02 NSPECHO verifyDataFlag = False RTR 1: Calling rttMonGetFirstStoredHopAddress - LU0 RTR Collector 1 RTR 1: echoTarget called - LU0 RTR Collector 1 applicationHandle: inRttMonCtrlAdminQItem = 13920808 receiveFinished = FALSE currentLUHandle = 14199576 maxRespBufferLen = 52 receivedBufferLen = 0 echoTimeout (milliseconds) = 5000 Data: E6 A7 E8 A9 01 02 03 77 00 00 00 00 C1 calling luReceive... RTR 1: calling luSend - LU0 RTR Collector 1 RTR 1: receiveFinished is FALSE - LU0 RTR Collector 1 in echoTarget calling process_wait_for_event_timed(5000 milliseconds) RTR 1: rtt_closeIndication called - DSPU Msg Proc applicationHandle: inRttMonCtrlAdminQItem = 13920808 receiveFinished = FALSE currentLUHandle = 14199576 maxRespBufferLen = 52 receivedBufferLen = 0 RTR 1: setting receiveFinished to TRUE - DSPU Msg Proc in rtt_closeIndication RTR 1: Woke on receive event - LU0 RTR Collector 1 RTR 1: returned from echoTarget - LU0 RTR Collector 1 with D_echoTarget_connectionLost return_code and responseTime (milliseconds) = 196 ... RTR 1: Calling getRttMonOperState (check active) - LU0 RTR Collector 1 RTR 1: Going to Sleep - LU0 RTR Collector 1 until next frequency time (delta milliseconds 60000)
If you receive an error message, verify that you have tried the recommended action for resolving the error. Check for any release-specific information that may apply to a problem by reading the Release Notes for CiscoWorks Blue Internetwork Performance Monitor.
To help solve any problems you may encounter using IPM, have the following information ready when you call Cisco Systems for support:
|
|