|
|
This chapter describes how you can use the tools within the AtmDirector application to troubleshoot and enhance your network.
The following topics provide a framework to help you troubleshoot your network:
The AtmDirector application logs error and debug messages that are useful when you need to troubleshoot your network or resolve any problems. The error and debug messages are automatically recorded (by default) in the $CWSIROOT/log/atmd.log file.
To set the logging option on or off, follow these steps:
Step 1 Select Preferences>Options from the AtmDirector main window (Figure 2-2).
The Global Preferences window opens (Figure 3-3).
Step 2 Select the miscellaneous index tab.
The Miscellaneous options are displayed (Figure A-1).
Step 3 Click the On button to log error and debug messages, or click the Off button to stop logging the error and debug messages.
Topology and discovery messages are automatically logged if the On button is selected. This is the default.
Step 4 Click OK.
You can start or stop logging the error and debug messages while the AtmDirector application is running. The option you select (On or Off) will not change when the application is terminated.
You can begin to troubleshoot your network and resolve any problems by analyzing the error and debug messages that have been recorded in the logfile of the AtmDirector application. The logfile with the error and debug messages is kept in the $CWSIROOT/log/atmd.log file.
The error and debug messages in the $CWSIROOT/log/atmd.log file are in the following format:
<timestamp> AtmDirector:<severity>:<component>:<message>
Example error and debug messages include the following:
1998/07/29 17:09:15.55 AtmDirector:Info:GUI:Started AtmDirector Initialization... 1998/07/29 17:09:15.56 AtmDirector:Debug:Topology:Running in Debug All mode. 1998/07/29 17:09:17.08 AtmDirector:Debug:ORB:EVENTCHANNEL CONNECTED... 1998/07/29 17:09:30.37 AtmDirector:Info:GUI:Finished AtmDirector Initialization.
The AtmDirector application monitors devices and links at defined intervals and shows their status on the topology map by changing the colors of the affected device icons (Table 2-10) and indicating the status of the links (Table 2-11).
You can redefine the intervals by changing the SNMP polling parameters (see Polling Parameters). The polling parameters (Timeout, Retries, Data Collection Polling Interval, and Utilization Polling Interval) are displayed in the Global Preferences window (Figure 3-3).
The Timeout parameter default is 5 seconds. If the polling process does not receive a response from a device in the time specified, the device is considered unreachable.
The Retries parameter default is 3 attempts. If the discovery process cannot reach a device in the specified number of attempts, the device is considered unreachable.
The Data Collection Polling Interval parameter default is 30 minutes. This polling interval is used by RMON.
The Utilization Polling Interval parameter default is 10 seconds. This polling interval is used for the utilization calculations in the VC List.
You can troubleshoot your ATM network or monitor the traffic and usage of its virtual channels (VCs) by using specific reports and graphical displays provided by the AtmDirector application. Refer to the following sections for the information you need:
You can troubleshoot your ATM-VLAN network by monitoring its LANE components and Virtual Channels and by using specific reports and graphical displays provided by the AtmDirector application. Refer to the following sections for the information you need:
You can use the AtmDirector application to troubleshoot your PNNI network by checking the node configurations (including the PNNI timers), monitoring the link status of neighboring peers and PNNI addresses, and tuning the PNNI parameters. Refer to the following sections for the information you need:
The AtmDirector application has some features that require you to enable data collection for troubleshooting purposes. The collected data is used to help you perform the following tasks:
Refer to the following sections for the information you need to collect data:
Table A-1 displays problems you might encounter while using the AtmDirector application and provides probable causes and possible solutions.
| Problem | Probable Cause | Possible Solution |
|---|---|---|
Unable to discover an end host. | ILMI is not enabled. | Enable ILMI on the affected end host. |
No SNMP connection to the end host. | Set up the SNMP connection to the end host. Make sure all device requirements are met. See "Device Requirements" in Chapter 1 "AtmDirector Overview." | |
LEC does not appear in ELAN map. | Device where LEC resides is not SNMP reachable or it was unable to join the ELAN. | Check to see if the LEC exists in the ELAN (see "Displaying Summary Information for an ATM-VLAN" for more information), and check to see if the device is SNMP reachable. |
LEC is unable to join an ELAN. | LEC was not discovered as a valid LEC. | Check to see if the device where the LEC resides is SNMP reachable. |
LEC was discovered at one time, but went down and could not rejoin the ELAN. | Check the status of the LEC, make sure its address is configured correctly on the Lightstream 1010 (see "Monitoring Configuration Server Addresses" for more information). | |
Check the last failure state of the LEC (see "Monitoring LE Server Status" for more information). | ||
No connectivity between clients. | Clients belong to different ELANs. | Verify that both clients belong to the same ELAN (see "Displaying Summary Information for an ATM-VLAN" for more information). |
One client is unknown to the other. | Check the client ARP information to see if it is known to the LE client (see "Monitoring the LE_ARP Table" for more information). | |
Client(s) not registered with the LES. | Check the LES status parameters window (see "Monitoring LE Server Status" for more information). | |
BUS performance graph indicates high usage. | Client using maximum amount of bandwidth. | Determine which LEC is generating heavy broadcast usage. Check the TopN clients (see "Graphing Top N Active Hosts" for more information). |
Unexpected volume of control frames. | Incorrect configuration. | Check "Graphing Client Performance Information" to get information about the control frames and change the configuration accordingly. For example, if the OUT ARP requests have a high volume, you probably need to change the ARP response time. Note See various configuration parameters (such as timeouts) in "Monitoring Client Status and Control Parameters" for more information. |
Need to take device off-line for maintenance purposes. | Possible effects on ELANs. | Check the ATM-VLAN catalog from the fabric map to list all the ELAN components residing on a device (see "Displaying ATM-VLAN Information for Fabric Devices" for more information). |
PNNI node does not appear on the topology map. | PNNI node is not enabled. | Use CiscoView or the CLI to verify the PNNI node (node index=1) is enabled. Then select the Lightstream 1010 switch that contains the node and rediscover the device. |
PNNI node is isolated from the PNNI network. | ANI server did not find a PNNI link for this node during the previous discovery cycle. | Select the PNNI node from the PNNI topology map. Then check to see if the level of the PNNI node is the same as the other nodes (see "Displaying the Node Configuration and Information" for more information). Also check to see if any interfaces for this node are configured to PNNI (see "Using the Interface Tuning Window" for more information). Note If the node level and interface information is correct, you need to rediscover the device. The PNNI link takes approximately 2-3 minutes to synchronize with the neighboring nodes, and the ANI server might not have found a PNNI link from this node in the previous discovery cycle. |
Posted: Thu Sep 30 11:34:10 PDT 1999
Copyright 1989-1999©Cisco Systems Inc.