summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1158.txt
diff options
context:
space:
mode:
authorThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
committerThomas Voss <mail@thomasvoss.com> 2024-11-27 20:54:24 +0100
commit4bfd864f10b68b71482b35c818559068ef8d5797 (patch)
treee3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc1158.txt
parentea76e11061bda059ae9f9ad130a9895cc85607db (diff)
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc1158.txt')
-rw-r--r--doc/rfc/rfc1158.txt7451
1 files changed, 7451 insertions, 0 deletions
diff --git a/doc/rfc/rfc1158.txt b/doc/rfc/rfc1158.txt
new file mode 100644
index 0000000..cee619b
--- /dev/null
+++ b/doc/rfc/rfc1158.txt
@@ -0,0 +1,7451 @@
+
+
+
+
+
+
+Network Working Group M. Rose, Editor
+Request for Comments: 1158 Performance Systems International
+ May 1990
+
+
+ Management Information Base for Network Management
+ of TCP/IP-based internets:
+ MIB-II
+
+1. Status of this Memo
+
+ This memo defines the second version of the Management Information
+ Base (MIB-II) for use with network management protocols in TCP/IP-
+ based internets. In particular, together with its companion memos
+ which describe the structure of management information (RFC 1155)
+ along with the network management protocol (RFC 1157) for TCP/IP-
+ based internets, these documents provide a simple, workable
+ architecture and system for managing TCP/IP-based internets and in
+ particular the Internet community.
+
+ This document on MIB-II incorporates all of the technical content of
+ RFC 1156 on MIB-I and extends it, without loss of compatibilty.
+ However, MIB-I as described in RFC 1156 is full Standard Protocol of
+ the Internet, while the MIB-II described here is Proposed Standard
+ Protocol of the Internet.
+
+ This memo defines a mandatory extension to the base MIB (RFC 1156)
+ and is a Proposed Standard for the Internet community. The
+ extensions described here are currently Elective, but when they
+ become a standard, they will have the same status as RFC 1156, that
+ is, Recommended. The Internet Activities Board recommends that all
+ IP and TCP implementations be network manageable. This implies
+ implementation of the Internet MIB (RFC 1156 and the extensions in
+ RFC 1158) and at least one of the two recommended management
+ protocols SNMP (RFC 1157) or CMOT (RFC 1095).
+
+ This version of the MIB specification, MIB-II, is an incremental
+ refinement of MIB-I. As such, it has been designed according to two
+ criteria: first, changes have been made in response to new
+ operational requirements in the Internet; and, second, the changes
+ are entirely upwards compatible in order to minimize impact on the
+ network as the managed nodes in the Internet transition from MIB-I to
+ MIB-II.
+
+ It is expected that additional MIB groups and variables will be
+ defined over time to accommodate the monitoring and control needs of
+ new or changing components of the Internet.
+
+
+
+
+IETF SNMP Working Group [Page 1]
+
+RFC 1158 MIB II May 1990
+
+
+ Please refer to the latest edition of the "IAB Official Protocol
+ Standards" RFC for current information on the state and status of
+ standard Internet protocols.
+
+ Distribution of this memo is unlimited.
+
+ Table of Contents
+
+
+ 1. Status of this Memo .................................. 1
+ 2. Introduction ......................................... 3
+ 3. Changes from MIB-I ................................... 4
+ 3.1 Deprecated Objects .................................. 4
+ 3.2 Display Strings ..................................... 5
+ 3.3 The System Group .................................... 5
+ 3.4 The Interfaces Group ................................ 5
+ 3.5 The Address Translation Group ....................... 6
+ 3.6 The IP Group ........................................ 7
+ 3.7 The ICMP Group ...................................... 7
+ 3.8 The TCP Group ....................................... 7
+ 3.9 The UDP Group ....................................... 7
+ 3.10 The EGP Group ...................................... 8
+ 3.11 The Transmission Group ............................. 8
+ 3.12 The SNMP Group ..................................... 8
+ 4. Objects .............................................. 8
+ 4.1 Object Groups ....................................... 9
+ 4.2 Format of Definitions ............................... 10
+ 5. Object Definitions ................................... 10
+ 5.1 The System Group .................................... 11
+ 5.2 The Interfaces Group ................................ 14
+ 5.2.1 The Interfaces table .............................. 15
+ 5.3 The Address Translation Group ....................... 27
+ 5.4 The IP Group ........................................ 30
+ 5.4.1 The IP Address table .............................. 38
+ 5.4.2 The IP Routing table .............................. 41
+ 5.4.3 The IP Address Translation table .................. 48
+ 5.5 The ICMP Group ...................................... 51
+ 5.6 The TCP Group ....................................... 61
+ 5.6.1 The TCP Connection table .......................... 66
+ 5.6.2 Additional TCP Objects ............................ 69
+ 5.7 The UDP Group ....................................... 70
+ 5.7.1 The UDP Listener table ............................ 72
+ 5.8 The EGP Group ....................................... 73
+ 5.8.1 The EGP Neighbor table ............................ 75
+ 5.8.2 Additional EGP variables .......................... 83
+ 5.9 The Transmission Group .............................. 83
+ 5.10 The SNMP Group ..................................... 83
+ 6. Definitions .......................................... 95
+
+
+
+IETF SNMP Working Group [Page 2]
+
+RFC 1158 MIB II May 1990
+
+
+ 7. Identification of OBJECT instances for use with the
+ SNMP ................................................. 126
+ 7.1 ifTable Object Type Names ........................... 127
+ 7.2 atTable Object Type Names ........................... 127
+ 7.3 ipAddrTable Object Type Names ....................... 128
+ 7.4 ipRoutingTable Object Type Names .................... 128
+ 7.5 ipNetToMediaTable Object Type Names ................. 129
+ 7.6 tcpConnTable Object Type Names ...................... 129
+ 7.7 udpTable Object Type Names .......................... 130
+ 7.8 egpNeighTable Object Type Names ..................... 130
+ 8. Acknowledgements .................................... 130
+ 9. References .......................................... 131
+ 10. Security Considerations.............................. 133
+ 11. Author's Address..................................... 133
+
+2. Introduction
+
+ As reported in RFC 1052, IAB Recommendations for the
+ Development of Internet Network Management Standards [1], a
+ two-prong strategy for network management of TCP/IP-based
+ internets was undertaken. In the short-term, the Simple
+ Network Management Protocol (SNMP) was to be used to manage
+ nodes in the Internet community. In the long-term, the use of
+ the OSI network management framework was to be examined. Two
+ documents were produced to define the management information:
+ RFC 1065, which defined the Structure of Management
+ Information (SMI) [2], and RFC 1066, which defined the
+ Management Information Base (MIB) [3]. Both of these
+ documents were designed so as to be compatible with both the
+ SNMP and the OSI network management framework.
+
+ This strategy was quite successful in the short-term:
+ Internet-based network management technology was fielded, by
+ both the research and commercial communities, within a few
+ months. As a result of this, portions of the Internet
+ community became network manageable in a timely fashion.
+
+ As reported in RFC 1109, Report of the Second Ad Hoc Network
+ Management Review Group [4], the requirements of the SNMP and
+ the OSI network management frameworks were more different than
+ anticipated. As such, the requirement for compatibility
+ between the SMI/MIB and both frameworks was suspended. This
+ action permitted the operational network management framework,
+ the SNMP, to respond to new operational needs in the Internet
+ community by producing this document.
+
+ As such, the current network management framework for TCP/IP-
+ based internets consists of: Structure and Identification of
+
+
+
+IETF SNMP Working Group [Page 3]
+
+RFC 1158 MIB II May 1990
+
+
+ Management Information for TCP/IP-based internets, RFC 1155 [13],
+ which describes how managed objects contained in the MIB are
+ defined; Management Information Base for Network Management of
+ TCP/IP-based internets (version 2), this memo, which describes
+ the managed objects contained in the MIB; and, the Simple
+ Network Management Protocol, RFC 1157 [14], which defines the
+ protocol used to manage these objects.
+
+ Consistent with the IAB directive to produce simple, workable
+ systems in the short-term, the list ofc objects (e.g., for BSD UNIX)
+ were excluded.
+
+ 7) It was agreed to avoid heavily instrumenting critical
+ sections of code. The general guideline was one counter
+ per critical section per layer.
+
+3. Changes from MIB-I
+
+ Features of this MIB include:
+
+ 1) incremental additions to reflect new operational
+ requirements;
+
+ 2) upwards compatibility with the SMI/MIB and the SNMP;
+
+ 3) improved support for multi-protocol entities; and,
+
+ 4) textual clean-up of the MIB to improve clarity and
+ readability.
+
+ The objects defined in MIB-II have the OBJECT IDENTIFIER prefix:
+
+ mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }
+
+3.1. Deprecated Objects
+
+ In order to better prepare implementors for future changes in the
+ MIB, a new term "deprecated" may be used when describing an object.
+ A deprecated object in the MIB is one which must be supported, but
+ one which will most likely be removed from the next version of the
+ MIB (e.g., MIB-III).
+
+ MIB-II marks one object as being deprecated:
+
+ atTable
+
+ As a result of deprecating the atTable object, the entire Address
+ Translation group is deprecated.
+
+
+
+IETF SNMP Working Group [Page 4]
+
+RFC 1158 MIB II May 1990
+
+
+ Note that no functionality is lost with the deprecation of these
+ objects: new objects providing equivalent or superior functionality
+ are defined in MIB-II.
+
+3.2. Display Strings
+
+ In the past, there have been misinterpretations of the MIB as to when
+ a string of octets should contain printable characters, meant to be
+ displayed to a human. As a textual convention in the MIB, the
+ datatype
+
+ DisplayString ::= OCTET STRING
+
+ is introduced. A DisplayString is restricted to the NVT ASCII
+ character set, as defined in pages 10-11 of [7].
+
+ The following objects are now defined in terms of DisplayString:
+
+ sysDescr
+ ifDescr
+
+ It should be noted that this change has no effect on either the
+ syntax nor semantics of these objects. The use of the DisplayString
+ notation is merely an artifact of the explanatory method used in
+ MIB-II and future MIBs.
+
+ Further, it should be noted that any object defined in terms of OCTET
+ STRING may contain arbitrary binary data, in which each octet may
+ take any value from 0 to 255 (decimal).
+
+3.3. The System Group
+
+ Four new objects are added to this group:
+
+ sysContact
+ sysName
+ sysLocation
+ sysServices
+
+ These provide contact, administrative, location, and service
+ information regarding the managed node.
+
+3.4. The Interfaces Group
+
+ The definition of the ifNumber object was incorrect, as it required
+ all interfaces to support IP. (For example, devices without IP, such
+ as MAC-layer bridges, could not be managed if this definition was
+ strictly followed.) The description of the ifNumber object is changed
+
+
+
+IETF SNMP Working Group [Page 5]
+
+RFC 1158 MIB II May 1990
+
+
+ accordingly.
+
+ The ifTable object was mistaken marked as read-write, it has been
+ (correctly) re-designated as read-only. In addition, several new
+ values have been added to the ifType column in the ifTable object:
+
+ ppp(23)
+ softwareLoopback(24)
+ eon(25)
+ ethernet-3Mbit(26)
+ nsip(27)
+ slip(28)
+
+ Finally, a new column has been added to the ifTable object:
+
+ ifSpecific
+
+ which provides information about information specific to the media
+ being used to realize the interface.
+
+3.5. The Address Translation Group
+
+ In MIB-I, this group contained a table which permitted mappings from
+ network addresses (e.g., IP addresses) to physical addresses (e.g.,
+ MAC addresses). Experience has shown that efficient implementations
+ of this table make two assumptions: a single network protocol
+ environment, and mappings occur only from network address to physical
+ address.
+
+ The need to support multi-protocol nodes (e.g., those with both the
+ IP and CLNP active), and the need to support the inverse mapping
+ (e.g., for ES-IS), have invalidated both of these assumptions. As
+ such, the atTable object is declared deprecated.
+
+ In order to meet both the multi-protocol and inverse mapping
+ requirements, MIB-II and its successors will allocate up to two
+ address translation tables inside each network protocol group. That
+ is, the IP group will contain one address translation table, for
+ going from IP addresses to physical addresses. Similarly, when a
+ document defining MIB objects for the CLNP is produced (e.g., [8]),
+ it will contain two tables, for mappings in both directions, as this
+ is required for full functionality.
+
+ It should be noted that the choice of two tables (one for each
+ direction of mapping) provides for ease of implementation in many
+ cases, and does not introduce undue burden on implementations which
+ realize the address translation abstraction through a single internal
+ table.
+
+
+
+IETF SNMP Working Group [Page 6]
+
+RFC 1158 MIB II May 1990
+
+
+3.6. The IP Group
+
+ The access attribute of the variable ipForwarding has been changed
+ from read-only to read-write.
+
+ In addition, there is a new column to the ipAddrTable object,
+
+ ipAdEntReasmMaxSize
+
+ which keeps track of the largest IP datagram that can be re-
+ assembled on a particular interface. There is also a new column in
+ the ipRoutingTable object,
+
+ ipRouteMask
+
+ which is used for IP routing subsystems that support arbitrary subnet
+ masks.
+
+ One new object is added to the IP group:
+
+ ipNetToMediaTable
+
+ which is the address translation table for the IP group (providing
+ identical functionality to the now deprecated atTable in the address
+ translation group).
+
+3.7. The ICMP Group
+
+ There are no changes to this group.
+
+3.8. The TCP Group
+
+ Two new variables are added:
+
+ tcpInErrs
+ tcpOutRsts
+
+ which keep track of the number of incoming TCP segments in error and
+ the number of resets generated by a TCP.
+
+3.9. The UDP Group
+
+ A new table:
+
+ udpTable
+
+ is added.
+
+
+
+
+IETF SNMP Working Group [Page 7]
+
+RFC 1158 MIB II May 1990
+
+
+3.10. The EGP Group
+
+ Experience has indicated a need for additional objects that are
+ useful in EGP monitoring. In addition to making several additions to
+ the egpNeighborTable object, a new variable is added:
+
+ egpAs
+
+ which gives the autonomous system associated with this EGP entity.
+
+3.11. The Transmission Group
+
+ MIB-I was lacking in that it did not distinguish between different
+ types of transmission media. A new group, the Transmission group, is
+ allocated for this purpose:
+
+ transmission OBJECT IDENTIFIER ::= { mib-2 10 }
+
+ When Internet-standard definitions for managing transmission media
+ are defined, the transmission group is used to provide a prefix for
+ the names of those objects.
+
+ Typically, such definitions reside in the experimental portion of the
+ MIB until they are "proven", then as a part of the Internet
+ standardization process, the definitions are accordingly elevated and
+ a new object identifier, under the transmission group is defined. By
+ convention, the name assigned is:
+
+ type OBJECT IDENTIFIER ::= { transmission number }
+
+ where "type" is the symbolic value used for the media in the ifType
+ column of the ifTable object, and "number" is the actual integer
+ value corresponding to the symbol.
+
+3.12. The SNMP Group
+
+ The application-oriented working groups of the IETF have been tasked
+ to be receptive towards defining MIB variables specific to their
+ respective applications.
+
+ For the SNMP, it is useful to have statistical information. A new
+ group, the SNMP group, is allocated for this purpose:
+
+ snmp OBJECT IDENTIFIER ::= { mib-2 11 }
+
+4. Objects
+
+ Managed objects are accessed via a virtual information store, termed
+
+
+
+IETF SNMP Working Group [Page 8]
+
+RFC 1158 MIB II May 1990
+
+
+ the Management Information Base or MIB. Objects in the MIB are
+ defined using Abstract Syntax Notation One (ASN.1) [9].
+
+ The mechanisms used for describing these objects are specified the
+ companion memo, the SMI. In particular, each object has a name, a
+ syntax, and an encoding. 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 language is used for
+ this purpose. However, the companion memo purposely restricts the
+ ASN.1 constructs which may be used. These restrictions are
+ explicitly made for simplicity.
+
+ The encoding of an object type is simply how that object type is
+ represented using the object type's syntax. Implicitly tied to the
+ notion of an object type's syntax and encoding is how the object type
+ is represented when being transmitted on the network. This memo
+ specifies the use of the basic encoding rules (BER) of ASN.1 [10],
+ subject to the additional requirements imposed by the SNMP [14].
+
+4.1. Object Groups
+
+ Since this list of managed objects contains only the essential
+ elements, there is no need to allow individual objects to be
+ optional. Rather, the objects are arranged into the following
+ groups:
+
+ - System
+ - Interfaces
+ - Address Translation (deprecated)
+ - IP
+ - ICMP
+ - TCP
+ - UDP
+ - EGP
+ - Transmission
+ - SNMP
+
+ There are two reasons for defining these groups: to provide a means
+ of assigning object identifiers; and, to provide a method for
+ implementations of managed agents to know which objects they must
+ implement. This method is as follows: if the semantics of a group is
+ applicable to an implementation, then it must implement all objects
+
+
+
+IETF SNMP Working Group [Page 9]
+
+RFC 1158 MIB II May 1990
+
+
+ in that group. For example, an implementation must implement the EGP
+ group if and only if it implements the EGP.
+
+4.2. Format of Definitions
+
+ The next section contains the specification of all object types
+ contained in the MIB. Following the conventions of the companion
+ memo, the object types are defined using the following fields:
+
+ OBJECT:
+ -------
+ A textual name, termed the OBJECT DESCRIPTOR, for the
+ object type, along with its corresponding OBJECT
+ IDENTIFIER.
+
+ Syntax:
+ The abstract syntax for the object type, presented using
+ ASN.1. This must resolve to an instance of the ASN.1
+ type ObjectSyntax defined in the SMI.
+
+ Definition:
+ A textual description of the semantics of the object
+ type. Implementations should ensure that their
+ interpretation of the object type fulfills this
+ definition since this MIB is intended for use in multi-
+ vendor environments. As such it is vital that object
+ types have consistent meaning across all machines.
+
+ Access:
+ A keyword, one of read-only, read-write, write-only, or
+ not-accessible. Note that this designation specifies the
+ minimum level of support required. As a local matter,
+ implementations may support other access types (e.g., an
+ implementation may elect to permitting writing a variable
+ marked herein as read-only). Further, protocol-specific
+ "views" (e.g., those implied by an SNMP community) may
+ make further restrictions on access to a variable.
+
+ Status:
+ A keyword, one of mandatory, optional, obsolete, or
+ deprecated. Use of deprecated implies mandatory status.
+
+5. Object Definitions
+
+ RFC1158-MIB
+
+ DEFINITIONS ::= BEGIN
+
+
+
+
+IETF SNMP Working Group [Page 10]
+
+RFC 1158 MIB II May 1990
+
+
+ IMPORTS
+ mgmt, OBJECT-TYPE, NetworkAddress, IpAddress,
+ Counter, Gauge, TimeTicks
+ FROM RFC1155-SMI;
+
+ DisplayString ::=
+ OCTET STRING
+
+
+ mib-2 OBJECT IDENTIFIER ::= { mgmt 1 } -- MIB-II
+
+ system OBJECT IDENTIFIER ::= { mib-2 1 }
+ interfaces OBJECT IDENTIFIER ::= { mib-2 2 }
+ at OBJECT IDENTIFIER ::= { mib-2 3 }
+ ip OBJECT IDENTIFIER ::= { mib-2 4 }
+ icmp OBJECT IDENTIFIER ::= { mib-2 5 }
+ tcp OBJECT IDENTIFIER ::= { mib-2 6 }
+ udp OBJECT IDENTIFIER ::= { mib-2 7 }
+ egp OBJECT IDENTIFIER ::= { mib-2 8 }
+ -- cmot OBJECT IDENTIFIER ::= { mib-2 9 }
+ transmission OBJECT IDENTIFIER ::= { mib-2 10 }
+ snmp OBJECT IDENTIFIER ::= { mib-2 11 }
+ END
+
+5.1. The System Group
+
+ Implementation of the System group is mandatory for all systems.
+
+
+ OBJECT:
+ -------
+ sysDescr { system 1 }
+
+ Syntax:
+ DisplayString (SIZE (0..255))
+
+ Definition:
+ A textual description of the entity. This value should
+ include the full name and version identification of the
+ system's hardware type, software operating-system, and
+ networking software. It is mandatory that this only
+ contain printable ASCII characters.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+
+IETF SNMP Working Group [Page 11]
+
+RFC 1158 MIB II May 1990
+
+
+ OBJECT:
+ -------
+ sysObjectID { system 2 }
+
+ Syntax:
+ OBJECT IDENTIFIER
+
+ Definition:
+ The vendor's authoritative identification of the network
+ management subsystem contained in the entity. This value
+ is allocated within the SMI enterprises subtree
+ (1.3.6.1.4.1) and provides an easy and unambiguous means
+ for determining "what kind of box" is being managed. For
+ example, if vendor "Flintstones, Inc." was assigned the
+ subtree 1.3.6.1.4.1.4242, it could assign the identifier
+ 1.3.6.1.4.1.4242.1.1 to its "Fred Router".
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ sysUpTime { system 3 }
+
+ Syntax:
+ TimeTicks
+
+ Definition:
+ The time (in hundredths of a second) since the network
+ management portion of the system was last re-initialized.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ sysContact { system 4 }
+
+ Syntax:
+ DisplayString (SIZE (0..255))
+
+
+
+IETF SNMP Working Group [Page 12]
+
+RFC 1158 MIB II May 1990
+
+
+ Definition:
+ The textual identification of the contact person for this
+ managed node, together with information on how to contact
+ this person.
+
+ Access:
+ read-write.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ sysName { system 5 }
+
+ Syntax:
+ DisplayString (SIZE (0..255))
+
+ Definition:
+ An administratively-assigned name for this managed node.
+ By convention, this is the node's fully-qualified domain
+ name.
+
+ Access:
+ read-write.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ sysLocation { system 6 }
+
+ Syntax:
+ DisplayString (SIZE (0..255))
+
+ Definition:
+ The physical location of this node (e.g., "telephone
+ closet, 3rd floor").
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+
+
+IETF SNMP Working Group [Page 13]
+
+RFC 1158 MIB II May 1990
+
+
+ OBJECT:
+ -------
+ sysServices { system 7 }
+
+ Syntax:
+ INTEGER (0..127)
+
+ Definition:
+ A value which indicates the set of services that this
+ entity potentially offers. The value is a sum. This
+ sum initially takes the value zero, Then, for each layer,
+ L, in the range 1 through 7, that this node performs
+ transactions for, 2 raised to (L - 1) is added to the
+ sum. For example, a node which performs only routing
+ functions would have a value of 4 (2^(3-1)). In
+ contrast, a node which is a host offering application
+ services would have a value of 72 (2^(4-1) + 2^(7-1)).
+ Note that in the context of the Internet suite of
+ protocols, values should be calculated accordingly:
+
+ layer functionality
+ 1 physical (e.g., repeaters)
+ 2 datalink/subnetwork (e.g., bridges)
+ 3 internet (e.g., supports the IP)
+ 4 end-to-end (e.g., supports the TCP)
+ 7 applications (e.g., supports the SMTP)
+
+ For systems including OSI protocols, layers 5 and 6 may
+ also be counted.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+5.2. The Interfaces Group
+
+ Implementation of the Interfaces group is mandatory for all systems.
+
+
+ OBJECT:
+ -------
+ ifNumber { interfaces 1 }
+
+ Syntax:
+ INTEGER
+
+
+
+
+IETF SNMP Working Group [Page 14]
+
+RFC 1158 MIB II May 1990
+
+
+ Definition:
+ The number of network interfaces (regardless of their
+ current state) present on this system.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+5.2.1. The Interfaces table
+
+ The Interfaces table contains information on the entity's interfaces.
+ Each interface is thought of as being attached to a "subnetwork".
+ Note that this term should not be confused with "subnet" which refers
+ to an addressing partitioning scheme used in the Internet suite of
+ protocols.
+
+
+ OBJECT:
+ -------
+ ifTable { interfaces 2 }
+
+ Syntax:
+ SEQUENCE OF IfEntry
+
+ Definition:
+ A list of interface entries. The number of entries is
+ given by the value of ifNumber.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ifEntry { ifTable 1 }
+
+
+
+
+
+
+
+
+
+
+
+IETF SNMP Working Group [Page 15]
+
+RFC 1158 MIB II May 1990
+
+
+ Syntax:
+ IfEntry ::= SEQUENCE {
+ ifIndex
+ INTEGER,
+ ifDescr
+ DisplayString,
+ ifType
+ INTEGER,
+ ifMtu
+ INTEGER,
+ ifSpeed
+ Gauge,
+ ifPhysAddress
+ OCTET STRING,
+ ifAdminStatus
+ INTEGER,
+ ifOperStatus
+ INTEGER,
+ ifLastChange
+ TimeTicks,
+ ifInOctets
+ Counter,
+ ifInUcastPkts
+ Counter,
+ ifInNUcastPkts
+ Counter,
+ ifInDiscards
+ Counter,
+ ifInErrors
+ Counter,
+ ifInUnknownProtos
+ Counter,
+ ifOutOctets
+ Counter,
+ ifOutUcastPkts
+ Counter,
+ ifOutNUcastPkts
+ Counter,
+ ifOutDiscards
+ Counter,
+ ifOutErrors
+ Counter,
+ ifOutQLen
+ Gauge,
+ ifSpecific
+ OBJECT IDENTIFIER
+ }
+
+
+
+
+IETF SNMP Working Group [Page 16]
+
+RFC 1158 MIB II May 1990
+
+
+ Definition:
+ An interface entry containing objects at the subnetwork
+ layer and below for a particular interface.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ We now consider the individual components of each interface
+ entry:
+
+
+ OBJECT:
+ -------
+ ifIndex { ifEntry 1 }
+
+ Syntax:
+ INTEGER
+
+ Definition:
+ A unique value for each interface. Its value ranges
+ between 1 and the value of ifNumber. The value for each
+ interface must remain constant at least from one re-
+ initialization of the entity's network management system
+ to the next re-initialization.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ifDescr { ifEntry 2 }
+
+ Syntax:
+ DisplayString (SIZE (0..255))
+
+ Definition:
+ A textual string containing information about the
+ interface. This string should include the name of the
+ manufacturer, the product name and the version of the
+ hardware interface.
+
+
+
+IETF SNMP Working Group [Page 17]
+
+RFC 1158 MIB II May 1990
+
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ifType { ifEntry 3 }
+
+ Syntax:
+ INTEGER {
+ other(1), -- none of the following
+ regular1822(2),
+ hdh1822(3),
+ ddn-x25(4),
+ rfc877-x25(5),
+ ethernet-csmacd(6),
+ iso88023-csmacd(7),
+ iso88024-tokenBus(8),
+ iso88025-tokenRing(9),
+ iso88026-man(10),
+ starLan(11),
+ proteon-10Mbit(12),
+ proteon-80Mbit(13),
+ hyperchannel(14),
+ fddi(15),
+ lapb(16),
+ sdlc(17),
+ t1-carrier(18),
+ cept(19), -- european equivalent of T-1
+ basicISDN(20),
+ primaryISDN(21),
+ -- proprietary serial
+ propPointToPointSerial(22),
+ ppp(23),
+ softwareLoopback(24),
+ eon(25), -- CLNP over IP [12]
+ ethernet-3Mbit(26)
+ nsip(27), -- XNS over IP
+ slip(28) -- generic SLIP
+ }
+
+ Definition:
+ The type of interface, distinguished according to the
+ physical/link protocol(s) immediately "below" the network
+ layer in the protocol stack.
+
+
+
+IETF SNMP Working Group [Page 18]
+
+RFC 1158 MIB II May 1990
+
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ifMtu { ifEntry 4 }
+
+ Syntax:
+ INTEGER
+
+ Definition:
+ The size of the largest datagram which can be
+ sent/received on the interface, specified in octets. For
+ interfaces that are used for transmitting network
+ datagrams, this is the size of the largest network
+ datagram that can be sent on the interface.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ifSpeed { ifEntry 5 }
+
+ Syntax:
+ Gauge
+
+ Definition:
+ An estimate of the interface's current bandwidth in bits
+ per second. For interfaces which do not vary in
+ bandwidth or for those where no accurate estimation can
+ be made, this object should contain the nominal
+ bandwidth.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+
+
+IETF SNMP Working Group [Page 19]
+
+RFC 1158 MIB II May 1990
+
+
+ OBJECT:
+ -------
+ ifPhysAddress { ifEntry 6 }
+
+ Syntax:
+ OCTET STRING
+
+ Definition:
+ The interface's address at the protocol layer immediately
+ "below" the network layer in the protocol stack. For
+ interfaces which do not have such an address (e.g., a
+ serial line), this object should contain an octet string
+ of zero length.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ifAdminStatus { ifEntry 7 }
+
+ Syntax:
+ INTEGER {
+ up(1), -- ready to pass packets
+ down(2),
+ testing(3) -- in some test mode
+ }
+
+ Definition:
+ The desired state of the interface. The testing(3) state
+ indicates that no operational packets can be passed.
+
+ Access:
+ read-write.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ifOperStatus { ifEntry 8 }
+
+
+
+
+
+IETF SNMP Working Group [Page 20]
+
+RFC 1158 MIB II May 1990
+
+
+ Syntax:
+ INTEGER {
+ up(1), -- ready to pass packets
+ down(2),
+ testing(3) -- in some test mode
+ }
+
+ Definition:
+ The current operational state of the interface. The
+ testing(3) state indicates that no operational packets
+ can be passed.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ifLastChange { ifEntry 9 }
+
+ Syntax:
+ TimeTicks
+
+ Definition:
+ The value of sysUpTime at the time the interface entered
+ its current operational state. If the current state was
+ entered prior to the last re-initialization of the local
+ network management subsystem, then this object contains a
+ zero value.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ifInOctets { ifEntry 10 }
+
+ Syntax:
+ Counter
+
+
+
+
+
+IETF SNMP Working Group [Page 21]
+
+RFC 1158 MIB II May 1990
+
+
+ Definition:
+ The total number of octets received on the interface,
+ including framing characters.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ifInUcastPkts { ifEntry 11 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of subnetwork-unicast packets delivered to a
+ higher-layer protocol.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ifInNUcastPkts { ifEntry 12 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of non-unicast (i.e., subnetwork-broadcast or
+ subnetwork-multicast) packets delivered to a higher-layer
+ protocol.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+
+
+
+IETF SNMP Working Group [Page 22]
+
+RFC 1158 MIB II May 1990
+
+
+ OBJECT:
+ -------
+ ifInDiscards { ifEntry 13 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of inbound packets which were chosen to be
+ discarded even though no errors had been detected to
+ prevent their being deliverable to a higher-layer
+ protocol. One possible reason for discarding such a
+ packet could be to free up buffer space.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ifInErrors { ifEntry 14 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of inbound packets that contained errors
+ preventing them from being deliverable to a higher-layer
+ protocol.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ifInUnknownProtos { ifEntry 15 }
+
+ Syntax:
+ Counter
+
+
+
+
+
+IETF SNMP Working Group [Page 23]
+
+RFC 1158 MIB II May 1990
+
+
+ Definition:
+ The number of packets received via the interface which
+ were discarded because of an unknown or unsupported
+ protocol.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ifOutOctets { ifEntry 16 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number of octets transmitted out of the
+ interface, including framing characters.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ifOutUcastPkts { ifEntry 17 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number of packets that higher-level protocols
+ requested be transmitted to a subnetwork-unicast address,
+ including those that were discarded or not sent.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+
+
+IETF SNMP Working Group [Page 24]
+
+RFC 1158 MIB II May 1990
+
+
+ OBJECT:
+ -------
+ ifOutNUcastPkts { ifEntry 18 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number of packets that higher-level protocols
+ requested be transmitted to a non-unicast (i.e., a
+ subnetwork-broadcast or subnetwork-multicast) address,
+ including those that were discarded or not sent.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ifOutDiscards { ifEntry 19 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of outbound packets which were chosen to be
+ discarded even though no errors had been detected to
+ prevent their being transmitted. One possible reason for
+ discarding such a packet could be to free up buffer
+ space.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ifOutErrors { ifEntry 20 }
+
+ Syntax:
+ Counter
+
+
+
+
+IETF SNMP Working Group [Page 25]
+
+RFC 1158 MIB II May 1990
+
+
+ Definition:
+ The number of outbound packets that could not be
+ transmitted because of errors.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ifOutQLen { ifEntry 21 }
+
+ Syntax:
+ Gauge
+
+ Definition:
+ The length of the output packet queue (in packets).
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ifSpecific { ifEntry 22 }
+
+ Syntax:
+ OBJECT IDENTIFIER
+
+ Definition:
+ A reference to MIB definitions specific to the particular
+ media being used to realize the interface. For example,
+ if the interface is realized by an ethernet, then the
+ value of this object refers to a document defining
+ objects specific to ethernet. If an agent is not
+ configured to have a value for any of these variables,
+ the object identifier
+
+ nullSpecific OBJECT IDENTIFIER ::= { 0 0 }
+
+ is returned. Note that "nullSpecific" is a syntatically
+ valid object identifier, and any conformant
+
+
+
+IETF SNMP Working Group [Page 26]
+
+RFC 1158 MIB II May 1990
+
+
+ implementation of ASN.1 and BER must be able to generate
+ and recognize this value.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+5.3. The Address Translation Group
+
+ Implementation of the Address Translation group is mandatory for all
+ systems. Note however that this group is deprecated by MIB-II. That
+ is, it is being included solely for compatibility with MIB-I nodes,
+ and will most likely be excluded from MIB-III nodes. From MIB-II and
+ onwards, each network protocol group contains its own address
+ translation tables.
+
+ The Address Translation group contains one table which is the union
+ across all interfaces of the translation tables for converting a
+ NetworkAddress (e.g., an IP address) into a subnetwork-specific
+ address. For lack of a better term, this document refers to such a
+ subnetwork-specific address as a "physical" address.
+
+ Examples of such translation tables are: for broadcast media where
+ ARP is in use, the translation table is equivalent to the ARP cache;
+ or, on an X.25 network where non-algorithmic translation to X.121
+ addresses is required, the translation table contains the
+ NetworkAddress to X.121 address equivalences.
+
+
+ OBJECT:
+ -------
+ atTable { at 1 }
+
+ Syntax:
+ SEQUENCE OF AtEntry
+
+ Definition:
+ The Address Translation tables contain the NetworkAddress
+ to "physical" address equivalences. Some interfaces do
+ not use translation tables for determining address
+ equivalences (e.g., DDN-X.25 has an algorithmic method);
+ if all interfaces are of this type, then the Address
+ Translation table is empty, i.e., has zero entries.
+
+ Access:
+ read-write.
+
+
+
+IETF SNMP Working Group [Page 27]
+
+RFC 1158 MIB II May 1990
+
+
+ Status:
+ deprecated.
+
+
+ OBJECT:
+ -------
+ atEntry { atTable 1 }
+
+ Syntax:
+ AtEntry ::= SEQUENCE {
+ atIfIndex
+ INTEGER,
+ atPhysAddress
+ OCTET STRING,
+ atNetAddress
+ NetworkAddress
+ }
+
+ Definition:
+ Each entry contains one NetworkAddress to "physical"
+ address equivalence.
+
+ Access:
+ read-write.
+
+ Status:
+ deprecated.
+
+ We now consider the individual components of each Address
+ Translation table entry:
+
+
+ OBJECT:
+ -------
+ atIfIndex { atEntry 1 }
+
+ Syntax:
+ INTEGER
+
+ Definition:
+ The interface on which this entry's equivalence is
+ effective. The interface identified by a particular
+ value of this index is the same interface as identified
+ by the same value of ifIndex.
+
+ Access:
+ read-write.
+
+
+
+
+IETF SNMP Working Group [Page 28]
+
+RFC 1158 MIB II May 1990
+
+
+ Status:
+ deprecated.
+
+
+ OBJECT:
+ -------
+ atPhysAddress { atEntry 2 }
+
+ Syntax:
+ OCTET STRING
+
+ Definition:
+ The media-dependent "physical" address.
+
+ Setting this object to a null string (one of zero length) has
+ the effect of invaliding the corresponding entry in the
+ atTable object. That is, it effectively disassociates the
+ interface identified with said entry from the mapping
+ identified with said entry. It is an implementation-specific
+ matter as to whether the agent removes an invalidated entry
+ from the table. Accordingly, management stations must be
+ prepared to receive tabular information from agents that
+ corresponds to entries not currently in use. Proper
+ interpretation of such entries requires examination of the
+ relevant atPhysAddress object.
+
+ Access:
+ read-write.
+
+ Status:
+ deprecated.
+
+
+ OBJECT:
+ -------
+ atNetAddress { atEntry 3 }
+
+ Syntax:
+ NetworkAddress
+
+ Definition:
+ The NetworkAddress (e.g., the IP address) corresponding
+ to the media-dependent "physical" address.
+
+ Access:
+ read-write.
+
+
+
+
+
+IETF SNMP Working Group [Page 29]
+
+RFC 1158 MIB II May 1990
+
+
+ Status:
+ deprecated.
+
+5.4. The IP Group
+
+ Implementation of the IP group is mandatory for all systems.
+
+
+
+ OBJECT:
+ -------
+ ipForwarding { ip 1 }
+
+ Syntax:
+ INTEGER {
+ forwarding(1), -- i.e., acting as a gateway
+ not-forwarding(2) -- i.e., NOT acting as a gateway
+ }
+
+ Definition:
+ The indication of whether this entity is acting as an IP
+ gateway in respect to the forwarding of datagrams
+ received by, but not addressed to, this entity. IP
+ gateways forward datagrams. IP hosts do not (except
+ those source-routed via the host).
+
+ Access:
+ read-write.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ipDefaultTTL { ip 2 }
+
+ Syntax:
+ INTEGER
+
+ Definition:
+ The default value inserted into the Time-To-Live field of
+ the IP header of datagrams originated at this entity,
+ whenever a TTL value is not supplied by the transport
+ layer protocol.
+
+ Access:
+ read-write.
+
+
+
+IETF SNMP Working Group [Page 30]
+
+RFC 1158 MIB II May 1990
+
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ipInReceives { ip 3 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number of input datagrams received from
+ interfaces, including those received in error.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ipInHdrErrors { ip 4 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of input datagrams discarded due to errors in
+ their IP headers, including bad checksums, version number
+ mismatch, other format errors, time-to-live exceeded,
+ errors discovered in processing their IP options, etc.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ipInAddrErrors { ip 5 }
+
+ Syntax:
+ Counter
+
+
+
+IETF SNMP Working Group [Page 31]
+
+RFC 1158 MIB II May 1990
+
+
+ Definition:
+ The number of input datagrams discarded because the IP
+ address in their IP header's destination field was not a
+ valid address to be received at this entity. This count
+ includes invalid addresses (e.g., 0.0.0.0) and addresses
+ of unsupported Classes (e.g., Class E). For entities
+ which are not IP Gateways and therefore do not forward
+ datagrams, this counter includes datagrams discarded
+ because the destination address was not a local address.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ipForwDatagrams { ip 6 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of input datagrams for which this entity was
+ not their final IP destination, as a result of which an
+ attempt was made to find a route to forward them to that
+ final destination. In entities which do not act as IP
+ Gateways, this counter will include only those packets
+ which were Source-Routed via this entity, and the
+ Source-Route option processing was successful.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ipInUnknownProtos { ip 7 }
+
+ Syntax:
+ Counter
+
+
+
+
+
+IETF SNMP Working Group [Page 32]
+
+RFC 1158 MIB II May 1990
+
+
+ Definition:
+ The number of locally-addressed datagrams received
+ successfully but discarded because of an unknown or
+ unsupported protocol.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ipInDiscards { ip 8 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of input IP datagrams for which no problems
+ were encountered to prevent their continued processing,
+ but which were discarded (e.g., for lack of buffer
+ space). Note that this counter does not include any
+ datagrams discarded while awaiting re-assembly.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ipInDelivers { ip 9 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number of input datagrams successfully
+ delivered to IP user-protocols (including ICMP).
+
+ Access:
+ read-only.
+
+
+
+
+
+IETF SNMP Working Group [Page 33]
+
+RFC 1158 MIB II May 1990
+
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ipOutRequests { ip 10 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number of IP datagrams which local IP user-
+ protocols (including ICMP) supplied to IP in requests for
+ transmission. Note that this counter does not include
+ any datagrams counted in ipForwDatagrams.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ ipOutDiscards { ip 11 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of output IP datagrams for which no problem
+ was encountered to prevent their transmission to their
+ destination, but which were discarded (e.g., for lack of
+ buffer space). Note that this counter would include
+ datagrams counted in ipForwDatagrams if any such packets
+ met this (discretionary) discard criterion.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ipOutNoRoutes { ip 12 }
+
+
+
+IETF SNMP Working Group [Page 34]
+
+RFC 1158 MIB II May 1990
+
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of IP datagrams discarded because no route
+ could be found to transmit them to their destination.
+ Note that this counter includes any packets counted in
+ ipForwDatagrams which meet this "no-route" criterion.
+ Note that this includes any datagarms which a host cannot
+ route because all of its default gateways are down.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ipReasmTimeout { ip 13 }
+
+ Syntax:
+ INTEGER
+
+ Definition:
+ The maximum number of seconds which received fragments
+ are held while they are awaiting reassembly at this
+ entity.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ipReasmReqds { ip 14 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of IP fragments received which needed to be
+ reassembled at this entity.
+
+
+
+
+IETF SNMP Working Group [Page 35]
+
+RFC 1158 MIB II May 1990
+
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ipReasmOKs { ip 15 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of IP datagrams successfully re-assembled.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ipReasmFails { ip 16 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of failures detected by the IP re-assembly
+ algorithm (for whatever reason: timed out, errors, etc).
+ Note that this is not necessarily a count of discarded IP
+ fragments since some algorithms (notably the algorithm in
+ RFC 815) can lose track of the number of fragments by
+ combining them as they are received.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+
+
+
+
+
+IETF SNMP Working Group [Page 36]
+
+RFC 1158 MIB II May 1990
+
+
+ OBJECT:
+ -------
+ ipFragOKs { ip 17 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of IP datagrams that have been successfully
+ fragmented at this entity.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ipFragFails { ip 18 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of IP datagrams that have been discarded
+ because they needed to be fragmented at this entity but
+ could not be, e.g., because their "Don't Fragment" flag
+ was set.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ipFragCreates { ip 19 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of IP datagram fragments that have been
+ generated as a result of fragmentation at this entity.
+
+
+
+IETF SNMP Working Group [Page 37]
+
+RFC 1158 MIB II May 1990
+
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+5.4.1. The IP Address table
+
+ The Ip Address table contains this entity's IP addressing
+ information.
+
+
+
+ OBJECT:
+ -------
+ ipAddrTable { ip 20 }
+
+ Syntax:
+ SEQUENCE OF IpAddrEntry
+
+ Definition:
+ The table of addressing information relevant to this
+ entity's IP addresses.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ipAddrEntry { ipAddrTable 1 }
+
+ Syntax:
+ IpAddrEntry ::= SEQUENCE {
+ ipAdEntAddr
+ IpAddress,
+ ipAdEntIfIndex
+ INTEGER,
+ ipAdEntNetMask
+ IpAddress,
+ ipAdEntBcastAddr
+ INTEGER,
+ ipAdEntReasmMaxSize
+ INTEGER (0..65535)
+ }
+
+
+
+IETF SNMP Working Group [Page 38]
+
+RFC 1158 MIB II May 1990
+
+
+ Definition:
+ The addressing information for one of this entity's IP
+ addresses.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ipAdEntAddr { ipAddrEntry 1 }
+
+ Syntax:
+ IpAddress
+
+ Definition:
+ The IP address to which this entry's addressing
+ information pertains.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ipAdEntIfIndex { ipAddrEntry 2 }
+
+ Syntax:
+ INTEGER
+
+ Definition:
+ The index value which uniquely identifies the interface
+ to which this entry is applicable. The interface
+ identified by a particular value of this index is the
+ same interface as identified by the same value of
+ ifIndex.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+
+IETF SNMP Working Group [Page 39]
+
+RFC 1158 MIB II May 1990
+
+
+ OBJECT:
+ -------
+ ipAdEntNetMask { ipAddrEntry 3 }
+
+ Syntax:
+ IpAddress
+
+ Definition:
+ The subnet mask associated with the IP address of this
+ entry. The value of the mask is an IP address with all
+ the network bits set to 1 and all the hosts bits set to
+ 0.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ipAdEntBcastAddr { ipAddrEntry 4 }
+
+ Syntax:
+ INTEGER
+
+ Definition:
+ The value of the least-significant bit in the IP
+ broadcast address used for sending datagrams on the
+ (logical) interface associated with the IP address of
+ this entry. For example, when the Internet standard
+ all-ones broadcast address is used, the value will be 1.
+ This value applies to both the subnet and network
+ broadcasts addresses used by the entity on this (logical)
+ interface.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ipAdEntReasmMaxSize { ipAddrEntry 5 }
+
+
+
+
+IETF SNMP Working Group [Page 40]
+
+RFC 1158 MIB II May 1990
+
+
+ Syntax:
+ INTEGER (0..65535)
+
+ Definition:
+ The size of the largest IP datagram which this entity can
+ re-assemble from incoming IP fragmented datagrams
+ received on this interface.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+5.4.2. The IP Routing table
+
+ The IP Routing table contains an entry for each route presently known
+ to this entity.
+
+
+ OBJECT:
+ -------
+ ipRoutingTable { ip 21 }
+
+ Syntax:
+ SEQUENCE OF IpRouteEntry
+
+ Definition:
+ This entity's IP Routing table.
+
+ Access:
+ read-write.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ipRouteEntry { ipRoutingTable 1 }
+
+ Syntax:
+ IpRouteEntry ::= SEQUENCE {
+ ipRouteDest
+ IpAddress,
+ ipRouteIfIndex
+ INTEGER,
+ ipRouteMetric1
+
+
+
+IETF SNMP Working Group [Page 41]
+
+RFC 1158 MIB II May 1990
+
+
+ INTEGER,
+ ipRouteMetric2
+ INTEGER,
+ ipRouteMetric3
+ INTEGER,
+ ipRouteMetric4
+ INTEGER,
+ ipRouteNextHop
+ IpAddress,
+ ipRouteType
+ INTEGER,
+ ipRouteProto
+ INTEGER,
+ ipRouteAge
+ INTEGER,
+ ipRouteMask
+ IpAddress
+ }
+
+ Definition:
+ A route to a particular destination.
+
+ Access:
+ read-write.
+
+ Status:
+ mandatory.
+
+ We now consider the individual components of each route in the
+ IP Routing table:
+
+
+ OBJECT:
+ -------
+ ipRouteDest { ipRouteEntry 1 }
+
+ Syntax:
+ IpAddress
+
+ Definition:
+ The destination IP address of this route. An entry with
+ a value of 0.0.0.0 is considered a default route.
+ Multiple routes to a single destination can appear in the
+ table, but access to such multiple entries is dependent
+ on the table-access mechanisms defined by the network
+ management protocol in use.
+
+
+
+
+
+IETF SNMP Working Group [Page 42]
+
+RFC 1158 MIB II May 1990
+
+
+ Access:
+ read-write.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ipRouteIfIndex { ipRouteEntry 2 }
+
+ Syntax:
+ INTEGER
+
+ Definition:
+ The index value which uniquely identifies the local
+ interface through which the next hop of this route should
+ be reached. The interface identified by a particular
+ value of this index is the same interface as identified
+ by the same value of ifIndex.
+
+ Access:
+ read-write.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ipRouteMetric1 { ipRouteEntry 3 }
+
+ Syntax:
+ INTEGER
+
+ Definition:
+ The primary routing metric for this route. The semantics
+ of this metric are determined by the routing-protocol
+ specified in the route's ipRouteProto value. If this
+ metric is not used, its value should be set to -1.
+
+ Access:
+ read-write.
+
+ Status:
+ mandatory.
+
+
+
+
+
+IETF SNMP Working Group [Page 43]
+
+RFC 1158 MIB II May 1990
+
+
+ OBJECT:
+ -------
+ ipRouteMetric2 { ipRouteEntry 4 }
+
+ Syntax:
+ INTEGER
+
+ Definition:
+ An alternate routing metric for this route. The
+ semantics of this metric are determined by the routing-
+ protocol specified in the route's ipRouteProto value. If
+ this metric is not used, its value should be set to -1.
+
+ Access:
+ read-write.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ipRouteMetric3 { ipRouteEntry 5 }
+
+ Syntax:
+ INTEGER
+
+ Definition:
+ An alternate routing metric for this route. The
+ semantics of this metric are determined by the routing-
+ protocol specified in the route's ipRouteProto value. If
+ this metric is not used, its value should be set to -1.
+
+ Access:
+ read-write.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ipRouteMetric4 { ipRouteEntry 6 }
+
+ Syntax:
+ INTEGER
+
+
+
+
+
+IETF SNMP Working Group [Page 44]
+
+RFC 1158 MIB II May 1990
+
+
+ Definition:
+ An alternate routing metric for this route. The
+ semantics of this metric are determined by the routing-
+ protocol specified in the route's ipRouteProto value. If
+ this metric is not used, its value should be set to -1.
+
+ Access:
+ read-write.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ipRouteNextHop { ipRouteEntry 7 }
+
+ Syntax:
+ IpAddress
+
+ Definition:
+ The IP address of the next hop of this route. (In the
+ case of a route bound to an interface which is realized
+ via a broadcast media, the value of this field is the
+ agent's IP address on that interface.)
+
+ Access:
+ read-write.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ipRouteType { ipRouteEntry 8 }
+
+ Syntax:
+ INTEGER {
+ other(1), -- none of the following
+
+ invalid(2), -- an invalidated route
+
+ -- route to directly
+ direct(3), -- connected (sub-)network
+
+ -- route to a non-local
+ remote(4) -- host/network/sub-network
+
+
+
+IETF SNMP Working Group [Page 45]
+
+RFC 1158 MIB II May 1990
+
+
+ }
+
+ Definition:
+ The type of route.
+
+ Setting this object to the value invalid(2) has the effect of
+ invalidating the corresponding entry in the ipRoutingTable
+ object. That is, it effectively disassociates the destination
+ identified with said entry from the route identified with said
+ entry. It is an implementation-specific matter as to whether
+ the agent removes an invalidated entry from the table.
+ Accordingly, management stations must be prepared to receive
+ tabular information from agents that corresponds to entries
+ not currently in use. Proper interpretation of such entries
+ requires examination of the relevant ipRouteType object.
+
+ Access:
+ read-write.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ipRouteProto { ipRouteEntry 9 }
+
+ Syntax:
+ INTEGER {
+ other(1), -- none of the following
+
+ -- non-protocol information,
+ -- e.g., manually configured
+ local(2), -- entries
+
+ -- set via a network management
+ netmgmt(3), -- protocol
+
+ -- obtained via ICMP,
+ icmp(4), -- e.g., Redirect
+
+ -- the remaining values are
+ -- all gateway routing protocols
+ egp(5),
+ ggp(6),
+ hello(7),
+ rip(8),
+ is-is(9),
+
+
+
+IETF SNMP Working Group [Page 46]
+
+RFC 1158 MIB II May 1990
+
+
+ es-is(10),
+ ciscoIgrp(11),
+ bbnSpfIgp(12),
+ ospf(13),
+ bgp(14)
+ }
+
+ Definition:
+ The routing mechanism via which this route was learned.
+ Inclusion of values for gateway routing protocols is not
+ intended to imply that hosts should support those
+ protocols.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ipRouteAge { ipRouteEntry 10 }
+
+ Syntax:
+ INTEGER
+
+ Definition:
+ The number of seconds since this route was last updated
+ or otherwise determined to be correct. Note that no
+ semantics of "too old" can be implied except through
+ knowledge of the routing protocol by which the route was
+ learned.
+
+ Access:
+ read-write.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ipRouteMask { ipRouteEntry 11 }
+
+ Syntax:
+ IpAddress
+
+
+
+
+IETF SNMP Working Group [Page 47]
+
+RFC 1158 MIB II May 1990
+
+
+ Definition:
+ Indicate the mask to be logical-ANDed with the
+ destination address before being compared to the value in
+ the ipRouteDest field. For those systems that do not
+ support arbitrary subnet masks, an agent constructs the
+ value of the ipRouteMask by determining whether the value
+ of the correspondent ipRouteDest field belong to a
+ class-A, B, or C network, and then using one of:
+
+ mask network
+ 255.0.0.0 class-A
+ 255.255.0.0 class-B
+ 255.255.255.0 class-C
+
+ If the value of the ipRouteDest is 0.0.0.0 (a default
+ route), then the mask value is also 0.0.0.0. It should
+ be noted that all IP routing subsystems implicitly use
+ this mechanism.
+
+ Access:
+ read-write.
+
+ Status:
+ mandatory.
+
+5.4.3. The IP Address Translation table
+
+ The Address Translation tables contain the IpAddress to "physical"
+ address equivalences. Some interfaces do not use translation tables
+ for determining address equivalences (e.g., DDN-X.25 has an
+ algorithmic method); if all interfaces are of this type, then the
+ Address Translation table is empty, i.e., has zero entries.
+
+
+ OBJECT:
+ -------
+ ipNetToMediaTable { ip 22 }
+
+ Syntax:
+ SEQUENCE OF IpNetToMediaEntry
+
+ Definition:
+ The IP Address Translation table used for mapping from IP
+ addresses to physical addresses.
+
+ Access:
+ read-write.
+
+
+
+
+IETF SNMP Working Group [Page 48]
+
+RFC 1158 MIB II May 1990
+
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ IpNetToMediaEntry { ipNetToMediaTable 1 }
+
+ Syntax:
+ IpNetToMediaEntry ::= SEQUENCE {
+ ipNetToMediaIfIndex
+ INTEGER,
+ ipNetToMediaPhysAddress
+ OCTET STRING,
+ ipNetToMediaNetAddress
+ IpAddress,
+ ipNetToMediaType
+ INTEGER
+ }
+
+ Definition:
+ Each entry contains one IpAddress to "physical" address
+ equivalence.
+
+ Access:
+ read-write.
+
+ Status:
+ mandatory.
+
+ We now consider the individual components of each IP Address
+ Translation table entry:
+
+
+ OBJECT:
+ -------
+ ipNetToMediaIfIndex { ipNetToMediaEntry 1 }
+
+ Syntax:
+ INTEGER
+
+ Definition:
+ The interface on which this entry's equivalence is
+ effective. The interface identified by a particular
+ value of this index is the same interface as identified
+ by the same value of ifIndex.
+
+
+
+
+
+IETF SNMP Working Group [Page 49]
+
+RFC 1158 MIB II May 1990
+
+
+ Access:
+ read-write.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ipNetToMediaPhysAddress { ipNetToMediaEntry 2 }
+
+ Syntax:
+ OCTET STRING
+
+ Definition:
+ The media-dependent "physical" address.
+
+ Access:
+ read-write.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ipNetToMediaNetAddress { ipNetToMediaEntry 3 }
+
+ Syntax:
+ IpAddress
+
+ Definition:
+ The IpAddress corresponding to the media-dependent
+ "physical" address.
+
+ Access:
+ read-write.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ ipNetToMediaType { ipNetToMediaEntry 4 }
+
+ Syntax:
+ INTEGER {
+
+
+
+IETF SNMP Working Group [Page 50]
+
+RFC 1158 MIB II May 1990
+
+
+ other(1), -- none of the following
+
+ invalid(2), -- an invalidated mapping
+
+ dynamic(3),
+
+ static(4)
+ }
+
+ Definition:
+ The type of mapping.
+
+ Setting this object to the value invalid(2) has the effect of
+ invalidating the corresponding entry in the ipNetToMediaTable.
+ That is, it effectively disassociates the interface identified
+ with said entry from the mapping identified with said entry.
+ It is an implementation-specific matter as to whether the
+ agent removes an invalidated entry from the table.
+ Accordingly, management stations must be prepared to receive
+ tabular information from agents that corresponds to entries
+ not currently in use. Proper interpretation of such entries
+ requires examination of the relevant ipNetToMediaType object.
+
+ Access:
+ read-write.
+
+ Status:
+ mandatory.
+
+5.5. The ICMP Group
+
+ Implementation of the ICMP group is mandatory for all systems.
+
+ The ICMP group contains the ICMP input and output statistics.
+
+
+ OBJECT:
+ -------
+ icmpInMsgs { icmp 1 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number of ICMP messages which the entity
+ received. Note that this counter includes all those
+ counted by icmpInErrors.
+
+
+
+
+IETF SNMP Working Group [Page 51]
+
+RFC 1158 MIB II May 1990
+
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ icmpInErrors { icmp 2 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of ICMP messages which the entity received but
+ determined as having ICMP-specific errors (bad ICMP
+ checksums, bad length, etc.).
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ icmpInDestUnreachs { icmp 3 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of ICMP Destination Unreachable messages
+ received.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ icmpInTimeExcds { icmp 4 }
+
+
+
+
+IETF SNMP Working Group [Page 52]
+
+RFC 1158 MIB II May 1990
+
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of ICMP Time Exceeded messages received.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ icmpInParmProbs { icmp 5 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of ICMP Parameter Problem messages received.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ icmpInSrcQuenchs { icmp 6 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of ICMP Source Quench messages received.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+
+
+
+
+IETF SNMP Working Group [Page 53]
+
+RFC 1158 MIB II May 1990
+
+
+ OBJECT:
+ -------
+ icmpInRedirects { icmp 7 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of ICMP Redirect messages received.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ icmpInEchos { icmp 8 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of ICMP Echo (request) messages received.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ icmpInEchoReps { icmp 9 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of ICMP Echo Reply messages received.
+
+ Access:
+ read-only.
+
+
+
+
+
+IETF SNMP Working Group [Page 54]
+
+RFC 1158 MIB II May 1990
+
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ icmpInTimestamps { icmp 10 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of ICMP Timestamp (request) messages received.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ icmpInTimestampReps { icmp 11 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of ICMP Timestamp Reply messages received.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ icmpInAddrMasks { icmp 12 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of ICMP Address Mask Request messages
+ received.
+
+
+
+IETF SNMP Working Group [Page 55]
+
+RFC 1158 MIB II May 1990
+
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ icmpInAddrMaskReps { icmp 13 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of ICMP Address Mask Reply messages received.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ icmpOutMsgs { icmp 14 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number of ICMP messages which this entity
+ attempted to send. Note that this counter includes all
+ those counted by icmpOutErrors.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ icmpOutErrors { icmp 15 }
+
+
+
+
+
+IETF SNMP Working Group [Page 56]
+
+RFC 1158 MIB II May 1990
+
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of ICMP messages which this entity did not
+ send due to problems discovered within ICMP such as a
+ lack of buffers. This value should not include errors
+ discovered outside the ICMP layer such as the inability
+ of IP to route the resultant datagram. In some
+ implementations there may be no types of error which
+ contribute to this counter's value.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ icmpOutDestUnreachs { icmp 16 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of ICMP Destination Unreachable messages sent.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ icmpOutTimeExcds { icmp 17 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of ICMP Time Exceeded messages sent.
+
+ Access:
+ read-only.
+
+
+
+IETF SNMP Working Group [Page 57]
+
+RFC 1158 MIB II May 1990
+
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ icmpOutParmProbs { icmp 18 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of ICMP Parameter Problem messages sent.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ icmpOutSrcQuenchs { icmp 19 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of ICMP Source Quench messages sent.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ icmpOutRedirects { icmp 20 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of ICMP Redirect messages sent. For a host,
+ this object will always be zero, since hosts do not send
+
+
+
+IETF SNMP Working Group [Page 58]
+
+RFC 1158 MIB II May 1990
+
+
+ redirects.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ icmpOutEchos { icmp 21 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of ICMP Echo (request) messages sent.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ icmpOutEchoReps { icmp 22 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of ICMP Echo Reply messages sent.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ icmpOutTimestamps { icmp 23 }
+
+
+
+
+
+IETF SNMP Working Group [Page 59]
+
+RFC 1158 MIB II May 1990
+
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of ICMP Timestamp (request) messages sent.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ icmpOutTimestampReps { icmp 24 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of ICMP Timestamp Reply messages sent.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ icmpOutAddrMasks { icmp 25 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of ICMP Address Mask Request messages sent.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+
+
+
+
+IETF SNMP Working Group [Page 60]
+
+RFC 1158 MIB II May 1990
+
+
+ OBJECT:
+ -------
+ icmpOutAddrMaskReps { icmp 26 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of ICMP Address Mask Reply messages sent.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+5.6. The TCP Group
+
+ Implementation of the TCP group is mandatory for all systems that
+ implement the TCP.
+
+ Note that instances of object types that represent information about
+ a particular TCP connection are transient; they persist only as long
+ as the connection in question.
+
+
+ OBJECT:
+ -------
+ tcpRtoAlgorithm { tcp 1 }
+
+ Syntax:
+ INTEGER {
+ other(1), -- none of the following
+ constant(2), -- a constant rto
+ rsre(3), -- MIL-STD-1778, Appendix B
+ vanj(4) -- Van Jacobson's algorithm [11]
+ }
+
+ Definition:
+ The algorithm used to determine the timeout value used
+ for retransmitting unacknowledged octets.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+
+
+IETF SNMP Working Group [Page 61]
+
+RFC 1158 MIB II May 1990
+
+
+ OBJECT:
+ -------
+ tcpRtoMin { tcp 2 }
+
+ Syntax:
+ INTEGER
+
+ Definition:
+ The minimum value permitted by a TCP implementation for
+ the retransmission timeout, measured in milliseconds.
+ More refined semantics for objects of this type depend
+ upon the algorithm used to determine the retransmission
+ timeout. In particular, when the timeout algorithm is
+ rsre(3), an object of this type has the semantics of the
+ LBOUND quantity described in RFC 793.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ tcpRtoMax { tcp 3 }
+
+ Syntax:
+ INTEGER
+
+ Definition:
+ The maximum value permitted by a TCP implementation for
+ the retransmission timeout, measured in milliseconds.
+ More refined semantics for objects of this type depend
+ upon the algorithm used to determine the retransmission
+ timeout. In particular, when the timeout algorithm is
+ rsre(3), an object of this type has the semantics of the
+ UBOUND quantity described in RFC 793.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+
+
+
+
+
+IETF SNMP Working Group [Page 62]
+
+RFC 1158 MIB II May 1990
+
+
+ OBJECT:
+ -------
+ tcpMaxConn { tcp 4 }
+
+ Syntax:
+ INTEGER
+
+ Definition:
+ The limit on the total number of TCP connections the
+ entity can support. In entities where the maximum number
+ of connections is dynamic, this object should contain the
+ value "-1".
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ tcpActiveOpens { tcp 5 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of times TCP connections have made a direct
+ transition to the SYN-SENT state from the CLOSED state.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ tcpPassiveOpens { tcp 6 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of times TCP connections have made a direct
+ transition to the SYN-RCVD state from the LISTEN state.
+
+
+
+IETF SNMP Working Group [Page 63]
+
+RFC 1158 MIB II May 1990
+
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ tcpAttemptFails { tcp 7 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of times TCP connections have made a direct
+ transition to the CLOSED state from either the SYN-SENT
+ state or the SYN-RCVD state, plus the number of times TCP
+ connections have made a direct transition to the LISTEN
+ state from the SYN-RCVD state.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ tcpEstabResets { tcp 8 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of times TCP connections have made a direct
+ transition to the CLOSED state from either the
+ ESTABLISHED state or the CLOSE-WAIT state.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+
+
+
+
+IETF SNMP Working Group [Page 64]
+
+RFC 1158 MIB II May 1990
+
+
+ OBJECT:
+ -------
+ tcpCurrEstab { tcp 9 }
+
+ Syntax:
+ Gauge
+
+ Definition:
+ The number of TCP connections for which the current state
+ is either ESTABLISHED or CLOSE-WAIT.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ tcpInSegs { tcp 10 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number of segments received, including those
+ received in error. This count includes segments received
+ on currently established connections.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ tcpOutSegs { tcp 11 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number of segments sent, including those on
+ current connections but excluding those containing only
+ retransmitted octets.
+
+
+
+IETF SNMP Working Group [Page 65]
+
+RFC 1158 MIB II May 1990
+
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ tcpRetransSegs { tcp 12 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number of segments retransmitted - that is, the
+ number of TCP segments transmitted containing one or more
+ previously transmitted octets.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+5.6.1. The TCP Connection table
+
+ The TCP connection table contains information about this entity's
+ existing TCP connections.
+
+
+ OBJECT:
+ -------
+ tcpConnTable { tcp 13 }
+
+ Syntax:
+ SEQUENCE OF TcpConnEntry
+
+ Definition:
+ A table containing TCP connection-specific information.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+
+
+
+IETF SNMP Working Group [Page 66]
+
+RFC 1158 MIB II May 1990
+
+
+ OBJECT:
+ -------
+ tcpConnEntry { tcpConnTable 1 }
+
+ Syntax:
+ TcpConnEntry ::= SEQUENCE {
+ tcpConnState
+ INTEGER,
+ tcpConnLocalAddress
+ IpAddress,
+ tcpConnLocalPort
+ INTEGER (0..65535),
+ tcpConnRemAddress
+ IpAddress,
+ tcpConnRemPort
+ INTEGER (0..65535)
+ }
+
+ Definition:
+ Information about a particular current TCP connection.
+ An object of this type is transient, in that it ceases to
+ exist when (or soon after) the connection makes the
+ transition to the CLOSED state.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ tcpConnState { tcpConnEntry 1 }
+
+ Syntax:
+ INTEGER {
+ closed(1),
+ listen(2),
+ synSent(3),
+ synReceived(4),
+ established(5),
+ finWait1(6),
+ finWait2(7),
+ closeWait(8),
+ lastAck(9),
+ closing(10),
+ timeWait(11)
+
+
+
+IETF SNMP Working Group [Page 67]
+
+RFC 1158 MIB II May 1990
+
+
+ }
+
+ Definition:
+ The state of this TCP connection.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ tcpConnLocalAddress { tcpConnEntry 2 }
+
+ Syntax:
+ IpAddress
+
+ Definition:
+ The local IP address for this TCP connection. In the
+ case of a connection in the listen state which is willing
+ to accept connections for any IP interface associated
+ with the node, the value 0.0.0.0 is used.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ tcpConnLocalPort { tcpConnEntry 3 }
+
+ Syntax:
+ INTEGER (0..65535)
+
+ Definition:
+ The local port number for this TCP connection.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+
+
+IETF SNMP Working Group [Page 68]
+
+RFC 1158 MIB II May 1990
+
+
+ OBJECT:
+ -------
+ tcpConnRemAddress { tcpConnEntry 4 }
+
+ Syntax:
+ IpAddress
+
+ Definition:
+ The remote IP address for this TCP connection.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ tcpConnRemPort { tcpConnEntry 5 }
+
+ Syntax:
+ INTEGER (0..65535)
+
+ Definition:
+ The remote port number for this TCP connection.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+5.6.2. Additional TCP Objects
+
+
+ OBJECT:
+ -------
+ tcpInErrs { tcp 14 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number of segments received in error (e.g., bad
+ TCP checksums).
+
+
+
+
+
+IETF SNMP Working Group [Page 69]
+
+RFC 1158 MIB II May 1990
+
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ tcpOutRsts { tcp 15 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of TCP segments sent containing the RST flag.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+5.7. The UDP Group
+
+ Implementation of the UDP group is mandatory for all systems which
+ implement the UDP.
+
+
+ OBJECT:
+ -------
+ udpInDatagrams { udp 1 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number of UDP datagrams delivered to UDP users.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+
+
+
+
+
+IETF SNMP Working Group [Page 70]
+
+RFC 1158 MIB II May 1990
+
+
+ OBJECT:
+ -------
+ udpNoPorts { udp 2 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number of received UDP datagrams for which
+ there was no application at the destination port.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ udpInErrors { udp 3 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of received UDP datagrams that could not be
+ delivered for reasons other than the lack of an
+ application at the destination port.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ udpOutDatagrams { udp 4 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number of UDP datagrams sent from this entity.
+
+
+
+
+
+IETF SNMP Working Group [Page 71]
+
+RFC 1158 MIB II May 1990
+
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+5.7.1. The UDP Listener table
+
+ The UDP listener table contains information about this entity's UDP
+ end-points on which a local application is currently accepting
+ datagrams.
+
+
+ OBJECT:
+ -------
+ udpTable { udp 5 }
+
+ Syntax:
+ SEQUENCE OF UdpEntry
+
+ Definition:
+ A table containing UDP listener information.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ udpEntry { udpTable 1 }
+
+ Syntax:
+ UdpEntry ::= SEQUENCE {
+ udpLocalAddress
+ IpAddress,
+ udpLocalPort
+ INTEGER (0..65535)
+ }
+
+ Definition:
+ Information about a particular current UDP listener.
+
+ Access:
+ read-only.
+
+
+
+
+IETF SNMP Working Group [Page 72]
+
+RFC 1158 MIB II May 1990
+
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ udpLocalAddress { udpEntry 1 }
+
+ Syntax:
+ IpAddress
+
+ Definition:
+ The local IP address for this UDP listener. In the case
+ of a UDP listener which is willing to accept datagrams
+ for any IP interface associated with the node, the value
+ 0.0.0.0 is used.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ udpLocalPort { udpEntry 2 }
+
+ Syntax:
+ INTEGER (0..65535)
+
+ Definition:
+ The local port number for this UDP listener.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+5.8. The EGP Group
+
+ Implementation of the EGP group is mandatory for all systems which
+ implement the EGP.
+
+
+
+
+
+
+
+IETF SNMP Working Group [Page 73]
+
+RFC 1158 MIB II May 1990
+
+
+ OBJECT:
+ -------
+ egpInMsgs { egp 1 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of EGP messages received without error.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ egpInErrors { egp 2 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of EGP messages received that proved to be in
+ error.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ egpOutMsgs { egp 3 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number of locally generated EGP messages.
+
+ Access:
+ read-only.
+
+
+
+
+IETF SNMP Working Group [Page 74]
+
+RFC 1158 MIB II May 1990
+
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ egpOutErrors { egp 4 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of locally generated EGP messages not sent due
+ to resource limitations within an EGP entity.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+5.8.1. The EGP Neighbor table
+
+ The Egp Neighbor table contains information about this entity's EGP
+ neighbors.
+
+
+ OBJECT:
+ -------
+ egpNeighTable { egp 5 }
+
+ Syntax:
+ SEQUENCE OF EgpNeighEntry
+
+ Definition:
+ The EGP neighbor table.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ egpNeighEntry { egpNeighTable 1 }
+
+
+
+
+IETF SNMP Working Group [Page 75]
+
+RFC 1158 MIB II May 1990
+
+
+ Syntax:
+ EgpNeighEntry ::= SEQUENCE {
+ egpNeighState
+ INTEGER,
+ egpNeighAddr
+ IpAddress,
+ egpNeighAs
+ INTEGER,
+ egpNeighInMsgs
+ Counter,
+ egpNeighInErrs
+ Counter,
+ egpNeighOutMsgs
+ Counter,
+ egpNeighOutErrs
+ Counter,
+ egpNeighInErrMsgs
+ Counter,
+ egpNeighOutErrMsgs
+ Counter,
+ egpNeighStateUps
+ Counter,
+ egpNeighStateDowns
+ Counter,
+ egpNeighIntervalHello
+ INTEGER,
+ egpNeighIntervalPoll
+ INTEGER,
+ egpNeighMode
+ INTEGER,
+ egpNeighEventTrigger
+ INTEGER
+ }
+
+ Definition:
+ Information about this entity's relationship with a
+ particular EGP neighbor.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ We now consider the individual components of each EGP neighbor
+ entry:
+
+
+
+
+IETF SNMP Working Group [Page 76]
+
+RFC 1158 MIB II May 1990
+
+
+ OBJECT:
+ -------
+ egpNeighState { egpNeighEntry 1 }
+
+ Syntax:
+ INTEGER {
+ idle(1),
+ acquisition(2),
+ down(3),
+ up(4),
+ cease(5)
+ }
+
+ Definition:
+ The EGP state of the local system with respect to this
+ entry's EGP neighbor. Each EGP state is represented by a
+ value that is one greater than the numerical value
+ associated with said state in RFC 904.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ egpNeighAddr { egpNeighEntry 2 }
+
+ Syntax:
+ IpAddress
+
+ Definition:
+ The IP address of this entry's EGP neighbor.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ egpNeighAs { egpNeighEntry 3 }
+
+
+
+
+
+IETF SNMP Working Group [Page 77]
+
+RFC 1158 MIB II May 1990
+
+
+ Syntax:
+ INTEGER
+
+ Definition:
+ The autonomous system of this EGP peer. Zero should be
+ specified if the autonomous system number of the neighbor
+ is not yet known.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ egpNeighInMsgs { egpNeighEntry 4 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of EGP messages received without error from
+ this EGP peer.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ egpNeighInErrs { egpNeighEntry 5 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of EGP messages received from this EGP peer
+ that proved to be in error (e.g., bad EGP checksum).
+
+ Access:
+ read-only.
+
+
+
+
+
+IETF SNMP Working Group [Page 78]
+
+RFC 1158 MIB II May 1990
+
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ egpNeighOutMsgs { egpNeighEntry 6 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of locally generated EGP messages to this EGP
+ peer.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ egpNeighOutErrs { egpNeighEntry 7 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of locally generated EGP messages not sent to
+ this EGP peer due to resource limitations within an EGP
+ entity.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ egpNeighInErrMsgs { egpNeighEntry 8 }
+
+ Syntax:
+ Counter
+
+
+
+
+IETF SNMP Working Group [Page 79]
+
+RFC 1158 MIB II May 1990
+
+
+ Definition:
+ The number of EGP-defined error messages received from
+ this EGP peer.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ egpNeighOutErrMsgs { egpNeighEntry 9 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of EGP-defined error messages sent to this EGP
+ peer.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ egpNeighStateUps { egpNeighEntry 10 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of EGP state transitions to the UP state with
+ this EGP peer.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+
+
+
+
+IETF SNMP Working Group [Page 80]
+
+RFC 1158 MIB II May 1990
+
+
+ OBJECT:
+ -------
+ egpNeighStateDowns { egpNeighEntry 11 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The number of EGP state transitions from the UP state to
+ any other state with this EGP peer.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ egpNeighIntervalHello { egpNeighEntry 12 }
+
+ Syntax:
+ INTEGER
+
+ Definition:
+ The interval between EGP Hello command retransmissions
+ (in hundredths of a second). This represents the t1
+ timer as defined in RFC 904.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ egpNeighIntervalPoll { egpNeighEntry 13 }
+
+ Syntax:
+ INTEGER
+
+ Definition:
+ The interval between EGP poll command retransmissions (in
+ hundredths of a second). This represents the t3 timer as
+ defined in RFC 904.
+
+
+
+IETF SNMP Working Group [Page 81]
+
+RFC 1158 MIB II May 1990
+
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ egpNeighMode { egpNeighEntry 14 }
+
+ Syntax:
+ INTEGER {
+ active(1),
+ passive(2)
+ }
+
+ Definition:
+ The polling mode of this EGP entity, either passive or
+ active.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ egpNeighEventTrigger { egpNeighEntry 15 }
+
+ Syntax:
+ INTEGER {
+ start(1),
+ stop(2)
+ }
+
+ Definition:
+ A control variable used to trigger operator-initiated
+ Start and Stop events. When read, this variable always
+ returns the most recent value that egpNeightEventTrigger
+ was set to. If it has not been set since the last
+ initialization of the network management subsystem on the
+ node, it returns a value of "stop".
+
+ Access:
+ read-write
+
+
+
+IETF SNMP Working Group [Page 82]
+
+RFC 1158 MIB II May 1990
+
+
+ Status:
+ mandatory.
+
+5.8.2. Additional EGP variables
+
+
+ OBJECT:
+ -------
+ egpAs { egp 6 }
+
+ Syntax:
+ INTEGER
+
+ Definition:
+ The autonomous system number of this EGP entity.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+5.9. The Transmission Group
+
+ Based on the transmission media underlying each interface on a
+ system, the corresponding portion of the Transmission group is
+ mandatory for that system.
+
+ When Internet-standard definitions for managing transmission media
+ are defined, the transmission group is used to provide a prefix for
+ the names of those objects.
+
+ Typically, such definitions reside in the experimental portion of the
+ MIB until they are "proven", then as a part of the Internet
+ standardization process, the definitions are accordingly elevated and
+ a new object identifier, under the transmission group is defined. By
+ convention, the name assigned is:
+
+ type OBJECT IDENTIFIER ::= { transmission number }
+
+ where "type" is the symbolic value used for the media in the ifType
+ column of the ifTable object, and "number" is the actual integer
+ value corresponding to the symbol.
+
+5.10. The SNMP Group
+
+ Implementation of the SNMP group is mandatory for all systems which
+ support an SNMP protocol entity. Some of the objects defined below
+
+
+
+IETF SNMP Working Group [Page 83]
+
+RFC 1158 MIB II May 1990
+
+
+ will be zero-valued in those SNMP implementations that are optimized
+ to support only those functions specific to either a management agent
+ or a management client.
+
+
+ OBJECT:
+ -------
+ snmpInPkts { snmp 1 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number of PDUs delivered to the SNMP entity
+ from the transport service.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ snmpOutPkts { snmp 2 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number of SNMP PDUs which were passed from the
+ SNMP protocol entity to the transport service.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ snmpInBadVersions { snmp 3 }
+
+ Syntax:
+ Counter
+
+
+
+
+IETF SNMP Working Group [Page 84]
+
+RFC 1158 MIB II May 1990
+
+
+ Definition:
+ The total number of syntactically correct SNMP PDUs which
+ were delivered to the SNMP protocol entity and were for
+ an unsupported SNMP version.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ snmpInBadCommunityNames { snmp 4 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number of SNMP PDUs delivered to the SNMP
+ protocol entity which used a SNMP community name not
+ known to said entity.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ snmpInBadCommunityUses { snmp 5 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number of SNMP PDUs delivered to the SNMP
+ protocol entity which represented an SNMP operation which
+ was not allowed by the SNMP community named in the PDU.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+
+IETF SNMP Working Group [Page 85]
+
+RFC 1158 MIB II May 1990
+
+
+ OBJECT:
+ -------
+ snmpInASNParseErrs { snmp 6 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number of ASN.1 parsing errors (either in
+ encoding or syntax) encountered by the SNMP protocol
+ entity when decoding received SNMP PDUs.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ snmpInBadTypes { snmp 7 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number of SNMP PDUs delivered to the SNMP
+ protocol entity which had an unknown PDU type.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ snmpInTooBigs { snmp 8 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number valid SNMP PDUs which were delivered to
+ the SNMP protocol entity and for which the value of the
+ "ErrorStatus" component is "tooBig."
+
+
+
+IETF SNMP Working Group [Page 86]
+
+RFC 1158 MIB II May 1990
+
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ snmpInNoSuchNames { snmp 9 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number valid SNMP PDUs which were delivered to
+ the SNMP protocol entity and for which the value of the
+ "ErrorStatus" component is "noSuchName."
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ snmpInBadValues { snmp 10 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number valid SNMP PDUs which were delivered to
+ the SNMP protocol entity and for which the value of the
+ "ErrorStatus" component is "badValue."
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ snmpInReadOnlys { snmp 11 }
+
+
+
+IETF SNMP Working Group [Page 87]
+
+RFC 1158 MIB II May 1990
+
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number valid SNMP PDUs which were delivered to
+ the SNMP protocol entity and for which the value of the
+ "ErrorStatus" component is "readOnly."
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ snmpInGenErrs { snmp 12 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number valid SNMP PDUs which were delivered to
+ the SNMP protocol entity and for which the value of the
+ "ErrorStatus" component is "genErr."
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ snmpInTotalReqVars { snmp 13 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number of MIB objects which have been retrieved
+ successfully by the SNMP protocol entity as the result of
+ receiving valid SNMP Get-Request and Get-Next PDUs.
+
+ Access:
+ read-only.
+
+
+
+IETF SNMP Working Group [Page 88]
+
+RFC 1158 MIB II May 1990
+
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ snmpInTotalSetVars { snmp 14 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number of MIB objects which have been altered
+ successfully by the SNMP protocol entity as the result of
+ receiving valid SNMP Set-Request PDUs.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ snmpInGetRequests { snmp 15 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number of SNMP Get-Request PDUs which have been
+ accepted and processed by the SNMP protocol entity.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ snmpInGetNexts { snmp 16 }
+
+ Syntax:
+ Counter
+
+
+
+
+IETF SNMP Working Group [Page 89]
+
+RFC 1158 MIB II May 1990
+
+
+ Definition:
+ The total number of SNMP Get-Next PDUs which have been
+ accepted and processed by the SNMP protocol entity.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ snmpInSetRequests { snmp 17 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number of SNMP Set-Request PDUs which have been
+ accepted and processed by the SNMP protocol entity.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ snmpInGetResponses { snmp 18 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number of SNMP Get-Response PDUs which have
+ been accepted and processed by the SNMP protocol entity.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+
+
+
+
+IETF SNMP Working Group [Page 90]
+
+RFC 1158 MIB II May 1990
+
+
+ OBJECT:
+ -------
+ snmpInTraps { snmp 19 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number of SNMP Trap PDUs which have been
+ accepted and processed by the SNMP protocol entity.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ snmpOutTooBigs { snmp 20 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number valid SNMP PDUs which were generated by
+ the SNMP protocol entity and for which the value of the
+ "ErrorStatus" component is "tooBig."
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ snmpOutNoSuchNames { snmp 21 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number valid SNMP PDUs which were generated by
+ the SNMP protocol entity and for which the value of the
+ "ErrorStatus" component is "noSuchName."
+
+
+
+IETF SNMP Working Group [Page 91]
+
+RFC 1158 MIB II May 1990
+
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ snmpOutBadValues { snmp 22 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number valid SNMP PDUs which were generated by
+ the SNMP protocol entity and for which the value of the
+ "ErrorStatus" component is "badValue."
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ snmpOutReadOnlys { snmp 23 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number valid SNMP PDUs which were generated by
+ the SNMP protocol entity and for which the value of the
+ "ErrorStatus" component is "readOnly."
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ snmpOutGenErrs { snmp 24 }
+
+
+
+IETF SNMP Working Group [Page 92]
+
+RFC 1158 MIB II May 1990
+
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number valid SNMP PDUs which were generated by
+ the SNMP protocol entity and for which the value of the
+ "ErrorStatus" component is "genErr."
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ snmpOutGetRequests { snmp 25 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number of SNMP Get-Request PDUs which have been
+ generated by the SNMP protocol entity.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ snmpOutGetNexts { snmp 26 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number of SNMP Get-Next PDUs which have been
+ generated by the SNMP protocol entity.
+
+ Access:
+ read-only.
+
+
+
+
+
+IETF SNMP Working Group [Page 93]
+
+RFC 1158 MIB II May 1990
+
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ snmpOutSetRequests { snmp 27 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number of SNMP Set-Request PDUs which have been
+ generated by the SNMP protocol entity.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ snmpOutGetResponses { snmp 28 }
+
+ Syntax:
+ Counter
+
+ Definition:
+ The total number of SNMP Get-Response PDUs which have
+ been generated by the SNMP protocol entity.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ snmpOutTraps { snmp 29 }
+
+ Syntax:
+ Counter
+
+
+
+
+
+IETF SNMP Working Group [Page 94]
+
+RFC 1158 MIB II May 1990
+
+
+ Definition:
+ The total number of SNMP Trap PDUs which have been
+ generated by the SNMP protocol entity.
+
+ Access:
+ read-only.
+
+ Status:
+ mandatory.
+
+
+ OBJECT:
+ -------
+ snmpEnableAuthTraps { snmp 30 }
+
+ Syntax:
+ INTEGER {
+ enabled(1),
+ disabled(2)
+ }
+
+ Definition:
+ Indicates whether the SNMP agent process is configured to
+ generate authentication-failure traps.
+
+ Access:
+ read-write.
+
+ Status:
+ mandatory.
+
+6. Definitions
+
+ RFC1158-MIB
+
+ DEFINITIONS ::= BEGIN
+
+ IMPORTS
+ mgmt, OBJECT-TYPE, NetworkAddress, IpAddress,
+ Counter, Gauge, TimeTicks
+ FROM RFC1155-SMI;
+
+ mib-2 OBJECT IDENTIFIER ::= { mgmt 1 } -- MIB-II
+ -- (same prefix as MIB-I)
+
+ system OBJECT IDENTIFIER ::= { mib-2 1 }
+ interfaces OBJECT IDENTIFIER ::= { mib-2 2 }
+ at OBJECT IDENTIFIER ::= { mib-2 3 }
+
+
+
+IETF SNMP Working Group [Page 95]
+
+RFC 1158 MIB II May 1990
+
+
+ ip OBJECT IDENTIFIER ::= { mib-2 4 }
+ icmp OBJECT IDENTIFIER ::= { mib-2 5 }
+ tcp OBJECT IDENTIFIER ::= { mib-2 6 }
+ udp OBJECT IDENTIFIER ::= { mib-2 7 }
+ egp OBJECT IDENTIFIER ::= { mib-2 8 }
+ -- cmot OBJECT IDENTIFIER ::= { mib-2 9 }
+ transmission OBJECT IDENTIFIER ::= { mib-2 10 }
+ snmp OBJECT IDENTIFIER ::= { mib-2 11 }
+
+
+ -- object types
+
+ -- the System group
+
+ sysDescr OBJECT-TYPE
+ SYNTAX DisplayString (SIZE (0..255))
+ ACCESS read-only
+ STATUS mandatory
+ ::= { system 1 }
+
+ sysObjectID OBJECT-TYPE
+ SYNTAX OBJECT IDENTIFIER
+ ACCESS read-only
+ STATUS mandatory
+ ::= { system 2 }
+
+ sysUpTime OBJECT-TYPE
+ SYNTAX TimeTicks
+ ACCESS read-only
+ STATUS mandatory
+ ::= { system 3 }
+
+ sysContact OBJECT-TYPE
+ SYNTAX DisplayString (SIZE (0..255))
+ ACCESS read-write
+ STATUS mandatory
+ ::= { system 4 }
+
+ sysName OBJECT-TYPE
+ SYNTAX DisplayString (SIZE (0..255))
+ ACCESS read-write
+ STATUS mandatory
+ ::= { system 5 }
+
+ sysLocation OBJECT-TYPE
+ SYNTAX DisplayString (SIZE (0..255))
+ ACCESS read-only
+ STATUS mandatory
+
+
+
+IETF SNMP Working Group [Page 96]
+
+RFC 1158 MIB II May 1990
+
+
+ ::= { system 6 }
+
+ sysServices OBJECT-TYPE
+ SYNTAX INTEGER (0..127)
+ ACCESS read-only
+ STATUS mandatory
+ ::= { system 7 }
+
+
+ -- the Interfaces group
+
+ ifNumber OBJECT-TYPE
+ SYNTAX INTEGER
+ ACCESS read-only
+ STATUS mandatory
+ ::= { interfaces 1 }
+
+ -- the Interfaces table
+
+ ifTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF IfEntry
+ ACCESS read-only
+ STATUS mandatory
+ ::= { interfaces 2 }
+
+ ifEntry OBJECT-TYPE
+ SYNTAX IfEntry
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ifTable 1 }
+
+ IfEntry ::= SEQUENCE {
+ ifIndex
+ INTEGER,
+ ifDescr
+ DisplayString,
+ ifType
+ INTEGER,
+ ifMtu
+ INTEGER,
+ ifSpeed
+ Gauge,
+ ifPhysAddress
+ OCTET STRING,
+ ifAdminStatus
+ INTEGER,
+ ifOperStatus
+ INTEGER,
+
+
+
+IETF SNMP Working Group [Page 97]
+
+RFC 1158 MIB II May 1990
+
+
+ ifLastChange
+ TimeTicks,
+ ifInOctets
+ Counter,
+ ifInUcastPkts
+ Counter,
+ ifInNUcastPkts
+ Counter,
+ ifInDiscards
+ Counter,
+ ifInErrors
+ Counter,
+ ifInUnknownProtos
+ Counter,
+ ifOutOctets
+ Counter,
+ ifOutUcastPkts
+ Counter,
+ ifOutNUcastPkts
+ Counter,
+ ifOutDiscards
+ Counter,
+ ifOutErrors
+ Counter,
+ ifOutQLen
+ Gauge,
+ ifSpecific
+ OBJECT IDENTIFIER
+ }
+
+ ifIndex OBJECT-TYPE
+ SYNTAX INTEGER
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ifEntry 1 }
+
+ ifDescr OBJECT-TYPE
+ SYNTAX DisplayString (SIZE (0..255))
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ifEntry 2 }
+
+ ifType OBJECT-TYPE
+ SYNTAX INTEGER {
+ other(1), -- none of the
+ -- following
+ regular1822(2),
+ hdh1822(3),
+
+
+
+IETF SNMP Working Group [Page 98]
+
+RFC 1158 MIB II May 1990
+
+
+ ddn-x25(4),
+ rfc877-x25(5),
+ ethernet-csmacd(6),
+ iso88023-csmacd(7),
+ iso88024-tokenBus(8),
+ iso88025-tokenRing(9),
+ iso88026-man(10),
+ starLan(11),
+ proteon-10Mbit(12),
+ proteon-80Mbit(13),
+ hyperchannel(14),
+ fddi(15),
+ lapb(16),
+ sdlc(17),
+ t1-carrier(18),
+ cept(19), -- european
+ --equivalent of T-1
+ basicISDN(20),
+ primaryISDN(21),
+ -- proprietary
+ -- serial
+ propPointToPointSerial(22),
+ terminalServer-asyncPort(23),
+ softwareLoopback(24),
+ eon(25), -- CLNP over IP
+ ethernet-3Mbit(26),
+ nsip(27), -- XNS over IP
+ slip(28) -- generic SLIP
+ }
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ifEntry 3 }
+
+ ifMtu OBJECT-TYPE
+ SYNTAX INTEGER
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ifEntry 4 }
+
+ ifSpeed OBJECT-TYPE
+ SYNTAX Gauge
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ifEntry 5 }
+
+ ifPhysAddress OBJECT-TYPE
+ SYNTAX OCTET STRING
+ ACCESS read-only
+
+
+
+IETF SNMP Working Group [Page 99]
+
+RFC 1158 MIB II May 1990
+
+
+ STATUS mandatory
+ ::= { ifEntry 6 }
+
+ ifAdminStatus OBJECT-TYPE
+ SYNTAX INTEGER {
+ up(1), -- ready to pass packets
+ down(2),
+ testing(3) -- in some test mode
+ }
+ ACCESS read-write
+ STATUS mandatory
+ ::= { ifEntry 7 }
+
+ ifOperStatus OBJECT-TYPE
+ SYNTAX INTEGER {
+ up(1), -- ready to pass packets
+ down(2),
+ testing(3) -- in some test mode
+ }
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ifEntry 8 }
+
+ ifLastChange OBJECT-TYPE
+ SYNTAX TimeTicks
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ifEntry 9 }
+
+ ifInOctets OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ifEntry 10 }
+
+ ifInUcastPkts OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ifEntry 11 }
+
+ ifInNUcastPkts OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ifEntry 12 }
+
+ ifInDiscards OBJECT-TYPE
+
+
+
+IETF SNMP Working Group [Page 100]
+
+RFC 1158 MIB II May 1990
+
+
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ifEntry 13 }
+
+ ifInErrors OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ifEntry 14 }
+
+ ifInUnknownProtos OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ifEntry 15 }
+
+ ifOutOctets OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ifEntry 16 }
+
+ ifOutUcastPkts OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ifEntry 17 }
+
+ ifOutNUcastPkts OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ifEntry 18 }
+
+ ifOutDiscards OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ifEntry 19 }
+
+ ifOutErrors OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ifEntry 20 }
+
+ ifOutQLen OBJECT-TYPE
+
+
+
+IETF SNMP Working Group [Page 101]
+
+RFC 1158 MIB II May 1990
+
+
+ SYNTAX Gauge
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ifEntry 21 }
+
+ ifSpecific OBJECT-TYPE
+ SYNTAX OBJECT IDENTIFIER
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ifEntry 22 }
+
+ nullSpecific OBJECT IDENTIFIER ::= { 0 0 }
+
+ -- the Address Translation group (deprecated)
+
+ atTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF AtEntry
+ ACCESS read-write
+ STATUS deprecated
+ ::= { at 1 }
+
+ atEntry OBJECT-TYPE
+ SYNTAX AtEntry
+ ACCESS read-write
+ STATUS deprecated
+ ::= { atTable 1 }
+
+ AtEntry ::= SEQUENCE {
+ atIfIndex
+ INTEGER,
+ atPhysAddress
+ OCTET STRING,
+ atNetAddress
+ NetworkAddress
+ }
+
+ atIfIndex OBJECT-TYPE
+ SYNTAX INTEGER
+ ACCESS read-write
+ STATUS deprecated
+ ::= { atEntry 1 }
+
+ atPhysAddress OBJECT-TYPE
+ SYNTAX OCTET STRING
+ ACCESS read-write
+ STATUS deprecated
+ ::= { atEntry 2 }
+
+
+
+
+IETF SNMP Working Group [Page 102]
+
+RFC 1158 MIB II May 1990
+
+
+ atNetAddress OBJECT-TYPE
+ SYNTAX NetworkAddress
+ ACCESS read-write
+ STATUS deprecated
+ ::= { atEntry 3 }
+
+
+ -- the IP group
+
+ ipForwarding OBJECT-TYPE
+ SYNTAX INTEGER {
+ gateway(1), -- entity forwards
+ -- datagrams
+ host(2) -- entity does NOT
+ -- forward datagrams
+ }
+ ACCESS read-write
+ STATUS mandatory
+ ::= { ip 1 }
+
+ ipDefaultTTL OBJECT-TYPE
+ SYNTAX INTEGER
+ ACCESS read-write
+ STATUS mandatory
+ ::= { ip 2 }
+
+ ipInReceives OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ip 3 }
+
+ ipInHdrErrors OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ip 4 }
+
+ ipInAddrErrors OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ip 5 }
+
+ ipForwDatagrams OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+
+
+
+IETF SNMP Working Group [Page 103]
+
+RFC 1158 MIB II May 1990
+
+
+ ::= { ip 6 }
+
+ ipInUnknownProtos OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ip 7 }
+
+ ipInDiscards OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ip 8 }
+
+ ipInDelivers OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ip 9 }
+
+ ipOutRequests OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ip 10 }
+
+ ipOutDiscards OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ip 11 }
+
+ ipOutNoRoutes OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ip 12 }
+
+ ipReasmTimeout OBJECT-TYPE
+ SYNTAX INTEGER
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ip 13 }
+
+ ipReasmReqds OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+
+
+
+IETF SNMP Working Group [Page 104]
+
+RFC 1158 MIB II May 1990
+
+
+ ::= { ip 14 }
+
+ ipReasmOKs OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ip 15 }
+
+ ipReasmFails OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ip 16 }
+
+ ipFragOKs OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ip 17 }
+
+ ipFragFails OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ip 18 }
+
+ ipFragCreates OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ip 19 }
+
+ -- the IP Interface table
+
+ ipAddrTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF IpAddrEntry
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ip 20 }
+
+ ipAddrEntry OBJECT-TYPE
+ SYNTAX IpAddrEntry
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ipAddrTable 1 }
+
+ IpAddrEntry ::= SEQUENCE {
+ ipAdEntAddr
+
+
+
+IETF SNMP Working Group [Page 105]
+
+RFC 1158 MIB II May 1990
+
+
+ IpAddress,
+ ipAdEntIfIndex
+ INTEGER,
+ ipAdEntNetMask
+ IpAddress,
+ ipAdEntBcastAddr
+ INTEGER,
+ ipAdEntReasmMaxSize
+ INTEGER (0..65535)
+ }
+
+ ipAdEntAddr OBJECT-TYPE
+ SYNTAX IpAddress
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ipAddrEntry 1 }
+
+ ipAdEntIfIndex OBJECT-TYPE
+ SYNTAX INTEGER
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ipAddrEntry 2 }
+
+ ipAdEntNetMask OBJECT-TYPE
+ SYNTAX IpAddress
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ipAddrEntry 3 }
+
+ ipAdEntBcastAddr OBJECT-TYPE
+ SYNTAX INTEGER
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ipAddrEntry 4 }
+
+ ipAdEntReasmMaxSiz OBJECT-TYPE
+ SYNTAX INTEGER (0..65535)
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ipAddrEntry 5 }
+
+ -- the IP Routing table
+
+ ipRoutingTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF IpRouteEntry
+ ACCESS read-write
+ STATUS mandatory
+ ::= { ip 21 }
+
+
+
+IETF SNMP Working Group [Page 106]
+
+RFC 1158 MIB II May 1990
+
+
+ ipRouteEntry OBJECT-TYPE
+ SYNTAX IpRouteEntry
+ ACCESS read-write
+ STATUS mandatory
+ ::= { ipRoutingTable 1 }
+
+ IpRouteEntry ::= SEQUENCE {
+ ipRouteDest
+ IpAddress,
+ ipRouteIfIndex
+ INTEGER,
+ ipRouteMetric1
+ INTEGER,
+ ipRouteMetric2
+ INTEGER,
+ ipRouteMetric3
+ INTEGER,
+ ipRouteMetric4
+ INTEGER,
+ ipRouteNextHop
+ IpAddress,
+ ipRouteType
+ INTEGER,
+ ipRouteProto
+ INTEGER,
+ ipRouteAge
+ INTEGER,
+ ipRouteMask
+ IpAddress
+ }
+
+ ipRouteDest OBJECT-TYPE
+ SYNTAX IpAddress
+ ACCESS read-write
+ STATUS mandatory
+ ::= { ipRouteEntry 1 }
+
+ ipRouteIfIndex OBJECT-TYPE
+ SYNTAX INTEGER
+ ACCESS read-write
+ STATUS mandatory
+ ::= { ipRouteEntry 2 }
+
+ ipRouteMetric1 OBJECT-TYPE
+ SYNTAX INTEGER
+ ACCESS read-write
+ STATUS mandatory
+ ::= { ipRouteEntry 3 }
+
+
+
+IETF SNMP Working Group [Page 107]
+
+RFC 1158 MIB II May 1990
+
+
+ ipRouteMetric2 OBJECT-TYPE
+ SYNTAX INTEGER
+ ACCESS read-write
+ STATUS mandatory
+ ::= { ipRouteEntry 4 }
+
+ ipRouteMetric3 OBJECT-TYPE
+ SYNTAX INTEGER
+ ACCESS read-write
+ STATUS mandatory
+ ::= { ipRouteEntry 5 }
+
+ ipRouteMetric4 OBJECT-TYPE
+ SYNTAX INTEGER
+ ACCESS read-write
+ STATUS mandatory
+ ::= { ipRouteEntry 6 }
+
+ ipRouteNextHop OBJECT-TYPE
+ SYNTAX IpAddress
+ ACCESS read-write
+ STATUS mandatory
+ ::= { ipRouteEntry 7 }
+
+ ipRouteType OBJECT-TYPE
+ SYNTAX INTEGER {
+ other(1), -- none of the following
+
+ invalid(2), -- an invalidated route
+
+ -- route to directly
+ direct(3), -- connected
+ -- (sub-)network
+
+ -- route to a non-local
+ remote(4) -- host/network/
+ -- sub-network
+ }
+ ACCESS read-write
+ STATUS mandatory
+ ::= { ipRouteEntry 8 }
+
+ ipRouteProto OBJECT-TYPE
+ SYNTAX INTEGER {
+ other(1), -- none of the following
+
+ -- non-protocol
+ -- information
+
+
+
+IETF SNMP Working Group [Page 108]
+
+RFC 1158 MIB II May 1990
+
+
+ -- e.g., manually
+ local(2), -- configured entries
+
+ -- set via a network
+ netmgmt(3), -- management protocol
+
+ -- obtained via ICMP,
+ icmp(4), -- e.g., Redirect
+
+ -- the following are
+ -- gateway routing
+ -- protocols
+ egp(5),
+ ggp(6),
+ hello(7),
+ rip(8),
+ is-is(9),
+ es-is(10),
+ ciscoIgrp(11),
+ bbnSpfIgp(12),
+ ospf(13)
+ bgp(14)
+ }
+ ACCESS read-only
+ STATUS mandatory
+ ::= { ipRouteEntry 9 }
+
+ ipRouteAge OBJECT-TYPE
+ SYNTAX INTEGER
+ ACCESS read-write
+ STATUS mandatory
+ ::= { ipRouteEntry 10 }
+
+ ipRouteMask OBJECT-TYPE
+ SYNTAX IpAddress
+ ACCESS read-write
+ STATUS mandatory
+ ::= { ipRouteEntry 11 }
+
+ -- the IP Address Translation tables
+
+ ipNetToMediaTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF IpNetToMediaEntry
+ ACCESS read-write
+ STATUS mandatory
+ ::= { ip 22 }
+
+ ipNetToMediaEntry OBJECT-TYPE
+
+
+
+IETF SNMP Working Group [Page 109]
+
+RFC 1158 MIB II May 1990
+
+
+ SYNTAX IpNetToMediaEntry
+ ACCESS read-write
+ STATUS mandatory
+ ::= { ipNetToMediaTable 1 }
+
+ IpNetToMediaEntry ::= SEQUENCE {
+ ipNetToMediaIfIndex
+ INTEGER,
+ ipNetToMediaPhysAddress
+ OCTET STRING,
+ ipNetToMediaNetAddress
+ IpAddress,
+ ipNetoToMediaType
+ INTEGER
+ }
+
+ ipNetToMediaIfIndex OBJECT-TYPE
+ SYNTAX INTEGER
+ ACCESS read-write
+ STATUS mandatory
+ ::= { ipNetToMediaEntry 1 }
+
+ ipNetToMediaPhysAddress OBJECT-TYPE
+ SYNTAX OCTET STRING
+ ACCESS read-write
+ STATUS mandatory
+ ::= { ipNetToMediaEntry 2 }
+
+ ipNetToMediaNetAddress OBJECT-TYPE
+ SYNTAX IpAddress
+ ACCESS read-write
+ STATUS mandatory
+ ::= { ipNetToMediaEntry 3 }
+
+ ipNetToMediaType OBJECT-TYPE
+ SYNTAX INTEGER {
+ other(1), -- none of the following
+
+ invalid(2), -- an invalidated mapping
+ dynamic(3), -- connected (sub-)network
+
+ static(4)
+ }
+ ACCESS read-write
+ STATUS mandatory
+ ::= { ipNetToMediaEntry 4 }
+
+
+
+
+
+IETF SNMP Working Group [Page 110]
+
+RFC 1158 MIB II May 1990
+
+
+ -- the ICMP group
+
+ icmpInMsgs OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { icmp 1 }
+
+ icmpInErrors OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { icmp 2 }
+
+ icmpInDestUnreachs OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { icmp 3 }
+
+ icmpInTimeExcds OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { icmp 4 }
+
+ icmpInParmProbs OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { icmp 5 }
+
+ icmpInSrcQuenchs OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { icmp 6 }
+
+ icmpInRedirects OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { icmp 7 }
+
+ icmpInEchos OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+
+
+
+IETF SNMP Working Group [Page 111]
+
+RFC 1158 MIB II May 1990
+
+
+ ::= { icmp 8 }
+
+ icmpInEchoReps OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { icmp 9 }
+
+ icmpInTimestamps OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { icmp 10 }
+
+ icmpInTimestampReps OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { icmp 11 }
+
+ icmpInAddrMasks OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { icmp 12 }
+
+ icmpInAddrMaskReps OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { icmp 13 }
+
+ icmpOutMsgs OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { icmp 14 }
+
+ icmpOutErrors OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { icmp 15 }
+
+ icmpOutDestUnreachs OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+
+
+
+IETF SNMP Working Group [Page 112]
+
+RFC 1158 MIB II May 1990
+
+
+ ::= { icmp 16 }
+
+ icmpOutTimeExcds OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { icmp 17 }
+
+ icmpOutParmProbs OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { icmp 18 }
+
+ icmpOutSrcQuenchs OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { icmp 19 }
+
+ icmpOutRedirects OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { icmp 20 }
+
+ icmpOutEchos OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { icmp 21 }
+
+ icmpOutEchoReps OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { icmp 22 }
+
+ icmpOutTimestamps OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { icmp 23 }
+
+ icmpOutTimestampReps OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+
+
+
+IETF SNMP Working Group [Page 113]
+
+RFC 1158 MIB II May 1990
+
+
+ ::= { icmp 24 }
+
+ icmpOutAddrMasks OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { icmp 25 }
+
+ icmpOutAddrMaskReps OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { icmp 26 }
+
+
+ -- the TCP group
+
+ tcpRtoAlgorithm OBJECT-TYPE
+ SYNTAX INTEGER {
+ other(1), -- none of the following
+ constant(2), -- a constant rto
+ rsre(3), -- MIL-STD-1778,
+ -- Appendix B
+ vanj(4) -- Van Jacobson's
+ -- algorithm
+ }
+ ACCESS read-only
+ STATUS mandatory
+ ::= { tcp 1 }
+
+ tcpRtoMin OBJECT-TYPE
+ SYNTAX INTEGER
+ ACCESS read-only
+ STATUS mandatory
+ ::= { tcp 2 }
+
+ tcpRtoMax OBJECT-TYPE
+ SYNTAX INTEGER
+ ACCESS read-only
+ STATUS mandatory
+ ::= { tcp 3 }
+
+ tcpMaxConn OBJECT-TYPE
+ SYNTAX INTEGER
+ ACCESS read-only
+ STATUS mandatory
+ ::= { tcp 4 }
+
+
+
+
+IETF SNMP Working Group [Page 114]
+
+RFC 1158 MIB II May 1990
+
+
+ tcpActiveOpens OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { tcp 5 }
+
+ tcpPassiveOpens OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { tcp 6 }
+
+ tcpAttemptFails OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { tcp 7 }
+
+ tcpEstabResets OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { tcp 8 }
+
+ tcpCurrEstab OBJECT-TYPE
+ SYNTAX Gauge
+ ACCESS read-only
+ STATUS mandatory
+ ::= { tcp 9 }
+
+ tcpInSegs OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { tcp 10 }
+
+ tcpOutSegs OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { tcp 11 }
+
+ tcpRetransSegs OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { tcp 12 }
+
+
+
+
+IETF SNMP Working Group [Page 115]
+
+RFC 1158 MIB II May 1990
+
+
+ -- the TCP connections table
+
+ tcpConnTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF TcpConnEntry
+ ACCESS read-only
+ STATUS mandatory
+ ::= { tcp 13 }
+
+ tcpConnEntry OBJECT-TYPE
+ SYNTAX TcpConnEntry
+ ACCESS read-only
+ STATUS mandatory
+ ::= { tcpConnTable 1 }
+
+ TcpConnEntry ::= SEQUENCE {
+ tcpConnState
+ INTEGER,
+ tcpConnLocalAddress
+ IpAddress,
+ tcpConnLocalPort
+ INTEGER (0..65535),
+ tcpConnRemAddress
+ IpAddress,
+ tcpConnRemPort
+ INTEGER (0..65535)
+ }
+
+ tcpConnState OBJECT-TYPE
+ SYNTAX INTEGER {
+ closed(1),
+ listen(2),
+ synSent(3),
+ synReceived(4),
+ established(5),
+ finWait1(6),
+ finWait2(7),
+ closeWait(8),
+ lastAck(9),
+ closing(10),
+ timeWait(11)
+ }
+ ACCESS read-only
+ STATUS mandatory
+ ::= { tcpConnEntry 1 }
+
+ tcpConnLocalAddress OBJECT-TYPE
+ SYNTAX IpAddress
+ ACCESS read-only
+
+
+
+IETF SNMP Working Group [Page 116]
+
+RFC 1158 MIB II May 1990
+
+
+ STATUS mandatory
+ ::= { tcpConnEntry 2 }
+
+ tcpConnLocalPort OBJECT-TYPE
+ SYNTAX INTEGER (0..65535)
+ ACCESS read-only
+ STATUS mandatory
+ ::= { tcpConnEntry 3 }
+
+ tcpConnRemAddress OBJECT-TYPE
+ SYNTAX IpAddress
+ ACCESS read-only
+ STATUS mandatory
+ ::= { tcpConnEntry 4 }
+
+ tcpConnRemPort OBJECT-TYPE
+ SYNTAX INTEGER (0..65535)
+ ACCESS read-only
+ STATUS mandatory
+ ::= { tcpConnEntry 5 }
+
+ -- additional TCP variables
+
+ tcpInErrs OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { tcp 14 }
+
+ tcpOutRsts OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { tcp 15 }
+
+
+ -- the UDP group
+
+ udpInDatagrams OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { udp 1 }
+
+ udpNoPorts OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+
+
+
+IETF SNMP Working Group [Page 117]
+
+RFC 1158 MIB II May 1990
+
+
+ ::= { udp 2 }
+
+ udpInErrors OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { udp 3 }
+
+ udpOutDatagrams OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { udp 4 }
+
+ -- the UDP listener table
+
+ udpTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF UdpEntry
+ ACCESS read-only
+ STATUS mandatory
+ ::= { udp 5 }
+
+ udpEntry OBJECT-TYPE
+ SYNTAX UdpEntry
+ ACCESS read-only
+ STATUS mandatory
+ ::= { udpTable 1 }
+
+ UdpEntry ::= SEQUENCE {
+ udpLocalAddress
+ IpAddress,
+ udpLocalPort
+ INTEGER (0..65535)
+ }
+
+ udpLocalAddress OBJECT-TYPE
+ SYNTAX IpAddress
+ ACCESS read-only
+ STATUS mandatory
+ ::= { udpEntry 1 }
+
+ udpLocalPort OBJECT-TYPE
+ SYNTAX INTEGER (0..65535)
+ ACCESS read-only
+ STATUS mandatory
+ ::= { udpEntry 2 }
+
+
+
+
+
+IETF SNMP Working Group [Page 118]
+
+RFC 1158 MIB II May 1990
+
+
+ -- the EGP group
+
+ egpInMsgs OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { egp 1 }
+
+ egpInErrors OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { egp 2 }
+
+ egpOutMsgs OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { egp 3 }
+
+ egpOutErrors OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { egp 4 }
+
+ -- the EGP Neighbor table
+
+ egpNeighTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF EgpNeighEntry
+ ACCESS read-only
+ STATUS mandatory
+ ::= { egp 5 }
+
+ egpNeighEntry OBJECT-TYPE
+ SYNTAX EgpNeighEntry
+ ACCESS read-only
+ STATUS mandatory
+ ::= { egpNeighTable 1 }
+
+ EgpNeighEntry ::= SEQUENCE {
+ egpNeighState
+ INTEGER,
+ egpNeighAddr
+ IpAddress,
+ egpNeighAs
+ INTEGER,
+ egpNeighInMsgs
+
+
+
+IETF SNMP Working Group [Page 119]
+
+RFC 1158 MIB II May 1990
+
+
+ Counter,
+ egpNeighInErrs
+ Counter,
+ egpNeighOutMsgs
+ Counter,
+ egpNeighOutErrs
+ Counter,
+ egpNeighInErrMsgs
+ Counter,
+ egpNeighOutErrMsgs
+ Counter,
+ egpNeighStateUps
+ Counter,
+ egpNeighStateDowns
+ Counter,
+ egpNeighIntervalHello
+ INTEGER,
+ egpNeighIntervalPoll
+ INTEGER,
+ egpNeighMode
+ INTEGER,
+ egpNeighEventTrigger
+ INTEGER
+ }
+
+ egpNeighState OBJECT-TYPE
+ SYNTAX INTEGER {
+ idle(1),
+ acquisition(2),
+ down(3),
+ up(4),
+ cease(5)
+ }
+ ACCESS read-only
+ STATUS mandatory
+ ::= { egpNeighEntry 1 }
+
+ egpNeighAddr OBJECT-TYPE
+ SYNTAX IpAddress
+ ACCESS read-only
+ STATUS mandatory
+ ::= { egpNeighEntry 2 }
+
+ egpNeighAs OBJECT-TYPE
+ SYNTAX INTEGER
+ ACCESS read-only
+ STATUS mandatory
+ ::= { egpNeighEntry 3 }
+
+
+
+IETF SNMP Working Group [Page 120]
+
+RFC 1158 MIB II May 1990
+
+
+ egpNeighInMsgs OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { egpNeighEntry 4 }
+
+ egpNeighInErrs OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { egpNeighEntry 5 }
+
+ egpNeighOutMsgs OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { egpNeighEntry 6 }
+
+ egpNeighOutErrs OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { egpNeighEntry 7 }
+
+ egpNeighInErrMsgs OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { egpNeighEntry 8 }
+
+ egpNeighOutErrMsgs OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { egpNeighEntry 9 }
+
+ egpNeighStateUps OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { egpNeighEntry 10 }
+
+ egpNeighStateDowns OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { egpNeighEntry 11 }
+
+
+
+
+IETF SNMP Working Group [Page 121]
+
+RFC 1158 MIB II May 1990
+
+
+ egpNeighIntervalHello OBJECT-TYPE
+ SYNTAX INTEGER
+ ACCESS read-only
+ STATUS mandatory
+ ::= { egpNeighEntry 12 }
+
+ egpNeighIntervalPoll OBJECT-TYPE
+ SYNTAX INTEGER
+ ACCESS read-only
+ STATUS mandatory
+ ::= { egpNeighEntry 13 }
+
+ egpNeighMode OBJECT-TYPE
+ SYNTAX INTEGER {
+ active(1),
+ passive(2)
+ }
+ ACCESS read-only
+ STATUS mandatory
+ ::= { egpNeighEntry 14 }
+
+ egpNeighEventTrigger OBJECT-TYPE
+ SYNTAX INTEGER {
+ start(1),
+ stop(2)
+ }
+ ACCESS read-write
+ STATUS mandatory
+ ::= { egpNeighEntry 15 }
+
+ -- additional EGP variables
+
+ egpAs OBJECT-TYPE
+ SYNTAX INTEGER
+ ACCESS read-only
+ STATUS mandatory
+ ::= { egp 6 }
+
+
+ -- the Transmission group (empty at present)
+
+ -- the SNMP group
+
+ snmpInPkts OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { snmp 1 }
+
+
+
+IETF SNMP Working Group [Page 122]
+
+RFC 1158 MIB II May 1990
+
+
+ snmpOutPkts OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { snmp 2 }
+
+ snmpInBadVersions OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { snmp 3 }
+
+ snmpInBadCommunityNames OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { snmp 4 }
+
+ snmpInBadCommunityUses OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { snmp 5 }
+
+ snmpInASNParseErrs OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { snmp 6 }
+
+ snmpInBadTypes OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { snmp 7 }
+
+ snmpInTooBigs OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { snmp 8 }
+
+ snmpInNoSuchNames OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { snmp 9 }
+
+
+
+
+IETF SNMP Working Group [Page 123]
+
+RFC 1158 MIB II May 1990
+
+
+ snmpInBadValues OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { snmp 10 }
+
+ snmpInReadOnlys OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { snmp 11 }
+
+ snmpInGenErrs OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { snmp 12 }
+
+ snmpInTotalReqVars OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { snmp 13 }
+
+ snmpInTotalSetVars OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { snmp 14 }
+
+ snmpInGetRequests OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { snmp 15 }
+
+ snmpInGetNexts OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { snmp 16 }
+
+ snmpInSetRequests OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { snmp 17 }
+
+
+
+
+IETF SNMP Working Group [Page 124]
+
+RFC 1158 MIB II May 1990
+
+
+ snmpInGetResponses OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { snmp 18 }
+
+ snmpInTraps OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { snmp 19 }
+
+ snmpOutTooBigs OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { snmp 20 }
+
+ snmpOutNoSuchNames OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { snmp 21 }
+
+ snmpOutBadValues OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { snmp 22 }
+
+ snmpOutReadOnlys OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { snmp 23 }
+
+ snmpOutGenErrs OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { snmp 24 }
+
+ snmpOutGetRequests OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { snmp 25 }
+
+
+
+
+IETF SNMP Working Group [Page 125]
+
+RFC 1158 MIB II May 1990
+
+
+ snmpOutGetNexts OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { snmp 26 }
+
+ snmpOutSetRequests OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { snmp 27 }
+
+ snmpOutGetResponses OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { snmp 28 }
+
+ snmpOutTraps OBJECT-TYPE
+ SYNTAX Counter
+ ACCESS read-only
+ STATUS mandatory
+ ::= { snmp 29 }
+
+ snmpEnableAuthTraps OBJECT-TYPE
+ SYNTAX INTEGER {
+ enabled(1),
+ disabled(2)
+ }
+ ACCESS read-write
+ STATUS mandatory
+ ::= { snmp 30 }
+
+ END
+
+7. Identification of OBJECT instances for use with the SNMP
+
+ The names for all object types in the MIB are defined explicitly
+ either in the Internet-standard MIB or in other documents which
+ conform to the naming conventions of the SMI. The SMI requires that
+ conformant management protocols define mechanisms for identifying
+ individual instances of those object types for a particular network
+ element.
+
+ Each instance of any object type defined in the MIB is identified in
+ SNMP operations by a unique name called its "variable name." In
+ general, the name of an SNMP variable is an OBJECT IDENTIFIER of the
+ form x.y, where x is the name of a non-aggregate object type defined
+
+
+
+IETF SNMP Working Group [Page 126]
+
+RFC 1158 MIB II May 1990
+
+
+ in the MIB and y is an OBJECT IDENTIFIER fragment that, in a way
+ specific to the named object type, identifies the desired instance.
+
+ This naming strategy admits the fullest exploitation of the semantics
+ of the powerful SNMP get-next operator, because it assigns names for
+ related variables so as to be contiguous in the lexicographical
+ ordering of all variable names known in the MIB.
+
+ The type-specific naming of object instances is defined below for a
+ number of classes of object types. Instances of an object type to
+ which none of the following naming conventions are applicable are
+ named by OBJECT IDENTIFIERs of the form x.0, where x is the name of
+ said object type in the MIB definition.
+
+ For example, suppose one wanted to identify an instance of the
+ variable sysDescr. The object class for sysDescr is:
+
+ iso org dod internet mgmt mib system sysDescr
+ 1 3 6 1 2 1 1 1
+
+ Hence, the object type, x, would be 1.3.6.1.2.1.1.1 to which is
+ appended an instance sub-identifier of 0. That is, 1.3.6.1.2.1.1.1.0
+ identifies the one and only instance of sysDescr.
+
+7.1. ifTable Object Type Names
+
+ The name of a subnetwork interface, s, is the OBJECT IDENTIFIER value
+ of the form i, where i has the value of that instance of the ifIndex
+ object type associated with s. For each object type, t, for which
+ the defined name, n, has a prefix of ifEntry, an instance, i, of t is
+ named by an OBJECT IDENTIFIER of the form n.s, where s is the name of
+ the subnetwork interface about which i represents information.
+
+ For example, suppose one wanted to identify the instance of the
+ variable ifType associated with interface 2. Accordingly, ifType.2
+ would identify the desired instance.
+
+7.2. atTable Object Type Names
+
+ The name of an address translation entry, x, is an OBJECT IDENTIFIER
+ of the form s.1.a.b.c.d, such that s is the value of that instance of
+ the atIfIndex object type associated with x, the subidentifer "1"
+ signifies the translation of an IP protocol address, and a.b.c.d is
+ the IP address value (in the familiar "dot" notation) of that
+ instance of the atNetAddress object type associated with x.
+
+ For each object type, t, for which the defined name, n, has a prefix
+ of atEntry, an instance, i, of t is named by an OBJECT IDENTIFIER of
+
+
+
+IETF SNMP Working Group [Page 127]
+
+RFC 1158 MIB II May 1990
+
+
+ the form n.y, where y is the name of the address translation entry
+ about which i represents information.
+
+ For example, suppose one wanted to find the physical address of an
+ entry in the address translation table (ARP cache) associated with an
+ IP address of 89.1.1.42 and interface 3. Accordingly,
+ atPhysAddress.3.1.89.1.1.42 would identify the desired instance.
+
+7.3. ipAddrTable Object Type Names
+
+ The name of an IP-addressable network element, x, is the OBJECT
+ IDENTIFIER of the form a.b.c.d such that a.b.c.d is the value (in the
+ familiar "dot" notation) of that instance of the ipAdEntAddr object
+ type associated with x.
+
+ For each object type, t, for which the defined name, n, has a prefix
+ of ipAddrEntry, an instance, i, of t is named by an OBJECT IDENTIFIER
+ of the form n.y, where y is the name of the IP- addressable network
+ element about which i represents information.
+
+ For example, suppose one wanted to find the network mask of an entry
+ in the IP interface table associated with an IP address of 89.1.1.42.
+ Accordingly, ipAdEntNetMask.89.1.1.42 would identify the desired
+ instance.
+
+ At the option of the agent, multiple entries for the same IP address
+ may be visible. To realize this, the agent, while required to return
+ a single entry for an IP address, x, of the form n.y, may also return
+ information about other entries for the same IP address using the
+ form n.y.z, where z is a implementation-dependendent small, non-
+ negative integer. It is strongly recommended that the value of z
+ correspond to the value of ipAddrIfIndex for that entry.
+
+7.4. ipRoutingTable Object Type Names
+
+ The name of an IP route, x, is the OBJECT IDENTIFIER of the form
+ a.b.c.d such that a.b.c.d is the value (in the familiar "dot"
+ notation) of that instance of the ipRouteDest object type associated
+ with x.
+
+ For each object type, t, for which the defined name, n, has a prefix
+ of ipRoutingEntry, an instance, i, of t is named by an OBJECT
+ IDENTIFIER of the form n.y, where y is the name of the IP route about
+ which i represents information.
+
+ For example, suppose one wanted to find the next hop of an entry in
+ the IP routing table associated with the destination of 89.1.1.42.
+ Accordingly, ipRouteNextHop.89.1.1.42 would identify the desired
+
+
+
+IETF SNMP Working Group [Page 128]
+
+RFC 1158 MIB II May 1990
+
+
+ instance.
+
+ At the option of the agent, multiple routes to the same destination
+ may be visible. To realize this, the agent, while required to return
+ a single entry for an IP route, x, of the form n.y, may also return
+ information about other routes to the same destination using the form
+ n.y.z, where z is a implementation-dependendent small, non-negative
+ integer.
+
+7.5. ipNetToMediaTable Object Type Names
+
+ The name of a cached IP address, x, is an OBJECT IDENTIFIER of the
+ form s.a.b.c.d, such that s is the value of that instance of the
+ ipNetToMediaIfIndex object type associated with the entry and a.b.c.d
+ is the value (in the familiar "dot" notation) of the
+ ipNetToMediaNetAddress object type associated with x.
+
+ For each object type, t, for which the defined name, n, has a prefix
+ of ipNetToMediaEntry, an instance, i, of t is named by an OBJECT
+ IDENTIFIER of the form n.y, where y is the name of the cached IP
+ address about which i represents information.
+
+ For example, suppose one wanted to find the media address of an entry
+ in the address translation table associated with a IP address of
+ 192.52.180.1 and interface 3. Accordingly,
+ ipNetToMediaPhysAddress.3.192.52.180.1 would identify the desired
+ instance.
+
+7.6. tcpConnTable Object Type Names
+
+ The name of a TCP connection, x, is the OBJECT IDENTIFIER of the form
+ a.b.c.d.e.f.g.h.i.j such that a.b.c.d is the value (in the familiar
+ "dot" notation) of that instance of the tcpConnLocalAddress object
+ type associated with x and such that f.g.h.i is the value (in the
+ familiar "dot" notation) of that instance of the tcpConnRemoteAddress
+ object type associated with x and such that e is the value of that
+ instance of the tcpConnLocalPort object type associated with x and
+ such that j is the value of that instance of the tcpConnRemotePort
+ object type associated with x.
+
+ For each object type, t, for which the defined name, n, has a prefix
+ of tcpConnEntry, an instance, i, of t is named by an OBJECT
+ IDENTIFIER of the form n.y, where y is the name of the TCP connection
+ about which i represents information.
+
+ For example, suppose one wanted to find the state of a TCP connection
+ between the local address of 89.1.1.42 on TCP port 21 and the remote
+ address of 10.0.0.51 on TCP port 2059. Accordingly,
+
+
+
+IETF SNMP Working Group [Page 129]
+
+RFC 1158 MIB II May 1990
+
+
+ tcpConnState.89.1.1.42.21.10.0.0.51.2059 would identify the desired
+ instance.
+
+7.7. udpTable Object Type Names
+
+ The name of a UDP listener, x, is the OBJECT IDENTIFIER of the form
+ a.b.c.d.e. such that a.b.c.d is the value (in the familiar "dot"
+ notation) of that instance of the udpLocalAddress object type
+ associated with x and such that e is the value of that instance of
+ the udpLocalPort object type associated with x.
+
+ For each object type, t, for which the defined name, n, has a prefix
+ of udpEntry, an instance, i, of t is named by an OBJECT IDENTIFIER of
+ the form n.y, where y is the name of the UDP listener about which i
+ represents information.
+
+ For example, suppose one wanted to determine if a UDP listener was
+ present at the local address of 89.1.1.42 on UDP port 21.
+ Accordingly, a successful retrieval of either
+ udpLocalAddress.89.1.1.42.21 or udpLocalPort.89.1.1.42.21 would
+ indicate this.
+
+7.8. egpNeighTable Object Type Names
+
+ The name of an EGP neighbor, x, is the OBJECT IDENTIFIER of the form
+ a.b.c.d such that a.b.c.d is the value (in the familiar "dot"
+ notation) of that instance of the egpNeighAddr object type associated
+ with x.
+
+ For each object type, t, for which the defined name, n, has a prefix
+ of egpNeighEntry, an instance, i, of t is named by an OBJECT
+ IDENTIFIER of the form n.y, where y is the name of the EGP neighbor
+ about which i represents information.
+
+ For example, suppose one wanted to find the neighbor state for the IP
+ address of 89.1.1.42. Accordingly, egpNeighState.89.1.1.42 would
+ identify the desired instance.
+
+8. Acknowledgements
+
+ This document was produced by the SNMP Working Group:
+
+ Karl Auerbach, Epilogue Technology
+ David Bridgham, Epilogue Technology
+ Brian Brown, Synoptics
+ John Burress, Wellfleet
+ Jeffrey D. Case, University of Tennessee at Knoxville
+ James R. Davin, MIT-LCS
+
+
+
+IETF SNMP Working Group [Page 130]
+
+RFC 1158 MIB II May 1990
+
+
+ Mark S. Fedor, PSI, Inc.
+ Stan Froyd, ACC
+ Satish Joshi, Synoptics
+ Ken Key, University of Tennessee at Knoxville
+ Gary Malkin, Proteon
+ Randy Mayhew, University of Tennessee at Knoxville
+ Keith McCloghrie, Hughes LAN Systems
+ Marshall T. Rose, PSI, Inc. (chair)
+ Greg Satz, cisco
+ Martin Lee Schoffstall, PSI, Inc.
+ Bob Stewart, Xyplex
+ Geoff Thompson, Synoptics
+ Bill Versteeg, Network Research Corporation
+ Wengyik Yeong, PSI, Inc.
+
+ In addition, the comments of the following individuals are also
+ acknolwedged:
+
+ Craig A. Finseth, Minnesota Supercomputer Center, Inc.
+ Jeffrey C. Honig, Cornell University Theory Center
+ Philip R. Karn, Bellcore
+ David Waitzman, BBN
+
+9. References
+
+ [1] Cerf, V., "IAB Recommendations for the Development of Internet
+ Network Management Standards", RFC 1052, IAB, April 1988.
+
+ [2] Rose, M., and K. McCloghrie, "Structure and Identification of
+ Management Information for TCP/IP-based internets", RFC 1065,
+ TWG, August 1988.
+
+ [3] McCloghrie K., and M. Rose,"Management Information Base for
+ Network Management of TCP/IP-based internets", RFC 1066, TWG,
+ August 1988.
+
+ [4] Cerf, V., "Report of the Second Ad Hoc Network Management Review
+ Group", RFC 1109, IAB, August 1989.
+
+ [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "A Simple
+ Network Management Protocol (SNMP)", RFC 1098, University of
+ Tennessee at Knoxville, NYSERNet, Inc., Rensselaer Polytechnic
+ Institute, MIT Laboratory for Computer Science, April 1989.
+
+ [6] Warrier, U., and L. Besaw, "Common Management Information
+ Services and Protocol over TCP/IP (CMOT)", RFC 1095, Unisys
+ Corporation, Hewlett-Packard, April 1989.
+
+
+
+
+IETF SNMP Working Group [Page 131]
+
+RFC 1158 MIB II May 1990
+
+
+ [7] Postel, J., "Telnet Protocol Specification", RFC 854,
+ USC/Information Sciences Institute, May 1983.
+
+ [8] Satz, G., "Experimental MIB Objects for the CLNP", Internet
+ Working Group Request for Comments draft. Network Information
+ Center, SRI International, Menlo Park, California, (in
+ preparation).
+
+ [9] Information processing systems - Open Systems Interconnection,
+ "Specification of Abstract Syntax Notation One (ASN.1)",
+ International Organization for Standardization, International
+ Standard 8824, December 1987.
+
+ [10] Information processing systems - Open Systems Interconnection,
+ "Specification of Basic Encoding Rules for Abstract Notation One
+ (ASN.1)", International Organization for Standardization.
+ International Standard 8825, December 1987.
+
+ [11] Jacobson, V., "Congestion Avoidance and Control", SIGCOMM 1988,
+ Stanford, California.
+
+ [12] Hagens, R., Hall, N., and M. Rose, "Use of the Internet as a
+ subnetwork for experimentation with the OSI network layer",
+ February, 1989.
+
+ [13] Rose, M., and K. McCloghrie, "Structure and Identification of
+ Management Information for TCP/IP-based Internets", RFC 1155,
+ Performance Systems International and Hughes LAN Systems, May
+ 1990.
+
+ [14] Case, J., Fedor, M., Schoffstall, M., and J. Davin, The Simple
+ Network Management Protocol", RFC 1157, University of Tennessee
+ at Knoxville, Performance Systems International, Performance
+ Systems International, and the MIT Laboratory for Computer
+ Science, May 1990.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+IETF SNMP Working Group [Page 132]
+
+RFC 1158 MIB II May 1990
+
+
+10. Security Considerations
+
+ Security issues are not discussed in this memo.
+
+11. Author's Address:
+
+ Marshall T. Rose
+ PSI, Inc.
+ PSI California Office
+ P.O. Box 391776
+ Mountain View, CA 94039
+
+ Phone: (415) 961-3380
+
+ Email: mrose@PSI.COM
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+IETF SNMP Working Group [Page 133]
+ \ No newline at end of file