traceroute output

RouterOS General
1

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

2

Is directly your router that do not have internet…

3

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.

4

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.

5

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.

6

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.

7

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.

8

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.

9

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?

10

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.

11

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.