How are DeviceTypes.xml file changes processed by Performance Management

Products

• CA Performance Management - Usage and Administration
• DX NetOps

Issue/Introduction

The DeviceTypes.xml file on the Data Aggregator is used to override discovered Device Types and Context Types in Performance Management. It is located in the following location; /opt/IMDataAggregator/data/custom/devicetypes/DeviceTypes.xml

 

How are the changes in this file processed by Performance Management?

 

What is the logic used for DeviceTypes.xml file changes to customize Device Type or Context Types values?

 

How can we override Device Types or Context Types in Performance Management?

Environment

All supported Performance Management releases

Cause

Sometimes expected types are not assigned correctly. This is often due to misconfiguration of the DeviceTypes.xml file resulting in unexpected outcomes with incorrect Device Type or Context Types assigned.

Resolution

With better understanding of the rules used to apply DeviceTypes.xml changes, the behavior is easier to utilize and predict.

These are the Type value tags available for use in the DeviceTypes.xml file.

The tags in the DeviceTypes.xml are parsed as follows:

// Router
// Switch
// Servers
// Firewalls
// Wireless
// Load Balancers
// Devices/Others

When the tags are uncommented for use, they default to using sysServicesOverride=false.

The sysServicesOverride does what it states.

• Set to false? This says no, do not override the discovered type which is based on the devices sysServices.0 MIB OID value. 
• Set to true? This says yes, override the discovered type which is based on the devices sysServices.0 MIB OID value.

If the discovered Type based on the devices sysServices.0 value needs to be changed, use sysServicesOverride=true.

• The value can be set at top of the the tags section opening to apply to all sysObjectID MIB OID values listed in that section.
  • In this example all sysObjectID values in the section use false.

<Firewalls sysServicesOverride="false">
          <sysObjectID>1.3.6.1.4.1.2620.1.6.123.1.48</sysObjectID>
          <sysObjectID>1.3.6.1.4.1.9.1.770</sysObjectID>
</Firewalls>

• It can also be set against a specific sysObjectID MIB OID value to override a single one while leaving others without being overridden.
  • In this example only the *.17 sysObjectID will use true, *.770 will default to false.

<Firewalls>
          <sysObjectID sysServicesOverride="true">1.3.6.1.4.1.9.1.17</sysObjectID>
          <sysObjectID>1.3.6.1.4.1.9.1.770</sysObjectID>
</Firewalls>

When a sysObjectID is entered into more than one tag section in the DeviceTypes.xml file, it's important to consider the parsing order as it relates to the use of the sysServicesOverride value.

• The parsing order results in the last sysObjectID MIB value entry found wins the right to use it's sysServicesOverride=value setting.
• At it's simplest, if the sysObjectID MIB OID is in both the <Router> and <Firewalls> sections:
  • The sysServicesOverride from <Router> is ignored
  • The sysServicesOverride from <Firewalls> is used
• For example we've added a sysObjectID value to the <Servers> section and set it  with sysServicesOverride=true. Later we add the same sysObjectID value to the <Firewalls> section where we don’t provide sysServicesOverride=true.
  • This means it will use the default sysServicesOverride=false for the <Firewall> entry.
  • In this scenario, when the types are re-evaluated based on the new DeviceTypes.xml changes, it will use the sysServicesOverride=false from <Firewalls>, ignoring the override value of true from <Servers>.
• Keep in mind that the last sysServicesOverride value is applied to the sysObjectID value when in more than one tag section, based on the section parsing order above.

Based on this information, we can go through two scenarios to apply the information.

1. The first is for a device that is discovered as a Device Type=Switch per the discovered sysServices.0 MIB OID value.
2. The second is for a device that is discovered as a Device Type=Other, which usually results from a device having no sysServices.0 OID or the OID is present but it's not set and returns no value.

Scenario 1: Device Type="Switch" set per valid sysServices.0 value.

• Keep Device Type "Switch", add Context Type "Firewall"?
  • Set sysObjID in <Firewalls> section with sysServicesOverride=false.
  • It will add Firewall to the already set Switch type.
  • Will show Type="Switch".
  • Will show Context Types as "Switch, Firewall".
• Make it Type "Server" only instead of "Switch"?
  • Set sysObjID in <Servers> section with sysServicesOverride=true.
  • It will override the "Switch" set from sysServices.0 and use "Server" for Type.
  • Will show "Server" for Type and Context Types value.
• Make it Type "Server", Context Type "Server, Firewall" instead of "Switch" or "Switch,Firewall"?
  • Set sysObjID in in <Servers> and <Firewalls> section.
  • Set both to use sysServicesOverride=true.
  • Will show Type="Server".
  • Will show "Server, Firewall" for Context Types.

Scenario 2: Device Type="Other" set via empty/missing sysServices.0 value.

• Make it Type "Switch" only instead of "Other"?
  • Set sysObjID in <Switch> section with sysServicesOverride=true.
  • Will show "Switch" in Type and Context Types.
  • Same can be used to make it Type="Server" or Type="Router".
• Keep Device Type="Other", add Context Type "Firewall"?
  • Set sysObjID in <Firewall> section with sysServicesOverride=false.
  • Will show Type="Other"
  • Will show Context Types as "Other, Firewall".
• Make it Type="Switch, add Context Type "Firewall"?
  • Set sysObjID in <Switch> and <Firewalls> sections.
  • Set both with sysServicesOverride=true.
  • Will show Type="Switch"
  • Will show Context Types as "Switch, Firewall".

We can apply scenario 1 to changes made to devices with a known Type set via sysServices.0 OID values. Devices that haven't yet been touched by overrides in the DeviceTypes.xml.

We can apply scenario 2 to changes made to devices without a known Type, those without a valid sysServices.0 OID that end up with type Other. Devices that haven't yet been touched by overrides in the DeviceTypes.xml.

Additional Information

Documentation: Device Types Override documentation

https://techdocs.broadcom.com/us/en/ca-enterprise-software/it-operations-management/performance-management/20-2/building/manage-devices/override-device-types.html

Knowledge Base Article: How are Device Type values selected for device elements?

Knowledge Base Article: Debugging problems with device type overrides in CA Performance Management