Hi all. First of all I wish you all a 2021 health and prosperous!

I am in an issue and not being able to find out what am I doing wrong. I follow step by step the follwing link: https://mum.mikrotik.com/presentations/ ... 743837.pdf to keep my home Mikrotik running with both ISP providers I have (VIVO and TIM).

It was working fine until I lost connectivity through TIM due to a fiber rupture on street and since them interface show as down at Netwatch. Some wirdeness:
From my PC, I can trace through right path:
Tracing route to 8.8.8.8 over a maximum of 30 hops

1 2 ms 1 ms 1 ms 192.168.88.1
2 2 ms 2 ms 2 ms 192.168.15.1
3 6 ms 4 ms 5 ms 189.59.241.110
4 6 ms 6 ms 7 ms 201.22.71.221
5 7 ms 6 ms 11 ms 152.255.139.33
6 6 ms 6 ms 7 ms 72.14.218.101
7 6 ms 7 ms 14 ms 108.170.251.65
8 5 ms 5 ms 5 ms 108.170.228.5
9 6 ms 5 ms 5 ms 8.8.8.8

Trace complete.

C:\Users\xxxxx>tracert -d 8.8.4.4

Tracing route to 8.8.4.4 over a maximum of 30 hops

1 55 ms 69 ms 1 ms 192.168.88.1
2 2 ms 1 ms 2 ms 192.168.1.1
3 6 ms 8 ms 6 ms 186.230.220.96
4 8 ms 9 ms 9 ms 10.221.252.48
5 25 ms 40 ms 24 ms 10.223.238.246
6 7 ms 6 ms 7 ms 72.14.197.37
7 8 ms 7 ms 8 ms 108.170.251.65
8 6 ms 6 ms 6 ms 108.170.229.185
9 9 ms 13 ms 6 ms 8.8.4.4

Trace complete.

Same with ping:
Pinging 8.8.8.8 with 32 bytes of data:
Reply from 8.8.8.8: bytes=32 time=5ms TTL=118
Reply from 8.8.8.8: bytes=32 time=6ms TTL=118
Reply from 8.8.8.8: bytes=32 time=6ms TTL=118
Reply from 8.8.8.8: bytes=32 time=7ms TTL=118

Ping statistics for 8.8.8.8:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 5ms, Maximum = 7ms, Average = 6ms

C:\Users\xxxxx>ping 8.8.4.4

Pinging 8.8.4.4 with 32 bytes of data:
Reply from 8.8.4.4: bytes=32 time=7ms TTL=118
Reply from 8.8.4.4: bytes=32 time=7ms TTL=118
Reply from 8.8.4.4: bytes=32 time=7ms TTL=118
Reply from 8.8.4.4: bytes=32 time=7ms TTL=118

Ping statistics for 8.8.4.4:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 7ms, Maximum = 7ms, Average = 7ms

However, from Mikrotik itself ping does not works:
[xxxxx@MikroTik] /tool> traceroute 8.8.4.4
# ADDRESS LOSS SENT LAST AVG BEST WORST STD-DEV STATUS
1 192.168.1.1 0% 3 0.4ms 0.4 0.4 0.4 0
2 186.230.220.96 0% 3 4.6ms 5 4.6 5.8 0.5
3 10.221.252.48 0% 3 4.8ms 6.5 4.8 7.5 1.2
4 10.223.238.246 0% 3 10.2ms 7.3 4.8 10.2 2.2
5 72.14.197.37 0% 3 5ms 5.1 4.5 5.7 0.5
6 108.170.251.65 0% 3 4.1ms 4.5 4.1 4.9 0.3
7 108.170.229.185 0% 3 4.9ms 4.7 4.4 4.9 0.2
8 8.8.4.4 0% 3 4.8ms 4.8 4.8 4.8 0

[xxxxx@MikroTik] /tool> ..
[xxxxx@MikroTik] > ping 8.8.4.4
SEQ HOST SIZE TTL TIME STATUS
0 8.8.4.4 timeout
1 8.8.4.4 timeout
2 8.8.4.4 timeout
sent=3 received=0 packet-loss=100%

Therefore keeping at netwatch interface down. I am adding the config and Netwatch screen at this thread. Any tip is very welcome!

What is especially weird is that traceroute to 8.8.4.4. works via the correct gateway but ping doesn't.

As you have configured everything manually, I'd recommend you to issue /interface detect-internet set detect-interface-list=none and see whether it helps. So far the detect internet feature has been responsible for several mysteries.

Si Sindy. Thanks for your quick reply. Same Behaviour. Please find below command:
[xxxx@MikroTik] > /interface detect-internet set detect-interface-list=none
[xxxx@MikroTik] > ping 8.8.4.4
SEQ HOST SIZE TTL TIME STATUS
0 8.8.4.4 timeout
1 8.8.4.4 timeout
sent=2 received=0 packet-loss=100%
[xxxx@MikroTik] /tool> traceroute 8.8.4.4
# ADDRESS LOSS SENT LAST AVG BEST WORST STD-DEV STATUS
1 192.168.1.1 0% 2 0.4ms 0.5 0.4 0.5 0.1
2 186.230.220.96 0% 2 4.7ms 5.4 4.7 6.1 0.7
3 10.221.252.48 0% 2 4.8ms 5.2 4.8 5.6 0.4
4 10.223.238.246 0% 2 6.7ms 6.4 6 6.7 0.4
5 72.14.197.37 0% 2 4.4ms 4.5 4.4 4.6 0.1
6 108.170.251.65 0% 2 5.2ms 5.5 5.2 5.8 0.3
7 108.170.229.185 0% 2 4.8ms 4.8 4.8 4.8 0
8 8.8.4.4 0% 2 4.8ms 4.9 4.8 4.9 0.1

First, what is the output of /ip firewall connection print detail where protocol=icmp dst-address~"8.8.4.4" ?

Second, can you check that the packets are actually leaving when you ping, and through which interface?
/tool sniffer quick ip-protocol=icmp ip-address=8.8.4.4

Third, what does /ip route print detail show?

Hi Sindy, I was not able to get the first command running. However, please find below the other two commands:

[xxxx@MikroTik] /tool sniffer> quick ip-protocol=icmp ip-address=8.8.4.4
INTERFACE TIME NUM DI SRC-MAC DST-MAC VLAN SRC-ADDRESS
TIM 2.133 1 -> C4:AD:34:12:1B:D4 80:20:DA:62:F8:49 192.168.1.254
TIM 3.138 2 -> C4:AD:34:12:1B:D4 80:20:DA:62:F8:49 192.168.1.254
TIM 4.14 3 -> C4:AD:34:12:1B:D4 80:20:DA:62:F8:49 192.168.1.254
TIM 12.14 4 -> C4:AD:34:12:1B:D4 80:20:DA:62:F8:49 192.168.1.254
TIM 13.146 5 -> C4:AD:34:12:1B:D4 80:20:DA:62:F8:49 192.168.1.254
TIM 14.148 6 -> C4:AD:34:12:1B:D4 80:20:DA:62:F8:49 192.168.1.254

[xxxx@MikroTik] > ip route print detail
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme,
B - blackhole, U - unreachable, P - prohibit
0 A S dst-address=0.0.0.0/0 gateway=192.168.15.1 gateway-status=192.168.15.1 reachable via VIVO
check-gateway=ping distance=1 scope=255 target-scope=10 routing-mark=to_VIVO

1 A S dst-address=0.0.0.0/0 gateway=192.168.1.1 gateway-status=192.168.1.1 reachable via TIM check-gateway=ping
distance=1 scope=255 target-scope=10 routing-mark=to_TIM

2 A S ;;; VIVO
dst-address=0.0.0.0/0 gateway=192.168.15.1 gateway-status=192.168.15.1 reachable via VIVO
check-gateway=ping distance=1 scope=30 target-scope=10

3 S dst-address=0.0.0.0/0 gateway=192.168.1.1 gateway-status=192.168.1.1 reachable via TIM check-gateway=ping
distance=2 scope=30 target-scope=10

4 X S ;;; TIM
dst-address=0.0.0.0/0 gateway=192.168.1.1 gateway-status=192.168.1.1 inactive check-gateway=ping
distance=2 scope=30 target-scope=10

5 A S ;;; Netwatch TIM
dst-address=8.8.4.4/32 gateway=192.168.1.1 gateway-status=192.168.1.1 reachable via TIM
check-gateway=ping distance=1 scope=30 target-scope=10

6 A S ;;; Netwatch VIVO
dst-address=8.8.8.8/32 gateway=192.168.15.1 gateway-status=192.168.15.1 reachable via VIVO

I was not able to get the first command running.

Interesting, have you copy-pasted it from here, without the question mark in the end? I did it and it works, so no typo in what I've posted.

Code: Select all

[xxxx@MikroTik] /tool sniffer> quick ip-protocol=icmp ip-address=8.8.4.4
INTERFACE              TIME    NUM DI SRC-MAC           DST-MAC           VLAN   SRC-ADDRESS                        
TIM                   2.133      1 -> C4:AD:34:12:1B:D4 80:20:DA:62:F8:49        192.168.1.254                      
TIM                   3.138      2 -> C4:AD:34:12:1B:D4 80:20:DA:62:F8:49        192.168.1.254                      
TIM                    4.14      3 -> C4:AD:34:12:1B:D4 80:20:DA:62:F8:49        192.168.1.254                      
TIM                   12.14      4 -> C4:AD:34:12:1B:D4 80:20:DA:62:F8:49        192.168.1.254                      
TIM                  13.146      5 -> C4:AD:34:12:1B:D4 80:20:DA:62:F8:49        192.168.1.254                      
TIM                  14.148      6 -> C4:AD:34:12:1B:D4 80:20:DA:62:F8:49        192.168.1.254 

This is the least expected output to me, as the packets are being sent from the correct WAN but no responses can be seen.

So please make the text window where you run the /tool sniffer quick as wide as your screen allows, run it again, run the /tool traceroute 8.8.4.4 in another window, and post the result from the sniffer here.

Hi Sandy. My Bad, I did not copied from your instructions. I tried to go through command myself. Sorry. Please find output as your last request:

[xxxx@MikroTik] /tool sniffer> quick ip-protocol=icmp ip-address=8.8.4.4
INTERFACE TIME NUM DI SRC-MAC DST-MAC VLAN SRC-ADDRESS
TIM 19.821 23 -> C4:AD:34:12:1B:D4 80:20:DA:62:F8:49 192.168.1.254
TIM 19.822 24 -> C4:AD:34:12:1B:D4 80:20:DA:62:F8:49 192.168.1.254
TIM 19.83 25 -> C4:AD:34:12:1B:D4 80:20:DA:62:F8:49 192.168.1.254
TIM 19.836 26 -> C4:AD:34:12:1B:D4 80:20:DA:62:F8:49 192.168.1.254
TIM 19.842 27 -> C4:AD:34:12:1B:D4 80:20:DA:62:F8:49 192.168.1.254
TIM 19.847 28 -> C4:AD:34:12:1B:D4 80:20:DA:62:F8:49 192.168.1.254
TIM 19.852 29 -> C4:AD:34:12:1B:D4 80:20:DA:62:F8:49 192.168.1.254
TIM 19.857 30 -> C4:AD:34:12:1B:D4 80:20:DA:62:F8:49 192.168.1.254
TIM 19.862 31 <- 80:20:DA:62:F8:49 C4:AD:34:12:1B:D4 8.8.4.4
TIM 20.813 32 -> C4:AD:34:12:1B:D4 80:20:DA:62:F8:49 192.168.1.254
TIM 20.813 33 -> C4:AD:34:12:1B:D4 80:20:DA:62:F8:49 192.168.1.254
TIM 20.818 34 -> C4:AD:34:12:1B:D4 80:20:DA:62:F8:49 192.168.1.254
TIM 20.826 35 -> C4:AD:34:12:1B:D4 80:20:DA:62:F8:49 192.168.1.254
TIM 20.835 36 -> C4:AD:34:12:1B:D4 80:20:DA:62:F8:49 192.168.1.254
TIM 20.84 37 -> C4:AD:34:12:1B:D4 80:20:DA:62:F8:49 192.168.1.254
TIM 20.845 38 -> C4:AD:34:12:1B:D4 80:20:DA:62:F8:49 192.168.1.254
TIM 20.85 39 -> C4:AD:34:12:1B:D4 80:20:DA:62:F8:49 192.168.1.254
TIM 20.855 40 <- 80:20:DA:62:F8:49 C4:AD:34:12:1B:D4 8.8.4.4
TIM 22.663 41 -> C4:AD:34:12:1B:D4 80:20:DA:62:F8:49 192.168.1.254
TIM 22.667 42 <- 80:20:DA:62:F8:49 C4:AD:34:12:1B:D4 8.8.4.4

[xxxx@MikroTik] /tool sniffer> ..
[xxxx@MikroTik] /tool> ..
[xxxx@MikroTik] > /ip firewall connection print detail where protocol=icmp dst-address~"8.8.4.4"
Flags: E - expected, S - seen-reply, A - assured, C - confirmed, D - dying, F - fasttrack, s - srcnat, d - dstnat
0 S C protocol=icmp src-address=192.168.1.254 dst-address=8.8.4.4 reply-src-address=8.8.4.4
reply-dst-address=192.168.1.254 icmp-type=8 icmp-code=0 icmp-id=61212 timeout=7s
connection-mark="TIM_conn" orig-packets=1 orig-bytes=56 orig-fasttrack-packets=0
orig-fasttrack-bytes=0 repl-packets=1 repl-bytes=56 repl-fasttrack-packets=0 repl-fasttrack-bytes=0
orig-rate=0bps repl-rate=0bps

Hi Sandy.

Not sure if that Firewall command allowed traffic (kind of newbie here). But it is working fine now! :|

[xxxx@MikroTik] > ping 8.8.8.8
SEQ HOST SIZE TTL TIME STATUS
0 8.8.8.8 56 119 3ms
1 8.8.8.8 56 119 3ms
sent=2 received=2 packet-loss=0% min-rtt=3ms avg-rtt=3ms max-rtt=3ms

[xxxx@MikroTik] > ping 8.8.4.4
SEQ HOST SIZE TTL TIME STATUS
0 8.8.4.4 56 119 5ms
1 8.8.4.4 56 119 5ms
2 8.8.4.4 56 119 5ms
sent=3 received=3 packet-loss=0% min-rtt=5ms avg-rtt=5ms max-rtt=5ms

Thank you a lot for your assistance!

Nope, the /ip firewall connection print command only shows tracked connections, it doesn't change anything.

So the mystery remains unresolved.

Actually you are right as the system become up since yesterday night: Jan/11/2021 21:14:40 (GMT-3)

Hi Sindy. Down again since yesterday night. From my PC I can ping and trace for 8.8.4.4 and from Mikrotik I cannot! :(

It looks to me as an external problem, and the only idea I have so far is that it is related to the ISP doing something about the TTL. But to be sure, I'd do the following in one command line window:

/tool sniffer set file-name=icmp-test.pcap
/tool sniffer quick interface=TIM ip-protocol=icmp

Then let it just run like that for slightly more than 30 seconds, this should show three pings generated by netwatch.
Next, run /ping 8.8.4.4 count=3 in another window.
After that finishes, run /tool traceroute 8.8.4.4 in that other window, until it gets the response from the 8.8.4.4.

Finally, break the /tool sniffer quick command, download the file, and use Wireshark to open it (or attach it to the post if simpler, there will be the public addresses of the ISP's routers but not your own one, and there will be your router's MAC address).

I'd like to see whether there is any other difference than the TTL value between the ICMP echo request packets sent as "manual" pings, "netwatch" pings, and the ones generated by traceroute.

The very principle of traceroute is to send test packets with low TTL starting from 1 and increasing in each new packet, so that the routers on the path to the destination send back a "TTL exceeded" (actually, it should probably read "expired") message and thus identify themselves. Since these test packets do reach 8.8.4.4., it means the path works. Hence I assume that the first router in the path (the ISP's one to which your Tik is conected) doesn't like packets with TTL 255 for some reason, but why it does so only soometimes and whether it is truly so needs to be investigated.

Right now they are both UP, I will wait until next event UP/DOWN and will revert, ok?

Sure, no point in investigating an issue which is not there.