I have a deployment of the dude running on x86 ver 6.41. It has been set up and running for a year. I monitor my watchguard utm appliances and interfaces to ISP uplinks and Branch office VPN’s. Yesterday we had to perform a firware upgrade on all 5 of our watchguard utm’s and since then all SNMP links on the dude map will not display any bitrate. To be more precise, they are displaying 0 bps for rx and tx, not returning null values. When i access the device settings in the dude and navigate to the SNMP tab, interface sub-tab, the dude it reading the tx and rx bitrates of the interfaces. Any clue as to what may be causing this issue? Please let me know if any other information would be helpful.
I have added one of the devices to a test map as you suggest, and still not working correctly. I have attached a screenshot of the properties dialogues open, so hopefully that will help
Om my test map I have something like this:
Does the issue is manifested only with one host/link or with any other links too? Do you have a possibility to verify it on another device/link?
I have 5 watchguard firewalls and all links to them are responding the same since we upgraded the firmware on the firewalls. I have verified all of them on the test map with the same results. I was searching some more on the forum and found this http://forum.mikrotik.com/t/problem-snmp-speed-interface/95546/2
Do you think that the upgrade changed the counters to 64 bit and this is the problem. If so, can you provide some assistance in building a new function as described as I am not very good with snmp at all.
Q. When should 64-bit counters be used?
A. RFC 2233 adopted expanded 64-bit counters for high capacity interfaces in which 32-bit counters do not provide enough capacity and wrap too fast.
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.
In case of 1Gbps interface, 32-bit counters should feet our needs.
I am not sure what this would change as according to the SNMP tab of the watchguard device, it is reading bandwitdh of the interfaces correctly.
I have been trying to understand the code Mikrotik uses to determine these bandwidth calculations, but I do not understand it, therefore, I dont know what to change if a change is needed due to the new watchguard interface oids
So, I have determined that I am pretty sure the issue with this is the built-in function link_index. I am certain that this is not an error, rather, the probe is actually reading a value of 0 for tx and rx bitrate. Since watchguard has informed me that the interface indexes changed in their latest software release, I am sure this is the problem. The question is, what is Mikrotik using to determine link_index. I can customize a function with the proper parameters from the information from watchguard, but I have no idea what Mikrotik is calling for link_index value to even know where to begin. Anyone shed some light on this?
Update on this. I loaded up a new vm with 6.41.2 CHR and have recreated the watchguard and main switch and added a link that should reflect Interface Eth 0/1 on the firebox. I have attached a screenshot and as you can see, I am getting no information on the link display for tx or rx bandwidth, however, under the device settings on the watchguard under snmp/interfaces, I am reading correct bandwidth usage on all links. It appears that there is an issue somewhere in where the dude is translating the function [Interface.InBitRate] and [Interface.OutBitRate] on the link display. Almost like the Interface part is not reading the interface list from SNMP data. Is there any way to fix this?
It seems this issue is related to Dude ver 6.x I have since created a test machine on 4.0b3 and everything works as it should. I think we are going to migrate back to 4.0b3 until 6.x proves to be more reliable. It appears that Mikrotik has once again ceased development of the dude as no feature updates have been added in quite some time. Disappointing to say the least. Thank you everyone for the help with troubleshooting this.