Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)
obsoletes
- rfc-1907 — Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)
also
- std-62
Extracted elements (25)
snmpBasicCompliance was deprecated and replaced by snmpBasicComplianceRev2 to add the snmpWarmStartNotificationGroup as a conditionally mandatory group and to align with current SNMP architecture terminology (removing references to 'manager role', 'agent role', and 'SNMPv2 entity').
snmpSetSerialNo uses the TestAndIncr textual convention to provide coarse-grain coordination among multiple cooperating command generators; the rationale is that fine-grain coordination is better served by additional similar objects defined within each MIB group.
The authenticationFailure DESCRIPTION was weakened from MUST to MAY (relative to RFC 1907) to reflect that while all implementations may be capable of generating the trap, the snmpEnableAuthenTraps object is the authoritative control, and the trap pertains to all SNMP entities, not just agents.
A large set of objects from RFC 1213's SNMP group (snmpOutPkts, snmpInTooBigs, snmpInNoSuchNames, snmpInBadValues, snmpInReadOnlys, snmpInGenErrs, snmpInTotalReqVars, snmpInTotalSetVars, and all per-PDU-type In/Out counters) are declared obsolete in this MIB and collected in snmpObsoleteGroup.
The linkDown and linkUp NOTIFICATION-TYPEs (snmpTraps 3 and 4) and egpNeighborLoss (snmpTraps 6) are not defined in this MIB; they are defined in RFC 2863 and RFC 1213 respectively, and their OID slots are noted as reserved.
It is strongly RECOMMENDED that snmpEnableAuthenTraps be stored in non-volatile memory so that it remains constant across re-initializations of the network management system.
It is strongly RECOMMENDED that the documentation for any access control mechanism used to control MIB access specify the precise conditions that contribute to the snmpInBadCommunityUses counter value.
The snmpBasicComplianceRev2 MODULE-COMPLIANCE requires mandatory groups snmpGroup, snmpSetGroup, systemGroup, and snmpBasicNotificationsGroup; snmpCommunityGroup is mandatory for entities supporting community-based authentication; snmpWarmStartNotificationGroup is mandatory for command responders that can reinitialize without altering configuration.
authenticationFailure NOTIFICATION-TYPE signals receipt of a protocol message that is not properly authenticated; all implementations MAY be capable of generating this trap, but actual generation is controlled by snmpEnableAuthenTraps.
coldStart NOTIFICATION-TYPE signals that the SNMP entity's notification originator is reinitializing and its configuration may have been altered. warmStart signals reinitialization with configuration unaltered.
snmpEnableAuthenTraps is a read-write INTEGER {enabled(1), disabled(2)} that controls whether the entity may generate authenticationFailure traps; its value overrides all other configuration.
snmpInBadCommunityNames counts community-based SNMP messages using a community name not known to the entity; implementations that perform additional authentication checks (e.g., source address validation) MAY also include messages failing those checks in this counter.
snmpInBadCommunityUses counts community-based SNMP messages that named a valid community but requested an operation not allowed for that community; the precise conditions depend on the access control mechanism in use.
snmpProxyDrops counts Confirmed Class PDUs silently dropped because forwarding to a proxy target failed in a manner other than a timeout, such that no Response-PDU could be returned.
snmpSetSerialNo is a TestAndIncr-syntax advisory lock (read-write) used to allow cooperating command generator applications to coordinate their use of the SNMP set operation; it provides coarse-grain coordination, and finer-grain coordination may use additional similar objects within individual MIB groups.
snmpSilentDrops counts Confirmed Class PDUs (GetRequest, GetNextRequest, GetBulkRequest, SetRequest, InformRequest) that were silently dropped because the minimum Response-PDU (with empty variable-bindings) exceeded either a local constraint or the originator's maximum message size.
snmpTrapOID (accessible-for-notify, OID syntax) carries the authoritative identification of the notification being sent and occurs as the second varbind in every SNMPv2-Trap-PDU and InformRequest-PDU. snmpTrapEnterprise carries the enterprise OID and is used when a proxy maps an RFC 1157 Trap-PDU into an SNMPv2-Trap-PDU.
sysORLastChange holds the value of sysUpTime at the time of the most recent change in state or value of any instance of sysORID, allowing managers to detect capability changes without polling every row.
sysORTable is a conceptual table listing the capabilities of the local SNMP command responder application with respect to MIB modules; each row (SysOREntry) contains sysORIndex, sysORID (an OID identifying a capabilities statement), sysORDescr, and sysORUpTime (the sysUpTime when the row was instantiated). Entities with dynamically configurable MIB support have a dynamically varying row count.
sysServices encodes the set of OSI layers at which the entity offers services as an integer 0..127, computed as the sum of 2^(L-1) for each layer L (1=physical, 2=datalink, 3=internet, 4=end-to-end, 7=application) the entity performs transactions for.
The SNMP group (mib-2 11) provides basic instrumentation counters: snmpInPkts (total messages from transport), snmpInBadVersions (unsupported version), snmpInASNParseErrs (ASN.1/BER decode errors), snmpSilentDrops, snmpProxyDrops, and the read-write control object snmpEnableAuthenTraps.
The system group (mib-2 1) defines objects common to all managed systems: sysDescr (DisplayString, read-only textual description), sysObjectID (OID identifying the device type), sysUpTime (TimeTicks since last re-initialization), sysContact, sysName, and sysLocation (read-write DisplayStrings up to 255 octets).
It is the customer/user's responsibility to ensure that the SNMP entity giving access to this MIB is configured so that only principals with legitimate rights can GET or SET its objects.
Several MIB objects have MAX-ACCESS read-write (sysContact, sysName, sysLocation, snmpEnableAuthenTraps, snmpSetSerialNo); SET operations in a non-secure environment without proper protection can negatively affect network operations.
SNMPv1 by itself is not a secure environment; even on a network secured with IPsec, there is no control over which hosts on that network may GET or SET objects. Implementors are recommended to use the SNMPv3 User-based Security Model (RFC 3414) and View-based Access Control Model (RFC 3415).