こんにちは！NOC（ネットワークオペレーションセンター）で日々、パケットのざわめきと格闘しているシニアエンジニアです。
皆さんは、ネットワークの調子が悪いときに真っ先にする確認といえば何でしょうか？ そう、ping コマンドですよね。「とりあえず ping を打ってみる」というのは、インフラエンジニアにとっても、開発者にとっても、いわば挨拶のようなものです。
でも、画面に流れてくる Request timed out や、見慣れないエラーメッセージにモヤモヤしたことはありませんか？
特に、トラブルシューティングの現場でよく目にする 「TTL（Time to Live）超過エラー」 は、パケットがネットワークの迷宮に迷い込んだことを教えてくれる、非常に重要なサインです。
今回は、このTTLの正体と、パケットが迷子になったときにルータが発する「SOS」の仕組みについて、郵便配達のたとえを交えながら、一緒に優しく紐解いていきましょう！
—
1. 宛先になかなか届かない？パケットの「寿命」ってなに？
インターネットの世界は、世界中のルータという名の交差点が無数に組み合わさってできています。私たちがスマホやPCから放ったデータ（パケット）は、いくつもの交差点を経由して、目的地のサーバへと旅立ちます。
ここで、ちょっと想像してみてください。
もし、ネットワークの設定ミスなどで、パケットがぐるぐると同じ交差点を無限に回り続けてしまったらどうなるでしょうか？
そう、世界中のルータが永遠にそのパケットを転送し続け、ネットワークの道路は大渋滞（パケットストーム）を起こして麻痺してしまいますよね。
この「無限ループという悪夢」を防ぐためにパケットに持たされているのが、TTL（Time to Live：生存時間） というカウンターです。名前に「タイム（時間）」とついていますが、実際の仕組みは時間ではなく「ルータをあと何回通過できるか」というホップ数（回数）の制限になっています。
郵便配達でイメージしてみよう！
TTLの仕組みは、まるで「手紙のスタンプ回数制限付きおつかい」に似ています。
1. あなたが手紙（パケット）を出すとき、封筒に「スタンプは最大で 64回 まで！」と大きく書き込みます（これが初期TTL値です）。
2. 手紙が1つ目の郵便局（ルータ）を通るたびに、係員がスタンプを1つ減らします（64 → 63）。
3. もし宛先が見つからず、郵便局の間をぐるぐるとたらい回しにされ、ついにスタンプの残り回数が「0」になってしまったら……？
4. その郵便局は、「これ以上たらい回しにするのはルール違反だ！」と判断し、手紙の旅を強制終了させます。そして、あなたのもとに「宛先にたどり着けませんでした」というお詫びの通知を送り届けるのです。
この「お詫びの通知」こそが、ネットワークの世界でルータから返される ICMP Time Exceeded（Type 11） というエラーメッセージなんですよ。
—
2. 実践！ traceroute はこの仕組みをどう使っているの？
「パケットの寿命が切れたらエラーになる」と聞くと、なんだか怖い機能のように思えるかもしれませんが、実はこの仕組み、ネットワークの診断ツールである traceroute（Windowsでは tracert）というコマンドで大いに活用されています。
traceroute は、「宛先までにどんなルータを通ってきたか」を調べるスグレモノですが、やっていることは実にシンプルです。
1. 最初は、あえて寿命が「1」だけのパケットを送り出します。
2. すぐ隣の1台目のルータで寿命が切れるため、そのルータが「TTLが切れましたよ！」とエラー（ICMP Time Exceeded）を返してくれます。これで1台目のルータのIPアドレスが分かります。
3. 次は、寿命を「2」にして送ります。2台目のルータで寿命が切れるため、2台目のルータのIPアドレスが分かります。
4. これを繰り返すことで、宛先までの道のりをまるでスタンプラリーのように暴いていくのです！
百聞は一見にしかず。実際に手元の端末から traceroute を実行したときの様子を見てみましょう。
# Linux環境でGoogleのパブリックDNS（8.8.8.8）までの経路を調査する例
$ traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 64 byte packets
1 gateway (192.168.1.1) 2.145 ms 1.987 ms 1.854 ms # 1台目のルータ（自宅のWi-Fiルータ）
2 10.0.0.1 (10.0.0.1) 5.123 ms 4.891 ms 5.012 ms # 2台目のルータ（プロバイダの設備）
3 172.16.100.5 (172.16.100.5) 12.451 ms 11.982 ms 12.111 ms # 3台目のルータ
...（中略）...
10 dns.google (8.8.8.8) 14.231 ms 14.102 ms 14.055 ms # 目的地のサーバに到着！このように、エラー（Time Exceeded）を逆手に取ることで、私たちはネットワークの地図を描き出すことができるのです。エラーも使いよう、面白いですよね！
—
3. 現場で遭遇する「TTL超過エラー」のトラブルシューティング
さて、ここからはNOCエンジニアとしてのリアルな現場のお話をしましょう。
日常の運用監視の中で、意図しないところでTTL超過エラーが発生している場合、それは大抵「ルーティングループ（経路の迷子状態）」が発生していることを意味します。
例えば、次のようなネットワーク構成を想像してみてください。
[あなたのサーバ] ---> (ルータA) <===> (ルータB) ---> [宛先不明のネットワーク]
^ |
|___(誤った設定)_|ルータAは「宛先に行くにはルータBへ行け」と言い、ルータBは「その宛先ならルータAに戻れ」と言っている……。こんな「無限お見合い状態」に陥ると、パケットはあっという間にTTLを使い果たしてしまいます。
実務でこのようなルーティングループに直面したときは、落ち着いて以下のステップで原因を特定していきましょう。
ステップ1：影響範囲と対象パケットの特定
まずは、どの宛先に向かうときにエラーが出ているのかを切り分けます。
# 宛先を指定してpingを実行し、応答を確認する
$ ping -c 4 192.168.100.50
PING 192.168.100.50 (192.168.100.50) 56(84) bytes of data.
From 192.168.1.1 icmp_seq=1 Time to live exceeded
From 192.168.1.1 icmp_seq=2 Time to live exceeded
# ※解説：自分自身のすぐ近くのルータ（192.168.1.1）から "Time to live exceeded" が返ってきています。
# これは、パケットが遠くへ行く前に、ごく近場のルータ間でループしている可能性が高いことを示唆しています。ステップ2：ホップ数の確認と異常箇所の特定
次に、traceroute を使って、パケットがどこで足止めを食らっているのか、あるいは同じIPアドレスが何度も登場していないかを確認します。
# どこでループしているかを視覚的にあぶり出す
$ traceroute 192.168.100.50
traceroute to 192.168.100.50 (192.168.100.50), 30 hops max
1 192.168.1.1 1.120 ms
2 10.0.0.254 2.450 ms
3 10.11.12.1 5.110 ms
4 10.0.0.254 5.230 ms # あれ？ 2番目のルータに戻っている！
5 10.11.12.1 5.450 ms # ここでループが発生していることが確定このように、出力結果に同じルータのIPアドレスが交互に現れたり、ホップ数が際限なく増えていく場合は、ルーティングテーブル（経路制御表）の設定ミス（スタティックルートの誤設定や、ダイナミックルーティングプロトコルBGP/OSPFのメトリック設定ミスなど）を疑います。
該当するルータにログインし、スタティックルートの向きや、ネクストホップのIPアドレスに矛盾がないかをじっくりと確認・修正することで、このループ地獄をスパッと断ち切ることができます。
—
まとめ
今回は、ping や traceroute の裏側で静かに働き、ネットワークの安全を守っている TTL（Time to Live） と ICMP Time Exceeded エラー について解説しました。
- TTLとは？ パケットの寿命（ルータを渡歩ける残りの回数）であり、無限ループによるネットワークの崩壊を防ぐための防衛策です。
- エラーの正体は？ 寿命が尽きたときにルータが発する「これ以上たらい回しにできません」というSOS通知です。
- トラブル時のアプローチは？
tracerouteを駆使してパケットがどこで迷子になっているかを可視化し、ルータの経路設定を見直すことで解決の糸口が見えてきます。
一見すると難しそうに見えるネットワークのエラーメッセージも、その背景にあるストーリーやたとえを知ることで、ぐっと身近なものに感じられたのではないでしょうか？
日々の運用や開発で「あれ？」と思う挙動に出会ったら、パケットたちが今どこを旅していて、どんな文句を言っているのか、ぜひ想像してみてくださいね。それでは、また次回のNOCブログでお会いしましょう！
コメント