Interfaces not being discovered in NetOps Data Aggregator

Products

• CA Performance Management
• Network Observability

Issue/Introduction

Devices are discovered in the DX NetOps Performance Management Data Aggregator. Some are missing Interface items. The High Speed Interface Vendor Certification (VC) is supported from the Interface Metric Family (MF) but no interface items are created. The same devices show interface items and data in Spectrum without issue.

There are two VC's supported for the Interface MF due to Vendor Certification Priority (VCP) Grouping. Neither has interfaces discovered for polling.

In Discovery log messaging for the device from the http://<DAHost>:<Port>/dcdebug page we see hard errors trying to query the OID's required for the Viptela VPN Interface (Port) VC. Sample error message is below. Note the "SNMP error -1" error message in the response from the device.

Mar 15 13:12:37.404: SNMP error -1 for column 1.3.6.1.4.1.41916.12.2.1.14 that already has 0 rows.  Re-read table=true

Environment

All supported DX NetOps Performance Management releases

Cause

One of the two VC's is receiving hard errors from the device when the VC OIDs are requested.

When VCP Grouping is configured, both VC's must reach a complete and error free discovery cycle seeking it's required OIDs. If any OIDs return hard errors no items will be created.

Resolution

Because there are hard errors in the response for the MF discovery run, we consider the data suspect and drop it all without generating interface items for polling.

To resolve it we have a few options.

1. Break the VCP Grouping that allows discovery of both of those Interface VCs against devices.
   1. Would affect all devices using that MF, not just problem ones.
   2. Unlikely the best or optimal fix but is an option worth mentioning.
      
      
2. Fix the device problems with the error responses. If the device did either of the following instead of returning errors we'd continue working with the data returned for the "High Speed Interface" VC. We'd generate it's items for polling.
   1. Fix the device so it returns valid values from the 1.3.6.1.4.1.41916.12.2.* OIDs required for the "Viptela VPN Interface (Port)" VC.
   2. Remove the MIBs from the device that support the OIDs the "Viptela VPN Interface (Port)" VC requires.
      1. The noSuchInstance type of errors that would return if the OIDs aren't present aren't the same 'hard' error the device is currently returning.
      2. Those messages in the device response would allow the rest of the data received to be properly processed.

Once the device has MIB data that doesn't generate an error when requested from the 1.3.6.1.4.1.41916.12.2.* OIDs required for the "Viptela VPN Interface (Port)" VC we'd be successful in discovering the interfaces sought for polling.

Additional Information

This article addresses a set of errors from a MIB table and all it's OIDs from the Vendor Certification involved.

If the errors are from a single problem OID, the following article can be used as a solution by removing the OID from queries using an extension.

KB : VIPTELA "Viptela VPN Interface (Port)" Interfaces on vEdge 1000/2000 devices Are 'Not Polled' or not discovered in DX Netops