Tips for Using Entity MIB Functions

Creating physical or logical entries

Create the appropriate physical entries or logical entries first, before creating the entries in the three mapping tables: entLPMappingTable, entAliasMappingTable, and the entPhysicalContainsTable.

Multiple parents

For physical entries that have more than one parent, all relationships must be defined in the entPhysicalContainsTable. For example, suppose you want to define that C is contained in A with the entPhysicalContainedIn field. You also want to define that C is also contained in B. In this case, you must define that C is contained in A, and C is contained in B in the entPhysicalContainsTable.

Recursive Relationships

Recursive relationships are not allowed in the entPhysicalTable and entPhysicalContainsTable. For example, suppose B is contained in A, and C is contained in B. In this case, A cannot be contained in C. The parent/child relationship is defined both in the entPhysicalContainedIn field of the entPhysicalTable() function and in the entPhysicalContainsTable. The recursive check safeguard is already built into the addPhysicalContainsTableEntry() function.

Uniqueness

When you specify entPhysicalParentRelPos, the allocPhysicalEntry() function does not check for uniqueness. For example, you can specify that A and B are contained in C by setting both entPhysicalParentRelPos fields to the same value. However, doing so would violate RFC 2737. The uniqueness of many fields is not necessarily checked by the functions. You must be aware of this fact during the design phase.

Deleting physical or logical entries

Deleting an entry is similar to making the entry stale. Both deleted and stale entries no longer show up in tables when performing SNMP operations. Whether you delete an entry or make an entry stale, the corresponding entries are automatically deleted in the three mapping tables. Note that you cannot undelete these corresponding mapping tables entries. This deletion is done to maintain the integrity of the tables.

The difference between deleting an entry and making the entry stale is that a stale entry can be restored. Stale entries can be made live with functions that are designed for that purpose. A deleted entry cannot be restored.

Deleting Parents

The integrity of the entPhysicalTable and entPhysicalContainsTable are not maintained if you delete a parent before you delete the subsequent generations. The deletePhysicalTableEntry() function does not recursively remove the parent and its subsequent generations. The function only removes the specified entry from the tables. If you do not delete a parent's generations before deleting the parent, you leave orphaned children. This practice is a violation of RFC 2737.

When you delete a parent of a multi-parent child, the entPhysicalContainedIn parameter is reset automatically to the lowest of the remaining parent index. RFC 2737 requires this reset. The entPhysicalParentRelPos parameter is then out of place. No API function lets you change that parameter. You can modify the entPhysicalParentRelPos parameter by manipulating the entry that is returned by the getPhysicalTableEntry() function. However, this approach for modifying entPhysicalParentRelPos is not supported. If you decide to try this approach, use caution.

Traps

A notification trap is sent out whenever a change is made to any of the five tables, such as the creation or deletion of entries. A mechanism exists to suppress traps from being sent too frequently. The throttling period is five seconds.

RFC Constraints and errors

The Entity MIB implementation has some constraints, which are dictated by RFC 2737. The only mechanism to notify the user about an error is through the error codes. You must understand the RFC thoroughly to be aware of the constraints.