|
|
Follow the information in these sections to troubleshoot CWSI Campus:
To use many of the troubleshooting techniques, you must first understand the background processes of CWSI Campus.
Refer to these sections for information about understanding and working with the CWSI Campus background processes:
CWSI Campus includes the following major technology components that enhance the overall performance:
These background processes are described in Table 8-1. The server processes represent the processes controlled by the CWSI Campus software; these are the background processes for the client processes. The client processes require user input.
| Process | Description | Type | pdshow | Task Manager or ps- |
|---|---|---|---|---|
Process Manager | This daemon manager starts and monitors many of the CWSI Campus processes, including ANI, RTPoller, Event Channel, and OSAgent. The Process Manager is one of the Essentials processes that monitors CWSI Campus. |
| dmgtd |
|
AniServer | ANI is a multithreaded Java program. It is installed as a daemon process and runs in the background, beginning as the workstation starts up. ANI is responsible for the discovery of the network, and it does all SNMP communication. | Server | AniServer | jre.exe |
CWSI Campus Database | The database engine is responsible for checking all ANI information into the database. For ANI, this is a checkpoint only. ANI performs all of its operations from the data stored in memory. The database stores user-entered information and allows ANI to quickly load its data model into memory upon a subsequent restart. | Server | DbCwsi (UNIX only) | dbeng50 The Essentials database engine has the same name, so your system should be running two processes with this name. |
OSAgent | OSAgent is a Common Object Broker Architecture (CORBA) agent, which passes messages between the AniServer and clients. All servers must register with the OsAgent, and all clients looking for service find it with the help of the OsAgent. The CWSI Campus login window is used to register the CWSI Campus client with OsAgent and to indicate that it is searching for an ANI named AniServer. The OSAgent is one of the Essentials processes that monitors CWSI Campus. | Server | RmeOrb | osagent |
RTPoller | Used by the AtmDirector application for periodic polling of the network for status of devices and links. | Server | RTPoller | jre.exe |
EventChannel | Sends events to all servers and clients who have registered with it. | Server | EventChannel | jre.exe |
CWSI Campus Client | Downloads complete picture of the topology so selection and display are done locally. Receives events from ANI about changes in discovery or network status. | Client | N/A | N/A
|
UserTracking Client | Provides graphical user interface for the UserTracking application. | Client | N/A
| N/A
|
VlanDirector Client | Provides graphical user interface for the VlanDirector application. | Client | N/A
| N/A
|
Topology Client | Displays network topology and used as the primary starting point for other applications. | Client | N/A
| N/A
|
AtmDirector | Links to the OSAgent and CWSI Campus database for some processing. | N/A |
|
|
CiscoView | Links to the OSAgent to provide communication with devices on the CWSI Campus map and CiscoView. | N/A |
|
|
TrafficDirector | TrafficDirector does not link directly with any of the background processes. You can start TrafficDirector from the CWSI Campus map. | N/A |
|
|
Figure 8-1 illustrates the interactions of the CWSI Campus processes.
Some of the troubleshooting steps may require that you enable trace or debug in ANI to gather additional information. You also might be asked to enable trace or debug for particular subsystems of CWSI Campus when you contact your Cisco TAC representative for additional assistance.
To enable trace and debug, follow these steps:
Step 1 Open a command prompt or shell window.
Step 2 Enter stopcwsiserver to stop the CWSI Campus server processes.
Step 3 Start ANI and enable trace and debug by entering the following command:
ani -trace <subsystem> -logfile <logfile name>
The troubleshooting instructions or the TAC representative will provide you with the appropriate subsystem name. You can enter any name for the log file, and the log file will appear in the <CWSIROOT> directory, where <CWSIROOT> is the directory in which you installed CWSI Campus.
Step 4 To stop the process, press Ctrl-C from the command prompt or shell window.
Step 5 Contact your Cisco TAC representatives and provide them with this log file.
The following command-line scripts control the CWSI Campus processes:
To use these scripts, you must be signed in as the administrator on Windows NT or as root on UNIX operating systems. Open a command prompt or shell window. Enter stopcwsiserver to stop the CWSI Campus server processes. When the prompt returns, all the daemons have been stopped. To restart the processes, enter startcwsiserver and wait until the prompt returns.
For detailed instructions for performing these tasks on Windows NT and UNIX systems, refer to the Troubleshooting chapter of the installation guides included with CiscoWorks 2000.
If an error occurs stating that you have lost connection to EventChannel, follow these steps:
Step 1 From the command prompt or shell window, enter pdshow AniServer to determine if AniServer is still running.
If it is not running, continue with Step 3.
Step 2 Check the Start and Stop time to determine if AniServer was restarted while CWSI Campus was running.
If AniServer did go down without your knowledge, open the ani.log file to determine the cause. You can also send the log file to your Cisco TAC representative to see if they can determine the cause.
Step 3 From the command prompt or shell window, enter pdshow EventChannel to determine if EventChannel is running.
If EventChannel is not running, continue with Step 5.
Step 4 Check the Start and Stop time to determine if EventChannel was restarted while CWSI Campus was running.
If AniServer had been restarted, EventChannel is reset, which terminates the connection between the CWSI Campus client and Event Channel.
Step 5 If either AniServer or EventChannel are not running, follow these steps:
(a) Exit CWSI Campus.
(b) Enter the startcwsiserver command.
(c) Start CWSI Campus.
If you have difficulty starting the CWSI Campus applications, follow the tips in these sections:
If you have just restarted your computer and are unable to log in to <Hostname>AniServer, the ANI server might not be ready to receive messages. Wait a few minutes, then try to log in again.
If you are still unable to log in, refer to the Troubleshooting chapter of the installation guides included with CiscoWorks 2000. That chapter includes detailed steps for resolving this error on Windows NT and UNIX systems.
You can run a utility to determine if you can connect to the CWSI Campus database.
Step 1 Locate the testdbconn.exe utility in the <CWSIROOT>/bin directory, where <CWSIROOT> is the directory in which you installed CWSI Campus.
Step 2 Run the testdbconn utility.
If the program finishes, and the prompt returns, then the database connection is fine. If the program appears to hang, contact your Cisco TAC representative for additional assistance.
A corrupted database cannot be easily identified. In past versions of CWSI Campus, symptoms included a connection that hangs or intermittent hanging. However, these problems have been resolved. Currently, the only way to know definitively whether the database is corrupted is to look at the ani.log file. If many SQL exceptions and errors are present in the ani.log, the database may be corrupted. You should contact your Cisco TAC representative for assistance determining whether your database is corrupted.
ANI cannot perform effectively with a corrupt database. If you determine you have a corrupt database, you need to reinitialize a new database.
 | Caution If you have entered information into the UserTracking application, this information will be lost when you delete the corrupted database. |
You can replace a corrupt database using two different methods:
If you run the script to replace a corrupted database, the script automatically stops all CWSI Campus servers. After the database engine stops, the script then erases the old database, sets the correct permissions, and replaces the old database with an empty, reinitialized database. The script automatically restarts the CWSI Campus servers.
To use this script, follow these steps:
Step 1 Run the reinitdb script.
On Windows NT, select Run from the Start menu and enter reinitdb.
On UNIX systems, log in as root and run the reinitdb script located in the <CWSIROOT>/bin directory, where <CWSIROOT> is the directory in which you installed CWSI Campus.
Step 2 Read the information that appears on the screen.
Step 3 Press any key to run the script, or press Ctrl-C to exit out of the script without running it.
Step 4 After the script finishes, wait a few minutes before starting CWSI Campus to allow time for the CWSI Campus servers to start up properly.
You should not need to manually replace a corrupted database because the script automatically performs all necessary steps for you. However, you can use this method if you want to retain a copy of your old database.
To create a new database, follow these steps:
Step 1 Run the stopcwsiserver script. (See "Stopping and Starting CWSI Campus Processes".)
Step 2 Locate the current database:
<CWSIROOT>\db\data\cwsi.db
Step 3 Back up the current database by renaming it. For example, you could name it cwsiold.db.
Step 4 Make a copy of the cwsi_ini.db file (which is also in the data directory).
| Caution Do not delete or rename the original cwsi_ini.db file. You will need this file if you need to reinitialize the database again. |
Step 5 Rename the copy of cwsi_ini.db to cwsi.db.
This is a fresh database file.
Step 6 Delete the cwsi.log file.
Step 7 Run the startcwsiserver script. (See "Stopping and Starting CWSI Campus Processes".)
You cannot install CWSI Campus on multiple workstations and allow them to share the database. Also, if you plan to install multiple copies of CWSI Campus on your network, you should change the name of the AniServer that each copy is accessing. See "Using Multiple Copies of CWSI Campus" for assistance.
If you plan to install multiple copies of CWSI Campus on your network, you should be aware of how the CWSI Campus discovery process works in this environment.
Depending on the available system resources on your initial CWSI Campus system, using the wrong AniServer might result in poor system performance of all CWSI Campus systems that are accessing and using the resources of the default AniServer.
To configure your systems, follow these steps:
| Caution The operation of ANI and CWSI Campus clients depends on the information in the ani.properties file. An incorrect entry in this property file can cause CWSI Campus to operate incorrectly. Follow the instructions carefully, and do not attempt to edit other information. |
Step 1 Close all CWSI Campus applications.
Step 2 Run the stopcwsiserver script. (See "Stopping and Starting CWSI Campus Processes".)
Step 3 Locate and open the ani.properties file with a text editor.
The ani.properties file is located in the <CWSIROOT>/etc/cwsi/ directory, where <CWSIROOT> is the directory in which you installed CWSI Campus.
Step 4 Change the following line to rename the AniServer process running on your local workstation:
AniName = AniServer_Name
For example, if you just installed a Solaris version of CWSI Campus, you could rename the AniServer to SOLAniServer.
Step 5 After making these changes, save the file and close your text editor.
Step 6 Run the startcwsiserver script. (See "Stopping and Starting CWSI Campus Processes".)
You can improve the performance of CWSI Campus by reducing the overhead on the CWSI Campus workstation. To reduce the CPU cycles required by CWSI Campus, follow these steps:
Step 1 Reduce the number of discovery threads.
This process causes discovery to take less CPU power, but discovery will take longer.
To change the discovery threads, follow these steps:
| Caution The operation of ANI and CWSI Campus clients depends on the information in the ani.properties file. An incorrect entry in this property file can cause CWSI Campus to operate incorrectly. Follow the instructions carefully, and do not attempt to edit other information. |
(a) Run the stopcwsiserver script. (See "Stopping and Starting CWSI Campus Processes".)
(a) Locate the ani.properties file in the CWSI directory.
(b) Locate the following line:
Discovery.threads=12.
(c) Change this line so that it now states:
Discovery.threads=5.
(d) Run the startcwsiserver script. (See "Stopping and Starting CWSI Campus Processes".)
Step 2 In UserTracking, increase the VMPSMajor and VMPSMinor time schedules.
Step 3 Increase the Discovery time scheduling interval.
Step 4 Change the discovery time scheduling interval to be fixed (once a day, twice a day) based on your need for timely information.
Step 5 Set up the system for high performance.
(a) Install enough physical memory to handle CWSI Campus and any other programs that you run simultaneously. You should avoid using swapping.
(b) Ensure a fast network connection; the connection should be better than a 10 MB shared media connection.
(c) If you are using Windows NT, use ultra fast wide SCSI drives. Also, place the swap file on its own partition if possible or ensure it remains unfragmented.
When entering valid community strings, what determines whether these examples are invalid or valid?
172.26.1.*:sub1::::::sub1: 172.26.1.*:sub2::::::sub2:
*.*.*.*:sub1::::::sub1: 172.26.1.*:sub2::::::sub2:
The first example is invalid because you have assigned different community strings to the same nested address. CWSI Campus probably will overwrite the first entry with the second. However, unpredictable results are also possible.
The second example is valid because 172.26.1.* is an address nested in the *.*.*.* address.
If you accidentally enter an invalid write community string, you will still be able to discover the network (provided you entered a valid read-only community string). You will not be able to perform any write actions until you enter a valid read-write string.
If you have experienced difficulty interpreting your discovered network, follow the suggestions in this section for assistance with common problems.
When a link between devices appears as a dashed line, it means that during the last discovery cycle, CWSI Campus was unable to do a complete discovery of one of the devices at either end of the link. This situation could happen if the link is inoperable for any reason, for example, if the link was removed from the network.
The most likely explanation for these dashed lines is an SNMP timeout. SNMP typically has the lowest priority of the background processes for the Cisco device system. For example, SNMP can be affected if you create a new VLAN because a spanning tree recalculation occurs which takes precendence over SNMP.
You can lengthen the SNMP timeout for an individual device. To lengthen the timeout, follow these steps:
Step 1 Select Edit>SNMP Communities from the CWSI Campus map window.
Step 2 Enter the community string using this syntax:
target:read:UNUSED:timeout:retries:UNUSED:UNUSED:write:
The default timeout is 3 seconds.
Step 3 If individual devices are configured with different community strings, enter new lines for each device.
Any changes made to the community strings take effect immediately.
Devices with a red X on them are not being discovered properly. For any device to be discovered by CWSI Campus, the following criteria must be met:
Devices appearing as a box with a red X signify that the device is reachable, but it is unknown to CWSI Campus. This icon is typically displayed for non-Cisco devices. It may also display if a new Cisco device has been released since the last release of CWSI Campus.
Several factors determine how long a discovery will take, including the following:
If you experience a slow discovery, follow these steps:
Step 1 Restrict discovery to only the VTP domains that you want to manage.
To exclude specific domains, follow the instructions in the "Adding and Removing VTP Domains" section of Chapter 3, "Discovering Your Network".
Step 2 Ensure that you have entered the appropriate community strings for your devices.
To edit the community strings file, follow the instructions in the "Modifying Community Strings" section of Chapter 2, "Preparing for Network Discovery".
Step 3 Increase the number of threads available to discovery if you have many devices to discover.
CWSI Campus allocates 12 threads to discovery. If you have many slow or unreachable devices, they can fill the thread pool and prevent other devices from being discovered.
To change the increase discovery threads, follow these steps:
| Caution The operation of ANI and CWSI Campus clients depends on the information in the ani.properties file. An incorrect entry in this property file can cause CWSI Campus to operate incorrectly. Follow the instructions carefully, and do not attempt to edit other information. |
(a) Run the stopcwsiserver script. (See "Stopping and Starting CWSI Campus Processes".)
(b) Locate the ani.properties file in the CWSI directory.
(c) Locate the following line:
Discovery.threads=12
(d) Change the line so that it reads:
Discovery.threads=60.
(e) Run the startcwsiserver script. (See "Stopping and Starting CWSI Campus Processes".)
You cannot completely shut off discovery. CWSI Campus was built on a real-time data model that relies upon discovery data.
You can set the discovery interval to an extremely large number so that discovery only occurs when the ANI server starts or when you manually discover the network.
See the "Changing Discovery Parameters" section in Chapter 3, "Discovering Your Network".
If CWSI Campus has discovered a device that you do not want displayed on the map, you cannot delete this device. The following solutions are available:
If CWSI Campus cannot correlate the ATM link information, the ATM network appears as a ATM cloud on the CWSI Campus map. Possible causes and their solutions include:
If none of these solutions resolve the ATM cloud, contact your Cisco TAC representative for additional assistance.
On some devices (typically unknown devices), CWSI Campus can retrieve only the media table from the IF table RFC1213 MIB ifType. In these cases, the link is displayed as Ethernet. For most devices, CWSI Campus reads the enterprise-specific MIBs, which contain more detailed port-type information. Therefore, 10M and 100M are displayed on the map.
Make sure that your routers do not have the same sysName. Routers advertise sysName as their CDP cache identification, and CWSI Campus depends on CDP information for discovery. Therefore, if you have two or more devices with the same sysName, CWSI Campus displays unpredictable results.
You can also check the log file to see if a large number of duplicate devices have been discovered and rejected as duplicates.
Devices that are unsupported by CWSI Campus will not appear with a device name, but will appear with an Object Identifier (OID) instead. CWSI Campus attempts to map the OID to a Cisco product tree MIB. If the OID is under the ciscoProducts or workgroup tree, the OID appears as the device name.
Some Frame Relay CDP links may not be discovered by CWSI Campus even though their neighbors appear by using the show cdp command on the CLI. This is caused by an IOS bug in which point-to-multipoint Frame Relay WAN links do not appear in the SNMP list of CDP neighbors even though they appear on the CLI.
Discrepancy reports allow you to discover inconsistencies in your network.
These sections provide information about working with discrepancy reports:
You can display and print reports about inconsistencies in your network map.
Step 1 From the CWSI Map window, select Reports>Discrepancies.
The Discrepancy window opens (Figure 8-2).
Step 2 To print the discrepancy report, select File>Export.
The report is saved as a file. You can print the report from the program in which it has been saved.
The discrepancy report displays information on inconsistencies or irregularities in your network. Table 8-2 describes these irregularities that may appear in your report.
When interpreting the discrepancy report, keep in mind that configurations that you set up intentionally may appear as discrepancies. If you are aware that this is how you wanted to configure your network, then do not be overly concerned with the discrepancies.
| Discrepancy | Meaning |
|---|---|
Trunk VLANs Mismatch | Different ends of a trunk specify different VLANs. |
Native VLANs Mismatch | Different ends of a single VLAN link specify different VLANs (native VLANs differ). |
VLAN Name Conflict | VLANs with different ISL numbers have the same name in different domains. |
VLAN Index Conflict | VLANs with different names have the same ISL number in different domains. |
VLAN SAID Conflict | Different SAID numbers on the same VLAN in different domains. |
LANE Configuration Server ATM Address Missing | Lane ATM addresses not found on the ATM switch. |
LANE Client VLAN/ATM-VLAN Misassociation | ATM-VLAN associated with a VLAN with a different name. |
LANE Client with no ATM-VLAN | A LANE client has no ATM-VLANs. |
LANE Broadcast Server with no ATM-VLAN | A LANE broadcast server has no ATM-VLAN. |
Link Duplex Mismatch | Full-duplex versus half-duplex on either side of a link. |
Link Speed Mismatch | Different link speed on either side of a link (for 10/100 ports or for any group of links). |
Trunk VLAN Protocol Mismatch | Protocol encapsulation differs across a trunk (isl versus 802.1Q). |
Trunk/nonTrunk Mismatch | Trunking ports versus nontrunking ports on either side of a link. |
VTP Disconnected Domain | A link in a VTP domain is not set to trunk. There are devices in this domain that do not communicate through any trunk. |
No VTP Server in Domain | There is no VTP server in the domain. |
EtherChannel Port Spanning Tree Not Disabled | Spanning Tree is not supported with Catalyst software release 2.3 and lower. Therefore, you must disable Spanning Tree on switches with active VLANs that go across the Fast EtherChannel connections. For Catalyst software release 3.1 and higher, you can configure Spanning Tree on Fast EtherChannel links. |
You can customize the Discrepancy Report to display only those discrepancies about which you want to be notified.
Step 1 From the CWSI Campus Map, select Options>Properties.
The CWSI Properties window opens.
Step 2 In the Properties window, select Discrepancy.
The discrepancies are displayed.
Step 3 Select only those discrepancies that you want displayed.
If you need assistance with CWSI Campus, or if you want to provide feedback to Cisco about CWSI Campus, follow these steps:
Step 1 Select File>Email Comments.
Step 2 In the CWSI Campus Mail window, enter the address information and describe the problem.
Step 3 Click Send to send the e-mail to Cisco Systems.
Posted: Mon Nov 15 10:30:49 PST 1999
Copyright 1989-1999©Cisco Systems Inc.