📄 rfc2021.txt
字号:
Network Working Group S. WaldbusserRequest for Comments: 2021 INSCategory: Standards Track January 1997 Remote Network Monitoring Management Information Base Version 2 using SMIv2Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing remote network monitoring devices.Table of Contents1 The Network Management Framework ...................... 22 Overview .............................................. 22.1 Remote Network Management Goals ..................... 32.2 Structure of MIB .................................... 53 Control of Remote Network Monitoring Devices .......... 63.1 Resource Sharing Among Multiple Management Sta- tions .............................................. 73.2 Row Addition Among Multiple Management Stations ..... 94 Conventions ........................................... 105 RMON 2 Conventions .................................... 105.1 Usage of the term Application Level ................. 105.2 Protocol Directory and Limited Extensibility ........ 115.3 Errors in packets ................................... 116 Definitions ........................................... 127 Security Considerations ............................... 1228 Appendix - TimeFilter Implementation Notes ........... 1239 Acknowledgments ...................................... 12910 References ........................................... 12911 Author's Address...................................... 130Waldbusser Standards Track [Page 1]RFC 2021 Remote Network Monitoring MIB January 19971. The Network Management Framework The Internet-standard Network Management Framework consists of three components. They are: RFC 1902 [1] which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. RFC 1213, STD 17, [3] which defines MIB-II, the core set of managed objects for the Internet suite of protocols. RFC 1905 [4] which defines the SNMP, the protocol used for network access to managed objects. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Within a given MIB module, objects are defined using the SMI's OBJECT-TYPE macro. At a minimum, each object has a name, a syntax, an access-level, and an implementation-status. The name is an object identifier, an administratively assigned name, which specifies an object type. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the object descriptor, to also refer to the object type. The syntax of an object type defines the abstract data structure corresponding to that object type. The ASN.1 [6] language is used for this purpose. However, RFC 1902 purposely restricts the ASN.1 constructs which may be used. These restrictions are explicitly made for simplicity. The access-level of an object type defines whether it makes "protocol sense" to read and/or write the value of an instance of the object type. (This access-level is independent of any administrative authorization policy.) The implementation-status of an object type indicates whether the object is mandatory, optional, obsolete, or deprecated.2. Overview This document continues the architecture created in the RMON MIB [RFC 1757] by providing a major feature upgrade, primarily by providing RMON analysis up to the application layer.Waldbusser Standards Track [Page 2]RFC 2021 Remote Network Monitoring MIB January 1997 Remote network monitoring devices, often called monitors or probes, are instruments that exist for the purpose of managing a network. Often these remote probes are stand-alone devices and devote significant internal resources for the sole purpose of managing a network. An organization may employ many of these devices, one per network segment, to manage its internet. In addition, these devices may be used for a network management service provider to access a client network, often geographically remote. The objects defined in this document are intended as an interface between an RMON agent and an RMON management application and are not intended for direct manipulation by humans. While some users may tolerate the direct display of some of these objects, few will tolerate the complexity of manually manipulating objects to accomplish row creation. These functions should be handled by the management application.2.1. Remote Network Management Goals o Offline Operation There are sometimes conditions when a management station will not be in constant contact with its remote monitoring devices. This is sometimes by design in an attempt to lower communications costs (especially when communicating over a WAN or dialup link), or by accident as network failures affect the communications between the management station and the probe. For this reason, this MIB allows a probe to be configured to perform diagnostics and to collect statistics continuously, even when communication with the management station may not be possible or efficient. The probe may then attempt to notify the management station when an exceptional condition occurs. Thus, even in circumstances where communication between management station and probe is not continuous, fault, performance, and configuration information may be continuously accumulated and communicated to the management station conveniently and efficiently.Waldbusser Standards Track [Page 3]RFC 2021 Remote Network Monitoring MIB January 1997 o Proactive Monitoring Given the resources available on the monitor, it is potentially helpful for it continuously to run diagnostics and to log network performance. The monitor is always available at the onset of any failure. It can notify the management station of the failure and can store historical statistical information about the failure. This historical information can be played back by the management station in an attempt to perform further diagnosis into the cause of the problem. o Problem Detection and Reporting The monitor can be configured to recognize conditions, most notably error conditions, and continuously to check for them. When one of these conditions occurs, the event may be logged, and management stations may be notified in a number of ways. o Value Added Data Because a remote monitoring device represents a network resource dedicated exclusively to network management functions, and because it is located directly on the monitored portion of the network, the remote network monitoring device has the opportunity to add significant value to the data it collects. For instance, by highlighting those hosts on the network that generate the most traffic or errors, the probe can give the management station precisely the information it needs to solve a class of problems. o Multiple Managers An organization may have multiple management stations for different units of the organization, for different functions (e.g. engineering and operations), and in an attempt to provide disaster recovery. Because environments with multiple management stations are common, the remote network monitoring device has to deal with more than own management station, potentially using its resources concurrently.Waldbusser Standards Track [Page 4]RFC 2021 Remote Network Monitoring MIB January 19972.2. Structure of MIB The objects are arranged into the following groups: - protocol directory - protocol distribution - address mapping - network layer host - network layer matrix - application layer host - application layer matrix - user history - probe configuration These groups are the basic units of conformance. If a remote monitoring device implements a group, then it must implement all objects in that group. For example, a managed agent that implements the network layer matrix group must implement the nlMatrixSDTable and the nlMatrixDSTable. Implementations of this MIB must also implement the system and interfaces group of MIB-II [3]. MIB-II may also mandate the implementation of additional groups. These groups are defined to provide a means of assigning object identifiers, and to provide a method for managed agents to know which objects they must implement. This document also contains enhancements to tables defined in the RMON MIB [RFC 1757]. These enhancements include: 1) Adding the DroppedFrames and LastCreateTime conventions to each table defined in the RMON MIB. 2) Augmenting the RMON filter table with a mechanism that allows filtering based on an offset from the beginning of a particular protocol, even if the protocol headers are variable length.Waldbusser Standards Track [Page 5]RFC 2021 Remote Network Monitoring MIB January 1997 3) Augmenting the RMON filter and capture status bits with additional bits for WAN media and generic media. These bits are defined here as: Bit Definition 6 For WAN media, this bit is set for packets coming from one direction and cleared for packets coming from the other direction. It is an implementation specific matter as to which bit is assigned to which direction, but it must be consistent for all packets received by the agent, and if the agent knows which end of the link is "local" and which end is "network", the bit should be set for packets from the "local" side and should be cleared for packets from the "network" side. 7 For any media, this bit is set for any packet with a physical layer error. This bit may be set in addition to other media-specific bits that denote the same condition. 8 For any media, this bit is set for any packet that is too short for the media. This bit may be set in addition to other media-specific bits that denote the same condition. 9 For any media, this bit is set for any packet that is too long for the media. This bit may be set in addition to other media-specific bits that denote the same condition. These enhancements are implemented by RMON-2 probes that also implement RMON and do not add any requirements to probes that are compliant to just RMON.3. Control of Remote Network Monitoring Devices Due to the complex nature of the available functions in these devices, the functions often need user configuration. In many cases, the function requires parameters to be set up for a data collection operation. The operation can proceed only after these parameters are fully set up. Many functional groups in this MIB have one or more tables in which to set up control parameters, and one or more data tables in which to place the results of the operation. The control tables are typically
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -