Data in Reports Seems Inconsistent

This issue is one of the hardest issues to troubleshoot. Consider the following possible causes:

Mismatched report types - If you run a host-centric NetProfiler report versus an interface-based report.

A host centric-report is any report you run from the Reports > Traffic Reports page, and select the Host, Application, or Advanced tab. These reports always query the database based upon the perspective of the hosts in the hosts field. When you run these queries, you look for all hosts matching the query conditions, and all output is from the perspective of the hosts.

An interface-centric report is any report you run from the Reports >Traffic Reports page, and select the Interface tab. These reports always run from the perspective of the interfaces in the interface field. When you run these queries, you are querying for all interfaces matching the query conditions, and all output is from the perspective of the interfaces.

Missing data - The primary causes of missing data are as follows:

No coverage of the desired data - With a large network, you can have pockets of data that are not covered by devices reporting to the NetProfiler: for example, a branch office might not have a device reporting traffic internal to the branch. You cannot report on traffic for which there is no coverage.

Too many devices reporting data - The NetProfiler currently is limited to storing data from a five devices. If flow is reported from more than five devices, the data is not retained. This results in the reported traffic rates for those devices being inaccurately low.

Missing directional data (ingress or egress) - When you export NetFlow, depending on the version and device type, you might not be able to export both ingress and egress data for each interface. Consider a common example in which only ingress data is received with NetFlow v5. When the flow records are sent, the egress interface is indicated in the record, even though the statics are counted on an ingress interface. When NetProfiler receives these ingress records, it assumes that the data is preserved as it passes through the device. This means that if the record is received on Interface 1, and the record indicates the egress interface is Interface 2, NetProfiler assumes that this amount of data leaves the device on Interface 2.

In some cases where this assumption is not valid: for example, on a router with a 10-Mbps interface on one side, and a 1.5-Mbps interface on the other side, and the router is forced to dropped data due to the 1.5-Mbps interface being oversubscribed. Because the NetProfiler has no way of knowing how much data actually went out the other interface, the numbers can be incorrect. If the 10-Mbps interface is receiving 5 Mbps, the NetProfiler reports 5 Mbps leaving the 1.5Mbp-interface because this is the best data NetProfiler received.

Routing issues - The NetProfiler must detect all the details of each flow that it reports on to provide accurate information. When you have asymmetric routing (where traffic takes one path from client-to-server and a different path from server-to-client), the NetProfiler can miss one side of the conversation. This results in inaccurate information from reports.

Different data resolution - While the NetProfiler provides several different data resolutions, many other devices do not provide multiple resolutions or do not allow detailed control over which resolution you use. Comparing a report from two different resolutions (for example, one hour on the NetProfiler and five minutes on a router) is very likely to result in differences in reported values.

Reporting device settings - Reports are not correct when the NetFlow export settings on the reporting device (for example, the router) are not as per the Riverbed recommendation.