We added a Cisco switch to our edge and I cannot seem to get the History Graph Bit Rate to report correctly. On the inside a RouterOS device shows peak traffic at 6g but on the outside Cisco device the peak for the same time is less than 3g. The only significant difference in the link settings are routerOS vs snmpv2. So far I have been unable to get the ouside Cisco snmp link to graph to match the inside and they should be very close as these links are inline with one another. I have read lots about the Dude snmp issues but have not yet found a resolution. I played around with changing the Appearance Label from using the Out/Inbit rate Variables to an OID but these changes do not seem change the history graphing. If I change the routerOS side to SNMPv2 I can get the inside graph to match the outside graph but it is still showing about half the actual peak traffic. Any ideas on how to get the SNMP side to graph correctly?

The issue is most likely a signed integer overflow (32768). Maybe try bringing the value from SNMP as RAW.

The issue is most likely a signed integer overflow (32768). Maybe try bringing the value from SNMP as RAW.

How would I do that ?

Add a function SNMP_BitRateLarge then in the code type oid_raw("1.3. . . .") put the correct OID number in between the quotes.

Changing the link label has zero impact on what the history graph looks like. I can get the link label to show a good bit rate. I need the history graph to report the bit rate correctly.

Changing the link label has zero impact on what the history graph looks like. I can get the link label to show a good bit rate. I need the history graph to report the bit rate correctly.

.
This is not changing the label. It's creating a new function that you use as the source to graph. Not the inbuilt SNMP Bit_rate.

The problem is that there exists not SNMP value that tells you the bitrate. Instead, there are SNMP values that count the bytes transferred via the interface, and the bitrate is calculated by reading these values at regular intervals and subtracting two adjacent values and dividing by the time between the readings, then multiply by 8 to get bits/s instead of bytes/s.
As the values are only 32 bits, and they are read every 5 minutes the calculation is wrong because in 5 minutes more than 2^32 bytes can flow through the interface.

This can be solved by making the interval smaller (e.g. 1 minute for such kind of speed) or by using 64-bit values for the counters (which Dude cannot do).

I finally resolved my issues on this one link by reducing the polling interval from 10 sec to 5 sec. This seems to only impact my 10g links that run higher than 4g. I have several 10g links that run 1-3g and they seem fine.