Duplicate Interface elements in CA Performance Manager (CAPM) when integrated with CA eHealth
Article ID: 32080
Updated On:
Products
Issue/Introduction
Description:
Interface elements contributed to CAPC by both eHealth and NFA Data Sources (DS) are showing duplicate elements
Solution:
Interfaces, primarily sub-interfaces, in eHealth without an associated Parent device element are the trigger for this behavior.
Due to a lack of associated parent element in eHealth when CAPC receives the interface element for synchronization it fails to link the matching interface element contributed by the NFA DS. This results in what appear to be duplicate interface elements, often with slightly different names depending on the naming schema differences between NFA and eHealth.
The major clue that interface elements without parent associations in eHealth causes this is what data is seen in each of the apparent 'duplicate' interfaces in CAPC Dashboard Views. One element, the one contributed by NFA, will only show data in NFA based Views in the interface elements Dashboard Context pages and no eHealth based data in the eHealth Views. The other, element contributed by eHealth, shows the opposite, only eHealth based data in the eHealth Views and no NFA based data in the NFA views in its Dashboard Conext pages.
To determine if interfaces that show these symptoms in CAPC are affected by this and have no associated parent element complete the following.
- Identify an few interfaces that show this problem in CAPC.
- Search for them in eHealth and determine whether or not they have an associated parent:
- Launch the eHealth OneClick UI.
- Navigate to the Managed Resources section and select the 'Elements' option.
- Search and find an Interface that shows the problem in that list.
- If not already displayed we want to look at a column named 'Parent Name'. If not present, right click on one of the column headers in the list of elements and select the 'Select Fields...' option that should appear. Put the 'Parent Name' column into the fields to display section and select OK.
Do you see the interfaces that show this problem in CAPC with or without Parent Names defined for them? If we do see them without parents associated to them it shows us why this is happening in CAPC.
An eHealth interface, contributed by an eHealth DS in CAPC, where NFA is also a DS, MUST have an associated Parent device in order for it to be displayed in CAPC views on pages with more than one data source. Non parented eHealth interfaces will only appear as eHealth elements in CAPC and will not appear on Dashboards which contain Views for data from multiple Data Sources.
The solution amounts to a variable configuration change for Discovery Policy functionality. That change would result in newly discovered elements getting the parent set where it would currently not have one set. That change again will only impact new elements created after the change is made. This is because the discoveries would find the new association but not make it to existing elements as discoveries only update other values considered 'changes' for existing elements. This value set is considered an association in that context so wouldn't be made.
For existing elements a Policy could be created to force this change on them.
The reasons we recommend not making this change, though it is ultimately your choice, are as follows:
There is a bit of a side affect in eHealth, but it should have NO impact to CAPC report/view
In eHealth, traffic on the physical interface and traffic on the sub interfaces will be aggregated up to the router. Effectively, it will double count the bytes/packets for the routers (parent -RH) report!
In CAPC it doesn't use the aggregated design to gather/aggregate data from interface to router, like eHealth does. Instead CAPC has device level Reports/Views such as TopN reports, which use data from interface elements directly. Interfaces (and sub-interfaces) have accurate statistics data sent from eHealth.
Even for eHealth, it has limited user controllable impact.
- The parent/child association is not created for sub-interface by default
- User has control with discover parameter:
- NH_DISCOVER_VIRTUAL_INTERFACE = yes
- The sub-interface element still has accurate stats.
Further reasons why support does not recommend this solution:
- Once the change is made, is nearly impossible (read very very difficult and time consuming) to revert while eHealth is running in place.
- The only appropriate way to back out the change is to load a DB save from before the change is made. But that comes with the large downside that any data between the time of the DB save the time its loaded would be lost resulting in a data gap in reports.
Environment
Component:
Feedback
