Why is ENTITY-MIB disabled by default

[gk13]

Is there a reason why ootb the ENTITY-MIB is disabled by default? Is there any negative impact when activating that MIB? Maybe @doug_schulze can shed some light on those questions

[Fabian Kunzke]

Hey,

So from what i've gathered, not all MIB files are active by default. Some MIBs are disabled as they may cover areas which are not of general use. The ENTITY-MIB file is not only extremely large, but also covers details most CMDBs won't require (component details like fans, sensors etc.).

Overall the main reason for some of the MIBs being disabled is that they can cause some performance issues with little to no use. In your case, feel free to check what the specific MIB file will cover and if you need that information in addition to the data retrieved by more specific or high-level MIBs.

If you need that data to be present, activate the MIB file and see what the impact is (on a lower environment). My assumption is, that these files aren't used in any ootb patterns, so activating it probably has no impact to the overall discovery scope, but may have impact to the performance.

Hope this helps.

Regards

Fabian

[gk13]

We asked support why ENTITY-MIB is disabled by default and here is the official answer:

Thank you for sharing the details. We reviewed the OOTB ENTITY-MIB entry in the MID Server MIB Files list and confirmed it is delivered with Active = false by default.

This is expected behavior and is generally intentional for the following reasons:

• ENTITY-MIB is already bundled with the MID Server: ServiceNow ships common SNMP MIB modules (including ENTITY-MIB) as part of the MID Server package, so the MID can use the bundled copy without needing the instance to actively distribute it.

• The OOTB "source" URL is no longer reliable: The default record points to a Cisco FTP source (ftp.cisco.com), which has been decommissioned. Keeping the OOTB record inactive avoids failed downloads or unnecessary errors caused by an unreachable source.

• Avoids duplicate or conflicting MIB loads: Leaving the instance-side record inactive prevents duplicate loading or potential conflicts between the MID-bundled MIB and an instance-managed copy.

• If SNMP Discovery is working as expected, no action is required and we recommend keeping ENTITY-MIB inactive.
• If there is a specific use case where the MID must load ENTITY-MIB from the instance for time being set the value to Active true and we recommend you to keep the value OOTB later.

[Fabian Kunzke]

Feel free to mark your own answer as correct. This certainly helps people find the answer more quickly.

Regards

Fabian