TTLとは？tracerouteが経路を表示できる仕組みを図解

tracerouteを実行すると、通過したルーターのIPが一行ずつ表示されます。どうして端末から途中の装置まで分かるのでしょうか。その手掛かりになるのがTTLです。

TTLは、パケットがネットワークを回り続けないようにする値です。ルーターで減り、途中で尽きると破棄されます。tracerouteは、この仕組みを使って途中の応答点を調べます。まず一つのパケットで値がどう変わるかを見ていきましょう。

TTLは、転送を続けられる回数を制限する

経路の設定が食い違い、二台のルーターが互いに同じパケットを返し続けたら、通信はループします。TTLがなければ、そのパケットが回り続け、ネットワークの負荷になります。

IPv4のTTLはヘッダーにある8ビットの値です。中継ルーターは転送するときに少なくとも一つ減らし、転送前に値が尽きるパケットを破棄します。

L2スイッチがフレームを中継するだけなら、このIPのTTLは減りません。L3スイッチでも、IPルーティングする場面で減るので、機器の台数とTTLの減少回数を単純に同じにしないようにします。

TTLを1、2、3と変えると、止まる場所が変わる

PCからR1、R2を経てサーバーへ届く例です。TTL1のパケットはR1で値が尽き、R2まで進めません。通常、R1から送信元へICMP Time Exceededが返ります。

TTL2ならR1を越え、R2で尽きます。TTL3なら二台のルーターを越え、サーバーへ届くことができます。表は、各ルーターが一つずつ減らす基本例です。

ICMP Time Exceededは「途中でTTLが尽きた」という通知です。ルーターが普通の業務通信に応答したわけではありません。tracerouteでは意図的に小さいTTLを使うので、この通知は調査の材料になります。

通知も送信元へ戻る経路が必要です。途中の装置でTTLが尽きても、その応答が届かなければ、端末からその場所は見えません。

tracerouteは、別々のプローブの応答を並べる

tracerouteはTTLを少しずつ増やした調査用パケットを送ります。このパケットをプローブと呼びます。TTL1への応答で最初のルーター、TTL2への応答で次のルーター、というように応答点を並べます。

同じパケットを全ルーターが順に返しているのではありません。別々のプローブを送り、それぞれの返信を受け取っています。

# Linux
traceroute -n 172.28.53.10
tcpdump -ni any 'icmp or host 172.28.53.10'

# Windows
tracert -d 172.28.53.10

# Cisco
show ip route 172.28.53.10

Internet Protocol Version 4
  Time to Live: 1
Internet Control Message Protocol
  Type: 11 (Time-to-live exceeded)
  Code: 0 (Time to live exceeded in transit)

WindowsのtracertはICMP Echo、Linuxの一般的なtracerouteは既定でUDPを使います。最後に到達したときの応答も方式によって違います。

表示されたIPは、通知を返した装置側のアドレスです。構成図の転送先インターフェースと必ず同じとは限りません。また、プローブごとに経路が分かれる構成では、出力が一本の固定経路をそのまま示すとも限りません。

TTL切れと、応答が返らない状態を分ける

同じIPが繰り返し現れるなら、経路がループしていないかを調べます。ルーティングテーブルと直前の変更を、関係する装置の両側で確認します。ただし一つの出力だけで原因を確定しません。

途中が「*」でも、その先や宛先が応答するなら、途中の装置が通知を返さない、通知が制限されるといった可能性があります。

「*」は、そのプローブへの応答が時間内に返らなかったという結果です。普通のパケット転送も同じ地点で止まる、と決まったわけではありません。

業務通信の失敗を調べるなら、宛先のTCPやアプリの応答も確認します。TTLによる経路調査と、実際のサービスが使えるかを分けて見ると、判断を急がずに済みます。

キャプチャでは、元のパケットとICMP通知を対応させる

Wiresharkでは、送ったプローブのIP欄でTTLを確認します。返ってきたICMPでは、タイプとコード、内包された元のIPヘッダーなどを見て、どのプローブへの通知かを対応させます。

返信パケットにも独自のTTLがあります。送ったパケットのTTLと、返信のTTLを同じ値として読まないでください。

TTLの初期値は環境によって違うため、受信した値だけでOSや通過台数を断定できません。送信時の値が分かり、同じ経路を比較できる場合に、減少を考えます。

送信元、宛先、方式、時刻、出力を残して、一つのTTLがどこで尽きたかを追ってみてください。経路が見える理由を、パケットの動きで説明できるようになります。

動画・筆者の投稿で補足する

文章と図で流れをつかんだら、関連する動画も参考にしてください。画面の表示や操作は、機種・ソフトウェアの版によって異なる場合があります。

関連する動画・筆者の投稿：2026年5月31日

この記事の執筆・監修者

けんと＠設計構築チャンネル

ネットワーク設計構築エンジニア／インフラ転職コンパス編集者

30歳・IT未経験からSIerへ転職。ネットワークエンジニアとして、金融系・オフィス系ネットワークの設計・構築に携わり、PL・PMも経験。自身の未経験転職と現場経験をもとに、仕事内容・技術・キャリア・求人選びをわかりやすく解説しています。

YouTube登録者5,000人 Xフォロワー5,000人

執筆者プロフィール・編集方針