|
DataMuseum.dkPresents historical artifacts from the history of: DKUUG/EUUG Conference tapes |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about DKUUG/EUUG Conference tapes Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - downloadIndex: D T
Length: 231086 (0x386ae)
Types: TextFile
Names: »DRAFT-IETF-SNMP-MIB2-00.TXT.1«
└─⟦9ae75bfbd⟧ Bits:30007242 EUUGD3: Starter Kit
└─⟦this⟧ »EurOpenD3/documents/nic.ddn.mil/DRAFT-IETF-SNMP-MIB2-00.TXT.1«
COMMENTS SHOULD BE SENT TO: mrose@nisc.nyser.net
RFC draft MIB-II September 1989
Management Information Base for Network Management
of TCP/IP-based internets
Sat Sep 30 07:39:28 1989
SNMP Working Group
M.T. Rose (editor)
NYSERNet, Inc.
165 Jordan Road
Troy, NY 12180
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 1065) along with the network
management protocol (RFC 1098) 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 memo specifies a standard for the Internet community.
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.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 1]
\f
RFC draft MIB-II September 1989
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) is 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
Management Information for TCP/IP-based internets, RFC 1065,
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 1098 [5], 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 of managed objects defined
here, has been derived by taking only those elements which are
considered essential. Since such elements are essential,
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 2]
\f
RFC draft MIB-II September 1989
there is no need to allow the implementation of individual
objects, to be optional. Rather, all compliant
implementations will contain all applicable (see below)
objects defined in this memo.
This approach of taking only the essential objects is NOT
restrictive, since the SMI defined in the companion memo
provides three extensibility mechanisms: one, the addition of
new standard objects through the definitions of new versions
of the MIB; two, the addition of widely-available but non-
standard objects through the experimental subtree; and three,
the addition of private objects through the enterprises
subtree. Such additional objects can not only be used for
vendor-specific elements, but also for experimentation as
required to further the knowledge of which other objects are
essential.
The design of MIB-II is heavily influenced by the first
extensibility mechanism. Several new variables have been
added based on operational experience and need. Based on
this, the criteria for including an object in MIB-II, is
remarkably similar to the MIB-I criteria:
1) An object needed to be essential for either fault or
configuration management.
2) Only weak control objects were permitted (by weak, it
is meant that tampering with them can do only limited
damage). This criterion reflects the fact that the
current management protocols are not sufficiently secure
to do more powerful control operations.
3) Evidence of current use and utility was required.
4) In MIB-I, an attempt was made to limit the number of
objects to about 100 to make it easier for vendors to
fully instrument their software. In MIB-II, this limit
was raised given the wide technological base now
implementing MIB-I.
5) To avoid redundant variables, it was required that no
object be included that can be derived from others in the
MIB.
6) Implementation specific objects (e.g., for BSD UNIX)
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 3]
\f
RFC draft MIB-II September 1989
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.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 4]
\f
RFC draft MIB-II September 1989
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.
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. Auxiliary Objects
Operational experience with MIB-I and the SNMP, has lead to a
need for a new designation for some MIB objects: "auxiliary".
A auxiliary object in the MIB is one which is used solely as
an index to a table object.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 5]
\f
RFC draft MIB-II September 1989
For example, the ifIndex object is used as an index to the
ifTable table. There is no useful reason for inspecting or
altering the value of the ifIndex object. However, when
walking the entire object tree using the powerful SNMP get-
next operator, many such queries are generated and answered,
e.g., if one were to request the value of the ifIndex object
for the interface whose ifIndex object equaled 5, one would
expect a reply that reported that the interface with an
ifIndex of 5 had an ifIndex of 5! This information is not
likely to be of great practical value.
It should be noted that these objects continue to be valuable
as tabular indices; and, these objects were originally defined
to assist with access methodologies utilized by other network
management protocols (e.g., CMOT [6]). Although the
guidelines given in RFC1109 explicitly allow the MIB to
diverge between network management protocols, it may be
desirable to retain this compatibility for the long-term.
Consequently, the auxiliary status is now defined: such
objects are excused as operands from those operations which do
not require their existence. Specifically, such objects need
not be lexicographically considered by the powerful SNMP get-
next operator.
3.3. 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 [7] (pages 10-11).
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
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 6]
\f
RFC draft MIB-II September 1989
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.4. The System Group
Two new objects are added to this group:
sysContact
sysName
These provide contact and administrative information regarding
the managed node.
3.5. 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 has been changed accordingly.
In addition, two new variables have been added to the
Interfaces table:
ifOutRetries
ifOutSuccRetries
In addition, several new values have been added to the ifType
variable:
terminalServer-asyncPort(23)
softwareLoopback(24)
eon(25)
ethernet-3Mbit(26)
nsip(27)
slip(28)
The index to the ifTable has been declared auxiliary.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 7]
\f
RFC draft MIB-II September 1989
3.6. 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 two
address translation tables inside each network protocol group.
That is, the IP group will contain two address translation
tables, one for going from IP addresses to physical addresses,
and the other for going from physical addresses to IP
addresses. Similarly, when a document defining MIB objects
for the CLNP is produced (e.g., [8]), it will also contain two
tables.
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.
In the meantime, the indices to the atTable are declared to be
auxiliary.
3.7. The IP Group
Two new objects are added to this group:
ipNetToMediaTable
ipMediaToNetTable
These are the address translation tables for the IP group.
In addition, there is a new variable,
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 8]
\f
RFC draft MIB-II September 1989
ipAdEntReasmMaxSize
which keeps track of the largest IP datagram that can be re-
assembled on a particular interface.
The access attribute of the variable ipForwarding has been
changed from read-only to read-write.
Finally, the definition of the variable ipAdEntIfIndex in the
ipAddrTable has been changed to represent a set of interfaces
applicable to a particular IP address, rather than a single
interface.
3.8. The ICMP Group
There are no changes to this group.
3.9. The TCP Group
It has been noted that the current method for defining tables
result in redundant information being returned. The redundant
entries in the TCP table are declared auxiliary.
3.10. The UDP Group
A new table:
udpTable
is added.
3.11. 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, a new variable is added:
egpAs
which gives the autonomous system associated with this EGP
entity.
The index to the EGP table is declared auxiliary.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 9]
\f
RFC draft MIB-II September 1989
3.12. 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 }
Under this tree are several subtrees, position by their
correspondent number in the ifType type, e.g.,
ethernet-csmacd OBJECT IDENTIFIER ::= { transmission 6 }
iso88025-tokenRing OBJECT IDENTIFIER ::= { transmission 9 }
t1-carrier OBJECT IDENTIFIER ::= { transmission 18 }
MIB-II does not define all subtrees for all possible values of
ifType. At present, only the three named above are defined.
It should be noted that the transmission group is
complementary to the interfaces group.
3.13. 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 }
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 10]
\f
RFC draft MIB-II September 1989
4. Objects
Managed objects are accessed via a virtual information store,
termed 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
in 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 of ASN.1 [10], subject to the additional
requirements imposed by the SNMP [5].
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
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 11]
\f
RFC draft MIB-II September 1989
- 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 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:
One of read-only, read-write, write-only, or
not-accessible.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 12]
\f
RFC draft MIB-II September 1989
Status:
One of mandatory, optional, obsolete, deprecated, or
auxiliary. Use of either deprecated or auxiliary implies
mandatory status.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 13]
\f
RFC draft MIB-II September 1989
5. Object Definitions
RFCxxxx-MIB { iso org(3) dod(6) internet(1) mgmt(2) 2 }
DEFINITIONS ::= BEGIN
IMPORTS
mgmt, OBJECT-TYPE, NetworkAddress, IpAddress,
Counter, Gauge, TimeTicks
FROM RFC1065-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
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 14]
\f
RFC draft MIB-II September 1989
5.1. The System Group
Implementation of the System group is mandatory for all
systems.
OBJECT:
-------
sysDescr { system 1 }
Syntax:
DisplayString
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.
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.42, it could assign the identifier
1.3.6.1.4.1.42.1.1 to its "Fred Router".
Access:
read-only.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 15]
\f
RFC draft MIB-II September 1989
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
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 }
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 16]
\f
RFC draft MIB-II September 1989
Syntax:
DisplayString
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.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 17]
\f
RFC draft MIB-II September 1989
5.2. The Interfaces Group
Implementation of the Interfaces group is mandatory for all
systems.
OBJECT:
-------
ifNumber { interfaces 1 }
Syntax:
INTEGER
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.
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-write.
Status:
mandatory.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 18]
\f
RFC draft MIB-II September 1989
OBJECT:
-------
ifEntry { ifTable 1 }
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
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 19]
\f
RFC draft MIB-II September 1989
Counter,
ifOutQLen
Gauge,
ifOutRetries
Counter,
ifOutSuccRetries
Counter
}
Definition:
An interface entry containing objects at the subnetwork
layer and below for a particular interface.
Access:
read-write.
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:
auxiliary.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 20]
\f
RFC draft MIB-II September 1989
OBJECT:
-------
ifDescr { ifEntry 2 }
Syntax:
DisplayString
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.
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
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 21]
\f
RFC draft MIB-II September 1989
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
}
Definition:
The type of interface, distinguished according to the
physical/link/network protocol(s) immediately "below" IP
in the protocol stack.
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 IP datagrams,
this is the size of the largest IP datagram that can be
sent on the interface.
Access:
read-only.
Status:
mandatory.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 22]
\f
RFC draft MIB-II September 1989
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.
OBJECT:
-------
ifPhysAddress { ifEntry 6 }
Syntax:
OCTET STRING
Definition:
The interface's address at the protocol layer immediately
"below" IP 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 }
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 23]
\f
RFC draft MIB-II September 1989
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 }
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 }
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 24]
\f
RFC draft MIB-II September 1989
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
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.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 25]
\f
RFC draft MIB-II September 1989
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.
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.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 26]
\f
RFC draft MIB-II September 1989
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
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
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 27]
\f
RFC draft MIB-II September 1989
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.
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.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 28]
\f
RFC draft MIB-II September 1989
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
Definition:
The number of outbound packets that could not be
transmitted because of errors.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 29]
\f
RFC draft MIB-II September 1989
ifOutQLen { ifEntry 21 }
Syntax:
Gauge
Definition:
The length of the output packet queue (in packets).
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
ifOutRetries { ifEntry 22 }
Syntax:
Counter
Definition:
The number of re-transmission attempts made.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
ifOutSuccRetries { ifEntry 23 }
Syntax:
Counter
Definition:
The number of occasions when transmission occurred
successfully after one or more transmission retries.
Access:
read-only.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 30]
\f
RFC draft MIB-II September 1989
Status:
mandatory.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 31]
\f
RFC draft MIB-II September 1989
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.
Status:
deprecated.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 32]
\f
RFC draft MIB-II September 1989
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.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 33]
\f
RFC draft MIB-II September 1989
Status:
deprecated.
OBJECT:
-------
atPhysAddress { atEntry 2 }
Syntax:
OCTET STRING
Definition:
The media-dependent "physical" address.
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.
Status:
deprecated.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 34]
\f
RFC draft MIB-II September 1989
5.4. The IP Group
Implementation of the IP group is mandatory for all systems.
OBJECT:
-------
ipForwarding { ip 1 }
Syntax:
INTEGER {
gateway(1), -- entity forwards datagrams
host(2) -- entity does NOT forward datagrams
}
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; 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.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 35]
\f
RFC draft MIB-II September 1989
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 }
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 36]
\f
RFC draft MIB-II September 1989
Syntax:
Counter
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:
-------
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 37]
\f
RFC draft MIB-II September 1989
ipInUnknownProtos { ip 7 }
Syntax:
Counter
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
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 38]
\f
RFC draft MIB-II September 1989
Definition:
The total number of input datagrams successfully
delivered to IP user-protocols (including ICMP).
Access:
read-only.
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.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 39]
\f
RFC draft MIB-II September 1989
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
ipOutNoRoutes { ip 12 }
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.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 40]
\f
RFC draft MIB-II September 1989
Status:
mandatory.
OBJECT:
-------
ipReasmReqds { ip 14 }
Syntax:
Counter
Definition:
The number of IP fragments received which needed to be
reassembled at this entity.
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
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 41]
\f
RFC draft MIB-II September 1989
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.
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.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 42]
\f
RFC draft MIB-II September 1989
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.
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.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 43]
\f
RFC draft MIB-II September 1989
Status:
mandatory.
OBJECT:
-------
ipAddrEntry { ipAddrTable 1 }
Syntax:
IpAddrEntry ::= SEQUENCE {
ipAdEntAddr
IpAddress,
ipAdEntIfIndex
INTEGER,
ipAdEntNetMask
IpAddress,
ipAdEntBcastAddr
INTEGER,
ipAdEntReasmMaxSize
INTEGER (0..65535)
}
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.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 44]
\f
RFC draft MIB-II September 1989
Access:
read-only.
Status:
auxiliary.
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 idnex is the
same interface as identified by the same value of
ifIndex.
Access:
read-only.
Status:
mandatory.
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.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 45]
\f
RFC draft MIB-II September 1989
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.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
ipAdEntReasmMaxSize { ipAddrEntry 5 }
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.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 46]
\f
RFC draft MIB-II September 1989
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
INTEGER,
ipRouteMetric2
INTEGER,
ipRouteMetric3
INTEGER,
ipRouteMetric4
INTEGER,
ipRouteNextHop
IpAddress,
ipRouteType
INTEGER,
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 47]
\f
RFC draft MIB-II September 1989
ipRouteProto
INTEGER,
ipRouteAge
INTEGER
}
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 such default routes 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.
Access:
read-write.
Status:
auxiliary.
OBJECT:
-------
ipRouteIfIndex { ipRouteEntry 2 }
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 48]
\f
RFC draft MIB-II September 1989
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.
OBJECT:
-------
ipRouteMetric2 { ipRouteEntry 4 }
Syntax:
INTEGER
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 49]
\f
RFC draft MIB-II September 1989
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
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.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 50]
\f
RFC draft MIB-II September 1989
Access:
read-write.
Status:
mandatory.
OBJECT:
-------
ipRouteNextHop { ipRouteEntry 7 }
Syntax:
IpAddress
Definition:
The IP address of the next hop of this route.
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
}
Definition:
The type of route.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 51]
\f
RFC draft MIB-II September 1989
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),
es-is(10),
ciscoIgrp(11),
bbnSpfIgp(12),
ospf(13)
}
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.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 52]
\f
RFC draft MIB-II September 1989
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.
5.4.3. The IP Address Translation Tables
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
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 53]
\f
RFC draft MIB-II September 1989
Definition:
The IP Address Translation table used for mapping from IP
addresses to physical addresses.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
IpNetToMediaEntry { ipNetToMediaTable 1 }
Syntax:
IpNetToMediaEntry ::= SEQUENCE {
ipNetToMediaIfIndex
INTEGER,
ipNetToMediaPhysAddress
OCTET STRING,
ipNetToMediaIpAddress
IpAddress
}
Definition:
Each entry contains one IpAddress to "physical" address
equivalence.
Access:
read-only.
Status:
mandatory.
We now consider the individual components of each IP Address
Translation table entry:
OBJECT:
-------
ipNetToMediaIfIndex { ipNetToMediaEntry 1 }
Syntax:
INTEGER
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 54]
\f
RFC draft MIB-II September 1989
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-only.
Status:
auxiliary.
OBJECT:
-------
ipNetToMediaPhysAddress { ipNetToMediaEntry 2 }
Syntax:
OCTET STRING
Definition:
The media-dependent "physical" address.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
ipNetToMediaIpAddress { ipNetToMediaEntry 3 }
Syntax:
NetworkAddress
Definition:
The IpAddress corresponding to the media-dependent
"physical" address.
Access:
read-only.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 55]
\f
RFC draft MIB-II September 1989
Status:
auxiliarly.
OBJECT:
-------
ipMediaToNetTable { ip 23 }
Syntax:
SEQUENCE OF IpMediaToNetEntry
Definition:
The IP Address Translation table used for mapping from
physical addresses to IP addresses.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
IpMediaToNetEntry { ipMediaToNetTable 1 }
Syntax:
IpMediaToNetEntry ::= SEQUENCE {
ipMediaToNetIfIndex
INTEGER,
ipMediaToNetNetAddress
IpAddress,
ipMediaToNetPhysAddress
OCTET STRING
}
Definition:
Each entry contains one IpAddress to "physical" address
equivalence.
Access:
read-only.
Status:
mandatory.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 56]
\f
RFC draft MIB-II September 1989
We now consider the individual components of each IP Address
Translation table entry:
OBJECT:
-------
ipMediaToNetIfIndex { ipMediaToNetEntry 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-only.
Status:
auxiliarly.
OBJECT:
-------
ipMediaToNetNetAddress { ipMediaToNetEntry 2 }
Syntax:
NetworkAddress
Definition:
The IpAddress corresponding to the media-dependent
"physical" address.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
ipMediaToNetPhysAddress { ipMediaToNetEntry 3 }
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 57]
\f
RFC draft MIB-II September 1989
Syntax:
OCTET STRING
Definition:
The media-dependent "physical" address.
Access:
read-only.
Status:
auxiliary.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 58]
\f
RFC draft MIB-II September 1989
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.
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.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 59]
\f
RFC draft MIB-II September 1989
OBJECT:
-------
icmpInDestUnreachs { icmp 3 }
Syntax:
Counter
Definition:
The number of ICMP Destination Unreachable messages
received.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
icmpInTimeExcds { icmp 4 }
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.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 60]
\f
RFC draft MIB-II September 1989
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.
OBJECT:
-------
icmpInRedirects { icmp 7 }
Syntax:
Counter
Definition:
The number of ICMP Redirect messages received.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
icmpInEchos { icmp 8 }
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 61]
\f
RFC draft MIB-II September 1989
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.
Status:
mandatory.
OBJECT:
-------
icmpInTimestamps { icmp 10 }
Syntax:
Counter
Definition:
The number of ICMP Timestamp (request) messages received.
Access:
read-only.
Status:
mandatory.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 62]
\f
RFC draft MIB-II September 1989
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.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
icmpInAddrMaskReps { icmp 13 }
Syntax:
Counter
Definition:
The number of ICMP Address Mask Reply messages received.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 63]
\f
RFC draft MIB-II September 1989
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 }
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.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 64]
\f
RFC draft MIB-II September 1989
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.
Status:
mandatory.
OBJECT:
-------
icmpOutParmProbs { icmp 18 }
Syntax:
Counter
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 65]
\f
RFC draft MIB-II September 1989
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
redirects.
Access:
read-only.
Status:
mandatory.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 66]
\f
RFC draft MIB-II September 1989
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 }
Syntax:
Counter
Definition:
The number of ICMP Timestamp (request) messages sent.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 67]
\f
RFC draft MIB-II September 1989
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.
OBJECT:
-------
icmpOutAddrMaskReps { icmp 26 }
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 68]
\f
RFC draft MIB-II September 1989
Syntax:
Counter
Definition:
The number of ICMP Address Mask Reply messages sent.
Access:
read-only.
Status:
mandatory.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 69]
\f
RFC draft MIB-II September 1989
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.
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
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 70]
\f
RFC draft MIB-II September 1989
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.
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
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 71]
\f
RFC draft MIB-II September 1989
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.
Access:
read-only.
Status:
mandatory.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 72]
\f
RFC draft MIB-II September 1989
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.
OBJECT:
-------
tcpCurrEstab { tcp 9 }
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 73]
\f
RFC draft MIB-II September 1989
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.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 74]
\f
RFC draft MIB-II September 1989
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.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 75]
\f
RFC draft MIB-II September 1989
Status:
mandatory.
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),
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 76]
\f
RFC draft MIB-II September 1989
established(5),
finWait1(6),
finWait2(7),
closeWait(8),
lastAck(9),
closing(10),
timeWait(11)
}
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.
Access:
read-only.
Status:
auxiliary.
OBJECT:
-------
tcpConnLocalPort { tcpConnEntry 3 }
Syntax:
INTEGER (0..65535)
Definition:
The local port number for this TCP connection.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 77]
\f
RFC draft MIB-II September 1989
Access:
read-only.
Status:
auxiliary.
OBJECT:
-------
tcpConnRemAddress { tcpConnEntry 4 }
Syntax:
IpAddress
Definition:
The remote IP address for this TCP connection.
Access:
read-only.
Status:
auxiliary.
OBJECT:
-------
tcpConnRemPort { tcpConnEntry 5 }
Syntax:
INTEGER (0..65535)
Definition:
The remote port number for this TCP connection.
Access:
read-only.
Status:
auxiliary.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 78]
\f
RFC draft MIB-II September 1989
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.
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 }
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 79]
\f
RFC draft MIB-II September 1989
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.
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
current accepting datagrams.
OBJECT:
-------
udpTable { udp 5 }
Syntax:
SEQUENCE OF UdpEntry
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 80]
\f
RFC draft MIB-II September 1989
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),
udpListener
DisplayString
}
Definition:
Information about a particular current UDP listener.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
udpLocalAddress { udpEntry 1 }
Syntax:
IpAddress
Definition:
The local IP address for this UDP listener.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 81]
\f
RFC draft MIB-II September 1989
Access:
read-only.
Status:
auxiliary.
OBJECT:
-------
udpLocalPort { udpEntry 2 }
Syntax:
INTEGER (0..65535)
Definition:
The local port number for this UDP listener.
Access:
read-only.
Status:
auxiliary.
OBJECT:
-------
udpListener { udpEntry 3 }
Syntax:
DisplayString
Definition:
The (system-specific) identification of the UDP listener
as a textual string.
Access:
read-only.
Status:
mandatory.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 82]
\f
RFC draft MIB-II September 1989
5.8. The EGP Group
Implementation of the EGP group is mandatory for all systems
which implement the EGP.
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 }
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 83]
\f
RFC draft MIB-II September 1989
Syntax:
Counter
Definition:
The total number of locally generated EGP messages.
Access:
read-only.
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
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 84]
\f
RFC draft MIB-II September 1989
Definition:
The EGP neighbor table.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
egpNeighEntry { egpNeighTable 1 }
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,
egpNeighMode
INTEGER
}
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 85]
\f
RFC draft MIB-II September 1989
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:
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 }
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 86]
\f
RFC draft MIB-II September 1989
Syntax:
IpAddress
Definition:
The IP address of this entry's EGP neighbor.
Access:
read-only.
Status:
auxiliary.
OBJECT:
-------
egpNeighAs { egpNeighEntry 3 }
Syntax:
INTEGER
Definition:
The autonomous system of this EGP peer. Zero should be
specified if the AS 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.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 87]
\f
RFC draft MIB-II September 1989
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.
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 }
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 88]
\f
RFC draft MIB-II September 1989
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
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.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 89]
\f
RFC draft MIB-II September 1989
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.
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:
-------
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 90]
\f
RFC draft MIB-II September 1989
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:
-------
egpNeighMode { egpNeighEntry 13 }
Syntax:
INTEGER {
passive(1),
active(2)
}
Definition:
The polling mode of this EGP entity, either passive or
active.
Access:
read-only.
Status:
mandatory.
5.8.2. Additional EGP variables
OBJECT:
-------
egpAs { egp 6 }
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 91]
\f
RFC draft MIB-II September 1989
Syntax:
INTEGER
Definition:
The autonomous system of this EGP entity.
Access:
read-only.
Status:
mandatory.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 92]
\f
RFC draft MIB-II September 1989
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.
Each subtree under the transmission group takes its position
from its correspondent number in the ifType type. At present,
23 such values are possible. In MIB-II however, only three
subtrees are defined.
5.9.1. Ethernet transmission type The Ethernet status table
contains variables useful in examining statistics gathered by
the ethernet interfaces attached to the system.
OBJECT:
-------
ethernetStats { ethernet-csmacd 1 }
Syntax:
SEQUENCE of EthernetEntry
Definition:
A table containing ethernet information.
Access:
read-only.
Status:
mandatory.
OBJECT:
ethernetEntry { ethernetStats 1 }
Syntax:
EthernetEntry ::= SEQUENCE {
etherIndex
INTEGER,
etherCRCErrs
Counter,
etherAlignErrs
Counter,
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 93]
\f
RFC draft MIB-II September 1989
etherOutColls
Counter,
etherSpuriousIntrs
Counter,
etherJabberConds
Counter,
etherCarrierLosts
Counter,
etherHeartBeatErrs
Counter,
etherRunts
Counter,
etherGiants
Counter
}
Definition:
The statistics table. An entry in this table is uniquely
identified by the value of the etherIndex variable
associated with the interface to which the statistics
refer.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
etherIndex { ethernetEntry 1 }
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.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 94]
\f
RFC draft MIB-II September 1989
Status:
auxiliary.
OBJECT:
-------
etherCRCErrs { ethernetEntry 2 }
Syntax:
Counter
Definition:
The number of CRC errors detected.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
etherAlignErrs { ethernetEntry 3 }
Syntax:
Counter
Definition:
The number of misaligned MAC-level frames.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
etherOutColls { ethernetEntry 4 }
Syntax:
Counter
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 95]
\f
RFC draft MIB-II September 1989
Definition:
The number of output collisions that have occurred.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
etherSpuriousIntrs { ethernetEntry 5 }
Syntax:
Counter
Definition:
The number of spurious interrupts detected.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
etherJabberConds { ethernetEntry 6 }
Syntax:
Counter
Definition:
The number of occasions when a jabber condition was
detected.
Access:
read-only.
Status:
mandatory.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 96]
\f
RFC draft MIB-II September 1989
OBJECT:
-------
etherCarrierLosts { ethernetEntry 7 }
Syntax:
Counter
Definition:
The number of times carrier was lost.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
etherHeartBeatErrs { ethernetEntry 8 }
Syntax:
Counter
Definition:
The number of times the timing pulse was lost/missed.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
etherRunts { ethernetEntry 9 }
Syntax:
Counter
Definition:
The number of media frames encountered that were too
short.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 97]
\f
RFC draft MIB-II September 1989
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
etherGiants { ethernetEntry 10 }
Syntax:
Counter
Definition:
The number of media frames encountered that were too
long.
Access:
read-only.
Status:
mandatory.
5.9.2. 8802.5 transmission type
The token ring status table contains variables useful in
examining statistics gathered by the 8802.5 interfaces
attached to the system.
OBJECT:
-------
iso88025Stats { iso88025-tokenRing 1 }
Syntax:
SEQUENCE of ISO88025Entry
Definition:
A table containing token-ring information.
Access:
read-only.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 98]
\f
RFC draft MIB-II September 1989
Status:
mandatory.
OBJECT:
-------
iso88025Entry { iso88025Stats 1 }
Syntax:
ISO88025Entry ::= SEQUENCE {
dot5Index
INTEGER,
dot5OddByteCounts
Counter,
dot5ParityErrs
Counter,
dot5BadFormats
Counter,
dot5OutTimeOuts
Counter,
connectedToRing
INTEGER
}
Definition:
The statistics table. An entry in this table is uniquely
identified by the value of the dot5Index variable
associated with the interface to which the statistics
refer.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
dot5Index { iso88025Entry 1 }
Syntax:
Counter
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 99]
\f
RFC draft MIB-II September 1989
Description:
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:
auxiliary.
OBJECT:
-------
dot5OddByteCounts { iso88025Entry 2 }
Syntax:
Counter
Description:
The number of frames with an odd number of bytes received
from the interface.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
dot5ParityErrs { iso88025Entry 3 }
Syntax:
Counter
Description:
The number of frames with parity errors received from the
interface.
Access:
read-only.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 100]
\f
RFC draft MIB-II September 1989
Status:
mandatory.
OBJECT:
-------
dot5BadFormats { iso88025Entry 4 }
Syntax:
Counter
Description:
The number of frames with bad formats received from the
interface.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
dot5OutTimeOuts { iso88025Entry 5 }
Syntax:
Counter
Description:
The number of timeouts encountered while waiting for the
token.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
connectedToRing { iso88025Entry 6 }
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 101]
\f
RFC draft MIB-II September 1989
Syntax:
INTEGER {
notConnected(1),
connected(2)
}
Description:
An indication of whether the entity is currently
connected to the token ring.
Access:
read-only.
Status:
mandatory.
5.9.3. T1-carrier transmission type
The T1 status table contains variable useful in examining
statistics gathered by the T1 interfaces attached to the
system.
OBJECT:
-------
t1Stats { t1-carrier 1 }
Syntax:
SEQUENCE of T1Entry
Definition:
A table containing T1 information.
Access:
read-only.
Status:
mandatory.
OBJECT:
t1Entry { t1Stats 1 }
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 102]
\f
RFC draft MIB-II September 1989
Syntax:
T1Entry ::= SEQUENCE {
t1CSUIndex
INTEGER,
t1Index
INTEGER,
t1CurrentPeriod
INTEGER,
t1TimeElapsed
INTEGER
}
Definition:
The statistics table. An entry in this table is uniquely
identified by the value of the T1CSUIndex variable
associated with the interface to which the statistics
refer. The t1Index variable refers to same interface as
identified by the same value of ifIndex.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
t1CSUIndex { t1Entry 1 }
Syntax:
INTEGER
Definition:
The index value which uniquely identifies the CSU to
which this entry is applicable.
Access:
read-only.
Status:
auxiliary.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 103]
\f
RFC draft MIB-II September 1989
OBJECT:
-------
t1Index { t1Entry 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.
OBJECT:
-------
t1CurrentPeriod { t1Entry 3 }
Syntax:
INTEGER
Definition:
The current time-period for error measurement purposes.
One of the 96 time-periods which a day is divided into
for the purpose of error measurement is identified by an
integer ranging in value from 1 to 96.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
t1TimeElapsed { t1Entry 4 }
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 104]
\f
RFC draft MIB-II September 1989
Syntax:
INTEGER
Definition:
The number of seconds that have elapsed since the
beginning of the current error-measurement period.
Access:
read-only.
Status:
mandatory.
5.9.3.1. T1 Error table
The T1 error table contains counters representing ESF error-
seconds accumulated for various 15-minute error periods in a
day.
OBJECT:
-------
t1ErrTable { t1-carrier 2 }
Syntax:
SEQUENCE OF T1Entry
Definition:
A table containing T1 ESF information.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
t1ErrEntry { t1ErrTable 1 }
Syntax:
T1ErrEntry ::= SEQUENCE {
t1ErrIndex
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 105]
\f
RFC draft MIB-II September 1989
INTEGER,
t1ErrorSecs
Counter,
t1BurstySecs
Counter,
t1SeverelyErroredSecs
Counter,
t1FailedSecs
Counter,
t1BipolarViolations
Counter
}
Definition:
A list of error counters representing ESF error-seconds
accumulated for various 15-minute error periods in a day.
The 96 time-periods which a day is divided into for the
purpose of error measurement is identified by an integer
ranging in value from 1 to 96. An entry in this table is
uniquely identified by the value of the time-period
identifier (treated as an INTEGER from 1 to 96) followed
by the T1ErrIndex variable associated with the interface
to which the statistics refer.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
t1ErrIndex { t1ErrEntry 1 }
Syntax:
INTEGER
Definition:
The index value which uniquely identifies the CSU to
which this entry is applicable.
Access:
read-only.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 106]
\f
RFC draft MIB-II September 1989
Status:
auxiliary.
OBJECT:
-------
t1ErrorSecs { t1ErrEntry 2 }
Syntax:
Counter
Definition:
The number of seconds in a time period when at least one
CRC-6 error occurred.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
t1BurstySecs { t1ErrEntry 3 }
Syntax:
Counter
Definition:
The number of seconds in a time period when at least two
and at most 319 CRC-6 errors occurred.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
t1SeverelyErroredSecs { t1ErrEntry 4 }
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 107]
\f
RFC draft MIB-II September 1989
Syntax:
Counter
Definition:
The number of seconds in a time period when at least 320
CRC-6 errors occurred or at least one Out Of Frame (OOF)
error occurred.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
t1FailedSecs { t1ErrEntry 5 }
Syntax:
Counter
Definition:
The number of times the Failed Second (FS) state was
entered within a time-period.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
t1BipolarViolations { t1ErrEntry 6 }
Syntax:
Counter
Definition:
The number of Bipolar Violations that have occurred in a
time period.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 108]
\f
RFC draft MIB-II September 1989
Access:
read-only.
Status:
mandatory.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 109]
\f
RFC draft MIB-II September 1989
5.10. The SNMP Group
Implementation of the SNMP group is mandatory for all systems
which implement the SNMP.
OBJECT:
-------
snmpInPkts { snmp 1 }
Syntax:
Counter
Definition:
The total number of packets delivered to the SNMP agent
process from the transport service.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
snmpOutPkts { snmp 2 }
Syntax:
Counter
Definition:
The total number of SNMP packets which were passed from
the SNMP agent process to the transport service.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
snmpBadVersions { snmp 3 }
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 110]
\f
RFC draft MIB-II September 1989
Syntax:
Counter
Definition:
The total number of SNMP packets which were delivered to
the SNMP agent process and were for an unsupported SNMP
version.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
snmpBadCommunityNames { snmp 4 }
Syntax:
Counter
Definition:
The total number of SNMP packets encountered which used
an invalid SNMP community name.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
snmpBadCommunityUses { snmp 5 }
Syntax:
Counter
Definition:
The total number of SNMP packets encountered which
contained an SNMP operation which was not allowed by the
SNMP community named in the packet.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 111]
\f
RFC draft MIB-II September 1989
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
snmpASNParseErrs { snmp 6 }
Syntax:
Counter
Definition:
The total number of ASN.1 parsing errors (either in
encoding or syntax) encountered when decoding SNMP
packets.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
snmpBadTypes { snmp 7 }
Syntax:
Counter
Definition:
The total number of SNMP packets delivered to the SNMP
agent process which had an unknown PDU type.
Access:
read-only.
Status:
mandatory.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 112]
\f
RFC draft MIB-II September 1989
OBJECT:
-------
snmpTotalReqVars { snmp 8 }
Syntax:
Counter
Definition:
The total number of MIB objects in valid SNMP Get-Request
and Get-Next packets which have been retrieved
successfully by the SNMP agent process.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
snmpTotalSetVars { snmp 9 }
Syntax:
Counter
Definition:
The total number of MIB objects in valid SNMP Set-Request
packets which have been altered successfully by the SNMP
agent process.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
snmpInGetRequests { snmp 10 }
Syntax:
Counter
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 113]
\f
RFC draft MIB-II September 1989
Definition:
The total number of SNMP Get-Request PDUs which have been
accepted and processed by the SNMP agent process.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
snmpInGetNexts { snmp 11 }
Syntax:
Counter
Definition:
The total number of SNMP Get-Next PDUs which have been
accepted and processed by the SNMP agent process.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
snmpInSetRequests { snmp 12 }
Syntax:
Counter
Definition:
The total number of SNMP Set-Request PDUs which have been
accepted and processed by the SNMP agent process.
Access:
read-only.
Status:
mandatory.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 114]
\f
RFC draft MIB-II September 1989
OBJECT:
-------
snmpOutGetResponses { snmp 13 }
Syntax:
Counter
Definition:
The total number of SNMP Get-Response PDUs which have
been passed from the SNMP agent process for transmission.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
snmpOutTraps { snmp 14 }
Syntax:
Counter
Definition:
The total number of SNMP Trap PDUs which have been passed
from the SNMP agent process for transmission.
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
snmpTooBigs { snmp 15 }
Syntax:
Counter
Definition:
The total number of SNMP response packets which had the
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 115]
\f
RFC draft MIB-II September 1989
error status field set to the SNMP protocol error
"tooBig".
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
snmpNoSuchNames { snmp 16 }
Syntax:
Counter
Definition:
The total number of SNMP response packets which had the
error status field set to the SNMP protocol error
"noSuchName".
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
snmpBadValues { snmp 17 }
Syntax:
Counter
Definition:
The total number of SNMP response packets which had the
error status field set to the SNMP protocol error
"badValue".
Access:
read-only.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 116]
\f
RFC draft MIB-II September 1989
Status:
mandatory.
OBJECT:
-------
snmpReadOnlys { snmp 18 }
Syntax:
Counter
Definition:
The total number of SNMP response packets which had the
error status field set to the SNMP protocol error
"readOnly".
Access:
read-only.
Status:
mandatory.
OBJECT:
-------
snmpGenErrs { snmp 19 }
Syntax:
Counter
Definition:
The total number of SNMP response packets which had the
error status field set to the SNMP protocol error
"genErr".
Access:
read-only.
Status:
mandatory.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 117]
\f
RFC draft MIB-II September 1989
6. Definitions
RFCxxxx-MIB { iso org(3) dod(6) internet(1) mgmt(2) 2 }
DEFINITIONS ::= BEGIN
IMPORTS
mgmt, OBJECT-TYPE, NetworkAddress, IpAddress,
Counter, Gauge, TimeTicks
FROM RFC1065-SMI;
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 }
-- object types
-- the System group
sysDescr OBJECT-TYPE
SYNTAX DisplayString
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
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 118]
\f
RFC draft MIB-II September 1989
STATUS mandatory
::= { system 3 }
sysContact OBJECT-TYPE
SYNTAX DisplayString
ACCESS read-write
STATUS mandatory
::= { system 4 }
sysName OBJECT-TYPE
SYNTAX DisplayString
ACCESS read-write
STATUS mandatory
::= { system 5 }
-- 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-write
STATUS mandatory
::= { interfaces 2 }
ifEntry OBJECT-TYPE
SYNTAX IfEntry
ACCESS read-write
STATUS mandatory
::= { ifTable 1 }
IfEntry ::= SEQUENCE {
ifIndex
INTEGER,
ifDescr
DisplayString,
ifType
INTEGER,
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 119]
\f
RFC draft MIB-II September 1989
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,
ifOutRetries
Counter,
ifOutSuccRetries
Counter
}
ifIndex OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 120]
\f
RFC draft MIB-II September 1989
STATUS auxiliary
::= { ifEntry 1 }
ifDescr OBJECT-TYPE
SYNTAX DisplayString
ACCESS read-only
STATUS mandatory
::= { ifEntry 2 }
ifType OBJECT-TYPE
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),
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 }
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 121]
\f
RFC draft MIB-II September 1989
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
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
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 122]
\f
RFC draft MIB-II September 1989
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
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
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 123]
\f
RFC draft MIB-II September 1989
::= { 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
SYNTAX Gauge
ACCESS read-only
STATUS mandatory
::= { ifEntry 21 }
ifOutRetries OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { ifEntry 22 }
ifOutSuccRetries OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { ifEntry 23 }
-- the Address Translation group (deprecated)
atTable OBJECT-TYPE
SYNTAX SEQUENCE OF AtEntry
ACCESS read-write
STATUS deprecated
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 124]
\f
RFC draft MIB-II September 1989
::= { 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 }
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
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 125]
\f
RFC draft MIB-II September 1989
::= { 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
::= { 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
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 126]
\f
RFC draft MIB-II September 1989
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
::= { ip 14 }
ipReasmOKs OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { ip 15 }
ipReasmFails OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 127]
\f
RFC draft MIB-II September 1989
::= { 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
IpAddress,
ipAdEntIfIndex
INTEGER,
ipAdEntNetMask
IpAddress,
ipAdEntBcastAddr
INTEGER,
ipAdEntReasmMaxSize
INTEGER (0..65535)
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 128]
\f
RFC draft MIB-II September 1989
}
ipAdEntAddr OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-only
STATUS auxiliary
::= { 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 }
ipRouteEntry OBJECT-TYPE
SYNTAX IpRouteEntry
ACCESS read-write
STATUS mandatory
::= { ipRoutingTable 1 }
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 129]
\f
RFC draft MIB-II September 1989
IpRouteEntry ::= SEQUENCE {
ipRouteDest
IpAddress,
ipRouteIfIndex
INTEGER,
ipRouteMetric1
INTEGER,
ipRouteMetric2
INTEGER,
ipRouteMetric3
INTEGER,
ipRouteMetric4
INTEGER,
ipRouteNextHop
IpAddress,
ipRouteType
INTEGER,
ipRouteProto
INTEGER,
ipRouteAge
INTEGER
}
ipRouteDest OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-write
STATUS auxiliary
::= { 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 }
ipRouteMetric2 OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 130]
\f
RFC draft MIB-II September 1989
::= { 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
-- e.g., manually
local(2), -- configured entries
-- set via a network
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 131]
\f
RFC draft MIB-II September 1989
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)
}
ACCESS read-only
STATUS mandatory
::= { ipRouteEntry 9 }
ipRouteAge OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-write
STATUS mandatory
::= { ipRouteEntry 10 }
-- the IP Address Translation tables
ipNetToMediaTable OBJECT-TYPE
SYNTAX SEQUENCE OF IpNetToMediaEntry
ACCESS read-only
STATUS mandatory
::= { ip 22 }
ipNetToMediaEntry OBJECT-TYPE
SYNTAX IpNetToMediaEntry
ACCESS read-only
STATUS mandatory
::= { ipNetToMediaTable 1 }
IpNetToMediaEntry ::= SEQUENCE {
ipNetToMediaIfIndex
INTEGER,
ipNetToMediaPhysAddress
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 132]
\f
RFC draft MIB-II September 1989
OCTET STRING,
ipNetToMediaNetAddress
IpAddress
}
ipNetToMediaIfIndex OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS auxiliary
::= { ipNetToMediaEntry 1 }
ipNetToMediaPhysAddress OBJECT-TYPE
SYNTAX OCTET STRING
ACCESS read-only
STATUS mandatory
::= { ipNetToMediaEntry 2 }
ipNetToMediaNetAddress OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-only
STATUS auxiliary
::= { ipNetToMediaEntry 3 }
ipMediaToNetTable OBJECT-TYPE
SYNTAX SEQUENCE OF IpMediaToNetEntry
ACCESS read-only
STATUS mandatory
::= { ip 23 }
ipMediaToNetEntry OBJECT-TYPE
SYNTAX IpMediaToNetEntry
ACCESS read-only
STATUS mandatory
::= { ipMediaToNetTable 1 }
IpMediaToNetEntry ::= SEQUENCE {
ipMediaToNetIfIndex
INTEGER,
ipMediaToNetNetAddress
IpAddress,
ipMediaToNetPhysAddress
OCTET STRING
}
ipMediaToNetIfIndex OBJECT-TYPE
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 133]
\f
RFC draft MIB-II September 1989
SYNTAX INTEGER
ACCESS read-only
STATUS auxiliary
::= { ipMediaToNetEntry 1 }
ipMediaToNetNetAddress OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-only
STATUS mandatory
::= { ipMediaToNetEntry 2 }
ipMediaToNetPhysAddress OBJECT-TYPE
SYNTAX OCTET STRING
ACCESS read-only
STATUS auxiliary
::= { ipMediaToNetEntry 3 }
-- 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
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 134]
\f
RFC draft MIB-II September 1989
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
::= { 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
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 135]
\f
RFC draft MIB-II September 1989
::= { 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
::= { 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
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 136]
\f
RFC draft MIB-II September 1989
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
::= { 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
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 137]
\f
RFC draft MIB-II September 1989
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 }
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 }
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 138]
\f
RFC draft MIB-II September 1989
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 }
-- 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 {
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 139]
\f
RFC draft MIB-II September 1989
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
STATUS auxiliary
::= { tcpConnEntry 2 }
tcpConnLocalPort OBJECT-TYPE
SYNTAX INTEGER (0..65535)
ACCESS read-only
STATUS auxiliary
::= { tcpConnEntry 3 }
tcpConnRemAddress OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-only
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 140]
\f
RFC draft MIB-II September 1989
STATUS auxiliary
::= { tcpConnEntry 4 }
tcpConnRemPort OBJECT-TYPE
SYNTAX INTEGER (0..65535)
ACCESS read-only
STATUS auxiliary
::= { tcpConnEntry 5 }
-- 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
::= { 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
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 141]
\f
RFC draft MIB-II September 1989
SYNTAX UdpEntry
ACCESS read-only
STATUS mandatory
::= { udpTable 1 }
UdpEntry ::= SEQUENCE {
udpLocalAddress
IpAddress,
udpLocalPort
INTEGER (0..65535),
udpListener
DisplayString
}
udpLocalAddress OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-only
STATUS auxiliary
::= { udpEntry 1 }
udpLocalPort OBJECT-TYPE
SYNTAX INTEGER (0..65535)
ACCESS read-only
STATUS auxiliary
::= { udpEntry 2 }
udpListener OBJECT-TYPE
SYNTAX DisplayString
ACCESS read-only
STATUS mandatory
::= { udpEntry 3 }
-- 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
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 142]
\f
RFC draft MIB-II September 1989
::= { 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
Counter,
egpNeighInErrs
Counter,
egpNeighOutMsgs
Counter,
egpNeighOutErrs
Counter,
egpNeighInErrMsgs
Counter,
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 143]
\f
RFC draft MIB-II September 1989
egpNeighOutErrMsgs
Counter,
egpNeighStateUps
Counter,
egpNeighStateDowns
Counter,
egpNeighIntervalHello
INTEGER,
egpNeighMode
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 auxiliary
::= { egpNeighEntry 2 }
egpNeighAs OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
::= { egpNeighEntry 3 }
egpNeighInMsgs OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { egpNeighEntry 4 }
egpNeighInErrs OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 144]
\f
RFC draft MIB-II September 1989
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 }
egpNeighIntervalHello OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
::= { egpNeighEntry 12 }
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 145]
\f
RFC draft MIB-II September 1989
egpNeighMode OBJECT-TYPE
SYNTAX INTEGER {
passive(1),
active(2)
}
ACCESS read-only
STATUS mandatory
::= { egpNeighEntry 13 }
-- additional EGP variables
egpAs OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
::= { egp 6 }
-- the Transmission group
ethernet-csmacd OBJECT IDENTIFIER ::= { transmission 6 }
ethernetStats OBJECT-TYPE
SYNTAX SEQUENCE OF EthernetEntry
ACCESS read-only
STATUS mandatory
::= { ethernet-csmacd 1 }
ethernetEntry OBJECT-TYPE
SYNTAX EthernetEntry
ACCESS read-only
STATUS mandatory
::= { ethernetStats 1 }
EthernetEntry ::= SEQUENCE {
etherIndex
INTEGER,
etherCRCErrs
Counter,
etherAlignErrs
Counter,
etherOutColls
Counter,
etherSpuriousIntrs
Counter,
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 146]
\f
RFC draft MIB-II September 1989
etherJabberConds
Counter,
etherCarrierLosts
Counter,
etherHeartBeatErrs
Counter,
etherRunts
Counter,
etherGiants
Counter
}
etherIndex OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS auxiliary
::= { ethernetEntry 1 }
etherCRCErrs OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { ethernetEntry 2 }
etherAlignErrs OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { ethernetEntry 3 }
etherOutColls OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { ethernetEntry 4 }
etherSpuriousIntrs OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { ethernetEntry 5 }
etherJabberConds OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 147]
\f
RFC draft MIB-II September 1989
STATUS mandatory
::= { ethernetEntry 6 }
etherCarrierLosts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { ethernetEntry 7 }
etherHeartBeatErrs OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { ethernetEntry 8 }
etherRunts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { ethernetEntry 9 }
etherGiants OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { ethernetEntry 10 }
iso88025-tokenRing OBJECT IDENTIFIER ::= { transmission 9 }
iso88025Stats OBJECT-TYPE
SYNTAX ISO88025Entry
ACCESS read-only
STATUS mandatory
::= { iso88025-tokenRing 1 }
iso88025Entry OBJECT-TYPE
SYNTAX ISO88025Entry
ACCESS read-only
STATUS mandatory
::= { iso88025Stats 1 }
ISO88025Entry ::= SEQUENCE {
dot5Index
INTEGER,
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 148]
\f
RFC draft MIB-II September 1989
dot5OddByteCounts
Counter,
dot5ParityErrs
Counter,
dot5BadFormats
Counter,
dot5OutTimeOuts
Counter,
connectedToRing
INTEGER
}
dot5Index OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS auxiliary
::= { iso88025Entry 1 }
dot5OddByteCounts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { iso88025Entry 2 }
dot5ParityErrs OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { iso88025Entry 3 }
dot5BadFormats OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { iso88025Entry 4 }
dot5OutTimeOuts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { iso88025Entry 5 }
connectedToRing OBJECT-TYPE
SYNTAX INTEGER {
notConnected(1),
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 149]
\f
RFC draft MIB-II September 1989
connected(2)
}
ACCESS read-only
STATUS mandatory
::= { iso88025Entry 6 }
t1-carrier OBJECT IDENTIFIER ::= { transmission 18 }
t1Stats OBJECT-TYPE
SYNTAX SEQUENCE OF T1Entry
ACCESS read-only
STATUS mandatory
::= { t1-carrier 1 }
t1Entry OBJECT-TYPE
SYNTAX T1Entry
ACCESS read-only
STATUS mandatory
::= { t1Stats 1 }
T1Entry ::= SEQUENCE {
t1CSUIndex
INTEGER,
t1Index
INTEGER,
t1CurrentPeriod
INTEGER,
t1TimeElapsed
INTEGER
}
t1CSUIndex OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS auxiliary
::= { t1Entry 1 }
t1Index OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
::= { t1Entry 2 }
t1CurrentPeriod OBJECT-TYPE
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 150]
\f
RFC draft MIB-II September 1989
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
::= { t1Entry 3 }
t1TimeElapsed OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
::= { t1Entry 4 }
t1ErrTable OBJECT-TYPE
SYNTAX SEQUENCE OF T1ErrEntry
ACCESS read-only
STATUS mandatory
::= { t1-carrier 2 }
t1ErrEntry OBJECT-TYPE
SYNTAX T1ErrEntry
ACCESS read-only
STATUS mandatory
::= { t1ErrTable 1 }
T1ErrEntry ::= SEQUENCE {
t1ErrIndex
INTEGER,
t1ErrorSecs
Counter,
t1BurstySecs
Counter,
t1SeverelyErroredSecs
Counter,
t1FailedSecs
Counter,
t1BipolarViolations
Counter
}
t1ErrIndex OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS auxiliary
::= { t1ErrEntry 1 }
t1ErrorSecs OBJECT-TYPE
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 151]
\f
RFC draft MIB-II September 1989
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { t1ErrEntry 2 }
t1BurstySecs OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { t1ErrEntry 3 }
t1SeverelyErroredSecs OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { t1ErrEntry 4 }
t1FailedSecs OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { t1ErrEntry 5 }
t1BipolarViolations OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { t1ErrEntry 6 }
-- the SNMP group
snmpInPkts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { snmp 1 }
snmpOutPkts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { snmp 2 }
snmpBadVersions OBJECT-TYPE
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 152]
\f
RFC draft MIB-II September 1989
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { snmp 3 }
snmpBadCommunityNames OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { snmp 4 }
snmpBadCommunityUses OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { snmp 5 }
snmpASNParseErrs OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { snmp 6 }
snmpBadTypes OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { snmp 7 }
snmpTotalReqVars OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { snmp 8 }
snmpTotalSetVars OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { snmp 9 }
snmpInGetRequests OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 153]
\f
RFC draft MIB-II September 1989
::= { snmp 10 }
snmpInGetNexts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { snmp 11 }
snmpInSetRequests OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { snmp 12 }
snmpOutGetResponses OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { snmp 13 }
snmpOutTraps OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { snmp 14 }
snmpTooBigs OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { snmp 15 }
snmpNoSuchNames OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { snmp 16 }
snmpBadValues OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { snmp 17 }
snmpReadOnlys OBJECT-TYPE
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 154]
\f
RFC draft MIB-II September 1989
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { snmp 18 }
snmpGenErrs OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
::= { snmp 19 }
END
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 155]
\f
RFC draft MIB-II September 1989
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 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.2.1.1 to which
is appended an instance sub-identifier of 0. That is,
1.3.6.1.2.2.1.1.0 identifies the one and only instance of
sysDescr.
7.1. ifTable Object Type Names
The name of a subnet interface, s, is the OBJECT IDENTIFIER
value of the form i, where i has the value of that instance of
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 156]
\f
RFC draft MIB-II September 1989
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 subnet
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 AT-cached network address, x, is an OBJECT
IDENTIFIER of the form 1.a.b.c.d, where a.b.c.d is the value
(in the familiar "dot" notation) of the atNetAddress object
type associated with x.
The name of an address translation equivalence e is an OBJECT
IDENTIFIER value of the form s.w, such that s is the value of
that instance of the atIndex object type associated with e and
such that w is the name of the AT-cached network address
associated with e.
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 the form n.y, where y is the name of the address
translation equivalence 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
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 157]
\f
RFC draft MIB-II September 1989
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.
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 instance.
7.5. ipNetToMacTable 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 ipNetToMacIfIndex object type associated with the entry
and a.b.c.d is the value (in the familiar "dot" notation) of
the ipNetToMacIpAddress object type associated with x.
For each object type, t, for which the defined name, n, has a
prefix of ipNetToMacEntry, 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 MAC address of an
entry in the address translation table associated with a IP
address of 192.52.180.1 and interface 3. Accordingly,
ipNetToMacPhysAddress.3.192.52.180.1 would identify the
desired instance.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 158]
\f
RFC draft MIB-II September 1989
7.6. ipMacToNetTable Object Type Names
The name of a cached MAC address, x, is an OBJECT IDENTIFIER
of the form s.b0.b1..bn, such that s is the value of that
instance of the ipMacToNetIfIndex object type associated with
the entry and b0.b1..bn is the value of the of the
ipMacToNetPhysAddress object type associated with x.
For each object type, t, for which the defined name, n, has a
prefix of ipMacToNetEntry, an instance, i, of t is named by an
OBJECT IDENTIFIER of the form n.y, where y is the name of the
cached MAC address about which i represents information.
For example, suppose one wanted to find the IP address of an
entry in the address translation table associated with a MAC
address of 08:00:20:00:38:ba and interface 3. Accordingly,
ipMactoNetIpAddress.3.8.0.32.0.56.186 would identify the
desired instance.
7.7. 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, tcpConnState.89.1.1.42.21.10.0.0.51.2059 would
identify the desired instance.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 159]
\f
RFC draft MIB-II September 1989
7.8. 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 the identifier of
a a UDP listener at the local address of 89.1.1.42 on UDP port
21. Accordingly, udpListener.89.1.1.42.21 would identify the
desired instance.
7.9. 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.
7.10. ethernetStats Object Type Names
The name of an ethernet interface, s, is the OBJECT IDENTIFIER
value of the form i, where i has the value of that instance of
the etherIndex object type associated with s.
For each object type, t, for which the defined name, n, has a
prefix of ethernetEntry, an instance, i, of t is named by an
OBJECT IDENTIFIER of the form n.s, where s is the name of the
ethernet interface about which i represents information.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 160]
\f
RFC draft MIB-II September 1989
For example, suppose one wanted to identify the instance of
the variable etherGiants associated with the ethernet
interface known as interface number 2. Accordingly,
etherGiants.2 would identify the desired instance.
7.11. iso88025Stats Object Type Names
The name of an token ring interface, s, is the OBJECT
IDENTIFIER value of the form i, where i has the value of that
instance of the dot5Index object type associated with s.
For each object type, t, for which the defined name, n, has a
prefix of iso88025Entry, an instance, i, of t is named by an
OBJECT IDENTIFIER of the form n.s, where s is the name of the
token ring interface about which i represents information.
For example, suppose one wanted to identify the instance of
the variable connectedToRing associated with the token ring
interface known as interface number 3. Accordingly,
connectedToRing.3 would identify the desired instance.
7.12. t1Stats Object Type Names
The name of an T1 interface, s, is the OBJECT IDENTIFIER value
of the form i, where i has the value of that instance of the
t1CSUIndex object type associated with s.
For each object type, t, for which the defined name, n, has a
prefix of t1Entry, an instance, i, of t is named by an OBJECT
IDENTIFIER of the form n.s, where s is the name of the T1
interface about which i represents information.
For example, suppose one wanted to identify the instance of
the variable t1CurrentPeriod associated with the CSU interface
known as interface number 1. Accordingly, t1CurrentPeriod.1
would identify the desired instance.
7.13. t1ErrTable Object Type Names
The name of an T1 error summary, s, is the OBJECT IDENTIFIER
value of the form p.i, where p has the value of the error
period of interest, and i has the value of that instance of
the t1ErrIndex object type associated with s.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 161]
\f
RFC draft MIB-II September 1989
For each object type, t, for which the defined name, n, has a
prefix of t1ErrEntry, an instance, i, of t is named by an
OBJECT IDENTIFIER of the form n.p.i, where p is the error
period of interest and i is the name of the T1 interface about
which i represents information.
For example, suppose one wanted to identify the instance of
the variable t1BurstySec associated with the CSU interface
known as interface number 1 during the fifth error period.
Accordingly, t1BurstySec.5.1 would identify the desired
instance.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 162]
\f
RFC draft MIB-II September 1989
8. Acknowledgements This document was produced by the SNMP
Working Group:
John Burress, Wellfleet
Jeffrey D. Case, University of Tennessee at Knoxville
James R. Davin, MIT
Mark S. Fedor, NYSERNet
Keith McCloghrie, Hughes LAN Systems
Marshall T. Rose, NYSERNet (chair)
Greg Satz, cisco
Martin Lee Schoffstall, NYSERNet
Wengyik Yeong, NYSERNet
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 163]
\f
RFC draft MIB-II September 1989
9. References
[1] V. Cerf, IAB Recommendations for the Development of
Internet Network Management Standards. Internet Working
Group Request for Comments 1052. Network Information
Center, SRI International, Menlo Park, California,
(April, 1988).
[2] M.T. Rose and K. McCloghrie, Structure and Identification
of Management Information for TCP/IP-based internets,
Internet Working Group Request for Comments 1065.
Network Information Center, SRI International, Menlo
Park, California, (August, 1988).
[3] K. McCloghrie and M.T. Rose, Manager Information Base for
Network Management of TCP/IP-based internets, Internet
Working Group Request for Comments 1066. Network
Information Center, SRI International, Menlo Park,
California, (August, 1988).
[4] V. Cerf, Report of the Second Ad Hoc Network Management
Review Group, Internet Working Group Request for Comments
1109. Network Information Center, SRI International,
Menlo Park, California, (August, 1989).
[5] J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin,
Simple Network Management Protocol, Internet Working
Group Request for Comments 1098. Network Information
Center, SRI International, Menlo Park, California,
(April, 1989).
[6] U. Warrier, L. Besaw, Comon Management Information
Services and Protocol over TCP/IP (CMOT), Internet
Working Group Request for Comments 1095. Network
Information Center, SRI International, Menlo Park,
California, (April, 1989).
[7] J.B. Postel, TELNET Protocol Specification, Internet
Working Group Request for Comments 854. Network
Information Center, SRI International, Menlo Park,
California, (May, 1983).
[8] G. Satz, Experimental MIB Objects for the CLNP, Internet
Working Group Request for Comments draft. Network
Information Center, SRI International, Menlo Park,
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 164]
\f
RFC draft MIB-II September 1989
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] V. Jacobson, Congestion Avoidance and Control, SIGCOMM
1988, Stanford, California.
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 165]
\f
RFC draft MIB-II September 1989
Table of Contents
1 Status of this Memo ................................... 1
2 Introduction .......................................... 2
3 Changes from MIB-I .................................... 5
3.1 Deprecated Objects .................................. 5
3.2 Auxiliary Objects ................................... 5
3.3 Display Strings ..................................... 6
3.4 The System Group .................................... 7
3.5 The Interfaces Group ................................ 7
3.6 The Address Translation Group ....................... 8
3.7 The IP Group ........................................ 8
3.8 The ICMP Group ...................................... 9
3.9 The TCP Group ....................................... 9
3.10 The UDP Group ...................................... 9
3.11 The EGP Group ...................................... 9
3.12 The Transmission Group ............................. 10
3.13 The SNMP Group ..................................... 10
4 Objects ............................................... 11
4.1 Object Groups ....................................... 11
4.2 Format of Definitions ............................... 12
5 Object Definitions .................................... 14
5.1 The System Group .................................... 15
5.2 The Interfaces Group ................................ 18
5.2.1 The Interfaces Table .............................. 18
5.3 The Address Translation Group ....................... 32
5.4 The IP Group ........................................ 35
5.4.1 The IP Address Table .............................. 43
5.4.2 The IP Routing Table .............................. 47
5.4.3 The IP Address Translation Tables ................. 53
5.5 The ICMP Group ...................................... 59
5.6 The TCP Group ....................................... 70
5.6.1 The TCP Connection Table .......................... 75
5.7 The UDP Group ....................................... 79
5.7.1 The UDP Listener Table ............................ 80
5.8 The EGP Group ....................................... 83
5.8.1 The EGP Neighbor Table ............................ 84
5.8.2 Additional EGP variables .......................... 91
5.9 The Transmission Group .............................. 93
5.9.1 Ethernet transmission type ........................ 93
5.9.2 8802.5 transmission type .......................... 98
5.9.3 T1-carrier transmission type ...................... 102
5.9.3.1 T1 Error table .................................. 105
5.10 The SNMP Group ..................................... 110
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 166]
\f
RFC draft MIB-II September 1989
6 Definitions ........................................... 118
7 Identification of OBJECT instances for use with the
SNMP ............................................... 156
7.1 ifTable Object Type Names ........................... 156
7.2 atTable Object Type Names ........................... 157
7.3 ipAddrTable Object Type Names ....................... 157
7.4 ipRoutingTable Object Type Names .................... 158
7.5 ipNetToMacTable Object Type Names ................... 158
7.6 ipMacToNetTable Object Type Names ................... 159
7.7 tcpConnTable Object Type Names ...................... 159
7.8 udpTable Object Type Names .......................... 160
7.9 egpNeighTable Object Type Names ..................... 160
7.10 ethernetStats Object Type Names .................... 160
7.11 iso88025Stats Object Type Names .................... 161
7.12 t1Stats Object Type Names .......................... 161
7.13 t1ErrTable Object Type Names ....................... 161
8 Acknowledgements ...................................... 163
9 References ............................................ 164
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 167]
\f
RFC draft MIB-II September 1989
Table of Contents
M.T.Rose (editor) OBSOLETES RFC 1066 [Page 168]