Ping

このページのゴール

pingを単なる「疎通確認コマンド」として使うのではなく、返ってきた結果からどこまでを直接確認できたかを正しく判断できるようにします。

Pingで重要なのは、成功か失敗かだけではありません。

何を宛先にしたか
↓
どの応答が返ったか
↓
何回成功し、何回失敗したか
↓
往復時間にどのような傾向があるか
↓
その結果だけで何を証明できるか
↓
次にどの確認情報を取るべきか

という順序で考えます。

PingはIP到達性を確認する強力な手掛かりですが、成功してもアプリケーションの正常性までは証明しません。逆に失敗しても、宛先ホスト停止だけが原因とは限りません。

このページで学ぶこと

• ICMP Echo RequestとICMP Echo Replyの関係
• ping <宛先IP>を選ぶ場面
• Cisco IOSの!、.、Uの意味
• 複数試行の結果を1文字ずつ読む方法
• Ping成功が直接証明する範囲
• Ping成功が証明しない範囲
• タイムアウトを原因と混同しない考え方
• Destination Unreachableを原因と混同しない考え方
• Ping失敗の原因が一意ではない理由
• 自インターフェース、デフォルトゲートウェイ、リモートIPへ段階的に確認する方法
• パケットロスの読み方
• 往復時間（RTT）の読み方
• Ping結果と確認コマンド出力を相関する方法
• Pingから次の切り分けへ進む判断方法

Pingの基本目的

Pingは、IPネットワーク上で宛先との到達性を確認するために使います。

Cisco IOSでは基本的に、

ping <宛先IP>

を使います。

例：

R1# ping 192.0.2.10

この確認で中心になるのは、ICMP Echo RequestとICMP Echo Replyです。

ICMP Echo Requestを送信する

Pingを実行すると、送信側は宛先へICMP Echo Requestを送ります。

概念的には、

送信元
  |
  | ICMP Echo Request
  v
宛先

という流れです。

Echo Requestを送信したことだけでは、宛先まで到達したことはまだ確認できません。

ICMP Echo Replyを受信する

宛先がEcho Requestを受信し、応答可能であればICMP Echo Replyが返ることがあります。

送信元
  |--------------------> 宛先
      Echo Request

送信元
  <--------------------| 宛先
       Echo Reply

送信元がEcho Replyを受信できれば、その確認条件ではICMPの往復通信が成立したと判断できます。

Echo Request送信とEcho Reply受信を分けて考える

Ping成功を理解するときは、

Echo Requestを送れた

だけでなく、

Echo Replyを受信できた

ことが重要です。

往路だけ届いて復路が成立しなければ、送信元は成功としてEcho Replyを確認できません。

Ping成功が直接確認するもの

Echo Replyを受信できた場合、直接確認できるのは、

その確認条件で
ICMP Echoの往復通信が成立した

ということです。

ここでいう「その確認条件」には、実行した装置、宛先IP、実行時点のネットワーク状態などが含まれます。

Ping成功はIP到達性の確認情報

Ping成功は、少なくともその時点でICMP Echoの往復が成立したというIP到達性の確認情報になります。

Ping成功
↓
ICMP Echo Request送信
↓
Echo Reply受信
↓
その条件で往復到達性あり

と読みます。

Ping成功はすべての通信成功を意味しない

Pingが成功しても、

Webアクセス成功
SSH接続成功
DNS名前解決成功
データベース接続成功
利用者認証成功

まで自動的に証明されるわけではありません。

Pingで使うICMPと、各アプリケーションが使う通信は分けて考えます。

HTTPS失敗中でもPingは成功し得る

例：

ping 192.0.2.20
→ 成功

HTTPS
→ 接続失敗

この結果は矛盾ではありません。

Pingから確認できるのはICMP到達性です。

HTTPS側は、

TCP接続
ポート
サービス状態
アプリケーション設定

などを別に確認する必要があります。

Ping成功だけで障害なしと判断しない

障害申告：

Web画面が開かない

確認：

ping 192.0.2.20
→ 成功

この時点で、

ネットワークもアプリケーションもすべて正常

とは判断しません。

正しくは、

ICMP往復は成立
↓
アプリケーション側の追加確認へ進む

です。

Cisco IOSのPing結果を1文字ずつ読む

Cisco IOSのPingでは、各試行の結果が記号で表示されることがあります。

このページで重要な記号は、

!
.
U

です。

1つの文字が1回の試行結果を表すと考えると、複数回の結果を読みやすくなります。

!はEcho Reply受信

Cisco IOSのPing結果で、

!

はEcho Replyを受信した成功試行を示します。

例：

!!!!!

なら、表示された5回の試行はすべてEcho Replyを受信したと読めます。

.は試行のタイムアウト

Cisco IOSのPing結果で、

.

は、その試行でタイムアウトまで期待する応答を受信できなかったことを示します。

重要なのは、

.
=
宛先ホスト停止

ではないことです。

.が直接示すのはタイムアウトです。

UはDestination Unreachable受信

Cisco IOSのPing結果で、

U

はICMP Destination Unreachableを受信したことを示します。

これは単なる無応答とは異なります。

.
→ 期待する応答をタイムアウトまで受信できなかった

U
→ Destination Unreachableを受信した

と区別します。

!、.、Uの比較

まず直接観測した事実を読み、原因は追加確認で絞ります。

!!!!!を読む

例：

R1# ping 192.0.2.10

!!!!!

読み方：

試行 1 → Echo Reply
試行 2 → Echo Reply
試行 3 → Echo Reply
試行 4 → Echo Reply
試行 5 → Echo Reply

したがって、この実行では表示された試行がすべて成功しています。

!!.!!を読む

例：

!!.!!

1文字ずつ読むと、

! → 成功
! → 成功
. → タイムアウト
! → 成功
! → 成功

です。

つまり、

成功 4
タイムアウト 1

と判断します。

混在した結果をまとめて成功扱いしない

!!.!!のような結果を見て、

最後が!だから正常

とは判断しません。

一部タイムアウトが発生していること自体が重要な確認情報です。

.U.!!を読む

例：

.U.!!

読み方：

. → タイムアウト
U → Destination Unreachable
. → タイムアウト
! → Echo Reply
! → Echo Reply

同じPing実行の中でも異なる結果が混在することがあります。

各文字を別々の観測結果として読みます。

すべて.の場合

例：

.....

この結果から直接言えるのは、

各試行で期待する応答をタイムアウトまで受信できなかった

ということです。

ここから、

宛先停止確定

へ飛躍してはいけません。

タイムアウトは原因名ではない

.は結果であり、原因を一意に示す値ではありません。

タイムアウトの候補には、状況に応じて、

ローカル側のインターフェース状態
近隣解決
経路
デフォルトゲートウェイ
途中経路
フィルタリング
復路
宛先側の状態

などがあります。

どれが原因かは追加確認で判断します。

Ping失敗の原因は一意ではない

Ping失敗を見たときに、

Ping失敗
↓
宛先ホスト停止

という1本の原因だけに結び付けてはいけません。

正しくは、

Ping失敗
↓
複数の原因候補
↓
追加確認
↓
原因候補を絞る

と進めます。

往路だけでなく復路も必要

Echo Replyを受信するには、送信したEcho Requestが宛先へ届くだけでは足りません。

送信元
→ 宛先

の往路と、

宛先
→ 送信元

の復路の両方が成立する必要があります。

そのため、Ping失敗を往路障害だけと決め付けません。

フィルタリングでもPingは失敗し得る

ネットワークや装置の条件によってICMPが許可されていなければ、IP経路が存在していてもPingが成功しないことがあります。

したがって、

Ping失敗
=
ルーティング経路なし

とも限りません。

近隣解決の問題でもPingは失敗し得る

同一リンク上の次ホップへフレームを送るために必要な近隣解決が成立しなければ、Ping成功まで進めない場合があります。

このときはPing結果だけでなく、

show arp

などの確認情報を組み合わせます。

インターフェース状態でもPing結果が変わる

送信に必要なインターフェースが使用できない状態なら、到達性にも影響します。

代表的な確認：

show ip interface brief
show interfaces

Ping失敗時は、まずローカル側の基本状態を確認する価値があります。

経路情報でもPing結果が変わる

宛先へ向かう適切な経路がなければ、期待する到達性は得られません。

代表的な確認：

show ip route

または宛先を指定して、

show ip route 192.0.2.10

のように確認します。

Uは応答を受信している

.とUの大きな違いは、

.
→ タイムアウト

U
→ ICMP Destination Unreachable受信

という点です。

Uでは、何らかの装置から明示的な到達不能通知を受信しています。

Uを宛先停止と決めない

Destination Unreachableは、

誰が返したか
どの到達不能条件か
その時点の経路やインターフェース状態はどうか

などを追加確認して解釈します。

Uだけで、

宛先ホスト自身が停止

と確定しません。

Uと.を同じ失敗として潰さない

どちらもPing成功ではありませんが、観測事実が異なります。

.
→ 期待応答なしでタイムアウト

U
→ 到達不能通知を受信

違いを残したまま次の切り分けへ進みます。

Pingの結果は実行時点の確認情報

Pingが成功したとしても、それは永久に到達可能であることを保証しません。

12:00 → Ping成功
12:30 → 障害発生

は十分にあり得ます。

Ping結果は実行した時点の確認情報として扱います。

1回の成功だけで傾向を決めない

一時的なパケットロスがある環境では、1回だけ成功しても安定性までは分かりません。

複数試行の結果を見て、

成功数
失敗数
ロス率
RTT

を確認します。

1回の失敗だけで恒久障害と決めない

逆に、1回タイムアウトしただけで、

常に通信不能

と判断するのも早すぎます。

再現性や時間変化、他の確認情報と組み合わせます。

パケットロスは結果傾向として読む

複数回のPingで一部試行が失敗した場合、パケットロスとして結果傾向を確認できます。

例：

Success rate is 80 percent (4/5)

なら、表示された5回のうち4回が成功したと読みます。

80%成功を100%成功と扱わない

Success rate is 80 percent (4/5)

は、

完全成功

ではありません。

成功試行と失敗試行が混在した結果として扱います。

2% ロスだけで原因を決めない

例：

100回の確認
→ 2% ロス

この結果は、

一部の試行が失われた

という傾向を示します。

しかし、

ケーブル故障確定
特定ルータ故障確定
輻輳確定

のような原因確定まではできません。

ロスは時間変化と相関する

パケットロスを見るときは、

常に発生するか
特定時間帯だけか
負荷時だけか
特定宛先だけか

などの傾向を確認します。

さらにインターフェースカウンタなどと相関します。

RTTは往復時間

Ping出力では、往復時間を確認できる場合があります。

例：

round-trip min/avg/max = 2/4/9 ms

ここでは、

min
avg
max

という往復時間の傾向を確認できます。

RTTが高いだけで原因を断定しない

以前よりRTTが高くなっていても、

特定ルータ故障確定
デュプレックス不一致確定

とは判断しません。

RTT変化は追加確認の入口です。

RTTは基準値との比較が重要

単発の値だけを見るより、

平常時
障害時
時間帯
宛先

を比較すると判断しやすくなります。

例：

平常時平均 3 ms
障害時平均 80 ms

なら変化は確認できますが、その原因は別途切り分けます。

min、avg、maxを原因名に置き換えない

RTTの、

min
avg
max

は測定結果です。

それ自体が、

回線障害
CPU高騰
輻輳

などの原因名ではありません。

Ping成功とRTTを分けて読む

Pingが成功していてもRTTが大きく変動する場合があります。

したがって、

成功したか

と、

どの程度のRTTだったか

は別の観点として読みます。

段階的にPingする目的

リモートIPへのPingが失敗したとき、最終宛先だけを何度も試すより、近い地点から段階的に確認すると範囲を絞りやすくなります。

基本イメージ：

自インターフェース
↓
デフォルトゲートウェイ
↓
リモートIP

各段階の結果を比較します。

自インターフェースへのPing

装置自身が持つIPアドレスへPingすることで、ローカルのIP設定やスタックに関する確認情報を得られます。

ただし、自分自身のIPへのPing成功は、

物理回線を通過した
対向装置まで届いた

ことを証明しません。

確認範囲を正しく限定します。

自分自身へのPing成功の証拠限界

自分のインターフェースIPへPing成功：

ping <自インターフェースIP>
→ 成功

この結果から、

デフォルトゲートウェイ到達可能
リモートネットワーク到達可能

とは言えません。

次の段階へ進みます。

デフォルトゲートウェイへのPing

端末や装置から外部ネットワークへ進む場合、デフォルトゲートウェイへの到達性は重要です。

ping <デフォルトゲートウェイIP>

が成功すれば、その確認条件でローカル側からゲートウェイまでのICMP往復が成立したと判断できます。

デフォルトゲートウェイ成功はその先の成功を証明しない

デフォルトゲートウェイまでPing成功しても、

リモートIPまで到達可能

とはまだ証明できません。

確認できた範囲は、

ローカル側
↔
デフォルトゲートウェイ

までです。

デフォルトゲートウェイ失敗時はローカル範囲を優先確認

デフォルトゲートウェイへのPingが失敗した場合は、まず近い範囲の確認情報を取ります。

代表例：

show ip interface brief
show interfaces
show arp
show ip route

ここで、

インターフェース
IP設定
近隣解決
経路

などを確認します。

リモートIPへのPing

デフォルトゲートウェイまで成功した後、リモートIPへPingします。

ping 192.0.2.10

ここで失敗した場合、

ローカルからゲートウェイまでは成立
リモートIPへのPingは不成立

という2つの確認情報を分けて保持します。

デフォルトゲートウェイ成功、リモート失敗の読み方

例：

自インターフェース → 成功
デフォルトゲートウェイ → 成功
リモートIP → 失敗

直接言えるのは、

少なくともゲートウェイまでのICMP往復は成立
リモートIPへのICMP往復は成立していない

ということです。

ゲートウェイ以降の全ルータが停止

とは言えません。

段階的確認は原因確定ではなく範囲絞り込み

段階的Pingの目的は、

どこまで到達できたか

を比較することです。

到達できなくなった境界が見えても、その境界だけで根本原因を確定せず、該当範囲の状態を追加確認します。

最終宛先だけを繰り返さない

リモートIPへ失敗したとき、

ping <リモートIP>
ping <リモートIP>
ping <リモートIP>

だけを繰り返しても、原因候補を十分に絞れない場合があります。

近い地点と内部状態の確認を組み合わせます。

Pingとshow ip interface briefを組み合わせる

Ping失敗時に、

show ip interface brief

を確認すると、ローカルインターフェースのIPアドレスと基本状態を確認できます。

Pingの到達性結果とローカルL3状態を別々に確認します。

Pingとshow interfacesを組み合わせる

show interfaces

では、より詳細なインターフェース状態やカウンタを確認できます。

Pingでロスが見える場合に、

input errors
CRC

などのカウンタ傾向が関連しているかを追加確認できます。

ただし、カウンタ値があるだけで原因を即断しません。

Pingとshow arpを組み合わせる

デフォルトゲートウェイなど同一リンク上の相手へ届かない場合、

show arp

で近隣解決の状態を確認することがあります。

Ping失敗と近隣解決状態を相関し、原因候補を絞ります。

Pingとshow ip routeを組み合わせる

リモート宛先へ届かない場合、

show ip route

で経路情報を確認します。

宛先を限定する場合は、

show ip route 192.0.2.10

のように確認できます。

Ping失敗だけで「経路なし」と決めず、実際の経路情報を確認します。

Pingとログを組み合わせる

Ping失敗と同じ時刻付近にインターフェース状態変化などが記録されている場合、ログも確認情報になります。

ただし、

Ping失敗
+
リンク状態変化ログ

があっても、必要に応じて現在状態やカウンタなどを確認して原因仮説を検証します。

Ping成功後にアプリケーション確認へ進む

障害対象がWebやSSHなどの場合、

Ping成功

でIP到達性を確認した後は、アプリケーションが使うプロトコルやサービス側を確認します。

Ping成功をゴールにせず、障害症状に必要な確認へ進みます。

Ping失敗時の基本切り分け順序

一例：

1. 宛先IPが正しいか確認
2. ローカルインターフェース状態を確認
3. 近い宛先へPing
4. デフォルトゲートウェイへPing
5. リモートIPへPing
6. ARPや経路情報を確認
7. フィルタリングや復路も候補にする
8. ロスやRTTの傾向を確認
9. 他の確認情報と相関
10. 原因仮説を検証

Pingだけで完結させず、次の確認へつなげます。

タイムアウト時の切り分け

結果：

.....

考え方：

タイムアウトを確認
↓
近い宛先でも失敗するか
↓
ローカル状態を確認
↓
近隣解決を確認
↓
経路を確認
↓
フィルタリングや復路を候補にする

タイムアウトを原因名にしないことが重要です。

U受信時の切り分け

結果：

UUUUU

考え方：

Destination Unreachable受信
↓
到達不能通知が返っている
↓
経路や送信元周辺の状態を確認
↓
原因を追加情報で絞る

Uと無応答を同じ扱いにしません。

一部ロス時の切り分け

結果：

!!.!!

考え方：

4回成功
1回タイムアウト
↓
完全な到達不能ではない
↓
ロスの再現性を確認
↓
インターフェースカウンタや時間変化と相関

1回だけの結果で原因を決めません。

高RTT時の切り分け

結果例：

round-trip min/avg/max = 2/70/180 ms

以前より大きい場合：

複数回確認
↓
時間帯や宛先を比較
↓
装置状態やインターフェース状態と相関

高RTTだけで特定原因を断定しません。

シナリオ1：Pingが使うICMPメッセージ

問い：

Pingが基本的に使用するICMPメッセージは何か

判断：

ICMP Echo Request
ICMP Echo Reply

です。

シナリオ2：Echo Reply受信で直接分かること

状況：

Echo Request送信
Echo Reply受信

判断：

その確認条件でICMP往復が成立した

です。

HTTPやすべてのTCPポートまで正常とは言えません。

シナリオ3：!の意味

出力：

!

判断：

Echo Replyを受信した

です。

シナリオ4：!!.!!

出力：

!!.!!

判断：

4回成功
1回タイムアウト

です。

シナリオ5：.の意味

出力：

.

判断：

その試行でタイムアウトまで期待応答を受信しなかった

です。

シナリオ6：.....の次の行動

出力：

.....

判断：

タイムアウトを確認情報として保持
↓
インターフェース
経路
近隣解決
フィルタリング
復路
宛先
などを追加確認

です。

宛先停止と即断しません。

シナリオ7：Uの意味

出力：

U

判断：

ICMP Destination Unreachableを受信した

です。

シナリオ8：U受信後

Uを確認した後は、

誰が到達不能を返しているか
経路はどうなっているか
インターフェース状態はどうか

などの追加確認へ進みます。

宛先ホスト停止確定

とは判断しません。

シナリオ9：リモートIPへのPing成功

状況：

リモートIPへPing
→ 成功

直接証明できるのは、

その送信条件と宛先条件でICMP Echo往復が成立

という範囲です。

シナリオ10：Ping成功、HTTPS失敗

状況：

Ping
→ 成功

HTTPS
→ 失敗

判断：

ICMP到達性は成立
アプリケーション側は追加確認

です。

シナリオ11：Ping成功が証明しないもの

Ping成功だけでは、

アプリケーションサービスの正常性

を証明しません。

Echo Reply受信とアプリケーション応答を混同しないことが重要です。

シナリオ12：Ping失敗の原因候補

Ping失敗には、

往路
復路
フィルタリング
近隣解決
経路
宛先状態
ローカル状態

など複数候補があります。

1つに固定しません。

シナリオ13：段階的にPingする

順序：

自インターフェース
↓
デフォルトゲートウェイ
↓
リモートIP

目的：

どこまでICMP到達性が成立しているか比較する

ことです。

シナリオ14：デフォルトゲートウェイ成功、リモート失敗

結果：

デフォルトゲートウェイ
→ 成功

リモートIP
→ 失敗

直接言えること：

ローカルからゲートウェイまでのICMP往復は成立

です。

その先の原因は追加確認が必要です。

シナリオ15：100回中2% ロス

結果：

100回のうち一部失敗

判断：

ロス傾向として記録
↓
時間変化
再現性
インターフェースカウンタ
他の確認情報
と相関

です。

2%という数値だけで正常、異常、原因を一意に決めません。

シナリオ16：RTT上昇

結果：

以前よりRTTが高い

判断：

複数試行
平常時との比較
装置状態
経路条件
インターフェース状態

などと相関します。

高RTTだけで特定故障を断定しません。

シナリオ17：Ping失敗後の確認コマンド

Ping失敗後に確認コマンドを使う目的は、

Pingだけでは分からない
インターフェース
ARP
経路

などの内部状態を確認するためです。

例：

show ip interface brief
show interfaces
show arp
show ip route

です。

シナリオ18：デフォルトゲートウェイへのPing失敗後

デフォルトゲートウェイへのPingが失敗した場合、

show ip interface brief
show arp

などを確認して、

ローカルL3状態
近隣解決

を追加確認します。

Pingと無関係な情報ではありません。

よくある誤り

!を単に「ネットワーク正常」と読む

!が直接示すのはEcho Reply受信です。

ネットワーク全体やアプリケーション全体の正常性まで広げません。

.を宛先停止と読む

.は試行のタイムアウトです。

宛先停止は原因候補の1つにすぎません。

UをEcho Reply成功と読む

UはDestination Unreachable受信です。

!と区別します。

途中に.があっても最後が!なら全部成功と考える

複数文字は各試行の結果です。

!!.!!なら1回タイムアウトしています。

Ping成功でWebサービスも正常と考える

PingはICMP到達性を確認します。

アプリケーションは別に確認します。

Ping失敗で経路なしと断定する

経路以外にも複数の原因候補があります。

実際の経路情報を確認します。

デフォルトゲートウェイ成功でリモートも到達可能と考える

デフォルトゲートウェイまでの成功は、その先の到達性を証明しません。

確認範囲を限定します。

リモート失敗でデフォルトゲートウェイ以降がすべて停止と考える

最終宛先への失敗だけでは、どの地点が原因か一意に決まりません。

追加確認します。

ロスが少ないから必ず正常と考える

ロス率は結果傾向です。

求められる品質や再現性と合わせて評価します。

ロスが1回でもあれば物理故障確定と考える

単発ロスだけで物理故障は確定できません。

カウンタや再現性と相関します。

RTT上昇だけで特定原因を決める

RTTは結果です。

原因は他の確認情報で絞ります。

同じPingだけを繰り返す

再現性確認には意味がありますが、原因切り分けには他の確認情報も必要です。

問題での判断パターン

パターン1：ICMPメッセージを問われる

Echo Request
Echo Reply

を選びます。

パターン2：Echo Replyで何を証明できるか

その条件でICMP往復が成立

までです。

パターン3：!

Echo Reply受信

です。

パターン4：!!.!!

成功4
タイムアウト1

です。

パターン5：.

試行のタイムアウト

です。

パターン6：.....

タイムアウトを確認情報として
追加切り分け

です。

パターン7：U

Destination Unreachable受信

です。

パターン8：Uの次

到達不能通知の送信元や経路を追加確認

です。

パターン9：Ping成功の証拠範囲

ICMP Echo往復

までです。

パターン10：Ping成功、アプリケーション失敗

ICMPとアプリケーションを分離

します。

パターン11：Ping成功が証明しないもの

アプリケーションサービス正常性

です。

パターン12：Ping失敗の原因

複数候補

と考えます。

パターン13：段階的Ping

自インターフェース
↓
デフォルトゲートウェイ
↓
リモートIP

で到達範囲を絞ります。

パターン14：デフォルトゲートウェイ成功、リモート失敗

デフォルトゲートウェイまでのICMP往復成立
その先は未確定

です。

パターン15：パケットロス

結果傾向
他の確認情報と相関

です。

パターン16：RTT上昇

複数試行
基準値
装置状態

と相関します。

パターン17：Ping後の確認コマンド

Pingだけで分からない内部状態を確認

するために使います。

パターン18：デフォルトゲートウェイ失敗とshow arp

ローカルL3状態
近隣解決

を追加確認します。

Ping切り分けの基本フロー

症状を確認
↓
宛先IPを確認
↓
pingを実行
↓
! / . / U を読む
↓
成功数と失敗数を見る
↓
ロスとRTTを見る
↓
近い宛先から段階的に比較
↓
インターフェース状態を確認
↓
ARPを確認
↓
経路を確認
↓
フィルタリングと復路も候補にする
↓
原因仮説を立てる
↓
別の確認情報で検証

この順序にすると、Pingの結果だけで原因を飛躍して決めにくくなります。

Ping結果を「証拠」と「推測」に分ける

例：

観測
→ デフォルトゲートウェイへのPing成功

直接言えること
→ デフォルトゲートウェイまでのICMP往復成立

まだ推測
→ その先のすべての経路も正常

この区別がトラブルシューティングでは重要です。

成功結果も証拠限界を持つ

成功は有用な確認情報ですが、

Ping成功

から証明できる範囲を超えて、

TCP正常
アプリケーション正常
認証正常
すべての経路装置正常

へ広げません。

失敗結果も証拠限界を持つ

失敗も有用な確認情報ですが、

Ping失敗

から、

宛先停止
経路なし
物理障害

のどれか1つへ即断しません。

切り分けで重要な考え方

Pingは原因そのものではなく、原因を絞るための確認手段です。

Ping結果
↓
直接分かる事実
↓
分からない部分
↓
次の確認

という流れで使います。

運用確認の観点

Pingを運用確認で使うときは、最低限次を残すと比較しやすくなります。

確認時刻
送信元装置
宛先IP
成功率
表示記号
ロス
RTT
同時点のインターフェース状態
経路状態
近隣解決状態

後から結果を比較するときに役立ちます。

正常系の例

R1# ping 192.0.2.10

!!!!!
Success rate is 100 percent (5/5)
round-trip min/avg/max = 2/3/5 ms

読み方：

表示された5試行すべてEcho Reply受信
ICMP往復成立
この実行ではロスなし
RTT結果あり

ただしアプリケーション正常までは証明しません。

一部失敗の例

R1# ping 192.0.2.10

!!.!!
Success rate is 80 percent (4/5)

読み方：

4試行成功
1試行タイムアウト
一部ロスあり

次に再現性と他の確認情報を確認します。

タイムアウトの例

R1# ping 192.0.2.10

.....
Success rate is 0 percent (0/5)

読み方：

表示された試行はすべてタイムアウト

原因はまだ未確定です。

Destination Unreachableの例

R1# ping 192.0.2.10

UUUUU

読み方：

各試行でDestination Unreachableを受信

無応答とは区別し、経路や到達不能通知の発生元などを追加確認します。

現在状態との相関

Ping結果と現在の装置状態を組み合わせます。

例：

デフォルトゲートウェイへのPing
→ 失敗

show ip interface brief
→ 該当インターフェースがdown

この2つの確認情報から、ローカル側インターフェース状態が到達性へ影響している仮説を強められます。

ARPとの相関

例：

デフォルトゲートウェイへのPing
→ 失敗

show arp
→ デフォルトゲートウェイに対応するエントリを確認できない

この場合、近隣解決の確認を深めます。

ただし、ARPエントリがないという事実だけで根本原因を確定しません。

経路との相関

例：

リモート Ping
→ 失敗

show ip route 192.0.2.10
→ 期待する経路を確認できない

Ping失敗と経路情報を相関し、経路に関する原因仮説を検証します。

インターフェースカウンタとの相関

例：

Ping
→ 一部ロス

show interfaces
→ エラーカウンタが増加

この組み合わせは追加調査の根拠になります。

ただし、カウンタ増加の種類と時間変化を確認して原因を絞ります。

切り分け結果を一文で表現する

良い表現：

デフォルトゲートウェイまではICMP往復が成立しているが、
リモートIPへのPingはタイムアウトする。
そのため、ゲートウェイ以降の経路、復路、フィルタリング、
宛先側状態を追加確認する。

悪い表現：

リモートサーバが壊れている。

確認できた範囲と未確認範囲を分けます。

まとめ

PingはICMP Echo Requestを送り、Echo Replyなどの結果からIP到達性を確認する基本手段です。

Cisco IOSの代表記号は、

!
→ Echo Reply受信

.
→ 試行のタイムアウト

U
→ Destination Unreachable受信

です。

Ping成功から直接言えるのは、

その確認条件でICMP Echo往復が成立した

という範囲です。

アプリケーション正常性までは証明しません。

Ping失敗も、

往路
復路
近隣解決
経路
フィルタリング
宛先状態
ローカル状態

など複数の原因候補を持つため、一意に原因を決めません。

切り分けでは、

自インターフェース
↓
デフォルトゲートウェイ
↓
リモートIP

と段階的に確認し、

show ip interface brief
show interfaces
show arp
show ip route

などの確認情報を相関します。

ロスやRTTも原因名ではなく結果傾向として扱い、

Pingで直接分かること
Pingだけでは分からないこと
次に確認すること

を常に分けて判断します。