No data for eHealth based Interface Models in CA Performance Center Dashboards

Document ID : KB000032038
Last Modified Date : 14/02/2018
Show Technical Document Details

Description:

After integrating eHealth with CA Performance Center (CAPC) most interfaces show no data available message.

Solution:

After integrating eHealth with CA Performance Center (CAPC) most interfaces show a 'No data available' message in the eHealth Interface tab of the Interface elements Dashboard.

If the problem is limited to sub-interfaces or virtual interfaces, such as Port-Channel or VLAN interfaces for example, but not physical interface elements, the cause is a lack of Parent-to-Child relationship in eHealth.

Be default eHealth creates a Parent-to-Child association between a parent Router Health *-RH element and its physical interface elements.

Be default eHealth does not create this relationship between a parent Router Health *-RH element and its sub-interface elements.

Only interface elements from eHealth that have a Parent-to-Child relationship configured will show Interface data in the eHealth Interface tab in CAPC Dashboards.

How do I know if the interfaces at hand are configured without a Parent to Child relationship in eHealth?

  1. Launch the eHealth OCE UI.
  2. If this is a standalone eHealth server, connect to the host
  3. If this is a Distributed eHealth Cluster connect to the Back End Poller host that manages the device with the problem interfaces
  4. In the Managed Resources area select the Elements option
  5. Right click on the column headers and display the Parent Name column
  6. Find the interfaces that show no data in CAPC

Do they have a value in the Parent Name column? If not this is our cause.

We can fix this so that the data for these sub-interfaces without a parent relationship show up in CAPC. But there is a rather large caveat to consider when making this change.

As an example, let us pretend that we have a Router discovered in eHealth which generates an *-RH parent element, a single Ethernet interface under it, and 5 sub-interfaces. Lets say they are VLAN virtual interfaces under the Ethernet interface.

As discussed above, by default eHealth will create a parent/child relationship for the parent *-RH element and its physical Ethernet interface. This relationship will not be made for the sub-interfaces.

When running reports, the *-RH will aggregate the values for just its physical Ethernet interfaces. The reports for the individual physical interfaces will show data representing themselves and their sub-interfaces.

The solution here creates a parent relationship between the *-RH element and the sub-interfaces. The difference after this change is that now the *-RH reports showing interface data will aggregate not just the physical interface data as a whole, but it will also include the sub-interface data in the aggregated stats. That will double the count of data as the default already includes those counts.

If this is acceptable, knowing that the interface data in the *-RH reports will be doubled, while the data in the reports for the physical interfaces will remain as-is and accurate, this solution can be implemented.

Step 1:
For this to work your eHealth server must be running a minimum release of eHealth version 6.2.2 D12 (or newer) or 6.3.2.02 (or newer). If not already running those minimum or newer release options, please upgrade for this solution to be successfully implemented.

Step 2:
Set discover parameter NH_DISCOVER_VIRTUAL_INTERFACE = yes in the Discover Profile to be used for these devices

Step 3:
Run the Discovery Profile and discover with RouterSwitch mode; save the updated sub-interface elements involved

Step 4:
After few good polls you should be able to run CAPC reports with data from these interfaces assuming they now show a parent relationship.

If after rediscovery that change is not made, thus not providing a solution to this, please do open a new support issue with CA eHealth support. Note in the new issue that you are seeking assistance with the solution in this Knowledge Base Article and after discovery the sub-interfaces are failing to obtain a parent relationship for some undetermined reason.