DX Unified Infrastructure Management

Hi,

While running the utilization report for the interface, its showing 150 to 200%. But the actual utilization is 75 to 100%.

NFA parser output is also showing the same percentage.

What could be the reason, why it is over populating.

Regards,
Kavi

Percent utilization is based on what ReporterAnalyzer obtains via SNMP from the router about the bandwidth of the interface. If the router is returning a bandwidth smaller than the actual bandwidth, then normal traffic utilization could easily result in a calculation of more than 100%. If the router is returning the correct information about the bandwidth of the interface (you can check under Admin->interfaces->physical & virtual) and still calculating higher than 100% utilization, you may have a problem with your netflow config. Check the commander to make sure you have all your commands in the router properly. It is also possible for certain interfaces to use more than the CIR (in which case >100% utilization would be expected when bursting).

This is from eHealth KB...hope it may be useful.

KB ID: TS11776
How can bandwidth utilization be above 100%
Spikes in bandwidth utilization on reports
Bandwidth utilization is exceeding 100%
Reporting
eHealth
Possible causes
1. The element is either Frame-Relay or an ATM subinterface
2. The elements speed is incorrect in the eHealth poller, or there was a recent change to the elements speed
3. The element is full duplex but is discovered and treated as half duplex
4. The devices snmp counters were reset between polls
1. If the element is Frame-Relay or an ATM subinterface, it can exceed 100% utilization. Please see KB Document: dev121 Frame Relay or ATM subtinterface Bandwidth Utilization exceeds 100% for more details.

2. The bandwidth utilization calculation uses the elements speed in its equation, so if it is too low the result will be too high. Check the speed set in the poller config GUI against the actual elements speed. Also, if there was a recent change to the elements speed, then there is a possibility that some of the old data will be incorrect. We do not store different speed values for elements in the eHealth database - every element only has one speed value, so if there was a change in the speed, the equation is using the new speed value to calculate utilization on older polled data.

3. If the element is truly full duplex but is calculated as half duplex the result will be too high. Run a Trend report for the device for bandwidth utilization in, out, and total. If in and out equal total then the element is being treated as half duplex. If total equals the average of in and out it is being treated as full duplex.

If the element is full duplex and being discovered as half duplex Please check KB Document TS11029 for help on element's operational speed characteristics are incorrectly set to 'half-duplex' instead of 'full-duplex'

Please check KB ID TS7596 For an explanation of full duplex bandwidth calculations, which explains the total bandwidth calculation for a full duplex line

4. The device counters have been reset.

Assume theoretically that the device mib counters only went to 1000, as opposed to 2 to the 32nd or 2 to the 64th power. eHealth polls for values every 5 minutes by default. If the counter was at 10 on one poll and 50 on the next it would calculate that 40 occurred during that time frame. If the counter was at 970 at one poll then 10 at the next. eHealth would calculate that 40 occurred during that time frame. (1000 - 970) + 10 = 40.

Now let's assume that the counter was at 600 at one poll. Then the counters get to 670 but then are reset to 0. At the next poll the counter is at 10. eHealth calculates (1000 - 600) + 10 = 410, since it has no way to know the counters reset.

If the delta between the first and second polled values is greater than 1/2 the possible delta in the counters (for example, (2^32)/2, or 2^31), then eHealth will display a large delta message, and drop the polled value. If it is less than this, then eHealth will populate the database with the calculated values. So if the counters were reset when the value was greater than 2^31, then it is possible to see a skew in the datapoint.

I assume since you mention the NFA parser that you're not talking about eHealth as a data source, but RA. In that case only cases 1 or 2 could apply since RA doesn't poll for the statistics themselves, but polls only the interface configuration.

Also, since this applies to RA, i'm moving this thread to that category.