Table Of Contents
1.1. Network and Device Requirements Introduction
2.4. Register Devices and Interfaces in DNS
2.5. Check Routing and Firewalls
2.6. Network Address Translation
2.7. Check Device Configurations for "Odd" Letters
3. Setting Up CiscoWorks Security
3.2. Modify Admin Password and Cisco.com Account
3.5. Create Self-Signed Certificates
4.1. Configure Cisco.com Account
4.2. Schedule Package Downloads
4.3. Import Downloaded Packages
5.1. Device and Credential Synchronization
5.4. User and Host Acquisition
5.6. Topology Group Administration
5.7. Configure Path Analysis and User Tracking Scheduling
6. Setting Up CiscoWorks Resource Manager Essentials
7. CiscoWorks Device Fault Manager
7.3. Configure the File Notifier Adapter
7.4. Configure the Mail Notifier Adapter
7.5. Configure the Trap Notifier
8.9. Network Operations Center
8.11. Spanning-Tree Documentation
9.3. Automatic Package Download
9.5. Resource Manager Essentials
9.6. CiscoWorks Device Fault Manager
10.4. CiscoWorks Campus Manager
10.6. CiscoWorks Resource Manager Essentials
12. Appendix A—The Network Discovery Process Explained
12.2. Cisco Discovery Protocol Neighbor Discovery
13.1. Required Configuration to Support rcp for CiscoWorks RME Software Distribution
13.2. Required Configuration to Support rcp for CiscoWorks RME Configuration Management
14. Appendix C—CiscoWorks Port Usage
Design Guide
CiscoWorks LAN Management Solution Deployment Guide
1. Device Setup
This section describes the minimum configuration tasks that should be performed on Cisco IOS® and Cisco Catalyst® devices before attempting to manage them using CiscoWorks. It should be noted that this is by no means an exhaustive configuration guide. Depending on the functionality required, further device configuration may be required. For comprehensive information, see "Performance and Fault Management" from Cisco Press as well as Cisco.com.
1.1. Network and Device Requirements Introduction
For CiscoWorks Campus Manager tools to function correctly, network services must first discover the devices in the network. The devices must be properly configured to complete the network discovery. To identify and discover devices and end stations on the network, the following requirements must be met:
•
Devices must support the Cisco Discovery Protocol or Integrated Local Management Interface (ILMI) to be discovered, and the supported protocol (Cisco Discovery Protocol or ILMI) must be enabled on each interface that should be discovered. ILMI is required for ATM devices only.
•
•
•
The following additional requirements must also be met for specific features of the CiscoWorks Campus Manager application to work properly:
•
1.2. Cisco IOS Devices
This section describes the steps that should be taken to set up Cisco IOS devices for network management. Note that not all steps may be required, and some steps can be expanded with more functionality. Do not forget to save the configuration to nonvolatile random-access memory (NVRAM) after performing these steps by using one of the two following commands:
write memory
or
copy running-config startup-config
1.2.1. Community Strings
CiscoWorks Resource Manager Essentials (RME) uses SNMP to retrieve and write information (configuration files, software images, etc.) to the devices. Therefore, all SNMP community strings must match on the devices and in the Essentials inventory.
To configure SNMP community strings on a Cisco IOS device, use the following global configuration commands:
snmp-server community
<read-community-string> rosnmp-server community <write-community-string> rw
1.2.2. System Reload
Some configuration and software management changes require reloading of a device before the changes will take effect. The device must be configured to allow an SNMP manager (in this case the CiscoWorks RME server) to reset the agent. This feature is available only for Cisco IOS devices.
To allow the Essentials server to reload a device, use the following global configuration command:
snmp-server system-shutdown
1.2.3. Syslog Message Logging
All devices must be configured to send syslog messages to the CiscoWorks RME server or a remote Syslog Analyzer Collector (SAC) in order to use the Syslog Analysis feature.
To configure message logging on a Cisco IOS device, use the following global configuration commands:
logging on
logging <server-ip-address>
logging trap <logging-level>
1.2.4. Remote Copy Protocol
The remote copy protocol (rcp) is one of the few protocols that can be used by configuration management and software management to transfer configuration files and software images between devices and the CiscoWorks RME server. To allow the Essentials server to read and write files to a device using rcp, this feature must be enabled on the device. The rcp feature is available only for Cisco IOS devices.
To enable rcp on a device, use the following global configuration commands:
ip rcmd rcp-enable
ip rcmd <remote-host> <remote-username> <server-ip-address> <local-username> enable
The server-ip-address parameter is the IP address or host name of the Essentials server.
Note:
1.2.5. Command-Line Prompts
In order to use the NetConfig function to execute batch configuration commands on devices, all command-line prompts must meet certain requirements:
•
•
Examples:
•
•
If you have customized any prompts, they must meet these requirements.
1.2.6. Cisco Discovery Protocol
Cisco Discovery Protocol is a Cisco proprietary protocol that is used by devices to advertise their existence to other devices on the network. Each device that has Cisco Discovery Protocol enabled maintains a table of its neighbors. Network services uses Cisco Discovery Protocol to gather information on each device and its neighbors, in order to form a view of the network topology. If Cisco Discovery Protocol is not enabled on a device, network services will not be able to discover its neighbors and build a topology of the network. Cisco Discovery Protocol is enabled by default, so you need to enable it only if it has been disabled. You might also want to disable Cisco Discovery Protocol on devices that are on the borders of your management domain. That way, additional devices beyond those boundaries that you are not responsible for will not be discovered and displayed in CiscoWorks Campus Manager.
To enable Cisco Discovery Protocol on a Cisco IOS device, use the following commands:
cdp run (to enable on all interfaces)
cdp enable (to enable on specific interfaces only)
Use the no form of the Cisco IOS command to disable Cisco Discovery Protocol on a device or interface. For example: no cdp enable.
Tip: Where Not to Run Cisco Discovery Protocol
Do not run Cisco Discovery Protocol on links that you do not want discovered, such as Internet connections.
Note:
1.2.7. SysName Variable
The system name must be unique on every Cisco IOS device for network services to discover all Cisco IOS devices on the network. Network services uses this variable to identify each device via Cisco Discovery Protocol. If this value is duplicated on any devices, network services discovers only one of the devices. On Cisco IOS Software, the domain name also affects the sysName.
To set the sysName variable on a Cisco IOS device, use the following global configuration command:
hostname <name>
1.2.8. Source Routing
Source routing is a function within IP that allows the source host to specify the route a packet should take through the network. If this option is specified in the IP header, then the packet is forwarded according to the path specified. This option must be enabled on Cisco IOS devices for the path-analysis function to be able to trace accurate paths from a source device to a destination. Source routing is enabled by default on Cisco IOS devices, so you need to enable it only if it has been disabled.
Verify that source routing has not been disabled by checking the device configuration for the following entry:
no ip source-route (this indicates source routing is currently disabled)
If source routing has been disabled on a device, use the following command to enable it:
ip source-route
Note:
1.3. Cisco Catalyst Devices
This section describes the steps that should be taken to set up Cisco Catalyst devices for network management. Note that not all steps may be required, and some steps can be expanded with more functionality.
1.3.1. Community Strings
Several important items must be configured correctly on every Cisco device that is going to be managed and monitored through CiscoWorks RME. Essentials uses SNMP to retrieve and write information (configuration files, software images, etc.) to the devices. Therefore, all SNMP community strings must match on the devices and in the Essentials inventory.
set snmp community read-only <read-community-string>
set snmp community read-write <write-community-string>
These commands ensure that the device can be identified and that inventory can be carried out.
1.3.2. Syslog Message Logging
All devices must be configured to send syslog messages to the CiscoWorks RME server or a remote SAC in order to use the Syslog Analysis feature.
To configure message logging on a Cisco Catalyst device, use the following commands:
set logging server enable
set logging server <server-ip-address>
set logging level all <logging-level> default or
The server-ip-address parameter can be the address of the Essentials server or a remote SAC that has been configured to forward syslog messages to the Essentials server.
Note:
1.3.3. Telnet
Telnet must be enabled on Cisco IOS devices. This means that the VTY login has to be configured using the following commands:
line vty 0 4
login
password <some password>
exec-timeout 0 0
This example references the minimal configuration. For better access control and logging facilities, consider using TACACS authentication and authorization.
1.3.4. Command-Line Prompts
In order to use the NetConfig function to execute batch configuration commands on devices, all command-line prompts must meet certain requirements:
•
Example:
•
If you have customized any prompts, they must meet these requirements.
1.3.5. Cisco Discovery Protocol
Cisco Discovery Protocol is a Cisco proprietary protocol that is used by devices to advertise their existence to other devices on the network. Each device that has Cisco Discovery Protocol enabled maintains a table of its neighbors. Network services uses Cisco Discovery Protocol to gather information on each device and its neighbors, in order to form a view of the network topology. If Cisco Discovery Protocol is not enabled on a device, network services is not able to discover its neighbors and build a topology of the network. Cisco Discovery Protocol is enabled by default, so you need to enable it only if it has been disabled. You might also want to disable Cisco Discovery Protocol on devices that are on the borders of your management domain. That way, additional devices beyond those boundaries that you are not responsible for will not be discovered and displayed in CiscoWorks Campus Manager.
To enable Cisco Discovery Protocol on a Cisco Catalyst device, use the following command:
set cdp enable <all | module/port>
Tip: All Parameter
Use the "all" parameter to enable Cisco Discovery Protocol on all ports on the device, or enter specific module and port numbers. A range of ports can also be entered. For example:
set cdp enable 2/1-10,3/5-10
To disable Cisco Discovery Protocol on a Cisco Catalyst device, use the set cdp disable command.
Tip: Where Not to Run Cisco Discovery Protocol
Do not run Cisco Discovery Protocol on links that you do not want discovered, such as Internet connections.
Note:
1.3.6. VLAN Trunk Protocol
Note:
VLAN Trunk Protocol (VTP) is used to configure and communicate VLAN settings across multiple switches. VTP must be configured on all switches in order to manage VLANs via CiscoWorks Campus Manager. A VTP domain must be established and the VTP mode must be defined on each device. In addition, at least one switch in each VTP domain must be defined as a VTP server in order for Campus to create VLANs in that domain. Discovering VLANs established on a switch using VTP transparent mode is supported from CiscoWorks Campus Manager Version 3.1. The old restriction of requiring at least one server in a VTP domain to identify virtual LANs (VLANs) has been removed. Then Campus can be used to view, create, modify, and delete VLANs via the topology services application instead of the command line.
To set a VTP domain and mode on a Cisco Catalyst switch, use the following commands:
set vtp domain <name>
set vtp mode <client | server | transparent>
set vtp v2 <enable | disable> (required for Token Ring networks)
Description of modes:
•
•
•
Note:
Note:
The campus best-practice recommendations emphasize campus stability and predictability (especially for protocols such as Spanning-Tree Protocol [STP]). General suggestions for enterprises that prefer a cautious approach may include making use of VTP transparent or VTP off (CatOS 7.0) instead of the typical VTP server and client model. The major VTP benefit of uniform VLAN creation across multiple switches may be out-weighed by the drawbacks of the same thing it is supposed to simplify, which is the automatic extension of VLANs of all switches in a domain. Hence the risk of unaccessary unenforced STP and its issues across multiple switches. Spanning tree is not bad—it is the defaults that are bad.
Another major risk of the VTP client and server is the possibility that the new server versioning could override the existing VTP server and delete VLANs unknown to the new master server from all switches within that domain. Though some of these risks can be reduced by VTP authentication, trunk clearing, and VTP pruning, the added complexity of these functions is not really worth it.
CiscoWorks Campus Topology can still discover and depict VLANs on switches that make use of VTP transparent mode; see http://www.cisco.com/en/US/products/sw/cscowork/ps563/products_user_guide_chapter09186a00800c9e72.html#35719.
More details of this would go way beyond the scope of this document, but the following link—Best Practices for Cisco Catalyst 4000, 5000, and 6000 Series Switch Configuration and Management— http://www.cisco.com/en/US/products/hw/switches/ps663/products_tech_note09186a0080094713.shtml —can be referenced for quite a few campus switching best-practise suggestions, including more technical coverage on spanning tree, further Cisco Discovery Protocol details, channels, Point Aggregation Protocol (PAgP), trunks, trunk clearing, pruning, syslog levels, and unidirectional link detection (UDLD).
1.3.7. Trunking
Note:
Trunking is a method of carrying traffic for multiple VLANs over the same link, between two switches or a switch and a router, thus extending the VLANs across the network. In order to perform trunking, ports on each side of the link must be set to trunk ports, and the Inter-Switch Link (ISL) or IEEE 802.1Q protocol must be enabled. ISL is a Cisco proprietary protocol used to combine traffic from multiple VLANs over one link. IEEE 802.1Q is the industry-standard protocol for performing the same function. IEEE 802.1Q must be used on Token Ring networks.
To enable trunking on a Cisco Catalyst Switch port, use the following command:
set trunk <module/port> on [vlans]
This command establishes the specified module or port as a trunk port and enables the ISL protocol.
You can use the optional "vlans" parameter to specify a specific range of VLANs to be allowed across the trunk. For example: set trunk 2/1 on 2-10 (valid ranges are from 1 to 1005).
2. Preinstallation Tasks
The following tasks should be carried out or reviewed before installing CiscoWorks.
2.1. Verify Locale Settings
CiscoWorks currently supports only the U.S. English and Japanese locales. Using other locales means that you are running on a nonsupported configuration. Further, CiscoWorks may display erratic behavior, such as JRunProxyServer services not starting automatically. Non-U.S. English keyboard layouts should work, though.
2.2. Verify DNS Settings
Make sure the CiscoWorks server has correct Domain Name System (DNS) settings. Verify connectivity to DNS, as well as forward and reverse lookup. CiscoWorks uses DNS for numerous operations, and waiting for DNS timeout will make it appear slow.
2.3. Check Browser Version
The recommended browser is Microsoft Internet Explorer 6.0 (JVM 5.0.0.3805). There are some issues with IE 6.0 Service Pack 1, so be sure to check them. Also, IE 5.5SP2 (JVM 5.0.0.3802) is supported in CiscoWorks Common Management Foundation (CMF) 2.1 and CiscoWorks RMEv3.4. Make sure the Microsoft VM (Java Virtual Machine) is installed.
CiscoWorks uses JRE Version 1.3.1 only.
Note:
2.4. Register Devices and Interfaces in DNS
For the name lookup process to work, devices should be registered in DNS.
When the discovery process encounters a device, it performs a reverse lookup on the IP address where the device was encountered in order to get the host name for the device. CiscoWorks then performs a forward lookup on the host name to get the preferred management interface for the device. Hence, all interfaces should be registered in reverse DNS, but only the preferred management interface should be registered in the forward lookup. The loopback0 interface is an ideal candidate for this, because it is never down.
Also note that CiscoWorks Campus Manager from Version 3.3 onward lets you select the preferred management interface from the graphical user interface (GUI) after discovery has been performed.
2.5. Check Routing and Firewalls
Make sure that any firewalls between the CiscoWorks server and the managed devices are configured to let management traffic through. Refer to Appendix C for information on which ports should be opened.
Also, make sure that there is connectivity between devices to be managed and the CiscoWorks server. Even if a route exists to a network behind a managed device, that does not mean that one exists to (and from) the device itself.
Note:
Note:
2.6. Network Address Translation
Normally, network management and NAT is not a very good combination. However, the following tips can help in managing networks that perform NAT:
•
•
•
As long as the IP addresses for the switches and loopback interfaces are unique throughout the network, the management process can use these IP addresses, even if the IP addresses for the networks on which NAT has been performed themselves are not unique. To make CiscoWorks discover the preferred management interface, see Section 2.4.
2.7. Check Device Configurations for "Odd" Letters
CiscoWorks supports only the 7-bit ASCII character set. This means that device configurations that contain other letters such as Æ, Ø, and Å can cause problems. For example, configurations that contain these letters can cause the discovery process to hang, and thus never finish, or the device synchronization process can fail. Check the contact and location information, interface descriptions, host names, etc. for these letters before running discovery.
2.8. Network Time Protocol
To be able to correlate events across multiple devices, the devices need to have the same perception of the time. To achieve this, configure the Network Time Protocol (NTP) on the devices. For information on how to configure this functionality, refer to the Cisco device configuration documentation or http://www.cisco.com/en/US/support/index.html.
2.9. Server Sizing
Tables 1 through 4 give the recommended configurations for server sizing. These are approximate figures, and may not be applicable to every environment, even if the numbers of devices match. Also notice that the greater the number of modules (that is, CiscoWorks ACL Manager, Cisco IPM, etc.), the higher the requirements. Similarly, the number of simultaneous users will affect these requirements.
These figures assume that Asynchronous Network Interface (ANI) and CiscoWorks RME are installed. Windows disk sizing is for the Windows NTFS File System.
Table 1 Small-Scale Network (<200 devices)—System Recommendations
Windows
P3-1GHz SP
512 MB
1 GB
6 GB
Solaris
SunFire 280R 750MHz SP
512 MB
1 GB
36 GB
Table 2 Medium-Scale Network (200-500 devices)—System Recommendations
Windows
P3-1GHz SP
1 GB
1.5 GB
9 GB
Solaris
SunFire 280R 750MHz SP
1 GB
1.5 GB
36 GB
Table 3 Large-Scale Network (500-1000 devices)—System Recommendations
Windows
P3-1GHz MP
1.5 GB
2 GB
9 GB
Solaris
SunFire 280R 750MHz MP
1.5 GB
2 GB
36 GB
Table 4 Very Large-Scale Network (1000-2000 devices)—System Recommendations
Windows
P3-1.4GHz MP
2 GB
2.5-3 GB
15-20 GB
Solaris
SunFire 280R 900MHz MP
2 GB
2.5-3 GB
36 GB
The following parameters are assumed for the network:
•
•
•
•
•
•
•
Variations in these parameters affect the performance of CiscoWorks, and the server should be sized accordingly. Also refer to the CiscoWorks documentation for information on client and server requirements.
In very large environments, the CiscoWorks applications may have to be spread on multiple servers. If this is the case, the following applications should be considered moved to separate servers:
•
•
•
Note:
Consult with your local Cisco office for the proper design before deploying CiscoWorks in very large-scale environments.
3. Setting Up CiscoWorks Security
After installing CiscoWorks, the first thing that you should do is to configure the security settings of the product.
3.1. Select Login Module
First, you should verify that you are using the correct login module for CiscoWorks. You can do this by selecting the Server Configuration -> Setup -> Security -> Select Login Module menu item. Then you should be presented with a screen that shows which login module is being used, and gives you the option to select an alternative login module.
Select the login module you want and click on the Next button to continue. The full procedure for modifying these settings is not described in this document.
Note:
3.2. Modify Admin Password and Cisco.com Account
The default password for the CiscoWorks admin user is "admin." This should be changed as soon as possible by logging in as the admin user and then selecting the Server Configuration -> Setup -> Security -> Modify My Profile menu item. At the very least, the password should be changed. Add the Cisco.com and proxy information as needed. Next, click on the Modify button to confirm the changes.
3.3. Add Users
Add further users into CiscoWorks as they are needed. Consider creating one user per operator for logging purposes. The menu item for this is Server Configuration -> Setup -> Security -> Add Users. Enter the information required. Make sure the proper roles are selected and click the Add button to confirm.
Tip: Permissions
For information on which operations can be carried out by which roles, select the Server Configuration -> Setup -> Security -> Permissions Report menu item.
Note:
3.4. Schedule Backup
Schedule backup enables you to schedule automatic database backups. Backups can be scheduled on a daily, weekly, or monthly basis. In order to conserve disk space, select how many backup versions or generations should be retained (default is 0 or one retained version). Configure this by selecting Server Configuration -> Administration -> Database Management -> Schedule Backup.
Specify where you want the database dump to be stored, and the number of generations you want.
Tip: Where to Store
You should store the backups on a disk that is backed up to tape on a regular basis.
Note:
Note:
3.5. Create Self-Signed Certificates
CiscoWorks allows you to create self-signed security certificates, which can be used to enable Secure Sockets Layer (SSL) connections between your client browser and management server. This can be done using the Server Configuration -> Administration -> Security Management -> Create Self Signed Certificates menu option.
Note:
Enter the values required for the fields described in Table 5.
Either:
•
or
•
The CiscoWorks server creates the security certificate. The process generates the files given in Table 6.
3.6. Enable or Disable SSL
Select Server Configuration > Administration > Security Management > Enable/Disable SSL from the left pane of the window. The Configure SSL window appears in the right pane.
If SSL is enabled, CiscoWorks displays the Disable button. This will use CiscoWorks in the secure mode with Secure Hypertext Transfer Protocol (HTTPS),
If SSL is disabled, CiscoWorks displays the Enable button (refer to Table 7). This will use CiscoWorks in unsecure mode with Hypertext Transfer Protocol (HTTP).
Click the Enable button to enable SSL.
Note:
To complete the task of enabling SSL:
1.
2.
On Windows 2000 enter:
net stop crmdmgtd
net start crmdmgtd
On Solaris enter
/etc/init.d/dmgtd stop
/etc/init.d/dmgtd start
3.
This can also be done on the command line using the following syntax:
On Solaris:
/opt/CSCOpx/objects/web/bin/ConfigSSL.pl -enable
/opt/CSCOpx/objects/web/bin/ConfigSSL.pl -disable
On Windows:
<INSTALLDIR>\bin\perl.exe <INSTALLDIR>\lib\web\ConfigSSL.pl -enable
<INSTALLDIR>\bin\perl.exe <INSTALLDIR>\lib\web\ConfigSSL.pl -disable
When you restart the CiscoWorks session after enabling SSL, you must enter the URL with the following changes:
•
•
Note:
Note:
4. Automatic Package Download
This section describes how to set up CiscoWorks to download new CiscoView packages as they become available. Furthermore, this section describes the procedure required to install these packages after download.
4.1. Configure Cisco.com Account
The Automatic Package Updater requires Cisco.com access to work. This means that CiscoWorks must be configured with a Cisco.com account to use when downloading new and updated packages. This is configured using the Device Manager -> Administration -> Package Support Updater -> CCO Connection menu item. When this menu item is selected, CiscoWorks should display a configuration page. At the very least you need to specify the Cisco.com login and password to use. If a proxy server is in use, configure the proxy parameters as well. Click on the Apply button to confirm the configuration.
4.2. Schedule Package Downloads
Next, configure the frequency with which CiscoWorks checks for new packages. This is done by using the Device Manager -> Administration -> Package Support Updater -> Schedule Downloads menu item. Here you select how often CiscoWorks should check for updates, what kind of packages to look for, etc., and then download the packages that meet the criteria selected. Configure this section as required. The configuration should be changed to reflect the customer's requirements. After the settings are configured press the Apply button to finalize the configuration.
4.3. Import Downloaded Packages
This point is not a one-time event that is performed right after installation. Rather, it is a recurring operation that is performed regularly. As the scheduled package download retrieves new and updated CiscoView packages, these need to be installed into CiscoView. This is done by selecting the Device Manager -> Administration -> Package Support Updater -> Staging Area Contents menu item. CiscoWorks displays a list of downloaded items. Check the items you want installed and click the Install button to continue the installation. Next, CiscoWorks displays a list of packages to be installed, and asks if you really want to install these packages. Click Yes to finalize the installation of these packages.
Note:
After a little while you should get a message saying that the installation of the selected packages has finished, and that CiscoWorks is restarting the server.
5. Network Discovery
One of the first tasks that should be carried out is discovering the network. This requires installation of the CiscoWorks Campus Manager component. Furthermore, CiscoWorks RME should also be installed to reap the full benefits of the procedures described within. This section describes a set of configuration tasks that should be performed.
5.1. Device and Credential Synchronization
The discovery process can send devices and device information to CiscoWorks RME when devices are discovered. To configure this functionality, select Server Configuration -> Setup -> ANI Server Admin -> Device Synchronization.
Add the host name of the server where CiscoWorks RME is installed. This is normally the same server on which CiscoWorks Campus Manager is installed.
Note:
The Port field contains the port number used to connect to CiscoWorks RME. This is normally the same port used to access the CiscoWorks GUI, that is, port 1741.
Next enter the admin user ID and password in the respective fields.
Tick each checkbox in the "Synchronize to Essentials" section, as well as "Synchronize from Essentials." Because CiscoWorks by default runs a discovery every four hours, this ensures that new devices are added to CiscoWorks RME automatically, as well as sending information to CiscoWorks Campus Manager if something is changed from CiscoWorks RME. Click on the Apply button to save the configuration.
Note:
Note:
5.2. SNMP Settings
Use this section to configure the SNMP community strings that CiscoWorks Campus Manager is to use during the discovery process. These settings are configured under the Server Configuration -> Setup -> ANI Server Admin -> SNMP Settings menu item.
Add subnets or ranges with corresponding community strings as required.
Tip: Wildcards
You can use * (asterisk) to indicate whole subnets such as 192.168.10.* as well as ? (question mark) to indicate individual numbers, such as 1?, which will match any number from 10 to 19. You can also use ranges such as 192.168.10.[10-20], as long as they are enclosed in square brackets. Note that you can use *.*.*.* to represent all networks. Note that multiple instances of *.*.*.* can be specified, but the Multiple wildcards checkbox must be checked for this to take effect. You have to restart the ANI server after this checkbox has been selected.
Note:
When the settings are configured correctly, click the Save button to verify.
5.3. Discovery Schedule
This setting is used to change how often CiscoWorks should perform a network discovery to look for new and updated devices. By default this is done every 4 hours starting at midnight. Depending on the network topology and customer requirements, these settings may need to be changed. Furthermore, CiscoWorks checks device status every 5 minutes by default in CiscoWorks Campus Manager versions up to 3.2, and every 120 minutes by default in Campus Manager 3.3 onward. These settings can be changed by selecting the Server Configuration -> Setup -> ANI Server Admin -> Discovery Schedule menu item. Click the Apply button to store the changes made.
5.4. User and Host Acquisition
This setting changes how often CiscoWorks should poll edge switches to look for connected end-station devices such as PCs and printers. To change it, select the Server Configuration -> Setup -> ANI Server Admin -> User and Host Acquisition menu item.
The Major Acquisition setting determines how often CiscoWorks should scan edge switches for information, whereas the Minor Acquisition setting is used to select how often CiscoWorks should try to confirm that the device is still there.
To get the user ID when a user logs on, the UT.BAT file needs to be installed into the login script. Check the documentation for more information on this.
Click on the Apply button to save the changes made.
Note:
5.5. Discovery Settings
These settings must be changed for the discovery process to run. These settings are found under the Server Configuration -> Setup -> ANI Server Admin -> Discovery Settings menu item. At the very least one device must be added, and more than one device can be added. If more seed devices are required than there are lines for, additional lines can be added by right-clicking on the list and selecting Insert.
CiscoWorks topology discovery works by querying seed devices for information regarding the devices themselves. Next the discovery process queries the devices for Cisco Discovery Protocol neighbor tables to find neighboring devices. The process is then repeated for these devices. Thus, it is vital that SNMP and Cisco Discovery Protocol have been configured on the devices. Note that Cisco Discovery Protocol is a Layer 2 protocol, and as such is blocked by firewalls.
Cisco Discovery Protocol is also blocked by Layer 3 devices. This means that the discovery process stops when it reaches a router. However, this can be circumvented by selecting the Jump Router Boundaries checkbox. This causes CiscoWorks to check each interface on the router for Cisco Discovery Protocol neighbors, thus continuing the discovery process.
By default CiscoWorks tries to do a reverse lookup to find the hostname when it encounters a device. If you do not want this to happen, turn off the Use reverse DNS Lookup checkbox.
It is possible to filter which IP addresses or VTP domains CiscoWorks should or should not discover. This is done by adding them to the filter criteria at the bottom of the screen.
When all settings have been configured, click the Apply button to save them. CiscoWorks asks if you want the discovery process to start immediately. Click Yes or No to select the option you want.
Tip: Monitoring the Discovery
You can monitor the progress of the discovery process by selecting the Server Configuration -> Diagnostics -> Discovery Metrics menu item. Click on the menu item again to update the information. When the discovery is done, click on the item listing the total number of devices discovered to see if there were any devices discovered that CiscoWorks was unable to manage for any reason.
5.6. Topology Group Administration
CiscoWorks Campus Manager can be used to display topology maps of your network. A recent feature addition is the ability to create topology groups, or containers. These are logical groupings of devices based on arbitrary hierarchical structures, such as geographical regions. For example, devices can be organized by country, within each country by state, within each state by city, etc. After the discovery has been performed, this can be configured using the Campus Manager -> Administration -> Topology Groups menu item.
5.7. Configure Path Analysis and User Tracking Scheduling
To configure scheduled jobs for path analysis and user tracking, select the Campus Manager -> Administration -> Job Schedule menu item.
5.7.1. Path Analysis
Included with CiscoWorks Campus Manager is a tool called Path Analysis, which can determine the Layer 2 and 3 path between a pair of devices (or end stations) in your network. To create a scheduled job to test a path between two devices on a regular basis, select the Campus Manager -> Administration -> Job Schedule menu item.
Next, click on the New Job button and enter the required parameters. The "No. of Archives" field specifies the number of versions of the result of this scan that you want to store for historical reasons.
5.7.2. User Tracking
CiscoWorks Campus Manager includes a utility called User Tracking. This tool keeps track of end-user equipment (PCs, printers, etc.), and where this equipment is connected to the network; that is, which switchport has which equipment connected to it. This information is updated regularly (as specified in Section 5.4). To store the User Tracking data to an external file on a regular basis for historical analysis, you need to schedule an export of this data. This is done using the menu item specified previously.
After selecting the menu item, click on the New Job button to create a new schedule. The "No. of Export Archives" field specifies the number of versions of the information that you want to store for historical reasons.
You should create a custom query and a custom layout in the User Tracking application before using this tool, because it requires the name of a predefined query and a predefined layout.
6. Setting Up CiscoWorks Resource Manager Essentials
This section describes how to set up CiscoWorks RME. This part of CiscoWorks is used for configuration management, software image management, and more. All the menu items for configuring CiscoWorks RME are found under the Resource Manager Essentials -> Administration folder.
Note that not every configuration setting is covered, because not all settings are required to make CiscoWorks manage the discovered network.
CiscoWorks can be configured to use the Secure Shell Protocol (SSH) instead of Telnet when talking to devices. However, note that the SSH implementation encrypts SSH packets that should not be encrypted. This can lead to unexpected results when using SSH, especially when the SSH session is closed. There is no workaround other than to not use SSH. However, a patch is available by calling the Cisco Technical Assistance Center (TAC), and referencing bug ID CSCdz03633.
Note:
6.1. System Configuration
This menu item, found under Resource Manager Essentials -> Administration -> System Configuration, is used to change proxy, SNMP, Simple Mail Transfer Protocol (SMTP), and rcp settings. Change these settings as required, and click on the Apply button to save the new settings.
6.2. Job Approval
Both software-management and configuration-management tasks allow you to set up approval checkpoints before a job can be run that will change a configuration or update the software image on a device. This can help increase the security on your network by forcing these types of high-impact jobs to be "approved" before they can be executed. Additionally, other CiscoWorks applications can also take advantage of this feature (for example, CiscoWorks ACL Manager).
To set up job approval, you must first create an approver list, a list of CiscoWorks user accounts that must approve the job before it can be run. This is done by assigning one or more users the approver role when the users are created. Users must have the role of approver to even be considered for an approver list. After you have created at least one approver list, you can enable the job-approval feature for software management, configuration management, or both.
To set up job approval, follow the steps in the next Sections 6.2.1 and 6.2.2.
Note:
6.2.1. Create an Approver List
Select Administration -> Job Approval -> Create Approver List from the Resource Manager Essentials drawer.
You must create at least one approver list before you can enable job approval. Only users who have been assigned the approver role will display in the list of valid user accounts for approval.
6.2.2. Enable Job Approval
Select the Resource Manager Essentials -> Administration -> Job Approval -> Edit Preferences menu item to enable job approval. You can select configuration-management or software-management jobs.
For software management, you can also be specific as to the types of jobs that require approval (new image distribution, undo image distribution, retry image distribution).
6.3. Inventory
Population of the inventory within the Essentials database must be completed before CiscoWorks RME can be used to manage your network. Devices can be neither monitored nor manipulated until they have been added to the inventory. Devices can be added to the inventory in four ways; the first three are directly associated with CiscoWorks RME tasks:
•
•
•
•
For each request to enter a device into the inventory (by any of the methods described), the CiscoWorks Inventory Manager initiates an inventory data collection from the device via SNMP. If the device can be accessed and its Management Information Base (MIB) is recognized by Inventory Manager, data is uploaded from the device and placed in the Managed Devices table in the inventory along with the device and any device attributes received from the enter process. If the device does not respond to the SNMP query or the device type is not supported by the Inventory Manager function, it is placed in the Unmanaged Device table. Because the device is considered unmanaged by CiscoWorks RME, no further queries are directed toward it. The user can delete these devices or resubmit them for inclusion in the inventory.
CiscoWorks Inventory Manager cooperates with other CiscoWorks RME functions needed to perform an initial data collection (for example, CiscoWorks Configuration Manager), telling them that a new managed device exists.
If CiscoWorks Campus Manager has been installed, you can normally skip to Section 6.3.5.
Note:
Note:
6.3.1. Manually Adding Devices
Note:
Adding devices manually is a slow and time-consuming process, but it does allow the user to associate all possible device attributes with the device at inventory submission time. Adding devices to the inventory is an administration task, and hence it is found within the Resource Manager Essentials -> Administration -> Inventory -> Add Devices menu item. Selecting this menu item displays a set of three screens of attributes for a device. In the first screen you must enter (required) either the device IP address or host name in the first field. If you know the serial number under the maintenance contract for this device, you can enter it in the appropriate field. CiscoWorks Inventory Manager, however, attempts to populate this field when performing a MIB read of the device during inventory data collection.
Tip: User Fields
The four User fields are definable by the user. These fields can be useful in creating device views. Example uses of User fields include Device Location, Device Type (core, access, distribution), and so on. After a value has been defined in a field, a dropdown list with potential values is displayed next to the appropriate User field. In CiscoWorks RME 3.5, users have the flexibility to change the User Name column heading to suit their own needs.
The second screen of attributes requires at least the entering of the device read community string. All other fields in the second and third screens are optional; however, entering password information is required for other CiscoWorks RME functions.
When you have finished entering the device attributes, click the Finish button on the third screen. At this time CiscoWorks Inventory Manager attempts to contact the device and place it into the appropriate table in the inventory. Meanwhile, a message is displayed asking if you wish to add more devices or view the status of the inventory submission. Click the corresponding button, depending on whether or not you want to add more devices. If you select to add more devices, you will be taken to the first screen to add another device.
Tip: Changing Information
Attributes can be changed or added any time after the device is in the inventory by using the Change Device Attributes task.
The user can also check device attributes during the add or import process by selecting the Check Device Attributes box. Any attribute (attributes) errors seen at this time are reported on the Add/Import Status Summary screen in the Device Attribute Errors field.
Note:
6.3.2. Importing Devices from a File
Note:
Importing devices from a file can be useful if you do not have a NMS to import from or you do not want to add all your devices manually. Like the manual add of devices to the inventory, the file-import process allows you to associate all device attributes with a device at import time. CiscoWorks Inventory Manager uses two different files to import data from a file: a CSV and a DIF file. Examples of these two files can be found at <Install Directory>/CSCOpx/example/import.
Note:
After creating your import file, import it by selecting the task: Resource Manager Essentials -> Administration -> Inventory -> Import From File. Enter the location and name of the file and click on the Next button. Before proceeding with the import of devices, CiscoWorks Inventory Manager asks you for the Reconciliation Criteria in case any device being imported already exists in the inventory. In other words, which data should Inventory Manager use if conflicts exist—the data currently in the database or the data being imported? It also gives you the option of deciding after the file is imported on a device-by-device bases. We will look at the Reconciliation Criteria screens after first looking at the import from NMSs.
After selecting the reconciliation criteria, the CiscoWorks Inventory Manager starts contacting all the devices in the Import file and placing them in the appropriate table within the inventory. Meanwhile, the Add/Import Status screen is displayed (this screen is discussed in more detail later). First we look at the NMS import process.
Tip: Exporting Inventory Information to a Text File
You can also export the inventory database to a CSV or DIF text file by selecting Resource Manager Essentials > Administration > Inventory > Export to File. This data is exported to a directory with administrator and root privileges only because it contains password information in plaintext. You can take advantage of this feature by exporting the inventory, making changes to the device attributes, and then importing the file back to the inventory.
6.3.3. Importing from Local or Remote NMS
Note:
If your network is large and you have a third-party NMS that has already discovered the network devices, it may be best to import the devices. Check with the release notes or the online help for importing from a NMS to determine compatibility between versions.
To import devices from a supported third-party NMS, do the following:
1.
2.
Note: If the NMS is installed in a nondefault location, you should select the Customize checkbox and enter the correct path information.
3.
4.
5.
6.3.4. Importing Devices from Proxy Server (Auto Update Server)
You can populate your CiscoWorks RME server with Cisco PIX® Firewall device data by importing the data from a supported proxy server such as Auto Update Server.
1.
2.
3.
4.
5.
6.
7.
If you click Yes, CiscoWorks RME manages the old devices through the new proxy server and the new devices are imported into the Essentials database. This may take a few minutes.
If you click No, CiscoWorks RME imports the devices of the new proxy server into its database. If some of the old devices appear in this import, they are moved to the managed state. The remaining devices continue to be suspended.
The Add/Import Status Summary dialog box displays the new information.
Note:
6.3.5. Check Add/Import Summary
When devices are initially imported, they are added to the pending category until the CiscoWorks Inventory Manager has processed them. After devices are processed, they are added either to the Managed table or to one of the Unmanaged tables. You can check the progress on this by selecting the Resource Manager Essentials -> Administration -> Inventory -> Import Status menu item. Note that this screen does not automatically update. Continue to click Update until no devices are left pending. If the import was successful, all devices will be listed under Managed. You should resolve problems with any devices listed under the following unmanaged categories:
•
•
•
•
Note:
6.3.6. Check Device Attributes
In order for all CiscoWorks RME functions to work properly, it is imperative that the attributes (community strings and passwords) of each device are placed in the inventory with the device. The Resource Manager Essentials -> Administration -> Inventory -> Check Device Attributes task uses all attributes to access the device. Any failures or lack of attribute data is reported in the View Check Attributes report.
Note:
6.3.7. Change Device Attributes
Use the Resource Manager Essentials -> Administration -> Inventory -> Change Device Attributes task to change any device or group of devices attributes. You can also change a specific devices attribute directly from the View Device Attributes report.
Before continuing, make sure all device attributes are correct.
6.3.8. Removing Devices from the CiscoWorks RME Inventory
To remove a device from the CiscoWorks RME inventory database, do the following:
1.
2.
Note that if CiscoWorks Campus Manager runs network discovery regularly, the deleted devices are added again if CiscoWorks Campus Manager finds them.
Note:
6.3.9. Schedule Collection
The first way to perform automatic updates of the inventory is by scheduling a complete inventory collection for all managed devices and updating the inventory database if changes have occurred, at a specified time each day or week. This process collects all the latest MIB information for each managed device, including chassis details, hardware and software versions, Flash memory size, and power-supply information, even if the information has not changed on the device. If a change is detected on the device, a change record is also created.
Note:
It is recommended that you run Schedule Collection at least once a week to ensure that information in the inventory database reflects up-to-date information about network devices. (Collecting all device inventory information can consume a lot of bandwidth.) You should also set the collection schedule to coincide with any reporting cycle. For example, if you produce inventory reports for management every Friday, you should schedule inventory collection to occur Thursday evening or early Friday morning.
To detect major changes to devices without significantly impacting the network, use Inventory Poller, which is discussed in more detail in the next section.
To set Schedule Collection, do the following:
1.
2.
6.3.10. Inventory Poller
The second method to automatically update the inventory for all managed devices is to schedule Inventory Poller, which periodically polls devices for any change. Instead of automatically collecting all information for each managed device, it polls devices to determine if a significant change has occurred, such as a chassis change or a reload. If this type of change is detected, the Inventory Poller then initiates a full inventory collection of all MIB information for that device only.
It is recommended that you use Inventory Poller more frequently to identify inventory changes on the network—as opposed to simply collecting all device information—because it uses fewer resources and will have less impact on the network and network devices. In addition, if it is run more frequently, changes will be detected closer to the time that they actually occur. Schedule Collection should be run less frequently, at night or when network activity is low, to pick up minor changes that are not detected by Inventory Poller.
To set Inventory Poller, do the following:
1.
