ネットワークの「迷子」を探し出せ！tracerouteで読み解くパケットの旅路
こんにちは！NOCでネットワークのトラブル対応を数え切れないほどこなしてきた、現場のエンジニアです。
皆さんは、Webサイトの表示が急に遅くなったり、特定のサーバーに繋がらなくなったりしたとき、真っ先に何をしますか？多くのエンジニアがまず叩くコマンド、それが traceroute（Windowsなら tracert）です。
でも、ただ画面に流れる数字の羅列を眺めているだけになっていませんか？実は、このコマンドには「パケットがどこで迷子になっているか」「どこで渋滞に巻き込まれているか」を見抜くための、現場直伝の読み解き方があるんです。
今日は、パケットを「荷物」に見立てて、その旅路を追いかける方法を一緒に学んでいきましょう！
—
1. tracerouteって結局、何をしてるの？
郵便物を送る場面を想像してみてください。宛先に届くまでには、いくつかの郵便局（ルーター）を経由しますよね。
traceroute は、「宛先まで荷物が届く道のりを、一つずつ確認するツール」です。
1. 最初は「1つ先の郵便局まで」荷物を送り、「届いた？」と聞く。
2. 次は「2つ先の郵便局まで」荷物を送り、「届いた？」と聞く。
3. これを繰り返し、徐々に遠くまで送り届けることで、経路上の全郵便局を特定するんです。
ここで使われる仕組みが、IPパケットのヘッダーにある TTL（Time To Live：生存時間）という値です。この値はルーターを通るたびに1ずつ減り、0になるとパケットは破棄されます。このとき、ルーターは「ごめん、期限切れだよ」というエラー（ICMP Time Exceeded）を返してくれる。この性質を逆手に取って、経路を炙り出すわけです。賢いですよね！
—
2. 現場で役立つ「応答遅延」の解析術
traceroute を実行すると、各ホップ（経由地）に対して3回パケットを送ります。その結果がこちらです。
# traceroute で google.com への経路を追いかける例
$ traceroute google.com
1 192.168.1.1 1.234 ms 1.120 ms 1.080 ms
2 10.0.5.1 5.450 ms 5.210 ms 5.330 ms
3 203.0.113.1 25.400 ms 25.100 ms 25.500 ms <-- ここで遅延が跳ね上がった！ここで注目すべきは、「どのホップから遅延が急増したか」です。
- ホップ1から2へ： 1ms→5ms（社内LANからISPの入り口へ。許容範囲）
- ホップ2から3へ： 5ms→25ms（ここが怪しい！）
このように、あるホップを境に遅延が大幅に増えた場合、そのルーター間、あるいはその先のネットワークで「大渋滞」が発生している可能性が高いと判断します。
現場の知見：その「遅延」は本当に障害？
注意してほしいのは、ホップ単体で遅延が大きくても、その後のホップで遅延が戻っている場合は「無視」してOKです。ルーターは優先順位の低い traceroute 用のパケットを、後回しにして処理することがあるからです。「遅延がずっと続くか」、ここが判断の分かれ目になります。
—
3. ルーティングループを検知する
トラブルシューティングで最も恐ろしいのが「ルーティングループ」です。パケットが「Aルーターに行けと言われ、AルーターはBに行けと言い、BはまたAに行けと言う…」という、終わりのない無限ループに陥る状態です。
traceroute では、これが一目でわかります。
# ループが発生している時の表示例
7 192.0.2.1 10.120 ms
8 198.51.100.1 10.150 ms
9 192.0.2.1 10.110 ms <-- 7番目と同じIPに戻ってきた！
10 198.51.100.1 10.160 ms
# これが画面を埋め尽くすまで繰り返されますこのように、同じIPアドレスが何度も登場し、ホップ数が際限なく増え続ける場合は、即座に上位ネットワーク担当者に連絡して、経路設定（ルーティングテーブル）を見直してもらう必要があります。
—
4. IX（インターネット交換点）でのトラブル特定
ISP同士が接続する IX（Internet Exchange）は、インターネットの「交差点」です。ここでの遅延は、多くのユーザーに影響します。
もし、traceroute の結果で、特定のISPのネットワークに入った途端に遅延が跳ね上がり、パケットロス（* * * と表示される）が発生しているなら、それはそのISPとIX間の接続がパンクしているか、ISP側での障害である可能性が高いです。
# パケットロスが発生している例
10 203.0.113.5 * * * <-- 返事がない…
11 203.0.113.6 50.200 ms 50.150 ms 50.300 ms※ただし、最近はセキュリティのために traceroute の応答をわざと拒否するルーターも多いので、「* が出たら即障害」と決めつけず、最後の宛先まで繋がっているなら「単なる設定」と割り切る勇気も必要です。
—
まとめ：ネットワークは「観察」がすべて
ネットワークのトラブルシューティングは、医者の診察と似ています。いきなり「設定を書き換えよう！」とするのではなく、まずは traceroute で「どこが痛いのか」をじっくり観察してください。
1. ベースラインを知る： 普段の正常な遅延値を知っておくこと。
2. 比較する： 障害が起きたときと、普段の結果を比較する。
3. 冷静になる： 一時の遅延に惑わされず、経路全体を俯瞰して見る。
皆さんがコマンドを打つその一歩が、トラブル解決への最短距離です。ぜひ、今日の記事を参考に、現場でパケットの旅路を追いかけてみてくださいね。
また次の記事で、より深く「現場の泥臭い知見」を共有しましょう！それでは、良いネットワークライフを！
コメント