アラートが鳴った。「ping が通らない」。

手元のターミナルを開く。ping <宛先>。Enter。何も返ってこない。

「サーバ、死んだか」 — そう短絡しがちな場面だ。再起動を頼みに行きたくなる。あるいは、上位に投げてしまいたくなる。けれど、その前に1つだけ、止まって考えてみたい。

ping を打って「返ってこない」と言うとき、本当は、何が起きているのか。

実は、同じ「届かない」に見える ping の応答が、ICMP(Internet Control Message Protocol — ネットワークの状態を伝える仕組み)の規格上、3つに分かれている。何も返ってこない場合と、「届かない」と能動的に教えてくれる別のメッセージが返ってくる場合と、何件かは返ってきて何件かは落ちる場合。3つは違う現象であり、それぞれ、壊れている層が違う。

考えてみよう: ping を打って「返ってこない」と言うとき、本当に何も返ってこないのか? それとも、何かは返ってきているのか? もし何かが返ってきている場合、それは「届かない」と教えてくれているのか、それとも別の何かなのか? 30秒だけ、自分の手元の経験を呼び戻して考えてみてほしい。これまで「ping 通らない」と言われたとき、どんな表示を見ていただろうか。

組み立ててみると、思い出すことがある。「Request timed out」と表示される ping。「Destination Host Unreachable」と表示される ping。複数回打って「5 packets transmitted, 4 received, 20% packet loss」と表示される ping。どれも「届いていない」雰囲気の応答だが、画面に出ている文字は、明らかに違う。これらは何が違うのか。

「届かない」には3つの顔がある — タイムアウト(沈黙)/ unreachable(拒否の声)/ 部分応答(一部だけ返事)。それぞれ壊れている層が違うので、次に確認する場所も変わる。3つを区別できることが、観測の最初の目線になる。

ping を打つ前に — 3つの宛先で、3つの違う景色が見える

ここで、ネットスミス社の景色から始めたい。

reader は、自席の業務 PC(OPS-PC01)から、いくつかの宛先へ ping を打つ場面を想像してほしい。1つ目は、同じ部屋の隣席 PC(OPS-PC02)。2つ目は、別フロアの営業部の PC(SALES-PC01)。3つ目は、社外の検証用宛先で、わざと辿れない場所として置かれた仮想的な宛先。

3つの宛先に、同じ ping <宛先> というコマンドを打ってみる。同じコマンドだが、返ってくる景色は、それぞれ違う。

1つ目の隣席 PC への ping。Enter を押した直後に、Reply が即座に返ってくる。「64 bytes from 10.1.50.20: icmp_seq=1 ttl=64 time=0.345 ms」のような表示だ。出した分だけ、対応する返事が即時に届く。これが「成功」。

2つ目の別フロア PC への ping。最初の数件は Reply が返ってくる。けれど、途中で「Request timed out」が混ざる。何件かは届いているが、何件かは届いていない。

3つ目の仮想的に経路がない宛先への ping。Reply は1件も返ってこない。代わりに、画面には「From 10.1.1.1 icmp_seq=1 Destination Host Unreachable」と表示される。Reply ではない、別の何かが返ってきている。

3つの違う景色。reader はこれまで、これらをまとめて「届く」「届かない」の二択で読んできたかもしれない。けれど、画面に出ている文字を素直に読めば、3つは別の現象だ。同じ ping コマンドが、宛先によって違う物語を語っている。

ポイント: 同じ ping コマンドでも、宛先によって違う景色が返ってくる。「届かない」に見える応答にも、何も返ってこない場合と、別のメッセージが返ってくる場合と、一部だけ返ってくる場合がある。これらの違いはどこから来るのか — それが、ここでの中核。

ping は「行きの依頼書」と「帰りの返事」のペアで成立している

3つの違いを読むには、まず ping そのものの仕組みを呼び戻したい。ping というコマンドが、裏で何をしているか。

ping を打つと、送信側のホストは、ICMP の Echo Request という小さなメッセージを1枚作って、宛先 IP に送り出す。これが「行きの依頼書」。届いたら、返事をください、という依頼だ。Echo Request の中には、識別用の番号と、検証用の小さなデータが入っている。それ以上の特別な要求は何もない。

宛先のホストが、その依頼書を受け取る。受け取ったホストは、決まった応答を返す。ICMP の Echo Reply という、これまた別のメッセージだ。中身は、依頼書に入っていたデータをそのままコピーして返すだけ。「届きましたよ、その証拠にあなたが送ったデータをそのまま返します」という意味の、シンプルな返事。

送信側は、出した行きの依頼書に対して、対応する帰りの返事が届けば、ペアが揃ったとして「成功」と判定する。コマンドの画面には「64 bytes from <宛先>: icmp_seq=1 ttl=64 time=0.345 ms」のように表示される。bytes は返事に入っていたデータの大きさ、icmp_seq は依頼書につけた番号、time は依頼書を出してから返事が戻ってくるまでにかかった時間だ。

これが、ping の往復モデルだ。Echo Request(行きの依頼書)と Echo Reply(帰りの返事)のペア。ping が「成功」と判定するのは、このペアが揃ったとき、それだけ。

ここからが大事だ。応答が「届かない」に見えるとき、ペアが揃わなかった、ということだけはわかる。だが、揃わなかった「理由」は、まだ1つに決まっていない。揃わない理由が、3つに分かれる。

ポイント: ping は ICMP の Echo Request(行きの依頼書)と Echo Reply(帰りの返事)のペアで成立する。ペアが揃って初めて「成功」。揃わない場合は、揃わない「理由」を3つに分けて読む。

1つ目の顔 — タイムアウト(沈黙)。何も返ってこない

1つ目の顔は「タイムアウト」だ。

ping コマンドは、Echo Request を出したあと、Echo Reply が返ってくるのを一定時間待つ。その時間内に何も返ってこなければ、「時間切れです」と判定して、画面に表示する。Windows の ping なら「Request timed out」、Cisco IOS の ping なら .(ピリオド1個)。Linux iputils の ping のように、応答行を出さず最後の statistics で全件 loss として確認する形の実装もある。

ここで重要なのは、このとき返ってきているものは、何もない、ということだ。エラー応答が返ってきたわけではない。何かのメッセージが届いたわけでもない。ただ、待った。出した。何も来なかった。それだけ。

これが「沈黙」だ。

沈黙が意味するのは、行きの依頼書は出たが、帰りの返事は届いていない、という状態。なぜ届かなかったかは、送信側からは直接わからない。可能性はいくつもある。経路途中のどこかでパケットが消えたかもしれない。宛先まで届いたが宛先からの応答が経路で消えたかもしれない。宛先がそもそも応答できない状態かもしれない。何かが応答を止めている設定で、サイレントに破棄しているかもしれない。送信側にあるのは、ただ「何も返ってこなかった」という事実だけだ。

この沈黙の顔を見たときの最初の問いは、「どこまで届いたのか」になる。届いた範囲がわかれば、消えた場所が絞れる。けれど、ping の沈黙からは、それを直接読み取れない。届いた範囲を確かめるには、別の道具が要る。それは、ここでの射程の外。次の話で扱う問いだ。

ポイント: タイムアウト(沈黙)= 何も返ってこない時間切れ。エラーメッセージが返ってきたわけでもない。送信側からは「どこで起きたか」を直接特定できない。これが第1の顔。

2つ目の顔 — unreachable(拒否の声)。届かないと能動的に教えてくれる

2つ目の顔は「Destination Unreachable」だ。略して unreachable と呼ばれる。

Linux iputils の ping で表示されるのは、こんな1行。「From 10.1.1.1 icmp_seq=1 Destination Host Unreachable」。Cisco IOS の ping なら U(大文字の U)。沈黙との違いは、目を凝らすまでもない。何かが返ってきている。

しかも、返ってきているものは、Echo Reply ではない。ICMP の規格上、Echo Reply とは別に定義された Destination Unreachable という、別のメッセージだ。送り主は、ICMP の規格に沿って能動的にこのメッセージを送ってきている。「この方向には届けられません」と、誰かが教えてくれている、という状態だ。

送り主は、宛先そのものとは限らない。経路の途中にいるルータが返してくる場合がある。例えば、ルータが宛先のネットワークに対して、ルーティングテーブルに該当する経路を持っていなければ、ルータは「自分にはこの宛先への経路情報がありません」と判断して、Destination Unreachable を送信元に返す。あるいは、設定で意図的に経路を遮断している場合も、ルータが Destination Unreachable で送信元に応答する場合がある。宛先のホスト自身が返す場合もある。たとえば、宛先まではパケットが届いたが、宛先のホストが応答できない状態にあるとき、宛先自身が Destination Unreachable を返すことがある。

つまり、unreachable が返ってきた、ということは、「届かない」を能動的に教えてくれている誰かが、経路上のどこかにいる、ということだ。届いてはいないが、情報は返ってきている、という逆説的な状態。

沈黙との違いは大きい。沈黙では「どこで起きたかわからない」が、unreachable では「誰が拒否しているか」のヒントが手元に来る。Linux ping の場合、表示の From の後ろにある IP アドレスが、その応答を返した送信元 — つまり、応答を返したルータか宛先のいずれか — の IP だ。経路上のルータが返したなら、そのルータまでは送信側からパケットが届いている、という情報まで手に入る。沈黙のときには得られなかった情報が、unreachable では返ってくる。

ポイント: unreachable(拒否の声)= ICMP の規格上 別のメッセージ(Destination Unreachable)が、経路上のルータか宛先から能動的に返ってくる。届いてはいないが情報は返ってきている、という逆説。応答の出所(From <ip>)が、次の手がかりになる。これが第2の顔。

3つ目の顔 — 部分応答(一部だけ返事)。経路は生きているが揺らいでいる

3つ目の顔は「部分応答」だ。

ping は通常、複数回 Echo Request を送る。Linux iputils の ping なら、Ctrl+C で止めるまで連続して打ち、止めたときに集計が出る。「120 packets transmitted, 113 received, 5.8% packet loss」のように。Cisco IOS の ping なら、デフォルトで 5 回送って、!!!.!(感嘆符4つの間にピリオド1つ)のような並びを表示する。

全部が成功でも、全部がタイムアウトでもない。一部が Reply で返ってきて、一部が沈黙で消えている、という景色だ。

これが意味するのは、経路は完全には死んでいないが、何かが揺らいでいる、ということ。Reply が返ってきた回数は、行きと帰りの両方が成功したペアの数。沈黙の回数は、ペアが揃わなかった回数。揃ったり揃わなかったりが交互に起きている、という状態だ。

原因はいくつもありうる。物理的なリンクの品質劣化でフレームが時々壊れているかもしれない。経路のどこかで輻輳が起きていて、混雑時にパケットが捨てられているかもしれない。途中のルータか宛先で、応答頻度を絞る設定が動いていて、間引かれているかもしれない。送信側からは、どれかをすぐに確定はできない。

ただ、共通して言えるのは、何回かは届いている、ということだ。タイムアウト(全件沈黙)とは違う。unreachable(能動的な拒否)とも違う。「大部分は OK だが、一部は落ちている」あるいは「半分は OK だが、半分は落ちている」という、揺らぎの顔。

この顔を読むときに重要なのは、ロス率の数字そのものだ。「120 件中 113 件 received、ロス率 5.8%」と「120 件中 60 件 received、ロス率 50%」では、見えている揺らぎの大きさが違う。観測されたロス率そのものを、いまの経路品質のシグナルとして読む。揺らぎが小さければ自然な範囲、大きければ明確な品質劣化のサイン。具体的にどこが揺らいでいるかは、ロス率の数字と他の手がかりを組み合わせて読む別の作業になる。

ポイント: 部分応答(一部だけ返事)= 複数回 ping を打って、一部だけ Echo Reply が返ってくる状態。ロス率として観測される。経路は生きているが何かが揺らいでいる。0% でも 100% でもない数字そのものが、揺らぎのシグナル。これが第3の顔。

3つの顔は壊れている層が違う — だから次に確認する場所も変わる

ここまで来て、3つの顔の正体が見えた。

3つは、ICMP の規格上、別のメッセージか別の現象として独立している。タイムアウトは、ICMP メッセージが何も返ってきていない状態を、送信側のタイマーが時間切れで判定したもの。unreachable は、Destination Unreachable という別タイプの ICMP メッセージが能動的に到着している状態。部分応答は、Echo Reply が来たり来なかったりという、繰り返しの中での揺らぎ。

だから、3つは「壊れている層」が違う。タイムアウトは経路途中のどこかでパケットが消失しているが、送信側からは消えた場所はわからない。unreachable は経路上のルータか宛先が、その方向への配送を能動的に拒否している。情報は返ってきているが配送はされていない。部分応答は経路自体は通っているが、品質が揺らいでいる。ある程度のフレームは届くが一部が落ちる。

層が違うから、次に確認する場所も変わる。

タイムアウトを見たら、最初に問うのは「どこまで届いていて、どこから先が沈黙しているか」だ。けれど、それを送信側から特定する道具を、ping だけでは持っていない。だから、別の道具が要る。これは次の話で扱う。

unreachable を見たら、最初に問うのは「誰が拒否しているか」だ。応答を返した IP がヒントとして手元にある。その IP がどの機器なのか、なぜ拒否しているのかを順に追う。

部分応答を見たら、最初に問うのは「揺らぎの大きさはどれくらいか」だ。ロス率の数字を読む。同時に、ping は L3 までの到達性を見ているだけだから、L7 のサービス自体が応答しているかは別の確認が要る。揺らぎが見えたら、L3 と L7 の両方を疑う。

3つを混同したまま「ping 通らない」と一言で済ませると、次の一手が選べない。3つを区別できると、観測の最初の目線が手に入る。これが、ここでの到達点だ。

ポイント: 3つの顔は壊れている層が違う。タイムアウト = 経路途中の消失 / unreachable = 経路上の能動的拒否 / 部分応答 = 経路品質の揺らぎ。だから次に確認する場所も変わる。3つを区別できることが、観測の最初の目線。

届かない理由は応答の種類で分かれる

ping の応答が4つに分かれることが、概念で手元に来た。

成功は、行きの依頼書(Echo Request)に対して帰りの返事(Echo Reply)が返ってきたという、ペアが揃った状態。タイムアウトは、ペアの帰りが返ってこない「沈黙」。unreachable は、Echo Reply の代わりに Destination Unreachable という別の ICMP メッセージが返ってきた「拒否の声」。部分応答は、複数回打って一部だけ返ってくる「揺らぎ」。中核は、後ろの3つ — 「届かない」の3つの顔を区別する目線だ。

3つは ICMP の往復モデルを土台にしながら、規格上 別のメッセージや別の現象として独立している。だからこそ、それぞれ壊れている層が違う。タイムアウトは経路途中の消失、unreachable は経路上の能動的拒否、部分応答は経路品質の揺らぎ。次に確認する場所も、3つでそれぞれ変わる。「届かない」を一言で済ませず、3つに分けて読むことが、観測の最初の目線になる。

ここまでで、観測の道具を1つ手に入れた。だが、気づいたことがある。

unreachable のときは、応答の出所(From <ip>)がヒントとして返ってくる。だから、誰が拒否しているかの足がかりがある。けれど、タイムアウト(沈黙)のときは、その足がかりが無い。沈黙が経路のどこで起きているのか — それを送信側から直接特定する道具を、ping だけではまだ持っていない。

途中の経路を見るには、どうすればいいのか。

次の話では、その問いに向き合う。沈黙の場所を送信側から見にいくための手立てを、次に獲得しに行く。