New Question
 
 
PRTG Network Monitor

Intuitive to Use.
Easy to manage.

200.000 administrators have chosen PRTG to monitor their network. Find out how you can reduce cost, increase QoS and ease planning, as well.

Free PRTG
Download >>

 

What is this?

This knowledgebase contains questions and answers about PRTG Network Monitor and network monitoring in general. You are invited to get involved by asking and answering questions!

Learn more

 

Top Tags


View all Tags


SNMP Traffic sensor wrong bandwidth values

Votes:

0

Your Vote:

Up

Down

Hi, I'm testing PRTG to have an overview of the bandwidth usage for our WAN connections but it seems the values returned are not correct. I use 30 seconds intervals, 64-bit snmp traffic sensor with snmp 2c authentication to cisco switches. We have different WAN connections: 10mbit symmetric & 30mbit symmetric. But even if I do speedtests (which show the correct values) and on moments the lines are saturated PRTG only shows about a third of these values (sensor values are set to mbit/s on the root). This also shows when I use custom ranges with raw data (no averages). Can I do anything about this?

bandwidth snmp traffic wrong

Created on Nov 16, 2016 3:36:32 PM by  Aeon (0) 1



12 Replies

Votes:

0

Your Vote:

Up

Down

Dear Aeon

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

Created on Nov 18, 2016 2:35:20 PM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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?

Created on Feb 17, 2017 10:14:51 AM by  MarcelE (100) 2



Votes:

0

Your Vote:

Up

Down

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

Regards Marcel

Created on Feb 17, 2017 10:29:56 AM by  MarcelE (100) 2



Votes:

0

Your Vote:

Up

Down

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?

Created on Feb 17, 2017 12:59:17 PM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

Hello Arne:

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

Regards Marcel

Created on Feb 17, 2017 1:09:23 PM by  MarcelE (100) 2



Votes:

0

Your Vote:

Up

Down

Dear Marcel

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

Created on Feb 17, 2017 3:23:39 PM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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

Created on Feb 24, 2017 2:18:36 PM by  MarcelE (100) 2



Votes:

0

Your Vote:

Up

Down

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.

Created on Feb 24, 2017 3:07:37 PM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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...

Created on Feb 27, 2017 10:42:30 AM by  MarcelE (100) 2



Votes:

0

Your Vote:

Up

Down

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.

Created on Feb 27, 2017 1:16:13 PM by  Arne Seifert [Paessler Support]

Last change on Feb 27, 2017 2:23:10 PM by  Arne Seifert [Paessler Support]



Votes:

0

Your Vote:

Up

Down

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?

Created on Oct 14, 2017 9:43:29 PM by  U5 (0) 1



Votes:

0

Your Vote:

Up

Down

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.

Created on Oct 16, 2017 7:46:42 AM by  Arne Seifert [Paessler Support]



Please log in or register to enter your reply.


Disclaimer: The information in the Paessler Knowledge Base comes without warranty of any kind. Use at your own risk. Before applying any instructions please exercise proper system administrator housekeeping. You must make sure that a proper backup of all your data is available.