traceroute / tracertはすべてのホップを表示しますか、それともパスの一部の詳細をスキップ/非表示にしますか？

現在、私は大学でネットワークエンジニアリングの学士号を取得しており、教授の一人がクラスで、たとえば15ホップを示すtracerouteが実際にパスを抽象化しており、実際にはさらに多くのノードが関与していると説明しました。これは本当ですか？

これは、tracerouteで見つけることができるすべてのものと矛盾しています。私の知る限り、tracerouteはICMP（またはUDP）パケットを0からTTLの特定の宛先に送信することで機能します-> n宛先に到達するまで。送信されたプローブパケットは、途中で各場所で連続してタイムアウトし、ICMPの「time exceeded」応答を生成し、最終的に宛先に到達すると「port unreachable」メッセージを生成します。

tracerouteの欠陥を理解しています。たとえば、特定のゲートウェイによってtracerouteトラフィックがブロックされたり、応答パケットのTTLがプローブの残りのTTLに設定されて、送信者に戻らないことがあります。

ただし、多くの調査を行った後、常に同じパスを返すtracerouteの場合、tracerouteを参照するものが不正確であることはわかりません。同様に、tracerouteによって報告されない「余分な」ホップがあることを参照するものはありません（応答なしでタイムアウトになった* * *ホップ以外）。

私は議論を受け入れており、これに対する答えを知りたいと心から思っています。

tracerouteは、AからBに到達するレイヤー3ホップの数を示します。

ただし、その間に何百ものスイッチを通過する可能性があります。また、シングルホップとして表示されるレイヤー2 VPNを実行している10のISPルーターを通過することもできます。MPLSネットワークは、内部を隠したり、内部を表示したりできます。パスに透過ファイアウォールを設定することもできます。

いずれにしても、教授は、パス内のすべてのデバイスがホップとしてカウントされることを保証できないと言っているのは正しいです。上記のポイントのため、50台のデバイスを使用できますが、3台のデバイスのように見えます。

しかし、それは常に起こりません。15ホップが表示される場合、15ホップである可能性が非常に高くなります。

これは、TTLに関して設定されたMPLSの基本的な例です：http : //www.juniper.net/techpubs/en_US/junos13.2/topics/reference/configuration-statement/no-propagate-ttl-edit-protocols -mpls.html

IP TTLフィールド値を減少させないデバイスは、tracerouteパスに表示されません。たとえば、Cisco ASA Firewallは、ファイアウォールを通過するパケットのIP TTLフィールドを減少させるように設定できます（接続の減少-ttlを設定）。デフォルトでは、TTLはデクリメントされていないため、ファイアウォールを隠しています（まあ、ある程度）。

Tracerouteは、IPデータグラムのTTLフィールドを減少させないデバイスを表示しません。

また、TTLフィールドをデクリメントし、TTLがゼロに達した場合にパケットを消費するデバイスを表示しませんが、ICMPデータグラムを介してこのイベントを送信者に通知することを無視します。ただし、これは完全に不可視ではありません。tracerouteでこの欠落ホップの存在を推測できます。次の高いTTL値が使用されると、チェーン内の次のデバイスが応答し、そのデバイスと前のデバイスの間の何かがTTLをデクリメントしますが、それ自体を通知しないためです。従来のtracerouteユーティリティは、応答を受信しないときにアスタリスクを出力します。このタイプのホストのアスタリスクの行を印刷します。

また、送信元アドレスに応じて、中間のルーターがこれらのICMPメッセージを選択的に抑制し、応答を生成してもパスの一部が見えないようにする可能性があります。