Dude v6 - Dependencies - How does it work?

eriitguy · Mon May 22, 2017 10:24 am

Hello!

We have started to use dependencies in Dude v6.

We have one device with LAN and WAN address.

For example
Gateway-WAN - 10.0.0.1
|-- Gateway-LAN - 192.168.0.1

Gateway-LAN can be up only if Gatewa-WAN is up.

When device Gateway-WAN goes down we receiving only notification about its down status.
When it goes up we usually get 2 notifications:
Gateway-WAN is up
Gateway-LAN is up

But some time we get only one notification:
Gateway-WAN is up

Does it mean that in second case Gateway-LAN was up after Gateway-WAN went back up and check of Gateway-LAN was performed?

In such case dependencies can work in the following way:
1. Gateway-WAN down
1.1 Send notification about Gateway-WAN down
1.2 Stop polling Gateway-LAN
2. Gateway-WAN up
2.1 Send notification about Gateway-WAN up
2.2 Start polling Gateway-LAN
2.3 If Gateway-WAN is up - do not send notification about it
2.4 If Gateway-LAN is down re-probe it and when it goes up send up notification with total down-time started from p. 1.2 or p. 1.1.

An example when we get notification about Gateway-WAN only:

Ping to Gateway-WAN:
Mon 05/22/2017 20:35:16.31 Reply from 10.0.0.1: bytes=32 time=28ms TTL=55
Mon 05/22/2017 20:35:17.46 Reply from 10.0.0.1: bytes=32 time=14ms TTL=55
Mon 05/22/2017 20:35:22.10 Request timed out.
Mon 05/22/2017 20:35:31.20 Request timed out.
Mon 05/22/2017 20:35:40.06 Request timed out.
Mon 05/22/2017 20:35:49.17 Request timed out.
Mon 05/22/2017 20:35:50.20 Reply from 10.0.0.1: bytes=32 time=2ms TTL=55
Mon 05/22/2017 20:35:51.24 Reply from 10.0.0.1: bytes=32 time=2ms TTL=55

Ping to Gateway-LAN:
Mon 05/22/2017 20:35:16.29 Reply from 192.168.0.1: bytes=32 time=28ms TTL=62
Mon 05/22/2017 20:35:17.32 Reply from 192.168.0.1: bytes=32 time=13ms TTL=62
Mon 05/22/2017 20:35:22.09 Request timed out.
Mon 05/22/2017 20:35:31.21 Request timed out.
Mon 05/22/2017 20:35:40.06 Request timed out.
Mon 05/22/2017 20:35:49.17 Request timed out.
Mon 05/22/2017 20:35:50.20 Reply from 192.168.0.1: bytes=32 time=3ms TTL=62
Mon 05/22/2017 20:35:51.24 Reply from 192.168.0.1: bytes=32 time=3ms TTL=62

Notifications:
ping on Gateway-WAN is now down - May/22/2017 20:35:48 - 00:00:20
ping on Gateway-WAN is now up - May/22/2017 20:35:53 - 00:00:05

Notification template:
[Probe.Name] on [Device.Name] is now [Service.Status] - [TimeAndDate] - [Service.TimeSinceChanged]

Polling:
10/5/3 - on map level

An example when we get notification about Gateway-LAN only:

Ping to Gateway-WAN:
Mon 05/22/2017 22:24:14.35 Reply from 10.0.0.1: bytes=32 time=2ms TTL=55
Mon 05/22/2017 22:24:18.96 Reply from 10.0.0.1: bytes=32 time=26ms TTL=55
Mon 05/22/2017 22:24:27.96 Request timed out.
Mon 05/22/2017 22:24:36.99 Request timed out.
Mon 05/22/2017 22:24:41.97 Request timed out.
Mon 05/22/2017 22:24:44.46 Request timed out.
Mon 05/22/2017 22:24:45.50 Reply from 10.0.0.1: bytes=32 time=3ms TTL=55
Mon 05/22/2017 22:24:46.56 Reply from 10.0.0.1: bytes=32 time=3ms TTL=55

Ping to Gateway-LAN:
Mon 05/22/2017 22:24:14.50 Reply from 192.168.0.1: bytes=32 time=2ms TTL=62
Mon 05/22/2017 22:24:19.46 Reply from 192.168.0.1: bytes=32 time=26ms TTL=62
Mon 05/22/2017 22:24:28.46 Request timed out.
Mon 05/22/2017 22:24:37.46 Request timed out.
Mon 05/22/2017 22:24:42.47 Request timed out.
Mon 05/22/2017 22:24:44.46 Request timed out.
Mon 05/22/2017 22:24:45.49 Reply from 192.168.0.1: bytes=32 time=2ms TTL=62
Mon 05/22/2017 22:24:46.56 Reply from 192.168.0.1: bytes=32 time=4ms TTL=62

Notifications:
ping on Gateway-LAN is now down - May/22/2017 22:24:43 - 00:00:22
ping on Gateway-LAN is now up - May/22/2017 22:24:53 - 00:00:12

Notification template:
[Probe.Name] on [Device.Name] is now [Service.Status] - [TimeAndDate] - [Service.TimeSinceChanged]

Polling:
10/5/3 - on map level

An example when we get notification about Gateway-WAN and Gateway-LAN:

Ping to Gateway-WAN:
Tue 05/23/2017  7:43:13.04 Reply from 10.0.0.1: bytes=32 time=7ms TTL=57
Tue 05/23/2017  7:43:18.38 Reply from 10.0.0.1: bytes=32 time=3ms TTL=57
Tue 05/23/2017  7:43:28.38 Request timed out.
Tue 05/23/2017  7:43:38.38 Request timed out.
Tue 05/23/2017  7:43:48.38 Request timed out.
Tue 05/23/2017  7:43:58.38 Request timed out.
Tue 05/23/2017  7:44:08.38 Request timed out.
Tue 05/23/2017  7:44:18.38 Request timed out.
Tue 05/23/2017  7:44:28.38 Request timed out.
Tue 05/23/2017  7:44:38.38 Request timed out.
Tue 05/23/2017  7:44:48.38 Request timed out.
Tue 05/23/2017  7:44:58.38 Request timed out.
Tue 05/23/2017  7:45:08.38 Request timed out.
Tue 05/23/2017  7:45:18.38 Request timed out.
Tue 05/23/2017  7:45:28.38 Request timed out.
Tue 05/23/2017  7:45:38.38 Request timed out.
Tue 05/23/2017  7:45:48.38 Request timed out.
Tue 05/23/2017  7:45:58.38 Request timed out.
Tue 05/23/2017  7:45:59.40 Reply from 10.0.0.1: bytes=32 time=4ms TTL=57
Tue 05/23/2017  7:46:00.40 Reply from 10.0.0.1: bytes=32 time=4ms TTL=57

Ping to Gateway-LAN:
Tue 05/23/2017  7:43:12.47 Reply from 192.168.0.1: bytes=32 time=4ms TTL=63
Tue 05/23/2017  7:43:13.47 Reply from 192.168.0.1: bytes=32 time=4ms TTL=63
Tue 05/23/2017  7:43:18.88 Request timed out.
Tue 05/23/2017  7:43:28.88 Request timed out.
Tue 05/23/2017  7:43:38.88 Request timed out.
Tue 05/23/2017  7:43:48.88 Request timed out.
Tue 05/23/2017  7:43:58.88 Request timed out.
Tue 05/23/2017  7:44:08.88 Request timed out.
Tue 05/23/2017  7:44:18.88 Request timed out.
Tue 05/23/2017  7:44:28.88 Request timed out.
Tue 05/23/2017  7:44:38.88 Request timed out.
Tue 05/23/2017  7:44:48.88 Request timed out.
Tue 05/23/2017  7:44:58.88 Request timed out.
Tue 05/23/2017  7:45:08.88 Request timed out.
Tue 05/23/2017  7:45:18.88 Request timed out.
Tue 05/23/2017  7:45:28.88 Request timed out.
Tue 05/23/2017  7:45:38.88 Request timed out.
Tue 05/23/2017  7:45:48.88 Request timed out.
Tue 05/23/2017  7:45:58.88 Request timed out.
Tue 05/23/2017  7:46:08.88 Request timed out.
Tue 05/23/2017  7:46:18.88 Request timed out.
Tue 05/23/2017  7:46:28.88 Request timed out.
Tue 05/23/2017  7:46:38.88 Request timed out.
Tue 05/23/2017  7:46:48.89 Request timed out.
Tue 05/23/2017  7:46:58.89 Request timed out.
Tue 05/23/2017  7:46:59.90 Reply from 192.168.0.1: bytes=32 time=3ms TTL=63
Tue 05/23/2017  7:47:00.90 Reply from 192.168.0.1: bytes=32 time=2ms TTL=63

Notifications:
ping on Gateway-WAN is now down - May/23/2017 07:43:42 - 00:00:20
ping on Gateway-WAN is now up - May/23/2017 07:45:57 - 00:02:15
ping on Gateway-LAN is now up - May/23/2017 07:46:57 - 00:03:15

Notification template:
[Probe.Name] on [Device.Name] is now [Service.Status] - [TimeAndDate] - [Service.TimeSinceChanged]

Polling:
10/5/3 - on map level

Thank you!

eriitguy · Tue May 23, 2017 9:26 am

If above described logic is one used in current Dude v6, we can have some issue with it.

For example:
Gateway-WAN goes down
1. Send notification about Gateway-WAN down
2. Stop Gateway-LAN polling

Gateway-WAN goes up
1. Send notification about Gateway-WAN up
2. Start polling Gateway-LAN
3. Issue can start from here:
3.1 If Gateway-LAN is up when its polling was started, we will not receive notification, because it is already up.
3.2 If Gateway-LAN is down when its polling was started, we will not receive notification, until it is not up.
In such case, we don't know - Gateway-LAN is up or down after parent device goes up.

Maybe we should send a child status notification only if it is down after parent went to up? This can help to eliminate multiple up notification, if we have multiple devices which depends on parent. But we will get notification if some of the depended devices are down.

Thank you!

eriitguy · Tue Oct 24, 2017 11:01 am

Video with demonstration of the issue: https://www.youtube.com/watch?v=PyCB0rsLP_c

Ticket#2017052222001251

Reply from support:

Reply about the notificatios sent on ticket #2017052022000551

eriitguy · Thu Nov 02, 2017 10:10 am

Video with demonstration of the related issue: https://www.youtube.com/watch?v=ihuW-J-SV5M

Ticket#2017052022000551

Reply from support:

Seems like the issue happens with child device, in case when status changes from Unknown => Down. In this case notifications reports only status "Down" to "Up".

Steps to reproduce:

Devices:
Gateway-WAN: 8.8.8.8 - Asked
Gateway-LAN: 8.8.4.4

Dependencies:
Gateway-LAN depends on Gateway-WAN

Polling:
Probe Interval: 00:00:05
Probe Timeout: 00:00:03
Probe Down Count: 2

Scheduler:
Interval: 00:00:08
ip firewall filter enable numbers=0 
:delay 2s
ip firewall filter enable numbers=1
:delay 2s
ip firewall filter disable numbers=0
:delay 4s
ip firewall filter disable numbers=1
:delay 2s

Firewall rules:
/ip firewall filter
add action=drop chain=output comment=Gateway-WAN disabled=yes dst-address=8.8.8.8
add action=drop chain=output comment=Gateway-LAN dst-address=8.8.4.4

Thank you!

MasteRTriX · Sat Dec 15, 2018 4:40 am

I've struggling with the same issue, and still no way to work around it. Even tried to set more time and probe count to childs than parents, but still getting many false notifications.

MasteRTriX · Thu Feb 21, 2019 6:56 am

Still haven´t found a way to avoid false up notifications

j2sw · Mon Apr 29, 2019 9:09 am

I think I am experiencing the same issues. I get notifications when I really should not be getting them.

Dude v6 - Dependencies - How does it work?

Dude v6 - Dependencies - How does it work?

Re: Dude v6 - Dependencies - How does it work?

Re: Dude v6 - Dependencies - How does it work?

Re: Dude v6 - Dependencies - How does it work?

Re: Dude v6 - Dependencies - How does it work?

Re: Dude v6 - Dependencies - How does it work?

Re: Dude v6 - Dependencies - How does it work?

Who is online