Excessive unwanted Cisco Airespace Wireless Interface elements created in CA Performance Management (CAPM)

Products

• CA Infrastructure Management
• CA Performance Management - Usage and Administration
• DX NetOps

Issue/Introduction

We have recently discovered and added Cisco WLC devices to CA Performance Management. The physical interfaces discovered against the High Speed Interface Vendor Certification are working fine.

There are also an excessive number of unwanted Cisco Airespace Wireless Interface elements being discovered. This has resulted in thousands of unwanted interface components that users now have to sort though in the interfaces table in order to find the physical interfaces they want information for.

When viewing the devices there are dual Metric Family entries found for the Interface Metric Family. Both show supported Vendor Certifications with actively polled elements.

One is the desired High Speed Interface Vendor Certification for the physical interfaces. The other is the unwanted Cisco Airespace Mobile Interface Vendor Certification.

The Interface Metric Family is only tied to the device through a single Monitoring Profile and Collection association. It isn't applied twice anywhere in the configuration.

How can these elements be removed and how can we prevent creation of new ones?

Environment

All support CA Performance Management releases

Cause

This is caused by Vendor Certification Priority (VCP) Priority Group configurations. 

The Interface MF NormalizedPortInfo shows these VCP entries for the ifXTable (High Speed Interface VC) and CiscoAirespaceWirelessMib (Cisco Airespace Mobile Interface VC). 

<VendorCertID>{http://im.ca.com/certifications/snmp}IfXTableMib</VendorCertID> 
<PriorityGroup>HuaweiQosHS,TimetraMPLSPortHS,AlteonPortHS,NetScreenHS,CeragonPortHS,StarentScreenHS,RadwareQosHS,RedBackPortHS,NetscalerIfStatHS,DSLPortHS</PriorityGroup> 

<VendorCertID>{http://im.ca.com/certifications/snmp}CiscoAirespaceWirelessMib</VendorCertID> 
<PriorityGroup>RedBackPortHS,RedBackPortLS</PriorityGroup> 

Because the IfXTableMib is supported, and has RedBackPortHS in the PriorityGroup, it ties it back to the other PriorityGroup linked to a VC that the device supports. That would be the CiscoAirespaceWirelessMib. 

Discovery finds support for and creates elements against IfXTableMib VendorCertID. It then looks to find VCs in its PriorityGroup that exist in PriorityGroup entries for other VendorCertID entries. RedBackPortHS is in the PriorityGroup for both. The device does support the CiscoAirespaceWirelessMib VC. 
The elements get discovered. 

Resolution

Group Vendor Certification Priorities

Grouping vendor certification priorities lets you use more than one vendor certification for the same device. A single vendor certification priority can belong to as many priority groups as necessary for your application. When a device is discovered, all vendor certifications in the priority group are supported on the device.

Important! Do not update PriorityGroup and change the order of the vendor certifications in the same REST call. Changing both simultaneously may disrupt automatic rediscovery. For more information, see Automatic Rediscovery Does Not Run After Updating Vendor Group Priority.

To group vendor certification priorities, use the REST Web Services. You cannot group vendor certification priorities using the UI.

Follow these steps: 

1. Run a GET operation on the following REST URL:
   

   http://<DA_HOST>:8581/rest/vendorpriorities/

   The REST call returns a list of all the vendor certification priorities.
   
   
2. Determine the ID of your metric family in the list of vendor certification priorities.
   
   
3. Run a GET operation on the following REST URL:
   
   http://<DA_HOST>:8581/rest/vendorpriorities/ID
   
   The XML of the vendor certification priority that you want to modify is retrieved.
   
   
4. To add a vendor certification priority to a group, add a <PriorityGroup> tag to the vendor certification.
   Example:
   In this example, the vendor certification priority is added to the group entitled "F5".
   
   <CertificationOrder>
  <CollectionID>167</CollectionID>
  <VendorCertID>{http://im.ca.com/certifications/snmp}F5BigipMultihostCpu</VendorCertID>
  <PriorityGroup>F5</PriorityGroup>
</CertificationOrder>
   
   Important! Proper XML for the <VendorCertID> tag is written on a single line, and excludes spaces and carriage returns. Failure to follow this guideline causes the vendor certification priority to fail.
   
   
5. (Optional) To add a single vendor certification priority to multiple groups, separate the group names using commas. 
   Example:
   
   <PriorityGroup>F5, Huawei</PriorityGroup>
   
   
6. Remove the <ID> and <MetricFamilyID> tags from the vendor certification priority XML.
   
   Leave the rest of the file intact.
   
   
7. Run a PUT REST call on the following URL to import the new XML file:
   

   http://<DA_HOST>:8581/rest/vendorpriorities/ID

   ID
   Specifies the ID of the vendor certification priority.
   CAPM rediscovers all devices that support the metric family.

In this situation the following specific change was made to have PriorityGroup for the CiscoAirespaceWirelessMib VC now show: 

<PriorityGroup>RedBackPortLS</PriorityGroup> 

After the change was made an Update Metric Families run was requested from the devices Polled Metric Families tab. When it completed the second Interface Metric Family entry was removed. 

After some time the elements should show in PC as Inactive. Their DA DS is sync'ing Inactive or Not Present items. 

Once that takes place we can then use the cleanupComponents.sh script to remove the inactive elements from cluttering the system. That script is found on the Data Aggregator in (default path) /opt/IMDataAggregator/scripts.