Page 1 of 1

Problem SNMP speed interface

Posted: Fri Feb 19, 2016 7:52 am
by dorwi
Hi all, I write with the help of Google translation. There is a problem. Dude does not correctly read speed interface switch equipment (interface 10GE). To solve the problem, I can upload MIB manufacturer switches in a Dude.
Question: how to make that interface Dude read out speed is loaded with MIB me?
p.s. sorry for my English )

Re: Problem SNMP speed interface

Posted: Fri Feb 19, 2016 8:33 pm
by lebowski
The Dude only uses the 32bit counters, the best you can do is create a new interface and set the speed to 4294967295, then it will record somewhat correctly but there will be gaps in the graph when the counter rolls over. You could lower the polling interval but you don't want to collect so much data. Really the best thing to do is live with it until they support 64 bit counters directly. OR you can create your own function to read the OID and use rate64 to graph your own values.

Adding MIB files to the dude changes OIDs into the text for that vendor. Also values in snmp can be float, interger, double, signed, char, etc and I think the MIB has that detail too. BUT As long as SNMP is enabled you can read any OID and use it directly in a function or a probe.

If you decide to build your own probe and use Rate64 search for rate32 in the probe tread.

Lebowski

Re: Problem SNMP speed interface

Posted: Tue Apr 05, 2016 7:25 am
by dorwi
Thanks for the answer! Do I understand correctly that standard variables such as Dude - [Device.Type] as it is impossible to change or view?

Re: Problem SNMP speed interface

Posted: Tue Apr 05, 2016 5:30 pm
by lebowski
They are derived from internal functions, I doubt you could build your own alternative since they don't allow for variables in functions. It would not be hard for them to allow for a check box that just preferred 64 bit counters.

If you have a 10gb link averaging 300mbps.That is the 32 bit counters will be rolling over in less than 2 if you probe the counter ever 1 minute. Every other time you read the counter it will have rolled over causing a downward spike then the very next read is accurate. Makes the graphs look terrible.

Found on the internet...
100 mbit/sec = 100,000,000 bits/sec = 12,500,000 bytes/sec
2^32 bytes = 4,294,967,296
2^32 / 12,500,000 = 343 seconds = 5.72 minutes between counter flips
Or, at about 105 mbits/sec, you lose the ability to accurately calculate usage in 5 minute samplings.

Or:
2^64 bytes = 18,446,744,073,709,551,616 (18 ?septillion?)
2^64 / 12,500,000 = 1,475,739,525,896 seconds = 46,763 years

So yeah we need updates... we have 30 links are converting to 10gb this year.

Re: Problem SNMP speed interface

Posted: Wed Apr 06, 2016 8:13 am
by dorwi
Thank you friend for the clarification of this issue. Now I understand this question. Let's wait for the update Dude. 8)

Re: Problem SNMP speed interface

Posted: Fri Dec 29, 2017 5:04 am
by alex1
Folks,

I have exactly the same issue with The Dude v6.40.5 (stable) and 10G interfaces on MikroTik CCR boxes with default polling interval.

The Dude only uses the 32bit counters, ...

That explains everything, but when we can expect that Dude software upgrade?
I looked through dude_v6.xx_changelog and couldn't find anything related to that issue.

Thanks!

Re: Problem SNMP speed interface

Posted: Tue Jan 09, 2018 5:27 pm
by sri2007
Yep, Dude has some issues related to SNMP, because it works in a 32bit world, however if you're using any RouterOS device, you can configure the mastering port to use routeros instead of snmp, and everything works greats, the port speeds are accurate, then conf is like this:
bgp port routeros1.JPG
And if you move your mouse over that link it shows this:
routeros 2.jpg

Re: Problem SNMP speed interface

Posted: Fri Jan 12, 2018 9:33 pm
by alex1
Very good, but it would work only for MikroTik devices. We currently have multi-vendor environment.

I'm still looking for a confirmation made by someone from MikroTik about the current situation and plans on fixing it. MikroTik might have some newer version with the fix...

Thanks.