2013 – NETWORK MANAGEMENT SYSTEMs (NMS):

ISO MODEL (5): Document ID: 15114:

Contents:

Introduction
Network Management
Fault Management:
      Network Management Platforms
      Troubleshooting Infrastructure
      Fault Detection & Notification
      Proactive Fault Monitoring &        Notification
Configuration Management:
      Configuration Standards
      Configuration File Management
      Inventory Management
      Software Management
Performance Management:
      Service Level Agreement
      Performance Monitoring, Measurement, and Reporting
      Performance Analysis and Tuning
Security Management:
      Authentication
      Authorization
      Accounting
      SNMP Security
Accounting Management:
      NetFlow Activation and Data Collection Strategy
      Configure IP Accounting

INTRODUCTION:

The International Organization for Standardization (ISO) network management model defines five functional areas of network management. This document covers all functional areas. The overall purpose of this document is to provide practical recommendations on each functional area to increase the overall effectiveness of current management tools and practices. It also provides design guidelines for future implementation of network management tools and technologies.

NETWORK MANAGEMENT:

The ISO network management model’s five functional areas are listed below.

Fault Management—Detect, isolate, notify, and correct faults encountered in the network.

Configuration Management—
Configuration aspects of network devices such as configuration file management, inventory management, and software management.

Performance Management—Monitor and measure various aspects of performance so that overall performance can be maintained at an acceptable level.

Security Management—Provide access to network devices and corporate resources to authorized individuals.

Accounting Management—Usage information of network resources.

The following diagram shows a reference architecture that Cisco Systems believes should be the minimal solution for managing a data network. This architecture includes a Cisco CallManager server for those who plan to manage Voice over Internet Protocol (VoIP): The diagram shows how you would integrate the CallManager server into the NMS topology.

The network management architecture includes the following:

*Simple Network Management Protocol (SNMP) platform for fault management

*Performance monitoring platform for long term performance management and trending

*CiscoWorks2000 server for configuration management, syslog collection, and hardware and software inventory management

Some SNMP platforms can directly share data with the CiscoWorks2000 server using Common Information Model/eXtensible Markup Language (CIM/XML) methods. CIM is a common data model of an implementation-neutral schema for describing overall management information in a network/enterprise environment. CIM is comprised of a specification and a schema. The specification defines the details for integration with other management models such as SNMP MIBs or Desktop Management Task Force Management Information Files (DMTF MIFs), while the schema provides the actual model descriptions.

XML is a markup language used for representing structured data in textual form. A specific goal of XML was to keep most of the descriptive power of SGML whilst removing as much of the complexity as possible. XML is similar in concept to HTML, but whereas HTML is used to convey graphical information about a document, XML is used to represent structured data in a document.

Cisco’s advanced services customers would also include Cisco’s NATkit server for additional proactive monitoring and troubleshooting. The NATkit server would either have a remote disk mount (rmount) or file transfer protocol (FTP) access to the data residing on the CiscoWorks2000 server.

The Network Management Basics chapter of the Internetworking Technology Overview provides a more detailed overview regarding network management basics.
 

1). Fault Management:

The goal of fault management is to detect, log, notify users of, and (to the extent possible) automatically fix network problems to keep the network running effectively. Because faults can cause downtime or unacceptable network degradation, fault management is perhaps the most widely implemented of the ISO network management elements.

Network Management Platforms

A network management platform deployed in the enterprise manages an infrastructure that consists of multivendor network elements. The platform receives and processes events from network elements in the network. Events from servers and other critical resources can also be forwarded to a management platform. The following commonly available functions are included in a standard management platform:

Network discovery

Topology mapping of network elements

Event handler

Performance data collector and grapher

Management data browser

Network management platforms can be viewed as the main console for network operations in detecting faults in the infrastructure. The ability to detect problems quickly in any network is critical. Network operations personnel can rely on a graphical network map to display the operational states of critical network elements such as routers and switches.

Network management platforms such as HP OpenView, Computer Associates Unicenter, and SUN Solstice can perform a discovery of network devices. Each network device is represented by a graphical element on the management platform’s console. Different colors on the graphical elements represent the current operational status of network devices. Network devices can be configured to send notifications, called SNMP traps, to network management platforms. Upon receiving the notifications, the graphical element representing the network device changes to a different color depending on the severity of the notification received. The notification, usually called an event, is placed in a log file. It is particularly important that the most current Cisco Management Information Base (MIB) files be loaded on the SNMP platform to ensure that the various alerts from Cisco devices are interpreted correctly.

Cisco publishes the MIB files for managing various network devices. The Cisco MIB files are located on the cisco.com website, and include the following information:

MIB files published in SNMPv1 format

MIB files published in SNMPv2 format

Supported SNMP traps on Cisco devices

OIDs for Cisco current SNMP MIB objects

A number of network management platforms are capable of managing multiple geographically distributed sites. This is accomplished by exchanging management data between management consoles at remote sites with a management station at the main site. The main advantage of a distributed architecture is that it reduces management traffic, thus, providing a more effective usage of bandwidth. A distributed architecture also allows personnel to locally manage their networks from remote sites with systems.

A recent enhancement to management platforms is the ability to remotely management network elements using a web interface. This enhancement eliminates the need for special client software on individual user stations to access a management platform.

A typical enterprise is comprised of different network elements. However, each device normally requires vendor-specific element management systems in order to effectively manage the network elements. Therefore, duplicate management stations may be polling network elements for the same information. The data collected by different systems is stored in separate databases, creating administration overhead for users. This limitation has prompted networking and software vendors to adopt standards such as Common Object Request Broker Architecture (CORBA) and Computer-Integrated Manufacturing (CIM) to facilitate the exchange of management data between management platforms and element management systems. With vendors adopting standards in management system development, users can expect interoperability and cost savings in deploying and managing the infrastructure.

CORBA specifies a system that provides interoperability between objects in a heterogeneous, distributed environment and in a manner that is transparent to the programmer. Its design is based on the Object Management Group (OMG) object model.

Troubleshooting Infrastructure

Trivial File Transfer Protocol (TFTP) and system log (syslog) servers are crucial components of a troubleshooting infrastructure in network operations. The TFTP server is used primarily for storing configuration files and software images for network devices. Routers and switches are capable of sending system log messages to a syslog server. The messages facilitate the troubleshooting function when problems are encountered. Occasionally, Cisco support personnel need the syslog messages to perform root cause analysis.

The CiscoWorks2000 Resource Management Essentials (Essentials) distributed syslog collection function allows for the deployment of several UNIX or NT collection stations at remote sites to perform message collection and filtering. The filters can specify which syslog messages will be forwarded to the main Essentials server. A major benefit of implementing distributed collection is the reduction of messages forwarded to the main syslog servers.

Fault Detection and Notification

The purpose of fault management is to detect, isolate, notify, and correct faults encountered in the network. Network devices are capable of alerting management stations when a fault occurs on the systems. An effective fault management system consists of several subsystems. Fault detection is accomplished when the devices send SNMP trap messages, SNMP polling, remote monitoring (RMON) thresholds, and syslog messages. A management system alerts the end user when a fault is reported and corrective actions can be taken.

Traps should be enabled consistently on network devices. Additional traps are supported with new Cisco IOS software releases for routers and switches. It is important to check and update the configuration file to ensure the proper decoding of traps. A periodic review of configured traps with the Cisco Assured Network Services (ANS) team will ensure effective fault detection in the network.

The following table lists the CISCO-STACK-MIB traps that are supported by, and can be used to monitor fault conditions on, Cisco Catalyst local area network (LAN) switches.
********

********

Environmental monitor (envmon) traps are defined in CISCO-ENVMON-MIB trap. The envmon trap sends Cisco enterprise-specific environmental monitor notifications when an environmental threshold is exceeded. When envmon is used, a specific environmental trap type can be enabled, or all trap types from the environmental monitor system can be accepted. If no option is specified, all environmental types are enabled. It can be one or more of the following values:

:

voltage—A ciscoEnvMonVoltageNotification is sent if the voltage measured at a given test point is outside the normal range for the test point (such as is at the warning, critical, or shutdown stage).

shutdown—A ciscoEnvMonShutdownNotification is sent if the environmental monitor detects that a test point is reaching a critical state and is about to initiate a shutdown.

   supply—A ciscoEnvMonRedundantSupplyNotification is sent if the redundant power supply (where extant) fails.

   fan—A ciscoEnvMonFanNotification is sent if any one of the fans in the fan array (where extant) fails.

   temperature—A ciscoEnvMonTemperatureNotification is sent if the temperature measured at a given test point is outside the normal range for the test point (such as is at the warning, critical, or shutdown stage).

Fault detection and monitoring of network elements can be expanded from the device level to the protocol and interface levels. For a network environment, fault monitoring can include Virtual Local Area Network (VLAN), asynchronous transfer mode (ATM), fault indications on physical interfaces, and so forth. Protocol-level fault management implementation is available using an element management system such as the CiscoWorks2000 Campus Manager. The TrafficDirector application in Campus Manager focuses on switch management utilizing mini-RMON support on Catalyst switches.

With an increasing number of network elements and complexity of network issues, an event management system that is capable of correlating different network events (syslog, trap, log files) may be considered. This architecture behind an event management system is comparable to a Manager of Managers (MOM) system. A well-designed event management system allows personnel in the network operations center (NOC) to be proactive and effective in detecting and diagnosing network issues. Event prioritization and suppression allow network operation personnel to focus on critical network events, investigate several event management systems including the Cisco Info Center, and conduct a feasibility analysis to fully explore the capabilities of such systems. To obtain more information, go to the Cisco Info Center.

Proactive Fault Monitoring and Notification

RMON alarm and event are two groups defined in the RMON specification. Normally, a management station performs polling on network devices to determine the status or value of certain variables. For example, a management station polls a router to find out the central processing unit (CPU) utilization and generate an event when the value hits reaches a configured threshold. This method wastes network bandwidth and can also miss the actual threshold depending on the polling interval.

With RMON alarm and events, a network device is configured to monitor itself for rising and falling thresholds. At a predefined time interval, the network device will takes a sample of a variable and compares it against the thresholds. An SNMP trap can be sent to a management station if the actual value exceeds or falls below the configured thresholds. RMON alarm and event groups provide a proactive method of managing critical network devices.

Cisco Systems recommends implementing RMON alarm and event on critical network devices. Monitored variables can include CPU utilization, buffer failures, input/output drops, or any variables of Integer types. Starting with Cisco IOS Software Release 11.1(1), all router images support RMON alarm and event groups.

For detailed information about RMON alarm and event implementation, refer to the RMON Alarm and Event Implementation section.

RMON Memory Constraints

RMON memory usage is constant across all switch platforms relating to statistics, histories, alarms, and events. RMON uses what is called a bucket to store histories and statistics on the RMON agent (which is the switch in this case). The bucket size is defined on the RMON probe (SwitchProbe device) or RMON application (TrafficDirector tool), then sent to the switch to be set.

Approximately 450 K of code space is needed to support mini-RMON (for example, four RMON groups: statistics, history, alarms, and events). The dynamic memory requirement for RMON varies because it depends on the runtime configuration.

The following table defines the runtime RMON memory usage information for each mini-RMON group.
†**********

RMON Group Definition DRAM Space Used Notes
Statistics 140 bytes per switched Ethernet/Fast Ethernet port Per port
History 3.6 K for 50 buckets * Each additional bucket uses 56 bytes
Alarm and Event 2.6 K per alarm and its corresponding event entries Per alarm per port
******************

*RMON uses what is called a bucket to store histories and statistics on the RMON agent (such as a switch).

RMON Alarm and Event Implementation

By incorporating RMON as part of a fault management solution, a user can proactively monitor the network before a potential problem occurs. For example, if the number of broadcast packets received increases significantly, it can cause an increase in CPU utilization. By implementing RMON alarm and event, a user can set up a threshold to monitor the number of broadcast packets received and alert the SNMP platform by means of an SNMP trap if the configured threshold is reached. RMON alarms and events eliminate the excessive polling normally performed by the SNMP platform for accomplishing the same goal.

Two methods are available from which to configure RMON alarm and event:

Command-line interface (CLI)

SNMP SET

The following sample procedures show how to set a threshold to monitor the number of broadcast packets received on an interface. The same counter is used in these procedures as is shown in the show interface command example at the end of this section.

Command-line Interface Example

To implement RMON alarm and event using the CLI interface, perform the following steps:

Find the interface index associated with Ethernet 0 by walking the ifTable MIB.

interfaces.ifTable.ifEntry.ifDescr.1 = “Ethernet0”
interfaces.ifTable.ifEntry.ifDescr.2 = “Ethernet1”
interfaces.ifTable.ifEntry.ifDescr.3 = “FastEthernet0”
interfaces.ifTable.ifEntry.ifDescr.4 = “Fddi0”
Obtain the OID associated with the CLI field to be monitored. For this example, the OID for ‘broadcasts’ is 1.3.6.1.2.1.2.2.1.12. The Cisco OIDs for specific MIB variables are available from the cisco.com website.

Determine the following parameters for setting up thresholds and events.

rising and falling thresholds

sampling type (absolute or delta)

sampling interval

action when threshold is reached

For the purpose of this example, a threshold is being set up to monitor the number of broadcast packets received on Ethernet 0. A trap will be generated if the number of broadcast packets received is greater than 500 between 60-second samples. The threshold will be reactivated when the number of input broadcasts does not increase between samples taken.

Note:  For detailed about these command parameters, check the Cisco Connection Online (CCO) documentation for RMON alarm and event commands for your particular Cisco IOS version.

Specify the trap sent (RMON event) when the threshold is reached using the following CLI commands (The Cisco IOS commands are displayed in bold):

rmon event 1 trap gateway description “High Broadcast on Ethernet 0” owner cisco

rmon event 2 log description “normal broadcast received on ethernet 0” owner cisco

Specify the thresholds and relevant parameters (RMON alarm) using the following CLI commands:

rmon alarm 1 ifEntry.12.1 60 delta rising-threshold 500 1

falling-threshold 0 2 owner cisco

Use SNMP to poll these tables to verify that the eventTable entries were made on the device.

rmon.event.eventTable.eventEntry.eventIndex.1 = 1

rmon.event.eventTable.eventEntry.eventIndex.2 = 2

rmon.event.eventTable.eventEntry.eventDescription.1 =
“High Broadcast on Ethernet 0”

rmon.event.eventTable.eventEntry.eventDescription.2 =
“normal broadcast received on ethernet 0”

rmon.event.eventTable.eventEntry.eventType.1 = snmp-trap(3)

rmon.event.eventTable.eventEntry.eventType.2 = log(2)

rmon.event.eventTable.eventEntry.eventCommunity.1 = “gateway”

rmon.event.eventTable.eventEntry.eventCommunity.2 = “”

rmon.event.eventTable.eventEntry.eventLastTimeSent.1 =
Timeticks: (0) 0:00:00

rmon.event.eventTable.eventEntry.eventLastTimeSent.2 =
Timeticks: (0) 0:00:00

rmon.event.eventTable.eventEntry.eventOwner.1 = “cisco”

rmon.event.eventTable.eventEntry.eventOwner.2 = “cisco”

rmon.event.eventTable.eventEntry.eventStatus.1 = valid(1)

rmon.event.eventTable.eventEntry.eventStatus.2 = valid(1)
Use SNMP to poll these tables to verify that the alarmTable entries were set.

rmon.alarm.alarmTable.alarmEntry.alarmIndex.1 = 1

rmon.alarm.alarmTable.alarmEntry.alarmInterval.1 = 60

rmon.alarm.alarmTable.alarmEntry.alarmVariable.1 = OID:
interfaces.ifTable.ifEntry.ifInNUcastPkts.2

rmon.alarm.alarmTable.alarmEntry.alarmSampleType.1 = absoluteValue(1)

rmon.alarm.alarmTable.alarmEntry.alarmValue.1 = 170183

rmon.alarm.alarmTable.alarmEntry.alarmStartupAlarm.1 =
risingOrFallingAlarm(3)

rmon.alarm.alarmTable.alarmEntry.alarmRisingThreshold.1 = 500

rmon.alarm.alarmTable.alarmEntry.alarmFallingThreshold.1 = 0

rmon.alarm.alarmTable.alarmEntry.alarmRisingEventIndex.1 = 1

rmon.alarm.alarmTable.alarmEntry.alarmFallingEventIndex.1 = 2

rmon.alarm.alarmTable.alarmEntry.alarmOwner.1 = “cisco”

rmon.alarm.alarmTable.alarmEntry.alarmStatus.1 = valid(1)
SNMP SET Example

In order to implement RMON alarm and event with the SNMP SET operation, complete these steps:

Specify the trap sent (RMON event) when the threshold is reached using the following SNMP SET operations:

# snmpset -c private 172.16.97.132 1.3.6.1.2.1.16.9.1.1.2.1
  octetstring “High Broadcast on Ethernet 0”
  eventDescription.1 : DISPLAY STRING- (ascii): High Broadcast on Ethernet 0

# snmpset -c private 172.16.97.132 1.3.6.1.2.1.16.9.1.1.3.1
  integer 3 eventType.1 : INTEGER: SNMP-trap

# snmpset -c private 172.16.97.132 1.3.6.1.2.1.16.9.1.1.4.1 octetstring “gateway”
  eventCommunity.1 : OCTET STRING- (ASCII): gateway

# snmpset -c private 172.16.97.132 1.3.6.1.2.1.16.9.1.1.6.1
  octetstring “cisco” eventOwner.1 : OCTET STRING- (ASCII): cisco

# snmpset -c private 172.16.97.132 1.3.6.1.2.1.16.9.1.1.7.1 integer 1
  eventStatus.1 : INTEGER: valid
Specify the thresholds and relevant parameters (RMON alarm) using the following SNMP SET operations:

# snmpset -c private 172.16.97.132 1.3.6.1.2.1.16.9.1.1.2.2
  octetstring “normal broadcast received on ethernet 0”
  eventDescription.2 : DISPLAY STRING- (ASCII): normal broadcast
  received on ethernet 0

# snmpset -c private 172.16.97.132 1.3.6.1.2.1.16.9.1.1.3.2 integer 2
  eventType.2 : INTEGER: log

# snmpset -c private 172.16.97.132 1.3.6.1.2.1.16.9.1.1.6.2 octetstring “cisco”
  eventOwner.2 : OCTET STRING- (ASCII): cisco

# snmpset -c private 172.16.97.132 1.3.6.1.2.1.16.9.1.1.7.2 integer 1
  eventStatus.2 : INTEGER: valid
Poll these tables to verify that the eventTable entries were made on the device.

% snmpwalk -v 1 172.16.97.132 private .1.3.6.1.2.1.16.9.1

# snmpset -c private 172.16.97.132 1.3.6.1.2.1.16.3.1.1.2.1 integer 60
  alarmInterval.1 : INTEGER: 60

# snmpset -c private 172.16.97.132 1.3.6.1.2.1.16.3.1.1.3.1
objectidentifier .1.3.6.1.2.1.2.2.1.12.2
  alarmVariable.1 : OBJECT IDENTIFIER:
.iso.org.dod.internet.mgmt.mib2.interfaces.ifTable
  ifEntry.ifInNUcastPkts.2

# snmpset -c private 172.16.97.132 1.3.6.1.2.1.16.3.1.1.4.1 integer 2

alarmSampleType.1 : INTEGER: deltaValue

# snmpset -c private 172.16.97.132 1.3.6.1.2.1.16.3.1.1.7.1 integer 500
  alarmRisingThreshold.1 : INTEGER: 500

# snmpset -c private 172.16.97.132 1.3.6.1.2.1.16.3.1.1.8.1 integer 0
  alarmFallingThreshold.1 : INTEGER: 0

# snmpset -c private 172.16.97.132 1.3.6.1.2.1.16.3.1.1.9.1 integer 1
  alarmRisingEventIndex.1 : INTEGER: 1

# snmpset -c private 172.16.97.132 1.3.6.1.2.1.16.3.1.1.10.1 integer 2
  alarmFallingEventIndex.1 : INTEGER: 2

# snmpset -c private 172.16.97.132 1.3.6.1.2.1.16.3.1.1.11.1 octetstring
“cisco”
  alarmOwner.1 : OCTET STRING- (ASCII): cisco

# snmpset -c private 172.16.97.132 1.3.6.1.2.1.16.3.1.1.12.1 integer 1
  alarmStatus.1 : INTEGER: valid
Poll these tables to verify that the alarmTable entries were set.

% snmpwalk -v 1 172.16.97.132 private .1.3.6.1.2.1.16.3.1
show interface

This example is a result of the show interface command.

gateway> show interface ethernet 0

Ethernet0 is up, line protocol is up
Hardware is Lance, address is 0000.0c38.1669 (bia 0000.0c38.1669)
Description: NMS workstation LAN
Internet address is 172.16.97.132/24
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255
Encapsulation ARPA, loopback not set, keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of “show interface” counters never
Queueing strategy: fifo
Output queue 0/40, 27 drops; input queue 0/75, 0 drops
5 minute input rate 1000 bits/sec, 2 packets/sec
5 minute output rate 1000 bits/sec, 1 packets/sec
21337627 packets input, 3263376846 bytes, 0 no buffer

Received 7731303 broadcasts
, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
0 input packets with dribble condition detected
17328035 packets output, 2824522759 bytes, 0 underruns
174 output errors, 44368 collisions, 4 interface resets
0 babbles, 0 late collision, 104772 deferred
174 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out

2. Configuration Management:
   
    TOC:

      2-1: Configuration Standards:
      2-2: Configuration File Management:
      2-3: Inventory Management:
      2-4: Software Management:

2-1: Configuration Standards:

With an increasing number of network devices deployed, it is critical to be able to accurately identify the location of a network device. This location information should provide a detailed description meaningful to those tasked with dispatching resources when a network problem occurs. To expedite a resolution if a network problem occurs, make certain to have available contact information of the person or department responsible for the devices. Contact information should include telephone number and the name of the person or department.

Naming conventions for network devices, starting from device name to individual interface, should be planned and implemented as part of the configuration standard. A well defined naming convention provides personnel with the ability to provide accurate information when troubleshooting network problems. The naming convention for devices can use geographical location, building name, floor, and so forth. For the interface naming convention, it can include the segment to which a port is connected, name of connecting hub, and so forth. On serial interfaces, it should include actual bandwidth, local data link connection identifier (DLCI) number (if Frame Relay), destination, and the circuit ID or information provided by the carrier.

2-2: Configuration File Management:

When you add new configuration commands on existing network devices needs, you must verify the commands for integrity before actual implementation takes place. An improperly configured network device can have a disastrous effect on network connectivity and performance. Configuration command parameters must be checked to avoid mismatches or incompatibility issues. It is advisable to schedule a thorough review of configurations with Cisco engineers on a regular basis.

A fully functional CiscoWorks2000 Essentials allows for backing up configuration files on routers and Cisco Catalyst switches automatically. The security feature of Essentials can be used to perform authentication on configuration changes. A change audit log is available to track changes and the user name of individuals issuing changes. For configuration changes on multiple devices, two options are available: the web-based NetConfig in the current version of CiscoWorks2000 Essentials or the cwconfig script. Configuration files can be downloaded and uploaded using CiscoWorks2000 Essentials utilizing the predefined or user-defined templates.

These functions can be accomplished with the configuration management tools in CiscoWorks2000 Essentials:

Push configuration files from the Essentials configuration archive to a device or multiple devices

Pull the configuration from the device to the Essentials archive

Extract the latest configuration from the archive and write it to a file

Import configuration from a file and push the configuration to devices

Compare the last two configurations in the Essentials archive

Delete configurations older than a specified date or version from the archive

Copy the startup configuration to the running configuration

 2-3: Inventory Management:

The discovery function of most network management platforms is intended to provide a dynamic listing of devices found in the network. Discovery engines such as those implemented in network management platforms should be utilized.

An inventory database provides detailed configuration information on network devices. Common information includes models of hardware, installed modules, software images, microcode levels, and so on. All these pieces of information are crucial in completing tasks such as software and hardware maintenance. The up-to-date listing of network devices collected by the discovery process can be used as a master list to collect inventory information using SNMP or scripting. A device list may be imported from CiscoWorks2000 Campus Manager into the inventory database of CiscoWorks2000 Essentials to obtain an up-to-date inventory of Cisco Catalyst switches.

 2-4: Software Management:

A successful upgrade of Cisco IOS images on network devices requires a detailed analysis of the requirements such as memory, boot ROM, microcode level, and so on. The requirements are normally documented and available on Cisco’s web site in the form of release notes and installation guides. The process of upgrading a network device running Cisco IOS includes downloading a correct image from CCO, backing up the current image, making sure all hardware requirements are met, and then loading the new image into the device.

The upgrade window to complete device maintenance is fairly limited for some organizations. In a large network environment with limited resources, it might be necessary to schedule and automate software upgrades after business hours. The procedure can be completed either using scripting language such as Expect or an application written specifically to perform such a task.

Changes to software in network devices such as Cisco IOS images and microcode versions should be tracked to assist in the analysis phase when another software maintenance is required. With a modification history report readily available, the person performing the upgrade can minimize the risk of loading incompatib kole images or microcode into network devices.
—_———_——————–

3. Performance Management:
     TOC:
     3-1: Service Level Agreement:
     3-2: Performance Monitoring:
     3-3: Measurement, and Reporting:
     3-4: Performance Analysis & Tuning

3-1: Service Level Agreement:

A service level agreement (SLA) is a written agreement between a service provider and their customers on the expected performance level of network services. The SLA consists of metrics agreed upon between the provider and its customers. The values set for the metrics must be realistic, meaningful, and measurable for both parties.

Various interface statistics can be collected from network devices to measure the performance level. These statistics can be included as metrics in the SLA. Statistics such as input queue drops, output queue drops, and ignored packets are useful for diagnosing performance-related problems.

At the device level, performance metrics can include CPU utilization, buffer allocation (big buffer, medium buffer, misses, hit ratio), and memory allocation. The performance of certain network protocols is directly related to buffer availability in network devices. Measuring device-level performance statistics are critical in optimizing the performance of higher-level protocols.

Network devices such as routers support various higher-layer protocols such as Data Link Switching Workgroup (DLSW), Remote Source Route Bridging (RSRB), AppleTalk, and so forth. Performance statistics of wide-area network (WAN) technologies including Frame Relay, ATM, Integrated Services Digital Network (ISDN), and others can be monitored and collected.

3-2: Performance Monitoring:

   Document ID: 15114

PDF Downloads
Network Management System: Best Practices White Paper
Share on printShare on emailShare on favoritesShare on googleShare on twitterShare on facebook
 Feedback
Related Documents
• Network Management System: Best Practices White Paper
• Performance Management: Best Practices White Paper
• Capacity and Performance Management: Best Practices White Paper
• Service Level Management: Best Practices White Paper
• Configuration Management: Best Practices White Paper

More…

Related Products/Technology
• Service Assurance Agent (SAA)
• CiscoWorks Resource Manager Essentials
• Simple Network Management Protocol (SNMP)
• Remote Monitoring (RMON)

Related Discussion
• setup RPS 2300 priority via CLI
• 16 interfaces into one bundle MLPPP
• max link per bundle MLPPP
• BGP Peering
• Cisco IDS, PIX, VPN Concentrator,…

Contents
Introduction
Network Management
Fault Management
      Network Management Platforms
      Troubleshooting Infrastructure
      Fault Detection and Notification
      Proactive Fault Monitoring and Notification
Configuration Management
      Configuration Standards
      Configuration File Management
      Inventory Management
      Software Management
Performance Management
      Service Level Agreement
      Performance Monitoring, Measurement, and Reporting
      Performance Analysis and Tuning
Security Management
      Authentication
      Authorization
      Accounting
      SNMP Security
Accounting Management
      NetFlow Activation and Data Collection Strategy
      Configure IP Accounting
Cisco Support Community – Featured Conversations
Related Information
Introduction

The International Organization for Standardization (ISO) network management model defines five functional areas of network management. This document covers all functional areas. The overall purpose of this document is to provide practical recommendations on each functional area to increase the overall effectiveness of current management tools and practices. It also provides design guidelines for future implementation of network management tools and technologies.

Network Management

The ISO network management model’s five functional areas are listed below.

Fault Management—Detect, isolate, notify, and correct faults encountered in the network.

Configuration Management—Configuration aspects of network devices such as configuration file management, inventory management, and software management.

Performance Management—Monitor and measure various aspects of performance so that overall performance can be maintained at an acceptable level.

Security Management—Provide access to network devices and corporate resources to authorized individuals.

Accounting Management—Usage information of network resources.

The following diagram shows a reference architecture that Cisco Systems believes should be the minimal solution for managing a data network. This architecture includes a Cisco CallManager server for those who plan to manage Voice over Internet Protocol (VoIP): The diagram shows how you would integrate the CallManager server into the NMS topology.

The network management architecture includes the following:

Simple Network Management Protocol (SNMP) platform for fault management

Performance monitoring platform for long term performance management and trending

CiscoWorks2000 server for configuration management, syslog collection, and hardware and software inventory management

Some SNMP platforms can directly share data with the CiscoWorks2000 server using Common Information Model/eXtensible Markup Language (CIM/XML) methods. CIM is a common data model of an implementation-neutral schema for describing overall management information in a network/enterprise environment. CIM is comprised of a specification and a schema. The specification defines the details for integration with other management models such as SNMP MIBs or Desktop Management Task Force Management Information Files (DMTF MIFs), while the schema provides the actual model descriptions.

XML is a markup language used for representing structured data in textual form. A specific goal of XML was to keep most of the descriptive power of SGML whilst removing as much of the complexity as possible. XML is similar in concept to HTML, but whereas HTML is used to convey graphical information about a document, XML is used to represent structured data in a document.

Cisco’s advanced services customers would also include Cisco’s NATkit server for additional proactive monitoring and troubleshooting. The NATkit server would either have a remote disk mount (rmount) or file transfer protocol (FTP) access to the data residing on the CiscoWorks2000 server.

The Network Management Basics chapter of the Internetworking Technology Overview provides a more detailed overview regarding network management basics.

Fault Management

The goal of fault management is to detect, log, notify users of, and (to the extent possible) automatically fix network problems to keep the network running effectively. Because faults can cause downtime or unacceptable network degradation, fault management is perhaps the most widely implemented of the ISO network management elements.

Network Management Platforms

A network management platform deployed in the enterprise manages an infrastructure that consists of multivendor network elements. The platform receives and processes events from network elements in the network. Events from servers and other critical resources can also be forwarded to a management platform. The following commonly available functions are included in a standard management platform:

Network discovery

Topology mapping of network elements

Event handler

Performance data collector and grapher

Management data browser

Network management platforms can be viewed as the main console for network operations in detecting faults in the infrastructure. The ability to detect problems quickly in any network is critical. Network operations personnel can rely on a graphical network map to display the operational states of critical network elements such as routers and switches.

Network management platforms such HP OpenView, Computer Associates Unicenter, and SUN Solstice can perform a discovery of network devices. Each network device is represented by a graphical element on the management platform’s console. Different colors on the graphical elements represent the current operational status of network devices. Network devices can be configured to send notifications, called SNMP traps, to network management platforms. Upon receiving the notifications, the graphical element representing the network device changes to a different color depending on the severity of the notification received. The notification, usually called an event, is placed in a log file. It is particularly important that the most current Cisco Management Information Base (MIB) files be loaded on the SNMP platform to ensure that the various alerts from Cisco devices are interpreted correctly.

Cisco publishes the MIB files for managing various network devices. The Cisco MIB files are located on the cisco.com website, and include the following information:

MIB files published in SNMPv1 format

MIB files published in SNMPv2 format

Supported SNMP traps on Cisco devices

OIDs for Cisco current SNMP MIB objects

A number of network management platforms are capable of managing multiple geographically distributed sites. This is accomplished by exchanging management data between management consoles at remote sites with a management station at the main site. The main advantage of a distributed architecture is that it reduces management traffic, thus, providing a more effective usage of bandwidth. A distributed architecture also allows personnel to locally manage their networks from remote sites with systems.

A recent enhancement to management platforms is the ability to remotely management network elements using a web interface. This enhancement eliminates the need for special client software on individual user stations to access a management platform.

A typical enterprise is comprised of different network elements. However, each device normally requires vendor-specific element management systems in order to effectively manage the network elements. Therefore, duplicate management stations may be polling network elements for the same information. The data collected by different systems is stored in separate databases, creating administration overhead for users. This limitation has prompted networking and software vendors to adopt standards such as Common Object Request Broker Architecture (CORBA) and Computer-Integrated Manufacturing (CIM) to facilitate the exchange of management data between management platforms and element management systems. With vendors adopting standards in management system development, users can expect interoperability and cost savings in deploying and managing the infrastructure.

CORBA specifies a system that provides interoperability between objects in a heterogeneous, distributed environment and in a manner that is transparent to the programmer. Its design is based on the Object Management Group (OMG) object model.

Troubleshooting Infrastructure

Trivial File Transfer Protocol (TFTP) and system log (syslog) servers are crucial components of a troubleshooting infrastructure in network operations. The TFTP server is used primarily for storing configuration files and software images for network devices. Routers and switches are capable of sending system log messages to a syslog server. The messages facilitate the troubleshooting function when problems are encountered. Occasionally, Cisco support personnel need the syslog messages to perform root cause analysis.

The CiscoWorks2000 Resource Management Essentials (Essentials) distributed syslog collection function allows for the deployment of several UNIX or NT collection stations at remote sites to perform message collection and filtering. The filters can specify which syslog messages will be forwarded to the main Essentials server. A major benefit of implementing distributed collection is the reduction of messages forwarded to the main syslog servers.

Fault Detection and Notification

The purpose of fault management is to detect, isolate, notify, and correct faults encountered in the network. Network devices are capable of alerting management stations when a fault occurs on the systems. An effective fault management system consists of several subsystems. Fault detection is accomplished when the devices send SNMP trap messages, SNMP polling, remote monitoring (RMON) thresholds, and syslog messages. A management system alerts the end user when a fault is reported and corrective actions can be taken.

Traps should be enabled consistently on network devices. Additional traps are supported with new Cisco IOS software releases for routers and switches. It is important to check and update the configuration file to ensure the proper decoding of traps. A periodic review of configured traps with the Cisco Assured Network Services (ANS) team will ensure effective fault detection in the network.

The following table lists the CISCO-STACK-MIB traps that are supported by, and can be used to monitor fault conditions on, Cisco Catalyst local area network (LAN) switches.

Trap Description
moduleUp The agent entity has detected that the moduleStatus object in this MIB has transitioned to the ok(2) state for one of its modules.
moduleDown The agent entity has detected that the moduleStatus object in this MIB has transitioned out of the ok(2) state for one of its modules.
chassisAlarmOn The agent entity has detected that the chassisTempAlarm, chassisMinorAlarm, or chassisMajorAlarm object in this MIB has transitioned to the on(2) state. A chassisMajorAlarm indicates that one of the following conditions exists:
Any voltage failure
Simultaneous temperature and fan failure
One hundred percent power supply failure (two out of two, or one out of one)
Electrically erasable programmable read-only memory (EEPROM) failure
Nonvolatile RAM (NVRAM) failure
MCP communication failure
NMP status unknown
A chassisMinorAlarm indicates that one of the following conditions exists:
Temperature alarm
Fan failure
Partial power supply failure (one out of two)
Two power supplies of incompatible type
chassisAlarmOff The agent entity has detected that the chassisTempAlarm, chassisMinorAlarm, or chassisMajorAlarm object in this MIB has transitioned to the off(1) state.
Environmental monitor (envmon) traps are defined in CISCO-ENVMON-MIB trap. The envmon trap sends Cisco enterprise-specific environmental monitor notifications when an environmental threshold is exceeded. When envmon is used, a specific environmental trap type can be enabled, or all trap types from the environmental monitor system can be accepted. If no option is specified, all environmental types are enabled. It can be one or more of the following values:

voltage—A ciscoEnvMonVoltageNotification is sent if the voltage measured at a given test point is outside the normal range for the test point (such as is at the warning, critical, or shutdown stage).

shutdown—A ciscoEnvMonShutdownNotification is sent if the environmental monitor detects that a test point is reaching a critical state and is about to initiate a shutdown.

supply—A ciscoEnvMonRedundantSupplyNotification is sent if the redundant power supply (where extant) fails.

fan—A ciscoEnvMonFanNotification is sent if any one of the fans in the fan array (where extant) fails.

temperature—A ciscoEnvMonTemperatureNotification is sent if the temperature measured at a given test point is outside the normal range for the test point (such as is at the warning, critical, or shutdown stage).

Fault detection and monitoring of network elements can be expanded from the device level to the protocol and interface levels. For a network environment, fault monitoring can include Virtual Local Area Network (VLAN), asynchronous transfer mode (ATM), fault indications on physical interfaces, and so forth. Protocol-level fault management implementation is available using an element management system such as the CiscoWorks2000 Campus Manager. The TrafficDirector application in Campus Manager focuses on switch management utilizing mini-RMON support on Catalyst switches.

With an increasing number of network elements and complexity of network issues, an event management system that is capable of correlating different network events (syslog, trap, log files) may be considered. This architecture behind an event management system is comparable to a Manager of Managers (MOM) system. A well-designed event management system allows personnel in the network operations center (NOC) to be proactive and effective in detecting and diagnosing network issues. Event prioritization and suppression allow network operation personnel to focus on critical network events, investigate several event management systems including the Cisco Info Center, and conduct a feasibility analysis to fully explore the capabilities of such systems. To obtain more information, go to the Cisco Info Center.

Proactive Fault Monitoring and Notification

RMON alarm and event are two groups defined in the RMON specification. Normally, a management station performs polling on network devices to determine the status or value of certain variables. For example, a management station polls a router to find out the central processing unit (CPU) utilization and generate an event when the value hits reaches a configured threshold. This method wastes network bandwidth and can also miss the actual threshold depending on the polling interval.

With RMON alarm and events, a network device is configured to monitor itself for rising and falling thresholds. At a predefined time interval, the network device will takes a sample of a variable and compares it against the thresholds. An SNMP trap can be sent to a management station if the actual value exceeds or falls below the configured thresholds. RMON alarm and event groups provide a proactive method of managing critical network devices.

Cisco Systems recommends implementing RMON alarm and event on critical network devices. Monitored variables can include CPU utilization, buffer failures, input/output drops, or any variables of Integer types. Starting with Cisco IOS Software Release 11.1(1), all router images support RMON alarm and event groups.

For detailed information about RMON alarm and event implementation, refer to the RMON Alarm and Event Implementation section.

RMON Memory Constraints

RMON memory usage is constant across all switch platforms relating to statistics, histories, alarms, and events. RMON uses what is called a bucket to store histories and statistics on the RMON agent (which is the switch in this case). The bucket size is defined on the RMON probe (SwitchProbe device) or RMON application (TrafficDirector tool), then sent to the switch to be set.

Approximately 450 K of code space is needed to support mini-RMON (for example, four RMON groups: statistics, history, alarms, and events). The dynamic memory requirement for RMON varies because it depends on the runtime configuration.

The following table defines the runtime RMON memory usage information for each mini-RMON group.

RMON Group Definition DRAM Space Used Notes
Statistics 140 bytes per switched Ethernet/Fast Ethernet port Per port
History 3.6 K for 50 buckets * Each additional bucket uses 56 bytes
Alarm and Event 2.6 K per alarm and its corresponding event entries Per alarm per port
*RMON uses what is called a bucket to store histories and statistics on the RMON agent (such as a switch).

RMON Alarm and Event Implementation

By incorporating RMON as part of a fault management solution, a user can proactively monitor the network before a potential problem occurs. For example, if the number of broadcast packets received increases significantly, it can cause an increase in CPU utilization. By implementing RMON alarm and event, a user can set up a threshold to monitor the number of broadcast packets received and alert the SNMP platform by means of an SNMP trap if the configured threshold is reached. RMON alarms and events eliminate the excessive polling normally performed by the SNMP platform for accomplishing the same goal.

Two methods are available from which to configure RMON alarm and event:

Command-line interface (CLI)

SNMP SET

The following sample procedures show how to set a threshold to monitor the number of broadcast packets received on an interface. The same counter is used in these procedures as is shown in the show interface command example at the end of this section.

Command-line Interface Example

To implement RMON alarm and event using the CLI interface, perform the following steps:

Find the interface index associated with Ethernet 0 by walking the ifTable MIB.

interfaces.ifTable.ifEntry.ifDescr.1 = “Ethernet0”
interfaces.ifTable.ifEntry.ifDescr.2 = “Ethernet1”
interfaces.ifTable.ifEntry.ifDescr.3 = “FastEthernet0”
interfaces.ifTable.ifEntry.ifDescr.4 = “Fddi0”
Obtain the OID associated with the CLI field to be monitored. For this example, the OID for ‘broadcasts’ is 1.3.6.1.2.1.2.2.1.12. The Cisco OIDs for specific MIB variables are available from the cisco.com website.

Determine the following parameters for setting up thresholds and events.

rising and falling thresholds

sampling type (absolute or delta)

sampling interval

action when threshold is reached

For the purpose of this example, a threshold is being set up to monitor the number of broadcast packets received on Ethernet 0. A trap will be generated if the number of broadcast packets received is greater than 500 between 60-second samples. The threshold will be reactivated when the number of input broadcasts does not increase between samples taken.

Note:  For details about these command parameters, check the Cisco Connection Online (CCO) documentation for RMON alarm and event commands for your particular Cisco IOS version.

Specify the trap sent (RMON event) when the threshold is reached using the following CLI commands (The Cisco IOS commands are displayed in bold):

rmon event 1 trap gateway description “High Broadcast on Ethernet 0” owner cisco

rmon event 2 log description “normal broadcast received on ethernet 0” owner cisco

Specify the thresholds and relevant parameters (RMON alarm) using the following CLI commands:

rmon alarm 1 ifEntry.12.1 60 delta rising-threshold 500 1

falling-threshold 0 2 owner cisco

Use SNMP to poll these tables to verify that the eventTable entries were made on the device.

rmon.event.eventTable.eventEntry.eventIndex.1 = 1

rmon.event.eventTable.eventEntry.eventIndex.2 = 2

rmon.event.eventTable.eventEntry.eventDescription.1 =
“High Broadcast on Ethernet 0”

rmon.event.eventTable.eventEntry.eventDescription.2 =
“normal broadcast received on ethernet 0”

rmon.event.eventTable.eventEntry.eventType.1 = snmp-trap(3)

rmon.event.eventTable.eventEntry.eventType.2 = log(2)

rmon.event.eventTable.eventEntry.eventCommunity.1 = “gateway”

rmon.event.eventTable.eventEntry.eventCommunity.2 = “”

rmon.event.eventTable.eventEntry.eventLastTimeSent.1 =
Timeticks: (0) 0:00:00

rmon.event.eventTable.eventEntry.eventLastTimeSent.2 =
Timeticks: (0) 0:00:00

rmon.event.eventTable.eventEntry.eventOwner.1 = “cisco”

rmon.event.eventTable.eventEntry.eventOwner.2 = “cisco”

rmon.event.eventTable.eventEntry.eventStatus.1 = valid(1)

rmon.event.eventTable.eventEntry.eventStatus.2 = valid(1)
Use SNMP to poll these tables to verify that the alarmTable entries were set.

rmon.alarm.alarmTable.alarmEntry.alarmIndex.1 = 1

rmon.alarm.alarmTable.alarmEntry.alarmInterval.1 = 60

rmon.alarm.alarmTable.alarmEntry.alarmVariable.1 = OID:
interfaces.ifTable.ifEntry.ifInNUcastPkts.2

rmon.alarm.alarmTable.alarmEntry.alarmSampleType.1 = absoluteValue(1)

rmon.alarm.alarmTable.alarmEntry.alarmValue.1 = 170183

rmon.alarm.alarmTable.alarmEntry.alarmStartupAlarm.1 =
risingOrFallingAlarm(3)

rmon.alarm.alarmTable.alarmEntry.alarmRisingThreshold.1 = 500

rmon.alarm.alarmTable.alarmEntry.alarmFallingThreshold.1 = 0

rmon.alarm.alarmTable.alarmEntry.alarmRisingEventIndex.1 = 1

rmon.alarm.alarmTable.alarmEntry.alarmFallingEventIndex.1 = 2

rmon.alarm.alarmTable.alarmEntry.alarmOwner.1 = “cisco”

rmon.alarm.alarmTable.alarmEntry.alarmStatus.1 = valid(1)
SNMP SET Example

In order to implement RMON alarm and event with the SNMP SET operation, complete these steps:

Specify the trap sent (RMON event) when the threshold is reached using the following SNMP SET operations:

# snmpset -c private 172.16.97.132 1.3.6.1.2.1.16.9.1.1.2.1
  octetstring “High Broadcast on Ethernet 0”
  eventDescription.1 : DISPLAY STRING- (ascii): High Broadcast on Ethernet 0

# snmpset -c private 172.16.97.132 1.3.6.1.2.1.16.9.1.1.3.1
  integer 3 eventType.1 : INTEGER: SNMP-trap

# snmpset -c private 172.16.97.132 1.3.6.1.2.1.16.9.1.1.4.1 octetstring “gateway”
  eventCommunity.1 : OCTET STRING- (ASCII): gateway

# snmpset -c private 172.16.97.132 1.3.6.1.2.1.16.9.1.1.6.1
  octetstring “cisco” eventOwner.1 : OCTET STRING- (ASCII): cisco

# snmpset -c private 172.16.97.132 1.3.6.1.2.1.16.9.1.1.7.1 integer 1
  eventStatus.1 : INTEGER: valid
Specify the thresholds and relevant parameters (RMON alarm) using the following SNMP SET operations:

# snmpset -c private 172.16.97.132 1.3.6.1.2.1.16.9.1.1.2.2
  octetstring “normal broadcast received on ethernet 0”
  eventDescription.2 : DISPLAY STRING- (ASCII): normal broadcast
  received on ethernet 0

# snmpset -c private 172.16.97.132 1.3.6.1.2.1.16.9.1.1.3.2 integer 2
  eventType.2 : INTEGER: log

# snmpset -c private 172.16.97.132 1.3.6.1.2.1.16.9.1.1.6.2 octetstring “cisco”
  eventOwner.2 : OCTET STRING- (ASCII): cisco

# snmpset -c private 172.16.97.132 1.3.6.1.2.1.16.9.1.1.7.2 integer 1
  eventStatus.2 : INTEGER: valid
Poll these tables to verify that the eventTable entries were made on the device.

% snmpwalk -v 1 172.16.97.132 private .1.3.6.1.2.1.16.9.1

# snmpset -c private 172.16.97.132 1.3.6.1.2.1.16.3.1.1.2.1 integer 60
  alarmInterval.1 : INTEGER: 60

# snmpset -c private 172.16.97.132 1.3.6.1.2.1.16.3.1.1.3.1
objectidentifier .1.3.6.1.2.1.2.2.1.12.2
  alarmVariable.1 : OBJECT IDENTIFIER:
.iso.org.dod.internet.mgmt.mib2.interfaces.ifTable
  ifEntry.ifInNUcastPkts.2

# snmpset -c private 172.16.97.132 1.3.6.1.2.1.16.3.1.1.4.1 integer 2

alarmSampleType.1 : INTEGER: deltaValue

# snmpset -c private 172.16.97.132 1.3.6.1.2.1.16.3.1.1.7.1 integer 500
  alarmRisingThreshold.1 : INTEGER: 500

# snmpset -c private 172.16.97.132 1.3.6.1.2.1.16.3.1.1.8.1 integer 0
  alarmFallingThreshold.1 : INTEGER: 0

# snmpset -c private 172.16.97.132 1.3.6.1.2.1.16.3.1.1.9.1 integer 1
  alarmRisingEventIndex.1 : INTEGER: 1

# snmpset -c private 172.16.97.132 1.3.6.1.2.1.16.3.1.1.10.1 integer 2
  alarmFallingEventIndex.1 : INTEGER: 2

# snmpset -c private 172.16.97.132 1.3.6.1.2.1.16.3.1.1.11.1 octetstring
“cisco”
  alarmOwner.1 : OCTET STRING- (ASCII): cisco

# snmpset -c private 172.16.97.132 1.3.6.1.2.1.16.3.1.1.12.1 integer 1
  alarmStatus.1 : INTEGER: valid
Poll these tables to verify that the alarmTable entries were set.

% snmpwalk -v 1 172.16.97.132 private .1.3.6.1.2.1.16.3.1
show interface

This example is a result of the show interface command.

gateway> show interface ethernet 0

Ethernet0 is up, line protocol is up
Hardware is Lance, address is 0000.0c38.1669 (bia 0000.0c38.1669)
Description: NMS workstation LAN
Internet address is 172.16.97.132/24
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255
Encapsulation ARPA, loopback not set, keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of “show interface” counters never
Queueing strategy: fifo
Output queue 0/40, 27 drops; input queue 0/75, 0 drops
5 minute input rate 1000 bits/sec, 2 packets/sec
5 minute output rate 1000 bits/sec, 1 packets/sec
21337627 packets input, 3263376846 bytes, 0 no buffer

Received 7731303 broadcasts
, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
0 input packets with dribble condition detected
17328035 packets output, 2824522759 bytes, 0 underruns
174 output errors, 44368 collisions, 4 interface resets
0 babbles, 0 late collision, 104772 deferred
174 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
Configuration Management

The goal of configuration management is to monitor network and system configuration information so that the effects on network operation of various versions of hardware and software elements can be tracked and managed.

Configuration Standards

With an increasing number of network devices deployed, it is critical to be able to accurately identify the location of a network device. This location information should provide a detailed description meaningful to those tasked with dispatching resources when a network problem occurs. To expedite a resolution if a network problem occurs, make certain to have available contact information of the person or department responsible for the devices. Contact information should include telephone number and the name of the person or department.

Naming conventions for network devices, starting from device name to individual interface, should be planned and implemented as part of the configuration standard. A well defined naming convention provides personnel with the ability to provide accurate information when troubleshooting network problems. The naming convention for devices can use geographical location, building name, floor, and so forth. For the interface naming convention, it can include the segment to which a port is connected, name of connecting hub, and so forth. On serial interfaces, it should include actual bandwidth, local data link connection identifier (DLCI) number (if Frame Relay), destination, and the circuit ID or information provided by the carrier.

Configuration File Management

When you add new configuration commands on existing network devices needs, you must verify the commands for integrity before actual implementation takes place. An improperly configured network device can have a disastrous effect on network connectivity and performance. Configuration command parameters must be checked to avoid mismatches or incompatibility issues. It is advisable to schedule a thorough review of configurations with Cisco engineers on a regular basis.

A fully functional CiscoWorks2000 Essentials allows for backing up configuration files on routers and Cisco Catalyst switches automatically. The security feature of Essentials can be used to perform authentication on configuration changes. A change audit log is available to track changes and the user name of individuals issuing changes. For configuration changes on multiple devices, two options are available: the web-based NetConfig in the current version of CiscoWorks2000 Essentials or the cwconfig script. Configuration files can be downloaded and uploaded using CiscoWorks2000 Essentials utilizing the predefined or user-defined templates.

These functions can be accomplished with the configuration management tools in CiscoWorks2000 Essentials:

Push configuration files from the Essentials configuration archive to a device or multiple devices

Pull the configuration from the device to the Essentials archive

Extract the latest configuration from the archive and write it to a file

Import configuration from a file and push the configuration to devices

Compare the last two configurations in the Essentials archive

Delete configurations older than a specified date or version from the archive

Copy the startup configuration to the running configuration

Inventory Management

The discovery function of most network management platforms is intended to provide a dynamic listing of devices found in the network. Discovery engines such as those implemented in network management platforms should be utilized.

An inventory database provides detailed configuration information on network devices. Common information includes models of hardware, installed modules, software images, microcode levels, and so on. All these pieces of information are crucial in completing tasks such as software and hardware maintenance. The up-to-date listing of network devices collected by the discovery process can be used as a master list to collect inventory information using SNMP or scripting. A device list may be imported from CiscoWorks2000 Campus Manager into the inventory database of CiscoWorks2000 Essentials to obtain an up-to-date inventory of Cisco Catalyst switches.

Software Management

A successful upgrade of Cisco IOS images on network devices requires a detailed analysis of the requirements such as memory, boot ROM, microcode level, and so on. The requirements are normally documented and available on Cisco’s web site in the form of release notes and installation guides. The process of upgrading a network device running Cisco IOS includes downloading a correct image from CCO, backing up the current image, making sure all hardware requirements are met, and then loading the new image into the device.

The upgrade window to complete device maintenance is fairly limited for some organizations. In a large network environment with limited resources, it might be necessary to schedule and automate software upgrades after business hours. The procedure can be completed either using scripting language such as Expect or an application written specifically to perform such a task.

Changes to software in network devices such as Cisco IOS images and microcode versions should be tracked to assist in the analysis phase when another software maintenance is required. With a modification history report readily available, the person performing the upgrade can minimize the risk of loading incompatible images or microcode into network devices.

Performance Management

Service Level Agreement

A service level agreement (SLA) is a written agreement between a service provider and their customers on the expected performance level of network services. The SLA consists of metrics agreed upon between the provider and its customers. The values set for the metrics must be realistic, meaningful, and measurable for both parties.

Various interface statistics can be collected from network devices to measure the performance level. These statistics can be included as metrics in the SLA. Statistics such as input queue drops, output queue drops, and ignored packets are useful for diagnosing performance-related problems.

At the device level, performance metrics can include CPU utilization, buffer allocation (big buffer, medium buffer, misses, hit ratio), and memory allocation. The performance of certain network protocols is directly related to buffer availability in network devices. Measuring device-level performance statistics are critical in optimizing the performance of higher-level protocols.

Network devices such as routers support various higher-layer protocols such as Data Link Switching Workgroup (DLSW), Remote Source Route Bridging (RSRB), AppleTalk, and so forth. Performance statistics of wide-area network (WAN) technologies including Frame Relay, ATM, Integrated Services Digital Network (ISDN), and others can be monitored and collected.

Performance Monitoring, Measurement, and Reporting

Different performance metrics at the interface, device, and protocol levels should be collected on a regular basis using SNMP. The polling engine in a network management system can be utilized for data collection purposes. Most network management systems are capable of collecting, storing, and presenting polled data.

Various solutions are available in the marketplace to address the needs of performance management for enterprise environments. These systems are capable of collecting, storing, and presenting data from network devices and servers. The web-based interface on most products makes the performance data accessible from anywhere in the enterprise. Some of the commonly deployed performance management solutions include:

InfoVista VistaView

SAS IT Service Vision

Trinagy TREND

An evaluation of the above products will determine if they meet the requirements of different users. Some vendors support integration with network management and system management platforms. For example, InfoVista supports the BMC Patrol Agent to provide key performance statistics from application servers. Each product has a different pricing model and capabilities with the base offering. Support for performance management features for Cisco’s devices such as NetFlow, RMON, and Cisco IOS Service Assurance Agent/Response Time Reporter (RTR/SAA CSAA/RTR) is available on some solutions. Concord has recently added support for Cisco’s WAN switches that can be used to collect and view performance data.

The CSAA/RTR Service Assurance Agent (SAA)/Response Time Reporter (RTR) feature in Cisco IOS can be utilized for measuring the response time between IP devices. A source router configured with CSAA configured is capable of measuring the response time to a destination IP device that can be a router or an IP device. The response time can be measured between the source and the destination or for each hop along the path. SNMP traps can be configured to alert management consoles if the response time exceeds the predefined thresholds.

Recent enhancements to Cisco IOS extends the capabilities of CSAA to measure the following:

HyperText Transfer Protocol (HTTP) service performance

Domain name system (DNS) lookup

Transmission control protocol (TCP) connect

HTTP transaction time

Interpacket delay variance (jitter) of Voice over IP (VoIP) traffic

Response time between end points for a specific quality of service (QoS)

IP type of service (ToS) bits

Packet loss using CSAA generated packets

Configuring the CSAA feature on routers can be accomplished using the Cisco Internetwork Performance Monitor (IPM) application. The CSAA/RTR is imbedded in many but not all feature sets of the Cisco IOS software. A release of the Cisco IOS software release that supports CSAA/RTR must be installed on the device that IPM uses to collect performance statistics. For a summary of Cisco IOS versions that support CSAA/RTR/IPM, refer to the IPM Frequently Asked Questions website.

Additional information regarding IPM includes:

      http://www.cisco.com/en/US/docs/net_mgmt/ciscoworks_internetwork_performance_monitor/2.0/user/guide/ipmover.html

      http://www.cisco.com/en/US/docs/ios/redirect/eol.html

3-3: Measurement, and Reporting:
3-4: Performance Analysis & Tuning

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s