Response Path items have no metric data in CA Performance Management (CAPM)
search cancel

Response Path items have no metric data in CA Performance Management (CAPM)

book

Article ID: 145503

calendar_today

Updated On:

Products

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

Issue/Introduction

A significant number of IPSLA Response Path Tests on Cisco devices are not reporting data in Performance Management.

All Views for the data from these items return "No Data To Display" or "Invalid Data".

The tests are functioning at the device level.

Re-discovering the device and the metric families and even deleting the device and rediscovering it makes no difference.

Environment

Performance Management r3.6.9 or 3.7.7 and earlier releases

Cause

The cause for the issue is a device based problem. The test bucketID values should be less than the devices sysUpTime. The problem devices were restarted but the bucketID values didn't get reset.

Detailed Poll Logging through the Data Aggregator DCDebug page (<DA_HOST>:8581/dcdebug) shows the following error for all related items.

Feb 18 21:16:16.489: CiscoIPSLAFirstPollListener processing GETNEXT response=ResponseEvent [source=Snmp, address=<Device_IP>/161, request=GETNEXT[requestID=951785610, errorStatus=Success(0), errorIndex=50, VBS[1.3.6.1.4.1.9.9.42.1.3.5.1.4.103 = Null; 1.3.6.1.2.1.1.3 = Null]], response=RESPONSE[requestID=951785610, errorStatus=Success(0), errorIndex=0, VBS[1.3.6.1.4.1.9.9.42.1.3.5.1.4.103.1260360000 = 1200; 1.3.6.1.2.1.1.3.0 = 62 days, 5:55:54.05]], userObject=ItemBasedRequestState[responseReceivedTimestamp=1582060576489, nextIndex=1, itemList=[3615901]]

, error=null]

Feb 18 21:16:16.489: Initial bucket discovery failed for IP=<Device_IP>, item ID=3615901, discoveredOID=1.3.6.1.4.1.9.9.42.1.3.5.1.4, testIndex=103. Not sending SNMP GET request and sending UNEXPECTED_END_OF_TABLE response


What we should see, from a working device with the same kind of tests is the following.

Feb 18 21:17:46.243: CiscoIPSLASubsequentBucketDiscoveryListener processing successful GETNEXT response=ResponseEvent [source=Snmp, address=<Device_IP>/161, request=GETNEXT[requestID=1790384248, errorStatus=Success(0), errorIndex=50, VBS[1.3.6.1.4.1.9.9.42.1.3.5.1.4.210.3759166294 = Null; 1.3.6.1.2.1.1.3 = Null]], response=RESPONSE[requestID=1790384248, errorStatus=Success(0), errorIndex=0, VBS[1.3.6.1.4.1.9.9.42.1.3.5.1.4.211.3758806294 = 2400; 1.3.6.1.2.1.1.3.0 = 435 days, 2:34:34.33]], userObject=ItemBasedRequestState[responseReceivedTimestamp=1582060666243, nextIndex=1, itemList=[3673572]]

, error=null]

Feb 18 21:17:46.243: OID wasn't Sys Up Time OR a new Bucket, it was : 1.3.6.1.4.1.9.9.42.1.3.5.1.4.211.3758806294 also, var.getOid shows 1.3.6.1.4.1.9.9.42.1.3.5.1.4.211.3758806294


Broadcom Engineering examined the code to determine what is done when the UEOT (UNEXPECTED_END_OF_TABLE) message is printed in releases r3.6.x and earlier. We get bucketid from the response, and we also store off sysuptime from the response. Then we compare bucketid and sysuptime to confirm the bucketid < sysuptime value. If it's not, we encounter a conditional clause where we see if we have a previous discovered bucket. If not, we set the UEOT error.

For the failure example above, if we calculate the values out we see:

  • sysUpTime is: 1.3.6.1.2.1.1.3.0 = 62 days, 5:55:54.05
  • Bucket ID for index 103: 1260360000 (a timeticks value)

To translate the timeticks value to days we use "timeticks/8640000=days" where 8640000 represents number of seconds in a day. We end up with:

  • 1260360000/8640000=145.875

Here we see the bucket ID equals 145.875 days and sysUpTime shows just over 62 days.

Does this prove out for the working device example above at test index 211?

  • sysUpTime is: 1.3.6.1.2.1.1.3.0 = 435 days, 2:34:34.33
  • Bucket ID: 3758806294

Crunch the numbers and we get:

  • 3758806294/8640000=435.0470247685185

Bucket ID is just less than sysUpTime and checks out as correct.

Resolution

This issue is resolved in changes to IPSLA polling where we allow this device to issue and still provide the expected metric data.

The changes were introduced in release 3.6.10 and 3.7.8.

To resolve this, you can choose to:

  • Upgrade to the latest available Performance Management release
  • Resolve the issue on the device with device admin or Vendor support assistance
Powered by Wolken Software