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.

thanks

apiel1, hello!

Maybe interfaces indexes were changed and need to be re-selected on link properties, may you look at this?


Thank you!

Thank you for the reply. I have checked and the interface index is set correct on all of the links

apiel1,

May you try to add devices and their links on the test map in same Dude to verify if newly created object will work as expected?


Thank you!

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

Thank You again for the reply

apiel1, thank you for provided information!

It looks like all is configured correctly on your side and Dude got information using SNMP.

May you try to add some variables into the link label, near existing one?
Thank you!

I have added the variables to the link labels and below is a screenshot of the results

Thanks

apiel1,

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?


Thank you!

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
viewtopic.php?f=8&t=105008&p=522404&hil ... 32#p522404

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.

Thanks

apiel1,

Which interfaces do you have on your devices - 1Gbps or 10Gbps?

From the SNMP Counters: Frequently Asked Questions:

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.


Thank you!

The are all 1Gbps links. No 10Gbps

Thanks

Hello, apiel1!

May you try solution described in the forum topic - problem with ?? links on dude?
Wiki - Manual:The_Dude_v6/db_vacuum


Thank you!

I ran the database vacuum function and still have the same results.

Thanks.

apiel1,

Thank you for verification!

To exclude possible bugs in Dude v6, may you verify how it will work with Dude v3.6 of 4.0b3?


Thank you!

I tried same setup on 4.0b3 and everything works as it should. According to Watchguard, they did make a change that caused the OID numbers for the interfaces to be different as detailed in the link below
https://watchguardsupport.secure.force. ... lang=en_US

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

Any other advice on this?

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?

Thanks

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?

I have also received the following information from watchguard confirming that they did indeed change the interface oid values in the last upgrade, but i find this hard to believe that this is the problem as i am reading correct SNMP data on the device from within the dude as evident in the screenshot.
https://watchguardsupport.secure.force. ... lang=en_US

Any help or insight on this would be greatly appreciated.

I have same ??? issue on SNMP V1. Try SNMP V2c on device and The Dude

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.

I had the same problem with RADWIN radios, they use to work well on 3.6 version. It´s very said that the dude has stopped again, let´s hope this is not for long.

SO I thought I had solved this issue, by migrating back to 4.0b3 as in my tests i was showing SNMP link bandwidth, but it turns out, the problem is only partially solved. I am now getting bandwidth on the Links, but it does not update unless I double click on a link and bring up the settings dialogue box fo the link, then all of the snmp data on all of the watchguard links will update, but will not unpate on its own (10Sec interval is what is set to update labels). Also will not graph throughput. Any thoughts on this one?

I have ?? on some links. The Dude 6.41.2. Vacuum-db doesn't help.
Another server V4.0beta3 has no issue.

Probably, same issue viewtopic.php?f=8&t=118803&p=653750#p653750

I'm still having the same issue, who figured out how to fix it?