ping・tracerouteでネットワーク障害を切り分ける方法を実践解説

ここまでのネットワーク中級講座では、 L2 Switch、VLAN、Routing、NAT、ACL、Firewall、冗長化など、 Network通信を構成するさまざまな仕組みを学習してきました。

しかし実際の運用では、 知識を覚えるだけではなく、 「通信できないときに、どこに問題があるのかを調べる」 力が必要になります。

そこで障害箇所を絞り込むために利用される代表的なコマンドが、 pingと traceroute / tracertです。

ネットワーク障害は「切り分け」が重要

「Webサイトへ接続できない」 という現象だけを見ても、 原因は1つとは限りません。

pingとは？

pingは、 指定した宛先までIP通信できるかを確認する代表的なコマンド です。

一般的にはICMP Echo Requestを送信し、 相手からICMP Echo Replyが返ってくるか確認します。

pingを実行してみよう

Windowsでは次のように実行できます。

C:\> ping 192.168.20.10

192.168.20.10 に ping を送信しています 32 バイトのデータ:
192.168.20.10 からの応答: バイト数=32 時間=3ms TTL=126
192.168.20.10 からの応答: バイト数=32 時間=2ms TTL=126

Linuxでは同じように、

$ ping 192.168.20.10

64 bytes from 192.168.20.10: icmp_seq=1 ttl=62 time=2.4 ms
64 bytes from 192.168.20.10: icmp_seq=2 ttl=62 time=2.1 ms

と確認できます。

pingはどこから確認すればよい？

いきなり遠くのServerだけにpingするのではなく、 近い場所から順番に確認する と障害範囲を絞りやすくなります。

例：Default GatewayまではpingできるがServerへ届かない

C:\> ping 192.168.10.1

Reply from 192.168.10.1: bytes=32 time<1ms TTL=255

C:\> ping 192.168.20.10

Request timed out.
Request timed out.

この場合、 少なくともPCからDefault Gatewayまでは通信できています。

次に、 Gatewayより先のどこまで通信が進んでいるか を確認したくなります。

そこで利用するのが tracerouteです。

tracerouteとは？

tracerouteは、 宛先までに経由するRouterを確認するための代表的なコマンド です。

Windowsでは tracert、 Linuxなどでは traceroute を利用するのが一般的です。

tracertの結果を見てみよう

C:\> tracert 192.168.20.10

  1    <1 ms    <1 ms    <1 ms   192.168.10.1
  2     2 ms      2 ms      2 ms   10.0.0.2
  3     3 ms      3 ms      3 ms   192.168.20.10

Trace complete.

この結果なら、

という経路を通っていることが分かります。

tracerouteはどうやって経由Routerを調べる？

tracerouteでは、 IP Headerにある TTL（Time To Live） を利用します。

TTLを少しずつ増やしながらPacketを送ることで、 途中のRouterを順番に確認できます。

tracerouteの「* * *」は何を意味する？

障害調査でよく見るのが、 次のような結果です。

C:\> tracert 192.168.20.10

  1    <1 ms    <1 ms    <1 ms   192.168.10.1
  2     2 ms      2 ms      2 ms   10.0.0.2
  3     *         *         *      Request timed out.
  4     4 ms      4 ms      4 ms   192.168.20.10

上の例ではHop 3が応答していませんが、 Hop 4のDestinationまで到達しています。

そのため、 Hop 3で通信が止まっているわけではありません。

本当に途中で通信が止まっている例

C:\> tracert 192.168.20.10

  1    <1 ms    <1 ms    <1 ms   192.168.10.1
  2     2 ms      2 ms      2 ms   10.0.0.2
  3     *         *         *      Request timed out.
  4     *         *         *      Request timed out.
  5     *         *         *      Request timed out.

Hop 2までは応答していますが、 その先から継続して応答がありません。

この場合は、 R2より先のRoute、Link、Firewall、宛先側Networkなどを 調べるきっかけになります。

pingが通らない＝通信不能とは限らない

これは障害切り分けで非常に重要です。

pingはICMPを利用しますが、 Network機器やServer側で ICMP Echoを拒否している 場合があります。

この場合、 pingは失敗してもWeb通信自体は正常です。

IP Addressなら通るのにHostnameでは失敗する場合

次のケースを考えてみましょう。

C:\> ping 192.168.20.10

Reply from 192.168.20.10

C:\> ping server.example.com

Ping request could not find host server.example.com.

IP Address宛てでは通信できています。

そのためNetwork経路そのものより、 DNS名前解決 に問題がある可能性が高くなります。

通信できないときの基本的な切り分けフロー

ここで実際に試してみよう：障害切り分けシミュレーター

Scenarioを選び、 疑似Terminalでpingやtracerouteを実行して 障害箇所を推測してみましょう。

理解度チェック：この結果からどこを調べる？

C:\> ping 192.168.10.1

Reply from 192.168.10.1

C:\> ping 192.168.20.10

Request timed out.

C:\> tracert 192.168.20.10

1  192.168.10.1
2  10.0.0.2
3  * * *
4  * * *

WindowsとLinuxでよく使う確認コマンド

実務では「OSI参照モデルを逆引き」すると考えやすい

障害切り分けでは、 これまで学習してきたNetwork知識がつながります。

たとえば、

障害切り分けで覚えておきたい3つの考え方

確認問題：障害切り分けの基本を理解できたか確認しよう

まとめ