Interface elements contributed to CAPC by both eHealth and NFA Data Sources (DS) are showing duplicate elements
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.
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.
Further reasons why support does not recommend this solution: