■ ICMP

エラーを通知したり、通信状態を管理したりするプロトコルが、ICMPだ。

いんたーねっと・こんとろーる・めっせーじ・ぷろとこる、でしたっけ。

そうだ。
インターネット制御メッセージプロトコルってところだな。

「コントロール」を「制御」に訳しただけですね。

(ｷﾞﾛﾘ)

いえ、なんでもないッス。

うむ。ICMPには、その機能において、いくつかのメッセージのタイプに分かれている。
よく使われるものは以下の５つだ。

タイプ３・Destination Unreachableと、タイプ５・Redirectは前回やりましたね。

うむ、それぞれタイプ３・Destination Unreachableは「宛先に届かなかった」というメッセージ。
タイプ５・Redirectは「よりよい経路はこちらですよ」というメッセージだったな。

はい。

というわけで、今回は。
タイプ８・Echo Requestとタイプ０・Echo Replyについて説明する。

えちょー？

■ Echo

なんだその怪音は？
莫迦者、エコーと読め。エコーと。

えこー？
エコーっていうと、あれですか。反響音というか、こだまというか。

そうだ。
山に向かって、「やっほ〜」と言ったら、しばらくしてから「やっほ〜」と返ってくるアレだ。

それは山彦では？

そうとも言う。
木霊も山彦も、英語では同じ「Echo」だがな。声を返してくるのが、「山の精」か「木の精」かの違いだ。

ははぁ。

美しい日本語という奴だ。
ともかく、その「Echo」がタイプ８とタイプ０だ。

RequestとReplyでしたっけ。

うむ。
訳すと、タイプ８が「エコー要求」[Echo Request]で。
タイプ０が「エコー応答」[Echo Reply]になる。

「要求」と「応答」…。
どっかで聞いたような。

そうだな。
ARPの説明ででてきたな。

あぁ、そうそう。
「ARP要求」と「ARP応答」でしたよね。
「ARP要求」を送ると、「ARP応答」が帰ってくる、でしたよね。

そうだ。
それと同じように、エコー要求を送り、それを受け取ったホストはエコー応答を返す。

ははぁ。
まさしく、「エコー」なんですね。要求すると、返答する。

そうだ。
たったコレだけの仕組みだ。

はぁ。
これ、なんかの役に立つんですか？

もの凄く役に立つ。

わ、なんか断言しましたね。

うむ。
この「Echo」の仕組みを利用したもので、pingというコマンドがある。

ぴんぐ？
ペンギンですか？

それはピングー。▼ link
読みはピンだ。「g」は発音しない。

ぴん。

このコマンドはネットワーク管理者御用達。
このコマンドを使わない管理者はいないとまで断言できるシロモノだ。

へへぇ。すごそうですね。

■ ping

pingという名前だが。もともとは、卓球[ping-pong]とかでわかるとおり、擬音語だ。
何かが、何かに当たった時にでる音だな。

ピンポンの「ピン」ですか。

そうだ。
それで水中にある物体を探すソナーが出す信号音の事を探信音[ping]という。このコマンドの名前の由来はそれらしい。

探信音…。

うむ。
探信音を出すと、音が物体に当たって跳ね返ってくる。そこから擬音の[ping]が使われているのではないかな。

…。
…!!   交響曲(シンフォニー)です!!

…沈黙の艦隊かよ。
しかもそれ探信音じゃないし。

あの男も…、海から来た…。

いや、それはもういいから。

なんだ、ノリが悪いですね博士。
そんなんじゃ立派な海江田四郎になれませんよ。

おお、それはちょっと悲しいな。
だがしかし、立派じゃない海江田四郎というのも想像つかないが。

ははぁ。
確かに安酒で酔っ払ってクダをまく海江田四郎なんてのは想像の埒外にありますね。

うむ、そうだろう。
それはともかく、pingだ。ping自体は、デフォルトゲートウェイの話の時に使って見せているな。

デフォルトゲートウェイの話…。

ネット君の記憶力に頼るよりは、もう一度説明した方が早い。
pingは、任意の宛先へエコー要求を送りつけるコマンドだ。

任意の宛先へエコー要求を送りつける？
エコー要求を送りつけると、それを受け取った宛先はエコー応答を返してきますよね。

その通り。エコー要求を受け取った宛先は、エコー応答を返してくる。
エコー要求を送った送信元はエコー応答を受け取る。これは何をあらわしている？

何と言われても。

つまり、エコーの要求と応答が受け渡し可能。
送信元と宛先は接続されているという意味だ。

あ〜、なるほど。
ICMPパケットが送信元と宛先の間を行き来できるんですものね。

そうだ。さらに、エコーの要求と応答にかかる時間を計ることにより、ネットワークの状態を調べることもできる。

状態を調べる？

うむ。
どこかがボトルネックになっていたり、回線が混雑していたり、宛先が遠かったりすると、応答までにかかった時間が長くなる。

ははぁ。

簡単に動きを示すと、以下のようになる。

ふ〜ん。
ホントにソナーみたいですね。
送ったEcho Requestに反応があるかどうか確かめるんだ。

■ ping・実際例

では実際に、Windowsでpingを行ってみよう。

はい。

コマンドは簡単だ。
コマンド(MS-DOS)プロンプトで以下のように打ちたまえ。

ふむふむ。

そうすると、以下のような画面が表示される。
例えば、192.168.0.1にpingを行ってみた。

はぁ。

まずは(1)の部分。Pinging 192.168.0.1 with 32 bytes of dataの部分。
192.168.0.1に32バイトのデータでpingを行っています、だ。

32バイトのデータで、ってのは？

これはさきほど出てきたICMP Type8の中身だが。
「データ」の所に「任意」とあるだろう？ここのサイズのことだ。これは-l のオプションで変更可能だ。

変更すると、なにかあるんですか？

pingは接続を確かめる以外に、ネットワークの調査をする、と先ほど言ったな。
つまり。大きいサイズのデータの時、小さいサイズのデータの時、と送るデータのサイズを変えることで調査を行うのだよ。

あ〜、なるほど。色々試してみるんですね。

うむ、そうだ。
続いて(2)は、Reply from 192.168.0.1 : bytes=32 time<10ms TTL=30。これはReplyが返ってきたことを示す。

４回あるのは？

それは１回のpingコマンドで、４回requestを送るからだ。
なので、replyも４回帰ってくる。

ふむふむ。
Reply from 192.168.0.1 : bytes=32ってのは、192.168.0.1から32バイトのEcho Replyが返ってきたってことですよね。timeとTTLは？

timeは返るまでにかかった時間だ。
ここの数値が予想より大きいと、なにかしらネットワークで障害が発生している可能性がある、と判断できる。「time<10ms」は10ミリ秒以下ってことだな。

ははぁ。TTLは？

とある数からこの数字を引くと途中で経過したルータ(ゲートウェイ)の数になる値だ。ただし、とある数ってのはReplyを返してきた相手のOSに依存する。
TTLについては次回説明する。

はい。

(3)と(4)は結果報告だ。
(3)は、Requestをいくつ送って、いくつReplyが返ってきたか。(4)は、返ってくるまでの最小・最大・平均時間だ。

え〜っと、Sent = 4, Received = 4, Lost = 0だから、Request４つ送って、Reply４つ受け取って、損失０ってことですね。

そうだ。
Minimum = 0ms,Maximum = 0ms,Average = 0msってのは、相手がLAN内のデバイスなので、ミリ秒以下で反応があったということだ。

なるほど。
情報が満載ですね。

うむ。
ネットワーク管理者御用達と言った意味がわかるだろう。
これらの情報を見て、ネットワークの状態を判断するのだよ。

なるほど。

■ ping・エラー例

では、pingのエラー例を見て、pingから何がわかるか、を話そう。

これは、Requestに対して、Replyが返ってこなかったことを指す。
理由には以下のようなことが考えられる。

ははぁ。

さて、上の理由をみて気がつくところがないか？

気がつくところ？
なんか、いろいろ原因があるということはわかりましたが。

もうちょっと考えろ。
これは、レイヤ３以下の障害だ。IPアドレスも、ルーティングも、ケーブルも、スイッチ・ハブも、すべてそうだ。

そう言われればそうですね。

ICMPメッセージを見てもわかるとおり、ICMPはレイヤ４以上のデータを使わない。
つまり、基本的にレイヤ３以下のみで動くのだよ。

レイヤ４以上のエラーが入り込まない…。

そうだ、つまりpingが成功したのに繋がらないのはレイヤ４以上に障害があることを示すし。
pingが失敗したならレイヤ３以下に障害があることになる。

なるほど。pingはレイヤ３以下の障害を見つけてくれるってことですね。

そうだ。
では、他のエラーも見てみよう。

これは、ドメイン名でpingを行った際に出るエラーだ。
pingが実行される前の段階、DNSで出るエラーだな。そのドメインネームは存在しません、というエラーだ。

DNSはレイヤ７では？ pingにレイヤ７が影響するのですか？

いやいや。
これはpingの責任ではない。ドメインネーム→IPアドレスの変換はpingが実行される前に実行されるからな。

こっちは、パケットの生存時間切れだ。
TTLの設定ミスか、ルーティングループでも発生しているか。

上の画像の場合は？

これはエラーを出すために、意図的にTTLを低く設定した。
それゆえのエラーだな。

これは、Destination host unreachableつまり、ICMP タイプ３が返ってきたエラーだ。

Destination host unreachable、宛先到達不能ですよね。

うむ、途中のルータで宛先へのルートがない時に出てきたエラーだったな。
他にもデフォルトゲートウェイが設定されていないのに、他ネットワークへpingを行った時などに起きる。

デフォルトゲートウェイがないと、他ネットワークにはデータ転送できないですからね。
あれ？
これって、デフォルトゲートウェイの回ででてきましたよね。

うむ。
pingが何故繋がらなかったかという理由は覚えておくと役に立つので覚えておくように。

はい。

■ ping・使い方

実際、pingはネットワークへの接続ができなくなった場合に、障害の確認方法として使われることが多い。
簡単だし、便利だしな。

そうみたいですね。

障害を確認するから、といってもやみくもにpingを行ってもしょうがない。
一応、pingを行う順番というものが、経験則としてある。

まず、ループバックアドレス(127.0.0.1)で、TCP/IPが動作しているかどうか確かめる。
次に自分のIPアドレスで、IPアドレス設定が間違っていないかを確認する。

ループバックアドレスと、自分自身のIPアドレスは同じなのではないのですか？

似てるようで、ちょっと違う。ループバックアドレスは、自分自身のIPアドレスの設定が間違っていても使えるのだよ。なので、TCP/IPの動作確認として使う。

へぇ。

LAN内のネットワーキングデバイスの障害を確認して。

LAN外へ出るための、デバイス・サービスの確認をする。

最後に目的に対してpingを行う。
つまり、自分に近いところから確かめていくのがよいだろう。

足場を固めつつ、前へいくんですね。

うむ。ただ、pingだけではLAN外へ出た後の、目的とのサーバとを繋ぐ途中のルータの障害を確かめるのはなかなか難しい。
その場合は、tracerouteを使う。

とれーするーと？

ちょっと今回は長くなったな。
tracerouteと、ICMP タイプ11、Time Exceededはまた次回だ。

了解です。
３分間ネットワーキングでした〜♪