Management Information Base for version 2 of the Simple Network Management Protocol (SNMPv2)
obsoleted by
- rfc-1907 — Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)
Extracted elements (24)
Case diagrams are used throughout the document to illustrate the flow of packet-processing counters. Each counter in the snmpStats and snmpV1 groups corresponds to a discard point in the ordered processing pipeline, making it easy to determine at which stage packets are being lost.
The snmpORTable is intended for SNMPv2 agents that support dynamically-configurable object resources; agents that do not support such resources will never have any instances of the columnar objects in this table.
The snmpSetSerialNo object provides only coarse-grain coordination among cooperating managers. The document notes that fine-grain coordination may require additional similar objects defined within individual MIB groups, as appropriate.
A SNMPv2 entity that does not support SNMPv1 should count packets whose first octet is 0x30 (hex) in snmpStats30Something, as these are possibly misdirected SNMPv1 Messages that arrived at a SNMPv2-only agent.
All implementations of SNMPv2 must be capable of generating the authenticationFailure trap, though the snmpV2EnableAuthenTraps object controls whether the trap will actually be sent.
It is strongly recommended that snmpV2EnableAuthenTraps be stored in non-volatile memory so that it remains constant between re-initializations of the network management system.
SNMPv2 entities implementing this MIB must support the mandatory groups: system (from RFC1213-MIB), snmpStatsGroup, snmpORGroup, snmpTrapGroup, and snmpSetGroup. The snmpV1Group is mandatory only for entities that also implement SNMPv1.
Six well-known NOTIFICATION-TYPEs are defined: coldStart (agent reinitializing, configuration may change), warmStart (agent reinitializing, configuration unchanged), linkDown (link failure, varbind: ifIndex), linkUp (link restored, varbind: ifIndex), authenticationFailure (improperly authenticated message received), and egpNeighborLoss (EGP neighbor marked down, varbind: egpNeighAddr).
snmpSetSerialNo (TestAndIncr, read-write) is an advisory lock in the Set Group that allows cooperating SNMPv2 manager entities to coordinate their use of the SNMPv2 Set operation via coarse-grain serialization.
snmpStats30Something (Counter32) counts packets whose first octet is 0x30 (ASN.1 SEQUENCE tag) received by a SNMPv2 entity that does not support SNMPv1; such packets are possibly misdirected SNMPv1 Messages.
snmpStatsBadAuths (Counter32) counts SnmpAuthMsgs whose authInfo field was inconsistent with the authentication protocol associated with the source party.
snmpStatsEncodingErrors (Counter32) counts packets received by the SNMPv2 entity that were improperly encoded or had invalid syntax. Derived from RFC1213-MIB.snmpInASNParseErrs.
snmpStatsNotInLifetimes (Counter32) counts SnmpAuthMsgs deemed unauthentic because the authInfo.authSrcTimestamp field was less than the source party's clock plus lifetime, providing a counter for replay-protection failures.
snmpStatsPackets (Counter32) counts the total number of packets received by the SNMPv2 entity from the transport service. It is the entry point in the Case diagram for all inbound packet processing.
snmpStatsSilentDrops (Counter32) counts GetRequest, GetNextRequest, GetBulkRequest, SetRequest, and InformRequest PDUs silently dropped because a reply with an empty variable-bindings field would still exceed either a local constraint or the maximum message size of the request's source party.
snmpStatsUnknownDstParties (Counter32) counts SnmpPrivMsgs for which the privDst field did not identify a known local party; snmpStatsDstPartyMismatches counts those where the inner authData.dstParty field did not match privDst.
snmpStatsWrongDigestValues (Counter32) counts SnmpAuthMsgs deemed unauthentic because the authInfo.authDigest field did not equal the expected digest value.
snmpTrapOID (OBJECT IDENTIFIER) identifies the trap currently being sent and occurs as the second varbind of a SNMPv2-Trap-PDU. snmpTrapEnterprise identifies the enterprise for traps originating from RFC1157 Trap-PDU proxy mapping and occurs as the last varbind.
snmpTrapTable augments partyEntry and contains snmpTrapNumbers (Counter32), which tracks how many traps have been sent to a particular SNMPv2 party since the last initialization of the entity or creation of the party, whichever is more recent.
snmpV2EnableAuthenTraps (TruthValue, read-write) controls whether an agent is permitted to generate authenticationFailure traps; its value overrides all other configuration, providing a master switch for suppressing such traps.
The Object Resource Group includes snmpORLastChange (TimeStamp of last snmpORID change), snmpORTable (conceptual table of dynamically-configurable object resources), with each row containing snmpORIndex, snmpORID (OID), and snmpORDescr (DisplayString).
The SNMPv1 Statistics Group provides two Counter32 objects: snmpV1BadCommunityNames (SNMPv1 messages using an unknown community name) and snmpV1BadCommunityUses (SNMPv1 messages containing an operation not allowed for the named community). This group is mandatory only for SNMPv2 entities that also implement SNMPv1.
The SNMPv2 Statistics Group (snmpStats) provides 12 read-only Counter32 objects offering basic instrumentation of a SNMPv2 entity, covering all stages of inbound packet processing from receipt through authentication, authorization, and PDU handling.
The document explicitly states that security issues are not discussed in this memo, deferring security analysis to other SNMPv2 framework documents such as the Party MIB (RFC 1447).