IPv4総合トラブルシューティング

このページで学ぶこと

• 症状整理
• 確認情報の選択
• CLI / 設定情報の確認
• Address計算 / 比較
• 原因仮説の作成
• 原因仮説の除外
• 根本原因の特定
• 修正内容の判断
• 修正後の再確認
• IPv4 Addressing以外への切り分け

ページ010〜017では、IPv4アドレス設定を構成する要素と、期待値/ 実際値から確認結果を特定する方法を確認してきました。

ページ018では、それらを1つのトラブルシューティングの流れへ統合します。

ここでの目的は、

誤っている値を1つ見つける

だけではありません。

実際には、

症状を整理する

必要な確認情報を選ぶ

期待値と実際値を比較する

原因仮説を作る

確認情報で仮説を除外する

最も強く支持される原因候補を絞る

必要な修正を判断する

修正後に再確認する

症状の解消によって原因判断を確認する

という一連の流れが必要です。

基本流れは、

症状
↓
期待値
↓
確認情報
↓
実際値
↓
仮説
↓
検証/ 除外
↓
根本原因候補
↓
修正
↓
再確認
↓
根本原因の確認

です。

また、IPv4アドレス設定の主要な確認結果が正常なら、

無理にIPv4アドレス設定を原因にする

のではなく、

IPv4アドレス設定以外へ切り分ける

こともトラブルシューティングの一部です。

1. トラブルシューティングは「症状」と「原因」を分ける

トラブルシューティングの最初では、

何が起きているか

と、

なぜ起きているか

を分けます。

例えば、

PC-AからPC-BへPingできない

は、

症状

です。

一方、

PC-Aのサブネットマスクが
期待値/24ではなく/25

は、

設定上の確認結果

です。

その確認結果が症状を説明できるなら、

根本原因候補

になります。

症状を確認しただけで、

マスクが根本原因

と決めてはいけません。

2. 最初に症状の範囲を絞る

同じ、

通信できない

でも、範囲によって確認対象は変わります。

例えば、

PC-Aだけ通信できない

のか、

PC-AとPC-Bの間だけ通信できない

のか、

同一LAN全体が通信できない

のかでは意味が異なります。

最初に、

誰
どの機器か

何
何ができないか

どこ
どのセグメント/ インターフェースか

範囲
1台だけか複数台か

を整理します。

ページ018では、症状を必要以上に広げません。

3. 「できること」も確認情報として使う

トラブルシューティングでは、

できないこと

だけではなく、

できること

も原因候補を減らす確認情報になります。

例えば、

PC-A
デフォルトゲートウェイへ通信できる

PC-B
デフォルトゲートウェイへ通信できる

PC-A ↔ PC-B
通信できない

なら、

すべてのIPv4通信が失敗している

わけではありません。

逆に、

PC-A
同じLAN上のどのホストにも通信できない

なら、確認範囲は変わります。

正常な通信もトラブルシューティングの確認情報として利用します。

4. 期待値を確認してから実際値を見る

IPv4アドレス設定のトラブルシューティングでは、

実際の設定

だけを見ても、それが正しいか判断できない場合があります。

先に、

期待値

を確認します。

例えば、

期待値

PC-A
192.168.10.10/24

PC-B
192.168.10.20/24

同一LAN

という設計があれば、実際値と比較できます。

期待値には必要に応じて、

IPv4アドレス

プレフィックス/ サブネットマスク

期待するサブネット

割り当て方式

アドレス種別

必要ホスト数

独立サブネットか同一サブネットか

などがあります。

5. 確認情報は確認したい仮説に合わせて選ぶ

すべてのコマンドや情報を最初から集める必要はありません。

例えば、

アドレス/ プレフィックス誤設定

を疑うなら、

現在のIPv4アドレス

サブネットマスク

期待アドレス設計

が必要です。

Cisco IOS / IOS XE 機器なら代表的に、

show ip interface brief

や、

show running-config interface <interface>

などから確認できます。

一方、

ホスト収容数不足

を疑うなら、

プレフィックス

必要ホスト数

の比較が必要です。

確認したい内容に必要な確認情報を選びます。

6. CLI出力は「表示された事実」として読む

例えば、

R1# show ip interface brief

Interface              IP-Address      OK? Method Status Protocol
GigabitEthernet0/0     192.168.10.1   YES manual up     up

から直接確認できるのは、

現在値 IPv4アドレス
192.168.10.1

Status
up

Protocol
up

などです。

さらに、

R1# show running-config interface GigabitEthernet0/0

interface GigabitEthernet0/0
 ip address 192.168.10.1 255.255.255.128

なら、

設定済みプレフィックス
/25

も確認できます。

ただし、

/25だから障害原因

とはまだ言えません。

期待値との比較が必要です。

7. 確認情報を期待値/ 実際値へ整理する

複数情報があるときは、

項目               期待値              実際値              結果
アドレス           192.168.10.1        192.168.10.1        一致
プレフィックス      /24                 /25                 不一致
割り当て           静的                 静的                 一致
インターフェース状態 up/up               up/up               一致

のように整理すると判断しやすくなります。

この例なら、

プレフィックスだけが期待値と不一致

です。

そのため、

アドレスも変更する

という不要な修正を避けられます。

8. 必要ならサブネットを再計算する

実際のアドレス/ プレフィックスが確認できたら、必要に応じて、

ネットワークアドレス

ブロードキャストアドレス

ホスト範囲

サブネット所属

ホスト収容数

サブネット境界

を計算します。

ページ018ではサブネット化公式を再講義しません。

計算は、

原因仮説を検証する確認情報

として使用します。

例えば、

PC-A
10.1.4.30/27

PC-B
10.1.4.33/27

なら、

PC-A
10.1.4.0/27

PC-B
10.1.4.32/27

です。

期待値が同一サブネットなら、

実際の所属

が期待値と矛盾しています。

9. 原因仮説は確認情報から作る

トラブルシューティングでは、

思いついた原因

をそのまま根本原因にしません。

まず、

仮説

として扱います。

例えば、

期待値
PC-A / PC-Bとも192.168.40.0/24

実際値
PC-A 192.168.40.10/25
PC-B 192.168.40.200/24

なら、

仮説

PC-Aのプレフィックス不一致が
通信症状に関係している

という原因仮説を立てられます。

その仮説をサブネット所属や他の確認情報で検証します。

10. 仮説は複数作ってよい

症状だけでは複数原因が成立する場合があります。

例えば、

同一LANの2ホストが通信できない

という症状なら、

アドレス誤設定

プレフィックス誤設定

アドレス欠落

重複アドレス

サブネット所属不一致

などが候補になる可能性があります。

ただし、

考えられるものを全部列挙する

ことが目的ではありません。

症状と既存確認情報に関係する仮説だけを作ります。

11. 仮説を支持する確認情報と仮説を反証する確認情報を確認する

良いトラブルシューティングでは、

自分の仮説を支持する情報

だけを探しません。

仮説が、

IPv4アドレス/ マスク誤設定

なら、

支持する確認情報

期待値/24

実際値 /25

反証する確認情報

アドレス/ マスクとも期待値一致

サブネット所属も期待値一致

です。

反証する確認情報が揃えば、

IPv4アドレス/ マスク誤設定

という仮説を除外します。

12. 原因候補を1つずつ減らす

確認情報ごとに、

支持

棄却

未確認

を整理します。

例えば、

アドレス不一致
棄却

プレフィックス不一致
支持

重複
棄却

割り当て不一致
棄却

なら、プレフィックスに関する仮説が最も強く残ります。

この時点で、

根本原因候補

として扱えます。

ただし、修正後の結果まで確認していない段階では、

根本原因として完全確認済み

とは扱いません。

13. 設定上の確認結果と状態上の確認結果を区別する

ページ017で確認したとおり、

設定が誤っている

ことと、

現在の状態が期待値と違う

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

例えば、

interface GigabitEthernet0/1
 ip address dhcp

があり、

GigabitEthernet0/1
unassigned
YES DHCP
up
up

なら、

DHCPクライアント設定
存在

しています。

確認できる確認結果は、

期待値
アドレス取得済み

実際値
アドレスなし

です。

したがって、

アドレス設定に関する状態上の確認結果

として扱います。

この情報だけで、

ip address dhcpが誤っている

DHCPサーバーが根本原因

とは判断できません。

14. 根本原因候補は症状を説明できる必要がある

ある確認結果を根本原因候補とするには、

その確認結果によって
確認されている症状を説明できるか

を考えます。

例えば、

期待値
R2 = 10.20.30.2/24

実際値
R2 = 10.20.31.2/24

R1
10.20.30.1/24

R1とR2は直接接続

なら、

R2が期待値とは別サブネットへ所属

しているため、

R2のIPv4アドレス誤設定

は通信失敗を説明する強い根本原因候補です。

一方、

インターフェース説明の文字が違う

だけでは、通常このIPv4通信症状を説明できません。

15. 確認結果と根本原因候補を区別する

期待値との差分が存在しても、それだけで症状の根本原因とは限りません。

例えば、

期待する説明
TO-SW1

実際の説明
TO-SW2

という差分があっても、IPv4通信失敗の原因を直接説明しません。

一方、

期待するプレフィックス
/24

実際のプレフィックス
/25

通信相手が実際値 /25のローカル範囲外

なら、通信症状との関係があります。

ページ018では、

違う値

を見つけるだけではなく、

その違いが
症状を説明できるか

まで確認します。

16. 確認情報不足なら根本原因を確定しない

例えば、

設定済み
DHCP

現在値
unassigned

しか分からない場合、

根本原因
DHCPサーバー障害

とは言えません。

直接確認できるのは、

確認済みの結果
IPv4アドレス未取得

までです。

原因候補が複数残っているため、

根本原因未確定

と判断します。

トラブルシューティングでは、

確認情報不足を推測で埋めない

ことも重要です。

17. 複数確認結果がある場合は関係を整理する

1つの機器に複数確認結果が存在する場合があります。

例えば、

期待値

割り当て
静的

アドレス
192.168.10.1/24

実際値：

ip address dhcp

現在値：

203.0.113.10

なら、

割り当て方式不一致

現在のアドレス不一致

アドレス種別不一致

があります。

ここで、

全部が独立した根本原因

とは限りません。

確認情報から、

期待値とは異なるDHCP設定
↓
期待値とは異なるアドレスを取得

という関係が成立するなら、確認結果同士を関連付けられます。

ただし、DHCPサーバー内部の動作まで推測で確定しません。

18. 修正は最も強く支持される原因候補から決める

確認情報によって原因候補が十分絞れたら、

どの値を期待値へ戻すか

を判断します。

例えば、

期待値
PC-A = 192.168.120.50/24

実際値
PC-A = 192.168.120.50/25

で、

アドレス
一致

プレフィックス
不一致

症状とも整合

しているなら、

根本原因候補
PC-Aのプレフィックス/25

です。

修正は、

PC-Aのプレフィックスを
期待値/24へ修正

です。

正常なアドレスまで変更しません。

19. 修正は期待する設定を基準にする

トラブルシューティングでは、

通信できるようになれば
どんな値でもよい

とは考えません。

例えば、

期待値
A = 192.168.30.10/24
B = 192.168.30.200/24

実際値
A = 192.168.30.10/25

だった場合、

Bを192.168.30.20へ変更する

ことで通信条件が変わる可能性はあります。

しかし、

期待する設計

を無視しています。

修正は、

不一致であるAのプレフィックスを
期待値/24へ戻す

ことです。

20. 変更する項目を必要最小限にする

複数の値を一度に変更すると、

どの変更が結果へ影響したか

が分かりにくくなります。

例えば、

アドレス

マスク

割り当て方式

を全部同時に変更して通信が回復しても、

どの確認結果が症状へ関係していたか

を確認しにくくなります。

可能な限り、

確認情報で支持された原因候補に対応する
必要最小限の修正

へ絞ります。

21. コマンド暗記より修正の意味を判断する

ページ018では、

特定のコマンド文字列を暗記する

ことを必須にしません。

重要なのは、

何を

期待値の何へ

なぜ変更するか

です。

例えば、

誤り
プレフィックス/25

期待値
/24

なら、

修正
対象インターフェースのプレフィックスを/24へ修正

と判断できる必要があります。

問題文にCisco IOS / IOS XE 設定が与えられた場合は、その内容を読める必要があります。

22. 修正後に設定/ 状態を再確認する

変更コマンドを投入しただけでは終了しません。

まず、

修正値が本当に反映されたか

を確認します。

例えば、

期待値
192.168.120.50/24

へ修正したなら、

現在のアドレス
192.168.120.50

現在のプレフィックス
/24

になっているか確認します。

23. 元の症状を再試験する

修正が反映されても、トラブルシューティング完了とは限りません。

元の症状が、

PC-AからPC-Bへ通信できない

だったなら、

PC-AからPC-Bへの通信

を再試験します。

つまり、

設定/ 状態の確認
+
元の症状の再試験

の両方が必要です。

24. 修正後の結果で原因判断を確認する

確認情報から、

根本原因候補

としていた値を期待値へ修正し、

修正値
期待値と一致

元の症状
解消

となれば、

その原因候補が
実際の根本原因だった

という判断が強く確認されます。

つまり、

候補
↓
修正
↓
再確認
↓
症状の解消
↓
根本原因の確認

です。

25. 症状が残るなら原因判断を再評価する

修正後も、

元の症状が残る

なら、

修正した値は期待値どおりか

原因候補は症状全体を説明していたか

別の確認結果が残っていないか

複数原因が存在しないか

を再評価します。

この場合、

最初の原因候補が完全な根本原因ではなかった

可能性があります。

修正した値が実際に誤設定だったとしても、それだけが症状の原因とは限りません。

26. 関連確認情報も必要に応じて再確認する

問題の種類によって、元の症状以外の確認情報も再確認します。

重複アドレスなら、

アドレスの一意性

重複メッセージの再発有無

を確認します。

プレフィックス誤設定なら、

現在のプレフィックス

サブネット所属

期待する範囲

を確認します。

割り当てに関する問題なら、

設定済みの割り当て

現在のアドレス

期待する割り当て

を確認します。

27. IPv4アドレス設定仮説を除外する

問題に関連する、

アドレス

プレフィックス

サブネット所属

ネットワーク/ ブロードキャスト

収容数

重複

割り当て方式

現在のアドレス

アドレス種別

などを確認し、期待値と一致しているなら、

IPv4アドレス設定の誤り

という仮説は弱くなります。

ここで、

とりあえずアドレスを変更してみる

のは適切ではありません。

28. アドレス設定以外へ切り分ける

IPv4アドレス設定の主要確認情報が正常なら、

次のトラブルシューティング領域へ進む

と判断します。

例えば、

レイヤー2

ルーティング

DHCP内部

物理

ホスト側要因

などが次候補になり得ます。

ただしページ018では、

どのVLAN設定が誤っているか

どのルートが選ばれているか

DHCPメッセージ交換のどこで失敗したか

まで診断しません。

ページ018で必要なのは、

IPv4アドレス設定内に
直接支持される原因がない
↓
別領域へ切り分ける

という判断です。

29. エンドツーエンドケース 1：プレフィックスに関する確認結果を修正後に確認する

設計：

PC-A
192.168.30.10/24

PC-B
192.168.30.200/24

同一LAN

実際値：

PC-A
192.168.30.10/25

PC-B
192.168.30.200/24

症状：

PC-AとPC-Bが期待どおり通信できない

手順 1：期待値/ 実際値

PC-A

アドレス
一致

プレフィックス
期待値/24
実際値   /25
→ 不一致

PC-B

アドレス
一致

プレフィックス
一致

手順 2：サブネット計算

PC-Aの/25では、

192.168.30.0
～
192.168.30.127

がローカルサブネットです。

PC-Bの、

192.168.30.200

はその範囲外です。

したがって、

PC-Aのサブネット認識が
期待する設計と一致していない

ことは確認できます。

手順 3：根本原因候補

この時点では、

PC-Aのプレフィックス/25

は、

期待値と明確に不一致し
通信症状にも関係し得る
強い根本原因候補

です。

ただし、

これだけで通信失敗の根本原因確定

とはしません。

手順 4：修正

PC-Aのプレフィックスを
期待値/24へ修正

します。

手順 5：再確認

PC-A
192.168.30.10/24

になったことを確認します。

さらに、

PC-AとPC-Bが
同じ192.168.30.0/24へ所属

することを確認します。

手順 6：症状の再試験

PC-A ↔ PC-B

の元の通信を再試験します。

その結果、

元の症状が解消

したなら、

PC-Aのプレフィックス誤設定が
根本原因だった

と確認できます。

このケースの重要点は、

確認結果
↓
候補
↓
修正
↓
再試験
↓
確認

まで進むことです。

30. エンドツーエンドケース 2：IPv4アドレス値

設計：

R1
10.20.30.1/24

R2
10.20.30.2/24

直接接続

実際値：

R1
10.20.30.1/24

R2
10.20.31.2/24

両インターフェース
up/up

症状：

R1とR2が期待どおり直接通信できない

比較すると、

R1
期待値と一致

R2 プレフィックス
期待値と一致

R2 アドレス
期待値と不一致

です。

サブネットも、

R1
10.20.30.0/24

R2
10.20.31.0/24

です。

したがって、

根本原因候補
R2のIPv4アドレス誤設定

が強く支持されます。

修正：

R2を
期待値 10.20.30.2/24
へ修正

します。

その後、

現在のアドレス/ プレフィックス

両端のサブネット所属

R1 ↔ R2通信

を再確認します。

元の症状が解消すれば、

R2のIPv4アドレス誤設定

を根本原因として確認できます。

31. エンドツーエンドケース 3：重複アドレス

設計：

R1
10.10.10.1/24

R2
10.10.10.2/24

実際値：

R1
10.10.10.1/24

R2
10.10.10.1/24

さらに、

%IP-4-DUPADDR

が確認されたとします。

比較すると、

期待値
R2 = 10.10.10.2

実際値
R2 = 10.10.10.1

で、R1と同じアドレスです。

通常のインターフェースアドレス設定で、設計上意図した共有アドレスではないことも確認できているなら、

根本原因候補
重複IPv4アドレス

が強く支持されます。

修正：

R2を
期待値 10.10.10.2/24
へ修正

します。

修正後は、

R1 / R2のアドレス一意性

現在のアドレス

重複メッセージの再発有無

元の通信症状

を確認します。

症状が解消し、重複を示す確認情報も消えたなら、

重複IPv4アドレス

を根本原因として確認できます。

32. エンドツーエンドケース 4：アドレス設定では原因を確認できない

症状：

同一LANのPC-AとPC-Bが通信できない

確認結果：

インターフェース
期待状態

アドレス
期待値と一致

プレフィックス
期待値と一致

サブネット所属
一致

ネットワークアドレス/ブロードキャストアドレスの誤使用
なし

割り当て方式
期待値と一致

現在のアドレス
正常

重複を示す情報
なし

アドレス種別
期待値と一致

なら、

IPv4アドレス設定内に
症状を直接説明する確認結果がない

と判断できます。

ここで、

アドレスを別値へ変更する

プレフィックスを広げる

などは行いません。

次の対応は、

IPv4アドレス設定仮説の優先度を下げる

別トラブルシューティング領域へ切り分ける

ことです。

33. よくある誤判断

誤り1：症状を見ただけで原因を決める

通信できない
=
マスク誤り

とは限りません。

確認情報で検証します。

誤り2：最初に思いついた仮説へ固定する

仮説を反証する確認情報があれば仮説を除外します。

誤り3：期待値を確認せず実際値だけを見る

実際値の正誤を判断できません。

誤り4：確認結果を見つけた時点で根本原因確定とする

確認結果が症状を説明できるか確認し、修正後の再試験まで含めて判断します。

誤り5：DHCP + unassignedからDHCPサーバー障害を確定する

直接確認できるのはアドレス未取得という状態です。

誤り6：複数値を同時に変更する

どの修正が結果へ影響したか分かりにくくなります。

誤り7：通信できれば設計と違う値でもよい

修正は期待する設定を基準にします。

誤り8：設定を変更したら終了する

設定/ 状態と元の症状を再確認します。

誤り9：修正後も症状が残るのに根本原因確定済みとする

原因候補や残る確認結果を再評価します。

誤り10：アドレス設定の確認情報が正常でもアドレスを変更し続ける

別トラブルシューティング領域へ切り分けます。

34. IPv4総合トラブルシューティングの基本手順

1. 症状を明確化

        ↓

2. 期待する設定/ 設計を確認

        ↓

3. 必要な確認情報を選択

        ↓

4. 実際の設定/ 状態を確認

        ↓

5. 必要なサブネット計算・比較

        ↓

6. 原因仮説を作成

        ↓

7. 支持/ 仮説を反証する確認情報を確認

        ↓

8. 成立しない仮説を除外

        ↓

9. 症状を説明する
   根本原因候補を絞る

        ↓

10. 期待値を基準に
    修正を判断

        ↓

11. 必要最小限の値を修正

        ↓

12. 設定/ 状態を再確認

        ↓

13. 元の症状を再試験

        ↓

14. 症状解消なら
    根本原因判断を確認

        ↓

15. 未解決なら
    候補/ 確認結果を再評価

        ↓

16. アドレス設定が正常なら
    別領域へ切り分け

この流れを毎回機械的にすべて実行することが目的ではありません。

問題に応じて必要な手順を選びます。

重要なのは、

推測
↓
変更

ではなく、

確認情報
↓
候補
↓
必要な修正
↓
再確認
↓
結果による確認

という順序です。

35. 最終的に判断できるようにすること

ページ018では最終的に、

症状を限定できる

期待値を確認できる

必要な確認情報を選べる

CLI / 設定から事実を読める

アドレス/ プレフィックスを必要に応じて計算できる

期待値と実際値を比較できる

原因仮説を作れる

支持/ 仮説を反証する確認情報を区別できる

成立しない仮説を除外できる

根本原因候補を絞れる

期待値を基準に修正を判断できる

正常な値を不用意に変更しない

修正後に設定/ 状態を再確認できる

元の症状を再試験できる

結果から根本原因判断を確認または再評価できる

アドレス設定以外へ切り分ける状況を判断できる

必要があります。

まとめ

IPv4アドレス設定のトラブルシューティングでは、

通信できない

という症状から、いきなり設定変更を始めません。

まず、

症状

を明確にします。

次に、

期待値

を確認し、

実際の設定/ 状態

と比較します。

必要に応じて、

IPv4アドレス

プレフィックス

サブネット所属

ネットワーク/ ブロードキャスト

ホスト収容数

重複

割り当て方式

現在のアドレス

アドレス種別

を確認情報として使用します。

そこから、

仮説

を作り、

支持する確認情報

反証する確認情報

で検証します。

成立しない仮説は除外します。

そして、

期待値と矛盾し

症状を説明でき

他の確認情報とも整合する原因候補

を、

根本原因候補

として絞ります。

修正は、

通信できそうな値

ではなく、

期待する設定

を基準に判断します。

変更対象も、

確認情報で支持された原因候補に必要な範囲

へ絞ります。

修正後は、

設定/ 状態の再確認

元の症状の再試験

必要な関連確認情報の再確認

を行います。

その結果、

期待値へ修正済み

元の症状解消

となれば、

原因候補が根本原因だった

という判断を確認できます。

一方、症状が残るなら、

根本原因候補

残る確認結果

他の原因候補

を再評価します。

また、問題に関連するIPv4アドレス設定の確認情報が期待値と一致しているなら、

IPv4アドレス設定が根本原因

という仮説の優先度を下げます。

その場合は、

無理にアドレスを変更する

のではなく、

別のトラブルシューティング領域へ切り分ける

ことが正しい判断です。

ページ018での最終流れは、

症状
↓
期待値
↓
確認情報
↓
実際値
↓
計算 / 比較
↓
仮説
↓
検証/ 除外
↓
根本原因候補
↓
修正
↓
再確認
↓
根本原因の確認/ 再評価
↓
必要なら別領域へ切り分け

です。

これでIPv4アドレス設定・割り当て・サブネット化のトラブルシューティングをエンドツーエンドで扱える状態になります。

次のページ019からは、IPv6アドレス表記の確認を開始します。