Packet Capture Interpretation

このページのゴール

パケットキャプチャを、単に「パケットが見えた／見えない」で判断するのではなく、どの地点で、どの方向を、どの条件で観測した結果なのかを前提に読み取れるようにします。

特に重要なのは、

1地点で観測した事実
=
ネットワーク全体で起きた事実

ではないことです。

パケットキャプチャでは、

観測地点
観測方向
Ethernetヘッダ
802.1Qタグ
EtherType
ARP
IPヘッダ
TTL / Hop Limit
ICMP
要求と応答

を順番に確認し、直接証明できる範囲と、まだ証明できない範囲を分けることが重要です。

このページで学ぶこと

• パケットキャプチャの観測地点
• ingressとegressの観測方向
• Ethernetの送信元MACアドレスと宛先MACアドレス
• 802.1QタグとVLAN IDの読み方
• EtherTypeによる上位プロトコル識別
• ARP RequestとARP Replyの読み方
• IPv4とIPv6の送信元・宛先アドレス
• IPv4 TTLとIPv6 Hop Limitの読み方
• ICMP Echo RequestとICMP Echo Replyの読み方
• パケットを観測できない場合の証拠限界
• 複数地点のキャプチャを相関させる方法

パケットキャプチャで最初に確認すること

パケットの中身を見る前に、まず確認するのは、

どこで観測したか
どの方向を観測したか

です。

これが分からないと、同じパケットでも結果を正しく解釈できません。

観測地点とは

観測地点は、パケットを取得した場所です。

例：

送信ホスト
    |
    | ①送信側
    |
  ルータ
    |
    | ②中継区間
    |
  スイッチ
    |
    | ③受信側
    |
受信ホスト

①、②、③のどこで取得したかによって、見える情報は変わります。

送信側でパケットを見た意味

送信側で要求パケットを観測した場合、

その観測地点で
要求パケットが存在した

ことは確認できます。

しかし、

宛先まで届いた

ことまでは直接証明できません。

受信側で同じパケットを見た意味

受信側で同じ要求パケットを観測できた場合は、

少なくとも受信側のその観測地点までは
要求パケットが到達した

と判断できます。

1地点の観測を全体へ広げない

悪い判断：

送信側で要求を観測した
↓
宛先でも必ず受信した

良い判断：

送信側で要求を観測した
↓
送信側のその地点までは確認できた
↓
宛先側は別の確認が必要

です。

観測方向とは

同じインターフェースでも、

ingress
egress

では観測対象が異なります。

ingressとは

ingressは、そのインターフェースへ入ってくる方向です。

概念図：

外部
  |
  v
[ Interface ]
   ingress

egressとは

egressは、そのインターフェースから出ていく方向です。

概念図：

[ Interface ]
   egress
     |
     v
    外部

同じインターフェースでも結果は異なり得る

同じインターフェースでも、

ingressで見えるパケット
egressで見えるパケット

が同一とは限りません。

転送処理やフィルタリングの前後など、観測する位置と方向によって結果が変わるためです。

観測地点と方向はセットで記録する

良い記録例：

Gi1/0/1 ingress
Gi1/0/1 egress
Gi1/0/2 ingress
Gi1/0/2 egress

悪い記録例：

Gi1/0/1で見えた

だけでは、どちら向きか分かりません。

要求の流れを比較する

たとえば、

入口 ingress
→ 要求あり

出口 egress
→ 要求あり

なら、その装置では少なくとも両地点で同じ要求を観測しています。

一方、

入口 ingress
→ 要求あり

出口 egress
→ 要求なし

なら、入口と出口の間を追加確認候補にできます。

観測条件を固定して比較する

複数回の結果を比較するときは、

観測地点
観測方向
対象通信
時刻
フィルタ条件

をそろえることが重要です。

条件が違う結果を直接比較すると、誤った判断につながります。

Ethernetヘッダを読む

Ethernetフレームでは、L2の送信元と宛先を確認します。

代表的な情報：

Destination MAC Address
Source MAC Address
EtherType

送信元MACアドレス

Source MAC Addressは、その観測地点でのEthernetフレームのL2送信元を示します。

例：

Source MAC Address:
00:11:22:33:44:55

宛先MACアドレス

Destination MAC Addressは、その観測地点でのEthernetフレームのL2宛先を示します。

例：

Destination MAC Address:
00:aa:bb:cc:dd:ee

MACアドレスはリンクごとに変わり得る

同じIPパケットでも、ルータを越える前後ではEthernetヘッダが作り直されます。

概念例：

Host A
IP送信元 192.0.2.10
IP宛先   198.51.100.20
        |
        | Ethernet
        | 宛先MAC = R1
        v
       R1
        |
        | Ethernet
        | 送信元MAC = R1
        | 宛先MAC = 次Hop
        v
       R2

IPアドレスが同じでも、L2のMACアドレスはリンクごとに変わり得ます。

1地点のMACアドレスを全区間へ当てはめない

悪い判断：

送信側で宛先MACがaa:bb:cc:dd:ee
↓
全リンクで宛先MACも同じ

とは限りません。

ルータを越えると、次のリンク用のEthernetヘッダになります。

L2とL3を分ける

Ethernet Source / Destination
→ L2

IP Source / Destination
→ L3

として分けて読みます。

802.1Qタグを読む

802.1Qタグが存在する場合、キャプチャ結果からVLAN IDを確認できます。

例：

802.1Q
VLAN ID: 20

VLAN ID 20を観測した意味

直接言えることは、

その観測地点で
VLAN ID 20のタグを持つフレームを観測した

ことです。

VLAN IDから言い過ぎない

VLAN ID: 20を観測しても、

ネットワーク全区間で必ずVLAN 20タグ付き

とは限りません。

観測地点によってタグの有無は変わり得ます。

トランク側とアクセスポート側の違いを意識する

例：

トランク側 ingress
→ VLAN 20タグあり

アクセスポート側 egress
→ 同じタグを観測しない

という状態は、観測地点ごとのフレーム状態として扱います。

タグがないことだけで異常と決めない

タグが見えない場合でも、

観測地点
ポートの役割
フレームがどの処理段階にあるか

を考慮します。

Native VLANを即断しない

VLAN ID 20のタグを観測した事実だけから、

Native VLAN = 20

とは判断しません。

直接確認できるのは、その地点で見えたタグ情報までです。

EtherTypeを読む

EtherTypeは、Ethernetフレームの上位プロトコルを識別する重要な情報です。

代表例：

EtherType 0x0806

EtherType: 0x0806

なら、ARPとして内容を確認します。

EtherType 0x0800

EtherType: 0x0800

なら、IPv4ヘッダを確認します。

EtherType 0x86DD

EtherType: 0x86DD

なら、IPv6ヘッダを確認します。

EtherTypeは分類の入口

802.1Qタグ付きフレームでは、0x8100は上位L3プロトコルを示す値ではなく、802.1QタグのTPIDです。タグ情報の後ろに続く元のEtherTypeを確認して、ARP、IPv4、IPv6などの上位プロトコルを判断します。

判断の流れ：

EtherType確認
↓
ARPか
IPv4か
IPv6か
その他か
↓
該当する上位ヘッダを読む

Source MACだけで上位プロトコルを決めない

送信元MACアドレスはL2送信元を示します。

ARPかIPv4かIPv6か

の分類にはEtherTypeが有効です。

ARP Requestを読む

ARP Requestは、代表的には、

あるIPv4アドレスに対応するMACアドレスを知りたい

という問い合わせです。

ARP Requestの概念例

Who has 192.0.2.1?
Tell 192.0.2.10

この場合、

192.0.2.10側が
192.0.2.1に対応するMACアドレスを問い合わせている

と解釈します。

ARP Replyを読む

ARP Replyでは、問い合わせに対するMACアドレス情報が返されます。

概念例：

192.0.2.1 is at 00:aa:bb:cc:dd:ee

RequestとReplyの両方を観測した場合

同じ観測地点で、

ARP Request
ARP Reply

の両方を確認できたなら、

その観測地点で
ARPの要求と応答の両方を観測した

と判断できます。

ARP交換を見たこととネットワーク全体正常は別

ARP RequestとReplyを確認しても、

全スイッチのMACアドレステーブルが正しい
デフォルトルートが正しい
アプリケーションが正常

まで直接証明するわけではありません。

ARP Requestだけ見えてReplyがない場合

例：

ARP Request
→ 観測

ARP Reply
→ 観測なし

直接言えるのは、

この観測条件では
対応するARP Replyを観測していない

ことです。

Replyがない原因を即断しない

ARP Replyを観測できない場合でも、

対象ホスト停止
ケーブル断
ルーティング異常

のどれかに即断できません。

ARP Reply非観測の候補

考えられる方向：

Requestが相手まで届いていない
相手がReplyを生成していない
Replyが途中で失われた
Replyが別の観測条件では存在する
キャプチャ条件が対象を捉えていない

です。

ARPの非観測は観測条件付き

悪い判断：

ARP Replyがない
↓
対象ホスト停止確定

良い判断：

この観測地点・方向ではARP Replyなし
↓
別地点や別方向で追加確認

です。

IPv4ヘッダを読む

IPv4では、

Source Address
Destination Address
TTL
Protocol

などを確認します。

IPv4送信元アドレス

例：

Source Address: 192.0.2.10

なら、その観測パケットのL3送信元は192.0.2.10です。

IPv4宛先アドレス

例：

Destination Address: 198.51.100.20

なら、その観測パケットのL3宛先は198.51.100.20です。

送信元と宛先をセットで読む

例：

IPv4
Source:      192.0.2.10
Destination: 198.51.100.20

なら、

観測したIPv4パケットは
192.0.2.10から198.51.100.20宛て

と読みます。

インターフェース名だけでL3端点を決めない

観測インターフェースがGi1/0/1だからといって、

送信元IP = Gi1/0/1のIP

とは限りません。

L3端点は、観測したIPヘッダを確認します。

想定と異なる送信元IPを見た場合

期待：

Source IP = 192.0.2.10

実際：

Source IP = 192.0.2.99

なら、最初に記録するのは、

観測したパケットのL3送信元が
想定と異なる

という事実です。

想定差から原因を飛躍しない

送信元IPが想定と異なっても、

スイッチポート故障確定
宛先ホスト停止確定

とは判断しません。

IPv6ヘッダを読む

IPv6でも、

Source Address
Destination Address
Hop Limit

などを確認します。

IPv4 TTLを読む

TTLは、観測したIPv4パケットに残っている値です。

例：

TTL: 61

なら、

その観測地点で
TTL 61のIPv4パケットを観測した

と読みます。

TTLは全経路を一意に示さない

TTLが61だからといって、

必ず3台のルータを通過した

と一意に断定できるとは限りません。

初期TTLが分からない場合があるためです。

TTLだけで経路全体は復元できない

単一地点で、

TTL = 61

を見ても、

通過した全ルータ
往路全体
復路全体

を一意に復元することはできません。

TTLは比較情報として使える

同条件で複数地点を観測して、

地点A TTL 63
地点B TTL 62

のような差があれば、パケットが経路を進む中でTTLが減少していることを確認する材料になります。

IPv6 Hop Limitを読む

IPv6ではTTLではなく、

Hop Limit

を確認します。

例：

Hop Limit: 63

Hop Limitも観測地点での残存値

直接言えるのは、

そのIPv6パケットを
Hop Limit 63で観測した

ことです。

Hop Limitを残りHop数の絶対値にしない

Hop Limit = 63
↓
あと63台のルータを通れる

という単純な絶対値として経路全体を確定するものではありません。

TTLとHop Limitを区別する

IPv4
→ TTL

IPv6
→ Hop Limit

です。

フィールド名を混同しないようにします。

ICMPを読む

ICMPでは、メッセージの種類と方向を確認します。

代表的なPingの組み合わせ：

ICMP Echo Request
ICMP Echo Reply

ICMP Echo Request

ICMP Echo Requestは、Pingの要求側です。

概念例：

192.0.2.10
   |
   | Echo Request
   v
198.51.100.20

ICMP Echo Reply

ICMP Echo Replyは、対応する応答側です。

概念例：

192.0.2.10
   ^
   | Echo Reply
   |
198.51.100.20

RequestとReplyの両方を同じ地点で観測

同じ観測地点で、

Echo Request
Echo Reply

の両方を確認できたなら、

その観測地点では
要求と対応応答の両方を観測した

と言えます。

両方を観測しても復路全体は証明しない

要求と応答を同じ地点で見ても、

往路と復路が完全に同じ

とは限りません。

観測できたのはその地点です。

Requestだけ見える場合

例：

Echo Request
→ 観測

Echo Reply
→ 観測なし

直接言えるのは、

この観測条件では
対応するEcho Replyを観測していない

ことです。

Reply非観測だけでは原因を分けられない

Echo Replyが見えない原因候補：

Requestが宛先まで届いていない
宛先がReplyを生成していない
Replyが復路途中で失われた
フィルタリングされた
別の観測地点・方向には存在する
キャプチャ条件が対象を捉えていない

があります。

「見えない」を「存在しない」にしない

パケットキャプチャで重要な原則です。

このキャプチャで見えない

ことと、

ネットワーク上のどこにも存在しない

ことは同じではありません。

非観測は条件付き事実

正しい表現：

Gi1/0/1 ingressでは
対象パケットを観測していない

言い過ぎ：

対象パケットはネットワーク上に存在しない

です。

フィルタ条件も考慮する

実際にパケットが存在していても、

フィルタ条件に一致しない
観測方向が違う
観測インターフェースが違う
観測時間がずれている

などで見えない場合があります。

観測時間も重要

通信発生時刻とキャプチャ時間が一致していなければ、

取得結果に対象通信がない

ことがあります。

1地点の非観測で原因を確定しない

悪い判断：

1地点でReplyなし
↓
宛先停止確定

良い判断：

1地点でReplyなし
↓
観測地点・方向・時間・条件を確認
↓
別地点で追加確認

です。

複数地点キャプチャの目的

複数地点で同じ通信を観測すると、

どこまでは存在したか
どこから観測できなくなったか

を絞れます。

要求を2地点で比較する

例：

送信側 egress
→ Echo Requestあり

受信側 ingress
→ Echo Requestなし

なら、

送信側の観測地点では要求あり
受信側の観測地点では要求なし

という差が確認できます。

2地点間を候補範囲にする

この場合、

送信側観測地点
～
受信側観測地点

の間を追加確認候補にできます。

要求が両地点で見える場合

例：

送信側 egress
→ Requestあり

受信側 ingress
→ Requestあり

なら、

少なくとも両方の観測地点で
同じRequestを観測した

と判断します。

応答を2地点で比較する

例：

受信側 egress
→ Replyあり

送信側 ingress
→ Replyなし

なら、復路について、

受信側ではReplyあり
送信側ではReplyなし

という差を確認できます。

要求と応答を別々に追う

往路と復路は、

Request
Reply

を分けて追跡します。

一方が通っていても、他方が通っているとは限りません。

複数地点相関の基本

地点Aで存在
地点Bで存在
地点Cで非観測

なら、

地点Bから地点Cの間

を追加確認候補にできます。

同一パケットかを確認する

複数地点を比較するときは、

送信元 / 宛先IP
プロトコル
ICMP種別
時刻
識別情報

などを使い、同じ通信を比較していることを確認します。

異なる通信を比較しない

別の通信を、

同じパケットの前後

として扱うと誤判断になります。

複数地点比較では相関条件が重要です。

Cisco EPCの結果も同じ原則で読む

Cisco機器のEmbedded Packet Captureで、

Gi1/0/1 ingress
ICMP Echo Request

と記録されている場合、直接言えるのは、

Gi1/0/1 ingressで
ICMP Echo Requestを観測した

ことです。

EPCで見えたから宛先到達とは限らない

Gi1/0/1 ingressでRequestあり

という事実だけでは、

次Hopへ転送された
宛先に届いた
Replyが返った

まで証明できません。

EPCのBufferを読むとき

Buffer内の個々のパケットは、

どの観測地点
どの方向
どの通信
どの時刻

という条件付きで読みます。

1つのBufferをエンドツーエンド全体と考えない

EPC Bufferにパケットがあるからといって、

エンドツーエンド全体で同じ状態

とは限りません。

EthernetとIPを同時に読む

例：

Ethernet
Source MAC:      00:11:22:33:44:55
Destination MAC: 00:aa:bb:cc:dd:ee

IPv4
Source:          192.0.2.10
Destination:     198.51.100.20
TTL:             63

この場合、L2とL3を分けて記録します。

ルータ越え前後を比較する

地点A：

Ethernet Source MAC: Host A
Ethernet Destination MAC: R1
IP Source: 192.0.2.10
IP Destination: 198.51.100.20

地点B：

Ethernet Source MAC: R1
Ethernet Destination MAC: R2
IP Source: 192.0.2.10
IP Destination: 198.51.100.20

L2は変わっても、L3の送信元・宛先が維持されることがあります。

802.1QタグとIPアドレスを分ける

VLANタグはL2側の情報です。

VLAN ID 20

を見たことと、

IP Source 192.0.2.10

は別の観測項目です。

EtherTypeとIP Protocolを分ける

EtherTypeはEthernet側で上位プロトコルを識別します。

IPv4ヘッダ内のProtocolは、IPv4の上位プロトコルを識別する別のフィールドです。

パケットをLayerごとに読む

おすすめの順序：

1. 観測地点
2. 観測方向
3. Ethernet
4. 802.1Q
5. EtherType
6. ARP または IP
7. TTL / Hop Limit
8. ICMPなど上位内容
9. 要求と応答の対応

途中から読まない

いきなり、

Echo Replyがない

だけを見るのではなく、

どこで
どの方向で
何を対象に
取得したか

から確認します。

観測事実と推測を分ける

例：

観測事実:
Gi1/0/1 ingressでEcho Requestあり
Gi1/0/2 egressでEcho Requestなし

推測:
装置内部処理またはGi1/0/2側への転送条件に
追加確認が必要な可能性

です。

原因確定は別の確認情報が必要

パケットキャプチャは強い証拠になりますが、

1つの観測結果
=
根本原因確定

ではありません。

「存在した地点」を記録する

複数地点で調べる場合、

地点A Requestあり
地点B Requestあり
地点C Requestなし

のように記録します。

「存在しなくなった区間」を絞る

上の例なら、

地点Bから地点Cの間

を追加確認候補にできます。

RequestとReplyの表を作る

例：

この場合、往路要求は受信側まで観測できています。

復路応答は受信側で見える一方、送信側では見えていません。

復路候補範囲を絞る

前の例なら、

受信側 egress
～
送信側 ingress

の間を追加確認候補にできます。

VLANタグ比較の表

これは、

観測地点ごとのフレーム状態が異なる

ことを示します。

MACアドレス比較の表

同じIP通信でも、Ethernetヘッダがリンクごとに変わり得ることを確認できます。

TTL比較の表

同一パケットとして相関できるなら、地点間の転送でTTLが減少したことを確認する材料になります。

パケット未観測の扱い

パケットが見えない場合は、

未観測

という事実を先に記録します。

パケット未観測から直接言える範囲

例：

Gi1/0/2 egress
対象Echo Requestなし

なら、

その観測条件では
対象Echo Requestを観測していない

までです。

パケット未観測から直接言えないこと

その1件だけでは、

装置故障
リンク断
宛先停止
フィルタリング原因確定

までは証明できません。

観測地点の違いを確認する

別地点で見えた／見えないを比較することで、初めて範囲を絞れます。

Directionの違いを確認する

同じインターフェースでも、

ingressにはある
egressにはない

という差があるなら、装置内処理や転送判断の前後として追加確認できます。

RequestとReplyを混同しない

Requestあり
Replyなし

の場合、要求と応答は別方向・別イベントです。

RequestがあるからReplyも存在するとは限りません。

ARPとICMPを混同しない

ARPはL2隣接でのIPv4アドレスとMACアドレスの対応解決に使われます。

ICMP Echo RequestとICMP Echo ReplyはIP到達性確認で使われます。

別の役割です。

TTLとVLAN IDを混同しない

TTL
→ IPv4ヘッダ

VLAN ID
→ 802.1Qタグ

です。

Layerを分けて読みます。

EtherTypeとICMP Typeを混同しない

EtherType
→ Ethernetで上位プロトコルを識別

ICMP Type
→ ICMPメッセージ種別を識別

です。

問題での判断パターン

パターン1：最初に確認する条件

観測地点と観測方向

です。

パターン2：送信側でパケットを観測

直接言えるのは、

送信側のその観測地点でパケットを観測した

ことです。

宛先到達までは証明しません。

パターン3：同じインターフェースのingressとegress

見えるパケットが異なり得る理由は、

観測方向が異なる

ためです。

パターン4：ingressとegressで要求を比較

観測地点と観測方向を分けて比較

します。

パターン5：EthernetのL2送信元

確認するのは、

Source MAC Address

です。

パターン6：ルータ越え前後のMACアドレス

各観測地点のEthernetヘッダ

を比較します。

パターン7：VLAN ID 20のタグを観測

直接言えるのは、

その観測地点でVLAN 20のタグを持つフレームを観測した

ことです。

パターン8：トランク側でタグあり、アクセス側でタグなし

観測地点ごとのフレーム状態

として解釈します。

パターン9：EtherType 0x0806

ARP

として内容を確認します。

パターン10：ARP・IPv4・IPv6を分類

Ethernetヘッダの、

EtherType

を確認します。

パターン11：ARP Requestあり、Replyなし

直接言えるのは、

この観測条件ではARP Replyを観測していない

ことです。

パターン12：ARP RequestとReplyの両方あり

その観測地点でARPの要求と応答を観測した

と判断します。

パターン13：IPv4の送信元・宛先

観測したIPv4パケットの
L3送信元とL3宛先

を示します。

パターン14：想定と異なるSource IP

最初に、

観測したL3送信元が想定と異なる

という確認情報として扱います。

パターン15：IPv4 TTL

観測地点でのTTL残存値

として読みます。

TTLだけで全経路を一意に復元しません。

パターン16：IPv6 Hop Limit

観測したIPv6ヘッダのHop Limit値

として読みます。

パターン17：Echo RequestとEcho Replyの両方あり

その観測地点で
要求と応答の両方を観測した

と判断します。

パターン18：Echo Requestあり、Replyなし

この観測条件では
対応するEcho Replyを観測していない

と判断します。

パターン19：送信側egressでRequestあり、受信側ingressでRequestなし

両観測地点の間へ
追加確認範囲を絞る

ことができます。

パターン20：トラブルシューティングでの使い方

観測地点と方向を前提に
観測できたパケットから直接証明できる範囲だけ判断する

ことが基本です。

パターン21：EPC BufferでGi1/0/1 ingressにEcho Request

直接言えるのは、

Gi1/0/1 ingressで
Echo Requestを観測した

ことです。

パターン22：ARP Replyが見えず別地点で追加取得

目的は、

Replyがどこまで存在するか
Requestがどこまで到達するか

を追加確認することです。

よくある誤り

送信側で見えたから宛先到達と決める

送信側での観測は、その地点での存在を示します。

宛先側は別に確認します。

1地点で見えないからネットワーク全体に存在しないと決める

非観測は観測地点・方向・時間・フィルタ条件に依存します。

ARP Replyなしを対象ホスト停止と決める

Reply非観測の原因は複数あります。

Echo Replyなしを復路断と決める

Request未到達、Reply未生成、途中損失、フィルタリングなどもあり得ます。

VLANタグをエンドツーエンドで同じと決める

タグ状態は観測地点によって変わり得ます。

1地点のMACアドレスを全リンクへ当てはめる

L2ヘッダはルータ越えで変わり得ます。

TTLだけで通過ルータ数を確定する

初期TTLが不明なら一意に決まりません。

Hop Limitを絶対的な残りHop数として扱う

観測したIPv6パケットのフィールド値として読みます。

要求と応答を同じ方向として扱う

RequestとReplyは方向を分けて追跡します。

キャプチャ結果だけで根本原因を即断する

観測事実と原因仮説を分け、複数地点や別の確認情報と相関します。

切り分けの基本フロー

観測地点を確認
↓
観測方向を確認
↓
対象通信を確認
↓
Ethernetヘッダを読む
↓
802.1Qタグを読む
↓
EtherTypeで上位プロトコルを識別
↓
ARPまたはIPヘッダを読む
↓
TTL / Hop Limitを確認
↓
ICMPなど要求・応答を確認
↓
見えない場合は条件付き非観測として記録
↓
必要なら別地点で追加取得
↓
複数地点を相関して候補範囲を絞る

運用時に記録する情報

取得時刻
観測装置
観測インターフェース
観測方向
対象通信
Ethernet送信元MAC
Ethernet宛先MAC
VLAN ID
EtherType
IP送信元
IP宛先
TTL / Hop Limit
ICMP種別
Request有無
Reply有無

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

観測結果の記録例

観測地点: R1 Gi1/0/1
方向: ingress
時刻: 10:15:00

Ethernet:
  Source MAC: 00:11:22:33:44:55
  Destination MAC: 00:aa:bb:cc:dd:ee
  EtherType: 0x0800

IPv4:
  Source: 192.0.2.10
  Destination: 198.51.100.20
  TTL: 63

ICMP:
  Echo Requestあり

判断：

R1 Gi1/0/1 ingressで
192.0.2.10から198.51.100.20宛ての
ICMP Echo Requestを観測した。

ここから宛先到達までは証明しません。

複数地点比較の記録例

R1 Gi1/0/1 ingress
→ Echo Requestあり

R1 Gi1/0/2 egress
→ Echo Requestあり

R2 Gi1/0/1 ingress
→ Echo Requestなし

判断：

R1出口まではRequestを観測。
R2入口ではRequestを観測していない。
R1出口からR2入口の間を追加確認候補とする。

ARP比較の記録例

地点A
ARP Requestあり
ARP Replyなし

地点B
ARP Requestあり
ARP Replyあり

判断：

地点BではARP Replyを観測。
地点AではReplyを観測していない。
Replyが地点Bから地点Aまで戻る範囲を追加確認する。

ICMP比較の記録例

受信側
Echo Requestあり
Echo Replyあり

送信側
Echo Requestあり
Echo Replyなし

判断：

受信側ではReply生成後の通信を観測。
送信側ではReplyを観測していない。
復路の両地点間を追加確認候補とする。

VLANタグ比較の記録例

トランク側
VLAN 20タグあり

アクセスポート側
同じタグなし

判断：

観測地点ごとにフレーム状態が異なる。
VLANタグの有無だけで異常と即断しない。

TTLとHop Limitの記録例

IPv4：

地点A TTL 63
地点B TTL 62

IPv6：

地点A Hop Limit 63
地点B Hop Limit 62

同一通信として相関できる場合、経路を進む中で値が減少したことを確認する材料になります。

直接証明できること

パケットキャプチャから直接証明できるのは、

その観測地点で
その観測方向に
その条件に一致するパケットを
観測した

という事実です。

直接証明できないこと

1地点の観測だけでは、

エンドツーエンド全体の到達性
往路と復路の完全な経路
宛先アプリケーション正常性
観測地点外のパケット存在
非観測パケットの根本原因

までは証明できません。

最終判断の型

1. 観測地点を固定する
2. 観測方向を固定する
3. L2ヘッダを読む
4. 802.1Qタグを読む
5. EtherTypeで上位プロトコルを決める
6. ARPまたはIPヘッダを読む
7. TTL / Hop Limitを観測値として読む
8. Request / Replyを分ける
9. 非観測を原因確定に使わない
10. 複数地点を相関して範囲を絞る

まとめ

パケットキャプチャは、観測地点と観測方向に依存する確認情報です。

最初に、

どこで
どの方向を
観測したか

を確認します。

Ethernetでは、

Source MAC Address
Destination MAC Address
EtherType

を読み、必要に応じて802.1Qタグを確認します。

EtherTypeから、

ARP
IPv4
IPv6

などの上位プロトコルを識別します。

ARPでは、

Request
Reply

を分け、Replyが見えなくても対象ホスト停止と即断しません。

IPでは、

送信元
宛先
TTL
Hop Limit

を確認します。

TTLやHop Limitは観測地点での値であり、単一地点の値だけから全経路を一意に復元しません。

ICMPでは、

Echo Request
Echo Reply

を対応付けて読みます。

Replyが見えない場合でも、

宛先未到達
Reply未生成
復路途中損失
フィルタリング
観測条件

などを区別できないため、非観測だけで原因を確定しません。

最も重要なのは、

地点Aでは存在
地点Bでは存在
地点Cでは非観測

のように複数地点を相関させ、パケットを観測できる範囲と観測できなくなる範囲を絞ることです。

パケットキャプチャは、観測事実を非常に細かく確認できる一方で、1地点の結果をネットワーク全体へ広げず、直接証明できる範囲だけを判断することが重要です。