LMS 3.0

© 2008 National Engineers Training Services. All rights reserved. 1

Implementing CiscoWorks LMS 3.0 (CWLMS)

© 2006 National Engineers Training Services. All rights reserved. 2© 2008 National Engineers Training Services. All rights reserved. 2

Course Content:-

The Implementing CiscoWorks LMS (CWENT) v3.0 course teaches students how to effectively use the CiscoWorks applications contained in the LMS 3.0-3.01 bundle. The focus is on finding the correct tools within CiscoWorks to document the network, log changes that occur, deploy global changes to devices, monitor network performance, and manage network faults.

Course Goal:-

To effectively use CiscoWorks applications contained in LMS and find the correct tools to document the network, log changes, deploy global updates,

monitor performance, and manage network faults


Course Objectives:

Upon completing this course, students will be able to meet these objectives:

• Describe fundamental network management concepts• Describe the CiscoWorks applications in the LMS bundle• Prepare the various CiscoWorks repositories, databases, and applications for use• Maintain an asset inventory using CiscoWorks tools for documenting the network

and generating reports• Manage network connections using CiscoWorks tools to view and troubleshoot

network device, end user, host, and IP Phone connections• Manage the configurations of network devices using CiscoWorks tools that help

archive, modify, and detect changes• Monitor the network using CiscoWorks tools that measure response time and

device performance• Manage the network faults, using CiscoWorks tools which help detect and isolate

problems so they can be addressed before causing further network service degradation

• Describe various CiscoWorks system administration tasks


Course Outline:-

• Describing Network Management Fundamentals • Introducing CiscoWorks • Jump-Starting CiscoWorks • Implementing Asset Management • Managing Network Connections • Managing Device Configurations • Managing Network Performance • Managing Faults in the Network • Performing System Administration


Describe Network Management Fundamentals


Network Management

Network management refers to the activities, methods, procedures, and tools that pertain to the operation, administration, maintenance, and provisioning of networked systems

1. OperationOperation deals with keeping the network (and the services that the network provides) up and running smoothly. It includes monitoring the network to spot problems as soon as possible, ideally before users are affected.

2. AdministrationAdministration deals with keeping track of resources in the network and how they are assigned. It includes all the "housekeeping" that is necessary to keep the network under control.

3. MaintenanceMaintenance is concerned with performing repairs and upgrades - for example, when equipment must be replaced, when a router needs a patch for an operating system image, when a new switch is added to a network. Maintenance also involves corrective and preventive measures to make the managed network run "better", such as adjusting device configuration parameters.


4. Provisioning

Provisioning is concerned with configuring resources in the network to support a given service. For example, this might include setting up the network so that a new customer can receive voice service.


Network Management Server

A Network Management Sever (NMS) is a console that monitors and controls network elements by executing management applications. To perform NMS functions, high-performance workstation computers that have fast CPUs and extensive disk space are used. A managed network requires at least one NMS server to perform SNMP operations.

Network Management Server

Network Devices

Access Methods

A large number of access methods exist to support network and network device management. Access methods include the SNMP, Command Line Interfaces (CLIs), custom XML, CMIP, Windows Management Instrumentation (WMI), Transaction Language 1, CORBA, netconf, and the Java Management Extensions - JMX.

Access methods


Simple Network Management Protocol (SNMP)

The Simple Network Management Protocol (SNMP) is an application layer protocol that facilitates the exchange of management information between network devices. It is part of the Transmission Control Protocol/Internet Protocol (TCP/IP) protocol suite. SNMP enables network administrators to manage network performance, find and solve network problems, and plan for network growth.

Two versions of SNMP exist: SNMP version 1 (SNMPv1) and SNMP version 2 (SNMPv2). Both versions have a number of features in common, but SNMPv2 offers enhancements, such as additional protocol operations. Standardization of yet another version of SNMP Version 3 (SNMPv3).

SNMP Basic Components

An SNMP-managed network consists of three key components: managed devices, agents, and network-management systems (NMSs). A managed device is a network node that contains an SNMP agent and that resides on a managed network. Managed devices collect and store management information and make this information available to NMSs using SNMP. Managed devices, sometimes called network elements, can be routers and access servers, switches and bridges, hubs, computer hosts, or printers.


An agent is a network-management software module that resides in a managed device. An agent has local knowledge of management information and translates that information into a form compatible with SNMP.

An NMS executes applications that monitor and control managed devices. NMSs provide the bulk of the processing and memory resources required for network management. One or more NMSs must exist on any managed network.

An SNMP-Managed Network Consists of Managed Devices, Agents, and NMSs


SNMP Basic Commands

Managed devices are monitored and controlled using four basic SNMP commands: read, write, trap, and traversal operations.

The read command is used by an NMS to monitor managed devices. The NMS examines different variables that are maintained by managed devices.

The write command is used by an NMS to control managed devices. The NMS changes the values of variables stored within managed devices.

The trap command is used by managed devices to asynchronously report events to the NMS. When certain types of events occur, a managed device sends a trap to the NMS.

Traversal operations are used by the NMS to determine which variables a managed device supports and to sequentially gather information in variable tables, such as a routing table.


SNMP Management Information Base

A Management Information Base (MIB) is a collection of information that is organized hierarchically. MIBs are accessed using a network-management protocol such as SNMP. They are comprised of managed objects and are identified by object identifiers.

A managed object (sometimes called a MIB object, an object, or a MIB) is one of any number of specific characteristics of a managed device. Managed objects are comprised of

one or more object instances, which are essentially variables.

Two types of managed objects exist: scalar and tabular. Scalar objects define a single object instance. Tabular objects define multiple related object instances that are grouped in MIB tables.

An example of a managed object is at Input, which is a scalar object that contains a single object instance, the integer value that indicates the total number of input AppleTalk packets on a router interface.

An object identifier (or object ID) uniquely identifies a managed object in the MIB hierarchy. The MIB hierarchy can be depicted as a tree with a nameless root, the levels of which are assigned by different organizations.


MIB Hierarchy


Introducing CiscoWorks


CiscoWorks LMS 3.0 provides network management tools for simplifying the configuration, performance monitoring, and troubleshooting of Cisco networking devices. A new improved network desktop portal called the CiscoWorks LMS Portal provides new ways of viewing and launching network management functionality with the added flexibility of allowing users the ability to configure and build their own homepage. The CiscoWorks Assistant workflow module brings a diverse set of functions together for quick isolation and troubleshooting of network-related problems. In addition to the new portal and workflow engine, there are many new features that are being introduced in each of the CiscoWorks LMS application areas.

What is LMS 3.0


New Features

CiscoWorks LMS 3.0 provides significant new features as a bundle and within each specific application area. A summary of new bundle-level features is listed in Table 1. For information on the new application features of CiscoWorks LMS 3.0,


Feature Description

Single DVD installation framework All CiscoWorks LMS applications are delivered on a set of installation DVDs, one for Solaris operating systems and the other for Windows operating systems. The new installation framework allows for unattended installation and reduces the overall time required to install the CiscoWorks LMS software.

CiscoWorks LMS Portal A new portal framework that provides customers with three new views from their browsers:• System Administration View: Highlights application status, job status, log file information, backup/restore status, and other system and application-level details; provides network administrators more flexibility in defining what is most critical for them to monitor• Network Administrator View: Provides links and up-to-date status on network device issues and troubleshooting• Functional View: Similar to the current CiscoWorks LMS network desktop's functional view; provides a list of installed applications and their corresponding modules

CiscoWorks Assistant A new set of workflows for simplifying CiscoWorks LMS setup in both single and multiserver deployments and for quickly isolating and troubleshooting device down, link down, issues.

Device Credential Repository enhancements

The Device Credential Repository (DCR) now supports the ability to define multiple credentials for a single device.

Cisco Secure Access Control Server integration

The integration of CiscoWorks LMS with Cisco Secure Access Control Server helps in securing granular user roles and device access.


All CiscoWorks LMS 3.0 applications now ship on a set of two DVDs, one for Solaris installations and the other for Windows installations. Both Solaris and Windows installation DVDs are provided in the package so customers can choose which operating system version to install. The CiscoWorks LMS 3.0 applications included are as follows:

• CiscoWorks Device Fault Manager (DFM) 3.0• CiscoWorks Campus Manager 5.0• CiscoWorks Resource Manager Essentials (RME) 4.1• CiscoWorks Internetwork Performance Monitor (IPM) 4.0• CiscoWorks CiscoView 6.1.6• CiscoWorks Common Services 3.1• CiscoWorks LMS Portal 1.0• CiscoWorks Assistant 1.0

LMS Software Bundle


Installation of CWLMS 3.0


Server Requirements on Windows Systems


Components Recommended Server

LMS 100 1 CPU with 2 GB RAM memory requirement with a swap space of 4 GB.

LMS 300 1 CPU with 2 GB RAM memory requirement with a swap space of 4 GB.

LMS 1500 2 CPUs with 4 GB RAM memory requirement with a swap space of 8 GB.

LMS 5000 Standalone server:– 2 CPUs with 4 GB RAM memoryrequirement and 8 GB swap space. Solution server:– 4 CPUs with 8 GB RAM memoryrequirement and 16 GB swap space.

Maximum of 3,000 devices in eachapplication.– More than one server must be used tomanage up to 5000 devices


The following are the supported processors on a Windows system: Intel:• Intel® Xeon® processor (Dual Core)• Intel® Core™ Duo processor T2600 - T2300• Intel® Pentium® processor Extreme Edition 965 (Dual Core)• Intel® Pentium® D processor 960 (Dual Core)• Intel® Pentium® 4 processor with Hyper-Threading Technology AMD:• Dual-Core AMD Opteron Processor• AMD Opteron Processor• AMD Athlon 64 FX Processor• AMD Athlon™ 64 X2 Dual-Core


Installation Notes

Before you begin the installation, read the following notes:• Close all open or active programs. Do not run other programs during the installation process.• LMS 3.0 is not supported on any native 64-bit systems.• LMS 3.0 is not supported on virtual machines, such as VMware and VirtualPC.• By default, SSL is not enabled on CiscoWorks Server.• While launching CiscoWorks, network inconsistencies might cause installation errors if you are installing from a remote mount point.• If your CiscoWorks Server is integrated with any Network Management System (NMS) in your network using the Integration Utility, you must perform the integration whenever you enable or disable SSL in the CiscoWorks Server. You must do this to update the application registration in the NMS.• Disable any popup blocker utility that is installed on your client system before launching CiscoWorks.• CiscoWorks applications are installed in the default directories: On Windows: SystemDrive:\Program Files\CSCOpx On Windows, check the installation log in the root directory on the drive where the operating system is installed. Each installation creates a new log file. For example C:\Ciscoworks_install_20060721_182205.log


Installing New LMS 3.0 on Windows



Getting Started with LAN Management Solution 3.0


Accessing CiscoWorks Server

LMS 3.0 uses port number 1741 to access the CiscoWorks Server in normal(HTTP) mode and port number 443 to access the server in secure (HTTPS) modeby default.

To access the server from a client system, enter any one of these URLs in yourweb browser:

• If SSL is disabled and if you have installed LMS applications on the default port, and enter:http://server_name:1741• If SSL is enabled, and if you have installed LMS applications on the default port, enter: https://server_name:443

where server_name is the hostname of the server on which you installed LMSapplications. The CiscoWorks Login page appears. Enter the username and password that was provided during installation.


CiscoWorks LMS Portal Home Page


Understanding About Single-Server and Multi-Server Setup

When all the CiscoWorks applications are installed on a single LMS server, the setup is considered as a Single-server setup.

You can also install the CiscoWorks applications in more than one server for better performance and scalability. This setup is considered as a Multi-server setup.

To setup with multiple CiscoWorks servers, you must:• Set up Peer Server Account• Set up System Identity User• Set Up Peer Server Certificate

Understanding DCR and Device Management

The Device and Credential Repository (DCR) is a common repository of devices, their attributes, and credentials, meant to be used by various network managementapplications.

DCR helps multiple applications share device lists and credentials using a client-server mechanism, with secured storage and communications. The applications can read or retrieve the information.

DCR works based on a Master-Slave model. DCR Server can also be in Standalone mode.



1. Applications such as Campus Manager add, fetch, and update devices and credentials2. DCR Server notify changes to the applications3. Applications such as IPM and DFM fetch devices and credentials from DCR4. Applications such as RME fetch and update devices and credentials5. DCR CLI and Device Management UI add/delete devices, update device credentials, and import/export devices6. DCR Master notifies DCR Slaves for add, update, and delete devices and credentials7. DCR Master pulls updated devices and credentials from DCR Slave in response to its notification

Master DCRThe master repository of device list and credential data. The Master hosts theauthoritative, or a master-list of all devices and their credentials. All other DCRsin the same management domain that are running in Slave mode, normally sharesthis list.There is only one Master repository for each management domain, and it containsthe most up-to-date device list and credentials.

Slave DCRThe Slave DCR is a repository that is an exact replica of the Master.DCR Slaves are slave instances of DCR in other servers and provide transparentaccess to applications installed in those servers.



Standalone DCRIn Standalone mode, DCR maintains an independent repository of device list andcredential data. It does not participate in a management domain and its data is notshared with any other DCR. It does not communicate with or contain registrationinformation about any other Master, Slave, or Standalone DCR.

Device Management Modes

The possible modes are:• Auto Management— If any new devices are added in DCR, these devices arealso added to the application automatically.• Manual Allocation—You can use this option to selectively add devices to theapplication from DCR or when you have deleted devices in the applicationand you want to re-add those devices to the application.


Understanding About Single Sign-On

The Single Sign-On (SSO) feature helps you to use a single session to navigate to multiple CiscoWorks servers without having to authenticate to each of them.SSO mode can be set as Standalone, Master or Slave. In a single-server setup, the SSO mode is usually set to Standalone.Understanding AAA Modes

CiscoWorks Server has some built-in security features to authenticate and authorize users to perform the tasks in CiscoWorks applications. CiscoWorks Server also provides a way to select and configure pluggable authentication sources.To get maximum security protection, CiscoWorks Server can be integrated with Access Control Server (ACS). When integrated all the authentication and authorization transactions are performed by that ACS server. The following are the AAA modes in CiscoWorks Server:

Non-ACS — Also called CiscoWorks local mode. All the authentication services are provided by the login modules selected.

The available login modules are:

– CiscoWorks Local– IBM SecureWay Directory– KerberosLogin– Local UNIX System– Local NT System– MS Active Directory– Netscape Directory– Radius– TACACS+


About CiscoWorks Assistant

CiscoWorks Assistant is a web-based tool that provides workflows to help you to overcome network management and software deployment challenges.

CiscoWorks Assistant supports the following workflows:

Server SetupServer Setup workflow helps you to create a single or multi-server setup. It also assists you to add and manage devices, as well as configure the AAA mode to ACS. You can add devices to Device and Credential Repository and import these devices across LMS applications.

Device TroubleshootingYou can identify the root cause for device unreachability. The generated Device Troubleshooting report contains the details about Alerts and Syslog Messages, Last configuration change, details of the device topology, anddetails on network inconsistencies.

End Host/IP Phone DownYou can get the information required to troubleshoot as well as analyze the connectivity issues.


Preparing to Use LMS ApplicationsYou must perform some configuration activities in few applications to get started with them to be able to use the functions they provide.

The following are some of the important configuration operations you must perform.

This section contains:

• Preparing to Use Campus Manager• Preparing to Use Device Fault Manager• Preparing to Use Internetwork Performance Monitor• Preparing to Use Resource Manager Essentials• Using CiscoView


Preparing to Use Campus Manager

The following section will help you prepare to use Campus Manager:

• Processes and Settings, page• Device Discovery Settings• Data Collection Settings

Processes and SettingsThe following are the three main processes in Campus Manager:

• Device Discovery Discovers the devices available in the network, starting from the seed device. Updates this information to Device and Credentials Repository (DCR).• Data Collection Fetches the device list from DCR and collects the following data from the network: – Ports available in a device – VLANs present in the network/ device – Subnets in the network – Discrepancies in the network – Neighbor data for each device – Details about STP running in the network


Device Discovery SettingsUsing the Device Disfavor option, you can:

• Set SNMP target and credentials that will be used by Campus Manager to discover devices.• Configure the Seed device from where Campus Manager starts discovering the network.• Configure the range of IP addresses that need to be discovered.• Schedule the time intervals at which Device Discovery runs. You can configure the Device Discovery Settings either using LMS Setup Center or using Campus Manager Administration.

Go to Campus Manager > Admin > Device Discovery and configure thesesettings.

Data Collection SettingsUsing the Data Collection option, you can:

• Specify the time period at which SNMP queries time out, and the number of retries that can be attempted by Campus Manager before it stops querying the device.• Include or exclude devices for Data Collection by setting appropriate filters.• Schedule the time intervals at which Data Collection runs. You can configure the Device Discovery Settings, either using LMS Setup Center or using Campus Manager

Administration.Go to Campus Manager > Admin > Data Collection and configure these settings.


Preparing to Use Device Fault Manager

This section contains:

• Enabling Devices to Send Traps to DFM• Configuring SNMP Trap Forwarding

Enabling Devices to Send Traps to DFMSince DFM uses SNMP MIB variables and traps to determine device health, you must configure your devices to provide this information.

Enabling Cisco IOS-Based Devices to Send Traps to DFMFor devices running Cisco IOS software, enter the following commands:(config)# snmp-server [community string] ro(config)# snmp-server enable traps(config)# snmp-server host [a.b.c.d] traps [community string]

Enabling Catalyst Devices to Send SNMP Traps to DFMFor devices running Catalyst software, enter the following commands:(enable)# set snmp community read-only [community string](enable)# set snmp trap enable all(enable)# set snmp trap [a.b.c.d] [community string]


Preparing to Use Internetwork Performance MonitorThe following sections explain you how to get started and work with Internetwork Performance Monitor.

• IPM Application Settings

IPM Application SettingsYou can perform the application setup tasks in the Application Settings page. Go to select Internetwork Performance Monitor > Admin > Application Settings to launch this page.

Preparing to Use Resource Manager EssentialsThe following sections helps you to get started with Resource Manager Essentials:

• Setting Up Inventory• Setting Up Syslog Analyzer• Setting Up Software Management• Setting Up Configuration Management

Setting Up InventoryThis section describes the tasks that you must perform to set up the Inventory application. To set up RME Inventory, you should perform the following tasks:• Create network inventory by either adding device information by adding one device at a time or performing Bulk Import from DCR.• Obtain the login privileges to Cisco.com. See Logging Into Cisco.com for Software Management Tasks, page 5-78 for more information.• Schedule inventory polling and collection.• Set change report filters.• Display a detailed device report


Setting Up Syslog AnalyzerConnect to the device using Telnet and log in. The prompt changes to hostEnter enable and the enable password The prompt changes to host#.Enter configure terminal.

You are now in configuration mode, and the prompt changes to host(config)#.

• To make sure logging is enabled, enter logging on.• To specify the RME server to receive the router Syslog messages, enter logging IP address, where IP address is the server IP address.• To limit the types of messages that can be logged to the RME server, enter logging trap informational

to set the appropriate logging trap level by, where informational signifies severity level 6.

Using CiscoView CiscoView is a graphical SNMP-based device management tool that provides real-time views of networked

Cisco Systems devices. You can use CiscoView to:• View a graphical representation of the device, including component (interface, card, power supply, LED)

status.• Configure parameters for devices, cards, and interfaces.• Monitor real-time statistics for interfaces, resource utilization, and device performance.• Set user preferences.• Perform device-specific operations as defined in each device package.• Manage groups of stackable devices.


Performing Maintenance on Your CiscoWorks Server


The CiscoWorks server maintenance tasks include

• Performing Regular Backups• Purging the Data• Maintaining the Log Files

Performing Regular BackupsYou can schedule immediate, daily, weekly, or monthly automatic database backups. You should back up the database regularly so that you have a safe copy of the database.

Go to the CiscoWorks Home Page and select Common Services > Server >Admin > BackupThe Set Backup Schedule dialog box appears.Enter the following:

• Backup Directory—Location of the backup directory.• Generations—Maximum number of backups to be stored in the backup directory.• Time—From the lists, select the time period during which you want the backup to occur. Use a 24-hour format.• E-mail—Enter a valid e-mail ID in this field.• Frequency—Select the backup schedule:

The Time field is not enabled if you have selected Immediate as the Frequency.Click Apply.


Purging the Data

Data purging is deleting data that you no longer want. You can purge the data for the following reasons:• Databases are growing at an uncontrollable rate.• System performance is affecting the efficiency.• It is expensive to upgrade hardware.• To speed up migrations by reducing the volume of data to convert.• To ensure agility in the disaster recovery plan.


RMEYou can purge RME data by performing these tasks:• To purge the archived configurations, select Resource Manager Essentials > Administration > Config Mgmt > Archive Mgmt > Purge Settings.The Purge Settings page appears from where you can purge the required configurations.• To purge the Syslog messages, select Resource Manager Essentials > Administration > Syslog > Set Purge Policy.The Set Purge Policy page appears from where you can purge the required messages. • To purge the Change Audit data, selectResource Manager Essentials > Administration > ChangeAudit > Set Purge Policy.The Set Purge Policy page appears from where you can purge the required data.• To schedule purge operations for the RME jobs, select Resource Manager Essentials > Admin > System Preferences > Job Purge. The Job Purge page appears from where you can schedule the required purgeactivities.

Maintaining the Log FilesThe Logrot utility helps you manage the log files in a better fashion. Logrot is a log rotation program that can:

• Rotate log when CiscoWorks is running.• Optionally archive and compress rotated logs.• Rotate log only when it has reached a particular size.


What is Common Services



What is Common Services?

CiscoWorks Common Services are a set of management services that are shared by network managementapplications in a CiscoWorks solution set.

Common Services provides the foundation for CiscoWorks applications to share a common model for datastorage, login, user role definitions, access privileges, security protocols, as well as navigation. It creates astandard user experience for all management functions. It also provides the common framework for all basicsystem level operations such as installation, data management including backup-restore and import-export,event and message handling, job and process management, and software updates.The CD-ROM that contains CiscoWorks Common Services 3.0 also includes the following components:

• CiscoView —A graphical device management tool• Integration Utility —An integration module that supports third-party network management systems (NMS)• Device Center – A feature that provides a one-stop place where you can see a summary for a device, and launch troubleshooting tools, management tasks, and reports for the selected device. Some of Cisco’s management products integrate CiscoWorks Common Services into their general installation and runtime environments. Providing this support enables a common user experience and allows the application to leverage information from other Common Services-based applications. Information on installation, usage and available updates for Common Services versions bundled with these Cisco management products are generally located on the primary product’s web pages.




Common Services OverviewCommon Services is a collection of common management services that are shared and used by allCiscoWorks applications. Common Services provides a foundation for CiscoWorks applications to share acommon repository for devices and their associated credentials, login, and access privileges. It also providesthe common framework for all basic system level operations such as installation, backup, event andmessage handling, job and process management, and licensing.

Common Services consists of the following five major service categories:

Homepage - Provides a launch point and top level navigation for CiscoWorks applications installed on localand remote servers, CiscoWorks resources, Cisco.com resources, other web-based applications, productupdates, and urgent messages regarding CiscoWorks.

Security – Provides local or remote AAA services, secure communication between client and server, securecommunication between servers in multi-server deployment allowing for shared resources.

Device Management – Provides a common centralized repository for devices and their access credentials tobe used by all CiscoWorks applications. Also provides the framework for creating groups of devices to assistin troubleshooting and reporting activities.

Software Center – Provides a mechanism to retrieve the most current CiscoWorks software updates anddevice package updates used by CiscoWorks applications.

Admin – Provides administration services for managing the CiscoWorks server including backups, processmanagement, job status, diagnostic tools, and server licensing.


Features


CiscoView

CiscoView is an application that is part of the Common Services software. CiscoView is a graphical devicemanagement tool that uses SNMP v2/v3 to retrieve or set performance and configuration data fromnetworked Cisco devices. Using the performance data retrieved, CiscoView provides real-time views ofCisco devices. These views deliver a continuously updated physical/logical picture of device configurationand performance conditions. With the proper user authorization, the user can also configure a Cisco device,its cards and interfaces. The user can also monitor real-time statistics for interfaces, resource utilization, anddevice performance.CiscoView simply uses SNMP to query the configuration and performance of the device and displays theinformation graphically. Given the proper user authorization privileges, CiscoView can also be used tochange or modify the configuration of the device using SNMP.CiscoView is a powerful SNMP configuration and monitoring tool for Cisco devices and alleviates the needfor using the command line interface (CLI) to perform device configuration and monitoring.



Device Center

The Device Center is an application that is part of the Common Services software. The Device Centerprovides a “Device Centric” view for a single device that includes both data and links to execute tasks invarious applications. Device Center allows you to perform device-centric activities, such as changing device attributes, updating inventory, Telnet etc. depending on the applications which are installed on the Common Services server. You can also launch Element Management tools, reports, and management tasks all specific to the selected device.


NMS Integration Utility

CiscoWorks Integration Utility (IU) is a utility that integrates CiscoWorks applications with third-party Network Management Systems (NMS). The Integration Utility is installed on the platform hosting the NMS. The operating systems supported are:

• Solaris 2.8, 2.9• HPUX 11.0• AIX 5.1

• Windows 2000 Professional, Server, or Advanced Server with SP3 or SP4• Windows 2003 Server Standard or Enterprise Edition The NMS systems supported are:• HP OpenView Network Node Manager (NNM) versions 6.4, 7.0, and 7.0.1• NetView version 7.1 This utility adds Cisco device icons to topology maps, allows Cisco MIB browsing from NMS, integrates traps, and sets up menu items on the NMS to launch remotely installed CiscoWorks applications, such as CiscoView and Device Center.



Device Management










CiscoWorks Campus Manager


CiscoWorks Campus ManagerThe Campus Manager suite of applications provides powerful tools that automate and simplify the challengesjust described. Campus Manager auto discovers Cisco devices, Virtual Trunk Protocol (VTP) and ATMdomains, and VLAN memberships on the network. These items can then be displayed in a topology map,making it much easier to understand the network layout and connectivity of devices. Details about eachdevice and link are also available in the topology map, including IP address, connected interface and portnumbers, and line speed. In addition, reports provide information on logical and physical discrepancies,such as mismatches in link speed on each side of a connection, making it much easier to determineconfiguration errors.





A Closer Look At Campus ManagerCampus comprises three separate tools that can be used to manage and monitor layer 2 and 3 Ciscodevices on your network, and help address the challenges mentioned at the beginning of this chapter.Topology ServicesWith topology services, you no longer have to trace cables from stack to stack through a wiring closet todetermine which devices are connected through which ports. Topology Services auto discovers Ciscorouters and switches on the network and displays the network layout in hierarchical topology maps. Thesemaps make it easy to determine what types of devices are on the network, and how they are connected. Inaddition, topology services auto discovers ATM and VTP domains and VLAN memberships configured on thenetwork, making it easy to view and track them. It also provides features to allow you to create and modifyVLANs, LANE, and ATM services through an easy-to-use GUI. Automated discrepancy reports highlightphysical and logical problems with the network configuration, making it easy to identify configuration errorssuch as line-speed mismatches on either end of a connection.User TrackingThe User Tracking tool greatly simplifies the task of tracking user and end-station connections to thenetwork. User Tracking automatically identifies all end stations connected to Cisco devices that have beendiscovered on the network, including printers, servers, and PCs. User Tracking also collects detailedinformation about each end-station, including MAC address, IP address, Domain Name System (DNS)hostname, port assignment, and VLAN memberships. In addition, User Tracking can be configured to collectusernames associated with end stations, from UNIX hosts, a Windows NT primary domain controller (PDC),or Novell Directory Services (NDS), making it easier to locate specific users on the network. User Trackingprovides a means to track VLAN memberships, port assignments, and end-user host specifications.Path AnalysisPath analysis is a diagnostic tool for troubleshooting connectivity-related problems between end stations andLayer 2 and 3 devices. You can trace the Layer 2 or 3 path between any two endpoints on the discoverednetwork, making it much easier to narrow down where the problem might be when connectivity is lost. Pathanalysis provides more detailed information about each device than typical trace output, including interfacetype and speed and VLAN information. Output can be viewed in graphical, table, or trace output format.




Functional Flow – SNMP v2, v3 and Device CredentialsAs noted earlier, Campus Manager relies on the DCR to get device names, IP address, and their credentials that are needed to access the device and its configuration. The credentials needed are stored in the DCR and are made available to the CiscoWorks applications to use.Starting with Campus Manager v4.0, SNMP v3 is supported in addition to SNMP v2. The user has the option to use either version. SNMP v3 utilizes a configured username and password on the device. The method of authentication (SHA-1 or MD5) can be configured and selected.Note's• Refer to the Common Services tutorial or on-line help for details on defining the credentials andadding them to the DCR.• Refer to the Common Services on-line help or Cisco.com for details on configuring your devices for SNMP v2 or V3.And finally, before taking a closer look at Campus and its components, let’s briefly explore a Campus task that can be used to populate the DCR (Device Discovery).




Topology Services – What is it?

Topology Services is basically knowing how devices are physically interconnected and their associatedphysical and logical configuration information. Though this sounds basic and simple, Topology Servicescontains a rich set of features and tools to display and configure this information.

Topology Services provides comprehensive connectivity information that allows for network visualizationincluding the exact endpoint ports for each connection and the link speed. Besides maps, Topology Servicesincludes numerous reports to view different aspects of physical and logical connectivity, and a number oftasks that allow you to modify some of the physical (STP) and logical (VLANs) connectivity, and a completeset of ATM management tools.

This section will break Topology Services down into these three categories (visualizations, reports, andconfiguration tasks) to discuss and present some of the key features of topology services for completemanagement of physical connectivity, discrepancies, VLANs and VTP, STP, and ATM.



Topology Services – Connectivity VisualizationsThe first area of Topology Services we will explore is the most obvious – the topology maps. Granted, there are many tools out there that create and display a map of the network; the Campus maps are not a replacement for these tools, but rather Campus presents the data in a manner that facilitates the troubleshooting and management of the network on a day-to-day basis. There are many different views of the network each useful in their own way depending on the task at hand. Before launching the maps, summary information is provided which differs depending on the view selected. This information might be as simple as the devices in the view, or all the ports across the VTP domain for a selected VLAN.

The maps themselves are packed with features that allow you to customize their layout and quickly searchfor specific devices or device types and launch reports or configuration tasks.

Besides the connectivity based views, a special view can be displayed that shows the current STP state ofeach link in a STP instance. Later in the other subsections of Topology Services, we will see additional STPreports and tasks to actually modify the STP configuration.



Topology Services – View TypesTopology Services contains many different views each with their own merits depending on the task at hand.When launched, the left-hand side of the topology window will contain a navigation tree of the possible views.Three main categories of views are available:• Managed Domains – discovers all ATM and VTP domains. ATM domains are listed by fabric.Note(s):• For a VTP v2 domain, VLANs under the server and client mode devices will be listed directlyunder the top level tree.• For a VTP v3 domain, primary server, transparent and VTP-off mode devices will be listedunder the top level tree and the VLANs on secondary servers and client mode devices will belisted under the Primary server mode devices.• For a VTP v3 domain, switches listed and followed by a “P” are primary servers, and iffollowed by a “T” are configured in Transparent mode. Opening these will also list the VLANsdefined on them. A switch followed by the letter “O” has VTP disabled.• Network Views – Contains various device views of the network.• The LAN Edge View displays all layer 3 devices and clouds representing the switches.Expanding the LAN Edge View entry reveals the Switch Clouds discovered and automaticallylabeled. Switch Clouds consist of layer 2 devices and by definition could be VTP domainsand are STP domains. The default names of the Switch Cloud, which are sequentiallynumbered, can be renamed. The Layer 2 View simply displays all devices interconnected atlayer 2, and the Unconnected Device View shows managed devices not connected to anyother device. Expanding the VTP Views also lists all discovered VTP domains, but only liststhe devices in them.• Topology Groups – All CiscoWorks applications contain system defined groupings of devices andalso allow the user to create their own groupings of devices. These groups are listed under this handling



Topology Services – Summary Information

Campus Manager v4.x has expanded support for VLAN and VTP, including VTP v3. Information on VTPv2or VTP v3 can be viewed in Topology Services.As illustrated, note the following:

• For a VTP v2 domain, VLANs under the server and client mode devices will be listed directly under thetop level tree.

• For a VTP v3 domain, primary server, transparent and VTP-off mode devices will be listed under thetop level tree and the VLANs on secondary servers and client mode devices will be listed under thePrimary server mode devices.

• For a VTP v3 domain, switches listed and followed by a “P” are primary servers, and if followed by a“T” are configured in Transparent mode. Opening these will also list the VLANs defined on them. Aswitch followed by the letter “O” has VTP disabled.Also illustrated are the various icons used to differentiate the normal VLANs and Private VLANS and theirdesignated modes. More on Private VLANs is discussed later in this chapter and Chapter 3.



Topology Services – Summary InformationSelecting any view in the navigation tree of the main Topology Services window will list a summary ofinformation about the view on the right-hand side of the window. The displayed summary informationdepends on the view selected. For instance, selecting a VTP Domain under the Managed Domain headingdisplays information about all ports in that domain, where as selecting a VTP domain under the NetworkViews category displays the devices participating in that VTP domain.

Earlier it was mention that trying to find all ports in a VLAN could be a very time consuming task; now withTopology Services, the user simply needs to navigate to the desired VLAN and all ports in that VLAN will bedisplayed showing Port Status (up, down) and Port Mode (PVLAN-Host, Promiscuous, or non-PVLAN).



Network administrators no longer have to trace wires or probe switch tables to figure out where end usersare connected. The User Tracking tool is designed to assist in locating end-station connections at theaccess switch. This is a useful tool for troubleshooting or connectivity analysis. Through automatedacquisition, a table of end-user stations and layer 2 connection information is constructed. This table can besorted by column headings and queried, allowing administrators to easily find users by login name, MAC andIP address, or the switch port and switch to which the user is connected. In addition, predefined reportsenable managers to locate mobile users or violations in port policies, such as duplicate MAC addresses perswitch port or duplicate IP addresses.The User Tracking tool automatically locates end nodes, such as servers, workstations, or Cisco voice-over-IP (VoIP) telephone handsets, connected to Layer 2 Cisco devices on the network. During the discoveryprocess, User Tracking collects and stores specific connection information about each end station, including:• Domain Name System (DNS) host name, IP address, MAC address• Name and IP address of switch that end node is connected to, along with port number, name, andstatus• VLAN Trunk Protocol (VTP) domain, VLAN name and type• User login name passed from Windows NT primary domain controller (PDC) or Novell DirectoryStructure (NDS), or directly from the UNIX hostA user can also optionally download a Windows program to their desktop that allows for the quick query ofthe user tracking database without being logged into CiscoWorks. This program is called the User TrackingUtility and is discussed later.



User Tracking – End-Station Database

The User Tracking tool is an incredible time saver, it automatically collects and presents information vital fortroubleshooting the connectivity of end users or IP phones. The figure above displays the end-stationdatabase. As will be discussed shortly, the format of the display can be modified to fit the preference of auser, and displayed information can be quickly found through the use of filters. The particular figure aboveshows all entries, but as will also be seen shortly, the user can query the database to limit what is displayedto even further streamline the troubleshooting process.

User Tracking – IP Phone Database

Besides the database of end users (server, workstations, printers), User Tracking also keeps a separatetable listing all discovered IP phones registered with discovered media convergence servers to facilitate thetroubleshooting of VoIP operations.



User Tracking – Database Queries

When the User Tracking application is first launched (or the Reports tab is selected) the user is presentedwith a Quick Report dialog that allows for a query into the database using any of the collected fields ofinformation and a variety of compare type operators. By using the wildcard “*” in the Pattern field, theresulting report will display all entries in the database.

Alternatively, the user can create custom reports using the Custom Report Wizard which allows for moregranular queries. After entering the Query Expressions, the user can select the View button to see theresults. This Custom Report can also be saved (finish the wizard) and be run at a later date(s) using theReport Generator.



User Tracking – Report Generator

Allows for the scheduled execution of Duplicates, Custom, All Entry, and Switch Port Usage reports. Theuser can select the layout format and the time to run the report either immediately, once, or on a reoccurring basis. Reports that are generated with the Run Type set to Immediate will be immediately displayed. Reports scheduled to run at a later date and/or time, will be archived and can be viewed by selecting the report in the archive.



User Tracking – Violation Reports

User Tracking provides several reports that can help you identify conflicts with end stations that could lead topotential problems on the network. The following four reports are available to identify certain kinds ofduplicate connections that could result in network connectivity and performance problems.• Duplicate IP addresses—Typically, each host must have its own, unique IP address. If two hostshave the same IP address, they might not function correctly. If you find duplicate IP addresses, assignnew, unique IP addresses, as appropriate.• Duplicate MAC addresses—Typically, each host has its own, unique MAC address. If two hostshave the same MAC address in the same VTP domain, they might not function correctly. If you findduplicate MAC addresses, assign them to different VTP domains or VLANs, as appropriate. Note: Ona Sun workstation, you can assign the same MAC address to all the network interface cards.• Duplicate MAC addresses and VLAN names—Typically, each host has a unique MAC/VTP/VLANcombination. Multiple hosts with the same MAC address and VLAN name indicate a network misconfiguration.If you find duplicate MAC addresses and VLAN names, assign them to different VTPdomains or VLANs, as appropriate.• Ports with multiple MAC addresses (hubs)—Ports being shared by multiple hosts might not yieldthe best performance. If you locate a server system on a port with multiple hosts, consider moving thatsystem off the hub and connecting it to a direct port to improve performance.These reports are executed using the Report Generator and selecting the Duplicates application and then thedesired report. Like any report executed using the Report Generator, these reports can be run immediately,scheduled for a later date and time, or can be scheduled to run periodically.



User Tracking – Switch Port Usage ReportsUser Tracking provides several reports that can help you identify usage of switch ports. The following threereports are available to identify different states of ports.• Recently Down – Operating Status recently Up but is now Down, Administrative Status Up or Down• Unused Down – Operating Status Down, Administrative Status Down• Unused Up – Operating Status Down, Administrative Status UpThese reports are executed using the Report Generator and selecting the Switch Port Usage application andthen the desired report. Like any report executed using the Report Generator, these reports can be runimmediately, scheduled for a later date and time, or can be scheduled to run periodically.



User Tracking – User Tracking Utility

The User Tracking Utility is a Windows only application that can be downloaded from Cisco.com andinstalled on a client machine. During installation, the user is asked to configure the hostname or IP addressof the CiscoWorks server where Campus Manager resides, and a valid CiscoWorks login and password.Once installed on the client’s machine, the tool bar will display a field to enter User Information. Using wildcards if desired, enter a User name, IP Address, Host Name, or MAC Address. A Pop-Up will display with allhosts found matching the query. Click on an entry to see all the details. Clicking Copy All to Clipboard putsdetailed information on all returned devices to the clipboard.This application is extremely useful for quickly getting desired information on a user without having tonavigate through the CiscoWorks user interface.This completes the brief look at the User Tracking features of Campus Manager. Now, let’s look at the PathAnalysis tool within Campus Manager.



Path Analysis – What is it?

The Path Analysis application is an operations and diagnostic tool that traces the connectivity between twospecified devices on your network; not just the layer 3 path like the trace route command, but also thephysical path providing you with a much more complete picture of the path for troubleshooting.In addition to data traces, Path Analysis can also be used to trace the path for IP calls. For extendedtroubleshooting efforts, Path Analysis can also be schedule to occur at a specific time or repeatedperiodically.



Path Analysis – Data Trace – Graphical

Conducting a trace in Path Analysis is easy. You simply specify the source and destination nodes, and clickStart Trace.Path Analysis uses information gathered from Topology Services (topology, STP, VLAN, and LANEconfiguration), User Tracking, SNMP requests, traceroute, and Internet Control Message Protocol (ICMP)pings to perform the trace. When the trace is complete, output can be displayed in one of three formats:• Graphical map• Trace• TableThe graphical map output is displayed above. It includes an icon for each device determined to be in thepath. On the left side of the device icons, links between the devices show the layer 3 path. On the right sideof the device icons, links between the devices show the layer 2 path. Dashed lines indicate that the route is a“best guess” and might not be accurate because there is missing or conflicting information. Solid linesindicate that there is a high probability that the information is accurate because path analysis foundsupporting data from SNMP, traceroute, or NMS queries.

Placing the cursor over any device or link will display additional details. For devices, information mightinclude device type, class, and uptime. For links, it might include link type, delay, and from and to address.Information displayed will depend on the type of device or link, and the reliability of information that Path

Analysis was able to obtain. Trace output can be saved by selecting File>Save Trace As from the PathAnalysis menu. This will save all three formats (map, trace, and table) in a special .trc file that can be reopened and viewed in the path analysis tool at any time.



Path Analysis – Data Trace – Text

Besides the graphical map output of the trace, Path Analysis also includes text output of the trace.The Trace tab displays results of the trace in a format very similar to the common trace route command. Usethis output to determine the delay between hops along the path, which can help identify slow response timesand bottlenecks.In addition to the information usually displayed from a trace route command, the Path Analysis trace outputincludes layer 2 hops and both incoming and outgoing interfaces. It also displays the method by which PathAnalysis obtained the information, in the Learned By field. Path Analysis uses one of the following fourmethods to determine each hop on a traced route: SNMP requests, NMS server queries, trace routecommand, best guess. If “best guess” is listed in the Learned By column, this indicates that Path Analysiswas not able to obtain the necessary information from one of the other three sources, or information fromsome of these sources was conflicting. Best-guess information might not be accurate, but it should not beconsidered very reliable.The Table tab provides additional information about the trace, if available. Details will be available only ifPath Analysis can obtain the information from the server database or User Tracking table.The following information is listed in a table format:

• Device IP address, alias, class, type, and uptime• Connected interface name, address, mask, type, speed, MTU, and index number• MAC address• VTP domain and VLAN name• ATM fabric, ELAN name, virtual path identifier (VPI), and virtual channel identifier (VCI)



Path Analysis – Highlight Data Trace on Map

Any data or voice call trace can also be highlighted in a Topology Services network view. This provides extravisual reference during troubleshooting activities.



Path Analysis – Voice Trace Set-Up

You can determine the data paths and troubleshoot the signaling paths that voice-over-IP (VoIP) traffic uses on the network by data tracing the path from the IP Phone to the Cisco Call Manager. Additionally, you can trace the flow of voice packets for three types of VoIP telephone calls on your data network: completed calls, calls in progress, potential calls (calls that did not occur, but may occur in the future). For calls in progress or potential calls, use the IP phones IP addresses garnered from the User Tracking data base and perform a Data Trace.To trace a completed call, use the Voice Trace option. Performing a voice trace requires only slightly more effort when setting it up. From the Path Analysis window select Voice Trace. This will activate the button Find Call; select it. This will bring up the dialog to query the Call Details Record (CDR) database on any Cisco Call Manager known to Campus. Query the database to find the completed call to trace, highlight it, and select Start Trace.


Path Analysis – Voice Trace ResultsThe outputs for the voice traces are exactly the same as the output for the data traces.



Path Analysis – Scheduled Path Analysis

Various operational tests or troubleshooting activities may require the running of a trace at a specific time, orto run it periodically. Therefore, Path Analysis can be scheduled. Scheduling a Path Analysis is not donefrom the Path Analysis window, but rather from the Campus Manager Administration screen. Once theCampus Manager Administration screen is launched, select the Admin tab and the Schedule PathAnalysis option.

In the dialog that is displayed, simply choose the desired execution schedule and the source and destinationnodes. To view the results of the scheduled traces, return to the Path Analysis window an select Edit > ViewScheduled Traces from the menu. Output will be the same as if running Path Analysis live.This completes are brief look at the features of Path Analysis. Next, we will look at a few additional featuresthat add to the flexibility of the Campus product.


Resource Manager Essentials



Cisco realizes that to efficiently maintain and troubleshoot a large network, network administrators needaccess to current network information and efficient tools to help in configuration and troubleshooting tasks.Since their time is at a premium, these tools need collect and process the information with little or nooperator intervention. CiscoWorks Resource Manager Essentials (RME) does exactly this, meeting the main goals of what a configuration management tool should do



RME Time Savings

The network administrator is a busy person and time is a valuable commodity. Yet information is needed andconfiguration tasks need to be performed. RME provides a collection of tools to simply do what the networkadministrator doesn’t have time to do, freeing time up so they can go about their business of providing aconsistent, worry free network for the users.




RME Overview

RME is the cornerstone application for the CiscoWorks LMS bundle of infrastructure management toolsfocusing primarily on configuration management tasks. It includes many automated features that simplifyconfiguration management tasks, such as performing software image upgrades or changing configurationfiles on multiple devices. RME also includes some fault-management features, such as filtering of Syslogmessages.RME consists of the following major components:• Inventory Manager - Builds and maintains an up-to-date hardware and software inventory providing reports on detailed inventory information.• Configuration Manager – Maintains an active archive of multiple iterations of configuration files for every managed device and simplifies the deployment of configuration changes.• Software Manager – Simplifies and speeds software image analysis and deployment.• Syslog Analysis – Collects and analyzes Syslog messages to help isolate network error conditions.• 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




RME Functional Flow

The key to RME is its ability to keep the database up-to-date with all configuration information includingdevice inventory, software images, and configuration files. A benefit of this activity is the ability for RME todetect and report changes. RME uses various transport protocols necessary (i.e. SNMP, Remote CopyProtocol (RCP), Secure Copy Protocol (SCP), TFTP, Telnet, Secure Shell (SSH), and HTTPS) to access thedevices and retrieve the necessary data.

The best part about using RME for your network management needs is that many of its features areautomatic, freeing the network administrator from mundane data collection activities. To start using RME,the administrator has to add the devices to be managed and provide the proper access credentials (SNMPcommunity strings, passwords). Most of the collection activities already have a default schedule and begincollecting as soon as the devices are added.

User access to RME is through a standard web browser (refer to Chapter 4 for specific versions and clientrequirements). RME relies on the CiscoWorks server for common services. These services withinCiscoWorks are call Common Services (CS), such as the database engine, online help, security, login,application launching, job and process management, and the Web server.



What is Inventory Management?

Inventory Management is basically knowing what Cisco devices are actively deployed in the network andbasic information about them - How many 7200 routers are there? What devices are running IOS v12.01?How many empty switch slots are there?

Inventory Management provides comprehensive device information, including hardware and software details.This information is crucial for network maintenance, upgrades, administration, troubleshooting, and basicasset tracking. The inventory information can also be leveraged by other applications needing access to thissame information without the need for additional device queries. Network administrators must often be ableto quickly provide information to management on the number and types of devices being used on thenetwork. The more information network administrators have in one central place about all the devices, theeasier it is to locate necessary information, resolve problems quickly, and provide detailed information toupper management.

Inventory Management is also the starting point for many other management activities. For example, toupgrade the software image of a device, information about the amount of RAM, the modules installed, andthe current software version is needed. All this data is collected by RME Inventory Management!



How Inventory Management Works

The first order of business is adding devices to be managed by RME. The devices are added from theDevice and Credentials Repository (DCR) which is a component of Common Services (briefly discussednext). RME can be configured to automatically import any device from the DCR into RME, or it can also bedone in a more selective manner. The first scenario in Chapter 3 will have more details on this topic.Once RME is informed of the devices to be managed (the SNMP read community string for the device mustalso be in the DCR), RME polls the MIB of the device and retrieves all necessary inventory information.Inventory Management can now be configured to automatically re-retrieve the inventory information on aperiodic basis in order to keep the database current and to detect any changes. (By default, a scheduleexists.) If any changes are detected in hardware or software components, the inventory database will beupdated and a change audit record will be created to inform the network administrator of the change and as ameans to document the event. This helps to ensure that the information displayed in the inventory reportsreflect the current state of network devices.



Grouping of Devices

Most every RME task is executed against a set of devices. When thousands of devices are being managedthis will present some difficulties when trying to select specific devices for the task. For instance, a thousanddevices are being managed and a detailed hardware report needs to be run for only the 7200 routers.

RME, and CiscoWorks in general, uses the concepts of groups to simplify the selection of devices. AllCiscoWorks applications introduce default groupings. For example, Common Services has default systemgroups that categorize devices by type in a hierarchical manner (routers, 7200 router, etc). When selectingdevices for an RME task, these groups can be used. A device can belong to multiple groups.RME, and other CiscoWorks applications, also allow users to create their own groups. These groups arecreated using a set of rules and can be configured to be automatically populated or only with userintervention basically making for dynamic and static groups. Further, groups can be limited to only theoriginal creator, or other CiscoWorks users.

This powerful feature further simplifies the use of RME if useful groups are created. Each device also has 4user fields associated with it (stored in the DCR) that can be used to help define groups. For example, UserField 1 could be assigned to device location.



Inventory Management Sample Report - Detailed Device Report

The above picture is an example of the Detailed Device report. It includes system, chassis, bridge,processor, and module information presented in an easy to read format. This report was executed in a matterof seconds for a single device, but can also be run for a number of devices at one time. This provides a vividexample of the power of RME as the data in this report for even a single device using telnet and showcommands would have taken quite some time to retrieve, and certainly would not be as well presented. Nowmultiply this by many devices, and the power of Inventory Management becomes even more evident.Note(s):

• The data field labeled ‘Updated at’ is a time stamp of when RME collected the data presented.• The picture also shows a list of the other pre-defined system reports that can be quickly generated.• RME also allows for the creation of custom inventory reports,



Report Options

RME is all about making network management easier and automating mundane tasks. This picture showshow the report generator can be used to schedule a report to be run on a periodic basis. This ability canassist in many troubleshooting activities and even allow for the automated reporting while safely at home.

Tip:

It is important to remember that reports are based on the data in the database and do not directlycontact the device. Therefore, a periodic inventory report only makes sense if an inventory collection occursbetween the subsequent running of the report, else the data will be identical.



What is Device Configuration Management?

Since network problems can often be traced to an incorrectly configured network device, device configurationmanagement can be defined as the practice of being well informed about the configuration of devices in thenetwork. Being “well informed” about the configuration of devices in the network means that in the eventanything happens to a device, its configuration can be quickly restored. This would indicate that there shouldbe some mechanism to record each version of configuration file for each device. This allows for the rapidrestoration to a previous configuration and the ability to track changes between versions.

Device configuration management should also include mechanisms to simplify the actual configuration ofdevices. Although perfectly functional, using telnet to access multiple devices can be time consuming andpossibly error prone if typing is not the forte of the administrator.



How Device Configuration Management Works

Configuration Manager is similar in operation as Inventory Manager. The first order of business is to createan archive of configurations and keep it up-to-date. The archive can be kept current using severalmechanisms as described below.

• The first is to configure a schedule for retrieval. This method retrieves the configuration file and compares it with the latest version in the archive, if different, a Change Audit record is generated andthe retrieved file becomes the latest in the archive.

• The second is to poll for the MIB variable indicating the time the configuration was last changed. If thisis different then the value for the latest archived version, then the image is retrieved. Obviously, thismethod is not as resource intensive as the first.

• The third method is to configure the devices to send Syslog messages to RME. The Syslog Analysisfunction has an automated task that will retrieve and archive a configuration if a Syslog message isreceived indicating a change has occurred. Of course, the second and third method still makes surethe retrieved file is different than the latest in the archive to ensure that each archived version isdifferent then the previous.

Once populated, the network administrator can search the archive, compare configurations, and use thearchived versions as a starting point for using the several configuration tools.



Config Editor

The Config Editor tool included with RME Configuration Manager allows the network administrator to edit and download configuration files to devices using a GUI instead of the commonly used command-line interface.

Use Config Editor to edit individual device configurations from the archive, and download them to a device.A copy of the updated configuration will automatically be stored in the configuration archive.Note(s):

• Config Editor is a full screen editor allowing for the user to modify, edit, or delete commands.• No syntax checking is performed!• Interactive commands are possible using the following syntax:

#INTERACTIVEcommand1<R>response1<R>response2command2<R>response1#ENDS_INTERACTIVE



NetConfig

The NetConfig tool provides wizard-based templates to simplify and reduce the time it takes to roll out globalchanges to network devices. These templates can be used to execute one or more configuration commandson multiple devices at the same time. For example, if you want to change passwords on a regular basis toincrease security on devices, you can use the appropriate password template to update passwords on alldevices at once. A copy of all updated configurations will be automatically stored in the configurationarchive.

NetConfig comes with many predefined templates that allow you to use a simple GUI to change manycommon device configuration parameters. These predefined templates include corresponding rollbackcommands. Therefore, if a job fails on a device, the configuration will be returned to its original state.



Baseline Templates

Baseline Templates allow for the creation of a set of commands containing placeholders for device-specificvalues to be substituted. These templates can now be run against a set of devices (of the same type orcategory) and the placeholders populated with the appropriate value for each device (with NetConfigtemplates, all devices included in the job get the same value for the command placeholders). BaselineTemplates can be used to identify a set of standardized policy based commands that you would want to haveon a set of like devices.

When a new device of the same type is added to the network, use a previously created Baseline Template toquickly bring the device into compliance with corporate policy. Baseline Templates can be created for anydevice or interface type.

Baseline Templates can also be used to compare existing device configurations against the templates todetermine which devices are non-compliant to the baseline template. The non-compliant devices can also bebrought into compliance as part of the same job.



What is Software Image Management?

So far this chapter has discussed the management of both the hardware devices and their configuration files.The third piece to consider for overall configuration management of the devices in the network is the systemsoftware or operating system of the device. For complete coverage, it makes sense to have a repository ofthe software images being used on the network so that in the case of failure the image can be pushed backdown to the device. Also, since improvements to the software are always being made, it would be nice tohave a tool to help in the deployment of the new images that reduces the time and effort to upgrade devicesto a new image.



How Software Image Management Works

Before any images can be deployed to network devices, the software images must be first imported intoRME to be maintained in the software repository. RME does include a mechanism to perform a baselineimport from all devices on the network, and a job can be schedule to ensure that all unique images on thenetwork are in the repository. In the case of failure, the proper image can now be deployed back to thedevice or its replacement.

To upgrade a device to a image not in the repository, it to must first be imported to the repository. This canbe achieved from another device, a file, or most likely from Cisco.com. Prior to being imported fromCisco.com, the device to be upgraded can be analyzed to determine if it has the proper resources to run theproposed image.

Any image that is stored in the repository can now be distributed to one or more compatible devices on thenetwork. Software distribution is performed in a reliable manner controlled by the network administrator.Each step of the deployment process is recorded, so if failure occurs, the network administrator will knowexactly why. Once upgraded, Change Audit will generate a change record to document the event.


Bugs Summary Report

The Bug Summary Report displays a summary of the software image bugs for selected devices. This list isretrieved from Cisco.com, hence a Cisco.com account is required to execute this report.



Upgrade Analysis Report

To avoid common resource related errors when upgrading the software image on a device, first use theUpgrade Analysis option to determine the impact to, and prerequisites for a new software deployment usingimages that reside in either Cisco.com or the image repository. An administrative task allows for the settingof certain criteria for an image to match in order to be analyzed against the device to be upgraded, todetermine possible required hardware upgrades (boot ROM, Flash memory, RAM, and access).



Add Images

RME allows for the importing of images into the repository from several different locations – another device,file, or Cisco.com. Images must be in the repository in order to be distributed to a device. The screen shotabove shows the images currently in the repository.

A special import can be scheduled to import a baseline of images from the network. Similarly, asynchronization job can be schedule to ensure the repository contains all unique images of the network.




Image Distribution

RME allows the network administrator to schedule a job that will reliable distribute images to one or moredevices. A software distribution job will record each step of the task so that if a failure occurs the networkadministrator will know exactly how to fix it. Images can be distributed directly from the server to the device,or by first distributing the image to a remote device and then have other devices retrieve it from there.



What is Syslog Analysis?

One of the best forms of management is done by the device itself, and is communicated via Syslogmessages. Syslog messages indicate some behavior or activity on a device. These can be strictlyinformational or can indicate a configuring change or even a failure. Imagine being informed of a networkproblem by the source and not by some irate user.

To leverage these useful messages, RME includes numerous reports to allow the user to view the receivedmessages, and even allows for the configuration of an activity upon the receipt of select messages.Of course to take advantage of this feature, devices must first be configured to forward Syslog messages toRME. This can be done easily using NetConfig!



How Syslog Analysis Works

In order to utilize the Syslog Analysis features, devices must first be configured to forward Syslogmessages to either the RME server or a remote Syslog Analysis Collection (SAC) server. The remoteSACs are used to distribute Syslog message collection and processing in order to reduce Syslog trafficand processing on the RME server. All messages collected and processed by the remote SACs areperiodically forwarded to the RME server, which maintains a central repository for all Syslog messages.

Syslog messages received by a collector are stored in the local Syslog facility on the server and areperiodically read by the Syslog Analysis function for processing. Each message is compared against userdefined filters to determine if the message is considered important enough to keep. Messages not filtered are stored in the Syslog database (time stamp is converted to GMT) and checked against another set of user-defined filters to determine if the message should initiate a user-defined script (automated action).The database is then used to produce the various Syslog reports (messages displayed using the servertime zone).

Any user-defined filters used for reducing the Syslog messages to be included in the Syslog database willbe forwarded to any defined SAC.



Syslog Analysis Sample Report – Severity Level Summary

The Syslog Severity report lists the number of Syslog messages received (and not filtered) for each Syslogseverity level for a selected time period and group of devices. Clicking on the number of received messageswill show details of each individual Syslog message.



What is Change Audit and Audit Trail?

One of the most powerful features of RME is its ability to detect changes to the inventory, configuration files,and software images. Not only is this a great way to see what changed, when, and by who, but it is also anautomatic way to document any changes made to the network.

Audit Trail tracks and reports changes that the RME administrator makes on the RME server. The list ofchanges that a system administrator can make to the RME server is huge and includes reports on changingpreference settings, deleting devices, changing device attributes, changing policies or schedules,adding/editing Syslog filters, and more. For a complete list, refer to the RME User Guide.



How Change Audit Works

Change Audit is pretty straight forward – the incoming data is compared against the most recent data in thedatabase, if it is different then a change record is created to document the finding. The change recordincludes details of the change and how it was detected.



Change Audit Sample Report

Change Audit reports can be run against a selected group of devices and/or for a selected change type(software image change, inventory change, configuration change, etc.) over a selected period of time.

The above report was generated for the previous 24 hours and shows two changes that were detected byChange Audit. The listing shows that NetConfig job number 1023 was responsible for the change to theconfiguration files. Clicking on the Details link, it launches a Configuration Diff Report showing that thecurrent configuration includes one additional command; the additional line “set logging server192.168.138.22” was added to the new configuration line.

Using Change Audit services, the user quickly knows what change was made, who made the change, andwhen the change was made.


Device Fault Management



The Importance of Device Fault Management

Looking at a typical day in the life of a network administrator readily highlights the need for faultmanagement. Although the server or other resource outside the management scope of the networkadministrator can cause many of the issues that are blamed on the network, to the user it is always thenetwork’s fault.

Unfortunately, many of the complaints are real network problems, and finding the cause of them can be areal challenge. Most notable among the challenges are where to start looking for the cause, and what to lookfor.



What is Fault Management?

With the need for fault management so easily recognized, it can be defined as the ability to quickly and easilyisolate, detect, and correct the conditions leading to undesirable network behavior. Typically, networkmanagers perform fault management activities after the problem has already occurred. Unfortunately, as willbe discussed in more detail later in this chapter, the presence of a problem doesn’t always indicate what theactual cause is, resulting in a tremendous amount of effort and time on the part of the network administratorto hunt down the culprit.

A better solution would be to employ fault management tools that proactively monitor the network forindicators that the device or network is beginning to degrade. The network administrator would now knowexactly what to fix, avoiding costly network service degradation.

This sounds easy enough, so why is it so hard in practice? Before answering this question, let’s first definewhat a fault is.



What Constitutes a Fault?

In simple terms, a fault is any condition that leads to unexpected or undesirable behavior. Typically, thealtered behavior is fairly easy to detect (for example, poor response time). The resulting behavior of the faultcondition can be seen as a symptom of the fault, but may not directly point to the actual condition that causedthe fault. The real challenge of fault management is to isolate the root cause of the condition that leads to thealtered behavior. Like a doctor making a diagnosis, you look at the symptoms to try to locate the problem, butunfortunately, many faults may exhibit the same symptoms (for example, long latency is a symptom that maybe caused by many different faults).

A primary goal of any fault management system is to detect the symptoms and isolate the condition early, toallow for correction before network service degradation starts. We now begin to see one of the reasons whyfault management is so difficult; next, we will look at an example that further highlights the difficulties ofimplementing a fault management solution.




Introduction to CiscoWorks DFM

Traditionally, fault management applications have simply determined whether a device was up or down. Withthe complexity of network infrastructure equipment in networks today, a device can be up but performingbadly, resulting in network performance degradation. Most fault managers therefore allow the network administrator to selectively poll specific MIB variables to determine the overall health of a device. Doing so, however, requires a great deal of knowledge to determine what constitutes a healthy device, and what MIB variables to poll to determine its health. Further, many times a single MIB variable does not tell the whole story; multiple variables in conjunction with events are required determine a particular health index.

DFM addresses these issues head-on by providing device-specific fault management out of the box. Youdon’t have to write complex rules or spend vast amounts of time performing difficult configurations.



A Quick Look at DFM Alerts

DFM has the built-in intelligence to determine what variables and events to look for to determine the health ofa Cisco device, without user intervention, for true fault management. DFM correlates events and determinestheir importance so that the event viewer is not flooded with useless information. The events for a device isaggregated together and the user can view the alerts easily for all devices in the DFM Alerts and Activitieswindow. For example, rather than reporting that all of the ports on a card are down, DFM reports only onealert that there is a interface problem with the device. The user can then drill down into the alert and see theevents that the card is down.






Alerts & Activities

The Alerts and Activities display is the main DFM task used on a day-to-day basis. It provides a consolidatedreal-time (updated every 30 seconds) view of the operational status of the network. The display is designedto leave up and running, providing an ongoing monitoring tool. When a fault occurs on the network, DFMgenerates an event or events that are rolled up into an alert and is shown on the Alerts and Activities display.To minimize device alerts displayed or to focus monitoring efforts, Alert Views are employed to show asubset of the devices being monitored by DFM. Additionally, filtering by alert or event severity and status isalso available.

The Alert and Activities display is just the starting point for viewing network fault activity. From this display,numerous drill downs are available to see more information about alerts, events, and device details.



Alerts and Activities Legend

As shown in the graphic above, the Alerts and Activities display uses icons as a means of quick glancestatus (severity and Last Change), and as launch points for additional tools.



Alerts and Activities Details

The Alerts and Activities display provides a consolidated view of alerts detected on the network. Each alertcan be comprised of one or more events. To see the details about a particular alert, drill down to the detailsby clicking on the Alert ID. This launches the Alerts and Activities Detail display. It lists each of the individualevents detected on the device containing the alert. Information on the individual events including the time oflast change help in determining the nature of the faults.

From this display, the network administrator can perform various actions in handling the alert. First, the alertcan be acknowledged indicating that it has been reviewed. The network administrator may decide to suspendfurther monitoring of a device while troubleshooting and resolution procedures take place or can add anannotation to the alert to inform other team members of the resolution status.

Finally, the Alerts and Activities Detail display allows for the launching of several other CiscoWorks tools toassist in the troubleshooting and resolution efforts.



Event Details

Like the Alerts and Activities display, the Alerts and Activities Detail display shows a summary ofinformation. To see actual values from the device that triggered the event, click on the Event Id to launch Event Details.

This display list actual variables and their value during the last polling cycle and anyassociated threshold helping the network administrator determine the extent of the condition.



Detailed Device View

As will be detailed in the next section of this chapter, DFM discovers the different components of a device tofurther define how it is to be managed. The Detailed Device View provides information on the devices anddevice components that DFM is managing.The Detailed Device View (DDV) can be launched by clicking on the device name within the Alerts andActivities display or using a separate task under the Device Management tab. The Detailed Device Viewdisplay can not only be used to view current values retrieved by DFM for the different managed components,but to also choose to un-manage (suspend polling) specific components.

Aggregated Devices

The illustration above shows a DDV for a Cisco Catalyst 6500 switch. This switch contains an MSFC card (acontained device). If you select the MSFC card, the DDV displays the managed state of the subcomponenton the right side of the display and a new DDV launch point is provided. To display a DDV for the MSFCcard, click Launch New DDV For This Device. The new DDV appears,



Fault History

Fault History stores and allows you to view the history of DFM events and alerts for the past 31 days. Thestored history includes alert information and annotations, and event information and properties (for example,the values of MIB attributes at the time of the event, polling and threshold information, and utilizationinformation).

Fault History can be launched in a variety of ways:

• From the Alerts and Activities display (icon in upper right-hand corner) – provides fault history for the last 24 hours for all alerts within the current view.• From the Alerts and Activities Detail display (pull down menu tool list) – provides fault history for last 24 hours for the selected event.• From the tasks within the Fault History tab – allows for granular searching of the database.• From the Common Services Device Center – fault history for device displayed in device center for either the last 24 hours or 31 days.



Device Center

The CiscoWorks Device Center application provides information for a single device that includes both dataand links to all CiscoWorks applications registered to Common Services. Device Center provides a centralpoint from where you can see a summary and reports for the selected device, invoke various tools on theselected device, and perform the tasks that can be performed on the selected device.

After launching device center, you can perform device-centric activities, such as changing device attributes,updating inventory, Telnet etc. depending on the applications which are installed on the Common ServicesServer. You can also launch Element Management tools, reports, and management tasks from the DeviceCenter.

The Device Center has a launch point from CiscoWorks Homepage, but is discussed here because it can belaunched for a device from the DFM Alerts and Activities Detail pull down tools list. The Device Centersummary shows information regarding any current alert for the device and also includes a link to the FaultHistory report.



Notification Services

The Alerts and Activities display is one of the main ways to use DFM on a day-to-day basis but would requireconstant visual contact to be alerted to changes in the fault state of the network. To free the networkadministrators from 24/7 visual contact with the Alerts and Activities display, DFM allows for alternate meansto notify personnel – E-mail, SNMP traps, and Syslog message. Each of these notification mechanismswould provide a summary of the alert/event. The receiver of the notification could then return to DFM formore details.

Notifications are sent based on subscriptions to notification groups. Basically a notification group is a set ofevents and alerts occurring on a set of devices. This allows for different recipients or notification mechanismsfor different devices and alerts for ultimate notification flexibility.



Polling and Thresholds

Though DFM comes pre-configured with polling and threshold parameters, DFM can be customized tomodify these parameters for all members of a class or to create custom classes or groups and define specificpolling and threshold values for them. What can’t be created is the ability to poll variables not currently polledby DFM.


Internetwork Performance Monitor




ICMP Ping Command

A common and easy-to-use troubleshooting technique for network professionals is the use of "ping”. Ping isa utility that uses the ICMP echo request/reply protocol to test for connectivity to an IP address. Pinging adevice from a station provides a quick response to device reachability and response time from the station tothe target IP device. However, using ping from your station to a remote node may not easily help you identifywhere the problem is in the network since the measurement may be occurring over a different network pathor over multiple hops. Also, the use of the ICMP protocol to measure response time does not accuratelyreflect the response time for your application. An apparently healthy network (i.e. quick ping response and/orlow utilization) can still mask potential response time problems. The problem may reside in the upper layersof the protocol stack.



Traceroute Command

The traceroute command shows the actual routes packets take between devices and can be used todetect routing errors between the network management station and the target device.By diagnosing TCP/IP Layer 3 (transport) problems, Traceroute helps you understand why ping fails orwhy applications time out. You can view each hop (or gateway) on the route to your device and how longeach hop took.



Third Party Network Analyzers or Probes

Another common tool used for monitoring and troubleshooting response time is the use of network analyzersor probes. A probe is generally a dedicated hardware device that is used to monitor a network segment’sperformance. For example, an RMON2 probe can analyze the existing network traffic and report on theconnected segment's utilization, top talkers, and conversations broken down by upper layer protocols.Probes can capture packets and analyze packet header information for an in-depth analysis of the networksegment’s activity.

A probe’s report on segment utilization and error counts can possibly assist the network professional inpinpointing network delays or problems. But in order to detect where the delay is within the network,numerous probes would need to be deployed along each hop of the application's path. Although valuableinformation can be obtained from a network analyzer or probe, it may not always be a cost-effective solutionto solving response time and availability issues. Dedicated probes are a better fit when conducting networkbaselining and trending link, protocol, and application utilization, as well as, characterizing and identifying thetop talkers and conversations.



Cisco IOS IP Service Level Agreements (IP SLAs)

Cisco IOS IP SLAs are embedded within Cisco IOS software. Using IP SLAs, there are no new devices todeploy, learn, or manage; Cisco IOS IP SLA provides a scalable, cost-effective solution for networkperformance measurement.

Cisco IOS IP SLAs collect network performance information in real time: response time, one-way latency,jitter, packet loss, voice quality measurement, and other network statistics. The user can continuously,reliably, and predictably measure network performance and proactively monitor network health. With CiscoIOS IP SLA, service level monitoring is automated, IP service levels can be assured, network operation canbe verified proactively, and network performance can be accurately measured.

Active monitoring continuously measures the network performance between multiple paths in the network, providing an ongoing performance baseline.Network administrators can also use Cisco IOS IP SLA as a troubleshooting tool. They can obtain hop-by-hop performance statistics between two Cisco routers or between a router and a server. If the network performance level drops during the operation (ie: due to congestion), the network administrator can promptly identify the location of the bottleneck and resolve the problem. Cisco IOS IP SLA can also perform a network assessment for a new IP service and verify Quality of Service (QoS) levels.Cisco IOS IP SLA measures performance by sending one or more simulate protocol test packets to adestination IP device or a Cisco router. Cisco IOS IP SLA uses the timestamp information to calculateperformance metrics such as jitter, latency, network and server response times, packet loss, and MeanOpinion Score (MOS) voice quality scores.



Cisco Devices that Support IP SLAs

Most Cisco IOS platform types provide support for the IP SLAs agent as illustrated above. The IOS softwarerelease levels depicted use the newly renamed IP SLAs agent software. Earlier IOS releases are stillsupported, however, IP SLAs are known as Response Time Reporter (RTR) or Service Assurance Agents(SAAs).




Workflow Step 1: Determine the Test Requirement

Before deploying IPM and IP SLAs, put together a service level monitoring plan. What is it that you are tryingto assess? Are you trying to deploy a new application or assess current critical services? If so, how will it bedeployed; who will use the new applications; and what would be an acceptable network response time?The best uses for IP SLAs are capacity planning, service validation, and real-time troubleshooting.Therefore, gather information about the network applications, protocols, application users, and theacceptable network latency.

• Capacity Planning – In order to guarantee a certain service level, it is extremely important to assess the capacity of the network, the traffic mix, and the traffic pattern.• Service Validation – Any guarantee requires validation. A network administrator has to continuously monitor the service level to make real-time adjustments and to plan for future services.• Real-time Troubleshooting – Just as the traffic in the network is dynamic and changes constantly, so does the service level of the traffic. Real-time monitoring ensures that the level of performance is achieved.

After gathering information about the network, determine the test points in the network. Where does thetraffic start (source router) and where is it going (target device)? Select existing Cisco IOS routers or placeother spare routers in the network for generating the test operations.Keep in mind that there is no additional cost to deploy IP SLAs, because it is part of Cisco IOS software.Similarly, there is no additional device to learn, deploy and manage. It is possible to monitor any given link inthe network, since Cisco offers a full line of routers (CPE to edge to core).





Workflow Step 4: View the Test Results

Of course, the last step in the workflow is to view the test results. Every hour, IPM polls the data from the IPSLA MIB and stores the data long term in its database. Without IPM it would be difficult to view and comparehistorical data.To view the results, IPM can pull the real-time data directly from the MIB in the source router or IPM can pullthe data from its database for historical viewing. As you will see later in this chapter, IPM can display the rawtest data in real-time or historical test data which is aggregated and analyzed statistically.









Documents

LMS 3.0