Effective network management is critical in today's networks, helping enterprises deploy and manage solutions. With increasing reliance on networks to increase productivity, enterprises are confronted with an ever growing network size. Such increase in the number of network elements creates a challenge for network administrators. How does an enterprise effectively deploy and maintain its network devices?
CiscoWorks LAN Management Solution (LMS) provides the integrated management tools needed to simplify the configuration, administration, monitoring, and troubleshooting of Cisco® networks. LMS provides IT organizations an integrated system for sharing device information across management applications, automation of device management tasks, visibility into the health and capability of the network, and identification and localization of network trouble. By using common centralized systems and network-inventory knowledge, CiscoWorks LMS delivers a unique platform of cross-functional management capabilities that reduces network administration overhead and provides upper-layer systems integration.
This deployment guide considers scenarios where all applications reside on a single server and provides tips and suggestions on configuring the server and getting the basic functions of applications running. Discussions related to multiserver deployment can be found in the LMS 3.2 Large Scale Deployment Guide, available at http://www.cisco.com/en/US/products/sw/cscowork/ps2425/prod_white_papers_list.html.
Tip: In short, the decision on whether to use single or multiple LMS servers to manage the network depends on:
• How many devices are managed by the LMS server. In LMS 3.2, one single server can manage up to 5000 devices per server.
• How the LMS applications are used. For example, if DFM is used extensively to poll the devices, it is recommended to dedicate a server to DFM. Refer to the scalibility numbers and server planning details in the Large Scale Deployment Guide.
Note: There are release notes for the individual components but not at the bundle level.
LMS 3.2 Applications
LMS 3.2 is the latest version of LMS, released in June 2009. LMS itself is a solution bundle that consists of varoius integrated applications. Figure 1 lists all the applications in LMS 3.2.
Figure 1. LMS 3.2 Solution Bundle
• Common Services 3.2
Common Services provides a set of shared application services that are used by all LMS applications. It runs the database server, the web server, the job scheduler, the device discovery engine, and other backend processes to support other applications.
Common Services 3.2 includes CiscoView 6.1.9, Integration Utility 1.9, LMS Portal 1.2, and CiscoWorks Assistant (CWA) 1.2.
– LMS Portal is the GUI front of the CiscoWorks server. It gives the user the ability to customize information regardless of applications and to view frequently used information in a common place. With LMS Portal, users do not need to navigate through several pages to obtain the information they need -- instead, users can display application-related information as portlets and customize the homepage to have all information on a single screen from all applications.
– CiscoView provides a "front panel" graphical display of Cisco devices, allowing users to easily interact with device components to change configuration parameters and monitor statistics.
– Integration Utility is an integration module that supports third-party network management systems, such as HP OpenView NNM (Network Node Manager).
– CiscoWorks Assistant 1.2 has the following features:
Workflows to improve usability of LMS applications
Help to solve real business problems and overcome network inconsistencies
• Resource Manager Essentials (RME) 4.3
To support life cycle management, RME provides the ability to manage device inventory and audit changes, configuration files, software images -- as well as syslog analysis.
• Campus Manager (CM) 5.2
Campus Manager provides the ability to visualize network topology, manage VLANs, detect/fix network discrepancies, and display end-host/IP phone user tracking information.
• Device Fault Manager 3.2
Device Fault Manager provides the ability to monitor device faults in real time and determine the root cause by correlating device-level fault conditions. DFM can issue notifications of critical network conditions by email or pager. Fault history lets the user store and access historical information about alerts and faults that are detected and processed by DFM.
• Internetwork Performance Monitor (IPM) 4.2
Internetwork Performance Monitor measures network performance based on the synthetic traffic generation technology within Cisco IOS®Software, which is known as Cisco IOS IP SLA (Service Level Agreement). Using synthetic traffic by IPM gives the network manager a high degree of flexibility in selecting the endpoints in a network between which network performance will be measured. This flexibility makes IPM a highly effective performance troubleshooting tool.
• Virtual Network Manager (VNM)
VNM is an enterprise solution that allows administrators to carry out end-to-end Virtual Route Forwarding (VRF) configuration and to edit, extend, and delete VRF configuration details. It also collects VRF details of the VRF configured devices and generates reports to help you analyze VRF configurations on your network.
EnergyWise is a comprehensive program for power management utilizing the Cisco network as the power management platform. EnergyWise will allow customers to monitor, change, and facilitate efficient operation and reduce power consumption across the enterprise.
Currently the focus of the EnergyWise initiative is on current Catalyst® switches and future next-generation switches. Targeted EnergyWise clients are IP Phones, IP Cameras, IP Gateway video encoders, Wireless Access Points, Wireless Access Controllers, PC Laptops/Servers, PD Switch (C2960).
CiscoWorks LMS 3.2 will have an EnergyWise drop-in that provides the manageability support for EnergyWise covering provisioning, monitoring, reporting, and troubleshooting. The EnergyWise drop-in will be released as an update after the official release of LMS 3.2.
Add-on application:
• Health Utilization Monitor (HUM) 1.2
CiscoWorks Health and Utilization Monitor is an add-on application pre-integrated into LMS. HUM is a Simple Network Management Protocol (SNMP)-based MIB polling application that monitors network elements (such as CPU, memory, interfaces/ports, and links) for their availability and utilization levels and provides historical reporting.
Note: Refer to Appendix B for the version matrix of LMS bundles. To understand the new and legacy features introduced in each version, refer to the Installation Guide and the individual application user guides.
LMS Workflow
The flow chart in Figure 2 summarizes the device and LMS setup workflow, which covers the whole lifecycle of LMS server from initial setup to ongoing operations. The following chapters illustrate in detail each of the steps mentioned in this workflow.
Figure 2. Summary of Device and LMS Setup Workflow
Step 1. The first step in the workflow is to turn on Cisco Discovery Protocol (CDP), SNMP, and other credentials such as Telnet username/password on the devices so that the devices can be discovered and managed by CiscoWorks.
Tools used: Command-line interface (CLI) tools such as console connection, Telnet, Secure Shell (SSH) Protocol, and so on.
Step 2. The LMS server is installed, and initial setup was done on the server. This includes setting up the dashboard for the user interface, configuring basic server settings, automatically discovering the devices or manually adding devices, allocating the devices to be managed by the applications, integrating with Cisco Secure Access Control Server (ACS), and so on.
Tools used: LMS Portal, CiscoWorks Assistant, Common Services, and Setup Center.
Step 3. Once the Common Services Device and Credentials Repository (DCR) and the individual device databases residing on different applications are populated, administrators can start to perform their daily management tasks including:
• Device management: RME, CiscoView, and Device Center
• Network management: Campus Manager
• Fault management: Device Fault Manager
• Performance management : Internetwork Performance Monitor and Health Utilization Monitor
Besides these steps, there is also ongoing work for the maintenance and administration of the LMS server. The administrator can backup and restore data on the LMS server. LMS also offers a rich set of command-line tools to extract data from DCR and other individual applications. In LMS 3.2, we also support direct Open Database Connectivity (ODBC) access to database views.
2. Setting up Devices on the Network
LAN Management Solution 3.2 helps in managing Cisco devices on the network. Before LMS 3.2 can function properly, the network devices that LMS interfaces with must be set up correctly in order to communicate with the CiscoWorks server. For example, the SNMP community strings must match between the device and the CiscoWorks server. The information provided in this chapter is a general description of the means and procedures recommended to make sure that the network devices are set up properly.
Note: This chapter provides a great deal of information on the device configuration procedures required to manage devices using CiscoWorks LAN Management Solution. Keep in mind that this document is not intended to be a comprehensive configuration guide for LMS 3.2. For additional LMS configuration details, please contact a Cisco Certified network engineer (if possible) and refer to pertinent documents that are posted on Cisco.com.
Prior to LMS deployment, in the case of Cisco IOS and Catalyst Operating System (CatOS) devices, all configuration changes must be saved to nonvolatile memory (NVRAM) using the following commands:
write memory
or
copy running-config startup-config
Please note that the above command is provided to save pre-LMS deployment configuration changes. After LMS is deployed, configuration changes will be saved automatically where appropriate and no user intervention is required.
Also note that newer versions of CatOS devices have separate running and startup configurations.
Generic Configuration of Devices
This section describes the generic elements in the device configuration.
System Name
Each Cisco IOS device in the network must have a unique system name (sysname) in order to be managed. The system name is also populated in the Cisco Discovery Protocol table. If there are duplicate system names on the network, LMS will discover only one device by that name on the network. On Cisco IOS devices, the domain name also affects the system name.
You can set up the system name using the following commands:
For Cisco IOS devices:
hostname <name>
For Cisco CatOS devices:
set system name <name>
Domain Name
You can set a domain name on a Cisco IOS or CatOS device. To set up the domain name, use the following commands.
For Cisco IOS devices:
ip domain-name <name>
For Cisco CatOS devices:
set system name <name with domain name>
Command-Line Prompts
To utilize the NetConfig capability to execute batch changes on devices, Cisco device command-line prompts should meet the requirements described in this section.
Note: Customized prompts should also fulfill these requirements.
Cisco IOS devices:
• Login prompt should end with an angle bracket (>).
For example:Cisco>
• Enable prompt should end with a pound sign (#).
For example:Cisco#
Cisco CatOS devices:
• Enable prompt must end with (enable).
For example:Cisco(enable)
Configuring Communication Protocols
LMS uses various protocols to communicate with the devices. These protocols must be configured properly on both the LMS server and devices so that they can communicate to each other. See Table 1 for a list of device credentials for LMS applications.
1Configuration download also uses TFTP. Hence, SNMP Read/Write credentials are required.
2The file vlan.dat can be fetched only if the Telnet password and Enable password are supplied.
3Required in the case of a few devices such as PIX® devices, Cisco 2950 Series Switches.
SNMP Settings
LMS supports SNMPv1/v2c, and SNMPv3 with both AuthNoPriv mode and AuthPriv. SNMPv3 AuthPriv is a new feature introduced since LMS 3.0.1.
Note: SNMPv3 AuthPriv support for DFM is added in a drop-in over LMS 3.1 for 100, 300, and 1500 device counts.
SNMP settings include both the read-only community string and the rewritable community string. The read-only community string is used to perform "snmp get" operations on MIB objects to collect information such as inventory, interface utilization, and so on. The rewritable community string is used in various cases. For example, the RW string is used in RME for:
• Configuration deployment
• Software Image Management (SWIM)
CiscoWorks can collect device configurations by either SNMP-write, which triggers a TFTP, or by grabbing output from a CLI 'show running' c(requiring Telnet or SSH access to the device).
In image deployment the RW community string is used to trigger the TFTP connection and also for the system reboot after the image is downloaded. The RW string is also used in Campus Manager for configuration changes such as fixing discrepancies.
Enabling SNMPv1/v2c on Cisco IOS devices:
To enable SNMPv1/v2c on Cisco IOS devices, follow these steps:
snmp-server community <read-community-string> ro
snmp-server community <write-community-string> rw
Enabling SNMPv1/v2c on Cisco CatOS devices:
To enable SNMPv1/v2c on Cisco CatOS devices, follow these steps:
set snmp community read-only <read-community-string>
set snmp community read-write <write-community-string>
The community strings configured on the devices should match the community strings entered in the DCR component in LMS.
Enabling SNMPv3 on Cisco IOS devices:
To enable SNMPv3 on Cisco IOS devices, follow these steps:
• Create a user and authentication protocol to be used
set snmp user cmtester authentication md5 cisco123
• Create a group and associate the user with it
set snmp group cmtest user cmtester security-model v3 nonvolatile
Enabling traps in CatOS devices to be sent to a particular host:
To enable traps in Catalyst OS devices to be sent to a particular host, enter this command:
set snmp trap 192.168.124.24 public
Enabling traps in Cisco IOS devices to be sent to a particular host using SNMPv2c:
To enable traps in Cisco IOS devices to be sent to a particular host using SNMPv2c, enter this command:
snmp-server host 192.168.124.24 traps version 2c public
In the above examples for enabling traps, the public community string is to help selective processing of traps on the trap receiving side.
Prerequisites for SNMPv3 Support on Spanning Tree Protocol
For using various spanning tree features in devices running SNMPv3, you are required to make specific configurations on the devices for context name support. The additional command that needs to be configured for the three types of Spanning Tree Protocol are:
Note: Context support is not available on XL Series and 2950 Switches, and Campus Manager will not fully work with them when they are configured to use SNMPv3.
After a software image distribution operation using Resource Manager Essentials is completed, RME will reload the device if specified in the image distribution job. RME will be able to reload any device (Cisco IOS or CatOS) only if an SNMP manager (in this case RME) is allowed to reset the agent.
The following command is needed on Cisco IOS devices only:
snmp-server system-shutdown
Telnet/SSH
Telnet is one of the basic protocols that can be used by RME for configuration management. You can enable Telnet using the following commands.
To enable Telnet on Cisco IOS devices and CatOS devices, enter these commands:
line vty 0 4
password <password>
transport input telnet
Note: More than four VTY lines can be selected for login.
Different authentication on different VTY lines is not supported.
SSH provides for a secure communication with the device.
Cisco IOS Software
The following example configures SSH control parameters on a router running Cisco IOS Software:
Router> config terminal
Router (config)# hostname hostname <the name of the router>
Router (config)# ip domain-name domainname <a domain that the router services>
Note: For greater access control and logging facilities, use TACACS. SSH configuration requires the domain name to be configured.
Remote Copy Protocol
Remote Copy Protocol (RCP) is one of the protocols that can be used by RME for configuration management and software image management. For LMS to be able to provide configuration and software management using RCP, it must be enabled on the devices.
RCP can be enabled only on devices running Cisco IOS Software using the following sample commands:
username cwuser password 7 000C1C0A05
ip rcmd rcp-enable
ip rcmd remote-host cwuser 172.17.246.221 cwuser enable
ip rcmd remote-username cwuser
Note: The value of <remote-username> and <local-username> entered in the device should match the "RCP User" value provided in the LMS server. The default value is cwuser. This value can be reset by traversing through the following user interface links in LMS server: Common ServicesàServeràAdminàSystem Preferences. See Figure 3.
Figure 3. System Preferences
Secure Copy Protocol
The Secure Copy Protocol (SCP) feature was introduced in Cisco IOS 12.2(2)T.
To enable and configure a Cisco router for SCP server-side functionality, perform the steps in Table 2.
Table 2. SCP Configuration
Command
Purpose
Step 1
enable
Enables privileged EXEC mode.Enter your password if prompted.
Step 2
Router# configure terminal
Enters global configuration mode.
Step 3
Router (config)# aaa new-model
Sets authentication, authorization, and accounting (AAA)at login.
Step 4
Router (config)# aaa authentication login default group tacacs+
Enables the AAA access control system. Complete syntax: aaa authentication login {default |list-name} method1 [method2...]
Step 5
Router (config)# aaa authorization exec default group tacacs+
Sets parameters that restrict user access to a network. The exec keyword runs authorization to determine if the user is allowed to run an EXEC shell; therefore, you must use it when you configure SCP.
Establishes a username-based authentication system. You may skip this step if a network-based authentication mechanism -- such as TACACS+ or RADIUS -- has been configured.
The Cisco IOS HTTP server provides authentication, but not encryption, for client connections. The data that the client and server transmit to each other is not encrypted. This leaves communication between clients and servers vulnerable to interception and attack.
Use the following command to enable HTTP mode:
ip http server
The Secure HTTP (HTTPS) feature provides the capability to connect to the Cisco IOS HTTPS server securely. It uses Secure Sockets Layer (SSL)1 and Transport Layer Security (TLS) to provide device authentication and data encryption.
Cisco Common Services uses both Layer 2 (Cisco Discovery Protocol) and Layer 3 (Border Gateway Protocol [BGP], Open Shortest Path First [OSPF], Address Resolution Protocol [ARP], and routing tables) to discover devices. Cisco Discovery Protocol is the default protocol to discover Cisco devices on the network. Cisco Discovery Protocol is a Cisco proprietary Layer 2 protocol that is media and protocol independent and runs on all Cisco manufactured equipment. A Cisco device enabled with Cisco Discovery Protocol sends out periodic interface updates to a multicast address in order to make itself known to neighbors. Since it is a Layer 2 protocol, these packets (frames) are not routed.
Enabling Cisco Discovery Protocol on devices allows Common Services to learn information about neighboring devices and to send SNMP queries to those devices.
Enable/Disable Cisco Discovery Protocol on Cisco IOS devices:
Cisco Discovery Protocol is enabled on Cisco IOS devices by default. To manually enable Cisco Discovery Protocol capability on Cisco IOS devices use the following commands.
To enable Cisco Discovery Protocol globally:
cdp run
To enable Cisco Discovery Protocol on specific interfaces only:
cdp enable
Use the no command to disable Cisco Discovery Protocol capability on Cisco IOS devices.
Enable/Disable Cisco Discovery Protocol on Cisco CatOS devices:
Cisco Discovery Protocol is enabled on Cisco CatOS devices by default. To enable Cisco Discovery Protocol capability manually on CatOS devices use the following commands:
To enable Cisco Discovery Protocol globally:
set cdp enable
To enable Cisco Discovery Protocol on specific ports only:
set cdp enable [mod/port]
Use the set cdp disable command to disable Cisco Discovery Protocol on CatOS devices.
Do not run Cisco Discovery Protocol on links that don't need to be discovered by Campus Manager, for example, connection to the Internet and end host connection ports on access switches.
To protect from Cisco Discovery Protocoldenial of service (DoS) attacks, do not enable Cisco Discovery Protocol on links that are connected to non Cisco devices.
Note: Certain nonCisco devices support Cisco Discovery Protocol. If you enable Cisco Discovery Protocol on the Cisco devices connected to nonCisco devices, they will appear on the Campus map.
For related information, please refer to the following URL for how to discover devices using LMS.
Syslog messages can be enabled on Cisco devices to fully use the capability of LMS, especially RME. RME has a built-in syslog receiver/analyzer, and it can invoke automated actions based on the content of the syslog message.
Cisco IOS Devices
Enable Syslog messages on IOS devices from global configuration mode:
logging on
logging < server-ip-address>
logging facility local7
logging trap <logging-level>
For example,
logging 10.1.1.1
logging on
logging facility local7
logging trap warnings
Note: To limit the number of messages sent to the syslog servers, use the logging trap configuration command above.
Catalyst OS Devices
Enable Syslog messages on CatOS devices:
set logging server enable
set logging server <server-ip-address>
set logging level all <logging-level> default
The <server-ip-address> is the IP address of the LMS server. In case of multiple servers the server IP address entered here is the address of the RME server. In the case of remote Syslog Analyzer and Collector, this parameter is the IP address of the remote Syslog Analyzer and Collector.
A better way to turn on syslog on devices is to use the RME NetConfig tool. With NetConfig users can create a job to deploy syslog configuration commands to multiple devices at the same time. NetConfig will be discussed in following section, but Figure 4 shows what an example syslog configuration will look like.
Figure 4. Turn on Syslog Using NetConfig
Protocol Setup on the LMS Server
Note: The settings described in this section will be finished after the LMS server is installed.
One of the most important areas of setup is the RME protocol setup. RME uses various protocols for configuration and software management. Network administrators can assign the protocols to be used in RME for configuration management and software management.
Configuration Management
You can set the protocols and order for configuration management applications such as Archive Management, Config Editor, and NetConfig jobs to download configurations and to fetch configurations. The available protocols are Telnet, Trivial File Transport Protocol (TFTP), RCP, SSH (Secure Shell), SCP, and HTTPS.
To setup protocol ordering for configuration management, go to Resource Manager EssentialsàAdministrationàConfig Mgmt.
Figure 5. RME Transport Protocol Settings
As in the Figure 5, for Config Fetch we use the SSH and TFTP protocols. LMS will first try SSH. If SSH does not work after three retries (not customizable) and timeouts (customizable, see below), LMS will fall back to TFTP, the next protocol on the list.
For secure communication between the server and device use SSH.
Retries and Timeouts
File transfer protocols like RCP and SCP use Telnet and SSH as underlying transport protocols.
From RMEàAdminàSystem PreferencesàRME Device Attributes, we have an option to set timeout for SNMP, Telnet, and TFTP. See Table 3 and Figure 6.
Table 3. Protocol Timeout/Retry Settings
HTTPS
-
Single attempt with primary credentials (default); if failed, one more attempt with secondary credentials (only if administrator settings are enabled for fallback)
TFTP
5 seconds (default)
2 (default)
RCP
36 seconds (default)
Single attempt (no retries)
SNMP
2 seconds (default)
2 (default)
SCP
36 seconds (default)
3 attempts with primary credentials (default); if failed, 3 more attempts with secondary credentials (only if administrator settings enabled for fallback)
Protocols
Timeout
Retries
Telnet
36 seconds (default)
SSH
36 seconds (default)
Note: Telnet is retried three times by default and cannot be changed.
Figure 6. Protocol Options
RME Secondary Credentials
The RME server polls and receives two types of credentials from each device and populates the DCR.These credentials are:
• Primary credentials
• Secondary credentials
RME uses either the primary or secondary credentials to access the devices using the following protocols:
• Telnet
• SSH
The RME server first uses the primary credentials to access the device. The primary credentials are tried out three times, and on failure the secondary credentials are tried out three times. Secondary credentials are used as a fallback mechanism in RME 4.3 for connecting to devices. See Figure 7.
For instance, if the AAA server is down, accessing devices using their primary credentials will lead to failure.
You can add or edit the secondary credentials information through the DCR page available in CiscoWorks Common Services if the secondary credentials information is not available for a device.
Similarly, software management attempts downloading the software images based on the protocol order specified. While downloading the images, software management uses the first protocol in the list. If the first protocol in the list fails, these jobs use the second protocol and so on, until software management finds a transport protocol for downloading the images. The supported protocols are RCP, TFTP, SCP, and HTTP.
In the View/Edit Preferences dialog box (Resource Manager EssentialsàAdministrationàSoftware MgmtàView/Edit Preferences) you can define the protocol order that software management has to use for software image downloads. Use the Add and Remove buttons for selecting the protocol order. See Figure 8.
Figure 8. Software Image Management Options
3. Cisco LAN Management Solution 3.2 Installation
Cisco LAN Management Solution installation is supported on both the Windows and Solaris operating systems.
Single Installation Experience
From LMS 3.0, the installation framework is enhanced to support installation of all LMS applications in a single package. You can install or upgrade the LMS applications from the single installation packaged in the LMS 3.2 DVD. Because everything is packaged in one bundle, customers do not need to worry about the sequencing order of installing the various components. Compared to the installation experience of previous LMS versions, the installation of LMS 3.x on Windows and Solaris is much easier. The installation will finish in one coordinated effort, smoothly.
Checklist before Installation
Before starting the installation, we recommend that you:
• Make sure your server hardware and software meet the minimum requirements to install the LMS server. The requirements vary according to how many devices you want to manage, how many applications you are installing, how heavily you are using the applications, any need to use a virtual machine, and so on. Check out the "System Requirements" section for more details.
• Back up your database if you have a previous version of LMS running. It is recommended to store backups on a separate partition or preferably on a separate disk. Backup partitions need to be large enough to store all application databases (for instance, RME, Campus Manager, DFM, and so on) as well as device configurations, software images, and user accounts. The backup partition should allow for multiple revisions. It is recommended to verify all backups that may be needed in the future. Please refer to the document Data Migration Guide of LMS3.0 available on the installation DVD.
• Enable Domain Name System (DNS) on the server so the device names can be resolved against IP addresses. If DNS is not present, create a local hosts file to help resolve the device names.
We recommend that before installing the LMS 3.2 product, you register the product and receive a permanent license.
Licensing Process
To license your product, follow these steps:
Step 4. Register the LMS product with Cisco.com to get your license file. If you are a registered user of Cisco.com, get your license file from http://www.cisco.com/go/license.
Logging into Cisco.com allows your Cisco user profile information to auto populate several product registration fields. Please note that the user authentication information is case sensitive.
Step 5. After you install LMS 3.2, copy the new license file to the CiscoWorks Common Services server into a directory with read permissions for the user name casuser or the user group casusers, such as .\NMSROOT (/opt/CSCopx) on Solaris, C:\program files\CSCopx on Windows.
Note: Do not save the license file on your desktop. casuser does not have read permission for the desktop folder. Even if you give casuser read permission to the license file residing on your desktop, casuser still cannot access the file, and therefore the license file cannot be verified. You must give read permission to the folder in which the license file is located.
Step 6. Install the license file:
If you have obtained the LMS license before installation:
c. Select the first LMS application you wish to install (ideally Common Services 3.1), and when prompted:
– On Windows, select the first option button and click Browse and use the File browse window to locate the license file directory.
– On Solaris, select L for License File after you accept the licensing agreement and continue installing the application.
d. Click Next to install the license file.
If you want to convert an evaluation copy to a licensed copy:
Go to the CiscoWorks homepage and select Common ServicesàServeràAdminàLicensing. The License Administration page appears. Enter the path to the new license file in the License field, or click Browse to locate the license file that you copied to the server in Step 2.
The system verifies whether the license file is valid, and updates the license.
The updated licensing information appears in the License Information page.
If you encounter errors, repeat the steps to license your product.
Note: The license file obtained is platform independent and thus can be used in both Windows as well as Solaris operating systems.
SKUs of LMS 3.2
The licenses of LMS 3.2 are based on how many devices managed. However, for Internetwork Performance Monitor, the license is based on the number of devices and the number of collectors.
You can select any one of the following four licenses of LMS 3.2:
• CWLMS-3.2-100-K9
Allows you to manage the following in each application:
– CiscoWorks RME: 100 devices
– CiscoWorks Campus Manager: 100 devices
– CiscoWorks DFM: 100 devices
– CiscoWorks IPM: 100 devices and 300 collectors
• CWLMS-3.2-300-K9
Allows you to manage the following in each application:
– CiscoWorks RME: 300 devices
– CiscoWorks Campus Manager: 300 devices
– CiscoWorks DFM: 300 devices
– CiscoWorks IPM: 300 devices and 1000 collectors
• CWLMS-3.2-1.5K-K9
Allows you to manage the following in each application:
– CiscoWorks RME: 1500 devices
– CiscoWorks Campus Manager : 1500 devices
– CiscoWorks DFM: 1500 devices
– CiscoWorks IPM: 1500 devices and 1500 collectors
• CWLMS-3.2-5K-K9
Allows you to manage the following in each application:
Note: The 10,000 SKU has not been tested at the bundle level, that is, RME and 5000 devices in all other applications in a single server. It can be only a multi-server deployment.
New Installation Instruction for LMS 3.2
Thanks to the single-package installation design, the LMS installation programs on both Windows and Solaris are user friendly and fail-proof. For Windows-based installations (Figure 9), follow the interactive instructions on executing setup.exe. Installation on Solaris may need more work since various patches will be needed before installing LMS. Please follow the interactive instructions once you execute setup.sh.
Figure 9. LMS Installation on Windows
For step-by-step installation instructions, please refer to the white paper Installing and Getting Started with LMS 3.2 on the installation DVD.
Note: Choose "Custom Installation" or "Typical Installation" with "Show Details" option enabled, so you can get the database password. The password may be needed if you want to develop applications to access the LMS database directly.
Upgrade and Migration from Legacy LMS Versions
Direct upgrade from LMS 2.5.1 and LMS 2.6 are supported (make sure the hardware/software requirements are met). Remote upgrade or migration to LMS 3.2 is supported from LMS 2.2, LMS 2.5, LMS 2.5.1, and LMS 2.6.
For more information on upgrade and migration, see Installing and Getting Started with CiscoWorks LAN Management Solution 3.2 (Maintenance Kit) and Data Migration Guide for CiscoWorks LAN Management Solution 3.2 on the installation DVD.
Note: For customers still running LMS 2.2 or earlier, it is recommended to get a new server and perform a fresh installation.
Installation Log
The installation log exhaustively logs operations performed during the installation process. In case the installation is unsuccessful or problematic, you can review the installation log for error messages, if any.
• Solaris
In Solaris, the installation log is located at /var/tmp/Ciscoworks_install_YYYYMMDD_hhmmss.log for LMS 3.2 installation, where YYYYMMDD denotes the year, month, and date of installation and hhmmss denotes the hours, minutes, and seconds of installation.For example:/var/tmp/Ciscoworks_install_20060721_182 205.log
• Windows
In Windows, the installation log is located in the root directory of the drive where the operating system is installed. Each installation creates a new log file.
For LMS 3.2, the installation log file is C:\Ciscoworks_install_YYYYMMDD_hhmmss.log, where YYYYMMDD denotes the year, month, and date of installation and hhmmss denotes the hours, minutes, and seconds of installation.
For example: C:\Ciscoworks_install_20060721_182205.log
Verifying the LMS 3.2 Installation
After you install CiscoWorks LMS 3.2 on Windows, you must verify the installation. To do this:
Launch CiscoWorks: http://server_name:1741
where server_name is the name of the CiscoWorks server and 1741 is the TCP port used by the CiscoWorks server.
In normal mode (HTTP), the default TCP port for the CiscoWorks server is 1741. When SSL (HHTPS) is enabled, the default TCP port for the CiscoWorks server is 443.
You can change the HTTPS port number of the CiscoWorks server during the installation. See Installing and Getting Started with LAN Management Solution 3.2 for more information.
Select Common ServicesàSoftware CenteràSoftware Update.
The Software Updates window appears. The entries shown in Figure 10 appear in the Products Installed table for each application that you have installed.
Figure 10. Installed Components
Third-Party Tools and Software Changes
LMS supports HP OpenView 7.5.x and IBM NetView 7.1.x. For information on how to integrate with HP OpenView or NetView, check out the user guide of Integration Utility included in the DVD.
On the client side, Firefox 3.0 and Internet Explorer 7.0 browsers are supported in this release.
Post installation Tasks
The first step after installing the products is to check for any updates for service packs. Service packs can be downloaded from either Cisco.com or as a software update (accessed from Common ServicesàSoftware CenteràSoftware Update).
Note: There is a link on LMS Portal for the latest announcements regarding software update and related topics.
Recommendations for Installation of LMS 3.0 Applications
Here are a few caveats for the installation:
• LMS Portal 1.2 and CiscoWorks Assistant 1.2 will be selected by default along with Common Services 3.3.
• Common Services 3.3, LMS Portal 1.2, and CiscoWorks Assistant 1.2 must be installed and uninstalled together.
• Integration Utility (NMIM) 1.9 can be installed independently without installing the default applications Common Services 3.3, LMS Portal 1.2, and CiscoWorks Assistant 1.2.
• Applications can be selected simultaneously for a reinstallation during new or upgrade install of LMS 3.2.
Ports Used by LMS Applications
Make sure the ports listed in Table 4 are open on the CiscoWorks server, or are not used by other applications.
Table 4. LMS Application Port Usage
Protocol
Port Number
Service Name
Applications
Direction
(of Establishment) of Connection
TCP
49
TACACS+ and ACS
CiscoWorks Common Services, RME, Campus Manager, DFM, and IPM
Server to ACS
TCP
25
Simple Mail Transfer Protocol (SMTP)
CiscoWorks Common Services (PSU), RME
Server to SMTP server
TCP
22
SSH
CiscoWorks Common Services, Campus Manager, and RME
Server to device
TCP
23
Telnet
CiscoWorks Common Services, Campus Manager, and RME
Server to device
UDP
69
TFTP
CiscoWorks Common Services and RME
Server to device
Device to server
UDP
161
SNMP
CiscoWorks Common Services, CiscoView, RME, Campus Manager, DFM, IPM, and HUM
Server to device
Device to server
TCP
514
Remote Copy Protocol
CiscoWorks Common Services
Server to device
UDP
162
SNMP traps (standard port)
Campus and DFM
Device to server
UDP
514
Syslog
CiscoWorks Common Services and RME
Device to server
UDP
1431
Trap listener to MAC notification traps
Campus Manager
Device to server
UDP
9000
DFM trap receiving (if port 162 is occupied)
DFM
Device to Server
UDP
16236
UT host acquisition
Campus Manager
End host to Server
TCP
443
CiscoWorks HTTP server in SSL mode
CiscoWorks Common Services
Client to server
Server internal
TCP
1741
CiscoWorks HTTP Protocol
CiscoWorks Common Services, CiscoView, Campus Manager, RME, DFM, and IPM
Client to server
UDP
42342
OSAGENT
CiscoWorks Common Services
Client to server
(for ANIServer)
TCP
42352
ESS HTTP
(alternate port is 44352/tcp)
CiscoWorks Common Services
Client to server
TCP
8898
Log server
DFM
Server internal
TCP
9002
DynamID authentication (DFM broker)
DFM
Server internal
TCP
9007
Tomcat shutdown
CiscoWorks Common Services
Server internal
TCP
9009
Ajp13 connector used by Tomcat
CiscoWorks Common Services
Server internal
UDP
9020
DFM trap receiving
DFM
Server internal
TCP
10002
OpsXML message bus, OpsXMLRuntime
CiscoWorks Assistant
Server internal
UDP
14004
Lock port for ANIServer singlet on check
Campus Manager
Server internal
TCP
15000
Log server
DFM
Server internal
TCP
40050-
40070
CSTM ports used by CS applications, such as OGS, DCR
CiscoWorks Common Services
Server internal
TCP
40401
LicenseServer
CiscoWorks Common Services
Server internal
TCP
43242
ANIServer
Campus Manager
Server internal
TCP
42340
CiscoWorks Daemon Manager - Tool for Server Processes
CiscoWorks Common Services
Server internal
TCP
42344
ANI HTTP server
CiscoWorks Common Services
Server internal
UDP
42350
Event Services Software (ESS)
(alternate port is 44350/udp)
CiscoWorks Common Services
Server internal
TCP
42351
Event Services Software (ESS) listening
(alternate port is 44351/tcp)
CiscoWorks Common Services
Server internal
TCP
42353
ESS routing
(alternate port is 44352/tcp)
CiscoWorks Common Services
Server internal
TCP
43441
CMF database
CiscoWorks Common Services
Server internal
TCP
43455
RME database
RME
Server internal
TCP
43443
ANIDbEngine
Campus
Server internal
TCP
43445
Fault history database
DFM
Server internal
TCP
43446
Inventory service database
DFM
Server internal
TCP
43447
Event Promulgation Module database
DFM
Server internal
TCP
44400-
44420
CSTM port for DFM, HUM
DFM, HUM
Server internal
TCP
47000-
47040
CSTM port for RME
RME
Server internal
TCP
49154
UPMDbEngine
HUM
Server internal
TCP
49155
OpsxmlDbEngine, JDBC / ODBC
CiscoWorks Assistant
Server internal
TCP
49157
IPM database
IPM
Server internal
TCP
50001
SOAPMonitor
RME
Server internal
TCP
55000-
55020
CSTM port for Campus Manager
Campus Manager
Server internal
4. Initial Setup of the LMS 3.2 Server: Portal, Setup Center, and Common Services
This chapter will guide you through the initial setup of the LAN Management Solution server. This chapter provides setup information on the CiscoWorks Portal, CiscoWorks Assistant, Setup Center, and Common Services.
LMS Portal is the GUI front of the server. CWA is the workflow engine, or GUI wizard, to guide the user through setting up the LMS server. CWA has been steadily improved since first introduced in LMS 3.0. It is the recommended way for the initial setup of the LMS 3.2 server.
Alternatively, advanced users can use LMS Setup Center for more server setup functions. LMS Setup Center is the centralized location where the user can get done with most of the application settings including Common Services, Resource Management Essential, Campus Manager, and Device Fault Manager.
CiscoWorks Portal
In previous versions of LMS, users had to go through multiple layers of user interface (sometimes through three or four mouse clicks) to reach status information or the desired data. Moreover there was no customization supported. Users could not customize the desktop for easy, quick access to frequently accessed data or functionality, which led to usability challenges.
Starting with LMS 3.0, the CiscoWorks Portal was introduced as the dashboard to provide zero-click access to network data and management functionality, significantly improving the usability of LMS. Through this portal, you can easily launch all the functions offered by LMS and have direct access to the status of your LMS servers, network devices, and network topologies.
The primary benefits of CiscoWorks LMS Portal are:
• Customization: You can personalize the CiscoWorks homepage using the drag-and-drop, add, edit, and remove features
• Information available zero-click: Easy and quick access to the frequently viewed vital information pulled directly from the applications in the CiscoWorks LMS suite
• Multi-server support: Lists all of the portlets based on the applications installed on remote servers
• Lightweight GUI: Eliminates the need to install any plug-ins to launch the application
Components of LMS Portal
When the user logs into the LMS server, the user sees the CiscoWorks LMS Portal (Figure 11). The LMS Portal has three different components:
Figure 11. Portal Layout
• The Portal: The portal serves as the overall container and contains a set of views. You can set up the portal to manage a single server or multiple servers.
• Communities and Views: Views are organized pages under name tabs and contain a set of portlets. For example, under the Functional tab is the Functional view. LMS 3.2 comes with three predefined communities, or supersets of views (Figure 12).
Figure 12. Portal Communities
You can select either LMS or CiscoWorks Portal or My Portal from the drop-down box displayed at the top right corner of CiscoWorks LMS Portal.
The LMS community is the default community and contains nine page views:Functional, System, Network, CS, DFM, CM, RME, IPM, and HUM. You can also create your own page views and add portlets to get the view you want.
The CiscoWorks Portal is the public community shared by all users. You can copy views from LMS super view and add or delete portlets for everyone to see.
The My Portal view is the private community configured by the user. It changes when a different user logs into the server.
• Portlets: Portlets are individual pieces of data pointing to an application function or status report. You can add or remove portlets to customize the views except the Functional view. The portlet list is based on the applications installed and registered. The visibility of portlet contents is based on the user's roles and privileges.
Each portlet contains six icons on the top. These icons will be visible only when you move the mouse over the right corner of each portlet. By clicking these icons you can change the look and feel of the portlet, configure the portlet, get help, minimize or maximize, or close the portlet. See Figure 13.
Figure 13. Portlet Example: RME Hardware Summary
Customize the Portal
LMS offers tremendous flexibility for the user to customize the look and feel of the portal. You can,
• Add a page view
Adding a new view helps you to consolidate information specific to a particular function, such as troubleshooting. It also allows you to group data from different LMS applications on a single page.
To add a view:
Go to the CiscoWorks LMS Portal homepage and click the Add View button located at the top right corner of the portal.
Figure 14. Add View
Input the name and click Save.
Note: After you add a View, you can customize it by either duplicating an existing view as a template or by creating it afresh by adding your own portlet. To duplicate from an existing view as a template, click in your newly created view, click View, and then choose the template and click Save. Following this step, you can go to the view and choose to add or delete individual portlets.
Customize a View
To start from a blank view, click the tab for the new view, and click the Add Portlet button located at the top right corner. The portlet selector appears (Figure 15).
Figure 15. Add Portlets
From this selector, you can choose the portlet you want to add to your view by browsing the available categories.
You can search a portlet by using the search box at the top. For example, you can search for Object Finder (Figure 16).
• Portlet view: This is the default type. It's a view that contains various portlets of interests.
• Embedded view: You can embed a webpage in the embedded view. Just point it to the URL of the webpage. It'll show the webpage in LMS Portal.
• URL: You can point to a URL. Clicking the view tab will launch the website outside the portal.
To change the view type, click the Edit View button at the top right corner of the portal. For example, see Figure 17 to see how to make an embedded view for the RME dashboard.
Figure 17. Make an Embedded View
Note: You can create a friendly URL for the view, which can be used to directly access functions.
Deleting a View
To delete a view, edit the view and choose the view to be deleted (Figure 18).
Figure 18. Delete a View
Use CWA for initial Setup of the CiscoWorks Server
To use CWA for the initial setup, go to the Functional view and locate the CiscoWorks Assistant portlet. There are three workflows out of the box. Choose Server Setup (Figure 19).
Figure 19. CWA Portlet
The Server Setup workflow will guide the user through the basic server setup tasks including:
• Configuring server settings such as System Identity, admin password, SMTP, and so on
• Configuring device management mode
• Configuring default credentials for the network devices
• Manually adding or automatically discovering network devices on your network
• Allocating devices to be managed by applications like RME, CM, DFM, and IPM
• Integrating with ACS (optional but recommended; covered in a separate whitepaper)
Note: After finishing the CWA workflow, all these tasks can still be directly accessed in Common Services.
After launching the CWA server setup workflow, it shows the local LMS server and the connection status (Figure 20).
Figure 20. CWA Server Setup Workflow
Click the Start Setup button to start the workflow, or continue the previous unfinished setup.
For a fresh server, the user needs to configure the server setting as shown in Figure 21.
Figure 21. CWA Server Settings
The next step will show the current system identity. System identity setup helps you to create a trusted user on servers that are part of a multiple LMS server setup or ACS integration. This facilitates user communication among servers that are part of a management domain. There can only be one system identity user for each server.
The system identity user you configure must be a peer server user.
In the non-ACS mode, the system identity user that you create must be a local user, with all privileges.
In the ACS mode, the system identity user should be configured in ACS, with Super Admin privileges, in all applications registered in ACS. You can either configure the system identity user with the predefined Super Admin role or with a custom role created with all privileges in ACS. See Figure 22.
Figure 22. CWA: System Identity
In Figure 23 we create a new system identity user.
Figure 23. CWA: New System Identity
The next step is to configure the device management mode. Initially the devices are added or discovered to the DCR of Common Services. By default, all devices are managed automatically by Campus Manager and RME, but not DFM and IPM. The device management mode determines whether the new devices are automatically managed by CiscoWorks applications. There are three device management modes. See Table 5.
Table 5. Device Management Mode
Device Management Mode
Description
Auto Allocation Off
In this mode, automatic addition of devices to LMS applications is disabled. You can use this option to:
• Selectively add devices to the application from DCR.
• Add previously deleted devices back into the application.
You can manually add the devices to LMS applications even if you have selected other modes for device management.
Auto Allocation - All Devices
In this mode, all devices in DCR are added to the selected LMS application. This is also limited by the LMS license you have purchased.
Auto Allocation - Allocate by Groups
In this mode, devices that belong to a specific group in Common Services are added to LMS applications. This is also limited by the LMS license you have purchased.
You must select a group name for all applications that are installed on local and peer servers.
In Figure 24 we auto allocate all devices to the applications including RME, CM, DFM, and IPM.
Figure 24. CWA: Auto Allocation
CWA will finish the first part of the server setup and report the status. See Figure 25.
Figure 25. CWA: Server Setup
Multiple Default Credential Sets
Next CWA will guide you to configure the default credentials and credential sets. Default Credentials is a new feature since LMS 3.0. It allows the user to set up common (default) credentials for the devices so the user does not need to specify credentials one by one for the devices. In LMS 3.2, a new feature is added to support credential sets. Now you can create multiple sets of default credentials and assign the sets based on policies, that is, IP address, host name, or display name.
Figure 26 shows how to create the default credential set.
Figure 26. Create Default Credential Set
Here we create the credential set MyDefaultSet2. Click Apply and fill in the standard credentials and SNMP credentials.
The standard default credentials include primary and secondary credentials (username, password, and enable password for Telnet or SSH). See Figure 27.
Figure 27. Default Credentials: Standard Credentials
SNMP credentials now support both SNMPv2, and SNMPv3 for both AuthNoPriv and AuthPriv modes (Figure 28).
Figure 28. Default SNMP Credentials
Credential Set Policies
After saving the default credential set, the user is prompted to add the policy configuration for the default credential sets created. You can assign sets based on IP range, hostname, or display name (Figure 29).
Figure 29. Credential Policy Configuration
Figure 30 shows the add device interface. You can manually add the devices into DCR by bulk importing from a file (comma-separated values [CSV] or XML) or network management systems (HP OpenView, IBM NetView, or Cisco Secure ACS).
Or you can run the discovery process on the server to find devices on your network.
Figure 30. CWA: Discover Mode
The NG (next-generation) automatic device discovery of LMS 3.2 supports both Layer 2 (Cisco Discovery Protocol) and Layer 3 protocols. You can also do a ping sweep across the network or use other options like Cluster Discovery Module and Hot Standby Router Protocol (HSRP). For details, check out the NG discovery whitepaper at http://www.cisco.com/en/US/prod/collateral/netmgtsw/ps6504/ps6528/ps2425/white_paper_c11-493921.html.
Note: In LMS 3.2, discovery supports IPv6 using ping sweep and the Cisco Discovery Protocol module only.
By default Cisco Discovery Protocol is used to discover the devices. Figure 31 shows how to choose the discovery modules.
Figure 31. CWA: Discovery Modules
To use Cisco Discovery Protocol as the discovery protocol, first add the seed devices. The seed devices are usually the core switches that have the most connections to other network devices. The CiscoWorks server will go to the seed device and find its neighbors, then find the neighbors' neighbors. This process will propagate across the network until all devices are found.
In Figure 32 we add the seed devices and specify how many hops the discovery shall proceed (the default is unlimited). Jump Router Boundaries is turned on to allow the discovery to extend beyond the boundaries set by routers within the network. Device discovery may take longer if you do not selectively choose the boundaries by excluding specific IP addresses.
There is another option to use DCR as a seed list, but it is not recommended if you have already imported many devices in DCR.
Figure 32. CWA: Seed Device for Discovery
Next we configure the SNMP settings, including target, read community string, timeouts, and retries (Figure 33).
Note: Discovery SNMP settings page is enhanced to support SNMPv2c to SNMPv1 and SNMPv3 to SNMPv2c fallback. When the SNMP fallback from SNMPv2c to SNMPv1 option is selected, the discovery falls back to SNMPv1 if SNMPv2c fails.When SNMP fallback from SNMPv3 to SNMPv2c is selected, the discovery falls back to SNMPv2c if SNMPv3 fails.
Figure 33. CWA: SNMP Settings for Discovery
If you want to limit the discovery scope, configure the filter settings to include or exclude devices based on IP address, DNS domain, sysObjectID, or sysLocation (Figure 34).
Figure 34. CWA: Discovery Filter Settings
On the global settings, users can configure the preferred DCR display name and preferred management IP and choose the default credentials. If you want the discovery process to resolve IP addresses to hostnames, make sure DNS is configured properly on the LMS server. See Figure 35.
Figure 35. CWA: Discovery Global Settings
Multiple Device Credentials
New in LMS 3.2, multiple sets of default credentials can be configured and applied when adding, editing, or importing devices. Policy-based credentials allow users to apply credential sets to devices based on IP address range, display name, or host name.
After the discovery is done, a message is shown to report the success (Figure 36).
Figure 36. CWA: Discovery Completed
Users can check the devices discovered by going to Common ServiceàDevice and CredentialsàDevice Management to check out the device summary (Figure 37).
Figure 37. Common Services: Device Selector
The next step is to allocate the devices to the applications. In Figure 38 we are allocating all devices to RME, CM, DFM, and IPM.
Note: Most of the steps done by CWA can be directly accessed from the Common Services dashboard. If you need to rerun some of the jobs such as device discovery, launch the Common Services dashboard from the Functional view. For example, under Common Services à Device and Credentials à Device Discovery you can configure and run discovery.
CiscoWorks LMS Setup Center
For advanced users, CiscoWorks LMS Setup Center is a centralized area where the user can quickly complete the CiscoWorks system configurations. One of the most common observations from new CiscoWorks users is that it is difficult to remember which application menu to navigate to when changing a system setting. CiscoWorks LMS Setup Center was designed to provide shortcuts to those options that may be difficult to find. It allows you to configure the necessary server settings immediately after installing the CiscoWorks LMS software. The Edit icon displayed for each setting takes you to the respective application page to configure the settings. See Figure 39.
Figure 39. LMS Setup Center
The configurations in CiscoWorks LMS Setup Center are grouped into the following categories:
• System Settings: The configuration that the system needs to function effectively
• Security Settings: The security-related settings for the product
• Data Collection Settings: The settings necessary for collecting data from the devices
• Data Collection Schedule: The schedule settings for collecting the data from the server
• Data Purge Schedule: The configurations that are necessary for the device to purge data
The settings specific to all applications including CiscoWorks Common Services, CiscoWorks RME, CiscoWorks Campus Manager, and Device Fault Manager are grouped within these five categories, and Setup Center enables you to configure them in a common space.
Note: If an application is not installed, the corresponding entries are not available.
System Settings
This category lists the configurations that are necessary for the system to function.
The system settings specific to all the applications are grouped under this category. If a CiscoWorks application is not installed, the corresponding entries are not displayed. To launch the System Settings page, click the System Settings tab from the CiscoWorks homepage's LMS Setup Center application. The System Settings page displays the name of the settings, their value, and a brief description. Each entry has an Edit icon. Click the Edit icon for a specific system setting to open the corresponding settings page.
Security Settings
The security-related configurations of all CiscoWorks applications are grouped under this category. If a CiscoWorks application is not installed, then the corresponding entries are not displayed.
To launch the Security Settings page, click the Security Settings tab from the LMS Setup Center application. The Security Settings page displays the name of the settings, their value, and a brief description. Each entry has an Edit icon. Click the Edit icon for a specific security setting to open the corresponding security settings page.
Data Collection Settings
This category lists the settings to collect the data from the devices. The data collection settings specific to all CiscoWorks applications are displayed here. If an application is not installed, the corresponding entries are not displayed.
To launch the Data Collection Settings page, click the Data Collection Settings tab from the LMS Setup Center application. The Data Collection Settings page displays the name of the settings, their value, and a brief description. Each entry has an Edit icon. Click the Edit icon for a specific data collection setting to open the corresponding data collection page.
Data Collection Schedule
This category lists the schedule settings for the server for data collection. The data collection schedule settings for all CiscoWorks applications are under this category. If a CiscoWorks application is not installed, the corresponding entries are not displayed.
To launch the Data Collection Schedule page, click the Data Collection Schedule tab from the LMS Setup Center application. The Data Collection Schedule page displays the name of the settings, their value, and a brief description. Each entry has an Edit icon. Click the Edit icon for a specific data collection schedule setting to open the corresponding configuration page.
Data Purge Schedule
This category lists the configurations for the device to purge data. The data purge settings specific to all CiscoWorks applications are under this category. If a CiscoWorks application is not installed, the corresponding entries are not displayed.
To launch the Data Purge Schedule page, click the Data Purge Schedule tab from the LMS Setup Center application. The Data Purge Settings page displays the name of the settings, their value, and a brief description. Each entry is accompanied by an Edit icon. Click the Edit icon for a specific data purge schedule to open the corresponding configuration page.
Common Services Setup
Common Services is the core component of the LMS applications, and other applications rely on it to perform their tasks. Common Services maintains the database for DCR, which stores all the device information to be managed.
General Server Setup
DCR Mode
This paper discusses LMS server as a standalone server. As you become more familiar with the LMS features, you can set up multiple LMS servers to work together in a master/slave scenario. To change the mode of the LMS server, go to CSàDevice and CredentialsàAdminàMode Settings. See Figure 40.
Figure 40. DCR Mode
Device Polling
Unreachable devices in DCR are detected by polling the devices using supported protocols for a specific period of time. These devices can then be deleted from DCR. Protocols supported are ping, Snmpv1/v2/v3.
To configure device polling, go to Common Services àDevice and Credentials àAdminàDevice Polling. See Figure 41.
Figure 41. Device Poll Settings
Deleting Unreachable Devices from DCR
The possible reasons for device unreachability are:
• Connectivity protocols such as SNMP or Internet Control Message Protocol (ICMP) may be disabled on the device.
• Incorrect credentials may be configured for the device.
• Invalid timeout and retries may have been configured on the device.
To delete unreachable devices from DCR:
1. Go to the CiscoWorks homepage and select Common Services à Device and Credentials à Admin à Device Polling à Unreachable Device Report.
The Unreachable Device Report page appears.
Alternatively, you can navigate to this page from the LMS Portal homepage if you have installed the LMS Portal application on the CiscoWorks server.
2. Do either one of the following:
• Select Show All Unreachable Devices to display all the devices that are not reachable.
• Or select Show Devices Not Reachable For and enter a number in the text field corresponding to the polling frequency you have selected to see a list of devices unreachable during the corresponding time period.
• For example, if you enter the number 2 and have selected the device polling job frequency as Daily in the Device Polling Settings page, a list of devices that are unreachable for two days or more appears.
• If you enter the number 3 and have selected the device polling job frequency as 6 hours in the Device Polling Settings page, a list of devices that are unreachable for 18 hours or more appears.
Setting Up the CiscoWorks Homepage
You can configure or change the CiscoWorks homepage settings.
To modify the CiscoWorks homepage settings:
1. Select Common Services à Server à HomePage Admin à Settings.
2. Enter a name for the CiscoWorks Server in the Homepage Server Name field.
3. Check the Display Server name With Browser Title checkbox to display the name of the CiscoWorks Server along with the browser title.
4. Select the Hide External Resources check box to hide the Resources and CiscoWorks Product Updates panels in the homepage.
5. Enter the display name you want for third-party tools in the Custom Name for Third Party field.
6. Enter the display name you want for custom tools/homegrown tools in the Custom Name for Custom Tools field.
7. Select a value from the Urgent Messages Polling Interval drop-down list to set the polling interval for messages.
To disable this feature, select Disable from the drop-down list. The values are 1 Minute, 5 Minutes, 10 Minutes, and DISABLE.
The time you set here decides the polling interval for disk watcher messages and messages you want to broadcast using the Notify Users features. Disk watcher is a utility that monitors the file system. If the file system size goes above 90 percent, it displays an alert to the dashboard of logged-in CiscoWorks users. You can use this to monitor critical file systems.
8. Click Update. You can update any one of the above settings by clicking Update. If you have changed the homepage server name, a popup window appears prompting you to confirm whether you want to use this name in the provider group name. Click OK if you want the name to be suffixed to the provider group name.
• You need to restart Daemon Manager for the provider group name change to take effect.
Displaying CiscoWorks Server Name with Browser Title
Displaying the CiscoWorks server name with a browser title helps you to identify the server from which the application window is launched especially in a multi-server and single sign-on-based setup.
You can enable or disable the option of displaying the CiscoWorks server name along with the browser title. When you choose to display the server name in the browser title, the browser window displays the title in the following format:
Hostname - Application Window Title
Here Hostname is the name of the CiscoWorks server and Application Window Title is the title of the application window launched from CiscoWorks server.
For example, if the name of your CiscoWorks server is lmsdocultra, then the title of the CiscoWorks homepage would be displayed as lmsdocultra - CiscoWorks. If you launch Common Services from the CiscoWorks homepage, the title of the Common Services home window would be displayed as lmsdocultra - Common Services Home.
You can also enable or disable the display of the server name with the browser title by changing the configurations in a properties file.
Configure the uii-windows.properties file located at NMSROOT/lib/classpath to:
• Enable or disable the option of displaying the server name with the browser title
• Change the format of the display from Hostname - ApplicationWindowTitle to ApplicationWindowTitle - Hostname and vice versa
• Replace a hyphen (-) with any other delimiter except empty spaces
• Trim the spaces between the hostname, delimiter, and application window title
Registering Applications with CiscoWorks Homepage
Using this feature, you can register CiscoWorks applications on local or remote servers. You need to enter application instance attributes (host, port, and protocol). Other information such as AppName and URLs available are already defined by the application in a template.
During registration you are prompted to select an application template and then register with the CiscoWorks server. The registration enables the application to be integrated with other applications based on the template definition. It also helps application launch points to be displayed on the CiscoWorks homepage.
To view the registered applications:
1. Select Common ServicesàServeràHomePage AdminàApplication Registration.
2. View the list of registered applications in the Registered Applications dialog box.
To register a new application:
1. Click Register in the Registered Applications dialog box. A wizard guides you through the process.
2. Choose the location for registration. You can select Register from Templates or Import from Other servers.
To register from templates:
1. Select the Register from Templates radio button and click Next.
2. Select the radio button corresponding to the template you require and click Next.
3. Enter the server attributes in the server attributes dialog box and click Next.
4. Click Finish.
Importing from Other Servers
You must perform the following tasks before importing application registrations from other servers. This is to help ensure a secure environment for importing registrations.
• Create self-signed certificates for the local and remote servers (if not already done).
• Add the remote server's certificate to the local server. See Setting up Peer Server Certificate from the online help that accompanies LMS for details.
• Restart the local server.
• Create a peer server user on the remote server. Configure this user as a system identity user in the local server. See Setting up Peer Server Account and Setting up System Identity Account from the online help that accompanies LMS for details.
To import from other servers:
1. Select the Import from Other Servers radio button and click Next.
2. Enter the server name, server display name, and the secure port numbe in the Import Server's Attributes dialog box. Click Next.
3. Select one or more applications from the list to import into the CiscoWorks server. Click Next.
4. The Import Registration Summary window displays a summary of the information you entered. Click Finish.
When the browser-server security mode of the remote server is changed from non-SSL to SSL or from SSL to non-SSL, you should deregister the applications imported from that server and register them again.
Viewing Registered Application Information
The Application Registration screen shows the list of registered applications. You can view the application name, version, host name, and a description for each of the registered applications. This page shows the applications that are registered in the local server as well as any other applications whose templates are imported from other servers.
The version in this screen shows the major version of the applications. In order to know the version with patch level, go to Software CenteràSoftware Updates. The Software Updates page shows the version with patch-level information. The patch-level information is only available for the applications installed in the local server.
Registering Links with the CiscoWorks Homepage
You can add additional links to the CiscoWorks homepage for custom tools and home-grown tools and for third-party applications such as HP OpenView. The links appear under Third Party or Custom Tools on the LMS Portal as you have specified it.
To register links with the CiscoWorks homepage:
1. Select Common ServicesàServeràHomePage AdminàLinks Registration. The Links Registration Status page appears.
2. Click Register. The Enter Link Attributes dialog box appears.
3. Enter the link name and the URL.
4. Select the radio button corresponding to Third Party or Custom Tools to set the display location.
5. Click OK.
Securing LMS Servers
Accessing the LMS Server Securely Using SSL
By default the LMS server is accessed over HTTP at http://server:1741. Common Services provides secure access between the client browser and management server by using SSL. SSL encrypts the transmission channel between the client and server.
Note: SSL is an application-level protocol that enables secure transactions of data through privacy, authentication, and data integrity. It relies upon certificates, public keys, and private keys.
To enable browser-server security:
1. Go to the CiscoWorks homepage and select Common ServicesàServeràSecurityàBrowser-Server Security Mode Setup.
2. Select the Enable option to enable SSL.
3. Click Apply.
4. Log out from your CiscoWorks session, and close all browser sessions.
5. Restart the Daemon Manager from the CiscoWorks server CLI.
On Windows:
Enter net stop crmdmgtd
Enter net start crmdmgtd
On Solaris:
Enter /etc/init.d/dmgtd stop
Enter /etc/init.d/dmgtd start
6. Restart the browser and the CiscoWorks session.
After this change has been implemented, you can log into the server securely using SSL by going to https://server:443. Note the port number has been changed from 1741 to 443.
Setting Up a Local User
To create a local user, go to the CiscoWorks homepage and select Common ServicesàServeràSecurityàLocal User Setup. Click Add to start the process. Fill in the username and password on the form, and choose the user role.
Note: By default, the minimum character limit for CiscoWorks local usernames is five characters. To add a local username with fewer than five characters, change the entry for validate User to false in the NMSROOT/lib/classpath/ss.properties file.
You can only create one user at a time. To create local users in bulk, use the CLI tool. Refer to the help file and search on Setting Up Local Users Through CLI.
System administrators determine user security levels when users are granted access to CiscoWorks. When users are granted logins to the CiscoWorks application, they are assigned one or more roles (Table 6).
Table 6. User Roles
Level
Description
0
Help Desk
1
Approver
2
Network Operator
4
Network Administrator
8
System Administrator
16
Export Data
A role is a collection of privileges that dictate the type of system access you have. A privilege is a task or operation defined within the application. The set of privileges assigned to you defines your role and dictates how much and what type of system access you have.
The user role or combination of roles dictates which tasks are presented to the users. Table 7 shows the security levels.
For information on tasks that can be performed with each role, you can generate a permissions report. To generate a permissions report:
1. Go to the CiscoWorks homepage and select Common ServicesàServeràReports.
2. Select Permissions Report from the Available Reports pane.
3. Click Generate Report.
Note: The permissions report can only show the privilege details of local users. If a user is created on ACS, that user will only show as Help Desk.
You can only add one user at a time for the GUI. To bulk create users, use CLI. For detailed information, search Setting up Local Users Through CLI from the online help that accompanies LMS.
Creating Self-Signed Certificates
CiscoWorks allows you to create security certificates that enable SSL communication between your client browser and management server.
Self-signed certificates are valid for five years from the date of creation. When the certificate expires, the browser prompts you to install the certificate again from the server where you have installed CiscoWorks.
Note: If you regenerate the certificate, when you are in multiserver mode, any existing peer relation might break. The peers need to reimport the certificate in this scenario.
To create a certificate:
1. Go to the CiscoWorks homepage and select Common ServicesàServeràSecurityàCertificate Setup.
2. Enter the values required for the fields described in Table 7.
Table 7. Security Certificate Setup
Field
Usage Notes
Country Name
Two-character country code
State or Province
Two-character state or province code or the complete name of the state or province
Locality
Two-character city or town code or the complete name of the city or town
Organization Name
Complete name of your organization or an abbreviation
Organization Unit Name
Complete name of your department or an abbreviation
Host Name
DNS name of the computer or the IP address of the computer.
Enter the host name with a proper domain name. This is displayed on your certificate (whether self-signed or third-party issued). Local host or 127.0.0.1 should not be given.
Email Address
Email address to which the mail has to be sent.
You can also enter multiple email addresses separated by commas.
3. Click Apply to create the certificate.
The process generates the following files:
• server.key: Server's private key
• server.crt: Server's self- signed certificate
• server.pk8: Server's private key in PKCS#8 format
You can use the CSR file to request a security certificate, if you want to use a third-party security certificate.
Note: If the certificate is not a self-signed certificate, you cannot modify it.
5. Device Management: Resource Management Essentials, CiscoView, Device Center
Business Scenarios
As enterprise networks grow ever larger, it becomes a tedious job to manage hundreds or even thousands of devices. With the LMS applications discussed in this chapter, we can address problems like these:
How do I keep track of the inventory of devices on my network? How do I generate a customized report that digs out just the inventory information I need?
How do I keep track of the outdated devices and plan for an equipment upgrade budget? How do I keep track of not only outdated hardware but outdated Cisco IOS Software images?
How do I keep track of the product information relevant to my network, such as the Product Security Incident Response Team(PSIRT) security alerts and product defects (bugs)? How do I find out which devices are under support contract?
How do I keep an archive of the configuration and be able to restore the configurations if there is any mis-configuration? How do I push configurations to multiple devices on my network without doing it one-by-one through CLI? How do I keep track of the changes?
How do I manage compliance by enforcing configuration policies across the network so everyone is following rules when they configure hundreds of devices?
How do I automatically upgrade the software images on devices without spending too much time and affecting our business?
How do I monitor the syslog messages and be automatically notified if something happens?
All these questions and more can be answered with three LMS applications for elements management:
• Resource Manager Essentials
• CiscoView
• Device Center
Managing Devices in RME
RME Overview
RME is the cornerstone application for the CiscoWorks LMS bundle of infrastructure management tools focusing primarily on configuration management tasks. It includes many automated features that simplify configuration management tasks, such as performing software image upgrades or changing configuration files on multiple devices. RME also includes some fault-management features, such as filtering of syslog messages.
RME consists of the following major components (Figure 42):
• Inventory Manager: Builds and maintains an up-to-date hardware and software inventory providing reports on detailed inventory information. RME has many predefined reports. You can also create custom reports to dig out just the information you need.
• Configuration Manager: Maintains an active archive of multiple iterations of configuration files for every managed device and simplifies the deployment of configuration changes. You can use ConfigEditor to change, compare, and deploy configuration to one device, or use NetConfig to deploy to multiple devices. You can design baseline templates for different configuration needs. You can also specify which action to take after the configuration is deployed.
• Software Manager: Simplifies and speeds software image analysis and deployment. You can do an automatic upgrade analysis to help you select the right image. Then use the SWIM feature to import images, stage the image locally or remotely, then deploy to groups of devices.
• Syslog Analysis: Collects and analyzes syslog messages to help isolate network error conditions. You can filter the syslog messages and designate actions based on the messages.
• Change Audit Services: Continuously monitors incoming data versus stored data to provide comprehensive reports on software image, inventory, and configuration changes.
• Audit Trails: Continuously monitors and tracks changes made to the RME server by the system administrator.
• Compliance Management: By creating a baseline template, which is essentially sophisticated regular expressions, users can enforce configuration rules to help ensure that the configuration complies with the internal policies or government regulations.
Inventory Management provides comprehensive device information, including hardware and software details. This information is crucial for network maintenance, upgrades, administration, troubleshooting, and basic asset tracking. The inventory information can also be used by other applications that need access to this same information without the need for additional device queries. Network administrators must often be able to quickly provide information to management on the number and types of devices being used on the network. The more information network administrators have in one central place about all the devices, the easier it is to locate necessary information, resolve problems quickly, and provide detailed information to upper management.
Inventory Management is also the starting point for many other management activities. For example, to upgrade the software image of a device, information about the amount of RAM, the modules installed, and the current software version is needed. All this data is collected by RME Inventory Management.
In Chapter 4, we talked about how to populate the DCR and add devices to individual applications, such as RME's inventory. You can check out the RME devices under RMEàDevicesàDevice ManagementàRME Devices.Inventory Collection/Polling
At the time of RME installation, system jobs are created for both Inventory collection and polling, with their own default schedules.
Periodic inventory collection versus periodic inventory polling:
A periodic inventory collection job collects inventory data from all devices (devices in the All Devices group) and updates inventory database. The periodic polling polls all devices to check a certain MIB value to see whether the timestamp has changed. If there is a change in the timestamp, RME then goes ahead to retrieve inventory changes and collects and updates the inventory database.
Note: Inventory polling consumes much less bandwidth than inventory collection.
The predefined default periodicity of the collector job is once a week, and the predefined default periodicity of the polling job is once a day.
The polling job detects most changes in all devices, with much less impact on your network and on the LMS server.
To change the default settings, traverse to Resource Manager EssentialsàAdministrationàInventoryàSystem Job Schedule. The System Job Schedule dialog box displays the current collection or polling schedule; change the values and click Apply.
Reports Generator
Once you add devices to RME from DCR, RME start retrieving inventory information based on the default schedule setting. RME has numerous predefined reports built-in for all the internal applications. These reports can be generated for view by going to RMEàReportsàReport Generator. These applications include:
• Audit Trail: Tracks and reports changes that the RME administrator makes on the RME server
• BugToolkit: Helps users identify the bugs filed against devices in their network and check the status of the bugs
• Change Audit: Tracks and reports changes made in the network including configuration, inventory, and software image changes
• Contract Connection: Shows the status of service contracts of all Cisco IOS devices in your network
• Device Credential: Displays the device names and the credential status for each device
• Inventory: Reports the comprehensive inventory information collected by RME
• Syslog: Displays the syslog message received from the devices by RME
Under each application, you can generate different types of reports. For example, under Inventory you can generate the reports shown in Figure 43,
Figure 43. Built-in Inventory Reports
All these reports are generated with a set of predefined query criteria. For example, Software Report will list the software versions based on the categories of the devices. If you want to query a customized list of variables from the inventory, you can use a custom reports template for this as described in the following section.
Some built-in reports are particularly unique in LMS:
• PSIRT Summary report: Introduced in LMS 3.0, this report automates how users track the PSIRT security alert from Cisco. The LMS server can be scheduled periodically to fetch the PSIRT information from cisco.com and correlate to the user's network devices.
• EoS/EoL Hardware Report: Introduced along with PSIRT report, this report works in similar way to automate how users track the EoS/EoL (End of Sale/End of Life) status of the network devices. Good for budget planning. Some customers schedule it to run every quarter to know how much equipment needs to be upgraded.
In LMS 3.1, offline support for PSIRT/EOX was added. Users can select the source of the information to be from Cisco Connection Online or a local file if the LMS server is not directly connected to Internet. This can be customized at Resource Manager Essentials à Admin à Reports à PSIRT/EOX Reports. See Figure 44.
Figure 44. PSIRT/EOX Local Reports
Check the online help to learn how to download Cisco Connection Online PSIRT/EoX information to a local file.
• EoS/EoL Software Report: New feature in LMS 3.2, generates the end of sale, end of life, and end of engineering dates for the software image versions running in the devices in your network. It provides a summary of the end of sale or end of life alerts based on the selected devices.
• PoE Report: Power over Ethernet (PoE) is the ability of the LAN switching infrastructure to provide power over a copper Ethernet cable to an endpoint (powered device). You can generate a PoE report to display detailed information of PoE-enabled devices managed by RME.
• POE Port Level Report: New in LMS 3.2, you can generate a PoE Port Level Report to display information such as power consumption, power available, and power remaining at the port level for devices.
• PSE Report: New in LMS 3.2, you can generate a PSE Report to display information such as power consumption, power available, and power remaining at the PSE/device level.
Custom Reports
To create a customized report with your interested query variables, such as "the serial number of all c1701 routers", follow these steps:
1. Create a custom report template. Go to RMEàReportsàCustom Reports Template, choose Inventory, give it a name such as customreporttest, make it public so everyone can see it, and define the rule as illustrated in Figure 45.
Figure 45. Custom Reports Template
2. Go to RMEàReportsàReport Generator, and choose Inventory. Notice the custom report template customreporttest shows up at the bottom of the dropdown list (Figure 46).
Figure 46. Custom Report
3. Choose your devices and generate the report (Figure 47). Here you can generate a one-time report or schedule a job report to run daily, weekly, or monthly, and automatically be sent in an email or published to a central storage location.
Figure 47. Generate Custom Reports
Note: Successfully generated reports are stored in the archives. You can access the report archives by selecting RMEàReportsàReport Archives.
Software Image Management
RME greatly simplifies the work for software image management by building intelligence into the application to help the user pick and access device images from Cisco.com. Follow these steps to perform a software upgrade to your devices.
Analyze the software images: RME helps the user to analyze the device and decide whether it has enough resources to run the new image. RME gives image recommendations for each selected device. Go to RMEàSoftware MgmtàSoftware DistributionàUpgrade Analysis, then log into Cisco.com. Once you log in, you can see all the available versions for this device. When you select a version, RME will give you suggestions about what to do before upgrading (Figure 48).
Figure 48. Upgrade Analysis Report
The criteria for image recommendation can be modified at RMEàAdminàSoftware MgmtàViewàEdit Preferences.
Note: The number and type of variables analyzed depend on the device type and software version selected. The knowledge base used for analysis can be upgraded by going to RME à Admin à Software Mgmt à Update Upgrade Analysis.
Add images to the repository: Instead of browsing around on Cisco.com trying to find the image file, RME helps the user to locate the image easily online and adds it into the local repository. You can schedule the download immediately or later. See Figure 49.
Note: You can also export the image from the local repository to be used elsewhere.
Figure 49. Add Images from Cisco.com
Create a job for image distribution: Instead of manually loading the images one by one through the CLI, the user can schedule a job to deploy images to a group of devices.The methods of distribution include:
– Basic: This option allows you to select devices and then perform software image upgrades to those devices. Software Management checks the current image on the device and recommends a suitable image for distribution.
– By devices [Advanced]: This option allows you to enter the software image and storage media for the device that you want to upgrade. The selected image and storage media are validated and verified for dependencies and requirements.
– By images: This option lets you select a software image from the software image repository and then use it to perform an image upgrade on suitable devices in your network.
– Use Remote Staging: This option allows you to select a software image, store it temporarily on a device, and then use the stored image to upgrade suitable devices in your network. This is helpful when the Resource Manager Essentials server and the devices (including the remote stage device) are distributed across a WAN.
Software Image Baseline Collection
It is recommended that you first import a baseline of all software images running on your network. The baseline imports a copy of each unique software image running on the network (the same image running on multiple devices is imported into the software library only once). The images act as a backup if any of your devices get corrupted and need a new software image or if an error occurs during an upgrade. If some devices are running software images not in the software repository then a synchronization report can be generated for these devices.
To schedule a synchronization report:
1. Select Resource Manager EssentialsàSoftware MgmtàSoftware RepositoryàSoftware Repository Synchronization. Click Schedule. Enter the information and click Submit.
2. Import a baseline of all software images
3. Once the Software Repository Synchronization job has finished successfully, you could create a job to import all software images on your network by performing the following steps:
All running images that are not in the software repository will appear; click Next. Enter the job control information and click Next, and click Finish when completed.
Note: If you have not selected the Use Generated Out-of-Sync Report option, it will take more time to show the software image selection dialog box.
Customize Software Management Settings
Software Management attempts downloading the software images based on the protocol order specified. While downloading the images, Software Management uses the first protocol in the list. If the first protocol in the list fails, these jobs use the second protocol, and so on, until Software Management finds a transport protocol for downloading the images. The supported protocols are RCP, TFTP, SCP, and HTTP.
In the View/Edit Preferences dialog box (Resource Manager EssentialsàAdministrationàSoftware MgmtàView/Edit Preferences) you can define the protocol order that Software Management has to use for software image download. Use the Add and Remove buttons for selecting the protocol order. See Figure 50.
Figure 50. Management Protocol Settings
Support for In-Service Software Upgrade
RME supports the In-Service Software Upgrade (ISSU) process. This process allows Cisco IOS Software images to be updated without rebooting the device. This increases network availability and reduces downtime caused by planned software upgrades.
To perform the image upgrade using this ISSU process, the running image in the device must be ISSU capable.
ISSU support is available only for the following devices:
• Cisco Catalyst 6000 Series IOS Dual Chassis (VSS) Switches
• Cisco Catalyst 6000 Series Dual Supervisor Switches
The ISSU process can be applied for the following distribution methods:
• By devices [Basic]
• By devices [Advanced]
• By image
• Through remote staging
To perform this ISSU image upgrade process you must select the Reboot immediately after downloading option in the Job Schedule and Options page of the device distribution flow.
You can also customize the configurations available in the Issuconf.properties file located at NMSROOT/MDC/tomcat/webapps/rme/WEB-INF/conf/swim.
You can configure the properties listed in Table 8 in the Issuconf.properties file.
Table 8. Device Management Mode
Variable
Description
RBTConfig
Configure the rollback timer.
By default, the value of this variable is set as NO.
If you configure the value as Yes, then rollback will happen for the value set in the variable RollBackTime.
RollBackTime
Enter the rollback timer (value in minutes).
By default, the rollback time is set as 45.
To consider the value for the rollback timer, you must set the RBTConfig value as Yes.
IssuSupImgVer
The ISSU-supported version of the running image.
For ISSU upgrade support, the value for this variable must be an ISSU-capable image version such as SXI.
This value can match the version of the running image either completely or partially. For example, 12.2(33)SXI, or SXI.
The running software image version in the device must match the version configured in the Issuconf.properties.
Configuration Management
The Configuration Management tab in RME includes three applications: Archive Management, Config Editor, and NetConfig.
1. Archive Management
2. The Archive Management application maintains an active archive of the configuration of devices managed by RME. It provides:
• The ability to fetch, archive, and deploy the device configurations
• The ability to handle syslog-triggered configuration fetches, thereby making sure that the archive is in sync with the device.
• The ability to search and generate reports on the archived data
• The ability to compare and label configurations
Configuration Collection/Polling
The configuration archive can be updated with configuration changes by periodic configuration archival (with and without configuration polling). You can enable this using Resource Manager EssentialsàAdministrationàConfig MgmtàArchive MgmtàCollection Settings.
Note: Scheduled collection and polling are disabled by default as the customer's network may have sporadic bursts of traffic and the network management system should not take up the existing bandwidth. It is best for the customer to select the periodic collection and polling.
You can modify how and when the configuration archive retrieves configurations by selecting one or all of the following:
• Periodic Polling
Configuration archive performs an SNMP query on the device, if there are no configuration changes detected in the devices, no configuration is fetched.
• Periodic Collection
Configuration is fetched without checking for any changes in the configuration.
Step 1. Select Resource Manager Essentials à Administration à Config Mgmt à Archive Mgmt à Collection Settings.
Step 2. Select one or all the options.
• Default protocols used for a configuration fetch and deploy
• Many protocols are used for performing a configuration fetch and deploy. The system provides a default order of protocols that will be used to fetch or deploy the configuration on the device. You can set the protocols and order for Configuration Management applications such as Archive Management, Config Editor, and NetConfig jobs to download configurations and to fetch configurations.
The available protocols are:
• Telnet
• TFTP
• RCP
• SSH
• Secure Copy Protocol (SCP)
• HTTPS
To setup protocol ordering for Configuration Management, go to Resource Manager EssentialsàAdministrationàConfig MgmtàTransport Settings. See Figure 51.
Figure 51. RME Transport Settings
Protocol ordering can be setup for different configuration applications (Archive Management, Config Editor, and NetConfig) by selecting the application from the Application Name drop-down list. Select the protocol order by using the Add and Remove buttons on the screen and click Apply.
For secure communication between the server and device use SSH.
1. Config Editor
2. You can use the Config Editor application to perform the tasks listed in Table 9.
Table 9. Config Editor Tasks
Task
Launch Point
Set or change your Config Editor preferences.
Select RMEàAdminàConfig MgmtàConfig Editor.
View the list of previously opened files in private or public work areas.
The RME Config Editor function can be used to edit a device configuration stored in the configuration archive and download it to the device. The Config Editor tool allows the user to make changes to any version of a configuration file, review changes, and then download the changes to the device.
When a configuration file is opened with Config Editor, the file is locked so that no one else will be able to make changes to it at the same time. While the file is locked, it is maintained in a "private" archive available only to the user who checked it out. If other users attempt to open the file to edit it, they will be notified that the file is already checked out and they can only open a "read-only" copy. The file will remain locked until it is downloaded to the device or manually unlocked within Config Editor by the user who checked it out or by a user that has network administrator and system administrator privileges.
1. NetConfig
2. You can use the NetConfig application to perform the tasks listed in Table 10.
Table 10. NetConfig Tasks
Task
Launch Point
• View and create NetConfig jobs using the NetConfig Job Browser.
• View job details (by clicking the Job ID hyperlink in the NetConfig Job Browser).
Enter your password if prompted.
located at the top right corner of the portal.
located at the top right corner. The portlet selector appears (Figure 15).
to start the workflow, or continue the previous unfinished setup.
