Once again.
I turn attention to it because it’s a natural and important functionality for the program to monitor the network.
I will try to explain well.
When there is a tree of connections between devices, and the first of them stops working, “the dude” send notifications about failure of all devices below tree. Example for 200 devices.
Imagine that, when sms is a notification, and I get 200 sms messages about not running devices when the first device stop working. I should get one notification about failure for highest devices on the parents tree.
asik, I’m having similar or same issue with devices on the same map and I’ve set the Parents field with upstream device. I’m getting mixed results and haven’t had time to try to isolate exactly what is happening. We monitor independent customer sites. At some sites I seem to get a notification for all devices (approx 50) when their Internet goes down. Other sites it is only a few of the devices.
One question I have is do you need to enter all devices in the upstream hierarchy, or just the immediate parent?
Also, what happens when the parent goes down in the middle of the polling cycle for that network? i.e. the parent device goes down after it is polled successfully and the Dude is still polling the downstream devices, so those devices would go to down status before the parent. I assume we would get notification for those devices before the parent. Is the Delay setting for the notification supposed to prevent this?
tber, thanks for your understanding of the problem, I have quite the same issues.
It seems that the idea for probing devices by “the dude” is to completely rebuild, on stage, dependent of the position the devices in the hierarchy tree.
Intelligent probing on stages, depending on the location of the tree prevent the notification for multiple devices when the main device with access to the Internet goes down should be deploy.
Below a simplification.
It looks like there are issues with SNMP. Interface Traffic Graphs does not show the real traffic the link had, it looks like some SNMP queries are lost. Same devices are graphed with Cacti and/or RouterOS own tool->graphs so I can make the comparison and I’m sure about it.
Also noticed that can’t get SMP info from Ubiquiti EdgeSwitches, and previous versions did.
*) Fixed - Submap icon wasn’t placed on map if “New Map” option was used.
*) Fixed - Custom tool wasn’t accessible from Devices-> List
*) Fixed - Device → RouterOS didn’t show interfaces in interface dropdown list
*) Fixed - Error was displayed when tried to edit multiple simlpe queues
asik - at the moment it’s possible to use device tree structure:
[Parent device]
└──────────[Child device]
If Partent device is down (Child device also is not reachable) you will receive notification only about Parent device.
When the parent is reachable again, you will receive notifications about both devices (This will require little change, not to send child notification if it’s under parent).
joanllopart - Can you give us example ?
Just note that due to priorities, development of new features/fixes might delayed, but the suggestions/reports are always appreciated and stored.
For example CCR1072’s port sfpplus8. Graphed by router itself (tools → graphing):
Same port traffic graphed by cacti:
Now graphed by Dude 6.39rc7:
If we look closer to last hour:
It looks like it loses some SNMP readings when traffic goes over 1Gbps (It’s a 10Gbps port). But I’ve seen similar behaviour on other graph’s links that handle much less traffic.
PaulsMT - I wish the dude functioned as you write above.
I use device tree structure for my setup (with 400+ devices) and it does not work as expected.
Maybe the problem lies in probing. When a PARENT stops working, often first CHILD is marked down and “the dude” send notification, then “the dude” probe parent device and send notification too. In this way sends multiple notification’s about one failure.
If you can’t reproduce the problem I can share my dude remotely.
Maybe I have a problem with the configuration? below my settings.
Chupaka - change timouts for devices in a big device tree structure is complicated and a there is no sure about the expected results.
I finger crossed, that MT team find solutions for this problem.
I doubt they removed it in v6.x
Let’s not talk about the obvious, is that possibility, but does work in your configuration? in my not. Please click the link to the post stated below:
