7 Network Working Group K. McCloghrie
8 Request for Comments: 1213 Hughes LAN Systems, Inc.
9 Obsoletes: RFC 1158 M. Rose
10 Performance Systems International
15 Management Information Base for Network Management
16 of TCP/IP-based internets:
21 This memo defines the second version of the Management Information
22 Base (MIB-II) for use with network management protocols in TCP/IP-
23 based internets. This RFC specifies an IAB standards track protocol
24 for the Internet community, and requests discussion and suggestions
25 for improvements. Please refer to the current edition of the "IAB
26 Official Protocol Standards" for the standardization state and status
27 of this protocol. Distribution of this memo is unlimited.
31 1. Abstract............................................... 2
32 2. Introduction .......................................... 2
33 3. Changes from RFC 1156 ................................. 3
34 3.1 Deprecated Objects ................................... 3
35 3.2 Display Strings ...................................... 4
36 3.3 Physical Addresses ................................... 4
37 3.4 The System Group ..................................... 5
38 3.5 The Interfaces Group ................................. 5
39 3.6 The Address Translation Group ........................ 6
40 3.7 The IP Group ......................................... 6
41 3.8 The ICMP Group ....................................... 7
42 3.9 The TCP Group ........................................ 7
43 3.10 The UDP Group ....................................... 7
44 3.11 The EGP Group ....................................... 7
45 3.12 The Transmission Group .............................. 8
46 3.13 The SNMP Group ...................................... 8
47 3.14 Changes from RFC 1158 ................. ............. 9
48 4. Objects ............................................... 10
49 4.1 Format of Definitions ................................ 10
50 5. Overview .............................................. 10
51 6. Definitions ........................................... 12
52 6.1 Textual Conventions .................................. 12
53 6.2 Groups in MIB-II ..................................... 13
54 6.3 The System Group ..................................... 13
58 SNMP Working Group [Page 1]
60 RFC 1213 MIB-II March 1991
63 6.4 The Interfaces Group ................................. 16
64 6.5 The Address Translation Group ........................ 23
65 6.6 The IP Group ......................................... 26
66 6.7 The ICMP Group ....................................... 41
67 6.8 The TCP Group ........................................ 46
68 6.9 The UDP Group ........................................ 52
69 6.10 The EGP Group ....................................... 54
70 6.11 The Transmission Group .............................. 60
71 6.12 The SNMP Group ...................................... 60
72 7. Acknowledgements ...................................... 67
73 8. References ............................................ 69
74 9. Security Considerations ............................... 70
75 10. Authors' Addresses ................................... 70
79 This memo defines the second version of the Management Information
80 Base (MIB-II) for use with network management protocols in TCP/IP-
81 based internets. In particular, together with its companion memos
82 which describe the structure of management information (RFC 1155)
83 along with the network management protocol (RFC 1157) for TCP/IP-
84 based internets, these documents provide a simple, workable
85 architecture and system for managing TCP/IP-based internets and in
86 particular the Internet community.
90 As reported in RFC 1052, IAB Recommendations for the Development of
91 Internet Network Management Standards [1], a two-prong strategy for
92 network management of TCP/IP-based internets was undertaken. In the
93 short-term, the Simple Network Management Protocol (SNMP) was to be
94 used to manage nodes in the Internet community. In the long-term,
95 the use of the OSI network management framework was to be examined.
96 Two documents were produced to define the management information: RFC
97 1065, which defined the Structure of Management Information (SMI)
98 [2], and RFC 1066, which defined the Management Information Base
99 (MIB) [3]. Both of these documents were designed so as to be
100 compatible with both the SNMP and the OSI network management
103 This strategy was quite successful in the short-term: Internet-based
104 network management technology was fielded, by both the research and
105 commercial communities, within a few months. As a result of this,
106 portions of the Internet community became network manageable in a
109 As reported in RFC 1109, Report of the Second Ad Hoc Network
110 Management Review Group [4], the requirements of the SNMP and the OSI
114 SNMP Working Group [Page 2]
116 RFC 1213 MIB-II March 1991
119 network management frameworks were more different than anticipated.
120 As such, the requirement for compatibility between the SMI/MIB and
121 both frameworks was suspended. This action permitted the operational
122 network management framework, the SNMP, to respond to new operational
123 needs in the Internet community by producing this document.
125 As such, the current network management framework for TCP/IP- based
126 internets consists of: Structure and Identification of Management
127 Information for TCP/IP-based internets, RFC 1155 [12], which
128 describes how managed objects contained in the MIB are defined;
129 Management Information Base for Network Management of TCP/IP-based
130 internets: MIB-II, this memo, which describes the managed objects
131 contained in the MIB (and supercedes RFC 1156 [13]); and, the Simple
132 Network Management Protocol, RFC 1098 [5], which defines the protocol
133 used to manage these objects.
135 3. Changes from RFC 1156
137 Features of this MIB include:
139 (1) incremental additions to reflect new operational
142 (2) upwards compatibility with the SMI/MIB and the SNMP;
144 (3) improved support for multi-protocol entities; and,
146 (4) textual clean-up of the MIB to improve clarity and
149 The objects defined in MIB-II have the OBJECT IDENTIFIER prefix:
151 mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }
153 which is identical to the prefix used in MIB-I.
155 3.1. Deprecated Objects
157 In order to better prepare implementors for future changes in the
158 MIB, a new term "deprecated" may be used when describing an object.
159 A deprecated object in the MIB is one which must be supported, but
160 one which will most likely be removed from the next version of the
163 MIB-II marks one object as being deprecated:
170 SNMP Working Group [Page 3]
172 RFC 1213 MIB-II March 1991
175 As a result of deprecating the atTable object, the entire Address
176 Translation group is deprecated.
178 Note that no functionality is lost with the deprecation of these
179 objects: new objects providing equivalent or superior functionality
180 are defined in MIB-II.
184 In the past, there have been misinterpretations of the MIB as to when
185 a string of octets should contain printable characters, meant to be
186 displayed to a human. As a textual convention in the MIB, the
192 is introduced. A DisplayString is restricted to the NVT ASCII
193 character set, as defined in pages 10-11 of [6].
195 The following objects are now defined in terms of DisplayString:
200 It should be noted that this change has no effect on either the
201 syntax nor semantics of these objects. The use of the DisplayString
202 notation is merely an artifact of the explanatory method used in
203 MIB-II and future MIBs.
205 Further it should be noted that any object defined in terms of OCTET
206 STRING may contain arbitrary binary data, in which each octet may
207 take any value from 0 to 255 (decimal).
209 3.3. Physical Addresses
211 As a further, textual convention in the MIB, the datatype
216 is introduced to represent media- or physical-level addresses.
218 The following objects are now defined in terms of PhysAddress:
222 ipNetToMediaPhysAddress
226 SNMP Working Group [Page 4]
228 RFC 1213 MIB-II March 1991
231 It should be noted that this change has no effect on either the
232 syntax nor semantics of these objects. The use of the PhysAddress
233 notation is merely an artifact of the explanatory method used in
234 MIB-II and future MIBs.
236 3.4. The System Group
238 Four new objects are added to this group:
245 These provide contact, administrative, location, and service
246 information regarding the managed node.
248 3.5. The Interfaces Group
250 The definition of the ifNumber object was incorrect, as it required
251 all interfaces to support IP. (For example, devices without IP, such
252 as MAC-layer bridges, could not be managed if this definition was
253 strictly followed.) The description of the ifNumber object is
256 The ifTable object was mistaken marked as read-write, it has been
257 (correctly) re-designated as not-accessible. In addition, several
258 new values have been added to the ifType column in the ifTable
272 Finally, a new column has been added to the ifTable object:
276 which provides information about information specific to the media
277 being used to realize the interface.
282 SNMP Working Group [Page 5]
284 RFC 1213 MIB-II March 1991
287 3.6. The Address Translation Group
289 In MIB-I this group contained a table which permitted mappings from
290 network addresses (e.g., IP addresses) to physical addresses (e.g.,
291 MAC addresses). Experience has shown that efficient implementations
292 of this table make two assumptions: a single network protocol
293 environment, and mappings occur only from network address to physical
296 The need to support multi-protocol nodes (e.g., those with both the
297 IP and CLNP active), and the need to support the inverse mapping
298 (e.g., for ES-IS), have invalidated both of these assumptions. As
299 such, the atTable object is declared deprecated.
301 In order to meet both the multi-protocol and inverse mapping
302 requirements, MIB-II and its successors will allocate up to two
303 address translation tables inside each network protocol group. That
304 is, the IP group will contain one address translation table, for
305 going from IP addresses to physical addresses. Similarly, when a
306 document defining MIB objects for the CLNP is produced (e.g., [7]),
307 it will contain two tables, for mappings in both directions, as this
308 is required for full functionality.
310 It should be noted that the choice of two tables (one for each
311 direction of mapping) provides for ease of implementation in many
312 cases, and does not introduce undue burden on implementations which
313 realize the address translation abstraction through a single internal
318 The access attribute of the variable ipForwarding has been changed
319 from read-only to read-write.
321 In addition, there is a new column to the ipAddrTable object,
325 which keeps track of the largest IP datagram that can be re-assembled
326 on a particular interface.
328 The descriptor of the ipRoutingTable object has been changed to
329 ipRouteTable for consistency with the other IP routing objects.
330 There are also three new columns in the ipRouteTable object,
338 SNMP Working Group [Page 6]
340 RFC 1213 MIB-II March 1991
343 the first is used for IP routing subsystems that support arbitrary
344 subnet masks, and the latter two are IP routing protocol-specific.
346 Two new objects are added to the IP group:
351 the first is the address translation table for the IP group
352 (providing identical functionality to the now deprecated atTable in
353 the address translation group), and the latter provides information
354 when routes are lost due to a lack of buffer space.
358 There are no changes to this group.
362 Two new variables are added:
367 which keep track of the number of incoming TCP segments in error and
368 the number of resets generated by a TCP.
380 Experience has indicated a need for additional objects that are
381 useful in EGP monitoring. In addition to making several additions to
382 the egpNeighborTable object, i.e.,
394 SNMP Working Group [Page 7]
396 RFC 1213 MIB-II March 1991
401 egpNeighIntervalHello
406 a new variable is added:
410 which gives the autonomous system associated with this EGP entity.
412 3.12. The Transmission Group
414 MIB-I was lacking in that it did not distinguish between different
415 types of transmission media. A new group, the Transmission group, is
416 allocated for this purpose:
418 transmission OBJECT IDENTIFIER ::= { mib-2 10 }
420 When Internet-standard definitions for managing transmission media
421 are defined, the transmission group is used to provide a prefix for
422 the names of those objects.
424 Typically, such definitions reside in the experimental portion of the
425 MIB until they are "proven", then as a part of the Internet
426 standardization process, the definitions are accordingly elevated and
427 a new object identifier, under the transmission group is defined. By
428 convention, the name assigned is:
430 type OBJECT IDENTIFIER ::= { transmission number }
432 where "type" is the symbolic value used for the media in the ifType
433 column of the ifTable object, and "number" is the actual integer
434 value corresponding to the symbol.
438 The application-oriented working groups of the IETF have been tasked
439 to be receptive towards defining MIB variables specific to their
440 respective applications.
442 For the SNMP, it is useful to have statistical information. A new
443 group, the SNMP group, is allocated for this purpose:
445 snmp OBJECT IDENTIFIER ::= { mib-2 11 }
450 SNMP Working Group [Page 8]
452 RFC 1213 MIB-II March 1991
455 3.14. Changes from RFC 1158
457 Features of this MIB include:
459 (1) The managed objects in this document have been defined
460 using the conventions defined in the Internet-standard
461 SMI, as amended by the extensions specified in [14]. It
462 must be emphasized that definitions made using these
463 extensions are semantically identically to those in RFC
466 (2) The PhysAddress textual convention has been introduced to
467 represent media addresses.
469 (3) The ACCESS clause of sysLocation is now read-write.
471 (4) The definition of sysServices has been clarified.
473 (5) New ifType values (29-32) have been defined. In
474 addition, the textual-descriptor for the DS1 and E1
475 interface types has been corrected.
477 (6) The definition of ipForwarding has been clarified.
479 (7) The definition of ipRouteType has been clarified.
481 (8) The ipRouteMetric5 and ipRouteInfo objects have been
484 (9) The ACCESS clause of tcpConnState is now read-write, to
485 support deletion of the TCB associated with a TCP
486 connection. The definition of this object has been
487 clarified to explain this usage.
489 (10) The definition of egpNeighEventTrigger has been
492 (11) The definition of several of the variables in the new
493 snmp group have been clarified. In addition, the
494 snmpInBadTypes and snmpOutReadOnlys objects are no longer
495 present. (However, the object identifiers associated
496 with those objects are reserved to prevent future use.)
498 (12) The definition of snmpInReadOnlys has been clarified.
500 (13) The textual descriptor of the snmpEnableAuthTraps has
501 been changed to snmpEnableAuthenTraps, and the definition
506 SNMP Working Group [Page 9]
508 RFC 1213 MIB-II March 1991
511 (14) The ipRoutingDiscards object was added.
513 (15) The optional use of an implementation-dependent, small
514 positive integer was disallowed when identifying
515 instances of the IP address and routing tables.
519 Managed objects are accessed via a virtual information store, termed
520 the Management Information Base or MIB. Objects in the MIB are
521 defined using the subset of Abstract Syntax Notation One (ASN.1) [8]
522 defined in the SMI. In particular, each object has a name, a syntax,
523 and an encoding. The name is an object identifier, an
524 administratively assigned name, which specifies an object type. The
525 object type together with an object instance serves to uniquely
526 identify a specific instantiation of the object. For human
527 convenience, we often use a textual string, termed the OBJECT
528 DESCRIPTOR, to also refer to the object type.
530 The syntax of an object type defines the abstract data structure
531 corresponding to that object type. The ASN.1 language is used for
532 this purpose. However, the SMI [12] purposely restricts the ASN.1
533 constructs which may be used. These restrictions are explicitly made
536 The encoding of an object type is simply how that object type is
537 represented using the object type's syntax. Implicitly tied to the
538 notion of an object type's syntax and encoding is how the object type
539 is represented when being transmitted on the network.
541 The SMI specifies the use of the basic encoding rules of ASN.1 [9],
542 subject to the additional requirements imposed by the SNMP.
544 4.1. Format of Definitions
546 Section 6 contains contains the specification of all object types
547 contained in this MIB module. The object types are defined using the
548 conventions defined in the SMI, as amended by the extensions
553 Consistent with the IAB directive to produce simple, workable systems
554 in the short-term, the list of managed objects defined here, has been
555 derived by taking only those elements which are considered essential.
557 This approach of taking only the essential objects is NOT
558 restrictive, since the SMI defined in the companion memo provides
562 SNMP Working Group [Page 10]
564 RFC 1213 MIB-II March 1991
567 three extensibility mechanisms: one, the addition of new standard
568 objects through the definitions of new versions of the MIB; two, the
569 addition of widely-available but non-standard objects through the
570 experimental subtree; and three, the addition of private objects
571 through the enterprises subtree. Such additional objects can not
572 only be used for vendor-specific elements, but also for
573 experimentation as required to further the knowledge of which other
574 objects are essential.
576 The design of MIB-II is heavily influenced by the first extensibility
577 mechanism. Several new variables have been added based on
578 operational experience and need. Based on this, the criteria for
579 including an object in MIB-II are remarkably similar to the MIB-I
582 (1) An object needed to be essential for either fault or
583 configuration management.
585 (2) Only weak control objects were permitted (by weak, it is
586 meant that tampering with them can do only limited
587 damage). This criterion reflects the fact that the
588 current management protocols are not sufficiently secure
589 to do more powerful control operations.
591 (3) Evidence of current use and utility was required.
593 (4) In MIB-I, an attempt was made to limit the number of
594 objects to about 100 to make it easier for vendors to
595 fully instrument their software. In MIB-II, this limit
596 was raised given the wide technological base now
599 (5) To avoid redundant variables, it was required that no
600 object be included that can be derived from others in the
603 (6) Implementation specific objects (e.g., for BSD UNIX) were
606 (7) It was agreed to avoid heavily instrumenting critical
607 sections of code. The general guideline was one counter
608 per critical section per layer.
610 MIB-II, like its predecessor, the Internet-standard MIB, contains
611 only essential elements. There is no need to allow individual
612 objects to be optional. Rather, the objects are arranged into the
618 SNMP Working Group [Page 11]
620 RFC 1213 MIB-II March 1991
625 - Address Translation (deprecated)
634 These groups are the basic unit of conformance: This method is as
635 follows: if the semantics of a group is applicable to an
636 implementation, then it must implement all objects in that group.
637 For example, an implementation must implement the EGP group if and
638 only if it implements the EGP.
640 There are two reasons for defining these groups: to provide a means
641 of assigning object identifiers; and, to provide a method for
642 implementations of managed agents to know which objects they must
647 RFC1213-MIB DEFINITIONS ::= BEGIN
650 mgmt, NetworkAddress, IpAddress, Counter, Gauge,
656 -- This MIB module uses the extended OBJECT-TYPE macro as
660 -- MIB-II (same prefix as MIB-I)
662 mib-2 OBJECT IDENTIFIER ::= { mgmt 1 }
664 -- textual conventions
668 -- This data type is used to model textual information taken
669 -- from the NVT ASCII character set. By convention, objects
670 -- with this syntax are declared as having
674 SNMP Working Group [Page 12]
676 RFC 1213 MIB-II March 1991
684 -- This data type is used to model media addresses. For many
685 -- types of media, this will be in a binary representation.
686 -- For example, an ethernet address would be represented as
687 -- a string of 6 octets.
692 system OBJECT IDENTIFIER ::= { mib-2 1 }
694 interfaces OBJECT IDENTIFIER ::= { mib-2 2 }
696 at OBJECT IDENTIFIER ::= { mib-2 3 }
698 ip OBJECT IDENTIFIER ::= { mib-2 4 }
700 icmp OBJECT IDENTIFIER ::= { mib-2 5 }
702 tcp OBJECT IDENTIFIER ::= { mib-2 6 }
704 udp OBJECT IDENTIFIER ::= { mib-2 7 }
706 egp OBJECT IDENTIFIER ::= { mib-2 8 }
708 -- historical (some say hysterical)
709 -- cmot OBJECT IDENTIFIER ::= { mib-2 9 }
711 transmission OBJECT IDENTIFIER ::= { mib-2 10 }
713 snmp OBJECT IDENTIFIER ::= { mib-2 11 }
718 -- Implementation of the System group is mandatory for all
719 -- systems. If an agent is not configured to have a value
720 -- for any of these variables, a string of length 0 is
724 SYNTAX DisplayString (SIZE (0..255))
730 SNMP Working Group [Page 13]
732 RFC 1213 MIB-II March 1991
736 "A textual description of the entity. This value
737 should include the full name and version
738 identification of the system's hardware type,
739 software operating-system, and networking
740 software. It is mandatory that this only contain
741 printable ASCII characters."
744 sysObjectID OBJECT-TYPE
745 SYNTAX OBJECT IDENTIFIER
749 "The vendor's authoritative identification of the
750 network management subsystem contained in the
751 entity. This value is allocated within the SMI
752 enterprises subtree (1.3.6.1.4.1) and provides an
753 easy and unambiguous means for determining `what
754 kind of box' is being managed. For example, if
755 vendor `Flintstones, Inc.' was assigned the
756 subtree 1.3.6.1.4.1.4242, it could assign the
757 identifier 1.3.6.1.4.1.4242.1.1 to its `Fred
761 sysUpTime OBJECT-TYPE
766 "The time (in hundredths of a second) since the
767 network management portion of the system was last
771 sysContact OBJECT-TYPE
772 SYNTAX DisplayString (SIZE (0..255))
776 "The textual identification of the contact person
777 for this managed node, together with information
778 on how to contact this person."
782 SYNTAX DisplayString (SIZE (0..255))
786 SNMP Working Group [Page 14]
788 RFC 1213 MIB-II March 1991
794 "An administratively-assigned name for this
795 managed node. By convention, this is the node's
796 fully-qualified domain name."
799 sysLocation OBJECT-TYPE
800 SYNTAX DisplayString (SIZE (0..255))
804 "The physical location of this node (e.g.,
805 `telephone closet, 3rd floor')."
808 sysServices OBJECT-TYPE
809 SYNTAX INTEGER (0..127)
813 "A value which indicates the set of services that
814 this entity primarily offers.
816 The value is a sum. This sum initially takes the
817 value zero, Then, for each layer, L, in the range
818 1 through 7, that this node performs transactions
819 for, 2 raised to (L - 1) is added to the sum. For
820 example, a node which performs primarily routing
821 functions would have a value of 4 (2^(3-1)). In
822 contrast, a node which is a host offering
823 application services would have a value of 72
824 (2^(4-1) + 2^(7-1)). Note that in the context of
825 the Internet suite of protocols, values should be
826 calculated accordingly:
829 1 physical (e.g., repeaters)
830 2 datalink/subnetwork (e.g., bridges)
831 3 internet (e.g., IP gateways)
832 4 end-to-end (e.g., IP hosts)
833 7 applications (e.g., mail relays)
835 For systems including OSI protocols, layers 5 and
836 6 may also be counted."
842 SNMP Working Group [Page 15]
844 RFC 1213 MIB-II March 1991
847 -- the Interfaces group
849 -- Implementation of the Interfaces group is mandatory for
857 "The number of network interfaces (regardless of
858 their current state) present on this system."
862 -- the Interfaces table
864 -- The Interfaces table contains information on the entity's
865 -- interfaces. Each interface is thought of as being
866 -- attached to a `subnetwork'. Note that this term should
867 -- not be confused with `subnet' which refers to an
868 -- addressing partitioning scheme used in the Internet suite
872 SYNTAX SEQUENCE OF IfEntry
873 ACCESS not-accessible
876 "A list of interface entries. The number of
877 entries is given by the value of ifNumber."
882 ACCESS not-accessible
885 "An interface entry containing objects at the
886 subnetwork layer and below for a particular
898 SNMP Working Group [Page 16]
900 RFC 1213 MIB-II March 1991
954 SNMP Working Group [Page 17]
956 RFC 1213 MIB-II March 1991
960 "A unique value for each interface. Its value
961 ranges between 1 and the value of ifNumber. The
962 value for each interface must remain constant at
963 least from one re-initialization of the entity's
964 network management system to the next re-
969 SYNTAX DisplayString (SIZE (0..255))
973 "A textual string containing information about the
974 interface. This string should include the name of
975 the manufacturer, the product name and the version
976 of the hardware interface."
981 other(1), -- none of the following
988 iso88024-tokenBus(8),
989 iso88025-tokenRing(9),
999 e1(19), -- european equiv. of T-1
1001 primaryISDN(21), -- proprietary serial
1002 propPointToPointSerial(22),
1004 softwareLoopback(24),
1005 eon(25), -- CLNP over IP [11]
1010 SNMP Working Group [Page 18]
1012 RFC 1213 MIB-II March 1991
1015 nsip(27), -- XNS over IP
1016 slip(28), -- generic SLIP
1017 ultra(29), -- ULTRA technologies
1025 "The type of interface, distinguished according to
1026 the physical/link protocol(s) immediately `below'
1027 the network layer in the protocol stack."
1035 "The size of the largest datagram which can be
1036 sent/received on the interface, specified in
1037 octets. For interfaces that are used for
1038 transmitting network datagrams, this is the size
1039 of the largest network datagram that can be sent
1048 "An estimate of the interface's current bandwidth
1049 in bits per second. For interfaces which do not
1050 vary in bandwidth or for those where no accurate
1051 estimation can be made, this object should contain
1052 the nominal bandwidth."
1055 ifPhysAddress OBJECT-TYPE
1060 "The interface's address at the protocol layer
1061 immediately `below' the network layer in the
1062 protocol stack. For interfaces which do not have
1066 SNMP Working Group [Page 19]
1068 RFC 1213 MIB-II March 1991
1071 such an address (e.g., a serial line), this object
1072 should contain an octet string of zero length."
1075 ifAdminStatus OBJECT-TYPE
1077 up(1), -- ready to pass packets
1079 testing(3) -- in some test mode
1084 "The desired state of the interface. The
1085 testing(3) state indicates that no operational
1086 packets can be passed."
1089 ifOperStatus OBJECT-TYPE
1091 up(1), -- ready to pass packets
1093 testing(3) -- in some test mode
1098 "The current operational state of the interface.
1099 The testing(3) state indicates that no operational
1100 packets can be passed."
1103 ifLastChange OBJECT-TYPE
1108 "The value of sysUpTime at the time the interface
1109 entered its current operational state. If the
1110 current state was entered prior to the last re-
1111 initialization of the local network management
1112 subsystem, then this object contains a zero
1116 ifInOctets OBJECT-TYPE
1122 SNMP Working Group [Page 20]
1124 RFC 1213 MIB-II March 1991
1129 "The total number of octets received on the
1130 interface, including framing characters."
1133 ifInUcastPkts OBJECT-TYPE
1138 "The number of subnetwork-unicast packets
1139 delivered to a higher-layer protocol."
1142 ifInNUcastPkts OBJECT-TYPE
1147 "The number of non-unicast (i.e., subnetwork-
1148 broadcast or subnetwork-multicast) packets
1149 delivered to a higher-layer protocol."
1152 ifInDiscards OBJECT-TYPE
1157 "The number of inbound packets which were chosen
1158 to be discarded even though no errors had been
1159 detected to prevent their being deliverable to a
1160 higher-layer protocol. One possible reason for
1161 discarding such a packet could be to free up
1165 ifInErrors OBJECT-TYPE
1170 "The number of inbound packets that contained
1171 errors preventing them from being deliverable to a
1172 higher-layer protocol."
1178 SNMP Working Group [Page 21]
1180 RFC 1213 MIB-II March 1991
1183 ifInUnknownProtos OBJECT-TYPE
1188 "The number of packets received via the interface
1189 which were discarded because of an unknown or
1190 unsupported protocol."
1193 ifOutOctets OBJECT-TYPE
1198 "The total number of octets transmitted out of the
1199 interface, including framing characters."
1202 ifOutUcastPkts OBJECT-TYPE
1207 "The total number of packets that higher-level
1208 protocols requested be transmitted to a
1209 subnetwork-unicast address, including those that
1210 were discarded or not sent."
1213 ifOutNUcastPkts OBJECT-TYPE
1218 "The total number of packets that higher-level
1219 protocols requested be transmitted to a non-
1220 unicast (i.e., a subnetwork-broadcast or
1221 subnetwork-multicast) address, including those
1222 that were discarded or not sent."
1225 ifOutDiscards OBJECT-TYPE
1230 "The number of outbound packets which were chosen
1234 SNMP Working Group [Page 22]
1236 RFC 1213 MIB-II March 1991
1239 to be discarded even though no errors had been
1240 detected to prevent their being transmitted. One
1241 possible reason for discarding such a packet could
1242 be to free up buffer space."
1245 ifOutErrors OBJECT-TYPE
1250 "The number of outbound packets that could not be
1251 transmitted because of errors."
1254 ifOutQLen OBJECT-TYPE
1259 "The length of the output packet queue (in
1263 ifSpecific OBJECT-TYPE
1264 SYNTAX OBJECT IDENTIFIER
1268 "A reference to MIB definitions specific to the
1269 particular media being used to realize the
1270 interface. For example, if the interface is
1271 realized by an ethernet, then the value of this
1272 object refers to a document defining objects
1273 specific to ethernet. If this information is not
1274 present, its value should be set to the OBJECT
1275 IDENTIFIER { 0 0 }, which is a syntatically valid
1276 object identifier, and any conformant
1277 implementation of ASN.1 and BER must be able to
1278 generate and recognize this value."
1282 -- the Address Translation group
1284 -- Implementation of the Address Translation group is
1285 -- mandatory for all systems. Note however that this group
1286 -- is deprecated by MIB-II. That is, it is being included
1290 SNMP Working Group [Page 23]
1292 RFC 1213 MIB-II March 1991
1295 -- solely for compatibility with MIB-I nodes, and will most
1296 -- likely be excluded from MIB-III nodes. From MIB-II and
1297 -- onwards, each network protocol group contains its own
1298 -- address translation tables.
1300 -- The Address Translation group contains one table which is
1301 -- the union across all interfaces of the translation tables
1302 -- for converting a NetworkAddress (e.g., an IP address) into
1303 -- a subnetwork-specific address. For lack of a better term,
1304 -- this document refers to such a subnetwork-specific address
1305 -- as a `physical' address.
1307 -- Examples of such translation tables are: for broadcast
1308 -- media where ARP is in use, the translation table is
1309 -- equivalent to the ARP cache; or, on an X.25 network where
1310 -- non-algorithmic translation to X.121 addresses is
1311 -- required, the translation table contains the
1312 -- NetworkAddress to X.121 address equivalences.
1315 SYNTAX SEQUENCE OF AtEntry
1316 ACCESS not-accessible
1319 "The Address Translation tables contain the
1320 NetworkAddress to `physical' address equivalences.
1321 Some interfaces do not use translation tables for
1322 determining address equivalences (e.g., DDN-X.25
1323 has an algorithmic method); if all interfaces are
1324 of this type, then the Address Translation table
1325 is empty, i.e., has zero entries."
1330 ACCESS not-accessible
1333 "Each entry contains one NetworkAddress to
1334 `physical' address equivalence."
1346 SNMP Working Group [Page 24]
1348 RFC 1213 MIB-II March 1991
1357 atIfIndex OBJECT-TYPE
1362 "The interface on which this entry's equivalence
1363 is effective. The interface identified by a
1364 particular value of this index is the same
1365 interface as identified by the same value of
1369 atPhysAddress OBJECT-TYPE
1374 "The media-dependent `physical' address.
1376 Setting this object to a null string (one of zero
1377 length) has the effect of invaliding the
1378 corresponding entry in the atTable object. That
1379 is, it effectively dissasociates the interface
1380 identified with said entry from the mapping
1381 identified with said entry. It is an
1382 implementation-specific matter as to whether the
1383 agent removes an invalidated entry from the table.
1384 Accordingly, management stations must be prepared
1385 to receive tabular information from agents that
1386 corresponds to entries not currently in use.
1387 Proper interpretation of such entries requires
1388 examination of the relevant atPhysAddress object."
1391 atNetAddress OBJECT-TYPE
1392 SYNTAX NetworkAddress
1396 "The NetworkAddress (e.g., the IP address)
1397 corresponding to the media-dependent `physical'
1402 SNMP Working Group [Page 25]
1404 RFC 1213 MIB-II March 1991
1412 -- Implementation of the IP group is mandatory for all
1415 ipForwarding OBJECT-TYPE
1417 forwarding(1), -- acting as a gateway
1418 not-forwarding(2) -- NOT acting as a gateway
1423 "The indication of whether this entity is acting
1424 as an IP gateway in respect to the forwarding of
1425 datagrams received by, but not addressed to, this
1426 entity. IP gateways forward datagrams. IP hosts
1427 do not (except those source-routed via the host).
1429 Note that for some managed nodes, this object may
1430 take on only a subset of the values possible.
1431 Accordingly, it is appropriate for an agent to
1432 return a `badValue' response if a management
1433 station attempts to change this object to an
1434 inappropriate value."
1437 ipDefaultTTL OBJECT-TYPE
1442 "The default value inserted into the Time-To-Live
1443 field of the IP header of datagrams originated at
1444 this entity, whenever a TTL value is not supplied
1445 by the transport layer protocol."
1448 ipInReceives OBJECT-TYPE
1453 "The total number of input datagrams received from
1454 interfaces, including those received in error."
1458 SNMP Working Group [Page 26]
1460 RFC 1213 MIB-II March 1991
1465 ipInHdrErrors OBJECT-TYPE
1470 "The number of input datagrams discarded due to
1471 errors in their IP headers, including bad
1472 checksums, version number mismatch, other format
1473 errors, time-to-live exceeded, errors discovered
1474 in processing their IP options, etc."
1477 ipInAddrErrors OBJECT-TYPE
1482 "The number of input datagrams discarded because
1483 the IP address in their IP header's destination
1484 field was not a valid address to be received at
1485 this entity. This count includes invalid
1486 addresses (e.g., 0.0.0.0) and addresses of
1487 unsupported Classes (e.g., Class E). For entities
1488 which are not IP Gateways and therefore do not
1489 forward datagrams, this counter includes datagrams
1490 discarded because the destination address was not
1494 ipForwDatagrams OBJECT-TYPE
1499 "The number of input datagrams for which this
1500 entity was not their final IP destination, as a
1501 result of which an attempt was made to find a
1502 route to forward them to that final destination.
1503 In entities which do not act as IP Gateways, this
1504 counter will include only those packets which were
1505 Source-Routed via this entity, and the Source-
1506 Route option processing was successful."
1509 ipInUnknownProtos OBJECT-TYPE
1514 SNMP Working Group [Page 27]
1516 RFC 1213 MIB-II March 1991
1522 "The number of locally-addressed datagrams
1523 received successfully but discarded because of an
1524 unknown or unsupported protocol."
1527 ipInDiscards OBJECT-TYPE
1532 "The number of input IP datagrams for which no
1533 problems were encountered to prevent their
1534 continued processing, but which were discarded
1535 (e.g., for lack of buffer space). Note that this
1536 counter does not include any datagrams discarded
1537 while awaiting re-assembly."
1540 ipInDelivers OBJECT-TYPE
1545 "The total number of input datagrams successfully
1546 delivered to IP user-protocols (including ICMP)."
1549 ipOutRequests OBJECT-TYPE
1554 "The total number of IP datagrams which local IP
1555 user-protocols (including ICMP) supplied to IP in
1556 requests for transmission. Note that this counter
1557 does not include any datagrams counted in
1561 ipOutDiscards OBJECT-TYPE
1566 "The number of output IP datagrams for which no
1570 SNMP Working Group [Page 28]
1572 RFC 1213 MIB-II March 1991
1575 problem was encountered to prevent their
1576 transmission to their destination, but which were
1577 discarded (e.g., for lack of buffer space). Note
1578 that this counter would include datagrams counted
1579 in ipForwDatagrams if any such packets met this
1580 (discretionary) discard criterion."
1583 ipOutNoRoutes OBJECT-TYPE
1588 "The number of IP datagrams discarded because no
1589 route could be found to transmit them to their
1590 destination. Note that this counter includes any
1591 packets counted in ipForwDatagrams which meet this
1592 `no-route' criterion. Note that this includes any
1593 datagarms which a host cannot route because all of
1594 its default gateways are down."
1597 ipReasmTimeout OBJECT-TYPE
1602 "The maximum number of seconds which received
1603 fragments are held while they are awaiting
1604 reassembly at this entity."
1607 ipReasmReqds OBJECT-TYPE
1612 "The number of IP fragments received which needed
1613 to be reassembled at this entity."
1616 ipReasmOKs OBJECT-TYPE
1621 "The number of IP datagrams successfully re-
1626 SNMP Working Group [Page 29]
1628 RFC 1213 MIB-II March 1991
1633 ipReasmFails OBJECT-TYPE
1638 "The number of failures detected by the IP re-
1639 assembly algorithm (for whatever reason: timed
1640 out, errors, etc). Note that this is not
1641 necessarily a count of discarded IP fragments
1642 since some algorithms (notably the algorithm in
1643 RFC 815) can lose track of the number of fragments
1644 by combining them as they are received."
1647 ipFragOKs OBJECT-TYPE
1652 "The number of IP datagrams that have been
1653 successfully fragmented at this entity."
1656 ipFragFails OBJECT-TYPE
1661 "The number of IP datagrams that have been
1662 discarded because they needed to be fragmented at
1663 this entity but could not be, e.g., because their
1664 Don't Fragment flag was set."
1667 ipFragCreates OBJECT-TYPE
1672 "The number of IP datagram fragments that have
1673 been generated as a result of fragmentation at
1682 SNMP Working Group [Page 30]
1684 RFC 1213 MIB-II March 1991
1687 -- the IP address table
1689 -- The IP address table contains this entity's IP addressing
1692 ipAddrTable OBJECT-TYPE
1693 SYNTAX SEQUENCE OF IpAddrEntry
1694 ACCESS not-accessible
1697 "The table of addressing information relevant to
1698 this entity's IP addresses."
1701 ipAddrEntry OBJECT-TYPE
1703 ACCESS not-accessible
1706 "The addressing information for one of this
1707 entity's IP addresses."
1708 INDEX { ipAdEntAddr }
1709 ::= { ipAddrTable 1 }
1725 ipAdEntAddr OBJECT-TYPE
1730 "The IP address to which this entry's addressing
1731 information pertains."
1732 ::= { ipAddrEntry 1 }
1738 SNMP Working Group [Page 31]
1740 RFC 1213 MIB-II March 1991
1743 ipAdEntIfIndex OBJECT-TYPE
1748 "The index value which uniquely identifies the
1749 interface to which this entry is applicable. The
1750 interface identified by a particular value of this
1751 index is the same interface as identified by the
1752 same value of ifIndex."
1753 ::= { ipAddrEntry 2 }
1755 ipAdEntNetMask OBJECT-TYPE
1760 "The subnet mask associated with the IP address of
1761 this entry. The value of the mask is an IP
1762 address with all the network bits set to 1 and all
1763 the hosts bits set to 0."
1764 ::= { ipAddrEntry 3 }
1766 ipAdEntBcastAddr OBJECT-TYPE
1771 "The value of the least-significant bit in the IP
1772 broadcast address used for sending datagrams on
1773 the (logical) interface associated with the IP
1774 address of this entry. For example, when the
1775 Internet standard all-ones broadcast address is
1776 used, the value will be 1. This value applies to
1777 both the subnet and network broadcasts addresses
1778 used by the entity on this (logical) interface."
1779 ::= { ipAddrEntry 4 }
1781 ipAdEntReasmMaxSize OBJECT-TYPE
1782 SYNTAX INTEGER (0..65535)
1786 "The size of the largest IP datagram which this
1787 entity can re-assemble from incoming IP fragmented
1788 datagrams received on this interface."
1789 ::= { ipAddrEntry 5 }
1794 SNMP Working Group [Page 32]
1796 RFC 1213 MIB-II March 1991
1799 -- the IP routing table
1801 -- The IP routing table contains an entry for each route
1802 -- presently known to this entity.
1804 ipRouteTable OBJECT-TYPE
1805 SYNTAX SEQUENCE OF IpRouteEntry
1806 ACCESS not-accessible
1809 "This entity's IP Routing table."
1812 ipRouteEntry OBJECT-TYPE
1814 ACCESS not-accessible
1817 "A route to a particular destination."
1818 INDEX { ipRouteDest }
1819 ::= { ipRouteTable 1 }
1850 SNMP Working Group [Page 33]
1852 RFC 1213 MIB-II March 1991
1859 ipRouteDest OBJECT-TYPE
1864 "The destination IP address of this route. An
1865 entry with a value of 0.0.0.0 is considered a
1866 default route. Multiple routes to a single
1867 destination can appear in the table, but access to
1868 such multiple entries is dependent on the table-
1869 access mechanisms defined by the network
1870 management protocol in use."
1871 ::= { ipRouteEntry 1 }
1873 ipRouteIfIndex OBJECT-TYPE
1878 "The index value which uniquely identifies the
1879 local interface through which the next hop of this
1880 route should be reached. The interface identified
1881 by a particular value of this index is the same
1882 interface as identified by the same value of
1884 ::= { ipRouteEntry 2 }
1886 ipRouteMetric1 OBJECT-TYPE
1891 "The primary routing metric for this route. The
1892 semantics of this metric are determined by the
1893 routing-protocol specified in the route's
1894 ipRouteProto value. If this metric is not used,
1895 its value should be set to -1."
1896 ::= { ipRouteEntry 3 }
1898 ipRouteMetric2 OBJECT-TYPE
1906 SNMP Working Group [Page 34]
1908 RFC 1213 MIB-II March 1991
1911 "An alternate routing metric for this route. The
1912 semantics of this metric are determined by the
1913 routing-protocol specified in the route's
1914 ipRouteProto value. If this metric is not used,
1915 its value should be set to -1."
1916 ::= { ipRouteEntry 4 }
1918 ipRouteMetric3 OBJECT-TYPE
1923 "An alternate routing metric for this route. The
1924 semantics of this metric are determined by the
1925 routing-protocol specified in the route's
1926 ipRouteProto value. If this metric is not used,
1927 its value should be set to -1."
1928 ::= { ipRouteEntry 5 }
1930 ipRouteMetric4 OBJECT-TYPE
1935 "An alternate routing metric for this route. The
1936 semantics of this metric are determined by the
1937 routing-protocol specified in the route's
1938 ipRouteProto value. If this metric is not used,
1939 its value should be set to -1."
1940 ::= { ipRouteEntry 6 }
1942 ipRouteNextHop OBJECT-TYPE
1947 "The IP address of the next hop of this route.
1948 (In the case of a route bound to an interface
1949 which is realized via a broadcast media, the value
1950 of this field is the agent's IP address on that
1952 ::= { ipRouteEntry 7 }
1954 ipRouteType OBJECT-TYPE
1956 other(1), -- none of the following
1958 invalid(2), -- an invalidated route
1962 SNMP Working Group [Page 35]
1964 RFC 1213 MIB-II March 1991
1967 -- route to directly
1968 direct(3), -- connected (sub-)network
1970 -- route to a non-local
1971 indirect(4) -- host/network/sub-network
1976 "The type of route. Note that the values
1977 direct(3) and indirect(4) refer to the notion of
1978 direct and indirect routing in the IP
1981 Setting this object to the value invalid(2) has
1982 the effect of invalidating the corresponding entry
1983 in the ipRouteTable object. That is, it
1984 effectively dissasociates the destination
1985 identified with said entry from the route
1986 identified with said entry. It is an
1987 implementation-specific matter as to whether the
1988 agent removes an invalidated entry from the table.
1989 Accordingly, management stations must be prepared
1990 to receive tabular information from agents that
1991 corresponds to entries not currently in use.
1992 Proper interpretation of such entries requires
1993 examination of the relevant ipRouteType object."
1994 ::= { ipRouteEntry 8 }
1996 ipRouteProto OBJECT-TYPE
1998 other(1), -- none of the following
2000 -- non-protocol information,
2001 -- e.g., manually configured
2002 local(2), -- entries
2004 -- set via a network
2005 netmgmt(3), -- management protocol
2007 -- obtained via ICMP,
2008 icmp(4), -- e.g., Redirect
2010 -- the remaining values are
2011 -- all gateway routing
2018 SNMP Working Group [Page 36]
2020 RFC 1213 MIB-II March 1991
2035 "The routing mechanism via which this route was
2036 learned. Inclusion of values for gateway routing
2037 protocols is not intended to imply that hosts
2038 should support those protocols."
2039 ::= { ipRouteEntry 9 }
2041 ipRouteAge OBJECT-TYPE
2046 "The number of seconds since this route was last
2047 updated or otherwise determined to be correct.
2048 Note that no semantics of `too old' can be implied
2049 except through knowledge of the routing protocol
2050 by which the route was learned."
2051 ::= { ipRouteEntry 10 }
2053 ipRouteMask OBJECT-TYPE
2058 "Indicate the mask to be logical-ANDed with the
2059 destination address before being compared to the
2060 value in the ipRouteDest field. For those systems
2061 that do not support arbitrary subnet masks, an
2062 agent constructs the value of the ipRouteMask by
2063 determining whether the value of the correspondent
2064 ipRouteDest field belong to a class-A, B, or C
2065 network, and then using one of:
2070 255.255.255.0 class-C
2074 SNMP Working Group [Page 37]
2076 RFC 1213 MIB-II March 1991
2079 If the value of the ipRouteDest is 0.0.0.0 (a
2080 default route), then the mask value is also
2081 0.0.0.0. It should be noted that all IP routing
2082 subsystems implicitly use this mechanism."
2083 ::= { ipRouteEntry 11 }
2085 ipRouteMetric5 OBJECT-TYPE
2090 "An alternate routing metric for this route. The
2091 semantics of this metric are determined by the
2092 routing-protocol specified in the route's
2093 ipRouteProto value. If this metric is not used,
2094 its value should be set to -1."
2095 ::= { ipRouteEntry 12 }
2097 ipRouteInfo OBJECT-TYPE
2098 SYNTAX OBJECT IDENTIFIER
2102 "A reference to MIB definitions specific to the
2103 particular routing protocol which is responsible
2104 for this route, as determined by the value
2105 specified in the route's ipRouteProto value. If
2106 this information is not present, its value should
2107 be set to the OBJECT IDENTIFIER { 0 0 }, which is
2108 a syntatically valid object identifier, and any
2109 conformant implementation of ASN.1 and BER must be
2110 able to generate and recognize this value."
2111 ::= { ipRouteEntry 13 }
2114 -- the IP Address Translation table
2116 -- The IP address translation table contain the IpAddress to
2117 -- `physical' address equivalences. Some interfaces do not
2118 -- use translation tables for determining address
2119 -- equivalences (e.g., DDN-X.25 has an algorithmic method);
2120 -- if all interfaces are of this type, then the Address
2121 -- Translation table is empty, i.e., has zero entries.
2123 ipNetToMediaTable OBJECT-TYPE
2124 SYNTAX SEQUENCE OF IpNetToMediaEntry
2125 ACCESS not-accessible
2130 SNMP Working Group [Page 38]
2132 RFC 1213 MIB-II March 1991
2136 "The IP Address Translation table used for mapping
2137 from IP addresses to physical addresses."
2140 ipNetToMediaEntry OBJECT-TYPE
2141 SYNTAX IpNetToMediaEntry
2142 ACCESS not-accessible
2145 "Each entry contains one IpAddress to `physical'
2146 address equivalence."
2147 INDEX { ipNetToMediaIfIndex,
2148 ipNetToMediaNetAddress }
2149 ::= { ipNetToMediaTable 1 }
2151 IpNetToMediaEntry ::=
2155 ipNetToMediaPhysAddress
2157 ipNetToMediaNetAddress
2163 ipNetToMediaIfIndex OBJECT-TYPE
2168 "The interface on which this entry's equivalence
2169 is effective. The interface identified by a
2170 particular value of this index is the same
2171 interface as identified by the same value of
2173 ::= { ipNetToMediaEntry 1 }
2175 ipNetToMediaPhysAddress OBJECT-TYPE
2180 "The media-dependent `physical' address."
2181 ::= { ipNetToMediaEntry 2 }
2186 SNMP Working Group [Page 39]
2188 RFC 1213 MIB-II March 1991
2191 ipNetToMediaNetAddress OBJECT-TYPE
2196 "The IpAddress corresponding to the media-
2197 dependent `physical' address."
2198 ::= { ipNetToMediaEntry 3 }
2200 ipNetToMediaType OBJECT-TYPE
2202 other(1), -- none of the following
2203 invalid(2), -- an invalidated mapping
2210 "The type of mapping.
2212 Setting this object to the value invalid(2) has
2213 the effect of invalidating the corresponding entry
2214 in the ipNetToMediaTable. That is, it effectively
2215 dissasociates the interface identified with said
2216 entry from the mapping identified with said entry.
2217 It is an implementation-specific matter as to
2218 whether the agent removes an invalidated entry
2219 from the table. Accordingly, management stations
2220 must be prepared to receive tabular information
2221 from agents that corresponds to entries not
2222 currently in use. Proper interpretation of such
2223 entries requires examination of the relevant
2224 ipNetToMediaType object."
2225 ::= { ipNetToMediaEntry 4 }
2228 -- additional IP objects
2230 ipRoutingDiscards OBJECT-TYPE
2235 "The number of routing entries which were chosen
2236 to be discarded even though they are valid. One
2237 possible reason for discarding such an entry could
2238 be to free-up buffer space for other routing
2242 SNMP Working Group [Page 40]
2244 RFC 1213 MIB-II March 1991
2253 -- Implementation of the ICMP group is mandatory for all
2256 icmpInMsgs OBJECT-TYPE
2261 "The total number of ICMP messages which the
2262 entity received. Note that this counter includes
2263 all those counted by icmpInErrors."
2266 icmpInErrors OBJECT-TYPE
2271 "The number of ICMP messages which the entity
2272 received but determined as having ICMP-specific
2273 errors (bad ICMP checksums, bad length, etc.)."
2276 icmpInDestUnreachs OBJECT-TYPE
2281 "The number of ICMP Destination Unreachable
2285 icmpInTimeExcds OBJECT-TYPE
2290 "The number of ICMP Time Exceeded messages
2298 SNMP Working Group [Page 41]
2300 RFC 1213 MIB-II March 1991
2303 icmpInParmProbs OBJECT-TYPE
2308 "The number of ICMP Parameter Problem messages
2312 icmpInSrcQuenchs OBJECT-TYPE
2317 "The number of ICMP Source Quench messages
2321 icmpInRedirects OBJECT-TYPE
2326 "The number of ICMP Redirect messages received."
2329 icmpInEchos OBJECT-TYPE
2334 "The number of ICMP Echo (request) messages
2338 icmpInEchoReps OBJECT-TYPE
2343 "The number of ICMP Echo Reply messages received."
2346 icmpInTimestamps OBJECT-TYPE
2354 SNMP Working Group [Page 42]
2356 RFC 1213 MIB-II March 1991
2359 "The number of ICMP Timestamp (request) messages
2363 icmpInTimestampReps OBJECT-TYPE
2368 "The number of ICMP Timestamp Reply messages
2372 icmpInAddrMasks OBJECT-TYPE
2377 "The number of ICMP Address Mask Request messages
2381 icmpInAddrMaskReps OBJECT-TYPE
2386 "The number of ICMP Address Mask Reply messages
2390 icmpOutMsgs OBJECT-TYPE
2395 "The total number of ICMP messages which this
2396 entity attempted to send. Note that this counter
2397 includes all those counted by icmpOutErrors."
2400 icmpOutErrors OBJECT-TYPE
2405 "The number of ICMP messages which this entity did
2406 not send due to problems discovered within ICMP
2410 SNMP Working Group [Page 43]
2412 RFC 1213 MIB-II March 1991
2415 such as a lack of buffers. This value should not
2416 include errors discovered outside the ICMP layer
2417 such as the inability of IP to route the resultant
2418 datagram. In some implementations there may be no
2419 types of error which contribute to this counter's
2423 icmpOutDestUnreachs OBJECT-TYPE
2428 "The number of ICMP Destination Unreachable
2432 icmpOutTimeExcds OBJECT-TYPE
2437 "The number of ICMP Time Exceeded messages sent."
2440 icmpOutParmProbs OBJECT-TYPE
2445 "The number of ICMP Parameter Problem messages
2449 icmpOutSrcQuenchs OBJECT-TYPE
2454 "The number of ICMP Source Quench messages sent."
2457 icmpOutRedirects OBJECT-TYPE
2462 "The number of ICMP Redirect messages sent. For a
2466 SNMP Working Group [Page 44]
2468 RFC 1213 MIB-II March 1991
2471 host, this object will always be zero, since hosts
2472 do not send redirects."
2475 icmpOutEchos OBJECT-TYPE
2480 "The number of ICMP Echo (request) messages sent."
2483 icmpOutEchoReps OBJECT-TYPE
2488 "The number of ICMP Echo Reply messages sent."
2491 icmpOutTimestamps OBJECT-TYPE
2496 "The number of ICMP Timestamp (request) messages
2500 icmpOutTimestampReps OBJECT-TYPE
2505 "The number of ICMP Timestamp Reply messages
2509 icmpOutAddrMasks OBJECT-TYPE
2514 "The number of ICMP Address Mask Request messages
2522 SNMP Working Group [Page 45]
2524 RFC 1213 MIB-II March 1991
2527 icmpOutAddrMaskReps OBJECT-TYPE
2532 "The number of ICMP Address Mask Reply messages
2539 -- Implementation of the TCP group is mandatory for all
2540 -- systems that implement the TCP.
2542 -- Note that instances of object types that represent
2543 -- information about a particular TCP connection are
2544 -- transient; they persist only as long as the connection
2547 tcpRtoAlgorithm OBJECT-TYPE
2549 other(1), -- none of the following
2551 constant(2), -- a constant rto
2552 rsre(3), -- MIL-STD-1778, Appendix B
2553 vanj(4) -- Van Jacobson's algorithm [10]
2558 "The algorithm used to determine the timeout value
2559 used for retransmitting unacknowledged octets."
2562 tcpRtoMin OBJECT-TYPE
2567 "The minimum value permitted by a TCP
2568 implementation for the retransmission timeout,
2569 measured in milliseconds. More refined semantics
2570 for objects of this type depend upon the algorithm
2571 used to determine the retransmission timeout. In
2572 particular, when the timeout algorithm is rsre(3),
2573 an object of this type has the semantics of the
2574 LBOUND quantity described in RFC 793."
2578 SNMP Working Group [Page 46]
2580 RFC 1213 MIB-II March 1991
2586 tcpRtoMax OBJECT-TYPE
2591 "The maximum value permitted by a TCP
2592 implementation for the retransmission timeout,
2593 measured in milliseconds. More refined semantics
2594 for objects of this type depend upon the algorithm
2595 used to determine the retransmission timeout. In
2596 particular, when the timeout algorithm is rsre(3),
2597 an object of this type has the semantics of the
2598 UBOUND quantity described in RFC 793."
2601 tcpMaxConn OBJECT-TYPE
2606 "The limit on the total number of TCP connections
2607 the entity can support. In entities where the
2608 maximum number of connections is dynamic, this
2609 object should contain the value -1."
2612 tcpActiveOpens OBJECT-TYPE
2617 "The number of times TCP connections have made a
2618 direct transition to the SYN-SENT state from the
2622 tcpPassiveOpens OBJECT-TYPE
2627 "The number of times TCP connections have made a
2628 direct transition to the SYN-RCVD state from the
2634 SNMP Working Group [Page 47]
2636 RFC 1213 MIB-II March 1991
2639 tcpAttemptFails OBJECT-TYPE
2644 "The number of times TCP connections have made a
2645 direct transition to the CLOSED state from either
2646 the SYN-SENT state or the SYN-RCVD state, plus the
2647 number of times TCP connections have made a direct
2648 transition to the LISTEN state from the SYN-RCVD
2652 tcpEstabResets OBJECT-TYPE
2657 "The number of times TCP connections have made a
2658 direct transition to the CLOSED state from either
2659 the ESTABLISHED state or the CLOSE-WAIT state."
2662 tcpCurrEstab OBJECT-TYPE
2667 "The number of TCP connections for which the
2668 current state is either ESTABLISHED or CLOSE-
2672 tcpInSegs OBJECT-TYPE
2677 "The total number of segments received, including
2678 those received in error. This count includes
2679 segments received on currently established
2683 tcpOutSegs OBJECT-TYPE
2690 SNMP Working Group [Page 48]
2692 RFC 1213 MIB-II March 1991
2696 "The total number of segments sent, including
2697 those on current connections but excluding those
2698 containing only retransmitted octets."
2701 tcpRetransSegs OBJECT-TYPE
2706 "The total number of segments retransmitted - that
2707 is, the number of TCP segments transmitted
2708 containing one or more previously transmitted
2713 -- the TCP Connection table
2715 -- The TCP connection table contains information about this
2716 -- entity's existing TCP connections.
2718 tcpConnTable OBJECT-TYPE
2719 SYNTAX SEQUENCE OF TcpConnEntry
2720 ACCESS not-accessible
2723 "A table containing TCP connection-specific
2727 tcpConnEntry OBJECT-TYPE
2729 ACCESS not-accessible
2732 "Information about a particular current TCP
2733 connection. An object of this type is transient,
2734 in that it ceases to exist when (or soon after)
2735 the connection makes the transition to the CLOSED
2737 INDEX { tcpConnLocalAddress,
2741 ::= { tcpConnTable 1 }
2746 SNMP Working Group [Page 49]
2748 RFC 1213 MIB-II March 1991
2765 tcpConnState OBJECT-TYPE
2783 "The state of this TCP connection.
2785 The only value which may be set by a management
2786 station is deleteTCB(12). Accordingly, it is
2787 appropriate for an agent to return a `badValue'
2788 response if a management station attempts to set
2789 this object to any other value.
2791 If a management station sets this object to the
2792 value deleteTCB(12), then this has the effect of
2793 deleting the TCB (as defined in RFC 793) of the
2794 corresponding connection on the managed node,
2795 resulting in immediate termination of the
2798 As an implementation-specific option, a RST
2802 SNMP Working Group [Page 50]
2804 RFC 1213 MIB-II March 1991
2807 segment may be sent from the managed node to the
2808 other TCP endpoint (note however that RST segments
2809 are not sent reliably)."
2810 ::= { tcpConnEntry 1 }
2812 tcpConnLocalAddress OBJECT-TYPE
2817 "The local IP address for this TCP connection. In
2818 the case of a connection in the listen state which
2819 is willing to accept connections for any IP
2820 interface associated with the node, the value
2822 ::= { tcpConnEntry 2 }
2824 tcpConnLocalPort OBJECT-TYPE
2825 SYNTAX INTEGER (0..65535)
2829 "The local port number for this TCP connection."
2830 ::= { tcpConnEntry 3 }
2832 tcpConnRemAddress OBJECT-TYPE
2837 "The remote IP address for this TCP connection."
2838 ::= { tcpConnEntry 4 }
2840 tcpConnRemPort OBJECT-TYPE
2841 SYNTAX INTEGER (0..65535)
2845 "The remote port number for this TCP connection."
2846 ::= { tcpConnEntry 5 }
2849 -- additional TCP objects
2851 tcpInErrs OBJECT-TYPE
2858 SNMP Working Group [Page 51]
2860 RFC 1213 MIB-II March 1991
2864 "The total number of segments received in error
2865 (e.g., bad TCP checksums)."
2868 tcpOutRsts OBJECT-TYPE
2873 "The number of TCP segments sent containing the
2880 -- Implementation of the UDP group is mandatory for all
2881 -- systems which implement the UDP.
2883 udpInDatagrams OBJECT-TYPE
2888 "The total number of UDP datagrams delivered to
2892 udpNoPorts OBJECT-TYPE
2897 "The total number of received UDP datagrams for
2898 which there was no application at the destination
2902 udpInErrors OBJECT-TYPE
2907 "The number of received UDP datagrams that could
2908 not be delivered for reasons other than the lack
2909 of an application at the destination port."
2914 SNMP Working Group [Page 52]
2916 RFC 1213 MIB-II March 1991
2919 udpOutDatagrams OBJECT-TYPE
2924 "The total number of UDP datagrams sent from this
2929 -- the UDP Listener table
2931 -- The UDP listener table contains information about this
2932 -- entity's UDP end-points on which a local application is
2933 -- currently accepting datagrams.
2935 udpTable OBJECT-TYPE
2936 SYNTAX SEQUENCE OF UdpEntry
2937 ACCESS not-accessible
2940 "A table containing UDP listener information."
2943 udpEntry OBJECT-TYPE
2945 ACCESS not-accessible
2948 "Information about a particular current UDP
2950 INDEX { udpLocalAddress, udpLocalPort }
2961 udpLocalAddress OBJECT-TYPE
2966 "The local IP address for this UDP listener. In
2970 SNMP Working Group [Page 53]
2972 RFC 1213 MIB-II March 1991
2975 the case of a UDP listener which is willing to
2976 accept datagrams for any IP interface associated
2977 with the node, the value 0.0.0.0 is used."
2980 udpLocalPort OBJECT-TYPE
2981 SYNTAX INTEGER (0..65535)
2985 "The local port number for this UDP listener."
2991 -- Implementation of the EGP group is mandatory for all
2992 -- systems which implement the EGP.
2994 egpInMsgs OBJECT-TYPE
2999 "The number of EGP messages received without
3003 egpInErrors OBJECT-TYPE
3008 "The number of EGP messages received that proved
3012 egpOutMsgs OBJECT-TYPE
3017 "The total number of locally generated EGP
3021 egpOutErrors OBJECT-TYPE
3026 SNMP Working Group [Page 54]
3028 RFC 1213 MIB-II March 1991
3034 "The number of locally generated EGP messages not
3035 sent due to resource limitations within an EGP
3040 -- the EGP Neighbor table
3042 -- The EGP neighbor table contains information about this
3043 -- entity's EGP neighbors.
3045 egpNeighTable OBJECT-TYPE
3046 SYNTAX SEQUENCE OF EgpNeighEntry
3047 ACCESS not-accessible
3050 "The EGP neighbor table."
3053 egpNeighEntry OBJECT-TYPE
3054 SYNTAX EgpNeighEntry
3055 ACCESS not-accessible
3058 "Information about this entity's relationship with
3059 a particular EGP neighbor."
3060 INDEX { egpNeighAddr }
3061 ::= { egpNeighTable 1 }
3082 SNMP Working Group [Page 55]
3084 RFC 1213 MIB-II March 1991
3095 egpNeighIntervalHello
3097 egpNeighIntervalPoll
3101 egpNeighEventTrigger
3105 egpNeighState OBJECT-TYPE
3116 "The EGP state of the local system with respect to
3117 this entry's EGP neighbor. Each EGP state is
3118 represented by a value that is one greater than
3119 the numerical value associated with said state in
3121 ::= { egpNeighEntry 1 }
3123 egpNeighAddr OBJECT-TYPE
3128 "The IP address of this entry's EGP neighbor."
3129 ::= { egpNeighEntry 2 }
3131 egpNeighAs OBJECT-TYPE
3138 SNMP Working Group [Page 56]
3140 RFC 1213 MIB-II March 1991
3144 "The autonomous system of this EGP peer. Zero
3145 should be specified if the autonomous system
3146 number of the neighbor is not yet known."
3147 ::= { egpNeighEntry 3 }
3149 egpNeighInMsgs OBJECT-TYPE
3154 "The number of EGP messages received without error
3155 from this EGP peer."
3156 ::= { egpNeighEntry 4 }
3158 egpNeighInErrs OBJECT-TYPE
3163 "The number of EGP messages received from this EGP
3164 peer that proved to be in error (e.g., bad EGP
3166 ::= { egpNeighEntry 5 }
3168 egpNeighOutMsgs OBJECT-TYPE
3173 "The number of locally generated EGP messages to
3175 ::= { egpNeighEntry 6 }
3177 egpNeighOutErrs OBJECT-TYPE
3182 "The number of locally generated EGP messages not
3183 sent to this EGP peer due to resource limitations
3184 within an EGP entity."
3185 ::= { egpNeighEntry 7 }
3187 egpNeighInErrMsgs OBJECT-TYPE
3194 SNMP Working Group [Page 57]
3196 RFC 1213 MIB-II March 1991
3200 "The number of EGP-defined error messages received
3201 from this EGP peer."
3202 ::= { egpNeighEntry 8 }
3204 egpNeighOutErrMsgs OBJECT-TYPE
3209 "The number of EGP-defined error messages sent to
3211 ::= { egpNeighEntry 9 }
3213 egpNeighStateUps OBJECT-TYPE
3218 "The number of EGP state transitions to the UP
3219 state with this EGP peer."
3220 ::= { egpNeighEntry 10 }
3222 egpNeighStateDowns OBJECT-TYPE
3227 "The number of EGP state transitions from the UP
3228 state to any other state with this EGP peer."
3229 ::= { egpNeighEntry 11 }
3231 egpNeighIntervalHello OBJECT-TYPE
3236 "The interval between EGP Hello command
3237 retransmissions (in hundredths of a second). This
3238 represents the t1 timer as defined in RFC 904."
3239 ::= { egpNeighEntry 12 }
3241 egpNeighIntervalPoll OBJECT-TYPE
3246 "The interval between EGP poll command
3250 SNMP Working Group [Page 58]
3252 RFC 1213 MIB-II March 1991
3255 retransmissions (in hundredths of a second). This
3256 represents the t3 timer as defined in RFC 904."
3257 ::= { egpNeighEntry 13 }
3259 egpNeighMode OBJECT-TYPE
3260 SYNTAX INTEGER { active(1), passive(2) }
3264 "The polling mode of this EGP entity, either
3266 ::= { egpNeighEntry 14 }
3268 egpNeighEventTrigger OBJECT-TYPE
3269 SYNTAX INTEGER { start(1), stop(2) }
3273 "A control variable used to trigger operator-
3274 initiated Start and Stop events. When read, this
3275 variable always returns the most recent value that
3276 egpNeighEventTrigger was set to. If it has not
3277 been set since the last initialization of the
3278 network management subsystem on the node, it
3279 returns a value of `stop'.
3281 When set, this variable causes a Start or Stop
3282 event on the specified neighbor, as specified on
3283 pages 8-10 of RFC 904. Briefly, a Start event
3284 causes an Idle peer to begin neighbor acquisition
3285 and a non-Idle peer to reinitiate neighbor
3286 acquisition. A stop event causes a non-Idle peer
3287 to return to the Idle state until a Start event
3288 occurs, either via egpNeighEventTrigger or
3290 ::= { egpNeighEntry 15 }
3293 -- additional EGP objects
3300 "The autonomous system number of this EGP entity."
3306 SNMP Working Group [Page 59]
3308 RFC 1213 MIB-II March 1991
3311 -- the Transmission group
3313 -- Based on the transmission media underlying each interface
3314 -- on a system, the corresponding portion of the Transmission
3315 -- group is mandatory for that system.
3317 -- When Internet-standard definitions for managing
3318 -- transmission media are defined, the transmission group is
3319 -- used to provide a prefix for the names of those objects.
3321 -- Typically, such definitions reside in the experimental
3322 -- portion of the MIB until they are "proven", then as a
3323 -- part of the Internet standardization process, the
3324 -- definitions are accordingly elevated and a new object
3325 -- identifier, under the transmission group is defined. By
3326 -- convention, the name assigned is:
3328 -- type OBJECT IDENTIFIER ::= { transmission number }
3330 -- where "type" is the symbolic value used for the media in
3331 -- the ifType column of the ifTable object, and "number" is
3332 -- the actual integer value corresponding to the symbol.
3337 -- Implementation of the SNMP group is mandatory for all
3338 -- systems which support an SNMP protocol entity. Some of
3339 -- the objects defined below will be zero-valued in those
3340 -- SNMP implementations that are optimized to support only
3341 -- those functions specific to either a management agent or
3342 -- a management station. In particular, it should be
3343 -- observed that the objects below refer to an SNMP entity,
3344 -- and there may be several SNMP entities residing on a
3345 -- managed node (e.g., if the node is hosting acting as
3346 -- a management station).
3348 snmpInPkts OBJECT-TYPE
3353 "The total number of Messages delivered to the
3354 SNMP entity from the transport service."
3357 snmpOutPkts OBJECT-TYPE
3362 SNMP Working Group [Page 60]
3364 RFC 1213 MIB-II March 1991
3370 "The total number of SNMP Messages which were
3371 passed from the SNMP protocol entity to the
3375 snmpInBadVersions OBJECT-TYPE
3380 "The total number of SNMP Messages which were
3381 delivered to the SNMP protocol entity and were for
3382 an unsupported SNMP version."
3385 snmpInBadCommunityNames OBJECT-TYPE
3390 "The total number of SNMP Messages delivered to
3391 the SNMP protocol entity which used a SNMP
3392 community name not known to said entity."
3395 snmpInBadCommunityUses OBJECT-TYPE
3400 "The total number of SNMP Messages delivered to
3401 the SNMP protocol entity which represented an SNMP
3402 operation which was not allowed by the SNMP
3403 community named in the Message."
3406 snmpInASNParseErrs OBJECT-TYPE
3411 "The total number of ASN.1 or BER errors
3412 encountered by the SNMP protocol entity when
3413 decoding received SNMP Messages."
3418 SNMP Working Group [Page 61]
3420 RFC 1213 MIB-II March 1991
3423 -- { snmp 7 } is not used
3425 snmpInTooBigs OBJECT-TYPE
3430 "The total number of SNMP PDUs which were
3431 delivered to the SNMP protocol entity and for
3432 which the value of the error-status field is
3436 snmpInNoSuchNames OBJECT-TYPE
3441 "The total number of SNMP PDUs which were
3442 delivered to the SNMP protocol entity and for
3443 which the value of the error-status field is
3447 snmpInBadValues OBJECT-TYPE
3452 "The total number of SNMP PDUs which were
3453 delivered to the SNMP protocol entity and for
3454 which the value of the error-status field is
3458 snmpInReadOnlys OBJECT-TYPE
3463 "The total number valid SNMP PDUs which were
3464 delivered to the SNMP protocol entity and for
3465 which the value of the error-status field is
3466 `readOnly'. It should be noted that it is a
3467 protocol error to generate an SNMP PDU which
3468 contains the value `readOnly' in the error-status
3469 field, as such this object is provided as a means
3470 of detecting incorrect implementations of the
3474 SNMP Working Group [Page 62]
3476 RFC 1213 MIB-II March 1991
3482 snmpInGenErrs OBJECT-TYPE
3487 "The total number of SNMP PDUs which were
3488 delivered to the SNMP protocol entity and for
3489 which the value of the error-status field is
3493 snmpInTotalReqVars OBJECT-TYPE
3498 "The total number of MIB objects which have been
3499 retrieved successfully by the SNMP protocol entity
3500 as the result of receiving valid SNMP Get-Request
3504 snmpInTotalSetVars OBJECT-TYPE
3509 "The total number of MIB objects which have been
3510 altered successfully by the SNMP protocol entity
3511 as the result of receiving valid SNMP Set-Request
3515 snmpInGetRequests OBJECT-TYPE
3520 "The total number of SNMP Get-Request PDUs which
3521 have been accepted and processed by the SNMP
3525 snmpInGetNexts OBJECT-TYPE
3530 SNMP Working Group [Page 63]
3532 RFC 1213 MIB-II March 1991
3538 "The total number of SNMP Get-Next PDUs which have
3539 been accepted and processed by the SNMP protocol
3543 snmpInSetRequests OBJECT-TYPE
3548 "The total number of SNMP Set-Request PDUs which
3549 have been accepted and processed by the SNMP
3553 snmpInGetResponses OBJECT-TYPE
3558 "The total number of SNMP Get-Response PDUs which
3559 have been accepted and processed by the SNMP
3563 snmpInTraps OBJECT-TYPE
3568 "The total number of SNMP Trap PDUs which have
3569 been accepted and processed by the SNMP protocol
3573 snmpOutTooBigs OBJECT-TYPE
3578 "The total number of SNMP PDUs which were
3579 generated by the SNMP protocol entity and for
3580 which the value of the error-status field is
3586 SNMP Working Group [Page 64]
3588 RFC 1213 MIB-II March 1991
3591 snmpOutNoSuchNames OBJECT-TYPE
3596 "The total number of SNMP PDUs which were
3597 generated by the SNMP protocol entity and for
3598 which the value of the error-status is
3602 snmpOutBadValues OBJECT-TYPE
3607 "The total number of SNMP PDUs which were
3608 generated by the SNMP protocol entity and for
3609 which the value of the error-status field is
3613 -- { snmp 23 } is not used
3615 snmpOutGenErrs OBJECT-TYPE
3620 "The total number of SNMP PDUs which were
3621 generated by the SNMP protocol entity and for
3622 which the value of the error-status field is
3626 snmpOutGetRequests OBJECT-TYPE
3631 "The total number of SNMP Get-Request PDUs which
3632 have been generated by the SNMP protocol entity."
3635 snmpOutGetNexts OBJECT-TYPE
3642 SNMP Working Group [Page 65]
3644 RFC 1213 MIB-II March 1991
3648 "The total number of SNMP Get-Next PDUs which have
3649 been generated by the SNMP protocol entity."
3652 snmpOutSetRequests OBJECT-TYPE
3657 "The total number of SNMP Set-Request PDUs which
3658 have been generated by the SNMP protocol entity."
3661 snmpOutGetResponses OBJECT-TYPE
3666 "The total number of SNMP Get-Response PDUs which
3667 have been generated by the SNMP protocol entity."
3670 snmpOutTraps OBJECT-TYPE
3675 "The total number of SNMP Trap PDUs which have
3676 been generated by the SNMP protocol entity."
3679 snmpEnableAuthenTraps OBJECT-TYPE
3680 SYNTAX INTEGER { enabled(1), disabled(2) }
3684 "Indicates whether the SNMP agent process is
3685 permitted to generate authentication-failure
3686 traps. The value of this object overrides any
3687 configuration information; as such, it provides a
3688 means whereby all authentication-failure traps may
3691 Note that it is strongly recommended that this
3692 object be stored in non-volatile memory so that it
3693 remains constant between re-initializations of the
3694 network management system."
3698 SNMP Working Group [Page 66]
3700 RFC 1213 MIB-II March 1991
3709 This document was produced by the SNMP Working Group:
3714 David Bridgham, Epilogue Technology
3717 Brian Brown, Synoptics
3719 Theodore Brunner, Bellcore
3722 John Burress, Wellfleet
3723 Jeffrey D. Case, University of Tennessee at Knoxville
3724 Chris Chiptasso, Spartacus
3729 James R. Davin, MIT-LCS
3731 Kurt Dobbins, Cabletron
3732 Nadya El-Afandi, Network Systems
3737 Richard Fox, Synoptics
3741 Fred Harris, University of Tennessee at Knoxville
3742 Ken Hibbard, Xylogics
3743 Ole Jacobsen, Interop
3745 Satish Joshi, Synoptics
3746 Frank Kastenholz, Racal-Interlan
3747 Shimshon Kaufman, Spartacus
3748 Ken Key, University of Tennessee at Knoxville
3749 Jim Kinder, Fibercom
3754 SNMP Working Group [Page 67]
3756 RFC 1213 MIB-II March 1991
3759 Christopher Kolb, PSI
3760 Cheryl Krupczak, NCR
3762 Martin Lee Schoffstall, PSI
3766 Gary Malkin, FTP Software, Inc.
3767 Randy Mayhew, University of Tennessee at Knoxville
3768 Keith McCloghrie, Hughes LAN Systems
3769 Donna McMaster, David Systems
3772 Jim Reinstedler, Ungerman Bass
3773 Anil Rijsinghani, DEC
3774 Kathy Rinehart, Arnold AFB
3776 Marshall T. Rose, PSI (chair)
3777 L. Michael Sabo, NCSC
3780 Martin Schoffstall, PSI
3782 Steve Sherry, Xyplex
3785 Mark Sleeper, Sparta
3790 Kaj Tesink, Bellcore
3791 Geoff Thompson, Synoptics
3792 Dean Throop, Data General
3793 Bill Townsend, Xylogics
3794 Maurice Turcotte, Racal-Milgo
3797 Bill Versteeg, Network Research Corporation
3798 Warren Vik, Interactive Systems
3800 Steve Waldbusser, CMU
3804 Jeff Young, Cray Research
3810 SNMP Working Group [Page 68]
3812 RFC 1213 MIB-II March 1991
3815 In addition, the comments of the following individuals are also
3818 Craig A. Finseth, Minnesota Supercomputer Center, Inc.
3819 Jeffrey C. Honig, Cornell University Theory Center
3820 Philip R. Karn, Bellcore
3824 [1] Cerf, V., "IAB Recommendations for the Development of Internet
3825 Network Management Standards", RFC 1052, NRI, April 1988.
3827 [2] Rose M., and K. McCloghrie, "Structure and Identification of
3828 Management Information for TCP/IP-based internets," RFC 1065,
3831 [3] McCloghrie, K., and M. Rose, "Management Information Base for
3832 Network Management of TCP/IP-based internets, RFC 1066, TWG,
3835 [4] Cerf, V., "Report of the Second Ad Hoc Network Management Review
3836 Group", RFC 1109, NRI, August 1989.
3838 [5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
3839 Network Management Protocol (SNMP)", RFC 1098, University of
3840 Tennessee at Knoxville, NYSERNet, Inc., Rensselaer Polytechnic
3841 Institute, MIT Laboratory for Computer Science, April 1989.
3843 [6] Postel, J., and J. Reynolds, "TELNET Protocol Specification", RFC
3844 854, USC/Information Sciences Institute, May 1983.
3846 [7] Satz, G., "Connectionless Network Protocol (ISO 8473) and End
3847 System to Intermediate System (ISO 9542) Management Information
3848 Base", RFC 1162, cisco Systems, Inc., June 1990.
3850 [8] Information processing systems - Open Systems Interconnection -
3851 Specification of Abstract Syntax Notation One (ASN.1),
3852 International Organization for Standardization, International
3853 Standard 8824, December 1987.
3855 [9] Information processing systems - Open Systems Interconnection -
3856 Specification of Basic Encoding Rules for Abstract Notation One
3857 (ASN.1), International Organization for Standardization,
3858 International Standard 8825, December 1987.
3860 [10] Jacobson, V., "Congestion Avoidance and Control", SIGCOMM 1988,
3861 Stanford, California.
3866 SNMP Working Group [Page 69]
3868 RFC 1213 MIB-II March 1991
3871 [11] Hagens, R., Hall, N., and M. Rose, "Use of the Internet as a
3872 Subnetwork for Experimentation with the OSI Network Layer", RFC
3873 1070, U of Wiscsonsin - Madison, U of Wiscsonsin - Madison, The
3874 Wollongong Group, February 1989.
3876 [12] Rose M., and K. McCloghrie, "Structure and Identification of
3877 Management Information for TCP/IP-based internets", RFC 1155,
3878 Performance Systems International, Hughes LAN Systems, May 1990.
3880 [13] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
3881 Network Management Protocol", RFC 1157, SNMP Research,
3882 Performance Systems International, Performance Systems
3883 International, MIT Laboratory for Computer Science, May 1990.
3885 [14] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
3886 RFC 1212, Performance Systems International, Hughes LAN Systems,
3889 9. Security Considerations
3891 Security issues are not discussed in this memo.
3893 10. Authors' Addresses
3897 1225 Charleston Road
3898 Mountain View, CA 94043
3899 1225 Charleston Road
3900 Mountain View, CA 94043
3902 Phone: (415) 966-7934
3908 Performance Systems International
3909 5201 Great America Parkway
3911 Santa Clara, CA 95054
3913 Phone: +1 408 562 6222
3915 EMail: mrose@psi.com
3916 X.500: rose, psi, us
3922 SNMP Working Group [Page 70]
projects / thirdparty / cups.git / blob