Lesson 1

Defining Network Management

Overview
Due to the increased use and complexity of networks, a proper network management strategy is
critical for the network administrator and the company. You must provide users with a
predictable high quality of service. You need a network management strategy to minimize
network downtime and take advantage of advances in technology. By using network
management tools and processes to gain visibility into the network, you can proactively resolve
problems, plan for changes in resource usage, and securely control and manage valuable
network resources.

Objectives
Upon completing this lesson, you will be able to define network management by identifying
goals for proper network operation and breaking the network down into functional areas. This
ability includes being able to meet these objectives:
 Define network management by identifying goals for proper network operation and the
evolution of network management
 Break network management down into the five functional areas defined by the ISO
 Describe the increased productivity and the ROI of network management
What Is Network Management?
This topic describes the goals for network management and breaks down network management
into functional areas.

What Is Network Management?

The Goals:
 Ensure that users of a network
receive information technology
services with the quality of service
they expect.
 Ensure the strategic and tactical
planning of the engineering,
operations, and maintenance
of a network and its services.
 Help network engineers manage
the complexity of a data network
and ensure that data can go
across the network with maximum
efficiency and transparency.
 Prepare for disaster recovery.

© 2007 Cisco Systems, Inc. All rights reserved. CWLMS v3.0—1-2

Network management can be defined in terms of the goals a company hopes to achieve from
employing a network management strategy. From the perspective of end users, the network
should provide consistent, high-level services. The actual method of providing the services
should be as transparent to the user as possible. The user does not care so much about the
network itself, but rather that they can retrieve their e-mail quickly at any time, access
application servers or network printers, transfer files, or browse web pages in a timely manner.

To ensure that these needs are met, network engineers and administrators need effective
network management tools to deal with network complexities, provide maximum efficiency,
and minimize downtime by preparing for disaster recovery.
 Evolution of Network Growth
Network traffic and
network technology

Growth

Network resources
(support staff, $$)

Time

 Networks are increasing in scale and complexity.

 You must not only manage the elements of the network infrastructure,
but also the services across the element.
 Support staff and budget do not always keep pace with technology.

© 2007 Cisco Systems, Inc. All rights reserved. CWLMS v3.0—1-3

A good network management strategy must be a high priority. Because of the ever-increasing
uses and complexity of networks, you must strive to keep up with network demands. Ten years
ago, the main concerns of a network administrator, for the smaller, less-demanding user
population, were uptime and availability. Today, uptime and availability are still important, but
now more complex issues must be considered, including IP telephony, secure remote access,
quality of service (QoS), and a larger, more demanding user population. You must now employ
a management strategy that maximizes network efficiency and helps to reduce demands on the
network administrator.

Unfortunately, the growth of a support staff and budget does not always keep pace with new
technologies being implemented in the network. You must often do more in your position with
less support and staff. Having the correct tools to automate many routine tasks can make your
job much more efficient.
What Is FCAPS?
This topic describes five functional areas of network management.

What Is FCAPS?

ISO defines five functional areas

of network management:

 Fault management
 Configuration management
 Accounting management
 Performance management
 Security management

Some management issues may span several areas.

© 2007 Cisco Systems, Inc. All rights reserved. CWLMS v3.0—1-4

To assist in focused management, the International Organization for Standardization (ISO) has
defined five functional areas of network management, known as the FCAPS model, as follows:
 Fault management
 Configuration management
 Accounting management
 Performance management
 Security management

Note Network issues do not always fit neatly into one functional area. Functional areas are used
to define various management issues.
A fault can be identified as a failure of a system, device, or component to operate as expected,
and requires action to resolve. Failures are indicated by excessive errors, such as alignment
errors in Ethernet. However, not all errors are considered faults. Some errors, such as collisions
in an Ethernet environment, are normal as long as they fall within an acceptable threshold.
Fault management is the detection, isolation, and correction of either persistent or transient
faults that cause networks to perform below expectations. Monitoring, the most basic function
of fault management systems, includes collecting information about device hardware and
software. Monitoring can also include data collection about device status, health, and
performance. Monitoring also includes post-collection analyzing and reporting based on the
data collected.
Documenting and understanding the network is at the very root of all network management
tasks. If you do not have a clear picture of network connectivity and the network configuration,
you cannot effectively maintain the network and resolve problems as they arise. Just as
important is that you have a secure and accurate archiving and tracking system for the
configuration files that drive network traffic. By maintaining an accurate archive of
configurations, you have better control of the network devices because you have rapid access to
vital configuration data about those devices, and you can compare and change configurations as
necessary.
Accounting management systems focus on how network resources are used. Rather than
looking at resource usage from a network performance viewpoint, however, accounting
management asks about who uses the resources. Which users are consuming resources? Which
systems or applications consume the most bandwidth? Answers to these questions enable you
to bill organizations for the use of these resources. This information also helps you to plan more
accurately for anticipated growth.
The purpose of performance management is to monitor, evaluate, and report on the behavior
and effectiveness of network and system equipment, including devices, links, circuits, systems
and their components, and applications. This reporting has value for both real-time monitoring
as well as for historical reporting purposes. For example, you can use performance management
systems to poll for data from network devices, links, systems, components, or applications in
real time to alert support organizations of performance problems. In addition, you can collect
and store performance data over time to identify utilization patterns, such as the flow of hourly,
daily, weekly, and monthly data cycles. You can then use the performance data to identify
trends to support more informed capacity planning for network and system upgrades.

Performance management looks at the network as a whole, at all of the links between any two
points, to identify bottlenecks in performance and provide data to support more informed
solutions to performance problems. Performance management focuses on evaluation metrics
that indicate how network and system resources are used, how well resources are performing,
and how those utilization patterns affect the delivery of network services, both for current
analysis and future planning.
The primary focus of security management is to protect networks, systems, and data from
unauthorized access. Security management is an important consideration for both technical and
management staff because the security of a network extends beyond the network itself. The
security of a network extends to the physical environment that also controls access to networks
and data. Therefore, security management must include policies defined by both management
and technical staff to ensure secure access to networks. Security management also involves
securing access to, and securing the manipulation of, data that resides on the network, and
should include identifying procedures to follow when a security breach occurs.
Benefits of Network Management
This topic describes some of the benefits of a well-planned network management strategy.

Most users do not care how they get their data, just that they get it. Improperly managed
networks lead to downtime and loss of access to important data, making users painfully aware
of their dependence on the network. Often, every little problem is blamed on the network,
amplifying the need for network management. Employing network management allows
network administrators to be constantly aware of the status and health of the network.
Deviations from expected behavior can be detected early and corrected before impacting users.
Managing the network cannot stop all network service degradation, but it can minimize the
degradation and provide the necessary data to assist the network administrator in a quick
resolution of the problem.

A well-planned and implemented network management strategy provides you with a

consistently high level of network services, which helps increase productivity. The collected
management data can also be used to maximize the return on investment, verify third-party
service-level agreements, and quantify change and growth. The time spent in formulating a
network management strategy will lead to an overall increase in network reliability and
effectiveness, and can save the organization money.

Note Good network management and statistics can provide a safe and effective way to deploy
new applications in a busy network. Network management information should be one of the
basic types of information that you gather when you deploy new applications in the network.
Summary
This topic summarizes the key points that were discussed in this lesson.

Summary

 Network management is often defined in terms of its goals—

ensuring network usability, easing day-to-day operations,
and minimizing technology complexity.
 Network management can be broken down into five functional
areas—Fault, Configuration, Accounting, Performance,
and Security (FCAPS).
 A good network management strategy reduces network downtime
and increases user productivity.

© 2007 Cisco Systems, Inc. All rights reserved. CWLMS v3.0—1-11

 Lesson 2

Exploring the Network

Management Process

Overview
To achieve the benefits of network management, you must collect and process the status and
health information of the network. This lesson describes the process of collecting network
information, focusing on the network management standards for information, and the
communication of that information.

Although it is important, network management traffic and resource consumption is considered

overhead. You should be familiar with how network management data can be collected, and the
network management information and communication models. This lesson will help you
understand the resource ramifications of performing various network management tasks, and
how to properly interpret the collected data.

Objectives
Upon completing this lesson, you will be able to describe the process of collecting network
status and health information, focusing on network management standards for information and
the communication protocol. This ability includes being able to meet these objectives:
 Describe the process of collecting network status and health information from network
devices using an NMS
 Define SMI and the MIB hierarchy to determine the OID for proprietary and
nonproprietary MIB objects
 Describe the SNMP communication model, SNMP versions, and polling versus traps
Performing Network Management
This topic describes the benefits of network management to network users, network
administrators, and the corporation. A clear understanding of these benefits is important for a
successful implementation of a network management strategy.

To achieve the benefits of network management, you must determine how to gather and
analyze the network status and health information. You can obtain this information from many
intelligent sources within the network environment. The data sources must be capable of
providing visibility into the status and health of the network and its shared components, and
monitoring and storing the network information.

Network management should also allow for convenient and simple ways to modify devices to
change their behavior to meet stated requirements. Therefore, the purpose of a network
management system (NMS) is to automatically gather this information and present it to the
network administrator in a meaningful and useful way, to help ensure the availability,
reliability, performance, and security of the network. The NMS should also include tools to
assist in the modification of devices.
 Sources for Information
Telnet HTTP syslog TFTP SNMP SNMP-Trap
CLI 80/TCP 514/UDP 69/UDP 161/UDP 162/UDP

show Web System TFTP

Commands Server Logging Client

SNMP
Operating System Data Structures AGENT
`
MIB
09123 Objects
COUNTERs GAUGEs TABLEs TIMERs FILEs

Built-in Production Manageable Device

Intelligence Services

Ping
Cisco Discovery Protocol, Layer N Forwarding Trace Route
VTP, and Cisco IOS IPSLA

© 2007 Cisco Systems, Inc. All rights reserved. CWLMS v3.0—1-3

Every computer-based system has internal mechanisms designed to report on the status of the
system and the production services provided by the system. Many network-based devices have
built-in intelligence, such as VLAN Trunking Protocol (VTP), Cisco Discovery Protocol, and a
Cisco IOS IP service level agreement (SLA) to assist in management activities that can be
configured and reported on using the same internal mechanisms. Access to the data provided by
these internal mechanisms is essential for network management activities.

Note The mechanism implementations vary from one system to another. Factors such as device
type, device model, operating system, and the version of operating system can be used to
characterize the mechanisms.

The internal mechanisms can consist of counters, gauges, tables, timers, and files. The retrieval
and modification of the information in these mechanisms for network management purposes
can be achieved through numerous communication protocols (depending on the device type),
including the traditional command-line interface (CLI), Telnet, HTTP, syslog, and TFTP. Other
simple applications, such as ping and traceroute, can also provide network management
information. In an effort to standardize the mechanism used for device status information that is
necessary for network management tasks, the MIB information model was created. Likewise,
the Simple Network Management Protocol (SNMP) is the standard communication model for
retrieving information held by the MIB.

Note The MIB objects consist of a database of values on the device that you can monitor or
modify using a NMS.
Standards for Information—the MIB
This topic describes the standard network management information model for the MIB.

Standards for Information—the MIB

MIB:
 Set of variables defining the status of a device (e.g. temp = 85 degrees)
 Just facts—not whether it is good or bad
 Defined according to SMI rules
 Each managed object is described using a unique object ID (OID)
MIB I/MIB II:
 Standard MIB (nonproprietary)
 Objects included are considered essential for either fault or configuration management
Other standard MIBs:
 RMON, host, router, etc.
SNMP Thousands of
Proprietary vendor MIBs: AGENT manageable objects
 Extensions to standard MIBs following rules defined
in the SMI standards
Each OID is described using ASN.1

© 2007 Cisco Systems, Inc. All rights reserved. CWLMS v3.0—1-4

An MIB is used to store information that represents device elements and their status. The
structure itself is called a Structure of Management Information (SMI). The SMI is a tree
structure that allows for efficient organization and retrieval of information. The “leaves” of the
tree are the actual MIB variables that contain information about some aspect of the device.
These values typically state a fact about the device, for example, temp = 85 degrees, rather than
a health index. Once this value is retrieved, it is up to the NMS application or the network
administrator to make the determination as to the significance of this value. An object identifier
(OID) uniquely identifies each MIB variable. Each OID is described using Abstract Syntax
Notation One (ASN.1).

MIBs are highly structured depositories for information about a device. Many standard
nonproprietary MIBs exist to manage standard features. However, many more MIBs that are
proprietary exist to uniquely manage the devices of different vendors. These nonstandard
proprietary MIBs are simply extensions to MIB I/II.
 Object Identifiers
ISO (1)

SNMP
AGENT ORG (3)  Hierarchically structured
 Each object uniquely identified
DOD (6)

Internet (1)

Directory (1) Mgmt (2) Experimental (3) Private (4)

OID for system
1.3.6.1.2.1.1 mib-2 (1) Enterprise (1)

System (1) TCP (6) Proteon (1) Sun (42)

Interfaces (2) UDP (7) IBM (2) Apple (63)

Address (3) EGP (8) Cisco (9) Microsoft (311)
Translation ..
CMOT (9) HP (11)
IP (4) .
Transmission (10) Wellfleet (18) Unassigned
ICMP (5) (9118)
SNMP (11)
Internet Activities Board Administered Vendor Administered
© 2007 Cisco Systems, Inc. All rights reserved. CWLMS v3.0—1-5

Each managed object within a MIB has a unique OID, which is a number in dotted notation,
providing the code to traverse the SMI tree to reach the MIB variable. The MIB structure can
be viewed as containing two parts:
 Standard or public part (nonproprietary) implemented on all devices and administered by
the Internet Architecture Board (IAB)
 Private part (proprietary) that is used by individual vendors to manage the unique features
of their own devices

It would be convenient if a standard MIB existed for each device type, allowing for the
homogeneous management of devices of all vendors. However, each vendor implements their
MIBs differently and therefore must be managed using a different set of variables. Logically,
this makes sense, because the manufacturer of the device can best determine how to manage the
device.

The public side of the MIB (nonproprietary) contains variables that are common to all devices.
All devices should implement these variables to comply with common management needs. For
example, an OID for a variable in the System group would always begin with (1.3.6.1.2.1.1).

The private side of the MIB allows vendors to manage unique statistics that allow network
management personnel to track unique features and functions that the vendor has implemented
in their devices.
 Scalar Objects (Instance 0)
ISO (1)

Org (3)

DOD (6)

Internet (1) Scalar objects have only one

Mgmt (2) instance of a variable.
MIB-2 (1)
sysDescr (1)
System (1)
sysObjectID (2) OID for SNMP object sysContact
1.3.6.1.2.1.1.4
sysUpTime (3)

sysContact (4) Sal A. Mander

sysName (5)
OID for SNMP variable Sal A. Mander
sysLocation (6) 1.3.6.1.2.1.1.4.0

sysServices (7)

© 2007 Cisco Systems, Inc. All rights reserved. CWLMS v3.0—1-6

The OID for each MIB variable is appended with an instance identifier to differentiate it from
multiple occurrences of the same variable. This results in multiple instances of an MIB
variable. For example, there is an MIB variable called interface errors identified by a unique
OID. For each interface, there exists a separate instance of this variable. To distinguish
interface errors for each interface on a device, an instance identifier must be associated with
each interface and appended to the interface errors OID.

In some cases, such as the MIB variable system name, there exists only one instance of the
variable. These objects are known as scalar variables. To retrieve a scalar variable, the instance
identifier of 0 is appended to the end of the OID of the scalar variable.
 Multiple Instances ISO (1)

Org (3)
Vector objects have appended instance
DOD (6)
suffixes >0 to identify the row in two
dimensional tabular data structures. Internet (1)

OID for variable: Instance 2 of ifDescr Mgmt (2)

Mib-2 (1)
1.3.6.1.2.1.2.2.1.3.2
Interfaces (2) System (1)
Ifnumber (1)

ifTable (2)

ifEntry (1)
Conceptualized Table

ifIndex (1) ifDescr (3) ifType (4) ifMtu (5) ... ifSpecific (22)

row 1
2 value

3
column
© 2007 Cisco Systems, Inc. All rights reserved. CWLMS v3.0—1-7

If each object is to be uniquely identified, MIB variables that can have more than one value,
such as multiple interfaces, present an interesting problem. The solution is to append an
instance identifier to the OID; the OID string alone identifies the object, whereas the OID string
with an appended instance identifies the value for the instance of the object.

Device objects that have multiple instances in which multiple MIB variables are defined are
represented using a table, in which the column is the MIB variable, and the row is the instance
of the device object.

In the figure, the NMS wants to retrieve the interface description for interface 2 (the instance
number of an interface may not always be corresponding). When traversing the MIB tree using
the OID, the number branch or object before the interface description leaf points to a table. The
next number in the OID indicates the column of the table, which corresponds to the interface
description MIB variable. The final number of the OID is the instance of the variable, and is
used to access the row of the table. The result is the interface description for interface 2. The
same OID with a different instance would result in the interface description for a different
interface.

Most management software applications append the appropriate instance identifier to an OID.
 Cisco MIB
Iso (1)
Org (3)
DOD (6)
Internet (1)
Private (4)
Enterprise (1)

Cisco (9) CiscoProducts (1)

OLD-CISCO-SYS-MIB

Local (2) lsystem(1) avgBusy1(57)

Temporary (3)
linterfaces(2)
CiscoMgmt(9) locIfInBitsSec(6)
.. locIfOutBitsSec(8)
.
CiscoPolicyAuto(18)
OLD-CISCO-INTERFACES-MIB
CISCO-SMIv1-MIB

All Cisco MIBs can be downloaded from Cisco.com.

© 2007 Cisco Systems, Inc. All rights reserved. CWLMS v3.0—1-8

The figure presents a partial look at the structure of the MIB that is administered by Cisco.
There are many objects administered by Cisco, which are declared in more than 150 different
MIB definitions.

In the past, all of the objects under the Cisco MIB branch were documented in one large
document, updated with each new release of Cisco IOS Software. Therefore, there was a 9.0
Cisco MIB, a 10.0 Cisco MIB, and so on. The product line at that time consisted exclusively of
routers.

As Cisco IOS Software matured and the product line grew, this massive MIB model became
unscalable. Within one revision level of Cisco IOS Software, there were different versions,
such as the IP-only image and the IBM feature set version. The product line also began to
include other devices such as LAN switches running completely different software.

Starting with Cisco IOS Release 10.2, the Cisco MIB was broken into individual component
MIB documents, each focusing on a specific feature, technology, or device type. This structure
allows quicker implementation of new features and allows you to compile only the parts you
need into your NMS.

Brief descriptions of the main subordinate branches under Cisco (9) are listed as follows:
 CiscoProducts (1): The root of the Cisco product sysObjectID values that are declared in
CISCO-PRODUCTS-MIB.
 Local (2): The subtree beneath which releases prior to Cisco IOS Release 10.2 MIBs were
built.
 Temporary (3): The Cisco IOS Release 10.2 experiments were placed here.
 pakmon (4): Reserved for pakmon.
 Workgroup (5): Reserved for use by the Workgroup Business Unit.
 OtherEnterprises (6): The location that MIBs from other companies are rerooted to in
order to maintain a controlled version.
 CiscoAgentCapability (7): The root for the assigned AGENT-CAPABILITIES value.
 CiscoConfig (8): The main subtree for configuration MIBs.
 CiscoMgmt (9): The main subtree for new MIB development.
 CiscoExperiment (10): This branch provides a root OID from which experimental MIBs
may be temporarily based. MIBs are typically based here if they fall into one of two
categories: Internet Engineering Task Force (IETF) work-in-process and Cisco work-in-
process. IETF works-in-process are MIBs that have not been assigned a permanent OID by
the Internet Assigned Numbers Authority (IANA). Cisco works-in-process are MIBs that
have not been assigned a permanent object identifier by the Cisco assigned number
authority, typically because the MIB is not ready for deployment. Support for MIBs in the
CiscoExperiment subtree are deleted when a permanent OID assignment is made.
 CiscoAdmin (11): Reserved for OIDs not associated with MIB objects.
 CiscoModules (12): The root for the MODULE-IDENTITY objects.
 Lightstream (13): Reserved for use by LightStream.
 Ciscoworks (14): The root for MIBs applicable to the CiscoWorks family of network
management products.
 Newport (15): Reserved for Newport Systems Solutions, now part of the Access Business
Unit.
 CiscoPartnerProducts (16): This is the root OID from which partner sysObjectID values
may be assigned. Partner sysObjectID values are composed of the CiscoPartnerProducts
prefix, followed by a single identifier that is unique for each partner, followed by the value
of sysObjectID of the Cisco product from which the partner product is derived. Note that
the chassisPartner MIB object defines the value of the identifier assigned to each partner.
 CiscoPolicy (17): The root of the policy management subtree.
 CiscoPolicyAuto (18): This branch is a subtree for OIDs that are automatically assigned
for use in policy management.

Note The current URL to download Cisco MIBs is

www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml, or search cisco.com for
―software center download mibs‖.
 Basic MIB Variable Types
 String
– A text string that provides information.
What is this device? sysDescr Cisco Systems WS-C55005

 Gauge
– A value that can go up or down. (for example, speedometer)
– A gauge variable is not time-dependent.
What is the temperature of the device? Temperature 88

 Counter
– A value that is always incrementing. (for example, odometer)
– It requires two reads to associate it with time.

What is the collision rate? t=0 ethCollisions 3567433

t=60s ethCollisions 3567451

3567451 – 3567433 = 18/min

© 2007 Cisco Systems, Inc. All rights reserved. CWLMS v3.0—1-9

The values returned by the MIB variables are used to make determinations about the health of a
system. It is important to understand the different types of MIB variables to properly interpret
the value returned. The following describes three basic types of MIB variables:
 String: The value returned is simply a text string describing some aspect of the device.
 Gauge: One way to describe a gauge would be an absolute value. The value returned by a
gauge represents the condition at the time the value was polled. The value can go up or
down. An analogy would be the speedometer in a car. At any time, the speedometer
indicates how fast the car is going at that moment.
 Counter: A counter can be described as a delta value. Counters simply increment every
time the corresponding event takes place, such as Ethernet collisions. An analogy would be
the odometer in a car; the odometer indicates how many total miles the car has traveled
since the car was built. To properly analyze a counter variable, two readings must be taken
to associate the variable with respect to time, or other measuring metric. You should not be
alarmed when the Ethernet collisions MIB variable returns a large value, because there is
no association with how long the counter has been counting. You should reread the variable
some time later, and the two values should be compared, resulting in a delta value. The
result is the number of collisions that occurred during the polling period, which is the time
between each reading of the MIB variable.
Standards for Communication—SNMP
This topic describes the standard network management communication model, SNMP, used to
retrieve information from the MIBs.

The SNMP protocol defines the rules that govern communication between the manager and the
management agents in network elements. As its name suggests, SNMP is a simple protocol
that, in its original version, SNMPv1, had five protocol message types that defined how
information was exchanged between manager and agents. The original five message types are
as follows:
 get-request: The SNMP manager generates get-request messages when it requests the
value of an MIB variable.
 get-next-request: These messages are very similar to get-request messages except that a
get-next-request message obtains the value for the next instance of an MIB variable or the
MIB variable next in line to the OID specified in the previous request.
 set-request: The set-request message is used by the SNMP manager to initialize or reset
the value of an MIB variable.
 get-response: The get-response message is generated by an agent on receipt of a get-
request, a get-next-request, or set-request message sent by an SNMP manager.
 Trap: The Trap message is an unsolicited message sent by an agent. Traps occur when an
agent observes an occurrence of a preset parameter in the agent.

SNMP managers and agents generate SNMP messages and encapsulate them in User Datagram
Protocol (UDP) for transmission over IP. All SNMP managers use UDP port 161 for receiving
SNMP messages except for traps. SNMP managers listen for traps on port 162. Each SNMP
message, except the trap message, contains a plaintext string, known as the community string,
used to restrict access to managed devices.
 SNMP Get Request and Response

OID
1.3.6.1.2.1.1.1 Instance

get-request(

Read = public read/write = private

sysDescr.0)
Read Comm
SNMP Manager
unity(public) Verify access
permission and retrieve

SNMP Agent
MIB value using OID to
traverse the MIB tree.
onse
get-resp
IOS)
cr. 0=Cisco
(sysDes
MIB value

© 2007 Cisco Systems, Inc. All rights reserved. CWLMS v3.0—1-11

In the figure, the NMS has requested the system description of a device on the network. The
NMS, which also understands the MIB structure, creates an SNMP get-request message
containing the OID for the system description MIB object (1.3.6.1.2.1.1.1.0), and the read
community string for access to the MIB on the device (public in the example). The SNMP
agent on the device receives the request and checks for proper read access by comparing its
SNMP read community string with the string sent by the NMS. If the community strings are the
same, the request is authorized and the SNMP agent uses the OID in the get-request message to
traverse the MIB tree to retrieve the requested MIB object. The SNMP agent places the result
of the request into a get-response message and sends it back to the NMS for viewing.
 Evolution of SNMP
 SNMPv1
– Defined in 1988 to address management needs of the
evolving Internet
 SNMPv2c
– Released in 1993 and revised in 1995
– Added new message type, the get-bulk request, for a more efficient
retrieval of multiple rows of a table
– Has 64-bit counters
– Still lacks strong security
 SNMPv3
– Issued in 1998
– Contains security enhancement
– Provides remote administration capabilities
– Is an architectural framework

© 2007 Cisco Systems, Inc. All rights reserved. CWLMS v3.0—1-12

There are three versions of SNMP available today:

 SNMPv1: SNMPv1 was defined in 1988 to address the management needs of the evolving
Internet and quickly became a standard in 1990.
 SNMPv2c: SNMPv2c was released in 1993 and revised in 1995 to address observed
limitations in SNMPv1. The most noticeable enhancements were the introduction of the
get-bulk-request message type and the addition of 64-bit counters. Retrieving information
with get and get-next-request messages was an inefficient method of collecting information
from device tabular data structures. Only one variable at a time can be solicited with
SNMPv1. The get-bulk-request of SNMPv2c addresses this weakness by receiving a “bulk”
of information using a single request. Also, the 64-bit counters address the issue of the 32-
bit counters rolling over too quickly, especially with high-speed links such as Gigabit
Ethernet. However, SNMPv2c still lacks strong security, which was one of the original
goals.
 SNMPv3: SNMPv3 was issued in 1998 and offered many new enhancements over
SNMPv1 and SNMPv2c. SNMPv3 provides strong security, remote administration
capabilities, and an architectural framework. Perhaps the most important enhancement is
that SNMPv3 defines a method for providing SNMP message-level security. SNMPv3
provides a user-based security model, much like the client-server security that is prevalent
today to protect users against four types of threats: the modification of information, a user
masquerading as a valid user, the modification of an SNMP message stream, or disclosure.
SNMPv3 provides authorization and access to an MIB subtree on a per-user basis.
 CiscoWorks LMS SNMP Support

 SNMPv1 and SNMPv2c

– Community strings are sent in plaintext.
– It is recommended that you use ACLs to filter SNMP requests
to a device.
 SNMPv3 authNoPriv
– Provides authentication based on the
HMAC-MD5 or HMAC-SHA algorithms.
– Does not encrypt the packets.

© 2007 Cisco Systems, Inc. All rights reserved. CWLMS v3.0—1-13

CiscoWorks LAN Management Solution (LMS) currently supports the following SNMP
options:
 SNMPv1 and SNMPv2c: SNMPv1 and SNMPv2c use a community string as a form of
security. Because the community string is sent in plaintext, it is recommended that you use
an access control list (ACL) on Cisco IOS devices and an IP permit statement on Cisco
Catalyst operating system devices to restrict SNMP requests.
 SNMPv3 authNoPriv: SNMPv3 provides packet-level security, integrity protection, and
replay protection, but does not encrypt the packets.

The table lists all of the security models and levels defined in SNMP:

SNMP Security Models and Levels

Model Level Authentication Encryption What Happens

v1 noAuthNoPriv Community string No SNMPv1 uses a community string match

for authentication.
v2c noAuthNoPriv Community string No SNMPv2c uses a community string match
for authentication.
v3 noAuthNoPriv Username No SNMPv3 noAuthNoPriv uses a username
match for authentication.
v3 authNoPriv Message Digest 5 No SNMPv3 authNoPriv provides
(MD5) or Secure authentication based on the Hashed
Hash Algorithm Message Authentication Code (HMAC)-
(SHA) MD5 or HMAC-SHA algorithms.
Model Level Authentication Encryption What Happens

v3 authPriv HMAC-MD5 or Data SNMPv3 authPriv provides authentication

HMAC-SHA Encryption based on the HMAC-MD5 or HMAC-SHA
Standard algorithms. Provides DES 56-bit
(DES) encryption in addition to authentication
based on the Cipher Block Chaining
(CBC) DES (DES-56) standard.
 Polling vs. Traps
Disk

NMS Server
WAN Disk
Farm
(equals $$) Disk

Rule: If disk utilization is greater than If disks reach 100%, then massive
98%, perform maintenance. failures occur (equals lost revenue).

Polling WAN Value Problem

Action
Rate Utilization Retrieved Avoidance
t=0 97% None
15min Low Not good
t=15 Dead Update resume

t=0 97% None

15min High Good
t=15 99% Perform
maintenance
When disk
utilization = 98%,
Exact
trap Nil N/A send trap and
perform moment
maintenance
© 2007 Cisco Systems, Inc. All rights reserved. CWLMS v3.0—1-14

As beneficial as network management can be, the process of collecting the information is still
categorized as overhead. You should use care when configuring management tools in order to
limit the amount of traffic generated by management tasks, but not at the expense of the
granularity needed to properly manage the network.

Example
The figure shows the trade-off between setting polling intervals and using traps. In this
scenario, the company has many mission-critical resources overseas that can cause a major
system meltdown if a disk becomes full. The company wants to monitor the disk utilization
using SNMP. They automate the polling of disk utilization and create a script to check disk
utilization. If the utilization reaches 98%, the script performs maintenance procedures on the
disks to avoid a system meltdown. The trick is to set the polling period frequently enough to
recognize and correct the condition early enough, but not so frequently that the polling
overloads the high-cost WAN link.

The engineer first sets the polling period to every 15 minutes. At this rate, the WAN is not
burdened by the management traffic. However, the polling period is great enough that by the
time the next poll occurs, the system may have already crashed. Next, they try 15 seconds. At
this rate, the next polling period is soon enough to catch the condition close to its actual
occurrence. However, polling all of the resources at this rate causes a substantial hit to the
WAN utilization. Obviously, the setting of the polling interval can be challenging.

Compare this scenario to using SNMP traps. Employees modify the BIOS on all of the
resources to check the disk utilization after each disk write operation. If the 98% threshold is
breached, a trap message is sent to the NMS, which in turn runs the script to perform the
necessary maintenance. Now the condition is discovered at the exact moment it occurs and
WAN bandwidth for polling is almost zero. The overhead is now the burden of the resource;
again, a trade-off.
Summary
This topic summarizes the key points that were discussed in this lesson.

Summary

 To reach the goals of network management, you must collect

information about the status and health of the network and
network devices.
 MIBs allow for a standardized way to define and store the data.
 SNMP provides a standardized way to retrieve data stored
in MIBs.

© 2007 Cisco Systems, Inc. All rights reserved. CWLMS v3.0—1-15

 Lesson 3

Examining the CiscoWorks

LMS Applications

Overview
This lesson describes the features and benefits of the applications in CiscoWorks LAN
Management Solution (LMS) software, and the client/server architecture used in these
applications. Understanding the functions of each CiscoWorks application enables you to
choose which tools to use to solve a particular problem.

Objectives
Upon completing this lesson, you will be able to describe an overview and the features of the
CiscoWorks applications in the CiscoWorks LMS bundle. This ability includes being able to
meet these objectives:
 Explain how CiscoWorks is a bundle of network management applications and describe the
client/server architecture
 Describe each of the applications that are included in the CiscoWorks LMS bundle
What Is CiscoWorks?
This topic describes the CiscoWorks LMS bundle and its functional architecture for managing
network devices.

What Is CiscoWorks?
Centralized system
for sharing network
device information.

Portal provides
launch points
for applications.

Tools provide innovative ways to

manage network devices.
© 2007 Cisco Systems, Inc. All rights reserved. CWLMS v3.0—1-2

The CiscoWorks LMS bundle contains some of the most common applications used to manage
Cisco network devices. Using these applications, network managers can provide
comprehensive configuration, fault, and performance management for Cisco-based networks.

The CiscoWorks LMS Portal provides launch points for applications and the major functions
installed on the local or remote CiscoWorks servers. These tools provide innovative ways to
centrally manage critical network characteristics such as availability, responsiveness, resilience,
and security in a consistent way.

CiscoWorks LMS has a centralized system for sharing device information across all
applications, improving manageability and allowing the management system to more
dynamically adjust to changes. CiscoWorks LMS also offers a new lightweight desktop
interface that facilitates rapid navigation between tools and that can be modified to individual
workflow needs. CiscoWorks LMS optionally uses security information maintained in Cisco
Secure Access Control Server (ACS) to simplify the management of user privileges. Cisco
Secure ACS integration provides flexibility in defining user roles, and supports secured user
views of specific devices or groups of devices by geographic or logical network segments.
 CiscoWorks Functional Architecture
AAA Server
(Access Control Server)

Cisco.com
User Authentication and RADIUS
Authorization TACACS+

CiscoWorks CiscoWorks
Client Servers
(Web Browser)
MIBs
HTTP SNMP, Telnet, SSH,
HTTPS TFTP, RCP, SCP,
and HTTPS

Multi-Server Trust Network Devices

Changes/ (SNMP Agents)
Updates

The CiscoWorks Functional Architecture provides:

 A client/server/agent architecture
 Central storage of information
 Access to information using a web browser
 Automatic collection of updates and changes
© 2007 Cisco Systems, Inc. All rights reserved. CWLMS v3.0—1-3

The CiscoWorks architecture is based on clients, servers, and agents. Information about the
Cisco device configurations, faults, and performance is stored in the MIBs of the devices. The
server uses Simple Network Management Protocol (SNMP), Telnet, Remote Copy Protocol
(RCP), or TFTP to retrieve information from managed devices or agents located in the network.
Because protecting company information and network access is a top priority, you can secure
the access between the CiscoWorks server and remote devices by using Secure Shell (SSH),
Secure Copy Protocol (SCP), HTTPS, and SNMP v3. The information is gathered from the
network on a scheduled or manual basis, or when a change in the network is detected, and is
stored in a central database located on the CiscoWorks server.

Clients access network information in the CiscoWorks database by using a supported web
browser to access the CiscoWorks server. Secure Sockets Layer (SSL) is used to secure user
authentication when the CiscoWorks server is accessed. By default, authentication and
authorization of users is handled locally on the CiscoWorks server. Authentication can also be
handled remotely by one of several methods, including TACACS+ and RADIUS. For a more
custom control of authentication and authorization on a per-device basis, you can integrate
CiscoWorks with an ACS, on which you can create user defined roles.

Communication between multiple CiscoWorks servers is enabled by a trust model addressed by

certificates and shared secrets. This trust model allows you to install applications within the
CiscoWorks LMS bundle on separate servers and still share information collected from the
network.

In addition, CiscoWorks is tightly integrated with Cisco.com. By using the extensive

knowledge base in Cisco, you can easily locate CiscoWorks product information, software
images, software updates, and more.
CiscoWorks LMS Applications
This topic describes the individual applications in the CiscoWorks LMS bundle.

CiscoWorks LMS Applications

CiscoWorks Portal
CiscoWorks Assistant

Performance
Internetwork

CiscoView
Essentials
Resource
Manager

Manager

Manager
Campus

Monitor

Device

Device
Center
Common Services Fault

© 2007 Cisco Systems, Inc. All rights reserved. CWLMS v3.0—1-4

CiscoWorks LMS provides the integrated management tools needed to simplify the
configuration, administration, monitoring, and troubleshooting of Cisco networks.

CiscoWorks LMS includes the following applications:

 CiscoWorks Common Services
 CiscoWorks Portal
 CiscoWorks Assistant
 CiscoWorks Campus Manager
 CiscoWorks Resource Manager Essentials (RME)
 CiscoWorks Internet Performance Monitor (IPM)
 CiscoWorks Device Fault Manager (DFM)
 CiscoView
 CiscoWorks Device Center

CiscoWorks Common Services provides a set of shared application services that all of the
CiscoWorks LMS applications use. CiscoWorks Common Services Release 3.1 includes
CiscoView, Integration Utility, CiscoWorks Portal, and CiscoWorks Assistant. Except for
CiscoView, these applications are used for managing the CiscoWorks server. The rest of the
CiscoWorks applications focus on the functional areas of the ISO Fault, Configuration,
Accounting, Performance, and Security (FCAPS) model.
 CiscoWorks Common Services
Network Devices

Common set of management

services shared by the
CiscoWorks applications

(CiscoWorks Common Services) DCR

Applications
Runtime Web page, process management,
Services user security, and the help engine
Database engine and utilities,
System event distribution services,
Services and job management

Web Browser
User Interface

© 2007 Cisco Systems, Inc. All rights reserved. CWLMS v3.0—1-5

CiscoWorks Common Services represents a common set of management services that the
CiscoWorks applications share. CiscoWorks Common Services provides a model for device
credentials, data storage, login, user role definitions, access privileges, security protocols, and
navigation. CiscoWorks Common Services enables you to manage user roles and privileges,
which allow you to control access to applications and specific features within the applications.
User roles and privileges are controlled by built-in authentication and authorization services, or
through an external ACS.

CiscoWorks Common Services creates a standard user experience for all management
functions. It also provides a common framework for all basic system-level operations such as
installation, data management including backup-restore and import-export, event and message
handling, and job and process management.

The CiscoWorks Common Services server consists of the following services:

 Runtime services: The web page, process management, security, and the help engine,
which is enabled at installation
 System services: The database engine and utilities, as well as event distribution services
and job management

Note CiscoWorks Common Services and CiscoWorks applications use popup dialog boxes for
many features. If you have a popup blocker enabled in your browser, none of these popups
will appear. Therefore, if a popup blocker is installed, you must disable it.
CiscoWorks LMS Portal is the first page that appears when you launch the CiscoWorks LMS
application. It serves as a top-level navigation interface and launch point for the frequently used
functions in the application. You can view important statistics and details on the CiscoWorks
LMS applications installed on your CiscoWorks server in a single page instead of navigating
through several pages.

Portlets are the basic units in the CiscoWorks LMS Portal, and are organized into views that are
displayed as tabs across the top of the portal. You can add, delete, or customize portlets and
views in your private portal. The public portal is shared by all users and can only be modified
by an administrator.

The primary benefits of the CiscoWorks LMS Portal are as follows:

 Customization: You can personalize the CiscoWorks LMS portal using the drag and drop,
add, edit, and remove features.
 Information available in a single click: The CiscoWorks LMS Portal provides easy and
quick access to the most vital, often-viewed information for applications in the CiscoWorks
LMS suite.
 Multiserver support: The CiscoWorks LMS Portal lists all of the portlets based on the
applications installed on remote servers.
 Lightweight GUI: The CiscoWorks LMS Portal eliminates the need to install plug-ins to
launch an application.
CiscoWorks Assistant, included in the CiscoWorks LMS solution, is a web-based tool that
provides workflows to help you overcome network management and software deployment
challenges. CiscoWorks Assistant is installed with CiscoWorks Common Services.

CiscoWorks Assistant workflows contain functionalities that are available across CiscoWorks
LMS applications. These functionalities are grouped logically to set up and configure the
CiscoWorks LMS server and to troubleshoot your end hosts, IP phones, and network devices.

Using CiscoWorks Assistant, you can easily deploy multiple CiscoWorks LMS servers and
maintain device credentials.

CiscoWorks Assistant supports the following deployment and troubleshooting workflows:

 Server Setup: You can deploy a single CiscoWorks LMS server or multiple CiscoWorks
LMS servers in your network. You can add devices to the Device and Credential
Repository (DCR) and import these devices across CiscoWorks LMS applications. You can
also change the CiscoWorks user authentication and authorization.
 End Host/IP Phone Down: This workflow allows you to locate and track the end hosts
and IP phones in your network, thus providing you with the information required to
troubleshoot and analyze connectivity issues.
 Device Troubleshooting: This workflow helps you identify the root cause for device
unreachabililty problems.
 CiscoWorks LMS Setup Center

Shortcuts to:
 System settings
 Security settings
 Data collection
settings
 Data collection
schedule
 Data purge settings

Shortcuts to system-wide
setup configuration tasks
and the CiscoWorks
Assistant Server setup
© 2007 Cisco Systems, Inc. All rights reserved. CWLMS v3.0—1-8

CiscoWorks LMS Setup Center is a centralized area that displays the CiscoWorks system
configurations. It allows you to configure the server settings immediately after installing the
CiscoWorks LMS software. It also has a shortcut to the CiscoWorks Assistant Server Setup.

One of the most common observations from new CiscoWorks users is that it is difficult to
remember which application menu to navigate when changing a system setting. CiscoWorks
LMS Setup Center was designed to provide shortcuts to those options that can be difficult to
find. The Edit icon displayed for each setting takes you to the respective application page to
configure the settings.

The configurations in CiscoWorks LMS Setup Center are grouped into the following
categories:
 System settings: The configurations that the system needs to function
 Security settings: The security-related settings for the product
 Data collection settings: The settings necessary for collecting data from the devices
 Data collection schedule: The schedule settings for collecting the data from the server
 Data purge schedule: The configurations that are necessary for the device to purge data

The settings specific to all applications, including CiscoWorks Common Services, CiscoWorks
RME, CiscoWorks Campus Manager, and Device Fault Manager, are grouped within these five
categories, and enables you to configure them in a common space. If an application is not
installed, the corresponding entries are not available.
 CiscoWorks Campus Manager

Visualization
(Topology Services)

Configuration
 View physical and logical
connectivity of network.
 Configure and view VLANs, Reports
VTP, and ATM domains.
 Report on devices, best
practices, and discrepancies.
 Locate the connectivity User Tracking
of hosts, end users,
and IP phones.
 Obtain a map or table trace of
the Layer 2 and Layer 3 Diagnostics
communication between two (Path Analysis)
devices.
Configuration Management, Fault Management
© 2007 Cisco Systems, Inc. All rights reserved. CWLMS v3.0—1-9

CiscoWorks Campus Manager focuses primarily on configuration management, both physical

and logical connectivity, of devices and end stations. It consists of the following separate tools
that can be used to manage and monitor Layer 2 and Layer 3 Cisco devices on the network:
 Visualization: With Topology Services, you no longer have to trace cables through a
wiring closet to determine which devices are connected to which ports. The Topology
Services tool auto-discovers Cisco routers and switches on the network and displays the
network layout in browser-accessible topology maps allowing you to view and monitor the
physical and logical services in your network.
 Configuration: CiscoWorks Campus Manager provides configuration menu workflows
that allow you to create and modify VLANs, assign VLANs to ports, display VLAN ports,
configure trunk ports, disallow VLANs on trunks, manage PVLANs, and configure
promiscuous ports.
 Reports: The CiscoWorks Campus Manager Reports menu allows you to view device
attributes, port attributes, and VLANs associated with selected devices. In addition, you can
run discrepancy reports discovered during data collection and display best practices
deviations found in the network.
 User Tracking: The User Tracking tool greatly simplifies the task of tracking user and
end-station connections to the network. User tracking automatically identifies all end
stations connected to Cisco switches that have been discovered on the network, including
printers, IP phones, servers, and PCs. User Tracking also collects detailed information
about each end station, including MAC address, IP address, Domain Name System (DNS)
host name, port assignment, and VLAN memberships.
 Diagnostics: Path Analysis is a diagnostic tool for troubleshooting connectivity-related
problems between end stations and Layer 2 and Layer 3 devices. The user can trace the
Layer 2 and Layer 3 path between any two endpoints, or between the endpoints of an IP
phone call, on the discovered network. This trace makes it easier to find the problem when
connectivity is lost.
CiscoWorks RME primarily focuses on the configuration management aspect of network
management. It includes many automated features that simplify configuration management
tasks, such as performing software upgrades or changing configuration files on multiple
devices. CiscoWorks RME also includes fault management features through the filtering of
syslog messages. CiscoWorks RME consists of these major functions, as well as some
additional features that you can use to manage Cisco devices:
 Inventory Management: All CiscoWorks RME functions are based upon devices from the
DCR. The Inventory Management function collects and stores detailed information on
every device managed by the CiscoWorks RME server. Inventory Management displays
this information through an extensive set of custom and standard inventory reports. In
conjunction with Change Audit Services, Inventory Management automatically tracks any
changes to device components.
 Configuration Management: The Configuration Management function stores the current
and previous versions of the configuration files for all of the supported Cisco devices
managed in the CiscoWorks RME inventory. The number of previous versions stored is a
user-configurable number. It automatically tracks changes to configuration files and
updates the archive if a change is made. Two additional functions, NetConfig and Config
Editor, are available to edit configuration files. The NetConfig application allows you to
save sets of commands and execute those commands on multiple devices at the same time.
Config Editor allows you to edit and download individual configuration files to devices
through a GUI instead of the command-line interface.
 Software Management: The Software Management function is used to store the most
current copies of software images running on all of the supported Cisco devices in the
network, as well as any additional software images that a network manager wishes to
maintain. You can use Software Management to reliably upgrade images on one or more
devices at the same time. If any errors occur during an upgrade, CiscoWorks RME allows
the user to roll back to the previous version. Optionally, for added security and change
 management control, software images are not downloaded unless approved by specifically
assigned users.
 Syslog Analysis: The Syslog Analysis function stores syslog messages from any device
configured to forward syslog messages to the CiscoWorks RME server. You can customize
it to filter out certain messages, or to automatically execute a series of commands if a
specific message is detected. For example, you can send an e-mail to the network
administrator if a critical-level error occurs on an important network device. Syslog reports
allow you to quickly view and sort messages by severity level, alarm type, device, or date.
In addition, a report of any messages logged in the past 24 hours is available, to see if any
serious errors occurred overnight.
 Change Audit Services: The Change Audit Services function allows you to trace changes
made to various functions within the network. Change Audit Services stores detailed
information about changes that are made to the inventory, software images, and
configuration files. This information allows the user to track changes in case there are
problems. You can track changes by what change was made, how the change was made,
when the change was made, and who made the change. You can also sort and view change
records by type, user, date, or method of change, such as Telnet, CiscoWorks RME
function, and other methods.
 Audit Trail: Audit Trail is similar to Change Audit. Instead of logging changes to devices,
Audit Trail tracks and reports administrative changes made to the CiscoWorks RME
settings.
 CiscoWorks Internet Performance
Monitor
 Use synthetic tests to measure
protocol response times and
monitor device availability.
– ICMP echo test
– TCP connect test
– DNS resolution test
– DHCP test
– HTTP response test
– Voice, video jitter test
– And more
 Isolate delays by viewing latency
hop-by-hop.
 Identify performance trends using
historical data.

Performance Management
© 2007 Cisco Systems, Inc. All rights reserved. CWLMS v3.0—1-11

The constant growth of networks today creates challenges for the network administrator in
maintaining the performance and availability of the network. Users often report that they have
network performance and availability issues, such as the network being slow or down. Network
administrators need an effective way to discover network problems, usually by collecting data,
before the problems affect end users.

CiscoWorks IPM provides the network administrator with the ability to measure network
response time, determine availability, and analyze response time patterns end-to-end as well as
hop-by-hop (router-to-router). CiscoWorks IPM also warns the network administrator of long
delays by using SNMP traps and events that allow the network administrator to proactively
solve potential performance issues before they affect the end user. To measure response time
information more precisely, CiscoWorks IPM measures the performance of business
application traffic directly. Using only ping to measure response time may not be enough.
Measuring the delay of voice data and other upper layer protocols, such as TCP, User Datagram
Protocol (UDP), DNS, and DHCP, can provide important information for optimizing the
network.
 CiscoWorks Device Fault Manager
 Proactively monitor
Cisco devices for faults:
– Environmental
(temperature,
voltage, power
supply)
– Connectivity Alerts and Activities
– Processor, memory
utilization, etc.
– Interface utilization,
errors, down
 Generate notifications
for alerts and events.
 Search 31 days of fault
history.
Fault History

Fault Management
© 2007 Cisco Systems, Inc. All rights reserved. CWLMS v3.0—1-12

Fault management of the network is vital to the success of a company. Traditionally, fault
managers simply determined whether a device was up or down. With the complexity of
network infrastructure equipment today, a device can be “up” but performing poorly, resulting
in network performance degradation. Most fault managers allow you to selectively poll specific
MIB variables to determine the overall health of a device. However, this selective polling
requires a great deal of knowledge to determine what constitutes a healthy device, and which
MIB variables to poll to determine its health.

CiscoWorks DFM directly addresses these issues, listening to SNMP traps, and contains the
intelligence to poll for predefined MIB variables for most Cisco devices. CiscoWorks DFM
then correlates multiple events together and displays them as alerts to determine the health of a
device without user intervention. You can configure notifications to proactively advise you
when a problem exists in the network, and you can search the fault history by alerts or events
that are stored for 31 days.
 CiscoView

 Graphically monitors
and configures a Cisco
network device.
 Configure and monitor
mini-RMON on
Ethernet ports. Mini-RMON
Manager
Chassis View

Configuration Management, Performance Management, Fault Management

© 2007 Cisco Systems, Inc. All rights reserved. CWLMS v3.0—1-13

CiscoView Chassis View is an easy-to-use, graphical application that allows the user to
configure and monitor a Cisco device. CiscoView Chassis View aides network managers by
displaying a physical view of a Cisco device and color-coding device ports for at-a-glance port
status, allowing you to quickly grasp essential information. The CiscoView Chassis View
features provide dynamic status, device monitoring, and comprehensive configuration
information for Cisco internetworking products such as routers, switches, and access products.
Being web-based, CiscoView Chassis View allows access from any client that has a standard
browser, network access, and minimum hardware requirements.

CiscoView Mini-RMON Manager provides web-enabled, real-time, Remote Monitoring

(RMON) information to users to facilitate troubleshooting and improve network availability.
Used in conjunction with certain Cisco devices, CiscoView Mini-RMON Manager provides
visibility into network issues or problems before they become critical.

Note CiscoView is installed when CiscoWorks Common Services is installed.

 CiscoWorks Device Center

Launch tools, reports, and

management tasks on a
network device.
 Tools used to
debug device-
related problems
 Reports that can
be launched for the
selected device
 Management
tasks that can be
performed on the
selected device

Configuration Management, Performance Management, Fault Management

© 2007 Cisco Systems, Inc. All rights reserved. CWLMS v3.0—1-14

Navigating the CiscoWorks menus to find the correct application can be challenging. The
network administrator may not use the correct application in troubleshooting a problem because
they do not navigate to the correct menu location. When a specific device is experiencing
unusual behavior, it is easier to start from that device to see what tools are available.

CiscoWorks Device Center provides a device-centric view for CiscoWorks applications from a
single location. It displays a summary, available reports, various tools, and tasks that you can
perform on the selected device. CiscoWorks Device Center is a very useful tool in
troubleshooting devices in the network.

You can perform device-centric activities, such as changing device attributes, updating
inventory, Telnet, and more, depending on the applications that are installed on the local
CiscoWorks Common Services server. You can launch other CiscoWorks LMS tools, reports,
and management tasks from CiscoWorks Device Center, but only from applications that reside
on the local server.

Note You cannot launch tools, reports, or perform management tasks that pertain to applications
installed on a remote server.
Summary
This topic summarizes the key points that were discussed in this lesson.

Summary

 CiscoWorks LMS is a bundle of applications that can securely and

efficiently manage network devices from a centralized location by
using a web-based client/server architecture. Routine tasks can
be automated to make the network administrator more effective.
 The CiscoWorks applications in the CiscoWorks LMS bundle are
CiscoWorks Common Services, CiscoWorks LMS Portal,
CiscoWorks Assistant, CiscoWorks LMS Setup Center,
CiscoWorks Campus Manager, CiscoWorks RME, CiscoWorks
IPM, CiscoWorks Device Fault Manager, CiscoView, and
CiscoWorks Device Center.

© 2007 Cisco Systems, Inc. All rights reserved. CWLMS v3.0—1-15

Module Summary
This topic summarizes the key points that were discussed in this module.

Module Summary

 The ultimate goal for network management is to make a network as

transparent as possible. This becomes more difficult with increased
network use and complexity. ISO defines network management using the
FCAPS model. A good network management strategy will reduce
network downtime.
 Collecting information about the status and health of the network is
accomplished by standardizing the way to store data (MIBs) and the
method used to retrieve data (SNMP).
 CiscoWorks LMS is a bundle of applications that assist in managing
network devices from a centralized location, automating many routine
tasks. The CiscoWorks applications in the LMS bundle are CiscoWorks
Common Services, CiscoWorks LMS Portal, CiscoWorks Assistant, LMS
Setup Center, Campus Manager, CiscoWorks RME, IPM, DFM,
CiscoView, and CiscoWorks Device Center.

© 2007 Cisco Systems, Inc. All rights reserved. CWLMS v3.0—1-1

When you successfully perform your role as a network administrator, nobody really knows who
you are and how well you do your job. The typical user of a network does not care how the
network works, as long as they can do their job. It is when the network goes down that the user
gets to know you. The goal to make the network as transparent as possible becomes more
difficult with increased use and complexity. Sometimes you are expected to do more with fewer
resources at your disposal.

Network management tools are designed to automate routine tasks and remotely manage a
network. In order to accomplish these tasks, a standard for the way data is stored and retrieved
was developed. With network management software, a user can easily obtain data stored in the
MIB on a device via Simple Network Management Protocol (SNMP). CiscoWorks LAN
Management Solution (LMS) is a bundle of applications that manage the network from a
centralized location, automating many routine tasks and making your job easier and more
efficient.