Community discussions

MikroTik App
 
lukass741
just joined
Topic Author
Posts: 5
Joined: Fri Apr 22, 2022 6:19 pm

traceroute output

Thu May 12, 2022 6:59 pm

To figure out the source of my internet outages I added to my WAN failover script this line:
:execute {/tool traceroute 8.8.8.8 duration=7} file=Tracert
that is executed when there is no response to ping to 8.8.8.8.

However, its output contains only:
Columns: LOSS, SENT, LAST
#  LOSS  SENT  LAST
1  0%       1  0ms 

Columns: LOSS, SENT, LAST
#  LOSS  SENT  LAST   
1  100%     1  timeout
2  0%       1  0ms    
Is this a common output when it can't reach the first node after the router?
Does this therefore mean the connection issue is between my router and the first network element of the ISP?

Thanks
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11967
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: traceroute output

Thu May 12, 2022 7:08 pm

Is directly your router that do not have internet...
 
lukass741
just joined
Topic Author
Posts: 5
Joined: Fri Apr 22, 2022 6:19 pm

Re: traceroute output

Thu May 12, 2022 7:28 pm

Do you mean there is a connection issue between my router and the first network node or is there an issue in my mikrotik itself?
Any suggestions for the next trubleshooting steps? Note that 99% of the time my internet connection is stable. Only from time to time there is a short outage while tryceroute returns this.
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 11383
Joined: Thu Mar 03, 2016 10:23 pm

Re: traceroute output

Fri May 13, 2022 7:12 am

Traceroute depends on nodes correctly sending ICMP Time Expired packets for packets with TTL value reaching 0. If some node only drops such packets (as it should be done) but doesn't send the ICMP packet back (or if ICMP packets get lost), then you see the 100% packet loss for an intermediate hop. It doesn't mean that node is unreachable or that route has problems. And this is direct consequence of limiting ICMP traffic some admins overly do (sometimes can be seen also on this forum). The other possibility is that that node is busy and doesn't send the ICMP packet all the time ... or it sends it too late and host doing traceroute gives up waiting for it. In that case loss rate will be less than 100% but more than 0. Again nothing to worry most of times.
 
lukass741
just joined
Topic Author
Posts: 5
Joined: Fri Apr 22, 2022 6:19 pm

Re: traceroute output

Fri May 13, 2022 3:40 pm

my normal result of /tool traceroute 8.8.8.8 duration=7 is
Columns: ADDRESS, LOSS, SENT, LAST, AVG, BEST, WORST, STD-DEV
 #  ADDRESS          LOSS  SENT  LAST     AVG  BEST  WORST  STD-DEV
 1  10.11.5.146      0%       4  4.5ms    4.4  4.2   4.7    0.2    
 2                   100%     4  timeout                           
 3  10.80.255.1      0%       3  5.3ms    5.5  5     6.1    0.5    
 4                   100%     3  timeout                           
 5  94.142.232.17    0%       3  5ms      5.3  5     5.5    0.2    
 6  82.113.32.226    0%       3  6.1ms    5.8  5.3   6.1    0.4    
 7  72.14.220.118    0%       3  6.6ms    6.8  6.6   7.2    0.3    
 8  172.253.50.255   0%       3  4.7ms    4.9  4.7   5      0.1    
 9  142.251.224.129  0%       3  4.8ms    4.9  4.8   5      0.1    
10  8.8.8.8          0%       3  5.1ms    4.9  4.7   5.1    0.2  
but during periods when ping 8.8.8.8 doesn't receive any response then result of the traceroute is as above posted.

Do you have any suggestion for me to identify the source of the outage? According to my ISP's stats the connection is very stable. I don't know how to figure out whether the source of the outages is my mikrotik or some issue with the cable between my router and last ISP's node or last ISP's node itself.
 
tangent
Forum Guru
Forum Guru
Posts: 1333
Joined: Thu Jul 01, 2021 3:15 pm
Contact:

Re: traceroute output

Fri May 13, 2022 5:07 pm

It’s almost certainly not an “outage.” Try a traceroute from a PC (called “tracert” on Windows) and you’ll likely see “* * *” in the same spot, meaning the same thing, but clearer, IMO.
 
lukass741
just joined
Topic Author
Posts: 5
Joined: Fri Apr 22, 2022 6:19 pm

Re: traceroute output

Fri May 13, 2022 9:30 pm

It’s almost certainly not an “outage.” Try a traceroute from a PC (called “tracert” on Windows) and you’ll likely see “* * *” in the same spot, meaning the same thing, but clearer, IMO.
My failover script periodically sends 2 pings to 8.8.8.8 and 2 pings to 1.1.1.1. In case of no response from either it executes the traceroute command and switches to the backup WAN by increasing distance of the primary WAN route.
Hence currently I don't have an easy way to do tracert from windows connected to the router. Anyway I assume its output would be similar as mikrotik - it would reach the router but nothing behind it. Or not?

Anyway if zero response of 2 pings to 8.8.8.8 and 2 pings to 1.1.1.1 is not an outage then what is it? Having my ICMP communication temporarily blocked by ISP? I believe if that was the case then these no ping responses would be somewhat regular. But they are very irregular and last anywhere between a few seconds to many minutes.
 
tangent
Forum Guru
Forum Guru
Posts: 1333
Joined: Thu Jul 01, 2021 3:15 pm
Contact:

Re: traceroute output

Fri May 13, 2022 9:50 pm

I don't have an easy way to do tracert from windows connected to the router.

That wasn't my point. I want you to simply try it and see the difference in "traceroute output" in other implementations, per your thread's title.

I assume its output would be similar as mikrotik - it would reach the router but nothing behind it. Or not?

Why assume, and why ask me? Try it and find out.

if zero response of 2 pings to 8.8.8.8 and 2 pings to 1.1.1.1 is not an outage then what is it?

Not my point. I'm saying that traceroute often fails at TTL=2 and sometimes at TTL=3 because ISP border gateways often don't respond to ICMP echo requests. Your own results a few steps down from the top post show this at TTL=2 and TTL=4. This is common, and it means your failure-case results aren't diagnostic relative to ping: a failure at TTL=2 is normal even when the link is up.

If you wait for the traceroute to time out by hitting its TTL limit, and you get no result beyond your local router, then it isn't telling you anything a ping doesn't.

I'm not telling you you have no ISP outages, but your traceroute results aren't giving you much here relative to your ping failures. About all it tells you is that the whole link goes down, at the border.
 
lukass741
just joined
Topic Author
Posts: 5
Joined: Fri Apr 22, 2022 6:19 pm

Re: traceroute output

Fri May 13, 2022 11:41 pm

Thanks for this insight.
Since traceroute when the link is up reaches the first done 10.11.5.146 but during outage it doesn't, it means the connection issue is anywhere between my router and the first node, right?
 
tangent
Forum Guru
Forum Guru
Posts: 1333
Joined: Thu Jul 01, 2021 3:15 pm
Contact:

Re: traceroute output

Sat May 14, 2022 12:00 am

It’s difficult to say, which is why I said the results aren’t diagnostic. If it stopped, say, 5 steps in, that would be interesting.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: traceroute output

Sat May 14, 2022 6:01 pm

Since traceroute when the link is up reaches the first done 10.11.5.146 but during outage it doesn't, it means the connection issue is anywhere between my router and the first node, right?
Correct. The question is what goes wrong - the physical link may be down, the address assignment may time out and not be renewed in time - e.g., some DHCP servers do not respond renewal attempts so the lease has to expire so that the client would be able to get a new one, which causes an outage, or something may go wrong with your Mikrotik's routing table so the traffic takes another route during the outage.

Some of the possible causes are configuration related, so an export of configuration should allow to narrow the search and to suggest additional investigation/monitoring methods.

Who is online

Users browsing this forum: aoravent, Bing [Bot], stevencameron16 and 91 guests