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 <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 126.96.36.199.4.1.419188.8.131.52.14 that already has 0 rows. Re-read table=true
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.
All supported DX NetOps Performance Management releases
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.
Once the device has MIB data that doesn't generate an error when requested from the 184.108.40.206.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.
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.