Entity MIB (Version 2)
Extracted elements (29)
entLogicalCommunity is deprecated in Version 2 in favor of entLogicalContextEngineID and entLogicalContextName, which provide proper SNMPv3 context identification. SNMPv3 agents may return a zero-length string for entLogicalCommunity or continue to support it for tri-lingual agent compatibility.
Most MIB objects in the Entity MIB have at most read-only MAX-ACCESS, a conscious decision to limit the MIB's scope. Version 2 introduced only a small set of writable string objects (entPhysicalSerialNum, entPhysicalAlias, entPhysicalAssetID) for administrative identification of physical components.
The Entity MIB is intentionally not a 'Chassis MIB replacement.' An earlier IETF working group attempted a Chassis MIB but reached no consensus, possibly due to overly broad scope. The Entity MIB restricts itself to representing manageable physical and logical components without covering all chassis management functions.
Version 2 updates entPhysicalDescr, entPhysicalName, and entLogicalDescr from the obsolete DisplayString TC to SnmpAdminString. The working group chose to update in-place rather than deprecate and define new objects because deprecating would have a more adverse impact on backward compatibility given the semantics of these objects.
Multiple instances of the Entity MIB within the same managed system (from different agents) are not required to be equivalent or consistent. Index values, vendor-specific identifiers, and the subset of entities represented are likely to differ between agents.
The Entity MIB is a single-scoped MIB. In environments where an agent represents the MIB in different naming scopes, single-scoped objects may be returned across all naming scopes and not just the default. Isolation of single-scoped objects is implementation-specific.
An agent must not generate more than one entConfigChange notification-event within a given five-second throttling period. Additional configuration changes during the window must be suppressed, with one event sent at the end of the period if any changes occurred.
An agent must not return an entLogicalCommunity value that allows more privileges than the community string used to access the object. The agent may return a community string with read-only privileges even when accessed with a read-write community.
For entity2Compliance, implementation of the entPhysicalContainsTable is mandatory for all agents. Implementation of entLPMappingTable and entAliasMappingTable is not mandatory for agents that model all MIB objects within a single naming scope.
If an agent implements write access for entPhysicalSerialNum, entPhysicalAlias, or entPhysicalAssetID and a value is written, the agent must retain that value for as long as the entity remains instantiated, including across all re-initializations and reboots, even if the entity's entPhysicalIndex changes.
If an agent represents multiple logical entities with the Entity MIB, the entityLogical group must be implemented for all logical entities known to the agent. Agents representing a single logical entity or multiple entities within a single naming scope may omit this group.
The containment relationships defined by entPhysicalContainedIn must form a strict hierarchy; recursion is not allowed. For double-wide modules contained by more than one physical entity, the object should identify the containing entity with the lowest entPhysicalIndex value.
The entAliasMappingTable may only contain entries for physical entities whose entPhysicalClass is port(10). Only rows representing interfaces or ports are permitted as entAliasMappingIdentifier values.
The entPhysicalTable must always contain at least one row for an 'overall' physical entity, which should have an entPhysicalClass value of stack(11), chassis(3), or module(9).
entLastChangeTime is a TimeStamp scalar recording the value of sysUpTime when any conceptual row in entPhysicalTable, entLogicalTable, entLPMappingTable, entAliasMappingTable, or entPhysicalContainsTable was last created, modified, or deleted.
entLogicalContextEngineID and entLogicalContextName, added in Version 2, together identify the SNMPv3 context associated with a logical entity. They replace entLogicalCommunity for SNMPv3-capable agents and are used with entLogicalTAddress/entLogicalTDomain to send SNMPv3 messages on behalf of that entity.
entPhysicalIsFRU is a read-only TruthValue indicating whether a physical entity is a field-replaceable unit. Components permanently contained within an FRU should return false(2); agents are not required to provide serial number or asset ID write access for non-FRU entities.
The entAliasMappingTable maps physical port entries (entPhysicalClass = port) and logical entities to external MIB row pointers (e.g., ifIndex, rptrPortGroupIndex). An entAliasLogicalIndexOrZero value of zero acts as a wildcard covering all logical entities not otherwise explicitly mapped.
The entConfigChange notification is generated when entLastChangeTime changes, allowing an NMS to trigger entity table maintenance polls. It is throttled to at most one notification-event per five-second interval; changes during a throttle window are suppressed and a single event is sent at window expiry.
The entLogicalTable contains one row per logical entity, indexed by an arbitrary integer. Each entry includes a description, type (OID), community string (deprecated), transport address/domain, and SNMPv3 context engine ID and context name.
The entLPMappingTable maps logical entities (entLogicalIndex) to the physical components (entPhysicalIndex) that realize them. A logical entity may map to multiple physical components and vice versa; agents should include only meaningful, non-redundant entries.
The entPhysicalContainsTable exposes container/containee relationships directly, indexed by (entPhysicalIndex, entPhysicalChildIndex), enabling an NMS to quickly discover all children of a given physical entity. It also captures double-wide module containment that cannot be represented in entPhysicalTable alone.
The entPhysicalTable contains one row per physical entity and must always contain at least one row for an 'overall' physical entity. Each row is indexed by an arbitrary PhysicalIndex integer and provides description, vendor type, class, containment relationship, and relative position.
The PhysicalClass textual convention enumerates 11 hardware types: other(1), unknown(2), chassis(3), backplane(4), container(5), powerSupply(6), fan(7), sensor(8), module(9), port(10), stack(11). A stack may only contain chassis entities; a chassis may be contained only within a stack.
The SnmpEngineIdOrNone textual convention encodes either a valid SnmpEngineID (non-zero length OCTET STRING up to 32 bytes) or an empty string indicating SNMPv3 is not supported for the associated logical entity.
Version 2 adds three writable string objects to entPhysicalTable: entPhysicalSerialNum (max 32 octets, vendor serial number), entPhysicalAlias (max 32 octets, NMS-assigned non-volatile handle), and entPhysicalAssetID (max 32 octets, asset tracking identifier). All must be retained across agent reboots once written.
The ENTITY-MIB module is registered under mib-2 47 (OID { mib-2 47 }), as defined in this document. It obsoletes RFC 2037 and was last updated December 7, 1999.
Several objects in the Entity MIB have read-write access (entPhysicalSerialNum, entPhysicalAlias, entPhysicalAssetID). Unauthorized write access could allow an adversary to corrupt asset tracking or serial number records. Agents must enforce appropriate SNMPv3 access control or community-based access restrictions on these objects.
The Entity MIB exposes detailed physical topology information (hardware revisions, serial numbers, model names, asset IDs, and containment structure) that could aid an attacker in targeting specific vulnerabilities. Access to the MIB should be controlled via SNMP access control mechanisms to limit disclosure.