IPv6総合Troubleshooting

このページで学ぶこと

• 症状整理
• 確認情報の選択
• 設定と実稼働状態の相関
• Address / Prefix計算
• 割り当て方式の診断
• RA flag診断
• Default Router診断
• EUI-64診断
• 仮説の除外
• 根本原因の特定
• 修正判断
• 修正後確認

ページ019〜025では、IPv6アドレス設定を構成する要素を個別に確認してきました。

ページ019
→ IPv6アドレス表記

ページ020
→ IPv6プレフィックスサイズ

ページ021
→ IPv6ユニキャストアドレス種別/範囲

ページ022
→ IPv6インターフェース設定

ページ023
→ Modified EUI-64

ページ024
→ IPv6アドレス割り当て

ページ025
→ IPv6確認

ページ026では、これらを1つのトラブルシューティングシナリオとして統合します。

実際の障害対応では、

アドレスがない

通信できない

DNS情報がない

デフォルトルーターがない

期待と違うアドレスが付いている

という症状だけでは、根本原因は決まりません。

基本流れは、

症状
↓
期待状態
↓
実際状態
↓
必要な確認情報を選択
↓
複数の原因候補を作る
↓
確認
↓
原因候補を除外
↓
根本原因
↓
最小修正
↓
再試験
↓
期待状態との再比較

です。

1. トラブルシューティングは「原因を当てる作業」ではない

IPv6トラブルシューティングで最初に行うことは、

すぐに設定を変更する

ことではありません。

最初に整理するのは、

何が起きているか

本来どうなるべきか

実際にはどうなっているか

です。

つまり、

症状

期待値

実際値

を分離します。

例えば、

SLAACアドレスが存在しない

という症状だけから、

RAが悪い

と即断してはいけません。

2. 症状と根本原因を分離する

次の状態を考えます。

GigabitEthernet0/0

リンクローカルアドレス
→ 存在

グローバル側アドレス
→ なし

これは、

症状

です。

原因候補には、

SLAAC設定がない

RAを受信していない

広告されたプレフィックスが期待と違う

Aフラグが期待と違う

プレフィックス長がSLAAC条件と合わない

などがあります。

したがって、

症状
≠
根本原因

です。

3. 最初に期待状態を固定する

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

何が正解なのか

が決まっていないと、実際値との差を判断できません。

例えば要件が、

割り当て
→ SLAAC

期待値プレフィックス
→ 2001:db8:10:1::/64

デフォルトルーター
→ RAから取得

なら、この3点が期待値です。

実際値側でアドレスが存在していても、

ステートフルDHCPv6で取得したアドレス

なら、要求された方式とは一致していません。

4. アドレスの存在だけで正常判定しない

IPv6アドレスが存在することと、

正しいアドレスである

正しいプレフィックスである

正しい方式で取得している

必要なデフォルトルーターが存在する

ことは別です。

例えば、

期待値
2001:db8:10:1::10/64

実際値
2001:db8:10:2::10/64

ならアドレスは存在します。

しかし、

期待値プレフィックス
≠
実際値プレフィックス

なので正常ではありません。

5. 設定と動作状態も分離する

実行中設定に、

ipv6 address autoconfig

が存在していても、

SLAACアドレスが実際に生成されている

とは限りません。

反対に、動作上の出力にアドレスが存在していても、

どの設定から得られたアドレスか

はアドレスだけでは決められない場合があります。

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

設定

動作状態

受信済み情報

を相関します。

6. 確認したい情報からコマンドを選択する

ページ025で扱った確認コマンドを、ページ026では原因切り分けのために使用します。

インターフェース/アドレス一覧
↓
show ipv6 interface brief

特定インターフェースの
IPv6詳細状態
↓
show ipv6 interface <interface>

インターフェース設定
↓
show running-config interface <interface>

DHCPv6クライアント状態
↓
show ipv6 dhcp interface <interface>

受信RA
ルーター有効期間
M/O
広告されたプレフィックス
↓
show ipv6 routers <interface>

重要なのは、

コマンドを知っている

だけではなく、

今の仮説を検証するには
どの情報が必要か

からコマンドを選択することです。

7. 最初の仮説をそのまま原因にしない

例えば、

SLAACアドレスがない

という症状を見たとき、

最初の仮説が、

RAを受信していない

だったとしても、即修正しません。

まず、

show ipv6 routers GigabitEthernet0/0

などから、RA受信状態を確認します。

RAが正常に存在していれば、

RA未受信

という仮説を除外できます。

8. 複数の仮説を比較する

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

仮説 A
仮説 B
仮説 C

を持ち、確認情報で減らします。

例えばSLAACアドレスがない場合、

仮説 A
→ クライアント設定不一致

仮説 B
→ RA未受信

仮説 C
→ Aフラグ不一致

仮説 D
→ 広告されたプレフィックス長不一致

仮説 E
→ 広告されたプレフィックス自体が不一致

という形です。

1つずつ出力で除外していきます。

9. プレフィックスは見た目ではなくビット境界で比較する

次の2つを考えます。

R1
2001:db8:10:1::1/64

R2
2001:db8:10:2::2/64

両方とも、

2001:db8

から始まっています。

しかし /64 では、

2001:db8:10:1

と、

2001:db8:10:2

は異なるプレフィックスです。

同一LAN上で同一プレフィックスが要求されているなら、

アドレス/プレフィックス不一致

が原因候補になります。

10. ホスト部分が似ていてもプレフィックス不一致は解消されない

例えば、

期待値
2001:db8:20:1::10/64

実際値
2001:db8:20:2::10/64

では、

::10

が同じです。

しかしトラブルシューティングで比較するのは、

アドレス全体

プレフィックス長

期待値ネットワーク

です。

したがって、

ホスト側が同じ

という理由で一致とは判断しません。

11. リンクローカルだけ存在する状態を正しく読む

出力：

GigabitEthernet0/0     [up/up]
    FE80::21A:2BFF:FE3C:4D5E

グローバル側アドレスがありません。

この状態から分かるのは、

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

リンクローカル
→ 存在

グローバル側アドレス
→ なし

までです。

ここだけから、

IPv6全体が無効

RAが必ず悪い

DHCPv6が必ず悪い

とは判断しません。

12. SLAACトラブルシューティングは処理の連鎖を見る

SLAACを期待している場合は、概念的に、

クライアント設定
↓
RA受信
↓
プレフィックス情報
↓
自律条件
↓
プレフィックス/インターフェース識別子条件
↓
アドレス生成
↓
動作上のアドレス

という連鎖で確認します。

どこまで正常なのかを特定することで、原因候補を狭めます。

13. SLAAC設定があるか確認する

Cisco IOSクライアントで期待値がSLAACなら、実行中設定で例えば、

interface GigabitEthernet0/0
 ipv6 address autoconfig

を確認します。

設定が存在しない場合、

クライアント側が期待した割り当て方式を要求していない

という差分になります。

設定が存在しているなら、次はRA側へ進みます。

14. SLAAC設定があってもアドレス生成成功とは限らない

設定：

ipv6 address autoconfig

動作上：

リンクローカルのみ

なら、

クライアント設定
→ 存在

グローバルSLAACアドレス
→ なし

です。

この時点ではクライアント設定だけを何度見ても原因は絞れません。

次に、

show ipv6 routers GigabitEthernet0/0

を確認します。

15. RAを受信しているか確認する

例えば、

Router FE80::1 on GigabitEthernet0/0
  Lifetime 1800 sec
  AddrFlag=0
  OtherFlag=0

  Prefix 2001:db8:20:1::/64 onlink autoconfig

が存在するなら、

RA送信元
→ 存在

ルーター
→ FE80::1

広告されたプレフィックス
→ 存在

自動設定情報
→ 存在

と判断できます。

したがって、

RAをまったく受信していない

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

16. RAがない場合は「RAなし」という事実を確定する

期待値：

SLAAC

設定：

ipv6 address autoconfig

動作上：

リンクローカルのみ

さらに、

show ipv6 routers GigabitEthernet0/0

で期待するルーター広告を確認できない場合、

クライアント設定
→ SLAAC

動作上のアドレス
→ なし

期待するRA
→ 未確認

という切り分けができます。

ページ026では、この確認情報を根本原因判断へ使用します。

17. SLAACではAフラグの位置を間違えない

SLAACで確認する自律フラグは、

RAヘッダー

ではなく、

プレフィックス情報オプション

側です。

概念的には、

プレフィックス
2001:db8:20:1::/64

A
1

なら、そのプレフィックスはステートレスアドレス自動設定への利用を示しています。

M/Oとは別の情報です。

18. A=1だけではSLAAC成功とは限らない

次のRAを考えます。

RAヘッダー
M=0
O=0

プレフィックス情報オプション
プレフィックス = 2001:db8:20::/60
A=1

Aフラグは自律設定を許可しています。

しかしCisco Ethernet系インターフェースで通常扱う64ビットインターフェース識別子と組み合わせるSLAACでは、

/60 + 64ビットインターフェース識別子

では128ビットになりません。

したがって、このシナリオでは、

広告されたプレフィックス長
→ SLAAC条件と不整合

が有力な原因です。

19. /60が常に間違いなのではない

ここで重要なのは、

IPv6では/60を使ってはいけない

という意味ではないことです。

ページ020で確認したように、IPv6プレフィックスには、

/48
/56
/60
/64

など様々な長さがあります。

今回問題なのは、

SLAACで64ビットインターフェース識別子と組み合わせるプレフィックス

として /60 が提示されていることです。

用途とプレフィックス長を関連付けて判断します。

20. SLAAC失敗では3点を優先確認する

SLAACアドレスが形成されない場合、少なくとも、

RAを受信しているか

プレフィックス情報オプションの
Aフラグが期待どおりか

広告されたプレフィックスが
SLAAC条件と整合するか

を確認します。

これらを確認せず、

DHCPv6がデフォルトルーターを配布していない

など別の役割を原因にしません。

21. M/OフラグはDHCPv6利用に関する情報として確認する

RAヘッダーの、

M
O

は、DHCPv6利用に関係する確認情報です。

教材上は、

M=0
O=0
→ このRAではDHCPv6利用を示していない

M=0
O=1
→ アドレス以外の追加情報を
   DHCPv6から取得する構成を示す

M=1
→ 管理対象アドレス設定を示す

として、期待する割り当て方式との整合を確認します。

一方、SLAACについては、

プレフィックス情報オプションのAフラグ

広告されたプレフィックス

プレフィックス長

などを別に確認します。

したがって、

M/O
→ DHCPv6利用に関する情報

Aフラグ/プレフィックス情報
→ SLAACに関する情報

として分離します。

また、M/Oフラグだけで、

実際にアドレス取得が成功した

DHCPv6サーバーとの交換が成功した

まで確定しません。

22. ステートレスDHCPv6では役割を分解する

期待値：

アドレス
→ SLAAC

DNS等の追加情報
→ DHCPv6

デフォルトルーター
→ RA

とします。

この場合、

SLAACアドレスが存在する

から分かるのはアドレス生成側です。

DNS等がない場合は、

追加情報側

を別にトラブルシューティングします。

23. SLAACアドレスがあるのにDNS等だけないケース

次の状態を考えます。

グローバルSLAACアドレス
→ 存在

デフォルトルーター
→ 存在

DHCPv6追加情報
→ なし

RA：

M=0
O=0

プレフィックス
2001:db8:30:1::/64
A=1

この場合、

SLAACアドレス生成
→ 成立している

プレフィックス/Aフラグ
→ SLAAC観点では整合

Oフラグ
→ ステートレスDHCPv6設計と不一致

と切り分けられます。

24. 正常な部分まで原因扱いしない

前のケースでは、

A=1

広告されたプレフィックス=/64

グローバルSLAACアドレスの存在

です。

これらは、

アドレス生成が成功している

ことを示す確認情報です。

したがって、DNS等だけがない症状に対して、

SLAACプレフィックスを変更する

アドレス方式そのものをステートフルへ変更する

といった修正は、根本原因に対応していません。

25. ステートフルDHCPv6もアドレスとデフォルトルーターを分離する

期待値：

アドレス
→ ステートフルDHCPv6

デフォルトルーター
→ RA

とします。

show ipv6 dhcp interfaceで、

割り当て済みアドレス
→ 存在

でも、

デフォルトルーター
→ 存在

とは限りません。

アドレス取得とデフォルトルーター探索は別です。

26. DHCPv6アドレス取得済みでもRAを確認する

シナリオ：

DHCPv6割り当て済みアドレス
2001:db8:50::25

デフォルトルーター
なし

なら、

DHCPv6アドレス割り当て
→ 成功

デフォルトルーター
→ 問題あり

です。

次に見るべきなのは、

show ipv6 routers GigabitEthernet0/0

です。

DHCPv6アドレスをもう一度確認するだけではデフォルトルーター問題を切り分けられません。

27. ルーター有効期間を根本原因判断に使う

RA：

Router FE80::1 on GigabitEthernet0/0
  Lifetime 1800 sec

なら、

デフォルトルーター候補として利用可能な
0以外のルーター有効期間

が広告されています。

一方、

有効期間 0 sec

なら、

そのRA送信元を
デフォルトルーターとして広告していない

という確認情報です。

デフォルトルーターがない症状では、この違いが重要です。

28. デフォルトルーター問題でDHCPv6を原因にしない

ステートフルDHCPv6でアドレスを取得している場合でも、

デフォルトルーター情報源
→ RA

という役割は変わりません。

したがって、

DHCPv6サーバーから
デフォルトゲートウェイオプションを受信できていない

という仮説を中心にしません。

確認対象は、

RA受信

ルーター有効期間

クライアント側のCisco IOS設定

です。

29. Cisco IOS autoconfigとautoconfig defaultを切り分ける

次の設定：

interface GigabitEthernet0/0
 ipv6 address autoconfig

で、

SLAACアドレス
→ 存在

なら、アドレス自動設定自体は成功しています。

しかし要件が、

RAで選択したルーターを使う
デフォルトルートも必要

なら、Cisco IOSクライアント設定では、

ipv6 address autoconfig default

との差を確認します。

30. アドレス成功とデフォルトルート要件を混同しない

シナリオ：

interface GigabitEthernet0/0
 ipv6 address autoconfig

RA：

Router FE80::1
Lifetime 1800 sec

Prefix 2001:db8:40:1::/64 autoconfig

動作上：

2001:db8:40:1:21a:2bff:fe3c:4d5e/64

要件：

SLAACアドレス
+
RAで選択したルーターを利用するデフォルトルート

この場合、

SLAACアドレス生成
→ 成功

RA受信
→ 成功

0以外ルーター有効期間
→ 存在

autoconfig default
→ なし

です。

したがって有力な根本原因は、

アドレス生成失敗

ではなく、

クライアント設定が
デフォルトルート登録要件を満たしていない

ことです。

31. 割り当て方式不一致を見抜く

期待値：

ステートフルDHCPv6

設定：

interface GigabitEthernet0/0
 ipv6 address autoconfig

動作上：

2001:db8:60:1:21a:2bff:fe3c:4d5e/64

なら、

期待値
→ ステートフルDHCPv6

設定済み
→ SLAAC

動作結果
→ SLAACアドレス

です。

アドレスが存在するため、

IPv6アドレス設定は正常

とは判断しません。

根本原因は、

期待する割り当て方式
と
設定済み割り当て方式
の不一致

です。

32. 根本原因は「最も直接的な不一致」を選ぶ

トラブルシューティングでは、正常な情報まで原因扱いすると判断を誤ります。

例えば、

SLAACアドレス
→ 存在

RAプレフィックス
→ /64

Aフラグ
→ 自律

ルーター有効期間
→ 0以外

なのに、

autoconfig default
→ なし

でデフォルトルート要件だけ満たしていないなら、

根本原因として選ぶべきなのは、

autoconfig defaultの設定差分

です。

正常な /64プレフィックスを変更する理由はありません。

33. Modified EUI-64は途中計算まで確認する

EUI-64ベースのアドレスが期待されている場合、

MAC

FF:FE挿入

U/Lビット

インターフェース識別子

プレフィックス

を比較します。

最終アドレスが違う場合でも、

どの段階で違ったか

を確認します。

34. EUI-64ケース：U/Lビット反転を確認する

MAC：

00:1A:2B:3C:4D:5E

まず、

00:1A:2B
3C:4D:5E

へ分けます。

FF:FE を挿入すると、

00:1A:2B:FF:FE:3C:4D:5E

です。

先頭バイト：

00

のU/Lビットを反転すると、

00 XOR 02
=
02

です。

したがって期待インターフェース識別子は、

021A:2BFF:FE3C:4D5E

になります。

35. FFFEが正しくてもU/Lビットが間違う場合がある

実稼働アドレス：

2001:db8:50:1:001a:2bff:fe3c:4d5e

を見ると、

FFFE

は正しい位置にあります。

しかし先頭は、

001a

です。

期待は、

021a

なので、

FFFE挿入
→ 正常

U/Lビット反転
→ 不一致

です。

この場合、FFFEを原因にしません。

36. 別のMACでも同じ考え方を使う

MAC：

0C:11:22:33:44:55

なら先頭バイトは、

0C

です。

U/Lビット反転は、

0C XOR 02
=
0E

です。

したがって期待インターフェース識別子は、

0e11:22ff:fe33:4455

です。

実際のインターフェース識別子が、

0c11:22ff:fe33:4455

なら、

FFFE
→ 正常

後半24ビット
→ 正常

U/Lビット
→ 誤り

と切り分けられます。

37. アドレス種別/範囲も原因候補になる

ページ021で確認したアドレス種別もトラブルシューティングで使用します。

例えば、

FE80::/10

のリンクローカルアドレスだけが存在している状態と、

グローバル側アドレス

が存在する状態は意味が異なります。

またリンクローカルは、

同一リンク内

で使用されるアドレスです。

別リンク宛先へ到達できない問題で、

リンクローカルしか存在しない

ことは重要な確認情報になります。

ただしルーティングプロトコルやルーティング表の本格解析まではここでは行いません。

38. 「どこまで正常か」を明確にする

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

全部壊れている

と考えるのではなく、

インターフェース
→ 正常

リンクローカル
→ 正常

RA受信
→ 正常

プレフィックス
→ 正常

SLAACアドレス
→ 正常

DHCPv6追加情報
→ 異常

のように整理します。

正常部分を固定すると、修正対象が小さくなります。

39. 根本原因確定前に修正しない

例えばSLAACアドレスがないからといって、

ipv6 address autoconfig default

へ変更しても、

広告されたプレフィックスが /60 ならアドレス生成問題は解決しません。

defaultキーワードは、

デフォルトルート登録

に関係する設定であり、

SLAAC用プレフィックス長の問題

を修正するものではありません。

40. 修正は根本原因へ直接対応させる

根本原因：

広告されたSLAACプレフィックス
→ /60

なら、修正対象は、

SLAAC用に広告するプレフィックス条件

です。

根本原因：

ステートレスDHCPv6設計なのに
Oフラグが期待と不一致

なら、修正対象は、

RA側のその他設定条件

です。

根本原因：

ステートフルDHCPv6要件なのに
クライアントがautoconfig

なら、修正対象は、

クライアント割り当て設定

です。

41. 最小修正を選ぶ

トラブルシューティングで根本原因を特定したあと、

IPv6関連設定を全部削除して
最初から作り直す

ことを基本方針にはしません。

修正は、

根本原因
↓
その原因に直接対応する設定
↓
必要最小限の変更

とします。

これにより、正常な部分を壊すリスクを減らせます。

42. ケース 1：同一LANのプレフィックスが違う

期待値：

R1とR2
→ 同一/64

実際値：

R1
2001:db8:10:1::1/64

R2
2001:db8:10:2::2/64

確認：

R1プレフィックス
2001:db8:10:1::/64

R2プレフィックス
2001:db8:10:2::/64

根本原因：

アドレス/プレフィックス設定不一致

です。

修正は、設計で要求された正しいプレフィックスへ不一致側を合わせます。

43. ケース 2：SLAAC設定あり、アドレスなし

設定：

ipv6 address autoconfig

動作上：

リンクローカルのみ

RA：

プレフィックス 2001:db8:20::/60 autoconfig

Aフラグ：

1

なら、

クライアント設定
→ 正常

RA受信
→ 存在

Aフラグ
→ 自律

プレフィックス長
→ SLAAC条件と不整合

です。

根本原因：

広告されたプレフィックス長

へ絞れます。

44. ケース 3：SLAAC設定あり、RAなし

設定：

ipv6 address autoconfig

動作上：

リンクローカルのみ

さらに、

show ipv6 routers GigabitEthernet0/0

で期待するルーター/プレフィックスを確認できない場合、

クライアント設定
→ 存在

期待するRA
→ 未確認

グローバルアドレス
→ なし

です。

このケースでは、プレフィックス計算より先に、

RAがクライアントへ到達しているか

という仮説を優先できます。

45. ケース 4：SLAACアドレスはあるがDNS情報がない

期待値：

アドレス
→ SLAAC

DNS
→ ステートレスDHCPv6

実際値：

SLAACアドレス
→ 存在

DHCPv6追加情報
→ なし

RA：

M=0
O=0

プレフィックス
2001:db8:30:1::/64
A=1

なら、

SLAAC
→ 成功

プレフィックス
→ 正常

Aフラグ
→ 正常

Oフラグ
→ 期待する方式がステートレスDHCPv6と不一致

です。

根本原因として、追加情報側へ絞れます。

46. ケース 5：ステートフルDHCPv6アドレスはあるがデフォルトルーターがない

期待値：

アドレス
→ ステートフルDHCPv6

デフォルトルーター
→ RA

実際値：

DHCPv6割り当て済みアドレス
→ 存在

デフォルトルーター
→ なし

この時点で、

DHCPv6アドレス割り当て

を原因候補から下げます。

次の確認は、

show ipv6 routers

による、

RA送信元

ルーター有効期間

です。

47. ケース 6：autoconfig default要件との不一致

要件：

SLAACアドレス
+
RAルーターを使用した
Cisco IOSデフォルトルート動作

実際値設定：

ipv6 address autoconfig

動作上：

SLAACアドレス
→ 存在

RA：

Router FE80::1
Lifetime 1800 sec

なら、

アドレス生成
→ 成功

RA
→ 存在

デフォルトルーターとして利用可能な有効期間
→ 存在

defaultキーワード
→ なし

です。

根本原因：

クライアント設定不一致

と判断できます。

48. ケース 7：期待する方式がステートフルDHCPv6なのに実際の方式がSLAAC

期待値：

ステートフルDHCPv6

設定：

ipv6 address autoconfig

動作上：

SLAACアドレス
→ 存在

なら、

アドレスの存在
→ あり

要件適合性
→ 不適合

です。

根本原因：

割り当て方式不一致

です。

49. ケース 8：Modified EUI-64の結果が違う

期待値条件：

MAC
00:1A:2B:3C:4D:5E

プレフィックス
2001:db8:50:1::/64

期待するインターフェース識別子：

021a:2bff:fe3c:4d5e

実際のインターフェース識別子：

001a:2bff:fe3c:4d5e

なら、

FFFE
→ 正常

MAC後半
→ 正常

U/Lビット
→ 誤り

です。

根本原因候補を、

U/Lビット反転

まで絞れます。

50. 修正しただけではトラブルシューティング完了ではない

例えば、

RAプレフィックス/60

が根本原因で、

/64

へ修正したとします。

設定変更コマンドが成功しても、

トラブルシューティング完了

ではありません。

次に、

クライアントへ期待するSLAACアドレスが
実際に生成されたか

を確認します。

51. 修正後は根本原因に対応する情報を取り直す

修正前：

RAプレフィックス
→ /60

SLAACアドレス
→ なし

修正後：

RAプレフィックス
→ /64

なら、再試験では、

show ipv6 routers

で新しいRAプレフィックスを確認し、

show ipv6 interface

などで、

期待するSLAACアドレス

が形成されたか確認します。

52. Oフラグ修正後の再試験

根本原因：

ステートレスDHCPv6設計なのに
Oフラグ=0

修正：

その他設定を示す
期待したRA条件へ変更

なら、修正後は、

RA側
→ 期待値フラグ確認

クライアント側
→ DHCPv6追加情報取得確認

を行います。

設定変更だけで終了しません。

53. 割り当て方式修正後の再試験

根本原因：

期待値
ステートフルDHCPv6

実際値
SLAAC

なら、クライアント設定を期待値方式へ修正します。

その後、

show running-config interface

だけではなく、

show ipv6 dhcp interface

show ipv6 interface

などを使って、

DHCPv6クライアント状態

割り当て済みアドレス

動作上のアドレス

を再確認します。

54. デフォルトルーター問題の再試験

根本原因：

autoconfig default
が必要なのに
autoconfigだけ

なら、必要なクライアント設定を修正したあと、

受信RA

ルーター有効期間

クライアント設定

デフォルトルート要件

の整合を再確認します。

ルーティング表全体や最長プレフィックス一致の本格解析はこのページの中心ではありません。

55. 再試験では元の症状が消えたかを見る

修正後確認の目的は、

コマンドが受理されたか

ではありません。

確認するのは、

最初の症状が解消したか

実際値が期待値へ一致したか

です。

例えば、

症状
SLAACアドレスなし

だったなら、

最終的に、

期待するSLAACアドレス
→ 存在

まで確認します。

56. 別の障害を作っていないかも確認する

最小修正後は、問題となった項目だけでなく、

もともと正常だった情報

が維持されていることも確認します。

例えば、

リンクローカル
→ 存在

期待値プレフィックス
→ 正常

割り当て方式
→ 正常

を必要に応じて確認します。

ただし無関係な領域全体を無制限に再試験するのではなく、今回の変更に関連する範囲を確認します。

57. トラブルシューティングでは証拠の強さを比較する

例えば、

SLAACアドレスがない

という症状に対し、

たぶんDHCPv6サーバーが悪い

という推測より、

show ipv6 routers
で期待RAが存在しない

という確認情報の方が強い証拠です。

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

推測

より、

設定

動作上の出力

受信済み情報

を優先します。

58. 正常情報は仮説除外に使う

例えば、

RA
→ 存在

プレフィックス
→ /64

Aフラグ
→ 期待値

SLAACアドレス
→ 存在

なら、

RA未受信

プレフィックス長不一致

SLAACアドレス生成失敗

は原因候補から外せます。

このように正常情報もトラブルシューティングでは重要です。

59. よくある誤判断

誤り1：症状を根本原因として扱う

アドレスがない

は症状です。

誤り2：最初に思いついた原因を即修正する

複数仮説を確認情報で絞ります。

誤り3：アドレスが存在すれば要件を満たしている

アドレス/プレフィックス/割り当て方式を分けます。

誤り4：SLAAC失敗なら必ずRA未受信

RA受信済みでもAフラグやプレフィックス条件が不一致の場合があります。

誤り5：A=1なら必ずSLAACアドレスができる

プレフィックス/インターフェース識別子条件や動作結果も確認します。

誤り6：M/OフラグだけでDHCPv6成功まで確定する

実際のクライアント状態は別に確認します。

誤り7：ステートフルDHCPv6アドレスがあればデフォルトルーターもある

デフォルトルーターはRA側です。

誤り8：SLAACアドレスがあるならautoconfig defaultも有効

defaultキーワードは実行中設定で確認します。

誤り9：EUI-64のFFFEだけ確認する

U/Lビット反転も確認します。

誤り10：プレフィックス長を見ずアドレス文字列だけ比較する

ネットワーク境界を含めて判断します。

誤り11：修正コマンドが成功したら終了する

動作結果を再確認します。

誤り12：原因に関係ない設定までまとめて変更する

根本原因に対応する最小修正を選びます。

60. IPv6総合トラブルシューティングの流れ

1. 症状を整理する

        ↓

2. 期待状態を定義する

        ↓

3. 実際状態を取得する

        ↓

4. 期待値と実際値の
   差分を整理する

        ↓

5. 原因候補を複数作る

        ↓

6. 必要な確認情報を
   選択する

        ↓

7. 実行中設定を確認

        ↓

8. 動作上のアドレス/
   プレフィックス/リンクローカルを確認

        ↓

9. SLAACなら
   RA/Aフラグ/
   プレフィックスを確認

        ↓

10. DHCPv6なら
    クライアント状態を確認

        ↓

11. デフォルトルーター問題なら
    RA/ルーター有効期間/
    クライアント設定を確認

        ↓

12. EUI-64なら
    MACから期待インターフェース識別子を計算

        ↓

13. 正常情報を使って
    仮説を除外

        ↓

14. 最も直接的な
    根本原因を特定

        ↓

15. 根本原因に対応する
    最小修正を選択

        ↓

16. 修正を実施

        ↓

17. 同じ確認情報を
    取り直す

        ↓

18. 実際値が期待値へ
    一致したことを確認

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

ページ026では最終的に、

症状と根本原因を分離できる

期待状態を先に定義できる

実際状態との
差分を整理できる

必要な確認コマンドを
症状から選択できる

設定と
動作状態を相関できる

IPv6アドレス/プレフィックスを
正確に比較できる

同一LANのプレフィックス不一致を
特定できる

リンクローカルのみの状態から
過剰な結論を出さない

SLAACトラブルシューティングで
RA受信を確認できる

AフラグとM/Oフラグを
混同しない

SLAAC用プレフィックス条件を
確認できる

/60と/64の違いを
シナリオに応じて判断できる

ステートレスDHCPv6で
アドレスと追加情報を
分離できる

ステートフルDHCPv6でも
デフォルトルーターはRA側と判断できる

ルーター有効期間を
デフォルトルーター診断に利用できる

autoconfigと
autoconfig defaultの差を
原因診断に使える

期待する割り当て方式と
実際値設定を比較できる

Modified EUI-64の
FFFE/U/Lビット/
インターフェース識別子を診断できる

複数仮説を
確認情報で除外できる

正常な確認情報を
原因候補除外に利用できる

最も直接的な
根本原因を選択できる

根本原因に対応した
最小修正を判断できる

修正後に
動作結果を
取り直せる

最初の症状が解消し
期待値と実際値が一致したことを
確認できる

必要があります。

まとめ

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

症状を見て
すぐ原因を決める

のではありません。

まず、

症状

期待状態

実際状態

を分けます。

次に、

実行中設定

動作上のアドレス

プレフィックス

リンクローカルアドレス

RA

DHCPv6

割り当て方式

から、必要な確認情報を選択します。

SLAAC問題なら、

クライアント設定
↓
RA受信
↓
Aフラグ
↓
広告されたプレフィックス
↓
アドレス生成

を確認します。

ステートレスDHCPv6では、

アドレス
→ SLAAC

追加情報
→ DHCPv6

デフォルトルーター
→ RA

を分けます。

ステートフルDHCPv6でも、

アドレス
→ DHCPv6

デフォルトルーター
→ RA

です。

Cisco IOSクライアントでは、

ipv6 address autoconfig

と、

ipv6 address autoconfig default

の差が、デフォルトルート要件のトラブルシューティングで重要になります。

Modified EUI-64では、

MAC
↓
FF:FE
↓
U/Lビット
↓
インターフェース識別子
↓
プレフィックスとの結合

を使って、どの生成段階が不整合かを判断します。

最終流れは、

症状
↓
期待値
↓
実際値
↓
仮説
↓
確認
↓
仮説除外
↓
根本原因
↓
最小修正
↓
再試験
↓
期待値との再比較

です。

トラブルシューティング完了の条件は、

設定を変更した

ことではありません。

根本原因に対応した修正を行い、

修正後の動作状態が

期待状態へ一致した

ことです。