it-swarm-ja.com

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に代わって構成が誤っている可能性がありますか?

8
Adam Lindberg

これが1回またはまれに発生する場合

すべての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回あります。 everyIPが2回リストされているため、さらに悪い可能性がありますが、最初の217.0.117.61の回答を提供するルーターがトレースに再び参加することはなかったため、次のすべてのパケットが通過しましたIPが返されなかった不明なルーター。

これが常に発生する場合

次に、ISPがネットワークを設定した方法が原因です。リスト内のIPは、高性能で洗練されたノードを備えた巨大な内部ネットワークを持つDeutsche Telekom AGに属しており、そのうちの1つは2回回答しているようです。

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

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

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

14
harrymc

一貫して発生しているため、ルーターのファームウェアの1つにバグがあり、トレースパケットのドロップに失敗する(および「TTL超過」レポートを送信する)か、その前に送信することが原因である可能性が高いと思います。すべきです。 BSD traceroute manページ の最初の問題の例を次に示します。

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の両方として表示されます。

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

  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番目です)。

1
Gordon Davisson