help understanding this tracert output

[bwanaaa]

2 1 ms <1 ms <1 ms 192.168.1.1
3 5 ms 7 ms 8 ms L100.BSTNMA-VFTTP-131.verizon-gni.net [173.76.3.1]
4 11 ms 12 ms 11 ms G0-6-1-1.BSTNMA-LCR-21.verizon-gni.net [130.81.217.202]
5 * * * Request timed out.
6 * * * Request timed out.
7 16 ms 16 ms 15 ms 0.ae3.BR2.NYC4.ALTER.NET [140.222.231.133]
8 26 ms 24 ms 25 ms 204.255.168.110
9 24 ms 24 ms 24 ms be2061.ccr42.jfk02.atlas.cogentco.com [154.54.3.69]
10 100 ms 98 ms 98 ms be2490.ccr42.lon13.atlas.cogentco.com [154.54.42.86]
11 100 ms 103 ms 102 ms be12488.ccr42.ams03.atlas.cogentco.com [130.117.51.42]
12 109 ms 106 ms 106 ms be2440.agr21.ams03.atlas.cogentco.com [130.117.50.6]
13 107 ms 107 ms 110 ms be2114.rcr21.dus01.atlas.cogentco.com [130.117.48.62]
14 113 ms 110 ms 110 ms be2567.nr11.b015770-1.dus01.atlas.cogentco.com [154.25.6.182]
15 118 ms 104 ms 118 ms 149.6.138.122
16 111 ms 109 ms 112 ms 89.163.234.93

hops 5 and 6 timed out. Since I can see hops before and after hops 5 and 6, what does that mean? I am connecting to the destination. Are hops 5 and 6 slow? Wouldnt that show up as a much bigger number to hop 7?

How do I find out which hops those were? Can I configure a route that avoids those hops?

 

[JackMDS]

Try another DNS.

https://www.grc.com/dns/benchmark.htm

 

[bwanaaa]

that is a great tool and it found the following anomalies:

ALL the following are marked in red as 'not responding to DNS queries'
89.163.234.93 ··· no official Internet DNS name ···
130.81.217.202 G0-6-1-1.BSTNMA-LCR-21.verizon-gni.net
130.117.48.62 be2114.rcr21.dus01.atlas.cogentco.com
130.117.50.6 be2440.agr21.ams03.atlas.cogentco.com
130.117.51.42 be12488.ccr42.ams03.atlas.cogentco.com
140.222.231.133 0.ae3.BR2.NYC4.ALTER.NET
149.6.138.122 ··· no official Internet DNS name ···
154.25.6.182 be2567.nr11.b015770-1.dus01.atlas.cogentco.com
154.54.3.69 be2061.ccr42.jfk02.atlas.cogentco.com
154.54.42.86 be2490.ccr42.lon13.atlas.cogentco.com
204.255.168.110 ··· no official Internet DNS name ···

If they identify themselves, how can they not be responding to DNS queries?

And the two hops that failed preceded the only unidentified hop with an unknown owner
149.6.138.122 ··· no official Internet DNS name ···

All of the 'non responsive hops' are owned by MCI (Verizon) or Cogent communications. They are marked in red as not responding to DNS queries but tracert identified them fine. So the tool is five years old. I guess since then some companies have set their DNS servers not to respond to ICMP? (How else could a DNS router work but not identify itself?)

 

[Fardringle]

It just means that device doesn't respond to queries of that type. Probably because the function of the device doesn't require it in any way, and it would add to the load on the device without serving any useful purpose.

 

[Gryz]

hops 5 and 6 timed out. Since I can see hops before and after hops 5 and 6, what does that mean?

Read up on the Internet how traceroute works.
Basically you send probe packets with different TTLs (Time To Lives). Starting with TTL=1, then TTL=2, etc. Traceroute sends 3 probes for each value of TTL. When packet gets forwarded, the router will decrement the TTL. If a TTL reaches 0, the router will drop your packet. But it will send a warning/error message. This is an ICMP Unreachable packet.

Some admins configure their routers to never send any ICMP Unreachables (or not even any other ICMP packets). This is stupid. It serves no purpose. Yet, they still do it. Probably because they think it will improve their security. But it doesn't.

So when you see those stars (*) it means that either:
1) your probe packet got dropped somewhere because of congestion before it reached TTL=0.
2) the ICMP reply got dropped somewhere on the way back to you
3) the router where TTL=0 refuses to send an ICMP

It has nothing to do with DNS.
The traceroute program will try to resolve all the IP-address it would print into DNS-hostnames. When traceroute doesn't get any DNS-replies (or no name exists for the address, or the queries time out) it simply prints the IP-address. It won't print that star. As I said, that star means traceroute never got an ICMP Unreachable.

I am connecting to the destination. Are hops 5 and 6 slow? Wouldnt that show up as a much bigger number to hop 7?

No, they are not slow.
Yes, if there is a large delay between two hops, the number will/should increase.

9 24 ms 24 ms 24 ms be2061.ccr42.jfk02.atlas.cogentco.com [154.54.3.69]
10 100 ms 98 ms 98 ms be2490.ccr42.lon13.atlas.cogentco.com [154.54.42.86]

The delay on the path between you and the destination is between hops 9 and 10. Most likely the link between be2061.ccr42.jfk02.atlas.cogentco.com and be2490.ccr42.lon13.atlas.cogentco.com is congested. Or maybe it is truly a long link (across a continent, or under an ocean). 100 ms is roughly equal to 18000 km. As ping (aka RTT, RoundTripTimes) as measured both ways, that means that link should be ~9000km long. That's not likely (unless you are indeed on another continent than the destination). So it must be congestion.

Try again on different times in the day. E.g. after midnight. Does the RTT go down ? Is the big increase in RTT between hop 9 and 10 gone ? That is an indication that your problem is because of congestion.

How do I find out which hops those were? Can I configure a route that avoids those hops?

It's between hops 9 and 10. You see that because of the sudden increase in RTT.

No, there is nothing you can do. It's a link internal to the Cogent network. Your ISP determines how your traffic is routed through the Internet. (And its mostly based on what is the cheapest path. Money wise). You could call your ISP, and ask them to route to the destination via another ISP than Cogent. There is a very tiny change they might do that. But 100ms extra delay is probably not enough. And one customer complaining is probably not enough.

The only thing you could do that might help is actually switch ISPs. But there's no way to know beforehand if the path that the new ISP takes will be better. The new ISP might be using Cogent too. I know you don't want to hear this, but in reality there is very little you can do to improve your ping to that destination.

 

[bwanaaa]

thank you for an informative and helpful reply. There should be a way to transfer points to your stackoverflow account.

 

[Gryz]

Don't worry about that. I don't need stackoverflow points. I'm already happy when people who asks questions acknowledge that they have read the answers. That is enough appreciation in itself.

 

[Fallen Kell]

Read up on the Internet how traceroute works.
Basically you send probe packets with different TTLs (Time To Lives). Starting with TTL=1, then TTL=2, etc. Traceroute sends 3 probes for each value of TTL. When packet gets forwarded, the router will decrement the TTL. If a TTL reaches 0, the router will drop your packet. But it will send a warning/error message. This is an ICMP Unreachable packet.

Some admins configure their routers to never send any ICMP Unreachables (or not even any other ICMP packets). This is stupid. It serves no purpose. Yet, they still do it. Probably because they think it will improve their security. But it doesn't.

They do it because it is spelled out by the US government as a requirement for security:

https://www.stigviewer.com/stig/fir...e/2014-07-07/finding/SRG-NET-000273-FW-000152

 

[Gryz]

They do it because it is spelled out by the US government as a requirement for security:

https://www.stigviewer.com/stig/fir...e/2014-07-07/finding/SRG-NET-000273-FW-000152

Thanks for the link.
Very interesting to see such a general recommendation.

And I still think that that rule is stupid.
I don't think you gain much by disabling ICMP altogether.
They do mention Path-MTU-Discovery as a potential problem.

Also note that that Stig document is about firewalls. Normally firewalls protect a leaf-network. But in this case, we are not even talking about a leaf-network. The 2 routers that don't send ICMP Unreachables are between Verizon and Alternet (which used to be UUNet, which got bought by Verizon too). This is a transit-network. These are transit-routers. Not firewalls. So they don't have any business dropping ICMP packets at all. I still think it's stupid.

 

[Fallen Kell]

Actually that STIG document is firewall rules for all systems (routers, switches, servers, client systems). If it is on the network and can have a firewall installed, those rules apply. But, you are correct, it doesn't really make sense in this case. The original purpose of the STIGs are for security setup/hardening of systems that connect to government networks, but most of the rules have been published to the general public to aid in general security configuration steps as well. As a result, many companies have used them as a basis for their general configuration standard (either in part or in whole).