Traceroute on a hop gives timeout

I was just looking into traceroute and trying to understand it's behaviour. Theoretically I get how IP routing and how traceroute work, but this case baffles me.

traceroute to google.com.ar (172.217.162.3), 64 hops max, 52 byte packets 1 192.168.0.1 (192.168.0.1) 1.935 ms 1.367 ms 1.271 ms 2 10.38.0.1 (10.38.0.1) 9.717 ms 11.107 ms 13.901 ms 3 10.242.3.165 (10.242.3.165) 10.858 ms 11.663 ms 10.366 ms 4 cpe-200-115-194-173.telecentro-reversos.com.ar (200.115.194.173) 12.070 ms 11.944 ms 11.704 ms 5 cpe-200-115-194-174.telecentro-reversos.com.ar (200.115.194.174) 11.402 ms 12.110 ms 11.167 ms 6 74.125.242.209 (74.125.242.209) 13.539 ms 13.080 ms 11.767 ms 7 216.239.58.217 (216.239.58.217) 10.603 ms 11.635 ms 10.811 ms 8 eze04s07-in-f3.1e100.net (172.217.162.3) 11.510 ms 11.575 ms 10.955 ms

There is a private IP there, 10.38.0.1, I tried to traceroute and/or ping it. If my router resolves that hop when resolving 172.217.162.3, it should resolve the hop itself as the destination

traceroute to 10.38.0.1 (10.38.0.1), 64 hops max, 52 byte packets
1 192.168.0.1 (192.168.0.1) 1.777 ms 1.481 ms 2.287 ms
2 * * *
3 * * *

Nothing

Lets try with traceroute -I as pointed here:

Why does traceroute fail?

traceroute to 10.38.0.1 (10.38.0.1), 64 hops max, 72 byte packets 1 192.168.0.1 (192.168.0.1) 1.686 ms 1.218 ms 1.145 ms 2 * * * 3 * * *

Neither...

Whats going on?

traceroute -v
Version 1.4a12+Darwin

Connection: LAN connected to WAN using broadband router Cisco DPC3925

1 Answer

There is a private IP there, 10.38.0.1, I tried to traceroute and/or ping it. If my router resolves that hop when resolving 172.217.162.3, it should resolve the hop itself as the destination

No. First of all, traceroute doesn't actually show what hop the previous router tried to resolve; it shows the address that this hop identifies itself with, which is not always the same address. (Note that the forwarded IP packets always have the original destination's IP address, not each hop's.)

Each hop identifies itself by sending an ICMP "TTL exceeded" error packet, and needs to pick an apropriate source address for it. It will have several addresses on different interfaces too choose from – including various Internet-facing interfaces, plus management networks – and might use various address selection algorithms, e.g. something simple such as "use the lowest address numerically".

In short, it can certainly be an address that the previous hop doesn't have any route for.

The second problem (even if there are complete routes towards that address) is that both ping and traceroute identify the final hop by a voluntarily sent response. The device might have ping (ICMP echo) replies simply turned off. Or it might have a firewall that discards your ping/traceroute probes without sending any reply. (The address you're trying to reach looks like something an ISP would use internally for a management network, so it's very likely that their firewall only accepts packets from the ISP's own NOC and nowhere else.)