ISPがルートで同じIPを2回使用するのは正常ですか？

ホームネットワークからtracerouteを実行すると、ルーターの直後に同じIPが2回続けて表示されます。

  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  ...

これは正常ですか、それともISPに代わって設定が誤っている可能性がありますか？

これが一度またはまれに起こる場合

すべてのIPパケットには、存続時間（TTL）フィールドがあります。このフィールドは、パケットを転送するルーターごとに1つずつ減少します。ルータがTTLを0にデクリメントする場合、パケットをドロップし、ICMP TTL超過エラーパケットを生成して、それを発信者に送り返します。

Tracerouteはこの機能を使用して、TTLが順次増加するパケットを送信します。これにより、tracerouteで送信元と宛先の間のパスの図を作成できます。

あなたのケースでは、おそらくルータから217.0.117.61へのパスが2つあり、一方が他方よりも長い可能性があります。だから何が起こったのか：

1. TTL = 1で送信されたパケットがルーターに到達し、ルーターが応答しました。
2. TTL = 2で送信されたパケット
   • ルーターに到達し、TTLを1に減らして送信しました。
   • その後217.0.117.61に達し、回答しました。
3. TTL = 3で送信されたパケット
   • ルーターに到達し、TTLを2に減らして送信しました。
   • 次に、不明なルーターに到達し、TTLを1に減らして送信しました。
   • その後217.0.117.61に達し、回答しました。

そのため、同じエントリが2回あります。すべての IPが2回リストされている場合はさらに悪くなる可能性がありますが、最初の217.0.117.61の回答を返すルーターはトレースに再び参加しなかったため、後続のすべてのパケットは、IPが返されなかった不明なルーターを通過しました。

これが常に発生する場合

それは、ISPがネットワークをセットアップした方法が原因です。リストにあるIPは、高性能の洗練されたノードを持つ巨大な内部ネットワークを持つDeutsche Telekom AGに属しています。

考えられる説明がいくつかあります。

• ISPには、traceroute要求に応答するファイアウォールがあります。企業のファイアウォールは、それ自体が特殊なコンピュータです。プログラムされている場合は、保護されているノードのIPアドレスである可能性がある、プログラムされたIPアドレスでtracroute要求に応答する場合があります。

• 企業のルーターは、その内部インターフェイスと外部インターフェイスの両方から応答できます。このような高速かつ高スループットのルーターは、実際には、コンポーネントとして特殊なサブルーターを備えたネットワークインボックスです。回答は、前向きと後ろ向きの両方のサブルーターから送信され、同じIPで応答します。

それは一貫して起こっているので、最も可能性の高い原因は、ルーターのファームウェアの1つにバグがあり、トレースパケットのドロップに失敗する（および「TTL超過」レポートを送信する）必要がある場合、またはその前に送信することのどちらかです。すべきです。次に、BSD tracerouteのマニュアルページの最初の問題の例を示します。

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).

この例では、バグが発生しているのは2番目のルーターであり、3番目のルーターは＃2と＃3の両方として表示されます。

一方、TTLが0ではなく1に達したときに2番目のルーターにパケットをドロップさせるバグがあった場合はどうなるかを考えます。

1. TTL = 1で送信されたトレースパケットは最初のルーターで0にデクリメントされ、ドロップしてTTL超過を報告するため、ホップ＃1として表示されます。ここですべて良い。
2. TTL = 2で送信されたパケットは、最初のルーターで1にデクリメントされます。次に、2番目のルーターはそれを0にデクリメントし、ドロップして報告するため、ホップ＃2として表示されます。繰り返しになりますが、ここですべてが良好です。
3. TTL = 3で送信されたパケットは、最初のルーターで2に減少します。次に、2番目のルーターはそれを1にデクリメントし、誤ってドロップして報告するため、ホップ＃3として表示されます。

繰り返しになりますが、バグがあるのは2番目のルーターですが、この場合は2番目にリストされているのは2番目のルーターです（manページの例では、2番目にリストされているのは3番目です）。