|
|
In some cases, the TrafficDirector environment does not work as you would expect. This chapter includes tips for troubleshooting your TrafficDirector environment. Use this chapter in conjunction with the error message descriptions found in Appendix H, "Error Messages."
This section explains:
For more information, see the following sections:
Because the operations personnel who set up and configured your SwitchProbe devices may be different than the TrafficDirector administrator, a quick review of the implications of configuration settings at the SwitchProbe device can help you isolate possible problems.
Before the TrafficDirector application can access SwitchProbe data, the parameters must be properly set using the SwitchProbe agent configuration utility, including those special parameters required for tracking Frame Relay, ATM, and WAN statistics.
For more information, see the following sections:
Before the TrafficDirector application can access the proper data required in the VLAN Monitor or ART Monitor applications, you must verify that the VLAN option is enabled at the SwitchProbe device or Network Analysis Module to support VLAN Monitor, and that the ARTMIB option is enabled at the device to support ART Monitor.
Before the TrafficDirector application can reflect NetFlow and Resource Monitor activity, verify that the NetFlow option is enabled at the SwitchProbe device to support viewing of Proxy SNMP and Round Trip Delay data (with Resource Manager only) and NetFlow statistics.
Before the TrafficDirector application can support viewing of NetFlow statistics on the Network Analysis Module, you must verify that the NetFlow option is enabled on the device.
To ensure that the TrafficDirector administrator has access privileges to the local console on the SwitchProbe device using the TrafficDirector Remote Login application, you must grant the optional administrative privileges (read and write access) to the TrafficDirector administrator.
User access privileges, if set at the SwitchProbe device, allow you to view the console settings, but not edit them. This user-level security setting is useful if you have multiple sites where operations personnel may be asked to track down, but not necessarily fix, a SwitchProbe agent problem.
If you do not know the administrative password at the SwitchProbe device and one is set, you cannot use the Remote Login application. These SwitchProbe security features are independent of the security options you can enable for access to TrafficDirector administrator applications.
The following sections contain more information:
To ensure that properties files can be reinstalled automatically when SwitchProbe devices are rebooted, follow these steps:
Step 1 Use the default scripts to run dvcfg (either startup for most agents or fstartup for Frame Relay agents).
Step 2 Set the SwitchProbe server address to the IP address of the TrafficDirector management station.
Step 3 Verify that the TrafficDirector dvtrap daemon is running.
If these conditions are met, you do not need to manually reinstall the properties files through Configuration Manager.
To test for network connectivity to the SwitchProbe device, use the Test Agents application. The test agent tool indicates whether an agent is operational and what options are supported, and indicates the general health of the device's UDP/IP connection.
For more information about agent configuration issues, see the Cisco SwitchProbe Installation and Configuration Guide.
To test an agent, Frame Relay agent, or switch, follow these steps:
Step 1 Select the agent you want to test from the agent list box either from the TrafficDirector main window or from Configuration Manager.
Step 2 Do one of the following:
If the agent is operational, the Agent Test window opens (Figure A-1).
When a test is successful, the information in Table A-1 is displayed. When you have finished viewing the information, click OK to close the Agent Test window.
| Field | Description |
|---|---|
IP Address | IP address of the agent management interface. |
Ping | Indicates the ping (query) result:
|
Read Community | The agent read community name (as entered in the Configuration Manager application), and whether this name is the same as the agent's established read community name (OK) or not (Failed). |
Write Community | The agent write community name (as entered in the Configuration Manager application), and whether this name is the same as the agent's established write community name (OK) or not (Failed). |
Protocol Monitoring | Indicates whether the agent supports RMON2 network-layer protocol monitoring. |
Application Monitoring | Indicates whether the agent supports RMON2 application-layer protocol monitoring. |
High Capacity Monitoring | Indicates whether the agent supports HCRMON as a high-speed device. |
VLAN Monitoring | Indicates whether the VLAN Monitor option is enabled in the agent. |
Application Response Time | Indicates whether the ARTMIB option is enabled in the agent. |
Resource Monitoring | Indicates whether Resource Monitor is enabled in the agent. Resource Monitor is required to configure RT Delays and Proxy SNMP gets. |
Interface Number | The number of the agent interface used to monitor activity on a network segment. |
Description | The media type of the interface specified in the Interface Number field. |
Interface Type | The type of interface distinguished according to the physical link protocol as described in RFC 1213. |
Physical Address | The MAC address of the agent. |
Number of Interfaces | Displays the number of network interfaces on the agent. |
Net Speed | The estimated bandwidth for the current interface in bits per second (bps). |
DTE Speed | The estimated DTE circuit speed (in bps). |
DCE Speed | The estimated DCE circuit speed (in bps). |
Description | Displays the device model as defined by the network administrator. |
Contact | Displays the name of the person responsible for the agent and how to contact that person. |
SysName | The administratively assigned name of the agent. |
Location | The physical location of the agent as defined by the system administrator in Configuration Manager. |
UpSince | The date and time the agent became operational on the network. Also indicates when the agent was last booted. |
The test information that is generated when communicating with a switch is slightly different from the information generated when you test an agent.
When you test a switch, the TrafficDirector software queries the switch and informs you if the query passed or failed.
Figure A-2 shows the Switch Test window.
When a test is successful, the information in Table A-2 is displayed:
| Field | Description |
|---|---|
IP Address | IP address of the switch management interface. |
Ping | Indicates the ping (query) result:
|
Read Community | The switch read community name (as entered in the Configuration Manager application), and whether this name is the same as the agent's established read community name (OK) or not (Failed). |
Write Community | The switch write community name (as entered in the Configuration Manager application), and whether this name is the same as the agent's established write community name (OK) or not (Failed). |
IP Address | Displays the IP address of the switch's management interface. |
Description | Displays the device model as defined by the network administrator. |
Contact | Displays the name of the person responsible for the switch and how to contact that person. |
SysName | The system name for the switch. |
Location | The physical location of the switch as described by the system administrator in Configuration Manager. |
UpSince | This is the date and time the switch became operational on the network. This also indicates when the switch was last booted. |
Roving Agent | The name of the roving agent defined for the switch, if any. |
Analyzer Port | The name of the switch port that the roving agent is physically connected to, if applicable. |
Monitor Port | The currently roved port, if any. The monitor port contains the name of the switch port that the roving agent is currently monitoring. |
You receive the same message as an agent or Frame Relay agent if the test failed.
To keep the SQL server database you have selected fully operational (either the embedded SQL server that comes bundled with the TrafficDirector software or the Microsoft SQL Server package), review the following sections to help you isolate problems with your SQL database:
Although you properly enabled the logging parameters for an agent in the properties file, you might still receive a message that no data is available for trend reports. If this occurs, you might have one of several problems:
You can verify whether logging is enabled for the proper type of domain (protocol or generic) and the correct number of agents and domains in the shared or custom properties files you created. Only certain combinations of reports and logging parameters---type of report template, number of agents and number of domains---guarantee the Trend Reporter application can generate reports. The valid combinations are discussed in Chapter 31, "Configuring and Generating Reports."
The background logging daemons could be properly configured to launch as the result of the settings (for stats, hosts, conversations, and ART) that you created in the properties file. However, until you click the Install button for the particular agent in Configuration Manager, the background logging daemons are not started and data is not logged. If the properties files are updated later to include domain and logging changes, you must click the Install button again for the changes to take effect.
Clicking the Install button tells the agent (at the SwitchProbe device) which domains to monitor, and it starts the logging process at the TrafficDirector management station.
If you receive a message in the Alert Monitor application that the database server initialization failed, you might trace the problem back to an improper UNIX system-level configuration. This happens because either the file permissions in the $NSHOME/usr directory were not properly set, or the environment variable was set incorrectly.
These issues are covered in the following sections:
You can check whether the environment variable was set properly by entering the following command to determine whether the variable was set to the directory where the TrafficDirector software was installed:
echo $NSHOME
If the variable is not set correctly, you can reset it using the following command:
setenv NSHOME /usr/nshome
(if running the csh UNIX shell)
or
NSHOME=/usr/nshome export NSHOME
(if running the sh or ksh UNIX shell)
Ideally, the environment variables should be automatically set each time the UNIX user logs in. The TrafficDirector installation script automatically sets the variables in the username's profile or.cshrc file during the install process.
You can also check whether the proper UNIX username permissions are being used to start the TrafficDirector software. Only the username that installed the TrafficDirector software is allowed to launch the rmonmgr application. The username also affects database access.
To verify permissions, follow these steps:
Step 1 To verify under which UNIX username the TrafficDirector software was installed, enter the following command:
ls -l $NSHOME/.netscout
Step 2 Shut down all currently running database daemons by entering the following command:
$NSHOME/bin/dbshutdn
Step 3 Once dbshutdn has finished, kill the remaining background daemons that dbshutdn does not stop. To find the remaining running processes, enter this command to generate a list of all background processes currently running:
ps -ef | grep $NSHOME
Step 4 Kill each remaining daemon using the processing ID and the kill command, such as:
kill 56930
Step 5 Issue the ps command again to confirm whether the daemons have been removed from the list; if some remain, you must log in as root user.
Step 6 Enter the su command and enter the root password.
Step 7 Enter the kill command for the remaining daemons.
Step 8 Exit the root login.
Step 9 Remove all control files in the $NSHOME/usr directory by entering this command:
rm *.ctl
Step 10 Remove the process id file in the $NSHOME/usr directory by entering this command:
rm *.pid
Step 11 If you cannot remove any control or process id files, log in again under the root username.
Step 12 Clean up the old log files by moving them into a new subdirectory.
Step 13 In the $NSHOME/usr directory, enter this command:
mkdir oldlog
Step 14 The mkdir command creates a subdirectory called oldlog. Move all existing log files to this new directory.
mv *.log ./oldlog/
Step 15 If you cannot remove the old log files, log in again under the root username.
Step 16 Verify that all remaining files in the $NSHOME/usr directory are owned by the same UNIX username as the person who installed the TrafficDirector software. To examine each file for correct ownership, enter:
ls -l | more
Step 17 If there are still discrepancies in file ownership, log in again as root and issue the chown and chgrp commands. For example, if trafficdirector is the username and staff is the group, enter:
chown trafficdirector *
chgrp staff *
Step 18 Verify that all files now have the correct ownership by using this command:
ls -l | more
Step 19 Log out of the root account.
Step 20 Verify that the environmental variables are set properly prior to starting rmonmgr.
For csh, enter this command:
source .trafficdirector
For sh or ksh, enter:
. ./.trafficdirector
Step 21 Start the TrafficDirector application again by entering this command:
$NSHOME/bin/rmonmgr &
Once started, the TrafficDirector application should run properly. To verify that all background daemons are running, watch the Alert Monitor for possible problems, or periodically check the event logs in $NSHOME/usr.
On UNIX platforms, the Autoreport features in Trend Reporter must have access to X-Windows functions. If the X-Windows environment is not available when generating graphical reports, the reports can fail.
This problem usually only occurs for Autoreporting and not when running the Trend Reporter application interactively.
Two conditions may cause autoreports not to be generated:
If you start the TrafficDirector software for the first time, but do not display it on the local X server (instead, you redirect it to another UNIX machine or PC X server), the autorptd daemon cannot handle the request. To avoid this issue, you should always start the TrafficDirector application first on the local console of the UNIX machine where the TrafficDirector software was installed. Starting TrafficDirector a second time, then redisplaying the GUI to another X server does not repeat the problem.
You can also create a special UNIX script that reconfigures the autorptd daemon to access a remote X server instead of the local X server. The best candidate for the remote server is where the TrafficDirector application is redisplayed.
To reset the DISPLAY environmental variable to an alternate X server, follow these steps:
Step 1 The alternate X server must be reconfigured to allow access to any UNIX username from the UNIX machine where the TrafficDirector software is installed. Enter this command each time the alternate X server is restarted:
xhost+hostname:0.0
Step 2 Rename the autorptd executable to autorptd2 to ensure that the autorptd daemon is not started automatically. Enter this command:
mv $NSHOME/bin/autorptd $NSHOME/bin/autorptd2
Step 3 Using the proper UNIX shell format, create a shell script in $NSHOME/bin called run_autoreports to include the following commands:
#!/usr/bin/csh
source /usr/nshome/.netscout
setenv DISPLAY my_pc:0.0
/usr/nshome/bin/autorptd2
for the csh shell environment, for example. The script redirects the display to the alternate X server automatically.
Step 4 Make the file permissions readable and executable so users may execute the script. Enter this command:
chmod ugo+rx $NSHOME/bin/run_autoreports
Step 5 You can add the run_autoreports script as a daily cron job. Because the original autorptd runs as the root user, you should add the cron job that launches the run_autoreports script while you are logged in as root user.
See your operating system documentation for more information about the crontab command.
Posted: Mon Feb 8 15:05:59 PST 1999
Copyright 1989-1999©Cisco Systems Inc.