/products_configuration_ uide_chapter09186a00800d84c7.html

Content 6.2 Network Management 6.2.8 RMON RMON is a major step forward in Internetwork management. It defines a remote monitoring MIB that supplements MIB-II and provides the network manager with vital information about the network. The remarkable feature of RMON is that while it is simply a specification of a MIB, with no changes in the underlying SNMP protocol, it provides a significant expansion in SNMP functionality. With MIB-II, the network manager can obtain information that is purely local to individual devices. Consider a LAN with a number of devices on it, each with an SNMP agent. An SNMP manager can learn of the amount of traffic into and out of each device, but with MIB-II it cannot easily learn about the traffic on the LAN as a whole. Network management in an internetworked environment typically requires one monitor per subnetwork. The RMON standard originally designated as IETF RFC 1271, now RFC 1757, was designed to provide proactive monitoring and diagnostics for distributed LAN-based networks. Monitoring devices, called agents or probes, on critical network segments allow for user-defined alarms to be created and a wealth of vital statistics to be gathered by analyzing every frame on a segment. The RMON standard divides monitoring functions into nine groups to support Ethernet topologies and adds a tenth group in RFC 1513 for Token Ring-unique parameters. The RMON standard was crafted to be deployed as a distributed computing architecture, where the agents and probes communicate with a central management station, a client, using Simple Network Management Protocol (SNMP). These agents have defined SNMP MIB structures for all nine or ten Ethernet or Token Ring RMON groups, allowing interoperability between vendors of RMON-based diagnostic tools. The RMON groups are defined as:

Statistics group – Maintains utilization and error statistics for the subnetwork or segment being monitored. Examples are bandwidth utilization, broadcast, multicast, CRC alignment, fragments, and so on.
History group – Holds periodic statistical samples from the statistics group and stores them for later retrieval. Examples are utilization, error count, and packet count.
Alarm group – Allows the administrator to set a sampling interval and threshold for any item recorded by the agent. Examples are absolute or relative values and rising or falling thresholds.
Host group – Defines the measurement of various types of traffic to and from hosts attached to the network. Examples are packets sent or received, bytes sent or received, errors, and broadcast and multicast packets.
Host TopN group – Provides a report of TopN hosts based on host group statistics.
Traffic matrix group – Stores errors and utilization statistics for pairs of communicating nodes of the network. Examples are errors, bytes, and packets.
Filter group – A filter engine that generates a packet stream from frames that match the pattern specified by the user.
Packet capture group – Defines how packets that match filter criteria are buffered internally.
Event group – Allows the logging of events, also called generated traps, to the manager, together with time and date. Examples are customized reports based upon the type of alarm.

Interactive Media Activity Matching: RMON Matching Activity When the student has completed this activity, the student will be able to understand how RMON operates and its terms and definitions. Web Links RMON http://www.cisco.com/en/US/tech/tk648/ tk362/tk560/tech_protocol_ home.html

Content 6.2 Network Management 6.2.9 Syslog The Cisco syslog logging utility is based on the UNIX syslog utility. System events are usually logged to the system console unless disabled. The syslog utility is a mechanism for applications, processes, and the operating system of Cisco devices to report activity and error conditions. The syslog protocol is used to allow Cisco devices to issue these unsolicited messages to a network management station. Every syslog message logged is associated with a timestamp, a facility, a severity, and a textual log message. These messages are sometimes the only means of gaining insight into some device misbehaviors. Severity level indicates the critical nature of the error message. There are eight levels of severity, 0-7, with level 0 (zero) being the most critical, and level 7 the least critical. The levels are as follows: 0 Emergencies 1 Alerts 2 Critical 3 Errors 4 Warnings 5 Notifications 6 Informational 7 Debugging The facility and severity level fields are used for processing the messages. Level 0 (zero) to level 7 are facility types provided for custom log message processing. The Cisco IOS defaults to severity level 6.This setting is configurable. In order to have the NMS receive and record system messages from a device, the device must have syslog configured. Below is a review of the command line syntax on how to configure these devices. To enable logging to all supported destinations: Router(config)#logging on To send log messages to a syslog server host, such as CiscoWorks2000: Router(config)#logging hostname | ip address To set logging severity level to level 6, informational: Router(config)#logging trap informational To include timestamp with syslog message: Router(config)#service timestamps log datetime Web Links Syslog http://www.cisco.com/en/US/tech/tk648/ tk362/tk790/tech_protocol_ home.html

Content Summary An understanding of the following key points should have been achieved:

The functions of a workstation and a server
The roles of various equipment in a client/server environment
The development of Networking Operating Systems (NOS)
An overview of the various Windows platforms
An overview of some of the alternatives to Windows operating systems
Reasons for network management
The layers of OSI and network management model
The type and application of network management tools
The role that SNMP and CMIP play in network monitoring
How management software gathers information and records problems
How to gather reports on network performance