Is it normal for an ISP to have the same IP twice in a route?

Question

If I traceroute out of my home network, I see the same IP twice in a row directly after my router:

  1     1 ms     1 ms     1 ms  router
  2    17 ms    16 ms    16 ms  217.0.117.61
  3    16 ms    16 ms    16 ms  217.0.117.61
  4    17 ms    17 ms    17 ms  87.186.233.102
  5    26 ms    24 ms    24 ms  217.239.39.2
  6    24 ms    24 ms    25 ms  ...

Is this normal, or could it be a mis-configuration on behalf of the ISP?

Answer 1

If this happens once or rarely

All IP packets have a time-to-live (TTL) field. This field is decremented by one by every router that forwards a packet. If a router decrements the TTL to 0, it drops the packet and generates an ICMP TTL exceeded error packet and sends it back to the originator.

Traceroute uses this feature to send packets with sequentially increasing TTLs. This allows traceroute to build a picture of the path between source and destination.

In your case, there were probably two paths possible from your router to 217.0.117.61, where one was longer than the other. So what happened was:

1. The packet sent with TTL=1 reached your router, which answered.
2. The packet sent with TTL=2
   • reached your router, which decremented the TTL to 1 and sent it on,
   • then reached 217.0.117.61, which answered.
3. The packet sent with TTL=3
   • reached your router, which decremented the TTL to 2 and sent it on,
   • then reached some unknown router, which decremented the TTL to 1 and sent it on,
   • then reached 217.0.117.61, which answered.

So that is why you have the same entry twice. It could have been worse, with every IP listed twice, but apparently the router to give the first 217.0.117.61 answer never participated again in the trace, so all the following packets passed through the unknown router whose IP was never returned.

If this always happens

Then it is because of the way that your ISP has set up its network. The IPs in your list belong to Deutsche Telekom AG which has an enormous internal network with high-performance sophisticated nodes, of whom one seems to answer twice.

There are a couple of possible explanations :

• The ISP has a firewall that answers traceroute requests. A corporate firewall is a specialized computer in its own right. It may answer tracroute requests, if programmed to, with the programmed IP address, which may be that of the node it is protecting.

• A corporate router may answer from both its inner and outer interfaces. Such a high-speed and high-throughput router is actually a network-in-a-box with specialized sub-routers as components. The answers may come from both the forward- and backward-facing sub-routers, answering with the same IP.

Answer 2

Since it's happening consistently, I think the most likely cause is a bug in one of the routers' firmware causing it to either fail to drop the trace packet (and send a "TTL exceeded" report) when it should, or sending it before it should. Here's an example of the first problem from the BSD traceroute man page:

A sample use and output might be:

 [yak 71]% traceroute nis.nsf.net.
 traceroute to nis.nsf.net (35.1.1.48), 30 hops max, 56 byte packet
 1 helios.ee.lbl.gov (128.3.112.1)  19 ms 19 ms  0 ms
 2 lilac-dmc.Berkeley.EDU (128.32.216.1)  39 ms  39 ms  19 ms
 3 lilac-dmc.Berkeley.EDU (128.32.216.1)  39 ms  39 ms  19 ms
 4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23)  39 ms  40 ms  39 ms
 [...]

Note that lines 2 & 3 are the same.  This is due to a buggy kernel on the
2nd hop system - lbl-csam.arpa - that forwards packets with a zero ttl (a
bug in the distributed version of 4.3 BSD).

In this example it's the second router that has the bug, and the third router winds up being listed as both #2 and #3.

On the other hand, consider what'd happen if the second router had a bug that made it drop packets when the TTL reached 1 instead of 0:

1. The trace packet sent with TTL=1 gets decremented to 0 at the first router, which drops it and reports TTL exceeded, and so it shows up as hop #1. All good here.
2. The packet sent with TTL=2 gets decremented to 1 at the first router; then the second router decrements it to 0, and drops and reports it, and so it shows up as hop #2. Again, all good here.
3. The packet sent with TTL=3 gets decremented to 2 at the first router; then the second router decrements it to 1, and erroneously drops and reports it, and so it shows up as hop #3.

Again it's the second router that has a bug, but in this case it's the second router that's listed twice (in the example in the man page it's the third that's listed twice).