SNMP Traffic sensor wrong bandwidth values

Dear Aeon

For comparison, please clone the sensor and set it to a 5-minute interval. Is that sensor showing the real bandwidth?

Hello

I have the same Problem. Our Traffic Sensor ist set to an 15 min intervall, but the reported values are way to low. Windows Performance monitor shows a bandwith usage of 400 Mbit/s during the last 10 hours - same in vSphere Client.

PRTG Reports an average of 30 Mbit/s

Any ideas?

Addition: 5 min intervall reports the same wrong data as the 15 min intervall. 1 min intervall reports correct data.

Regards Marcel

Dear MarcelE

If you use the tab "historic data", you get a table which also shows the total traffic volume for the time frame. Do you get the same volume for a 1-minute interval compared to 15-minute intervals, or different volumes depending on the reporting interval?

Hello Arne:

The one min data have aprox the same (wrong) bandwith, but less transferd data - which makes sense.

Regards Marcel

Dear Marcel

Please contact [email protected] and include screenshots showing the results using different report intervals. Thank you!

Just to let all of you know what the issue is...

SNMP Traffic Sensor on Windows is always a 32Bit counter. There is no possibility to use 64bit counters on Windows. Looks like Microsoft is not an SNMP fan…

https://windowsserver.uservoice.com/forums/295059-networking/suggestions/8571346-include-snmpv2-v3-64bit-counters-to-windows-serv

If you have an interface with a “high” bandwidth, you get a counter overflow if your scanning interval is too high. I did some tests and it looks really bad. Even a 60 Sec interval seems to produce an overflow on a 1Gbit interface at 90% usage… Welcome to 2017!

All our Windows SNMP traffic sensor results have the value of used toilet paper :-(

Workaround? - Use a scanning interval of 60 sec or less (Don’t know what to do on a 10 GBit interface...) - Use WMI counters - Alternative data source like vCenter

Paessler, correct me if I am wrong

Windows does not support 64 bit SNMP counters, that is correct. You can set the device options in PRTG and change the overflow handling. PRTG then detects an overflow and tries to repair the data.

Can PRTG handle more than one overflow during a scanning intervall?

I found some helpfull information about when to expect an overflow from CISCO: As the speed of network media increases, the minimum time in which a 32-bit counter wraps decreases. For example, a 10 Mbps stream of back-to-back, full-size packets causes ifInOctets to wrap in just over 57 minutes. At 100 Mbps, the minimum wrap time is 5.7 minutes, and at 1 Gbps, the minimum is 34 seconds.

So a 10Gbps interface can produce an overflow in less than 4 seconds...

Dear Marcel

There is no reliable way to determine the amount of multiple overflows. If the new volume is less than the previous, PRTG assumes a single overflow event.

You can set a traffic sensor to 30 seconds. The drawback is that if the counter does not update within 30 seconds, you will get a lot of zero values.

I have the same problem. but changing intervall does not help. the bandwidth is so far off. I am downloading with 10mb/s but rptg shows I am using 600mbit/s. I do have a 500mbits fiber connection. Have tried with both 5-15-30-60sec interval but all are way off. any idea on how to fix?

Dear U5,

the first thing to check would be if you monitor the right port there. Please also check if the device supports other traffic measurement options, like Netflow. If that is the case, please add such Flow sensor in order to get a reference for comparison.