Hello!
I have Dude 6.42.6 on RouterOS on eSXI server and the problem is that the Dude have very small pieces of link graph history. It is looks like this:
And, as you see some links show history only for 4 am, but now 11 am at my place (and it is router time).
Other link examples:
All this links are always up and always have good traffic. Last one always have at least more than 50 Mbit/s
I remeber this problem for about an year for different versions (I have autoupgrade script).
My maps have a lot of devices (about 1700), there is a big operator network.
What can I do with it?
Thank you in advance!
Are the holes at the same place of all graphs? If not then you could have some kind of packet loss, maybe some antiflood filter takes place somewhere in the network?
Hi,
I have similar experience and I can clearly map those holes it to time periods, when SNMP is not available (for example network problem, device turned off, SNMP service stopped etc..)
Same apply for the chart which ends on 4am - it means since then, there is no SNMP data available → no data for chart → chart does not update X axis with empty data (thats kind of error in TheDude graphing. I believe it should show empty data, but the graphing still needs a lot of development)
Can you make sure that you can do manual SNMP walk for devices which are missing chart at current time? Let us know your finding.
We have same problem. There is a few more posts about snmp issues on the dude V6. If at least one of your devices on that link - Mikrotik, i would recommend to use RouterOS instead of SNMP. But if both devices - non-MT you should try SNMP V2. Or just wait while MT fix that SNMP issue
Yesterday, I experienced similar thing - all SNMP probes died for my whole network.
Firstly, my dude stopped working due to out-of-space (which is nonsense because it was on 4GB drive with 3GB of free space) anyway, I added second drive moved the dude folder there and restarted dude.
Dude started but somehow, it was ignoring SNMP data once per 5 minutes, despite the fact that manual SNMP walk showed the data. There was nothing I could do until I deleted around hundred of excessive devices which I didn’t need - suddenly after deleting those, it started working fine.
This led me to thinking
maybe it is related to amount of data in database?
what if there is some limit on outgoing periodic SNMP requests and once you have enough devices in your network map, dude simply cannot catch up and starts skipping SNMP requests, leading to drops of probes?
I am absolutely certain that there is no firewall related setting in my case and except of deleting extra (mostly dead) devices from DB, I didn’t change anything else.
Currently, I have 170 devices, most of them windows computers with several SNMP probes and probe interval is 30s. I will keep updates once it happens again (I am sure it will, it is just matter of time because one of the reasons must be related to the condition.)
We can see gaps on the graph, few hours each, but dude snmpwalk works good always at the same time. Nonsense. I’m pretty sure this is a software issue, Mikrotik must to fix it.
Of course it is software issue but it would be helpful if we put together our knowledge about the issue and help Mikrotik reproduce it. Obviously, it is not happening all the time but just under some conditions. Unless Mikrotik find out these conditions, they can’t fix it. And we can help them find it.
I shared my findings so maybe someone will find himself in same position which might confirm the how it happens and help to resolve the issue.
