DHCPv4 Client / Server Process

このページで学ぶこと

• DORA Sequence
• DHCPDISCOVER Role
• DHCPOFFER Role
• DHCPREQUEST / Server 選択
• DHCPACK Role
• DHCPNAK Meaning
• DHCPDECLINE Meaning
• DHCPRELEASE Meaning
• DHCPINFORM Meaning
• UDP 67 / 68
• Direct vs Relayed Client
• DHCP Relay / ip helper-address Role
• giaddr Relayed Pool 選択
• Direct Client Pool 選択
• Message 停止段階の特定

1. DHCPv4は「アドレスをもらう」だけではなくメッセージフローで理解する

DHCPv4では、クライアントがIPv4設定を取得するまでに、クライアント、サーバー、必要に応じてリレーが役割を分担します。

初回取得の代表的なフローは、

クライアント                          DHCPサーバー
  |                                  |
  | ------ DHCPDISCOVER -----------> |
  | <------- DHCPOFFER ------------- |
  | ------ DHCPREQUEST ------------> |
  | <------- DHCPACK --------------- |
  |                                  |

です。

この4つを、

Discover
Offer
Request
Acknowledge

の頭文字から、

DORA

と呼びます。

ただし、すべてのDHCP通信が常にDORAの4メッセージだけで構成されるわけではありません。

2. DORAは初期アドレス取得の基本フロー

DORAでは、それぞれのメッセージに役割があります。

単純に順番だけ暗記するのではなく、

探索
↓
提案
↓
選択・要求
↓
確定

として理解します。

3. DHCPDISCOVERはサーバーを探索するメッセージ

IPv4アドレスをDHCPで取得しようとするクライアントは、利用可能なDHCPサーバーを探すためDHCPDISCOVERを送信します。

初期取得ではクライアントはまだ利用可能なIPv4アドレスを持っていないため、代表的には、

送信元IP
0.0.0.0

宛先IP
255.255.255.255

のようなブロードキャスト通信を使用します。

4. DHCPDISCOVERの目的はアドレス確定ではない

DHCPDISCOVERを送った時点では、

クライアントのIPv4アドレスが確定

したわけではありません。

DHCPDISCOVERの役割は、

利用可能なDHCPサーバーを見つける
と
アドレスと設定の提案を求める

ことです。

5. DISCOVERを見ただけでDHCP取得成功とは判断しない

パケットキャプチャやデバッグなどで、

DHCPDISCOVER

を確認できても、

DHCP取得成功

とは判断できません。

まだ、

OFFER
REQUEST
ACK

が必要です。

6. DHCPOFFERはサーバーからの提案

DHCPサーバーがクライアントへ提供可能なアドレスや設定パラメーターを持っている場合、DHCPOFFERを返します。

DHCPOFFERには代表的に、

• 提案するIPv4アドレス
• リースに関する情報
• Server Identifier
• その他の設定パラメーター

などが含まれます。

7. OFFERはリース確定ではない

DHCPOFFERを受信しても、

そのIPv4アドレスの利用が最終確定した

わけではありません。

OFFERはあくまで、

サーバーからクライアントへの提案

です。

その後クライアントがOFFERを選び、DHCPREQUESTを送信します。

8. 複数サーバーからOFFERを受け取ることがある

同じクライアントのDHCPDISCOVERを複数のDHCPサーバーが受信すると、複数のDHCPOFFERが返る可能性があります。

例えば、

サーバーA
192.168.10.101をOFFER

サーバーB
192.168.10.150をOFFER

のような状態です。

クライアントは受信したOFFERの中から1つを選択します。

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

複数の提案からどれを選ぶかはクライアント実装などに依存します。

そのため、

最初に届いたDHCPOFFER
=
必ず選択されるサーバー

とは判断しません。

実際にどのサーバーが選択されたかは、後続するDHCPREQUESTなどから確認します。

10. DHCPREQUESTでクライアントが選択を示す

初回取得のDORAでは、クライアントは選択したDHCPOFFERに対してDHCPREQUESTを送ります。

このDHCPREQUESTには、

どのサーバーを選択したか

を識別するためのServer Identifierなどが含まれます。

11. DHCPREQUESTは選択されたサーバーだけへの秘密のメッセージではない

初回取得のSELECTING状態では、クライアントはDHCPREQUESTをブロードキャストします。

これにより、

選択されたサーバー

だけでなく、

提案したが選択されなかったサーバー

も結果を知ることができます。

12. 選択されなかったサーバーはOFFERが採用されなかったと判断できる

例えば、

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

クライアント → REQUEST
Server Identifier = サーバーB

なら、

サーバーB
→ 選択された

サーバーA
→ 自分の提案は選択されなかった

と判断できます。

13. DHCPREQUESTは常にサーバー選択だけを意味するわけではない

DHCPREQUESTは初回DORAだけで使用されるメッセージではありません。

例えば、

• 初回OFFERの選択
• 再起動後の以前のアドレス確認
• リース更新

などでも使用されます。

したがって、

DHCPREQUESTを見た
=
必ず複数OFFERからサーバーを選択している

とは判断しません。

メッセージをクライアント状態や前後の通信と合わせて読みます。

14. 初回DORAではREQUESTをServer Identifierと合わせて読む

初回アドレス取得で、

DISCOVER
↓
複数OFFER
↓
REQUEST

と進んでいる場合、

DHCPREQUEST内のServer Identifierは、

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

を判断する重要な情報になります。

15. DHCPACKは要求を受け入れたことを示す

選択されたDHCPサーバーがクライアントの要求を受け入れると、DHCPACKを返します。

DHCPACKには、

• 確定したIPv4アドレス
• リース情報
• 必要な設定パラメーター

などが含まれます。

16. ACKはOFFERより後の確定段階

DORAを役割で並べると、

DISCOVER
サーバー探索

OFFER
候補を提案

REQUEST
クライアントが要求

ACK
サーバーが要求を受け入れる

となります。

したがって、

OFFER

と

ACK

を同じ意味として扱ってはいけません。

17. DHCPACK後にクライアントは取得した設定を利用する

DHCPACKを受け入れたクライアントは、取得したIPv4設定を利用できる状態へ進みます。

代表的には、

IPv4アドレス
サブネットマスク
デフォルトゲートウェイ
DNSサーバー
リース情報

などです。

実際にどのオプションが提供されるかはサーバー設定によって異なります。

18. ACKを見た後もクライアント側の状態確認は必要

サーバー側でDHCPACKが確認できても、

クライアントが必ず正常に設定を適用した

ことまで自動的に証明されるわけではありません。

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

ACKまで確認できた

という情報から、

DHCPメッセージフローはかなり後段まで進んでいる

と判断します。

19. DHCPNAKは要求を受け入れられないことを示す

DHCPサーバーはクライアントが要求するアドレスを利用させるべきでない場合などにDHCPNAKを返すことがあります。

例えば、

クライアントが以前のネットワークで使っていたアドレスを要求
↓
現在のサブネットでは不適切

といったシナリオです。

20. NAKをACKと混同しない

DHCPACK

は要求を受け入れたことを示します。

DHCPNAK

は要求したアドレスをそのまま利用できないことを示します。

したがって、

REQUEST
↓
NAK

なら、正常なリース確定には進んでいません。

21. DHCPNAK後はそのアドレスを継続利用する前提にしない

DHCPNAKを受け取ったクライアントは、

要求したアドレスが有効である

という前提を維持できません。

必要に応じてアドレス取得処理をやり直します。

22. DHCPDECLINEはクライアントがアドレス競合等を検知したときに使う

DHCPDECLINEは、

サーバーから提案・割り当てられたアドレスを
クライアントが利用できないと判断した

ことをサーバーへ通知するメッセージです。

代表例は、

そのアドレスが既にネットワーク上で使用されていることを検知

した場合です。

23. DECLINEはサーバーがクライアントを拒否するメッセージではない

名前が似ていますが、

DHCPDECLINE

はクライアントからサーバーへ送ります。

一方、

DHCPNAK

はサーバーからクライアントへ送ります。

方向と意味を区別します。

24. DHCPDECLINEとDHCPNAKを比較する

似た否定系メッセージでも責任が異なります。

25. DHCPRELEASEはリースを返却するメッセージ

クライアントが保持しているリースを不要と判断した場合、

DHCPRELEASE

をサーバーへ送信できます。

役割は、

このリースをもう利用しない

ことをサーバーへ知らせることです。

26. RELEASEは新しいアドレスを探すメッセージではない

DHCPRELEASEは、

新しいDHCPサーバーを探索する

ためのメッセージではありません。

それはDHCPDISCOVERの役割です。

RELEASEは、

現在保持しているリースを手放す

ために使用されます。

27. DHCPRELEASEは通常既知のサーバーへ送る

クライアントはリースを提供したDHCPサーバーを認識しているため、DHCPRELEASEは通常そのサーバーへ送信します。

初回DHCPDISCOVERのような、

利用可能なサーバーをブロードキャストで探す

目的とは異なります。

28. DHCPINFORMはアドレスを既に持つクライアントが追加情報を要求する

DHCPINFORMは、

クライアントが既にIPv4アドレスを持っている

場合に、DHCPサーバーへ追加設定パラメーターを問い合わせるために使用できます。

例えば、

DNS等の追加パラメーター

を取得したいシナリオです。

29. INFORMは新しいリースアドレスを取得するためのメッセージではない

DHCPINFORMを送るクライアントは、既に外部の方法などでIPv4アドレスを持っています。

したがって、

DHCPINFORM
=
新しいIPv4リースを要求

ではありません。

30. INFORMへの応答ではアドレス割り当てそのものが目的ではない

DHCPINFORMに対してサーバーは設定パラメーターを返しますが、

新しいIPv4アドレスリースを提供する

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

アドレス割り当てと設定パラメーター取得を分けて理解します。

31. DHCPメッセージの方向を整理する

代表的な方向は、

です。

方向を理解するとパケットキャプチャを読みやすくなります。

32. DHCPv4はUDPを使用する

DHCPv4はトランスポート層でUDPを使用します。

基本ポートは、

DHCPサーバー
UDP 67

DHCPクライアント
UDP 68

です。

33. クライアントからサーバーへの基本ポート

クライアントからDHCPサーバーへ送る代表的なメッセージでは、

送信元ポート
UDP 68

宛先ポート
UDP 67

として確認できます。

代表例は初回のDHCPDISCOVERです。

34. サーバーからクライアントへ直接配送する基本ポート

DHCPサーバーからクライアントへ直接配送される代表的な応答では、

送信元ポート
UDP 67

宛先ポート
UDP 68

として確認できます。

代表例は、リレーを介さずクライアントへ配送されるDHCPOFFERやDHCPACKです。

一方、DHCPリレーを経由する場合、サーバーはリレーエージェントへ応答を返します。

DHCPサーバー
UDP 67
↓
DHCPリレーエージェント
UDP 67

つまりサーバー → リレー区間では、

UDP 67 → UDP 67

となります。

その後リレーエージェントがクライアントへDHCPメッセージを転送します。

したがって、

サーバーからのDHCP応答
=
常に宛先UDP 68

とは判断しません。

35. ポート番号とメッセージ種別を混同しない

UDP 67／68は、

どのDHCPメッセージか

を示す番号ではありません。

メッセージ種別はDHCPオプション内などで識別されます。

ポートはクライアント・サーバー・リレー間の通信エンドポイントを識別する情報です。

36. DHCPDISCOVERの代表的な初期通信をまとめる

初期取得のクライアントでは代表的に、

送信元IP       0.0.0.0
宛先IP  255.255.255.255

送信元UDP      68
宛先UDP 67

DHCPメッセージ    DHCPDISCOVER

として確認できます。

37. サーバー応答は常に同じIP配送方式とは限らない

DHCPOFFERやDHCPACKは状況やクライアントのブロードキャストフラグ、リレーの有無などによって配送方法が変わることがあります。

したがって、

DHCPOFFERは必ずIPブロードキャスト

のように固定して暗記しません。

重要なのは、直接接続クライアントへの基本応答ではサーバーがUDP 67、クライアントがUDP 68を使用し、リレー経由ではサーバー → リレー区間がUDP 67 → 67となることです。

38. クライアントとサーバーが同一サブネットなら直接やり取りできる

DHCPクライアントとDHCPサーバーが同一IPサブネットに存在する場合、クライアントのブロードキャストをサーバーが直接受信できます。

クライアント
   |
   | DHCPDISCOVERブロードキャスト
   v
同一サブネット
   |
DHCPサーバー

この場合、DHCPリレーは必須ではありません。

39. 直接接続クライアントではgiaddrは0

DHCPリレーを経由していない直接接続クライアントのDHCPメッセージでは、

giaddr = 0.0.0.0

です。

この情報は、

リレー経由か
直接接続クライアントか

を判断する重要な材料になります。

40. クライアントとサーバーが別サブネットならブロードキャスト境界を考える

通常ルーターは、クライアントが送信したローカルブロードキャストをそのまま別IPサブネットへ転送しません。

そのため、

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

DHCPサーバー
192.168.100.10

のように別サブネットへサーバーが存在する場合、リレーが必要になります。

41. DHCPリレーはクライアントブロードキャストをサーバーへ届ける

DHCPリレーエージェントはクライアント側サブネットでブロードキャストされたDHCPメッセージを受信し、リモートDHCPサーバーへ転送します。

概念的には、

クライアント
   |
   | ブロードキャスト
   v
クライアント側L3インターフェース
   |
   | DHCPリレー
   v
リモートDHCPサーバー

となります。

42. Cisco IOSではip helper-addressがDHCPリレーの代表的な仕組み

Cisco IOSおよびIOS XEでは、

ip helper-address

がDHCPリレーを実現する代表的なインターフェース設定です。

役割は、

クライアント側で受信したDHCPブロードキャスト
↓
指定したDHCPサーバーへリレー

です。

具体的なIOS設定や確認コマンドは後で扱います。

43. helper-addressはクライアント側L3インターフェース側で考える

DHCPリレーは、

クライアントがブロードキャストを送信するサブネット

を受けるL3インターフェースで動作する必要があります。

概念例：

クライアントLAN
192.168.10.0/24
      |
      v
ルーターインターフェース
192.168.10.1
DHCPリレー
      |
      v
DHCPサーバー
192.168.100.10

です。

44. リレーは単なるブロードキャストフラッディングではない

DHCPリレーは、

クライアントブロードキャストをそのまま全ネットワークへフラッディングする

ものではありません。

リレーエージェントはDHCPメッセージを処理し、リモートサーバーへ転送します。

45. リレーエージェントはgiaddrを設定する

リレーされたDHCPメッセージでは、リレーエージェントが、

giaddr
ゲートウェイIPアドレス

フィールドへクライアント側サブネットを識別するためのアドレスを設定します。

Cisco IOSおよびIOS XEの一般的なリレー動作では、クライアントからDHCPメッセージを受信したインターフェースのアドレスがこの判断に使用されます。

46. giaddrはDHCPサーバーにクライアントサブネットを伝える

リモートDHCPサーバーから見ると、クライアントは別サブネットにいます。

サーバーは、

giaddr

を使って、

どのクライアントサブネット向けのアドレスを割り当てるべきか

を判断できます。

47. リレー経由クライアントではgiaddrがプール選択の重要情報

例えば、

giaddr
192.168.10.1

なら、サーバーは、

192.168.10.1が属するサブネット

に対応するDHCPプールを探します。

例えば、

192.168.10.0/24

のプールです。

48. giaddrはクライアントへ割り当てるアドレスそのものではない

例えば、

giaddr = 192.168.10.1

だからといって、

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

ではありません。

giaddrはリレーとクライアントサブネットを識別するためのゲートウェイアドレス情報です。

49. リレーされたDISCOVERではgiaddrは0ではない

基本的な比較は、

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

リレー経由クライアント
giaddr ≠ 0

です。

これによりサーバー側パケット情報からリレーの有無を判断できます。

50. 直接接続クライアントではプール選択方法が異なる

Cisco IOS XE DHCPサーバーでクライアントが直接接続されている場合、

giaddr = 0

です。

その場合サーバーは、

DHCPDISCOVERを受信したインターフェースに設定されたサブネット

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

51. 直接接続クライアントのプール選択をgiaddrだけで説明しない

次の説明は誤りです。

DHCPサーバーは常にgiaddrだけを見てプールを選択する

直接接続クライアントではgiaddr = 0だからです。

Cisco IOS XEサーバーでは、

直接接続クライアント
→ 受信インターフェースのサブネット

リレー経由クライアント
→ giaddrのサブネット

として区別します。

52. 直接接続クライアントの例

サーバーインターフェース：

GigabitEthernet0/0
192.168.20.1/24

クライアントのDHCPDISCOVER：

giaddr = 0.0.0.0

サーバーに、

192.168.20.0/24

に対応するDHCPプールがあれば、そのプールが候補になります。

53. リレー経由クライアントの例

トポロジ：

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

リレーインターフェース
192.168.30.1

DHCPサーバー
192.168.100.10

リレー後のメッセージで、

giaddr = 192.168.30.1

なら、サーバーは、

192.168.30.0/24

に対応するプールを選択します。

54. サーバー自身のサブネットではなくクライアントサブネットが重要

リレー環境では、DHCPサーバー自身が、

192.168.100.0/24

に存在していても、

クライアントが、

192.168.30.0/24

に存在するなら、

クライアントへ割り当てるアドレスはクライアント側サブネットに対応するプールから選ぶ必要があります。

その判断材料がgiaddrです。

55. サーバーへの到着インターフェースだけでリレー経由クライアントのプールを選ばない

リレー環境では、

DHCPサーバーがパケットを受信したサーバー側インターフェースのサブネット

だけを基準にすると、クライアントサブネットを正しく判別できません。

そのためサーバーはリレーが設定したgiaddrを利用します。

56. 直接接続とリレーを比較する

この違いはDHCPv4の重要な判断ポイントです。

57. Option 82はここでは深掘りしない

DHCPリレーでは、リレーエージェント情報オプション（Relay Agent Information Option）、いわゆるOption 82を利用する構成もあります。

ただしここでは、

giaddr
と
直接接続クライアントとリレー経由クライアント
と
基本的なプール選択

に集中します。

Option 82の詳細動作は扱いません。

58. DHCPメッセージを「どこまで進んだか」で読む

トラブルシューティングではメッセージの存在を、

DHCP処理がどの段階まで進んだか

という証拠として利用できます。

例えば、

DISCOVERあり
OFFERなし

と、

OFFERあり
REQUESTなし

では、確認すべき段階が異なります。

59. DISCOVERすら確認できない場合

期待する確認地点でDHCPDISCOVERが見えない場合、

DHCP処理の最初の段階より前
または
そこまでメッセージが届いていない

可能性を考えます。

ただしこの時点だけで具体的根本原因を決めません。

60. DISCOVERあり・OFFERなし

確認情報が、

DHCPDISCOVER
確認できる

DHCPOFFER
確認できない

なら、

クライアントからの探索メッセージまでは進んだ

と判断できます。

次に見る範囲は、

サーバーとリレーへの到達
サーバー側処理
プール等の応答条件

です。

具体的な修正は後のトラブルシューティングで扱います。

61. OFFERありならサーバーは少なくとも応答段階まで進んでいる

DISCOVER
↓
OFFER

まで確認できたなら、

少なくとも、

クライアントのDISCOVERをサーバー側が処理
↓
サーバーがOFFERを生成

する段階まで進んでいます。

62. OFFERあり・REQUESTなし

確認情報が、

DISCOVER
OFFER
確認済み

REQUEST
確認できない

なら、

DHCPサーバーがOFFERを生成するところまでは進んでいます。

その次は、

クライアントがOFFERを受信・選択できたか

という段階を確認します。

63. REQUESTあり・ACKもNAKもない

REQUEST
確認済み

ACK／NAK
確認できない

なら、

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

次の確認範囲は、

サーバーによるREQUEST処理
と
サーバーからの応答

です。

64. REQUEST後にNAKがある場合は「応答なし」ではない

REQUEST
↓
NAK

の場合、サーバーは応答しています。

問題は、

サーバーから返事がない

ことではなく、

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

ことです。

65. ACKまで確認できた場合

DISCOVER
OFFER
REQUEST
ACK

が一連で確認できれば、

DHCPサーバー側メッセージフローはリース確定段階まで進んでいます。

クライアントが依然として期待アドレスを持たない場合は、

ACK後のクライアント側適用

など、より後段を確認する必要があります。

66. メッセージ確認有無と根本原因を分ける

例えば、

DISCOVERあり
OFFERなし

だからといって、

DHCPサーバー故障確定

とは判断しません。

原因候補には、

• リレー
• ネットワーク経路
• サーバーサービス
• プール条件
• その他サーバー側条件

などがあります。

この段階では、

どこまで処理が進んだか

を判断します。

67. メッセージの「送信」と「受信」を区別する

クライアント側で、

DISCOVER送信

を確認しても、

サーバー側で、

DISCOVER受信

できているとは限りません。

同様に、

サーバーがOFFER送信

しても、

クライアントがOFFER受信

したことまで自動的には証明されません。

68. 同じメッセージでも確認地点によって意味が変わる

例えば、

クライアント側キャプチャ
DISCOVER確認

と、

サーバー側キャプチャ
DISCOVER確認

では得られる情報が違います。

前者は、

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

証拠です。

後者は、

DISCOVERがサーバーまで到達した

証拠になります。

69. リレー環境では確認地点を3つに分ける

リレー環境では、

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

という3つの役割があります。

そのため、

クライアントがDISCOVER送信
リレーがDISCOVER受信
サーバーがリレー経由のDISCOVER受信

を分けて考えます。

70. giaddrが入っているかはリレー処理の重要な確認情報

サーバー側でリレー経由のDHCPDISCOVERを確認したとき、

giaddr

が期待するクライアント側サブネットのアドレスになっているかを確認できます。

これは、

リレーがどのクライアントサブネットからメッセージを転送したか

を判断する材料です。

71. giaddrが期待サブネットと異なる場合

例えばクライアントが、

192.168.30.0/24

にいるのに、サーバーが受信したメッセージのgiaddrが別サブネットを示している場合、

サーバーのプール選択へ影響する可能性があります。

このページでは、

giaddrとクライアントサブネットが整合しているか

まで判断します。

具体的なリレー設定修正は後で扱います。

72. DHCP処理を一つのフローとして読む

初回取得では、

クライアントがサーバーを探索
↓
サーバーが候補を提示
↓
クライアントが候補を選択
↓
サーバーが要求を確定

という責任の受け渡しがあります。

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

最後に正常確認できたメッセージ

と、

次に期待するメッセージ

を組み合わせます。

73. 試験での判断例1：DORA順序

正しい初期取得順序は、

DHCPDISCOVER
↓
DHCPOFFER
↓
DHCPREQUEST
↓
DHCPACK

です。

74. 試験での判断例2：サーバー探索

クライアントが利用可能なDHCPサーバーを探すために送るメッセージは、

DHCPDISCOVER

です。

75. 試験での判断例3：サーバーからの提案

サーバーがクライアントへアドレスや設定を提案するメッセージは、

DHCPOFFER

です。

OFFER時点ではリース確定ではありません。

76. 試験での判断例4：OFFER選択

複数サーバーからOFFERを受けたクライアントが、選択したサーバーを示す初回取得メッセージは、

DHCPREQUEST

です。

Server Identifierも重要な確認情報になります。

77. 試験での判断例5：リース確定

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

DHCPACK

です。

78. 試験での判断例6：UDPポート

DHCPv4の基本ポートは、

サーバー側UDP 67
クライアント側UDP 68

です。

クライアントからサーバー方向では代表的に、

68 → 67

として読みます。

リレー経由ではサーバー → リレー区間が、

67 → 67

になる点も区別します。

79. 試験での判断例7：別サブネットのサーバー

クライアントとDHCPサーバーが別サブネットにいる場合、

DHCPリレー

がクライアントブロードキャストをリモートサーバーへ転送します。

Cisco IOSおよびIOS XEではip helper-addressが代表的な仕組みです。

80. 試験での判断例8：リレー経由クライアントのプール

サーバーが受け取ったDHCPDISCOVERで、

giaddr = 10.10.20.1

なら、

サーバーは、

10.10.20.1が属するサブネット

に対応するプールを選択します。

81. 試験での判断例9：直接接続クライアントのプール

Cisco IOS XE DHCPサーバーへクライアントが直接接続し、

giaddr = 0

なら、

サーバーは、

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

に対応するプールを選択します。

82. 試験での判断例10：NAK

クライアントのアドレス要求をサーバーが受け入れられない場合のメッセージは、

DHCPNAK

です。

83. 試験での判断例11：アドレス重複検知

クライアントが提示されたアドレスが既に使用されていることを検知した場合に送るメッセージは、

DHCPDECLINE

です。

84. 試験での判断例12：リース返却

クライアントが保持リースをサーバーへ返却するメッセージは、

DHCPRELEASE

です。

85. 試験での判断例13：追加設定パラメーター

既にアドレスを持つクライアントが追加設定パラメーターを要求するメッセージは、

DHCPINFORM

です。

86. 試験での判断例14：DISCOVER・REQUEST・RELEASEの違い

DHCPDISCOVER
→ サーバー探索

DHCPREQUEST
→ アドレスやOFFERなどを要求

DHCPRELEASE
→ 保持リースを返却

です。

役割を混同しません。

87. 試験での判断例15：DORAがOFFERで止まる

確認結果：

DISCOVER
確認

OFFER
確認

REQUEST
なし

なら、

サーバーがOFFERを返す段階までは成功

しています。

次に見るのはクライアントがOFFERを受信・選択してREQUESTへ進む段階です。

88. 試験での判断例16：複数OFFERから選ばれたサーバー

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

REQUEST
Server Identifier = サーバーB

なら、

クライアントが選択したサーバー
=
サーバーB

と判断できます。

89. 試験での判断例17：直接接続クライアント

サーバーとクライアントが同一サブネットで、

giaddr = 0

なら、

直接接続クライアントとして受信インターフェースサブネットをプール選択の判断材料にします。

90. 試験での判断例18：リレーの役割

クライアントブロードキャストを別サブネット上のDHCPサーバーへ届ける役割は、

DHCPリレーエージェント

です。

Cisco IOSおよびIOS XEではip helper-addressが代表的な実現方法です。

91. 試験での判断例19：67と68

UDP 67
→ DHCPサーバー

UDP 68
→ DHCPクライアント

です。

リレーエージェントもサーバー側ではUDP 67を使用するため、リレー環境ではサーバー → リレーが67 → 67になることがあります。

92. 試験での判断例20：ACKとNAK

DHCPACK
→ 要求を受け入れる

DHCPNAK
→ 要求したアドレスをそのまま利用させられない

として区別します。

93. 試験での判断例21：DECLINEとRELEASE

DHCPDECLINE
→ 提示アドレスを利用できないとクライアントが通知

DHCPRELEASE
→ 保持リースをクライアントが返却

です。

どちらもクライアント → サーバーですが意味は異なります。

94. 試験での判断例22：INFORM

クライアントが既にIPv4アドレスを持っており、追加設定パラメーターだけをDHCPサーバーから取得したい場合は、

DHCPINFORM

です。

95. 試験での判断例23：OFFERの意味

DHCPOFFERを受信

した状態は、

サーバーから提案を受けた

ことを示します。

リースが最終確定した

ことを示すわけではありません。

96. 試験での判断例24：giaddrからサブネットを判断

サーバーが受信したメッセージに、

giaddr
172.16.40.1

が設定されている場合、

172.16.40.1が属するクライアントサブネット

を基準として対応プールを判断します。

サーバー自身のLANだけを見ません。

97. 試験での判断例25：停止段階

確認結果：

DISCOVER
OFFER
REQUEST
確認

ACK／NAK
なし

なら、

クライアントがREQUESTを送る段階までは進んだ

と判断できます。

次に見るのはサーバーのREQUEST処理と応答段階です。

98. メッセージ停止段階の比較表

この表だけで根本原因を確定するのではなく、処理段階を絞ります。

99. 直接接続クライアントとリレー経由クライアントの比較

この違いを理解するとDHCPサーバー側のパケット情報を読みやすくなります。

100. DHCPメッセージ比較

101. DHCPv4処理を判断する基本フロー

DHCPDISCOVERは確認できるか
├─ なし
│  └─ クライアントから最初のメッセージが出る段階を確認
│
└─ あり
   ↓
DHCPOFFERは確認できるか
├─ なし
│  └─ リレーまたはサーバーの応答段階までを確認
│
└─ あり
   ↓
DHCPREQUESTは確認できるか
├─ なし
│  └─ クライアントのOFFER受信・選択段階を確認
│
└─ あり
   ↓
DHCPACKまたはDHCPNAKは確認できるか
├─ なし
│  └─ サーバーのREQUEST処理・応答段階を確認
│
├─ NAK
│  └─ 要求アドレスはそのまま利用できない
│
└─ ACK
   ↓
リース確定段階まで進んでいる

102. リレー環境を判断する基本フロー

クライアントとサーバーは同一サブネットか
├─ あり
│  ↓
│  直接接続クライアント
│  giaddr = 0
│  受信インターフェースサブネットでプール判断
│
└─ なし
   ↓
DHCPリレーが必要
   ↓
クライアント側L3インターフェースでブロードキャストを受信
   ↓
リレーがgiaddrを設定
   ↓
リモートDHCPサーバーへ転送
   ↓
サーバーはgiaddrのサブネットでプール判断

103. DORAだけで終わらせない

試験では、

DORA

という4文字だけを覚えるのではなく、

どのメッセージを誰が送るか

そのメッセージは何を意味するか

どこまで処理が進んだか

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

104. OFFERとACKの違いを確実にする

特に混同しやすいのが、

DHCPOFFER

と、

DHCPACK

です。

OFFER
→ 提案

ACK
→ 要求受理・確定

として区別します。

105. NAKとDECLINEの方向を確実にする

DHCPNAK
サーバー → クライアント

DHCPDECLINE
クライアント → サーバー

です。

NAK
→ サーバーが要求を受け入れない

DECLINE
→ クライアントが提示アドレスを利用できないと通知

という責任の違いがあります。

106. DISCOVERとINFORMも目的が違う

DHCPDISCOVER
→ アドレスを取得するためサーバーを探索

DHCPINFORM
→ アドレスを既に持つクライアントが追加パラメーターを要求

です。

INFORMをDHCPDISCOVERの代わりに使うわけではありません。

107. リレーとサーバーを同じ役割として扱わない

DHCPリレーは、

アドレスリースを決定するサーバー

ではありません。

基本的な役割は、

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

ことです。

アドレスを提供する役割はDHCPサーバーにあります。

108. giaddrの役割を一文で説明する

giaddrは、

リレー経由のDHCPメッセージで
DHCPサーバーがクライアント側サブネットを識別するための
ゲートウェイIPアドレス情報

として理解します。

109. 直接接続クライアントでは受信インターフェースが重要

giaddr = 0の直接接続クライアントに対してCisco IOS XE DHCPサーバーは、

DHCPDISCOVERをどのインターフェースで受信したか

を利用して対応するサブネットやプールを判断します。

したがって、

giaddrが0
→ プールを選択できない

ではありません。

110. ここではIOSコマンド暗記へ進みすぎない

この段階で重要なのは、

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

DORA
その他メッセージ

UDP 67／68

giaddr

直接接続とリレー経由のプール選択

の関係です。

具体的な、

DHCPクライアント設定
DHCPプール設定
`show`系コマンド
`debug`系コマンド
`release`／`renew`系コマンド

は次の段階で扱います。

111. 総合的な根本原因修正までは進まない

ここでは、

DISCOVERあり
OFFERなし

などのメッセージ情報から、

どの段階で処理が止まっているか

を判断します。

具体的に、

プールを修正する
ヘルパーアドレスを修正する
サービスを再有効化する
バインディングや競合を修正する

といった総合トラブルシューティングは後で扱います。

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

次の対応を迷わず判断できるようにします。

DISCOVER
→ クライアントがサーバーを探索

OFFER
→ サーバーがアドレスやパラメーターを提案

REQUEST
→ クライアントがアドレスやOFFERを要求

ACK
→ サーバーが要求を受け入れる

NAK
→ サーバーが要求アドレスを受け入れない

DECLINE
→ クライアントが提示アドレスを利用できないと通知

RELEASE
→ クライアントがリースを返却

INFORM
→ アドレスを持つクライアントが追加パラメーターを要求

113. 直接接続とリレー経由の判断も確実にする

giaddr = 0
と
サーバーとクライアントが直接接続
→ 受信インターフェースサブネットを基準

giaddr ≠ 0
と
リレー経由
→ giaddrのサブネットを基準

としてCisco IOS XE DHCPサーバーのプール選択を判断します。

114. メッセージ停止段階も確実にする

DISCOVERなし
→ 最初のクライアント送信段階以前を確認

DISCOVERあり・OFFERなし
→ サーバーまたはリレーの応答段階

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

REQUESTあり・ACK・NAKなし
→ サーバーのREQUEST処理・応答段階

ACKあり
→ リース確定段階まで進行

と読みます。

まとめ

DHCPv4の初回アドレス取得では、

DHCPDISCOVER
↓
DHCPOFFER
↓
DHCPREQUEST
↓
DHCPACK

というDORAが基本です。

ただしDHCPには、

DHCPNAK
DHCPDECLINE
DHCPRELEASE
DHCPINFORM

もあり、それぞれ送信方向と役割が異なります。

DHCPv4の基本ポートは、

サーバー
UDP 67

クライアント
UDP 68

です。

直接接続クライアントへのサーバー応答では代表的に、

67 → 68

となります。

一方、リレー経由ではサーバー → リレーエージェント区間が、

67 → 67

となり、リレーエージェントがクライアントへメッセージを転送します。

クライアントとサーバーが別サブネットならDHCPリレーを使用し、Cisco IOSおよびIOS XEではip helper-addressが代表的なリレーの仕組みです。

リレー経由クライアントでは、

giaddr ≠ 0
→ giaddrが属するサブネットからプールを判断

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

giaddr = 0
→ 受信インターフェースに設定されたサブネットからプールを判断

します。

トラブルシューティングでは単にDORAを暗記するのではなく、

最後に確認できたメッセージ
↓
次に期待されるメッセージ
↓
DHCP処理がどの段階まで進んだか

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