名称

ping — ICMP ECHO_REQUEST パケットをネットワーク上のホストへ送る

書式

ping	[ -AaDdfnoQqRrv][ -c count][ -G sweepmaxsize][ -g sweepminsize][ -h sweepincrsize][ -i wait][ -l preload][ -M mask | time][ -m ttl][ -P policy][ -p pattern][ -S src_addr][ -s packetsize][ -t timeout][ -W waittime][ -z tos] host

ping	[ -AaDdfLnoQqRrv][ -c count][ -I iface][ -i wait][ -l preload][ -M mask | time][ -m ttl][ -P policy][ -p pattern][ -S src_addr][ -s packetsize][ -T ttl][ -t timeout][ -W waittime][ -z tos] mcast-group

解説

ping ユーティリティは、ホストまたはゲートウェイから ICMP ECHO_RESPONSE を引き出すために ICMP プロトコルの強制な ECHO_REQUEST データグラムを使用します。 ECHO_REQUEST データグラム (“ping”) には、IP および ICMP ヘッダ、“struct timeval”、パケットの残りを埋める適当な数の“pad”バイトが順にあります。オプションは以下の通りです:

-A

聴覚モード。次のパケットを送信する前にパケットを受け取らないと、ベル (ASCII 0x07) 文字を出力します。送信間隔よりも往復時間が長い場合のために、未受信パケット数の最大値を増加させた場合のみ、それを越えて喪失したパケットがベルを鳴らします。

-a

聴覚モード。パケットを受け取った時に、出力にベル (ASCII 0x07) 文字を含みます。このオプションは、別形式のオプションがある場合は無視されます。

-c count

ECHO_RESPONSE パケットを count 回送出 (そして受信) してから終了します。本オプションが指定されない場合、 ping は割り込まれるまで動作を継続します。このオプションが ping sweep とともに指定されないなら、各 sweep は、 count パケットから成ります。

-D

フラグメント無しフラグを設定します。

-d

使用する socket に SO_DEBUG オプションを設定します。

-f

ping を垂れ流します。パケットが返って来るとすぐ、もしくは 100 分の 1 秒に 1 回のいずれか多い回数だけパケットを出力します。 ECHO_REQUEST パケットを送るたびに“.”が表示され、 ECHO_REPLY パケットを受信するたびにバックスペースが表示されます。これによりどれだけのパケットが欠落したのかをすばやく表示することができます。スーパユーザのみ使用可能です。

このオプションはネットワークに非常に負荷をかけるので、注意して使用する必要があります。

-G sweepmaxsize

全面的な ping を送信するとき、 ICMP ペイロードの最大サイズを指定します。このオプションは、ping sweep には必要です。

-g sweepminsize

全面的な ping を送信するとき、開始する ICMP ペイロードのサイズを指定します。デフォルト値は、0 です。

-h sweepincrsize

全面的な ping を送信するとき、各 sweep の後の ICMP ペイロードのサイズを増加するバイト数を指定します。デフォルト値は、1 です。

-I iface

与えられたインタフェースアドレスに対して、マルチキャストパケットを送ります。このフラグは、ping の宛先アドレスがマルチキャストアドレスの場合だけに適用できます。

-i wait

wait 秒数だけ パケットの送信間隔 を待ちます。デフォルトでは送出間隔は、1 秒です。より小さい値を指定できますが、 1 より小さい値を指定できるのはスーパユーザだけです。このオプションは、 -f オプションとは同時に指定できません。

-L

マルチキャストパケットのループバックを抑制します。このフラグは、宛先アドレスがマルチキャストアドレスの場合だけ適用できます。

-l preload

preload が指定されるなら、 ping は、パケットを出来るだけ速く送信し、通常の動作に戻ります。スーパユーザのみがこのオプションを使用できます。

-M mask | time

ICMP_ECHO の代りに ICMP_MASKREQ または ICMP_TSTAMP を使用します。 mask では、リモートマシンのネットマスクを表示します。 net.inet.icmp.maskrepl MIB 変数を設定すると、 ICMP_MASKREPLY が有効になります。 time では、起点、受理、送信のタイムスタンプが表示されます。

-m ttl

出力パケットの IP Time To Live を設定します。指定しないと、カーネルは、 net.inet.ip.ttl MIB 変数の値を使用します。

-n

数値のみ出力します。ホストアドレスに対する名前を調べるようなことはしません。

-o

応答パケットを 1 個受け取ると、成功状態で終了します。

-P policy

policy は、ping セッションの IPsec ポリシを指定します。詳細については、 ipsec(4) と ipsec_set_policy(3) を参照してください。

-p pattern

送出するパケットを埋める最大 16 バイトの“pad”バイトを指定します。これはネットワーク上でデータ依存の問題を診断するときに有効です。たとえば“ -p ff”は全て 1 の送出パケットを生成します。

-Q

いくらか静かな出力にします。自己が行なった問い合わせに対しての応答に含まれる ICMP エラーメッセージは表示されません。もともとは、 -v オプションがそのようなエラーを表示するために必要でしたが、 -v オプションは全ての ICMP エラーメッセージを表示します。忙しい機械上では、この出力は更に負荷になるでしょう。 -Q オプションを指定しないと、 ping は、自己の ECHO_REQUEST メッセージに起因する ICMP エラーメッセージを表示します。

-q

出力を抑制します。開始時と終了時の要約行しか表示しません。

-R

指定ホストまでの到達経路を記録します。 ECHO_REQUEST パケット中に RECORD_ROUTE オプションをつけ、返送パケット上の経路バッファを表示します。 IP ヘッダには経路を 9 個収める大きさしかないことに注意してください。特定の宛先に対してパケットを経路づけるには、通常 traceroute(8) コマンドを使う方が良いでしょう。不正に偽ったパケットによるなどしてしかるべき経路数よりも大くの経路が帰って来た場合、 ping は経路リストを表示し、正しい位置にまで縮めます。多くのホストは、 RECORD_ROUTE オプションを無視するか捨てます。

-r

通常のルーティングテーブルを無視し、直接接続されているネットワーク上のホストに対して送信します。指定接続されたネットワーク上にホストが存在しない場合には、エラーが返されます。このオプションは経路情報を持たないインタフェースを経由してローカルホストに ping をかけるのに用いられます (たとえばインタフェースが routed(8) によってドロップされた後)。

-S src_addr

引き続いて指定する IP アドレスを、出力パケットの送信元アドレスとして使用します。複数の IP アドレスを持つホストでは、このオプションを使用することにより、プローブパケットを送信するインタフェース以外の送信アドレスを強制可能です。 IP アドレスがこのマシンのインタフェースアドレスではない場合、エラーが返され、送信は行われません。

-s packetsize

送出するデータのバイト数を指定します。デフォルトでは、56 バイトです。これは、 ICMP ヘッダデータの 8 バイトと合せて 64 ICMP バイトになります。スーパユーザのみ、デフォルト値より大きな値を指定可能です。このオプションは、ping sweep と共に使用することができません。

-T ttl

マルチキャストパケットの IP 寿命時間 (Time To Live) を設定します。このオプションは、宛先アドレスがマルチキャストアドレスの場合だけ適用できます。

-t timeout

タイムアウトを、秒単位で指定します。タイムアウトすると、受信パケット数にかかわらず ping は終了します。

-v

冗長出力を有効にします。 ECHO_RESPONSE 以外の受信 ICMP パケットも表示されます。

-W waittime

各パケットの送信のための応答を待つミリ秒単位の時間です。応答が遅れて到着するなら、パケットは応答として印刷 (表示) されませんが、統計を計算するとき、応答とみなします。

-z tos

指定されたタイプのサービスを使用します。

問題の切り分けのために ping を用いるにはローカルインタフェースが up かつ running であることを確認するため、まずローカルホスト上で実行します。その後により遠くのホストやゲートウェイに“ping”します。経路周回時間 (round trip time) と消失パケットの統計が計算されます。重複したパケットが受信された場合、そのパケットは消失パケットの計算には含まれませんが、経路周回時間の統計の計算には使われます。指定されたパケットの数が送信され (受信され) たとき、もしくはプログラムが SIGINT で終了した場合、簡単な要約が表示されます。要約は、送出したパケット数、受信したパケット数、そして経路周回時間の最小/平均/最大/分散です。

ping が SIGINFO シグナル ( stty(1) に対する status 引数を参照) を受信した場合、現時点で送信および受信されたパケット数、経路周回時間の最小/平均/最大/分散を、標準エラー出力に書き込みます。

このプログラムは主にネットワークのテスト、計測、管理に用いられことを想定しています。 ping はそれ自体ネットワークに負荷をかけるので、トラブルのないときや自動スクリプトで用いることは勧められません。

ICMP パケットの詳細

オプションなしの IP ヘッダは、20 バイトです。 ICMP ECHO_REQUEST パケットはさらなる 8 バイトの ICMP ヘッダとそれに続く任意の大きさのデータからなっています。この大きさは、 packetsize によって指定されます (デフォルトでは、56 バイトです)。このように受信した IP パケット内の ICMP ECHO_REPLY データ量は常に指定されたデータ (ICMP ヘッダ) の大きさよりも 8 バイト大きくなります。

データ領域が少なくとも 8 バイトあるとき、 ping は最初の 8 バイトを経路周回時間の計算に用いるタイムスタンプを書くために用います。指定された pad の大きさが 8 バイトより小さい場合経路周回時間は得られません。

重複パケットと障害パケット

ping ユーティリティは重複パケットと障害パケットを報告します。重複パケットはユニキャストアドレスに対しては起こるはずのないものですが、リンク層での不適切な再送信によって引き起こされるようです。重複は様々な状況で起こる可能性があります。低いレベルの重複の存在は必ずしも警告にならないかもしれませんが、よい兆候ではありません。ブロードキャストもしくはマルチキャストアドレスに ping する時には、重複が起こることが期待されます。実際に重複するのではなく、異ったホストから同じ要求に対して応答が行われからです。

障害を受けたパケットは明らかに重大な警告です。多くの場合、 ping パケットの経路のどこか (ネットワーク内かホスト内) のハードウェアの故障が考えられます。

異なったデータパターンの試行

(インター) ネットワーク層はデータ部分に含まれるデータによってパケットの扱いを変えません。不幸にもデータ依存性の問題がネットワークに侵入し長い間検知されないままとなる可能性が知られています。多くの場合、問題を引き起こす特殊なパターンはたとえば全部 1 や全部 0 のようなもの、あるいは右端以外が 0 であるような十分な“遷移”を持たないものです。コマンドラインで (たとえば) 全部 0 のデータパターンを指定するだけでは不十分かもしれません。なぜなら問題のパターンはデータリンク層にあり、コマンドラインで指定したものとコントローラが送信するものとの間の関係は複雑だからです。

このことはデータ依存性が問題となるとき、それを見つけるために多くのテストをしなければならないということを意味します。運がよければ、あるネットワークを通して送れない、あるいは同じような長さのファイルよりもずっと長時間かかるファイルを見つけることができるかもしれません。この場合、そのファイルを調べ繰り返し現われるパターンを ping の -p オプションを使ってテストできます。

TTL の詳細

IP パケットの TTL 値はパケットが捨てられずに通過できる IP ルータの最大数を表わします。今のところインターネット上の各ルータは、 TTL フィールドをちょうど 1 だけ減らすと期待できます。

TCP/IP の仕様では、 IP パケットの TTL フィールドを 64 にすべきと推奨していますが、多くのシステムは、もっと小さい値を用いています ( 4.3BSD では、30、 4.2BSD では、15 を用いています)。

このフィールドに許される最大値は、255 です。そして多くの UNIX システムでは、 ICMP ECHO_REQUEST パケットの TTL フィールドを 255 にしています。これが“ping”は出来るのに telnet(1) や ftp(1) で入れないホストが発生する理由です。

通常 ping は受け取ったパケットの ttl 値を出力します。リモートシステムが ping パケットを受け取るとき、その応答における TTL フィールドに関し以下の 3 つのうちの 1 つを行なうことができます。

• 変更しない;これは、 4.3BSD-Tahoe リリース前の BSD システムが行なっていたことです。この場合、受け取ったパケット中の TTL 値は、255 から周回経路におけるルータの数を引いた数です。
• 255 にセットする;これは現在の BSD システムが行なっていることです。この場合、受け取ったパケット中の TTL 値は、255 から、リモートシステム から ping している ホスト まで の経路におけるルータの数を引いた数となります。
• ある他の値にセットする。マシンによっては 30 あるいは 60 のような TCP パケットで用いるのと同じ値を ICMP パケットに使います。また全く異なる値を用いるマシンもあるかもしれません。

終了ステータス

ping ユーティリティは、次の値の 1 つで終了します:

0

少なくとも 1 つの応答が、指定された host からありました。

2

転送は成功しましたが、応答は、受信されませんでした。

他の値

エラーが起こりました。これらの値は、 < sysexits.h> に定義されています。

関連項目

netstat(1), ifconfig(8), routed(8), traceroute(8)

歴史

ping ユーティリティは、 4.3BSD で登場しました。

作者

オリジナルの ping ユーティリティは、 Mike Muuss が US Army Ballistics Research Laboratory にて記述しました。

バグ

多くのホストやゲートウェイは、 RECORD_ROUTE オプションを無視します。

最大IPヘッダ長は、 RECORD_ROUTE オプションを付加するには小さ過ぎます。しかしながら、これについては出来ることは多くありません。

ping を垂れ流しにするのは、一般に勧められません。特にブロードキャストアドレスに対して ping の垂れ流しを行なうのは、きちんと条件を整えた場合においてのみにとどめるべきです。

-v オプションは忙しいホストではあまり価値がありません。