PING(8) FreeBSD システム管理者マニュアル PING(8)
名称
ping − ICMP ECHO_REQUEST パケットをネットワーク上のホストへ送る |
書式
ping [−AaDdfnoQqRrv] [−c count] [−i wait] [−l preload] [−M mask | time] [−m ttl] [−P policy] [−p pattern] [−S src_addr] [−s packetsize] [−t timeout] [−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] [−z tos] mcast-group |
解説 |
ping ユーティリティは、 ICMP の ECHO_REQUEST データグラムを用いて、指定し たホストやゲートウェイからの ICMP ECHO_RESPONSE を引き出します。 ECHO_REQUEST データグラム (‘‘ping’’) には IP および ICMP ヘッダ、 ‘‘struct timeval’’ 、パケットの残りを埋める適当な数の ‘‘pad’’ バイトが順 にあります。オプションは以下の通りです: |
−A
聴覚モード。次のパケットを送信する前にパケットを受け取らないと、 ベル (ASCII 0x07) 文字を出力します。送信間隔よりも往復時間が長い 場合のために、未受信パケット数の最大値を増加させた場合のみ、それ を越えて喪失したパケットがベルを鳴らします。 −a −c count −D −d −f −I interface −i wait −L −l preload −M −m ttl −n −o −P policy −p pattern −Q −q −R −r −S src_addr −s packetsize −T ttl −t timeout −v −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 の仕様では TCP パケットの 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 ユーティリティは、指定した host から少なくとも 1 回の応答を受信した 場合、終了値 0 を返します; 送出は成功したものの応答を受信できない場合は 2 を返します; エラーが発生した場合は、他の値 (<sysexits.h> が返されます。 |
関連項目
歴史
ping ユーティリティは 4.3BSD から登場しました。 |
作者
オリジナルの ping ユーティリティは、 Mike Muuss が US Army Ballistics Research Laboratory にて記述しました。 |
バグ
多くのホストやゲートウェイは、 RECORD_ROUTE オプションを無視します。 最大IPヘッダ長は、 RECORD_ROUTE オプションを付加するには小さ過ぎます。し かしながら、これについては出来ることは多くありません。 ping を垂れ流しにするのは、一般に勧められません。特にブロードキャストアド レスに対して ping の垂れ流しを行なうのは、きちんと条件を整えた場合におい てのみにとどめるべきです。 FreeBSD 10.0 October 2, 2002 FreeBSD 10.0 |