PINGを使用してネットワークをチェックする

オペレーティング オペレーティング オペレーティング

オペレーティング・システム・システム・システム・システム ヘルプを呼び出すコマンドヘルプを呼び出すコマンドヘルプを呼び出すコマンドヘルプを呼び出すコマンド

UNIX man ping

Windows ping -?

UNIXの場合、構文はベンダーごとに異なります。

たとえば、Solarisでは次のようになります。

ping -s <ホスト名> 1472 90

7.2.2 サンプル出力サンプル出力サンプル出力サンプル出力

PINGコマンドは次のような行を返します。

# ping -s ukp14901.uk.oracle.com 1472 10 PING ukp14901.uk.oracle.com: 1472 data bytes

1480 bytes from ukp14901.uk.oracle.com (138.3.65.126): icmp_seq=0. time=264. Ms 1480 bytes from ukp14901.uk.oracle.com (138.3.65.126): icmp_seq=1. time=211. Ms 1480 bytes from ukp14901.uk.oracle.com (138.3.65.126): icmp_seq=2. time=227. Ms 1480 bytes from ukp14901.uk.oracle.com (138.3.65.126): icmp_seq=3. time=212. Ms 1480 bytes from ukp14901.uk.oracle.com (138.3.65.126): icmp_seq=4. time=210. Ms 1480 bytes from ukp14901.uk.oracle.com (138.3.65.126): icmp_seq=5. time=212. ms 1480 bytes from ukp14901.uk.oracle.com (138.3.65.126): icmp_seq=6. time=225. ms 1480 bytes from ukp14901.uk.oracle.com (138.3.65.126): icmp_seq=7. time=212. ms 1480 bytes from ukp14901.uk.oracle.com (138.3.65.126): icmp_seq=8. time=232. ms 1480 bytes from ukp14901.uk.oracle.com (138.3.65.126): icmp_seq=9. time=255. ms

----ukp14901.uk.oracle.com PING

Statistics----10 packets transmitted, Statistics----10 packets received, 0% packet loss round-trip (ms) min/avg/max = 210/226/264

損失パケットが大量にあると、応答時間が非常に遅くなり、パケットの受信順序が狂うと、ネットワークに障 害が発生します。LANでは、ラウンドトリップの所要時間は10ミリ秒以下と極めて短いことが要求されます。

上記の例では、ラウンドトリップ時間が非常に長くなっています。これは、PINGが実行されたマシンがWAN 上にあるからです。マシンに到達するまでに必要なホップ数も多くなっています。tracertについての詳細はセ

クション7.2.3を参照してください。

以下のPINGからの出力は、ネットワーク上に何らかの問題があることを示しています。

C:¥>ping jcarlin-sun -l 1472 -n 90

Pinging jcarlin-sun.us.oracle.com [144.25.80.48] with 1472 bytes of data:

Reply from 144.25.80.48: bytes=1472 time=15ms TTL=253 Reply from 144.25.80.48: bytes=1472 time<10ms TTL=253 Reply from 144.25.80.48: bytes=1472 time<10ms TTL=253 Reply from 144.25.80.48: bytes=1472 time<10ms TTL=253 Request timed out.

Request timed out.

Request timed out.

Request timed out.

Request timed out.

Request timed out.

Request timed out.

Request timed out.

Request timed out.

Request timed out.

Reply from 144.25.80.48: bytes=1472 time<10ms TTL=253 Reply from 144.25.80.48: bytes=1472 time=16ms TTL=253

…

この出力を見ると、要求タイムアウトとパケット損失が多発したために、ピアによる接続のリセットが行われ たものと考えられます。

注：Windows NTでは送受信されたパケットの数やパケット損失率は表示されません。この場合には、次のよ うな式を使用して損失率を計算する必要があります。

パケット損失率（%）=（タイムアウトの回数÷PINGの数）×100 上記の例ではjarlin-sunで90回PINGが実行され、23回失敗しています。

したがって、パケット損失率は次のようになります。

パケット損失率（%）=（23÷90）×100=26%

7.2.3 traceroute / tracertの使用の使用の使用の使用

UNIXシステムのtracerouteは、TCP/IPパケットが1つのマシンから別のマシンに送られるまでに経由したルー トを追跡するユーティリティです。

Windowsでこれに該当するユーティリティがTRACERTです。

以下の出力は、LAN上のマシンとWAN上のマシンでのtracertの結果です。比較してみましょう。

LAN

D:¥>tracert jcarlin-pc.us.oracle.com

Tracing route to jcarlin-pc.us.oracle.com [130.35.96.107]

over a maximum of 30 hops:

1 <10 ms <10 ms <10 ms jcarlin-pc.us.oracle.com [130.35.96.107]

Trace complete.

WAN

D:¥>tracert ukp14901.uk.oracle.com

Tracing route to ukp14901.uk.oracle.com [138.3.65.126]

over a maximum of 30 hops:

1 <10 ms <10 ms <10 ms whq4op3-rtr-744-f2.us.oracle.com [130.35.96.1]

2 <10 ms <10 ms 15 ms whq4op3-rtr-771-f0.us.oracle.com [144.25.252.71]

3 <10 ms 16 ms <10 ms usrtr11-f0-0.us.oracle.com [137.254.20.11]

4 156 ms 172 ms 156 ms ukrtr8-atm5-0-0-1.us.oracle.com [137.254.22.2]

5 156 ms 172 ms 172 ms ukrtr1-f0.us.oracle.com [137.254.1.1]

6 203 ms 297 ms 172 ms bracknell-rtr-2-atm-301.uk.oracle.com [138.3.0.38]

7 172 ms 172 ms 172 ms edinburgh-rtr-1-s0.uk.oracle.com [138.3.1.54]

8 172 ms 188 ms 187 ms ukp14901.uk.oracle.com [138.3.65.126]

Trace complete.

この結果を見れば、当然ながらPINGによって報告されたリターン時間はWAN上のマシンでPINGを実行した 場合の方がかなり高いことが分かります。ネットワーク接続が時々タイミング・アウトするようなら、tracert を使用すれば問題がどこにあるのかを突き止め、調査対象を絞り込むことができます。

7.2.4 netstatの使用の使用の使用の使用

最初のテストで接続が不安定であることが分かったら、netstatを使用すれば有益な情報を得ることができます。

UNIX

# netstat -I

Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis Queue lo0 8232 loopback localhost 965676 0 965676 0 0 0

fddi0 4352 haggis haggis 652193 43 193048 0 0 0

衝突（ Collis ）に表示された値が大きい場合、ネットワークが飽和状態にあると考えられます。この値が5%

以上の場合は、調査してください。

Ieers や Oerrs の値が高い場合は、ネットワークに物理的な問題があることを意味します。この値はゼロ

に近くなければなりません。値が 100以上の場合は、（送信データの量にかかわらず）調査する必要がありま す。

Windowsでもnetstatコマンドを使用できます。ただし、構文は少し異なり、短い要約を入手することはできま

せん。

次のようなコマンドを使用してネットワーク・ステータスに関する情報を入手することができます。

C:¥>netstat -s

7.2.5 問題の追跡問題の追跡問題の追跡問題の追跡

フォームを実行して、FRM-99999エラーがネットワーク上の多数のタイムアウトに合致して発生するかどうか 調べてください。合致する場合は、ネットワークのタイムアウトが問題の原因と考えられます。パケット損失

があるとFormsに問題が発生します。Formsがすぐにクラッシュを起こさなかった場合でも、以降は理解でき

ない問題を受け取ることになるのでFormsが混乱します。

PING、traceroute、ipconfigを併用すれば、どこから調査を始めたら良いかを特定できます。配線に関連する問

題については、電気ケーブル・テスターを使用する必要があります。配線がゆるんでいたり、接続が不完全で あることも考えられます。ハブやスイッチには診断機能が内蔵されているものもありますから、これもチェッ クしてください。問題の原因を特定できない場合は、Protocol Analyzerを使用して原因を絞り込んでいく必要 があります。