Extended Ping

このページのゴール

Extended Pingを、単に「通常Pingより設定項目が多いPing」として覚えるのではなく、送信元条件を明示してL3到達性を比較するための確認手段として使えるようにします。

特に重要なのは、

通常Ping
→ 装置が通常選択する送信元条件で確認

Extended Ping
→ 確認したい送信元アドレス / インターフェースを明示して確認

という違いです。

また、Extended Pingが成功しても、

同じLANのクライアント通信が完全に正常

まで証明できるわけではありません。

このページでは、何を条件として変え、何を比較し、どこまでを証拠として扱えるかを中心に学びます。

このページで学ぶこと

• Extended Pingを使う目的
• 通常Pingとの違い
• 送信元アドレスまたはインターフェースを指定する意味
• 指定する送信元が実行装置で利用可能である必要性
• 往路と復路の到達性
• 送信元別の結果差を使った切り分け
• ルータからのExtended Pingと実クライアント通信の証拠差
• Repeat Countで複数回の結果を見る意味
• Datagram Sizeを変更して結果差を見る意味
• Timeoutを変更して応答待ち条件を見る意味
• 結果差を根本原因と混同しない考え方

Extended Pingとは

Extended Pingは、通常Pingよりも試験条件を細かく指定して到達性を確認するための方法です。

代表的に確認条件として使うものは、

宛先IP
送信元アドレス / インターフェース
Repeat Count
Datagram Size
Timeout

です。

この中でも、切り分けで特に重要なのが送信元条件です。

通常Pingとの基本的な違い

通常Pingでは、宛先を指定して実行します。

ping <宛先IP>

このとき送信元は、装置が通常の経路選択やインターフェース条件に基づいて使用するものになります。

Extended Pingでは、確認したい送信元アドレスや送信元インターフェースを明示して試験できます。

通常Pingの結果だけでは足りない場面

例として、ルータに複数のインターフェースがあるとします。

Loopback0
192.0.2.1

GigabitEthernet0/1
192.168.10.1

GigabitEthernet0/2
192.168.20.1

通常Pingが成功していても、どの送信元条件で成功したかが、実際に確認したい通信条件と一致しているとは限りません。

送信元条件を明示する意味

送信元条件を変えると、宛先は同じでも確認しているL3条件が変わります。

192.0.2.1
→ 198.51.100.10

192.168.10.1
→ 198.51.100.10

192.168.20.1
→ 198.51.100.10

このように同じ宛先へ異なる送信元から確認すると、送信元サブネットに依存して結果が変わるかを比較できます。

Extended Pingの中心は送信元指定

Extended Pingには複数の調整項目がありますが、切り分けで最も重要な追加条件の1つは、

送信元アドレス / インターフェース

です。

Repeat CountやDatagram Size、Timeoutは試験条件を追加で調整するために使います。

送信元アドレスを指定する

考え方の例：

宛先IP
198.51.100.10

送信元アドレス
192.168.10.1

この条件で成功した場合、

192.168.10.1を送信元にしたICMP Echoの往復

が成立したと判断します。

送信元インターフェースを指定する

送信元条件は、装置上のインターフェースを基準に指定する考え方もあります。

例：

送信元
Loopback0

宛先
198.51.100.10

ここではLoopback0に関連するアドレスを送信元条件として到達性を確認します。

Cisco IOSでExtended Pingを実行する

Cisco IOSでは、pingを引数なしで実行すると対話形式で条件を指定できます。

次は、送信元を192.168.10.1、宛先を198.51.100.10として5回確認する例です。

R1# ping
Protocol [ip]:
Target IP address: 198.51.100.10
Repeat count [5]: 5
Datagram size [100]: 100
Timeout in seconds [2]: 2
Extended commands [n]: y
Source address or interface: 192.168.10.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 198.51.100.10, timeout is 2 seconds:
Packet sent with a source address of 192.168.10.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

この例では、このページで扱う主要条件を次のように読みます。

Target IP address:
→ 宛先IP

Repeat count [5]:
→ 試行回数

Datagram size [100]:
→ データグラムサイズ

Timeout in seconds [2]:
→ 応答待ち時間

Extended commands [n]: y
→ 追加指定を有効化

Source address or interface:
→ 送信元アドレスまたは送信元インターフェース

Source address or interface:で指定した192.168.10.1が、この確認の送信元条件になります。

後続の追加プロンプトは、この例では既定値のまま進めています。

実行結果を読む

出力：

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

この結果から、

指定した送信元 192.168.10.1
指定した宛先 198.51.100.10
5回の試行
5回すべてEcho Reply受信

と読みます。

重要なのは、通常Pingと同じく成功記号だけを見るのではなく、どの送信元条件を指定した試験だったかをセットで記録することです。

ループバックを送信元にする意味

Loopback0を送信元にした確認は、

Loopback0側のアドレスを送信元にした場合

の往復到達性を確認するものです。

通常Pingが別の送信元を使って成功していても、Loopback0を送信元にした通信条件まで同じとは限りません。

LAN側インターフェースを送信元にする意味

例：

LAN側インターフェース
192.168.10.1

宛先
198.51.100.10

この条件でExtended Pingを実行すると、

192.168.10.1
↔
198.51.100.10

のICMP往復が成立するかを確認できます。

送信元は実行装置で利用可能なものを考える

重要なのは、Extended Pingで指定する送信元を、

実行装置自身が利用可能なアドレス / インターフェース

として考えることです。

実行装置に存在しない任意のクライアントアドレスを指定して、そのクライアント通信を完全再現できる、と考えてはいけません。

存在しないクライアントアドレスを自由に使うものではない

例：

ルータのLAN側IP
192.168.10.1

実クライアントIP
192.168.10.50

ルータからのExtended Pingで、

192.168.10.50を自由に送信元として使えば
クライアント通信を完全再現できる

とは考えません。

確認する主体はあくまでExtended Pingを実行する装置です。

ルータ自身のアドレスを使った試験

ルータが持つ、

Loopback
物理インターフェース
SVI

などの利用可能なアドレスを送信元として使い、条件ごとの差を確認します。

送信元指定は「なりすまし再現」ではない

Extended Pingの送信元指定は、

任意の端末になりすまして
その端末の全通信を再現する

ための機能として理解しません。

目的は、

実行装置で利用可能な送信元条件を制御して
L3到達性の差を見る

ことです。

往路と復路の両方が必要

Extended Pingが成功するには、Echo Requestが宛先へ届くだけでは足りません。

送信元
→
宛先

という往路と、

宛先
→
指定した送信元

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

指定した送信元へ応答が戻る必要がある

送信元を、

192.168.10.1

にした場合、Echo Replyはその送信元へ戻れる必要があります。

つまり、

192.168.10.1
→ 198.51.100.10

だけでなく、

198.51.100.10
→ 192.168.10.1

も成立する必要があります。

往路だけ正常でも成功しない

例：

192.168.10.1
→ 198.51.100.10

は到達できても、

198.51.100.10
→ 192.168.10.1

への復路が成立しなければ、送信元はEcho Replyを受信できません。

したがって、Extended Pingの失敗を往路だけの問題と決め付けません。

復路だけを直接表示する機能ではない

Extended Pingが失敗したからといって、

復路障害確定

とは判断しません。

失敗結果は、

往路
復路
経路
フィルタリング
宛先側状態

など複数の候補を持ちます。

通常Ping成功、Extended Ping失敗

重要な比較パターンです。

例：

通常Ping
→ 成功

192.168.10.1を送信元にしたExtended Ping
→ 失敗

この差から、

送信元条件によって到達性結果が変わる

ことが分かります。

差分が示すもの

通常Ping成功、特定送信元のExtended Ping失敗という結果は、

宛先そのものが常に停止している

という仮説を弱めます。

一方、

特定送信元サブネットに依存する経路差
指定送信元への復路差
送信元条件に依存するフィルタリング

などの仮説を強める材料になります。

差分は根本原因ではない

結果差が見えても、

復路が原因である

と即断しません。

正しくは、

送信元条件によって結果が変わった
↓
送信元依存の原因仮説を強める
↓
経路や設定など追加情報を確認する

です。

複数の送信元を比較する

例：

送信元 192.0.2.1
→ 成功

送信元 192.168.10.1
→ 失敗

送信元 192.168.20.1
→ 成功

この場合、

192.168.10.1を送信元にした条件だけ結果が異なる

という差分が重要です。

宛先を変えずに送信元を変える

送信元差を調べたい場合は、比較条件を整理します。

同じ宛先
同じ試験時点
送信元だけ変更

とすると、送信元条件による差を読みやすくなります。

比較条件を一度に変えすぎない

例：

送信元を変更
宛先も変更
Datagram Sizeも変更
Timeoutも変更

と同時に複数条件を変えると、何が結果差に影響したか分かりにくくなります。

基本は、

確認したい条件を1つずつ変える

ことです。

Extended Pingの結果を比較表にする

例：

原因ではなく、まず条件ごとの観測結果を並べます。

送信元別比較の切り分けフロー

通常Pingを確認
↓
確認したい送信元を決める
↓
Extended Pingで送信元を明示
↓
結果を比較
↓
送信元条件で差があるか
↓
差があれば経路・復路・フィルタリング等を追加確認

クライアントLANを想定した確認

例：

クライアントLAN
192.168.10.0/24

ルータのLAN側インターフェース
192.168.10.1

リモートIP
198.51.100.10

ルータから、

送信元 192.168.10.1
宛先 198.51.100.10

でExtended Pingを実行すると、LAN側インターフェースを送信元にしたL3到達性を確認できます。

成功しても実クライアント通信そのものではない

このExtended Pingが成功しても、

Client 192.168.10.50
→ リモートIP

の実通信すべてを確認したわけではありません。

試験の送信元は、

192.168.10.1

であり、

192.168.10.50

ではないからです。

ルータ側成功とクライアント側成功を分ける

ルータからのExtended Ping成功：

ルータ
192.168.10.1
→ リモートIP
成功

クライアント通信：

クライアント
192.168.10.50
→ リモートIP
失敗

この2つは同時に起こり得ます。

ルータ側Extended Pingが直接確認しないもの

ルータからのExtended Pingだけでは、クライアント固有の、

IPアドレス設定
デフォルトゲートウェイ設定
クライアントからルータまでのL2接続
クライアント自身の状態
アプリケーションの状態

まで直接確認したことにはなりません。

同じサブネットでも完全再現ではない

送信元が、

192.168.10.1

で、

192.168.10.50

と同じサブネットに属していても、

同じサブネット
=
同じ端末通信を完全再現

ではありません。

Extended Ping成功後もクライアントだけ失敗する場合

状況：

ルータのLAN側インターフェースを送信元
→ Extended Ping成功

クライアント
→ 通信失敗

この場合、

ルータから指定送信元条件でのL3到達性は成立

という証拠を保持しつつ、クライアント固有部分を別に確認します。

Extended Ping失敗でもクライアント障害と決めない

逆に、ルータからのExtended Pingが失敗しただけで、

クライアントNIC故障

と決めることもできません。

Extended Pingが直接確認しているのは、ルータ上の指定送信元条件からのL3到達性です。

Extended Pingとアプリケーションを分ける

Extended PingはICMPを使った到達性確認です。

したがって、

Extended Ping成功
=
Web正常
SSH正常
DNS正常
アプリケーション正常

ではありません。

Repeat Countとは

Repeat Countは、試行回数を増やして複数回の結果を確認するための条件です。

例：

Repeat Count
5

から、

Repeat Count
20

へ増やせば、より多くの試行結果を確認できます。

Repeat Countを増やす目的

単発では、

成功

していても、複数回実行すると一部失敗することがあります。

Repeat Countを増やすことで、

成功率
一部ロス
結果のばらつき

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

Repeat Countは送信元を変える項目ではない

Repeat Countを増やしても、

送信元アドレスが別サブネットへ変わる

わけではありません。

Repeat Countは試行回数の条件です。

Repeat Countと送信元指定を混同しない

目的別に分けます。

送信元条件を変えたい
→ 送信元アドレス / インターフェース

複数回の傾向を見たい
→ Repeat Count

です。

一部失敗の例

例：

Repeat Count
20

結果
18回成功
2回失敗

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

20回中2回失敗した

という結果です。

一部ロスだけで原因を断定しない

一部失敗が確認できても、

物理障害確定
経路障害確定
輻輳確定

とは判断しません。

Repeat Countを増やして得た結果は、追加切り分けの材料です。

Repeat Countを増やす価値

単発試験で結果が安定しないとき、

成功
失敗
成功
成功
失敗

のような傾向を確認するために有効です。

Datagram Sizeとは

Datagram Sizeは、送信するICMPデータグラムのサイズ条件を変更して結果差を見るための項目です。

例：

Datagram Size
100

Datagram Size
1400

のように条件を変えて比較します。

Datagram Sizeを変える目的

通常サイズでは成功し、大きいサイズだけ失敗する場合、

サイズ条件によって結果が変わる

という確認情報が得られます。

サイズ差を観測する

例：

Datagram Size 100
→ 成功

Datagram Size 500
→ 成功

Datagram Size 1400
→ 失敗

直接分かるのは、

大きいサイズ条件で結果差が発生した

ことです。

サイズ差だけで根本原因を決めない

大きいDatagram Sizeで失敗しても、

特定の原因で確定

とはしません。

まず、

サイズ依存の問題仮説を強める

ところまでに留めます。

Datagram SizeとRepeat Countを混同しない

回数を増やす
→ Repeat Count

サイズを変える
→ Datagram Size

です。

試験目的に応じて使い分けます。

サイズ条件を比較するときの考え方

送信元差を見たいのにDatagram Sizeまで同時に変えると、結果差の要因が増えます。

したがって、

送信元差を見る
→ Datagram Sizeは同じ

サイズ差を見る
→ 送信元条件は同じ

のように比較条件を整理します。

Timeoutとは

Timeoutは、応答を待つ時間条件です。

Timeoutを変更すると、

どの程度待って応答なしと判断するか

という条件が変わります。

Timeoutを長くする意味

例：

Timeout
短い
→ 失敗

Timeout
長い
→ 成功

なら、

応答待ち時間の条件によって結果が変わった

ことが分かります。

Timeoutを長くして成功しても原因確定ではない

Timeoutを延ばして応答を受信できた場合でも、

原因は必ず特定装置のCPU
原因は必ず物理回線

とは判断しません。

直接確認できたのは、

より長く待つ条件では応答を受信できた

という事実です。

Timeoutと遅延原因を分ける

Timeoutは待ち時間の条件です。

遅延の根本原因そのものを示す値ではありません。

Timeoutを短くして失敗した場合

短いTimeoutで失敗し、長いTimeoutで成功した場合、

応答に時間がかかっている可能性

は考えられます。

しかし原因は追加確認が必要です。

TimeoutとRepeat Countの違い

試行回数を変える
→ Repeat Count

1回ごとの応答待ち条件を変える
→ Timeout

です。

TimeoutとDatagram Sizeの違い

応答を待つ時間
→ Timeout

送信するデータグラムサイズ
→ Datagram Size

です。

目的を混同しないことが重要です。

3つの追加条件を整理する

これらは、送信元指定とは別の調整項目です。

送信元指定と3項目の関係

Extended Pingでは、

送信元条件
+
Repeat Count
+
Datagram Size
+
Timeout

を組み合わせて試験できます。

ただし、切り分けでは一度に多くの条件を変えず、目的を明確にします。

条件を固定して送信元だけ比較する

例：

宛先
198.51.100.10

Repeat Count
5

Datagram Size
100

Timeout
同一

送信元だけ変更

このようにすると、送信元条件による結果差を見やすくなります。

条件を固定してDatagram Sizeだけ比較する

例：

送信元
192.168.10.1

宛先
198.51.100.10

Repeat Count
5

Timeout
同一

Datagram Sizeだけ変更

サイズ条件による差を見やすくなります。

条件を固定してTimeoutだけ比較する

例：

送信元
192.168.10.1

宛先
198.51.100.10

Repeat Count
5

Datagram Size
100

Timeoutだけ変更

応答待ち条件による差を見やすくなります。

条件差を記録する

Extended Pingでは、結果だけでなく試験条件も記録します。

例：

送信元
192.168.10.1

宛先
198.51.100.10

Repeat Count
20

Datagram Size
100

Timeout
2秒

結果
20回中20回成功

条件が残っていないと、別試験との比較が難しくなります。

通常PingとExtended Pingを比較する

比較例：

通常Ping
→ 成功

Extended Ping
送信元 192.168.10.1
→ 失敗

この場合、

通常選択された送信元条件では成功
192.168.10.1を送信元にした条件では失敗

という差を記録します。

同じ結果でも意味が異なることがある

例：

通常Ping
→ 成功

Extended Ping
→ 成功

両方成功でも、同じ条件を試したとは限りません。

Extended Pingで送信元を変えていれば、

複数の送信元条件でICMP往復が成立

という追加の確認情報になります。

Extended Ping成功の証拠範囲

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

指定した送信元条件
指定した宛先条件
指定した試験条件

でICMP Echoの往復が成立したことです。

Extended Ping成功が証明しないもの

成功しても、

実クライアントの全通信正常
アプリケーションの正常
すべてのプロトコル正常
すべての時間帯で正常

までは証明しません。

Extended Ping失敗の証拠範囲

失敗した場合は、

その指定条件ではICMP Echoの往復が成立しなかった

という観測結果です。

原因は一意に決まりません。

Extended Ping失敗を宛先停止と決めない

Extended Pingが失敗しても、

宛先ホスト停止確定

とは判断しません。

送信元条件、経路、復路、フィルタリングなどを追加確認します。

送信元別結果から仮説を作る

例：

送信元 192.0.2.1
→ 成功

送信元 192.168.10.1
→ 失敗

仮説：

192.168.10.1の送信元条件に依存する差がある可能性

ここから追加確認へ進みます。

成功条件と失敗条件を比較する

切り分けでは、

何が同じか
何が違うか

を整理します。

例：

同じ
→ 宛先
→ 実行時点
→ Datagram Size
→ Timeout

違う
→ 送信元

この場合、送信元条件の差に注目します。

差分診断の基本

条件A
→ 成功

条件B
→ 失敗

AとBの違いを特定
↓
その違いに関係する仮説を作る
↓
追加情報で検証

Extended Pingはこの差分診断に有効です。

一度に条件を変えすぎた悪い例

試験1
送信元A
Datagram Size 100
Timeout 2秒

試験2
送信元B
Datagram Size 1400
Timeout 10秒

この比較で結果が変わっても、

送信元
サイズ
待ち時間

のどれが影響したか分かりにくくなります。

良い比較例

試験1
送信元A
Datagram Size 100
Timeout 2秒

試験2
送信元B
Datagram Size 100
Timeout 2秒

違いは送信元だけなので、送信元条件の差を評価しやすくなります。

Repeat Countを増やすシナリオ

状況：

単発では成功することも失敗することもある

次の確認：

Repeat Countを増やす

目的：

複数回の成功・失敗傾向を見る

です。

Datagram Sizeを変えるシナリオ

状況：

特定の通信条件でサイズ依存を疑う

次の確認：

Datagram Sizeだけ変更して比較

目的：

サイズ条件で結果が変わるかを見る

です。

Timeoutを変えるシナリオ

状況：

応答が遅い可能性を疑う

次の確認：

Timeout条件を変更

目的：

待ち時間条件で結果が変わるかを見る

です。

ルータ上の送信元を選ぶシナリオ

状況：

Loopback0からの到達性を確認したい

考え方：

Loopback0のアドレス / インターフェースを送信元に指定

です。

存在しない任意アドレスを使うのではありません。

LAN側送信元を選ぶシナリオ

状況：

LAN 192.168.10.0/24側を送信元条件にしたい

ルータが、

192.168.10.1

を持っているなら、そのアドレスまたは対応インターフェースを送信元条件として使います。

送信元が装置にないシナリオ

状況：

Client 192.168.10.50の通信を確認したい

誤った考え方：

ルータに存在しない192.168.10.50を
自由に送信元として使えば完全再現できる

正しい考え方：

ルータ自身で利用可能な送信元条件を使う
↓
結果はルータからのL3到達性として扱う
↓
クライアント固有部分は別証拠として扱う

です。

通常Ping成功、LAN送信元失敗のシナリオ

結果：

通常Ping
→ 成功

LAN側アドレスを送信元
→ 失敗

判断：

送信元条件による結果差あり

です。

この差から、送信元サブネットに依存する経路や復路の違いを疑う材料が得られます。

複数送信元すべて成功するシナリオ

結果：

Loopback0送信元
→ 成功

LAN1送信元
→ 成功

LAN2送信元
→ 成功

判断：

確認した複数送信元条件ではICMP往復が成立

です。

ただし、すべてのクライアント通信まで正常とは言いません。

Extended Ping成功、クライアント失敗のシナリオ

結果：

ルータのLAN側インターフェースを送信元
→ 成功

クライアント
→ 通信失敗

判断：

ルータ側の指定送信元条件ではL3到達性あり
クライアント固有部分は未確認

です。

Repeat Count増加でロスが見えるシナリオ

結果：

Repeat Count 5
→ 5回成功

Repeat Count 50
→ 一部失敗

判断：

複数回試行で一部失敗の傾向が見えた

です。

原因は追加確認します。

Datagram Size増加で失敗するシナリオ

結果：

Datagram Size 小
→ 成功

Datagram Size 大
→ 失敗

判断：

サイズ条件で結果差あり

です。

原因を一意に決めません。

Timeout延長で成功するシナリオ

結果：

短いTimeout
→ 失敗

長いTimeout
→ 成功

判断：

応答待ち条件で結果差あり

です。

遅延原因そのものは未確定です。

Extended Pingで最初に考える順序

何を確認したいか
↓
宛先を固定
↓
確認したい送信元を決める
↓
送信元が実行装置で利用可能か確認
↓
Extended Pingを実施
↓
結果を通常Pingや他送信元と比較
↓
必要に応じてRepeat Count / Datagram Size / Timeoutを調整
↓
差分から仮説を作る
↓
追加情報で検証

送信元差を見るときの基本判断

通常Ping成功
特定送信元失敗

なら、

送信元条件に依存する差

に注目します。

通常Ping成功
特定送信元成功

なら、

確認した複数条件で到達性成立

という追加証拠になります。

成功を広げすぎない

良い表現：

192.168.10.1を送信元としたExtended Pingは成功した。
この条件ではICMP往復が成立している。

悪い表現：

192.168.10.0/24の全クライアント通信は正常。

試験していない範囲まで結論を広げません。

失敗を広げすぎない

良い表現：

192.168.10.1を送信元としたExtended Pingは失敗した。
通常Pingとの差があるため、送信元条件に依存する差を追加確認する。

悪い表現：

宛先サーバが停止している。

原因確定には追加証拠が必要です。

試験条件を明示して記録する

Extended Pingの結果を残すときは、

送信元
宛先
Repeat Count
Datagram Size
Timeout
成功 / 失敗

をセットで記録します。

比較結果を一文で表す

良い例：

通常Pingは成功するが、
192.168.10.1を送信元にしたExtended Pingは失敗する。
送信元条件による結果差があるため、
192.168.10.0/24側への復路や送信元依存の経路条件を追加確認する。

この表現なら、観測事実と仮説を分けられます。

問題での判断パターン

パターン1：Extended Pingの主な利点

送信元アドレスなどの条件を指定して
L3到達性を確認できる

と判断します。

パターン2：通常Ping成功後に別LAN条件を確認する

確認したいLAN側アドレスを送信元として指定

する考え方を選びます。

パターン3：重要な追加指定

送信元アドレス / インターフェース

を明示して送信元条件を制御します。

パターン4：Loopback0を送信元にする

Loopback0のアドレス / インターフェース

を送信元条件として使います。

パターン5：存在しないクライアントアドレス

実行装置で利用可能な送信元を使う

と判断します。

任意のクライアントアドレスを使って完全再現するものではありません。

パターン6：指定送信元で成功する条件

往路
+
指定送信元への復路

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

パターン7：通常Ping成功、LAN送信元失敗

送信元サブネットに依存する経路 / 復路差

を疑う材料になります。

パターン8：複数送信元を比較する目的

送信元条件によって到達性結果が変わるか

を確認します。

パターン9：ルータLAN側送信元の成功限界

実クライアントの全通信条件までは試験していない

と判断します。

パターン10：Extended Ping成功後もクライアントだけ失敗

クライアント固有の
IP設定
デフォルトゲートウェイ
L2接続
など未確認部分を確認

します。

パターン11：Repeat Count

複数回の試行を行い
ロスや応答傾向を確認

するために使います。

パターン12：20回程度の試行を確認したい

Repeat Countを増やす

と判断します。

パターン13：サイズ依存の差を確認する

Datagram Sizeを変更

します。

パターン14：大きいDatagram Sizeだけ失敗

サイズ依存の問題仮説を強め
追加確認

します。

パターン15：Timeoutを長くする

応答を待つ時間条件を変更

します。

パターン16：Timeout延長で応答受信

待ち時間条件で結果差が出た
原因は追加確認が必要

と判断します。

パターン17：Extended Pingの切り分けでの使い方

送信元などを制御したL3到達性確認として使う

のであり、

クライアント / アプリケーション全体の完全再現

とは扱いません。

よくある誤り

Extended Pingは通常Pingより常に先に使う

状況に応じて使い分けます。

通常Pingで基本到達性を確認し、送信元条件を変えて比較したいときにExtended Pingが有効です。

送信元を自由なクライアントIPにできると考える

実行装置で利用可能な送信元条件を使う考え方が基本です。

Extended Ping成功でクライアント通信正常と決める

ルータ自身からの指定送信元条件を確認した結果です。

クライアント固有部分は別です。

Extended Ping失敗で宛先停止と決める

往路、復路、送信元条件など複数の要因があり得ます。

Repeat Countを送信元変更だと考える

Repeat Countは試行回数です。

Datagram Sizeを送信元変更だと考える

Datagram Sizeはデータグラムサイズ条件です。

Timeoutを経路変更だと考える

Timeoutは応答を待つ時間条件です。

すべての条件を同時に変える

差分の原因を評価しにくくなります。

目的に応じて1つずつ条件を変えます。

切り分けの基本フロー

通常Pingの結果確認
↓
確認したい送信元条件を決定
↓
実行装置で利用可能な送信元か確認
↓
Extended Ping
↓
通常Pingとの結果比較
↓
他の送信元条件とも比較
↓
必要ならRepeat Countを変更
↓
必要ならDatagram Sizeを変更
↓
必要ならTimeoutを変更
↓
条件差を整理
↓
原因仮説を作る
↓
追加情報で検証

運用確認で残す情報

Extended Pingを運用確認で使う場合は、

実行時刻
実行装置
送信元アドレス / インターフェース
宛先IP
Repeat Count
Datagram Size
Timeout
結果
通常Pingとの差
他送信元との差

を残すと比較しやすくなります。

観測事実と推測を分ける

例：

観測事実
→ 192.168.10.1送信元だけ失敗

仮説
→ 192.168.10.0/24側に依存する経路 / 復路差がある可能性

未確定
→ 根本原因

この順序で扱います。

通常Pingとの役割分担

通常Ping：

基本的なIP到達性を素早く確認

Extended Ping：

送信元や追加条件を制御し
条件差を比較

という役割で整理します。

Extended Pingの強み

最大の強みは、

試験条件を制御できること

です。

特に送信元を明示することで、

どの送信元条件で成功するか
どの送信元条件で失敗するか

を比較できます。

Extended Pingの限界

一方で、

ルータからの試験

である以上、

実クライアントの全通信
アプリケーション動作
クライアント固有設定

を完全再現するものではありません。

最終判断の型

Extended Pingの問題では、次の順序で考えます。

1. 何を変えたいのか
2. 送信元条件か
3. 試行回数か
4. サイズ条件か
5. 待ち時間条件か
6. 成功 / 失敗の差は何か
7. その差から直接言えることは何か
8. 何はまだ証明できないか

まとめ

Extended Pingは、通常Pingより細かい試験条件を指定してL3到達性を確認するために使います。

最も重要な追加条件の1つは、

送信元アドレス / インターフェース

です。

送信元を変えて同じ宛先への結果を比較すると、

送信元サブネットに依存する経路差
指定送信元への復路差
送信元条件に依存する差

を疑う材料が得られます。

ただし、指定する送信元は実行装置で利用可能なものとして考え、

任意のクライアントIPを使って
クライアント通信を完全再現する

ものではありません。

成功には、

往路
+
指定送信元への復路

が必要です。

また、

Repeat Count
→ 試行回数

Datagram Size
→ データグラムサイズ

Timeout
→ 応答待ち時間

として使い分けます。

Extended Pingの結果は、

指定条件でのL3到達性の証拠

として扱い、

実クライアントの全通信
アプリケーション正常性
根本原因

まで一気に広げません。

最終的には、

通常Ping
送信元別Extended Ping
Repeat Count
Datagram Size
Timeout

の結果差を整理し、観測事実と原因仮説を分けて追加確認へ進むことが重要です。