Entity MIB (Version 4)
obsoletes
- rfc-4133 — Entity MIB (Version 3)
Extracted elements (26)
entPhysicalUUID is read-only and fixed-size (RFC 4122 compliant only), while entPhysicalUris is writable and format-free. To support backward compatibility with RFC 4133 (v3) implementations, the UUID value should also be stored in entPhysicalUris in URN format, deliberately duplicating the information.
Most MIB objects have at most read-only MAX-ACCESS by conscious working group decision, limiting the Entity MIB's scope and deliberately avoiding overlap with device configuration management functions.
The PhysicalClass TC was deprecated in v4 and its content moved to IANA-ENTITY-MIB as IANAPhysicalClass so that new hardware class enumerations (e.g., future entity types) can be added by IANA assignment without requiring a new RFC to revise the ENTITY-MIB module.
The syntax for entPhysicalDescr, entPhysicalName, and entLogicalDescr was changed from DisplayString to SnmpAdminString in v2, which the ENTMIB WG acknowledged was not strictly allowed by SMIv2. Deprecating and redefining the objects was judged to have a more adverse impact on backward compatibility given the specific semantics of these objects.
Multiple Entity MIB instances from different agents in the same managed system are not required to be equivalent or consistent; vendor-specific identifiers and index values are likely to differ, and each agent may represent a different subset of the physical chassis.
The entLogicalCommunity object is deprecated; SNMPv3 agents should use entLogicalContextEngineID and entLogicalContextName to identify the context for each logical entity. Tri-lingual agents may still return a community string for legacy compatibility.
An agent must not return an entLogicalCommunity string that allows more privileges than the community string used to access this object, preventing privilege escalation via the logical entity table.
An agent should limit entLPMappingTable entries to meaningful, non-redundant information: only the most appropriate physical component closest to the root of a containment tree should be mapped, avoiding redundant port-level mappings when a module-level mapping already covers them.
For agents implementing more than one naming scope, at least one entry must exist in the entLogicalTable. Agents that instantiate all MIB objects within a single naming scope are not required to implement this table.
If write access is implemented for entPhysicalSerialNum, entPhysicalAlias, or entPhysicalAssetID, the agent must retain the supplied value for as long as that physical entity remains instantiated, including across all re-initializations and reboots even if the entity's entPhysicalIndex value changes.
Only entPhysicalIndex values that represent physical ports (i.e., where the associated entPhysicalClass value is 'port(10)') are permitted to exist in the entAliasMappingTable.
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)'.
The entPhysicalUUID object is read-only and its syntax must conform to RFC 4122, Section 4.1. A zero-length octet string is returned if no UUID information is known.
When a physical entity is contained by more than one physical entity (e.g., double-wide modules), entPhysicalContainedIn should identify the containing entity with the lowest value of entPhysicalIndex.
The entAliasMappingTable maps logical entity/physical port pairs to external MIB identifiers (e.g., ifIndex or rptrPortGroupIndex). The index value entAliasLogicalIndexOrZero equal to zero acts as a wildcard for all unspecified logical entities; non-zero entries take precedence over zero-indexed entries.
The Entity MIB defines five groups: entityPhysical (one row per physical component), entityLogical (one row per logical entity), entityMapping (associations between physical/logical entities and external identifiers), entityGeneral (entLastChangeTime scalar), and entityNotifications (entConfigChange notification).
The entLogicalTable associates each logical entity with SNMPv3 context information (entLogicalContextEngineID and entLogicalContextName) as well as transport address (entLogicalTAddress/entLogicalTDomain). The deprecated entLogicalCommunity object supports legacy SNMPv1/v2c access.
The entPhysicalContainsTable exposes container/containee relationships as a directly indexed table (indexed by parent entPhysicalIndex and child entPhysicalChildIndex), supplementing the entPhysicalContainedIn hierarchy and handling double-wide modules with multiple parent containment relationships.
The entPhysicalTable contains one row per physical entity indexed by PhysicalIndex (1..2147483647). Each EntPhysicalEntry has 19 columns: index, description, vendor type, containedIn, class, parent-relative position, name, hardware/firmware/software revisions, serial number, manufacturer name, model name, alias, asset ID, FRU flag, manufacturing date, URIs, and UUID.
The IANAPhysicalClass TEXTUAL-CONVENTION (in the new IANA-ENTITY-MIB module) enumerates physical entity types: other(1), unknown(2), chassis(3), backplane(4), container(5), powerSupply(6), fan(7), sensor(8), module(9), port(10), stack(11), cpu(12). It replaces the deprecated PhysicalClass TC and is IANA-maintained for future extensibility.
The UUIDorZero TEXTUAL-CONVENTION (in the new UUID-TC-MIB module) represents an RFC 4122-compliant UUID as a fixed-size OCTET STRING, or a zero-length string indicating absence. It is designed for reuse in other MIB modules.
Two MODULE-COMPLIANCE statements are defined: entity4Compliance for full Entity MIB v4 compliance, and entity4CRCompliance for constrained-resource devices (e.g., battery-powered), which requires only entPhysicalClass, entPhysicalName, and entPhysicalUUID.
RFC 6933 creates the IANA-ENTITY-MIB module with the IANA-maintained IANAPhysicalClass TEXTUAL-CONVENTION (OID under mib-2). The PhysicalClass TC in ENTITY-MIB is deprecated and its use is replaced by IANAPhysicalClass, allowing enumeration additions without re-issuing the ENTITY-MIB.
RFC 6933 creates the UUID-TC-MIB module (OID under mib-2) containing the UUIDorZero TEXTUAL-CONVENTION. IANA is requested to assign an OID for this MIB module under the mib-2 subtree.
Several objects have read-write MAX-ACCESS (entPhysicalSerialNum, entPhysicalAlias, entPhysicalAssetID, entPhysicalUris). Unauthorized writes could corrupt inventory and asset-tracking information; implementations should apply SNMPv3 access controls to restrict write operations to authorized principals.
The entLogicalCommunity object may expose SNMPv1/v2c community strings used as management credentials. Agents must guard against returning higher-privilege community strings than were used in the request, and SNMPv3 deployments should prefer the context-based objects instead.