DHCPv4 Troubleshooting

このページで学ぶこと

• Troubleshooting Sequence
• Topology / 役割の識別
• Client DHCP Configuration
• DISCOVER 確認情報
• Relay Necessity
• Relay Configuration / Helper Placement
• giaddr Verification
• Server DISCOVER Reception
• Correct Pool 選択
• Pool Network Mismatch
• Pool Exhaustion
• Excluded Address Range
• OFFER 確認情報
• REQUEST / Server Identifier
• Multi-Server Offer Interpretation
• ACK / NAK 確認情報
• Binding / Conflict 確認情報
• Show-before-Debug
• 根本原因 to 修正
• Release / Renew 修正後確認

1. DHCPv4トラブルシューティングは全体を一度に疑わない

DHCPv4クライアントがアドレスを取得できない場合、最初からDHCPサーバーだけを原因と決めてはいけません。

確認範囲を、

トポロジ・役割
↓
クライアント設定
↓
DISCOVER
↓
リレー
↓
サーバー受信
↓
プール選択
↓
アドレスの利用可能数
↓
OFFER
↓
REQUEST
↓
ACK・NAK
↓
バインディング・競合
↓
根本原因
↓
修正
↓
確認

のように段階へ分けます。

2. 最初にトポロジと役割を確認する

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

誰がクライアントか
誰がサーバーか
リレーが必要か

を確認します。

特に、

クライアント
↓
L3ゲートウェイ
↓
リモートDHCPサーバー

というトポロジなら、

クライアント
リレー
サーバー

の3つの役割を分けて考えます。

3. クライアント・リレー・サーバーは役割が違う

DHCPクライアント
→ アドレス・設定を要求する

DHCPリレー
→ クライアントとリモートサーバーのDHCPメッセージを中継する

DHCPサーバー
→ アドレス・設定を提供する

です。

同じCisco IOS・IOS XEデバイスでも、設定によって役割が変わります。

4. トラブルシューティング手順を固定する理由

いきなりサーバー側デバッグを開始すると、

そもそもクライアントがDISCOVERを送っていない

問題や、

リレー設定が存在しない

問題を見逃しやすくなります。

そのため、

トポロジ
↓
設定
↓
showコマンドの情報
↓
メッセージフロー
↓
必要ならデバッグ

の順で確認します。

5. 最初から設定を変更しない

トラブルシューティング開始直後に、

プール削除
バインディング全削除
ヘルパー移動
クライアント再設定

などを同時に実施すると、根本原因を判別しにくくなります。

まず現在状態を確認します。

6. showコマンドで確認してからデバッグを使う

最初に利用する確認情報は、

• running-config
• インターフェース状態
• クライアントリース
• DHCPプール
• バインディング
• 競合
• サーバー統計

などです。

これらで範囲を絞った後、必要ならデバッグを使用します。

7. クライアント設定を最初に確認する

IOSデバイス自身がDHCPクライアントとしてアドレスを取得する要件なら、対象インターフェースに、

ip address dhcp

が必要です。

例えば、

interface GigabitEthernet0/0
 ip address dhcp
 no shutdown

です。

8. クライアント設定確認コマンド

代表的には、

show running-config interface GigabitEthernet0/0

で、

ip address dhcp

が存在するか確認します。

9. クライアント設定がなければサーバー側を先に変更しない

シナリオ：

インターフェースにアドレスなし

show running-config interface
↓
固定アドレスなし
ip address dhcpなし

なら、

クライアントDHCP設定不足

が直接確認できています。

サーバープールを先に変更する理由はありません。

10. クライアント設定不足ではDISCOVER自体が期待できない

DHCPクライアントとして設定されていなければ、そのインターフェースから期待するDHCPアドレス取得処理が開始されません。

したがって、

DISCOVERなし
と
ip address dhcpなし

はクライアント側設定を強く疑う組み合わせです。

11. クライアント設定の修正

要件がDHCPクライアントなら、

interface GigabitEthernet0/0
 ip address dhcp

を設定します。

必要に応じてインターフェース管理状態も確認します。

12. クライアント設定があっても取得成功とは限らない

ip address dhcp

が存在していても、

アドレス取得成功

とは限りません。

次に動作状態を確認します。

13. クライアント動作状態を確認する

代表的には、

show ip interface brief

を使用します。

確認対象は、

• 現在のIPv4アドレス
• 方式
• インターフェース状態
• プロトコル状態

などです。

14. クライアントリースも確認する

IOSデバイス自身がDHCPクライアントとして取得したリースは、

show dhcp lease

で確認できます。

15. 設定とリースを混同しない

ip address dhcpあり

は設定。

show dhcp leaseでリースあり

は動作状態です。

両方を別の証拠として扱います。

16. DISCOVERの有無を確認する

クライアント設定が正しいのにアドレスを取得できない場合、

クライアントがDHCPDISCOVERを送信しているか

を確認します。

DISCOVERはDHCPアドレス取得処理の最初の重要なメッセージです。

17. DISCOVERがなければクライアント側に留まる

期待する確認地点で、

DHCPDISCOVERなし

なら、

• クライアント設定
• インターフェース状態
• DHCPクライアント処理

などを優先します。

リレーやプールへ進む前に、クライアントから最初のメッセージが出ているかを確認します。

18. DISCOVERがあれば次の確認地点へ進む

クライアント側で、

DHCPDISCOVER送信

を確認できたら、

クライアントがDHCP処理を開始した

ことが分かります。

次に、

サーバーまでそのDISCOVERが届く経路

を確認します。

19. クライアントとサーバーの位置関係を確認する

次に、

クライアントとDHCPサーバーは同じブロードキャストドメインか
別サブネットか

を確認します。

リレーの必要性を判断するためです。

20. 直接接続クライアントではリレーは通常不要

クライアントブロードキャストをDHCPサーバーが直接受信できる同一ブロードキャストドメインの構成なら、

DHCPリレー

は通常必要ありません。

サーバーがクライアントのDISCOVERを直接受信できます。

21. L3境界を越える構成ならリレーを確認する

例えば、

クライアント
10.20.30.0/24

DHCPサーバー
10.99.0.10

の間にルーター・L3スイッチがある場合、

クライアントブロードキャストをリモートサーバーへ届けるためDHCPリレーを確認します。

22. Cisco IOS・IOS XEの代表的リレー設定

クライアント側L3インターフェースで、

ip helper-address <DHCP-server-address>

を使用します。

例：

interface Vlan20
 ip address 10.20.30.1 255.255.255.0
 ip helper-address 10.99.0.10

です。

23. ヘルパーが存在するだけでは十分ではない

確認するのは、

ip helper-addressがあるか

だけではありません。

さらに、

正しいインターフェースか
正しいサーバーアドレスか

を確認します。

24. ヘルパーはクライアント側L3インターフェースに必要

重要なのは、

クライアントのDHCPブロードキャストを受信するL3インターフェース

です。

例えばクライアントVLAN 20のデフォルトゲートウェイが、

interface Vlan20

なら、そのSVIが重要な確認地点です。

25. サーバー側インターフェースへ置くと覚えない

ヘルパー配置は、

DHCPサーバーに近いインターフェース

で判断しません。

クライアントブロードキャストを受信するインターフェース

で判断します。

26. ヘルパー不足のシナリオ

シナリオ：

クライアントVLAN 20
↓
Vlan20
↓
リモートDHCPサーバー

Vlan20にip helper-addressなし

なら、

リレー設定不足

が直接的な原因候補です。

27. ヘルパー不足の修正

根本原因がヘルパー不足なら、

interface Vlan20
 ip helper-address 10.99.0.10

のように、正しいクライアント側L3インターフェースへ設定します。

28. ヘルパーアドレスの宛先も確認する

例えば、

ip helper-address 10.99.0.20

と設定されている一方、

実際のDHCPサーバーが、

10.99.0.10

なら、リレー宛先が不一致しています。

29. ヘルパーアドレス誤りを別原因へ置き換えない

ヘルパーアドレスが明確に誤っている場合、

DNSオプション
リース時間
クライアントホスト名

を変更しても、そのリレー宛先不一致自体は解消しません。

30. ヘルパーアドレス誤りの修正

根本原因がリレー宛先の誤りなら、

ip helper-address 10.99.0.10

のように正しいDHCPサーバーアドレスへ修正します。

31. リレーサービス状態も確認する

IOS・IOS XEでは、

no service dhcp

が設定されると、DHCPサーバー・リレーサービスが無効になります。

したがって、ヘルパーが正しくてもサービス状態を確認する必要があります。

32. no service dhcpの影響

例えば、

interface Vlan20
 ip helper-address 10.99.0.10

があっても、

no service dhcp

がグローバル設定に存在するなら、リレー機能は正常動作しません。

33. サービス状態の修正

根本原因が、

no service dhcp

なら、

service dhcp

でDHCPサーバー・リレーサービスを有効化します。

34. giaddrでリレー処理を確認する

標準的なDHCPリレー構成では、リレーエージェントはサーバーへ転送するDHCPメッセージの、

giaddr

を設定します。

これによってサーバーはクライアント側サブネットを判断できます。

35. 標準的なリレー構成でgiaddrが0なら要確認

リレーが必要なトポロジで、

サーバーが受信したDISCOVER
giaddr = 0.0.0.0

のままなら、

想定したリレー処理を通っているか

を優先的に確認します。

ここではOption 82などの高度な拡張ではなく、基本的なDHCPリレー構成を前提に切り分けます。

36. giaddrはクライアントアドレスではない

例えば、

giaddr = 10.20.30.1

だからといって、

クライアントアドレス = 10.20.30.1

ではありません。

giaddrはリレー・クライアントサブネットをサーバー側で識別するための情報です。

37. サーバーまでDISCOVERが届いたか確認する

クライアントがDISCOVERを送っただけでは、

サーバーがDISCOVERを受信した

とは限りません。

リレーやネットワーク経路の途中で届かない可能性があります。

38. クライアント側送信とサーバー側受信を分ける

クライアント側
DISCOVER送信確認

はクライアントが送信した証拠です。

サーバー側
DISCOVER受信確認

はサーバーまで到達した証拠です。

同じではありません。

39. リレー側確認も中間証拠になる

リレー環境では、

クライアント
↓
リレー
↓
サーバー

に分けられます。

例えば、

クライアントでDISCOVER送信確認
リレーでサーバー宛て転送確認
サーバーでは受信なし

なら、リレー以降の経路へ範囲を絞れます。

40. サーバーのDISCOVER受信の確認情報

サーバー側では、

show ip dhcp server statistics

などのメッセージカウンターや、

必要に応じたパケット・デバッグ確認情報を使えます。

特定クライアントの詳細確認では、カウンターだけでなくメッセージ内容との関連付けも必要です。

41. サーバーにDISCOVERが届いていない場合

シナリオ：

クライアント
DISCOVER送信あり

サーバー
DISCOVER受信なし

なら、

リレー
ヘルパー
ネットワーク経路

を優先的に確認します。

サーバープールのDNSオプションから調べ始める段階ではありません。

42. サーバーがDISCOVERを受信したらプールへ進む

サーバー側で、

DISCOVER受信

を確認できれば、

クライアントからサーバーまでの処理はその地点まで進んでいます。

次に、

正しいプールを選べるか

を確認します。

43. リレー経由クライアントのプール選択

基本的なCisco IOS XE DHCPサーバーでは、

giaddr != 0

のリレー経由クライアントに対して、

giaddrが属するサブネット

と一致するプールを探します。

44. giaddrによるプール選択例

サーバーが、

giaddr = 10.40.50.1

を受信した場合、

基本的には、

10.40.50.0/24

など、そのアドレスが属するサブネットに対応するプールを照合します。

45. 直接接続クライアントのプール選択

直接接続クライアントでは、

giaddr = 0.0.0.0

です。

Cisco IOS XE DHCPサーバーは、

DHCPDISCOVERを受信したインターフェースのサブネット

を基準に対応プールを照合します。

46. リレー経由と直接接続の比較

この違いはトラブルシューティングで重要です。

47. プールのnetwork設定を確認する

サーバーが正しいプールを選択できるには、

network

設定がクライアントサブネットと整合している必要があります。

48. プールのnetwork設定不一致例

クライアントサブネット：

10.60.70.0/24

サーバープール：

ip dhcp pool USERS
 network 10.60.80.0 255.255.255.0

なら、

クライアントサブネット
10.60.70.0/24

プールのnetwork設定
10.60.80.0/24

が不一致しています。

49. プールのnetwork設定不一致時にDNSだけ変えない

プールのnetwork設定が誤っている場合、

dns-server
default-router

だけを変更してもプール選択の根本問題は解消しません。

50. プールのnetwork設定不一致の修正

根本原因が、

クライアント 10.60.70.0/24
プール 10.60.80.0/24

なら、設計に従ってクライアントサブネットに対応する正しいプールのnetwork設定へ修正します。

例：

network 10.60.70.0 255.255.255.0

です。

51. 正しいプールがあってもアドレスの利用可能数を確認する

正しいプールが選択されても、

割り当て可能アドレスが残っていない

場合は新しいクライアントへOFFERできない可能性があります。

次にプール使用状況を確認します。

52. show ip dhcp poolでプール状態を確認する

代表的コマンド：

show ip dhcp pool

です。

プールのアドレス利用状況を判断するために利用します。

53. プール枯渇

例えば、

利用可能アドレス
0

であり、割り当て可能なアドレスがすべて使用中または利用不可なら、

プール枯渇

が主要な原因候補です。

54. プール枯渇を推測だけで決めない

クライアントがアドレスを取得できないだけで、

プール枯渇確定

とはしません。

show ip dhcp pool

などでアドレスの利用可能数を確認します。

55. リース済みと除外を合わせて読む

例えば対象プールで、

動的割り当て可能アドレス 10

リース済み 8
除外 2
利用可能数 0

なら、新規動的割り当て用アドレスが残っていません。

56. 除外アドレスを確認する

グローバル設定の、

ip dhcp excluded-address

によって、指定アドレスは通常の動的割り当て対象外になります。

57. 除外範囲が広すぎる場合

例えばプールが、

10.70.80.0/24

である一方、

ip dhcp excluded-address 10.70.80.1 10.70.80.254

なら、通常のホストアドレスとして利用できる範囲をほぼすべて除外しています。

新規クライアントへ割り当てるアドレスが残りません。

58. 除外設定は異常とは限らない

例えば、

ip dhcp excluded-address 10.70.80.10

が意図的に設定されているなら、

10.70.80.10を動的割り当てへ使わない

のは正常な動作です。

59. 除外アドレスと競合を混同しない

除外
→ 管理者が意図的に割り当て対象外にした

競合
→ サーバーがアドレス競合として扱っている

です。

60. プール枯渇の根本原因をさらに確認する

プール枯渇が確認できた場合でも、

なぜ利用可能が0なのか

を確認します。

例えば、

• 有効なクライアントリースで使用中
• 不要になった古いバインディング
• 除外範囲が過剰
• アドレス範囲自体が不足

などがあります。

61. バインディングを無差別に削除しない

プール枯渇だからといって、

全バインディングを無条件に削除

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

現在利用中のクライアントへ影響する可能性があります。

62. 枯渇修正は根本原因へ合わせる

例えば、

不要な古いバインディングが残っている

ことが確認できたなら、それを適切に整理します。

一方、正当に利用中のクライアントだけでプールが不足しているなら、アドレス設計側の対応が必要です。

63. 枯渇修正後は利用可能を再確認する

修正後、

show ip dhcp pool

で、

利用可能数 > 0

になったか確認します。

さらに次のDISCOVERへOFFERが生成されるかを確認します。

64. DISCOVERあり・OFFERなしを整理する

サーバーがDISCOVERを受信しているのにOFFERが生成されない場合、確認候補は例えば、

DHCPサービス状態
正しいプール
プールのnetwork設定
利用可能アドレス
除外アドレス

です。

65. no service dhcpもOFFERなしの原因になる

プール設定が存在していても、

no service dhcp

ならDHCPサーバーサービスは無効です。

この場合はプール内容だけを調べ続けません。

66. no service dhcpの修正

根本原因がグローバルサービス状態なら、

service dhcp

へ修正します。

その後、DISCOVERに対してサーバーが応答するか確認します。

67. OFFERを確認できたら意味を変える

サーバー側で、

DHCPOFFER送信

を確認できたなら、

DISCOVER受信
プール選択
アドレス提案

の段階までは進んでいます。

68. OFFER送信だけでクライアント受信とは言えない

サーバーがOFFERを送ったことと、

クライアントがOFFERを受信した

ことは別です。

確認地点を分けます。

69. OFFERの次はREQUESTを確認する

初回DORAでは、

DISCOVER
↓
OFFER
↓
REQUEST
↓
ACK

と進みます。

OFFERまで確認できたなら、次の重要なメッセージはREQUESTです。

70. OFFERあり・REQUESTなし

シナリオ：

サーバー
DISCOVER受信
OFFER送信

クライアント・サーバー確認情報
REQUESTなし

なら、

OFFER後からクライアントの選択・REQUEST生成まで

の段階へ注目します。

71. OFFER後の失敗を戻り経路だけに決めない

サーバーAで、

OFFER送信あり
REQUESTなし

でも、

サーバーA → クライアントの戻り経路障害

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

複数サーバー環境では別サーバーが選択されている可能性があります。

72. 複数DHCPサーバー環境を考える

クライアントは1つのDHCPDISCOVERに対して、

サーバーA
サーバーB

など複数サーバーからOFFERを受け取る場合があります。

73. クライアントが正常取得しているなら他サーバーを確認する

シナリオ：

サーバーA
OFFER送信

サーバーA
REQUEST確認なし

クライアント
正常にアドレス取得

なら、

他サーバーからのOFFER

を確認することが重要です。

74. 最初に届いたOFFERを必ず選ぶとは限らない

クライアントによるOFFER選択は実装等に依存するため、

最初にOFFERしたサーバー
=
必ず選択されるサーバー

とはしません。

75. DHCPREQUESTのServer Identifierを見る

初回のサーバー選択では、

DHCPREQUEST

に含まれるServer Identifierが重要です。

これによってクライアントが選択したサーバーを判断できます。

76. サーバーA・Bの例

サーバーA → OFFER
サーバーB → OFFER

クライアント → DHCPREQUEST
Server Identifier = Server B

なら、

クライアントはサーバーBを選択した

と判断できます。

77. サーバーAがREQUESTを見てもAが選ばれたとは限らない

初回SELECTING状態のDHCPREQUESTはブロードキャストされるため、

選択されなかったサーバーAもREQUESTを受信する可能性があります。

Server Identifierを確認します。

78. REQUESTなしを根本原因と一意化しない

OFFER送信後にREQUESTがない場合、

• クライアントがOFFERを受信できていない
• クライアントが別サーバーを選択した
• クライアント側処理が進んでいない

など複数の可能性があります。

確認情報を追加します。

79. クライアントがアドレス取得失敗なら複数情報を集める

サーバーAでOFFER送信後の状態が不明なら、

他サーバーのOFFER
DHCPREQUEST
Server Identifier
クライアント側メッセージ

を確認します。

80. REQUESTをサーバーが受信したら次の段階へ進む

サーバーがクライアントの、

DHCPREQUEST

を受信したなら、

クライアントは要求を送る段階まで進んでいます。

次に、

ACK
NAK

を確認します。

81. DHCPACKの意味

DHCPACK

はサーバーがクライアントの要求を受け入れ、リース・設定を確定するメッセージです。

82. ACK確認時に言えること

REQUESTの後にACKが確認できれば、

サーバーは要求を受け入れた

と判断できます。

83. ACKだけでクライアントの最終状態を完全証明しない

サーバーがACKを送ったことだけでは、

クライアントが正常にアドレスを適用
リモートネットワークまで正常

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

クライアント側状態も確認します。

84. DHCPNAKの意味

DHCPNAK

はサーバーがクライアントの要求アドレスをそのまま利用させられないことを示します。

85. NAKを応答なしと扱わない

REQUEST
↓
NAK

なら、サーバーは応答しています。

問題は、

サーバーが無応答

ではなく、

クライアントの要求が受け入れられていない

ことです。

86. NAK時は要求内容とネットワークを確認する

例えばクライアントが以前のネットワークで使用していたアドレスを要求しているなど、

現在のネットワークでそのアドレスを使用できるか

を確認します。

87. REQUEST後にACKもNAKもない場合

シナリオ：

サーバー
REQUEST受信

ACKなし
NAKなし

なら、

サーバー側のREQUEST処理

へ確認範囲を絞ります。

88. REQUEST後のサーバー確認

代表的には、

show ip dhcp pool
show ip dhcp binding
show ip dhcp conflict

などの状態情報を確認します。

必要ならサーバー側デバッグを追加します。

89. バインディングを確認する

サーバー側のDHCPバインディングは、

show ip dhcp binding

で確認できます。

90. バインディングから確認できること

例えば、

10.80.90.25
クライアントMAC・識別子

のバインディングがあれば、

サーバーがそのクライアント向けバインディングを保持している

ことを確認できます。

91. バインディングだけでエンドツーエンド疎通は証明しない

バインディングが存在しても、

クライアントがリモートネットワークへ到達できる
DNSが正常

まで直接証明するものではありません。

92. 競合を確認する

サーバーが競合として記録しているアドレスは、

show ip dhcp conflict

で確認できます。

93. 競合エントリの意味

例えば、

10.80.90.30

が競合テーブルに記録されているなら、

そのアドレスを、

アドレス割り当て問題の確認対象

として扱います。

94. 競合から他の根本原因を勝手に決めない

競合エントリが存在するだけで、

プールのnetwork設定不一致
誤ったヘルパー
クライアント設定不足

を直接証明するものではありません。

競合は競合として評価します。

95. バインディング・競合・プールを組み合わせる

例えば、

利用可能アドレスが少ない
バインディングが多数
競合も複数

なら、それぞれがアドレスの利用可能数へどのように影響しているか確認します。

96. サーバー統計も確認材料になる

show ip dhcp server statistics

ではDHCPメッセージカウンターを確認できます。

例えば、

DHCPDISCOVER
DHCPOFFER
DHCPREQUEST
DHCPACK
DHCPNAK

などです。

97. カウンターだけで特定クライアントを断定しない

カウンター増加はサーバー全体のDHCP活動を示す情報になり得ますが、

その1増加が必ず対象クライアント

とは限りません。

必要に応じてパケット・デバッグ情報と組み合わせます。

98. showコマンドで確認してからデバッグを使う理由

showコマンドは、

現在の設定
現在のプール
現在のバインディング
現在の競合
現在の統計

を比較的低い負荷で確認できます。

まずこれらを利用します。

99. デバッグは絞った後に利用する

例えば、

サーバーはDISCOVERを受信
正しいプールあり
利用可能アドレスあり
しかしOFFERなし

まで絞れたなら、

サーバー内部のメッセージ処理を詳しく確認するためデバッグを使用できます。

100. サーバー側の代表的デバッグ

代表例：

debug ip dhcp server packets
debug ip dhcp server events

です。

目的に応じて必要な範囲で使用します。

101. クライアント側デバッグとサーバー側デバッグを区別する

IOSデバイス自身がDHCPクライアントの場合の代表例：

debug dhcp detail

DHCPサーバー側：

debug ip dhcp server packets
debug ip dhcp server events

です。

102. デバッグを常時最大範囲で有効化しない

デバッグは詳細な情報を生成するため、必要性と環境を考えて利用します。

基本は、

show
↓
範囲を絞る
↓
必要なデバッグ

です。

103. 根本原因の特定は根拠をつなげる

単一コマンドだけではなく、

トポロジ
設定
メッセージ
プール
バインディング
競合

を組み合わせます。

104. 根本原因例：クライアントDHCP設定不足

確認情報：

クライアントアドレスなし
DISCOVERなし
ip address dhcpなし

なら、

クライアントDHCP設定不足

が根本原因として強く支持されます。

105. 根本原因への修正：クライアント

必要なクライアントインターフェースへ、

ip address dhcp

を設定します。

無関係なサーバープールは変更しません。

106. 根本原因例：ヘルパー不足

確認情報：

クライアントとサーバーは別サブネット
クライアントのDISCOVER送信
クライアント側インターフェースにヘルパーなし

なら、

リレー設定不足

が根本原因として強く支持されます。

107. 根本原因への修正：ヘルパー不足

クライアントブロードキャストを受信するL3インターフェースへ、

ip helper-address <correct-server>

を設定します。

108. 根本原因例：ヘルパー宛先誤り

確認情報：

ヘルパーあり
しかしアドレスが実サーバーと違う

なら、

リレー宛先不一致

です。

109. 根本原因への修正：ヘルパー宛先誤り

ヘルパーアドレスを正しいDHCPサーバーへ修正します。

他の正常なプール設定を根拠なく変更しません。

110. 根本原因例：プールのnetwork設定不一致

確認情報：

クライアントサブネット
10.90.100.0/24

プールのnetwork設定
10.90.110.0/24

なら、

プールのnetwork設定不一致

です。

111. 根本原因への修正：プールのnetwork設定

クライアントサブネットと設計に合う正しいプールのnetwork設定へ修正します。

例えば、

network 10.90.100.0 255.255.255.0

です。

112. 根本原因例：DHCPサービス無効

確認情報：

サーバー設定あり
DISCOVER受信
OFFERなし

no service dhcp

なら、

DHCPサーバーサービス無効

が直接的な根本原因です。

113. 根本原因への修正：サービス状態

service dhcp

で必要なDHCPサーバー・リレーサービスを有効化します。

114. 根本原因例：プール枯渇

確認情報：

正しいプール
利用可能数 = 0

で、新規クライアントへアドレスを提供できない状態なら、

プール枯渇

が根本原因として強く支持されます。

115. プール枯渇への修正は状況に合わせる

例えば、

不要な古いバインディング
過剰な除外範囲
アドレス範囲不足

のどれが原因かを確認して修正します。

無差別に全バインディングを削除しません。

116. 根本原因修正後は再現試験を行う

設定を修正したら、

設定を変更した
=
問題解決

とはしません。

新しいDHCP処理を確認します。

117. DHCPリース保持時のrenew dhcp

DHCP由来リースを保持するIOSクライアントでは、

renew dhcp <interface>

を利用して更新・再バインド処理を明示的に進めることができます。

118. renew dhcpの前提

renew dhcpは、

DHCP由来アドレスを保持しているインターフェース

が前提です。

リース未取得インターフェースで、

renew dhcp

を単独の新規アドレス取得コマンドとして扱いません。

119. release dhcpの役割

既存DHCPリースを明示的に返却する場合、

release dhcp <interface>

を使用できます。

120. release dhcpはip address dhcp設定を削除しない

release dhcpによってリース・DHCP由来アドレスは解放されますが、

ip address dhcp

というインターフェース設定自体を削除するコマンドではありません。

121. release dhcpとrenew dhcpの利用

DHCP由来リースを保持しているクライアントで、新しいDHCPサイクルを明示的に発生させたいシナリオでは、

release dhcp <interface>
renew dhcp <interface>

という操作を利用する場合があります。

122. release dhcpとrenew dhcp後も結果を確認する

確認対象は例えば、

新しいDHCPメッセージフロー
新しいクライアントアドレス
クライアントリース
サーバーバインディング

です。

コマンド実行だけで終了しません。

123. 修正後は根本原因に近い地点から再確認する

例えばヘルパーを修正したなら、

ヘルパー設定
↓
リレー転送
↓
サーバーのDISCOVER受信
↓
OFFER
↓
REQUEST
↓
ACK
↓
クライアントアドレス

を確認します。

124. プールのnetwork設定修正後の確認

プールのnetwork設定を修正したなら、

正しいプール選択
↓
利用可能アドレス
↓
OFFER
↓
REQUEST
↓
ACK
↓
バインディング
↓
クライアントアドレス

を確認します。

125. プール枯渇修正後の確認

プール枯渇を修正したなら、

show ip dhcp pool
↓
利用可能アドレス > 0
↓
次のDISCOVER
↓
OFFER生成

を確認します。

これにより修正と症状回復の関係を確認できます。

126. 修正後OFFERが再開すれば重要な根拠になる

例えば、

修正前
利用可能数 = 0
OFFERなし

不要な古いバインディング等を適切に整理

修正後
利用可能数 > 0
OFFERあり

なら、

プール枯渇が問題に寄与していた

ことを強く支持します。

127. 設定変更と確認をセットにする

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

根本原因
↓
必要な修正
↓
確認

を1セットとして考えます。

128. 問題パターン1：トラブルシューティング手順

DHCPクライアントがアドレスを取得できない場合、最初の基本順序は、

トポロジ・役割
↓
クライアント設定
↓
メッセージ・リレー・サーバー

です。

129. 問題パターン2：役割識別

クライアント、L3ゲートウェイ、リモートDHCPサーバーがあるなら、

DHCPクライアント
DHCPリレー
DHCPサーバー

を識別します。

130. 問題パターン3：クライアント設定不足

IOSクライアントに、

固定アドレスなし
ip address dhcpなし

なら、

クライアントインターフェースのDHCP設定

を修正します。

131. 問題パターン4：DISCOVERなし・クライアント設定なし

アドレスなし
DISCOVERなし
ip address dhcpなし

なら、

クライアントDHCP設定不足

が最も直接的な根本原因です。

132. 問題パターン5：別サブネットのサーバー

クライアントとサーバーの間にL3境界があるなら、

DHCPリレーが必要か

を確認します。

133. 問題パターン6：ヘルパー不足

クライアント側SVIにヘルパーがなく、サーバーが別サブネットなら、

リレー設定不足

を優先します。

134. 問題パターン7：ヘルパーアドレス誤り

設定済みヘルパー
10.99.0.20

実際のDHCPサーバー
10.99.0.10

なら、

ヘルパーアドレス宛先誤り

です。

135. 問題パターン8：ヘルパー配置誤り

ヘルパーがサーバー側インターフェースだけにあるなら、

クライアントブロードキャストを受信するL3インターフェース

へ配置すべきか確認します。

136. 問題パターン9：リレーなのにgiaddr = 0

標準的なリレー構成を期待しているのに、

サーバー受信DISCOVER
giaddr = 0.0.0.0

なら、

リレー設定・リレー処理

を優先します。

137. 問題パターン10：サーバーにDISCOVERが届かない

クライアントのDISCOVER送信あり

サーバー
DISCOVER受信なし

なら、

クライアント → リレー → サーバーの経路

を確認します。

138. 問題パターン11：リレー経由時のプール選択

giaddr = 10.40.50.1

なら、基本的には、

10.40.50.1が属するサブネット

に対応するプールを照合します。

139. 問題パターン12：直接接続時のプール選択

giaddr = 0
直接接続クライアント

なら、

受信インターフェースのサブネット

を基準にプールを照合します。

140. 問題パターン13：プールのnetwork設定不一致

クライアント
10.60.70.0/24

プール
10.60.80.0/24

なら、

プールのnetwork設定不一致

です。

141. 問題パターン14：プール枯渇

show ip dhcp pool
利用可能数 = 0

で割り当て可能アドレスがないなら、

プール枯渇

を主要候補とします。

142. 問題パターン15：全ホストアドレスを除外

ip dhcp excluded-address 10.70.80.1 10.70.80.254

によって実用的な動的割り当て候補がすべて除外されているなら、新しいクライアントへアドレスを提供できません。

143. 問題パターン16：意図した除外アドレス

ip dhcp excluded-address 10.70.80.10

が設計どおりなら、

10.70.80.10を動的割り当てしない

のは正常です。

144. 問題パターン17：no service dhcp

DISCOVERはサーバーへ届いているが、

no service dhcp

が根本原因なら、

service dhcp

へ修正します。

145. 問題パターン18：リース済み・除外で利用可能数0

動的割り当て候補 10
リース済み 8
除外 2
利用可能数 0

なら、

プール枯渇

です。

146. 問題パターン19：サーバーAでREQUESTがないがクライアント成功

サーバーA OFFERあり
サーバーA REQUESTなし
クライアント取得成功

なら、

他サーバーのOFFER
と
Server Identifier

を確認します。

147. 問題パターン20：複数サーバーで確認する2点

クライアントが取得失敗し、サーバーAのOFFER後が不明なら、

他DHCPサーバーのOFFER
DHCPREQUESTのServer Identifier

を確認します。

148. 問題パターン21：Server Identifier = B

サーバーAが受信したDHCPREQUESTで、

Server Identifier = Server B

なら、

クライアントはサーバーBのOFFERを選択した

と判断します。

149. 問題パターン22：REQUEST → NAK

DHCPREQUEST
↓
DHCPNAK

なら、

サーバーが要求アドレスをそのまま利用させられない

状態です。

150. 問題パターン23：REQUEST → ACK

DHCPREQUEST
↓
DHCPACK

なら、

サーバーが要求を受け入れた

と判断します。

151. 問題パターン24：バインディング

show ip dhcp binding

にクライアントのアドレスバインディングがあるなら、

サーバーがそのクライアント向けバインディングを保持

していることを直接確認できます。

152. 問題パターン25：競合

show ip dhcp conflict

にアドレスがあるなら、

そのアドレスを競合確認対象として扱う

必要があります。

153. 問題パターン26：デバッグ前の3項目

デバッグを有効化する前に、

トポロジ・役割
設定
showコマンドによる動作情報

を優先します。

154. 問題パターン27：show確認後のサーバー側デバッグ

サーバーはDISCOVER受信
OFFERなし

まで絞った後、さらに内部処理を見るなら、

debug ip dhcp server packets
debug ip dhcp server events

などを必要な範囲で使います。

155. 問題パターン28：ヘルパー不足修正

根本原因が、

クライアント側SVIにヘルパーなし

なら、

クライアント側SVIへ
正しいip helper-addressを追加

します。

156. 問題パターン29：プールのnetwork設定修正

根本原因が、

クライアント
10.90.100.0/24

プール
10.90.110.0/24

なら、

クライアントサブネットに対応するプールのnetwork設定

へ修正します。

157. 問題パターン30：renew dhcp

renew dhcp <interface>は、

DHCP由来リースを保持するインターフェース

で更新・再バインド処理を明示的に進める場合に使用します。

158. 問題パターン31：release dhcp → renew dhcp → 確認

既存DHCPリースを返却して再試行するシナリオでは、

release dhcp <interface>
↓
renew dhcp <interface>
↓
アドレス・リース・メッセージフロー確認

を行います。

159. 問題パターン32：OFFER後にREQUESTなし

DISCOVER
OFFER
確認済み

REQUESTなし

なら、

OFFER送信後
↓
クライアントのOFFER選択・REQUEST生成

の段階へ範囲を絞ります。

160. 問題パターン33：REQUEST後にACKもNAKもなし

REQUEST受信
ACKなし
NAKなし

なら、

プール
バインディング
競合
サーバーイベント

などサーバー側REQUEST処理を優先します。

161. 問題パターン34：サーバーへのDISCOVER到達確認

クライアント側とリレー側で送信・転送まで確認済みなら、

次はサーバー側で、

DHCPメッセージカウンター
パケット・デバッグ確認情報

を使い、

サーバーがDISCOVERを受信したか

を確認します。

162. 問題パターン35：プール枯渇修正後

修正前：

利用可能数 = 0
OFFERなし

不要な古いバインディング等を適切に整理した後：

利用可能数 > 0
OFFER送信

となったなら、

プール枯渇

が根本原因だったことを強く支持します。

163. 根拠と判断の比較表

164. 根本原因と必要な修正の比較表

165. 修正してはいけないものを考える

例えば根本原因が、

ヘルパーアドレス誤り

なのに、

クライアントDNS
プールのリース時間
バインディング全削除

を変更する必要はありません。

根本原因と修正内容を対応させます。

166. DHCPv4トラブルシューティング最終フロー

DHCPアドレスを取得できない
↓
トポロジ・役割確認
↓
クライアントDHCP設定は正しいか
├─ いいえ
│  └─ クライアント設定修正
│
└─ はい
   ↓
DISCOVERは出ているか
├─ いいえ
│  └─ クライアント側処理を確認
│
└─ はい
   ↓
サーバーは同一ブロードキャストドメインか
├─ はい
│  └─ 直接経路確認
│
└─ いいえ
   ↓
リレー・ヘルパー設定は正しいか
├─ いいえ
│  └─ ヘルパー設定・サービス状態を修正
│
└─ はい
   ↓
サーバーはDISCOVERを受信したか
├─ いいえ
│  └─ リレー・経路を確認
│
└─ はい
   ↓
正しいプールを選択できるか
├─ いいえ
│  └─ プールのnetwork設定・giaddrを確認
│
└─ はい
   ↓
利用可能アドレスはあるか
├─ いいえ
│  └─ 枯渇・除外設定を確認
│
└─ はい
   ↓
OFFERは送信されたか
├─ いいえ
│  └─ サービス状態・プール・必要ならデバッグ
│
└─ はい
   ↓
REQUESTは確認できるか
├─ いいえ
│  └─ クライアント選択・複数サーバー確認
│
└─ はい
   ↓
ACKまたはNAKはどうか
├─ NAK
│  └─ 要求拒否理由を確認
│
├─ 応答なし
│  └─ サーバー側REQUEST処理を確認
│
└─ ACK
   ↓
バインディング・クライアントアドレスを確認
   ↓
修正後確認

167. DHCPメッセージの基礎知識を障害調査へつなげる

DHCPメッセージの基礎として、

DORA
DHCPメッセージの意味
UDPポート67・68
リレー
giaddr
プール選択原理

を扱いました。

トラブルシューティングではそれらを、

障害調査の根拠

として利用します。

ここではメッセージ原理を繰り返すのではなく、障害調査での使い方に結び付けます。

168. IOSのDHCP確認コマンドを障害調査へつなげる

IOSのDHCP設定・確認では、

ip address dhcp
show dhcp lease
show ip dhcp pool
show ip dhcp binding
show ip dhcp conflict
show ip dhcp server statistics
ip helper-address
service dhcp
release dhcp
renew dhcp

などのコマンドを個別に扱いました。

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

どの状況で
どのコマンドを使い
何を判断し
何を修正するか

を統合します。

169. DHCP Snoopingとは切り分けて考える

DHCP Snooping、不正DHCPサーバー対策、信頼ポート（trusted）・非信頼ポート（untrusted）はレイヤー2セキュリティの論点です。

DHCPv4クライアント・リレー・サーバーの基本的な障害切り分けとは分けて考えます。

170. Option 82の詳細設計とは切り分ける

基本的なリレーの障害切り分けでは、

基本的なip helper-address
giaddr
プール選択

です。

Option 82の詳細なサブオプション設計や高度なプール選択例外は、基本的な切り分けとは別論点です。

171. DHCPv4とDHCPv6を混同しない

ここで確認するのはDHCPv4クライアント・サーバー・リレーのトラブルシューティングです。

DHCPv6メッセージやIPv6アドレス割り当ては別の仕組みとして区別します。

172. パケットキャプチャの操作手順と障害判断を分ける

パケットやメッセージの確認結果は利用しますが、

Wiresharkの具体的フィルター操作
キャプチャインターフェース設定
pcap解析手順

その操作手順そのものと、DHCPv4の障害判断は分けて考えます。

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

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

症状
↓
最初に確認する情報
↓
最後に正常な段階
↓
最初に失敗している段階
↓
根本原因
↓
必要な修正
↓
修正後確認

を一連で判断できることが重要です。

174. 「DISCOVERがない」と「OFFERがない」を区別する

DISCOVERなし
→ クライアント側から確認

DISCOVERあり
OFFERなし
→ リレー・サーバー・プール側へ進む

では障害範囲が異なります。

175. 「OFFERがない」と「REQUESTがない」を区別する

OFFERなし
→ サーバーが提案を生成できない段階

OFFERあり
REQUESTなし
→ クライアントのOFFER受信・選択段階

です。

176. 「REQUESTがない」と「ACKがない」を区別する

REQUESTなし
→ クライアント側の選択・REQUEST生成まで

REQUESTあり
ACKもNAKもなし
→ サーバー側REQUEST処理

です。

177. 最後に成功した地点を見る

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

何が失敗したか

だけでなく、

どこまで正常だったか

を確認します。

例えば、

サーバーのOFFER送信まで正常

なら、それ以前を何度も変更する優先度は下がります。

178. 最初に失敗した地点を見る

近い地点から順に確認した場合、

最初に期待結果が得られない段階

が重要です。

この考え方で障害範囲を絞ります。

179. 1つの根拠で過剰に断定しない

避ける判断：

DISCOVERなし
→ サーバー故障確定

OFFERなし
→ プール枯渇確定

OFFERあり・REQUESTなし
→ 戻り経路障害確定

競合あり
→ プールのnetwork設定不一致確定

です。

複数の根拠を組み合わせます。

180. 最終まとめフロー

トポロジ・役割
↓
クライアント設定
↓
DISCOVER
↓
リレーの必要性
↓
ヘルパー配置・宛先
↓
giaddr
↓
サーバーのDISCOVER受信
↓
正しいプール
↓
プールのnetwork設定
↓
利用可能アドレス・除外設定
↓
OFFER
↓
REQUEST・Server Identifier
↓
ACK・NAK
↓
バインディング・競合
↓
根本原因
↓
必要な修正
↓
`release dhcp`と`renew dhcp`等による再試行
↓
クライアントアドレス・リース・バインディング・メッセージフロー確認

この順序を使うことで、クライアント、リレー、サーバーのどこでDHCPv4処理が止まっているかを段階的に判断できます。

まとめ

DHCPv4トラブルシューティングでは、最初からDHCPサーバーだけを疑うのではなく、

トポロジ・役割
↓
クライアント設定
↓
DHCPメッセージフロー
↓
リレー
↓
プール
↓
アドレスの利用可能数
↓
バインディング・競合

を順番に確認します。

重要なのは、

クライアントがDISCOVERを送ったか

リレーが必要か

ヘルパーは正しいインターフェース・サーバーを向いているか

サーバーがDISCOVERを受信したか

正しいプールを選択できるか

アドレスは残っているか

OFFERは出たか

クライアントはどのサーバーを選択したか

ACKまたはNAKはどうなったか

を根拠から判断することです。

根本原因を確認したら、その原因に対応する修正だけを行います。

クライアント設定不足
→ ip address dhcp

ヘルパー不足・ヘルパー設定誤り
→ クライアント側インターフェースのヘルパーを修正

no service dhcp
→ service dhcp

プールのnetwork設定不一致
→ クライアントサブネットに対応する正しいプールのnetwork設定へ修正

プール枯渇
→ 原因に応じてアドレスの利用可能数を回復

そして修正後は、

メッセージフロー
クライアントアドレス
クライアントリース
サーバーバインディング
プールの利用可能アドレス数

などを再確認します。

DHCPv4トラブルシューティングの最終目標は、

どこで止まったか
↓
なぜ止まったか
↓
何を直すべきか
↓
直ったことをどう証明するか

まで判断できることです。