CPU name not consistent with VC formula in DX NetOps CA Performance Management (CAPM) when detecting devices

Products

• DX NetOps
• CA Performance Management - Usage and Administration

Issue/Introduction

CAPM in some cases does not appear to create correct names as per the Vendor Certification (VC) metric formula. In this case, the formula is:

physname=(isdef(entPhysicalName)?entPhysicalName:""); phys=((physname!="")?("-"+physname):""); modelname=(isdef(entPhysicalModelName)?entPhysicalModelName:""); model=((modelname!="")?(" Model: "+modelname):(" "+cpmCPUIndex)); return "CPU"+phys+model;

From a MIB walk of the Cisco 7609 device, for CPU indexes 1 & 2, the values are:

1.3.6.1.2.1.47.1.1.1.1.13.1   , OctetString , CISCO7609
1.3.6.1.2.1.47.1.1.1.1.13.2   , OctetString , 
1.3.6.1.2.1.47.1.1.1.1.7.1    , OctetString , CISCO7609
1.3.6.1.2.1.47.1.1.1.1.7.2    , OctetString , Physical Slot 1

where

1.3.6.1.2.1.47.1.1.1.1.13 = entPhysicalModelName
1.3.6.1.2.1.47.1.1.1.1.7  = entPhysicalName

So, going by the VC name formula we get for Index 1:

physname=(isdef(entPhysicalName)?entPhysicalName:"");               1.3.6.1.2.1.47.1.1.1.1.7 - CISCO7609
phys=((physname!="")?("-"+physname):"");                            -CISCO7609
modelname=(isdef(entPhysicalModelName)?entPhysicalModelName:"");    1.3.6.1.2.1.47.1.1.1.1.13 - CISCO7609
model=((modelname!="")?(" Model: "+modelname):(" "+cpmCPUIndex));   Model:CISCO7609
return "CPU"+phys+model;                           

               
So CPU name for Index 1 = CPU-CISCO7609 Model:CISCO7609

And for Index 2

physname=(isdef(entPhysicalName)?entPhysicalName:"");               1.3.6.1.2.1.47.1.1.1.1.7 - Physical Slot 1
phys=((physname!="")?("-"+physname):"");                            Physical Slot 1
modelname=(isdef(entPhysicalModelName)?entPhysicalModelName:"");    1.3.6.1.2.1.47.1.1.1.1.13 - “”
model=((modelname!="")?(" Model: "+modelname):(" "+cpmCPUIndex));   cpmCPUIndex
return "CPU"+phys+model;                                            

So CPU name for Index 2 = CPU-Physical Slot 1 2

However, what we see in the Components view is a bit different:

Environment

DX NetOps CAPM all supported releases

Cause

Based off the vendor certification (VC), we're not doing a 1-to-1 mapping of the indexes like you appear to be checking. There is a mapping in the Vendor Certification (VC) that tells CAPM which indexes of the OID to use.

According to the VC, it's taking the value of 1.3.6.1.2.1.47.1.1.1.1.4.x and using it to look at the row in 1.3.6.1.2.1.47.1.1.1.1.7 pointed to by that value.  

     <IndexTag>
       <Name>entity2Table</Name>
       <PrimaryKeyExpression>entPhysicalContainedIn</PrimaryKeyExpression>
       <ThisTagKeyExpression>entity2Index</ThisTagKeyExpression>
     </IndexTag>

Searching for those OIDs in the MIB walk, at the first three indexes for 1.3.6.1.2.1.47.1.1.1.1.4, we see:

1.3.6.1.2.1.47.1.1.1.1.4.1    , Integer     , 0
1.3.6.1.2.1.47.1.1.1.1.4.2    , Integer     , 1
1.3.6.1.2.1.47.1.1.1.1.4.3    , Integer     , 1
etc...

It's taking the value of 1.3.6.1.2.1.47.1.1.1.1.4.x (entPhysicalContainedIn) and using it to look at the row in 1.3.6.1.2.1.47.1.1.1.1.7 (entPhysicalName) pointed to by that value.  

Then looking at the values (0 & 1), there are no rows pointed by 0 in the MIB walk, but there is for 1 in 1.3.6.1.2.1.47.1.1.1.1.7:

1.3.6.1.2.1.47.1.1.1.1.7.1    , OctetString , CISCO7609

So, from the VC mapping, it's using the above, single OID - 1.3.6.1.2.1.47.1.1.1.1.7.1, in getting to 

CPU Model: CISCO7609
CPU-CISCO7609 2
CPU-CISCO7609 3

Resolution

This is working as designed. Always check the VC to see where the actual OID values are coming from.