DHCPv4 on IOS

このページで学ぶこと

• IOS Client Configuration
• Client Configuration Verification
• Client Operational Address Verification
• Client Lease Verification
• Client Message Debug
• Client Release
• Client Renew
• Server Excluded Address
• Server Pool Network
• Server Default Router Option
• Server DNS Option
• Server Pool Verification
• Server Binding Verification
• Server Conflict Verification
• Server Statistics Verification
• DHCP Service State
• Relay Helper Configuration
• Relay Helper Placement

1. IOSではDHCPクライアント・サーバー・リレーの役割を分けて確認する

Cisco IOS・IOS XEデバイスは、構成によって、

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

として動作できます。

同じ「DHCP」という機能でも、確認する設定やコマンドは異なります。

基本的には、

クライアント
→ 自分自身がアドレスを取得する

サーバー
→ クライアントへアドレス・パラメーターを提供する

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

と役割を分けます。

2. コマンドは「どの役割を確認するか」で選択する

例えば、

show dhcp lease

と、

show ip dhcp binding

はどちらもリースに関係しますが、確認対象は異なります。

show dhcp lease
→ IOSデバイス自身がDHCPクライアントとして取得したリース

show ip dhcp binding
→ IOSデバイスがDHCPサーバーとして保持しているクライアントバインディング

です。

似たコマンド名だけで判断せず、

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

を先に識別します。

3. IOSインターフェースをDHCPクライアントにする

Cisco IOS・IOS XEインターフェースがIPv4アドレスをDHCPから取得する代表的な設定は、

interface GigabitEthernet0/0
 ip address dhcp
 no shutdown

です。

中心となるコマンドは、

ip address dhcp

です。

4. ip address dhcpはインターフェース設定

ip address dhcpはグローバル設定ではなく、対象インターフェースへ設定します。

Router(config)# interface GigabitEthernet0/0
Router(config-if)# ip address dhcp

この設定によって、そのインターフェースはDHCPクライアントとしてIPv4設定の取得を試みます。

5. ip address dhcpとip helper-addressを混同しない

次の2つは役割が異なります。

したがって、

ルーター自身がDHCPでアドレスを取得したい

ならip address dhcpです。

LANクライアントのDHCPブロードキャストを別サブネットのサーバーへ送りたい

ならip helper-addressです。

6. 設定と動作状態を分けて確認する

インターフェースに、

ip address dhcp

が設定されていても、

現在アドレスを取得できている

とは限りません。

したがって、

設定
↓
動作中アドレス
↓
リース

を分けて確認します。

7. クライアント設定をshow running-config interfaceで確認する

特定インターフェースがDHCPクライアントとして設定されているかを直接確認する代表例は、

show running-config interface GigabitEthernet0/0

です。

期待する出力例：

interface GigabitEthernet0/0
 ip address dhcp
 no shutdown

ここでは、

ip address dhcpが設定されているか

を確認します。

8. running-configは「設定」を確認する

show running-config interfaceで確認できるのは、

デバイスへ現在設定されている設定

です。

例えば、

ip address dhcp

があればDHCPクライアント設定は存在します。

しかし、この情報だけでは、

DHCPサーバーからアドレス取得済み

とは判断できません。

9. 動作中アドレスはshow ip interface briefで確認する

インターフェースが現在使用しているIPv4アドレスを素早く確認する代表的コマンドは、

show ip interface brief

です。

例：

Interface              IP-Address      OK? Method Status Protocol
GigabitEthernet0/0     192.168.10.25   YES DHCP   up     up

ここでは、

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

を確認できます。

10. 設定済みと取得済みを分離する

次の2つは別の確認です。

show running-config interface GigabitEthernet0/0
→ ip address dhcpあり

show ip interface brief
→ 192.168.10.25を使用中

前者は設定。

後者は動作状態です。

11. ip address dhcpがなければクライアント設定不足を疑う

シナリオ：

GigabitEthernet0/0にアドレスがない

show running-config interface GigabitEthernet0/0
↓
ip address dhcpなし

この場合、サーバープールや競合を先に原因とするより、

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

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

12. クライアント設定不足への基本修正

インターフェースをDHCPクライアントとして動作させる要件なら、

interface GigabitEthernet0/0
 ip address dhcp
 no shutdown

のように設定します。

その後、

show ip interface brief

などで実際のアドレス取得状態を確認します。

13. IOSクライアントのリースはshow dhcp leaseで確認する

IOSデバイス自身がDHCPクライアントとして取得したリースを確認する代表的コマンドは、

show dhcp lease

です。

これはクライアント側の確認コマンドです。

14. show dhcp leaseとshow ip dhcp bindingの違い

混同しやすいため明確に分けます。

試験では、

誰のリースを見ているか

を確認します。

15. クライアント確認は3種類に分けられる

IOS DHCPクライアントでは基本的に、

設定
show running-config interface

↓

動作中アドレス
show ip interface brief

↓

リース
show dhcp lease

と役割を分けられます。

16. リースがないからといって設定までないとは限らない

例えば、

show running-config interface GigabitEthernet0/0
→ ip address dhcpあり

show dhcp lease
→ 有効なリースなし

なら、

設定は存在
しかしリース取得は成立していない

と分けて考えます。

17. showコマンドを先に使う

DHCPクライアントに問題がある場合でも、最初からデバッグを有効にする必要はありません。

まず、

show running-config interface
show ip interface brief
show dhcp lease

などで現在状態を確認します。

必要な場合に、より詳細なメッセージ処理へ進みます。

18. debug dhcp detailはクライアント側メッセージ確認に使う

IOSデバイス自身がDHCPクライアントとして行うDHCPメッセージ処理を詳しく確認するときは、

debug dhcp detail

を利用できます。

クライアントが送受信しているDHCPパケットや状態遷移等を詳しく確認するためのデバッグです。

19. debug dhcp detailとサーバー側デバッグを混同しない

クライアント側の代表的デバッグ：

debug dhcp detail

サーバー側では別のデバッグがあります。

例えば、

debug ip dhcp server packets

です。

したがって、

IOSデバイス自身がDHCPクライアント

なのか、

IOSデバイスがDHCPサーバー

なのかを先に判断します。

20. デバッグを初手に固定しない

デバッグは詳細な情報を取得できますが、

最初に必ずデバッグ

ではありません。

基本的には、

設定確認
↓
動作状態確認
↓
リース確認
↓
必要ならデバッグ

と進めます。

21. debug dhcp detailで見る目的

debug dhcp detailを使う目的は、

クライアントがDHCPメッセージを送信しているか

サーバーからメッセージを受信しているか

クライアントのDHCP処理がどこまで進んでいるか

などを詳しく確認することです。

22. デバッグだけで設定正常とは判断しない

DHCPパケットが確認できても、

running-configが期待どおり

とは限りません。

また設定が正しくても、正常にリースを取得できるとは限りません。

設定
動作状態
メッセージ

をそれぞれ分離します。

23. release dhcpは現在のDHCPリースを解放する

IOS DHCPクライアントが保持するリースを明示的に返却する代表的コマンドは、

release dhcp GigabitEthernet0/0

です。

インターフェース種別・番号を指定します。

24. release dhcpはインターフェースのip address dhcp設定を削除するコマンドではない

release dhcpを実行するとDHCP由来のリースを解放します。

しかし、

interface GigabitEthernet0/0
 ip address dhcp

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

リース

と、

クライアント設定

を分けて考えます。

25. DHCP由来アドレスがないインターフェースではreleaseが成立しない

release dhcpはDHCPから割り当てられたアドレスを保持しているインターフェースを対象とします。

したがって、

DHCP由来アドレスなし

のインターフェースに対してリース解放を実行しても正常な解放処理にはなりません。

26. renew dhcpはDHCPリースの更新を進める

DHCP由来のリースを保持しているインターフェースでは、

renew dhcp GigabitEthernet0/0

を利用してリース更新を明示的に進められます。

27. renew dhcpを単純な「アドレス新規取得コマンド」と覚えない

renew dhcpはDHCP由来のリースに対する更新・再バインド処理を進めるコマンドです。

したがって、

DHCPクライアント設定が存在しない

状態で、

renew dhcp

だけを実行すればクライアント設定まで自動作成されるわけではありません。

28. releaseとrenewは役割が違う

release dhcp
→ 現在のリースを解放

renew dhcp
→ DHCPリースの更新処理を進める

です。

似ていますが逆の役割です。

29. 新しいDHCPサイクルを明示的に発生させるケース

Cisco IOS XEでは、DHCPクライアント関連設定変更後などに新しいDHCPサイクルを発生させる手段として、

release dhcp GigabitEthernet0/0
renew dhcp GigabitEthernet0/0

という操作が使用される場合があります。

ただし重要なのは、

release

と、

renew

の個別の意味を理解することです。

30. 解放・更新後は結果を確認する

コマンドを実行しただけで、

修正完了

とはしません。

例えば、

show ip interface brief
show dhcp lease

を使って、

現在アドレスを取得できたか
新しいリース状態はどうか

を確認します。

31. クライアント側の基本確認フロー

show running-config interface GigabitEthernet0/0
↓
ip address dhcpの有無
↓
show ip interface brief
↓
動作中アドレス
↓
show dhcp lease
↓
リース
↓
必要ならdebug dhcp detail

です。

32. IOSデバイスをDHCPサーバーとして動作させる

Cisco IOS・IOS XEデバイスはDHCPサーバーとしても動作できます。

代表的な設定：

ip dhcp excluded-address 10.10.10.1 10.10.10.20

ip dhcp pool USERS
 network 10.10.10.0 255.255.255.0
 default-router 10.10.10.1
 dns-server 10.10.10.53

各行には異なる役割があります。

33. ip dhcp excluded-addressはグローバル設定

動的DHCP割り当てからアドレスを除外するときは、

ip dhcp excluded-address

を使用します。

例：

ip dhcp excluded-address 10.10.10.1 10.10.10.20

これは、

10.10.10.1 ～ 10.10.10.20

を動的割り当て対象外にします。

34. 1アドレスだけを除外にすることもできる

1つのアドレスだけを除外する場合は、

ip dhcp excluded-address 10.40.50.25

のように指定できます。

必ず範囲を指定しなければならないわけではありません。

35. 除外アドレスはプールネットワークそのものを変更しない

例えば、

network 10.10.10.0 255.255.255.0

というプールがあり、

ip dhcp excluded-address 10.10.10.1 10.10.10.20

を設定した場合、

プールのサブネットは依然として、

10.10.10.0/24

です。

その中の指定アドレスを動的割り当てから除外します。

36. ゲートウェイ等のインフラ用アドレスを除外にできる

例えば、

10.10.10.1

をルーターインターフェースが固定で使用している場合、そのアドレスをDHCPクライアントへ動的配布しないよう除外にできます。

同様に、

• サーバー
• プリンター
• ネットワークデバイス

など固定使用するアドレスを除外する構成があります。

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

除外アドレス

は管理者が動的割り当て対象外として設定したアドレスです。

競合

はDHCPサーバーがアドレス競合として記録している状態です。

意味が異なります。

38. ip dhcp poolでプール設定モードへ入る

DHCPプールを作成する代表例：

ip dhcp pool USERS

です。

この後、

network
default-router
dns-server

などのプールサブコマンドを設定します。

39. プール名はサブネットアドレスそのものではない

例：

ip dhcp pool USERS

のUSERSはプール名です。

実際にアドレスを割り当てるサブネットは、

network

で定義します。

40. networkでプール対象サブネットを指定する

例：

ip dhcp pool USERS
 network 10.20.30.0 255.255.255.0

このnetworkは、

このプールがどのサブネットを対象とするか

を定義します。

41. networkとdefault-routerは別の役割

network 10.20.30.0 255.255.255.0

はプール対象サブネットを定義します。

default-router 10.20.30.1

はクライアントへ通知するデフォルトゲートウェイを定義します。

同じものではありません。

42. networkとip helper-addressも別の役割

network

はDHCPサーバープール側の設定です。

ip helper-address

はDHCPリレー側インターフェース設定です。

したがって、

クライアントサブネットをプールへ定義

したい場合にip helper-addressは使用しません。

43. プールネットワークはクライアントサブネットと整合する必要がある

クライアントが、

192.168.60.0/24

に存在する一方、プールが、

network 192.168.50.0 255.255.255.0

なら、

プールネットワーク
クライアントサブネット

が一致していません。

設定確認では重要な不一致です。

44. default-routerはクライアントへゲートウェイを通知する

例：

ip dhcp pool USERS
 network 10.20.30.0 255.255.255.0
 default-router 10.20.30.1

クライアントはDHCP経由で、

デフォルトゲートウェイ
10.20.30.1

を受け取ることができます。

45. default-routerはIOSデバイス自身のデフォルトルート設定ではない

次を混同してはいけません。

default-router 10.20.30.1

は、

DHCPクライアントへ通知するゲートウェイオプション

です。

ルーター自身のルーティングテーブルへデフォルトルートを追加する、

ip route 0.0.0.0 0.0.0.0 ...

とは別です。

46. dns-serverはクライアントへDNSサーバーアドレスを通知する

例：

ip dhcp pool USERS
 dns-server 10.20.30.53

この設定により、DHCPクライアントへDNSサーバーアドレスを通知できます。

47. dns-serverはIOS自身をDNSサーバーへ変えるコマンドではない

プール内の、

dns-server 10.20.30.53

は、

クライアントへ10.20.30.53をDNSサーバーとして通知

する設定です。

IOSデバイス自身がDNSリゾルバーになることを意味しません。

48. network・default-router・dns-serverを比較する

それぞれの責任を分けます。

49. DHCPサーバーでは設定と動作情報を分ける

サーバーでも、

設定がある

ことと、

実際にアドレスが割り当てられている

ことは別です。

設定確認後は、

プール
バインディング
競合
統計

などの動作情報を目的別に確認します。

50. show ip dhcp poolでプール情報を確認する

代表的コマンド：

show ip dhcp pool

です。

DHCPアドレスプールに関する情報を確認できます。

51. show ip dhcp poolはプール利用状況の確認に使う

例えば、

プール名
サブネット
総アドレス数
リース済みアドレス
除外アドレス

など、プールの状態や利用状況を判断する材料になります。

52. プールの残りアドレスを調べたいならプールを見る

クライアントへ新しいアドレスを提供できる余地があるか確認するとき、

show ip dhcp pool

は重要です。

ただし実際に、

どのクライアントへどのアドレスが割り当てられているか

を見るコマンドとは役割が異なります。

53. show ip dhcp bindingで現在のバインディングを確認する

サーバーが保持しているDHCPバインディングを確認する代表的コマンド：

show ip dhcp binding

です。

54. バインディングはアドレスとクライアントの対応

DHCPバインディングでは、

IPアドレス
クライアント識別子・ハードウェアアドレス
リース情報

などを確認できます。

つまり、

どのアドレスが
どのクライアントへ
割り当てられているか

を確認するために利用します。

55. プールとバインディングは目的が違う

show ip dhcp pool
→ プール全体の状態

show ip dhcp binding
→ 個別クライアントへのバインディング

です。

試験で、

プールの残りアドレス
と
現在どのクライアントがアドレスを使用しているか

を確認したいなら、両方を使い分けます。

56. show ip dhcp conflictで競合を確認する

DHCPサーバーが競合として記録しているアドレスを確認する代表的コマンド：

show ip dhcp conflict

です。

57. 競合とバインディングを混同しない

show ip dhcp binding

はリース・バインディング。

show ip dhcp conflict

は競合記録です。

アドレスが競合扱いになっているかを確認したい場合は、

show ip dhcp conflict

を使用します。

58. 競合アドレスは通常の割り当て対象として扱えないことがある

DHCPサーバーがアドレス競合を検知・記録している場合、そのアドレスは通常の動的割り当てに使用されない状態になり得ます。

したがって、

プールにはアドレスがありそうなのに
期待どおり配布されない

シナリオでは競合情報も確認材料になります。

具体的な競合解消手順は、原因確認後に判断します。

59. show ip dhcp server statisticsでメッセージ統計を確認する

DHCPサーバーの送受信メッセージ統計を確認する代表的コマンド：

show ip dhcp server statistics

です。

60. 統計ではメッセージカウンターを見る

show ip dhcp server statisticsでは、

DHCPDISCOVER
DHCPOFFER
DHCPREQUEST
DHCPACK
DHCPNAK

などのメッセージ送受信カウンターを判断する材料が得られます。

61. 統計は個々のクライアントバインディング一覧ではない

show ip dhcp server statisticsで、

どのクライアントがどのアドレスをリース中か

を確認するのが主目的ではありません。

その場合は、

show ip dhcp binding

です。

62. サーバー確認コマンドを目的別に整理する

コマンド名が似ているため、目的との対応を覚えます。

63. no service dhcpは重要なグローバル状態

Cisco IOS・IOS XEではDHCPサーバー・リレーサービスは通常有効です。

設定に、

no service dhcp

がある場合、

DHCPサーバー
DHCPリレー

のサービスが無効になります。

64. プールが正しくてもno service dhcpならサーバーは機能しない

シナリオ：

ip dhcp pool USERS
 network 10.10.10.0 255.255.255.0
 default-router 10.10.10.1

が存在していても、

no service dhcp

が設定されている場合、

DHCPサーバー機能が無効です。

したがって、

プール設定がある
=
DHCPサーバーが稼働中

とは判断しません。

65. ヘルパーが正しくてもno service dhcpならリレーに影響する

例えば、

interface Vlan30
 ip helper-address 10.99.0.10

が存在していても、

グローバル設定が、

no service dhcp

なら、IOSのDHCPリレーサービスが無効です。

66. service dhcpで再度有効化する

no service dhcpによって無効化されているDHCPサーバー・リレー機能を再度有効化するグローバル設定は、

service dhcp

です。

67. service dhcpをクライアント設定と混同しない

service dhcp

はDHCPサーバー・リレーサービスのグローバル状態です。

インターフェース自身をDHCPクライアントにするコマンドは、

ip address dhcp

です。

68. no service dhcpの確認はグローバル設定を見る

DHCPサーバー・リレーがまったく動作していない場合、

show running-config

などから、

no service dhcp

が存在しないか確認することが重要です。

69. リレーにはip helper-addressを使う

クライアントとDHCPサーバーが別サブネットにある場合、Cisco IOS・IOS XEでは代表的に、

ip helper-address <DHCP-server-address>

を使用してDHCPリレーを構成します。

70. ip helper-addressはインターフェース設定

例：

interface Vlan30
 ip address 10.20.30.1 255.255.255.0
 ip helper-address 10.99.0.10

ip helper-addressはクライアント側ブロードキャストを受信するL3インターフェースへ設定します。

71. クライアント側L3インターフェースという考え方

トポロジ：

クライアント
10.20.30.0/24
      |
      v
Vlan30
10.20.30.1
      |
      |
      v
リモートDHCPサーバー
10.99.0.10

この場合、

Vlan30

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

ここへ、

ip helper-address 10.99.0.10

を設定します。

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

次の考え方は誤りです。

DHCPサーバーに近いインターフェースへ
ip helper-addressを置く

重要なのは距離ではありません。

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

です。

73. ルーテッド物理インターフェースでも考え方は同じ

例えば、

interface GigabitEthernet0/1
 ip address 10.20.30.1 255.255.255.0
 ip helper-address 10.99.0.10

のように、クライアントLANを収容するルーテッドインターフェースへ設定できます。

74. Router-on-a-Stickならクライアント側サブインターフェースを考える

例えばクライアントVLAN 30を、

GigabitEthernet0/0.30

がルーティングしている場合、

そのサブインターフェースがクライアントブロードキャストを受信するL3インターフェースになります。

ヘルパー配置は、

物理的にサーバーに近い場所

ではなく、

クライアントサブネットのL3ゲートウェイ

を基準に判断します。

75. SVI環境ならクライアントVLANのSVIを考える

レイヤー3スイッチで、

interface Vlan30
 ip address 10.20.30.1 255.255.255.0

がクライアントVLAN 30のデフォルトゲートウェイなら、そのSVIがクライアント側L3インターフェースです。

リモートDHCPサーバーへリレーする場合、

ip helper-address 10.99.0.10

をそのSVIへ設定します。

76. ヘルパーアドレスにはリモートDHCPサーバーを指定する

例：

ip helper-address 10.99.0.10

では、

10.99.0.10

がリレー先として指定されたサーバーアドレスです。

クライアントへ割り当てるデフォルトゲートウェイアドレスではありません。

77. ヘルパーアドレスとデフォルトルーターを混同しない

例：

クライアントゲートウェイ
10.20.30.1

DHCPサーバー
10.99.0.10

なら、

リレー側：

ip helper-address 10.99.0.10

サーバープール側：

default-router 10.20.30.1

です。

役割がまったく異なります。

78. ヘルパー設定の確認ではインターフェースも見る

単に、

ip helper-address 10.99.0.10

という行が存在するだけでは不十分です。

どのインターフェースに設定されているか

も重要です。

79. 正しいヘルパーが誤ったインターフェースにある場合

シナリオ：

クライアントVLAN
Vlan30

ヘルパー
サーバー側インターフェースにだけ存在

の場合、

クライアントのDHCPブロードキャストを受信するVlan30でリレーできる設定になっているかを確認します。

80. ヘルパー配置の修正

クライアント側SVIにヘルパーが必要なら、

interface Vlan30
 ip helper-address 10.99.0.10

のように、クライアントブロードキャストを受信するL3インターフェースへ配置します。

81. サーバーとクライアントが同一サブネットならリレーは通常不要

DHCPサーバーがクライアントと同じブロードキャストドメイン・IPサブネットに存在しているなら、クライアントブロードキャストをサーバーが直接受信できます。

その場合、

ip helper-address

を必ず必要とするわけではありません。

82. リレーが必要かはトポロジから判断する

クライアントとサーバーは同一サブネットか

を最初に確認します。

同一サブネット
→ 直接

異なるサブネット
→ リレーの必要性を確認

と考えます。

83. 設定と確認を一つに混ぜない

例えばサーバーで、

ip dhcp pool USERS

が存在することを確認できても、

現在バインディングが成立している

とは限りません。

リレーで、

ip helper-address

があっても、

正しいクライアント側インターフェースに配置されている

かは別確認です。

84. クライアント・サーバー・リレーの確認を整理する

85. クライアントの基本シナリオ

設定：

interface GigabitEthernet0/0
 ip address dhcp

確認：

show ip interface brief
show dhcp lease

必要なら：

debug dhcp detail

です。

86. サーバーの基本シナリオ

設定：

ip dhcp excluded-address 10.10.10.1 10.10.10.20

ip dhcp pool USERS
 network 10.10.10.0 255.255.255.0
 default-router 10.10.10.1
 dns-server 10.10.10.53

確認：

show ip dhcp pool
show ip dhcp binding
show ip dhcp conflict
show ip dhcp server statistics

です。

87. リレーの基本シナリオ

設定：

interface Vlan30
 ip address 10.20.30.1 255.255.255.0
 ip helper-address 10.99.0.10

確認ポイント：

クライアントサブネットはVlan30か
ヘルパーアドレスは正しいサーバーか
ヘルパーはクライアント側インターフェースにあるか
DHCPサービスは有効か

です。

88. 問題パターン1：DHCPクライアント設定

IOSインターフェースをDHCPv4クライアントにするコマンド：

ip address dhcp

です。

89. 問題パターン2：クライアント設定確認

GigabitEthernet0/0のクライアント設定を直接確認：

show running-config interface GigabitEthernet0/0

です。

確認対象：

ip address dhcp

です。

90. 問題パターン3：動作中アドレス

現在インターフェースへ割り当てられているIPv4アドレスを素早く確認：

show ip interface brief

です。

91. 問題パターン4：クライアントリース

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

show dhcp lease

で確認します。

92. 問題パターン5：クライアントメッセージデバッグ

クライアント側のDHCPメッセージ処理を詳しく確認：

debug dhcp detail

です。

93. 問題パターン6：クライアント解放

現在保持するDHCP由来リースを解放：

release dhcp GigabitEthernet0/0

です。

94. 問題パターン7：クライアント更新

DHCP由来リースの更新を進める：

renew dhcp GigabitEthernet0/0

です。

95. 問題パターン8：除外範囲

10.10.10.1～10.10.10.20を動的割り当てから除外：

ip dhcp excluded-address 10.10.10.1 10.10.10.20

です。

96. 問題パターン9：プールネットワーク

10.20.30.0/24をプール対象サブネットにする：

network 10.20.30.0 255.255.255.0

です。

97. 問題パターン10：デフォルトゲートウェイオプション

クライアントへ10.20.30.1をデフォルトゲートウェイとして通知：

default-router 10.20.30.1

です。

98. 問題パターン11：DNSオプション

クライアントへ10.20.30.53をDNSサーバーとして通知：

dns-server 10.20.30.53

です。

99. 問題パターン12：プール確認

プール利用状況：

show ip dhcp pool

です。

100. 問題パターン13：バインディング確認

サーバーが保持するクライアントバインディング：

show ip dhcp binding

です。

101. 問題パターン14：競合確認

競合記録：

show ip dhcp conflict

です。

102. 問題パターン15：サーバー統計

DHCPメッセージ統計：

show ip dhcp server statistics

です。

103. 問題パターン16：no service dhcp

設定：

no service dhcp

なら、

IOS DHCPサーバー・リレーサービスが無効

と判断します。

104. 問題パターン17：リレー設定

リモートDHCPサーバーが、

10.99.0.10

なら、

ip helper-address 10.99.0.10

を使用します。

105. 問題パターン18：ヘルパー配置

クライアントVLAN 30のL3ゲートウェイが、

interface Vlan30

なら、ヘルパーはクライアントブロードキャストを受信するVlan30へ設定します。

サーバー側インターフェースへ置くという判断ではありません。

106. 問題パターン19：クライアント設定欠落

シナリオ：

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

show running-config interface
↓
ip address dhcpなし

なら、

クライアントDHCP設定不足

を修正対象とします。

サーバープール枯渇をこの情報だけで確定しません。

107. 問題パターン20：更新後の確認

renew dhcp実行後にクライアント側で結果を見る代表的な2つ：

show ip interface brief
show dhcp lease

です。

動作中アドレス
と
リース

を確認します。

108. 問題パターン21：showコマンド確認後のデバッグ

設定・リースを確認しても取得が進まない場合、クライアント側メッセージ処理をさらに追う代表的コマンド：

debug dhcp detail

です。

109. 問題パターン22：解放・更新

DHCP由来リースを一度解放し、その後新しいDHCPサイクルを明示的に進めるシナリオでは、

release dhcp GigabitEthernet0/0
renew dhcp GigabitEthernet0/0

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

実行後は必ず新しい動作状態を確認します。

110. 問題パターン23：プールから通知するパラメーター

設定：

ip dhcp pool USERS
 network 10.30.40.0 255.255.255.0
 default-router 10.30.40.1
 dns-server 10.30.40.53

クライアントへ通知される代表的ネットワークパラメーターは、

デフォルトゲートウェイ
10.30.40.1

DNSサーバー
10.30.40.53

です。

111. 問題パターン24：プールとバインディング

プールの残りアドレス等を確認
→ show ip dhcp pool

どのクライアントへアドレスをリース中か確認
→ show ip dhcp binding

です。

112. 問題パターン25：競合と統計

競合記録
→ show ip dhcp conflict

DHCPメッセージカウンター
→ show ip dhcp server statistics

です。

113. 問題パターン26：サービス再有効化

設定に、

no service dhcp

があり、DHCPサーバー・リレーを再度有効化するなら、

service dhcp

です。

114. 問題パターン27：ヘルパーがサーバー側にある

シナリオ：

クライアントVLAN
Vlan30

ヘルパー
サーバー側インターフェースだけに存在

なら、

クライアントブロードキャストを受信するVlan30へ
正しいip helper-addressを配置

する必要があります。

115. 問題パターン28：1アドレスだけ除外にする

10.40.50.25だけを動的割り当てから除外：

ip dhcp excluded-address 10.40.50.25

です。

116. 問題パターン29：プールネットワーク不一致

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

192.168.60.0/24

プール：

network 192.168.50.0 255.255.255.0

なら、

プールのnetwork設定とクライアントサブネットが一致していない

と判断します。

117. 問題パターン30：インターフェース上のクライアント設定

show running-config interface GigabitEthernet0/1で確認すべきクライアント設定：

ip address dhcp

です。

118. 問題パターン31：networkの目的

プールの、

network 192.168.60.0 255.255.255.0

は、

そのプールがアドレスを提供する対象サブネットを定義

します。

DNSサーバーやリレーサーバーを指定するコマンドではありません。

119. 問題パターン32：プールとヘルパーがあるのに全く動かない

シナリオ：

プール設定あり
ヘルパー設定あり

しかし
DHCPサーバー・リレーが動作しない

グローバル設定
no service dhcp

なら、

DHCPサーバー・リレーサービスが無効

という直接的な確認情報があります。

120. クライアントコマンド比較

121. サーバーコマンド比較

122. リレー・サービスコマンド比較

123. クライアント確認フロー

DHCPクライアントとして設定されているか
↓
show running-config interface
↓
現在アドレスを取得しているか
↓
show ip interface brief
↓
リースはあるか
↓
show dhcp lease
↓
必要ならメッセージを見る
↓
debug dhcp detail

124. サーバー確認フロー

プール設定確認
↓
network
default-router
dns-server
excluded-address
↓
プール状態
show ip dhcp pool
↓
バインディング
show ip dhcp binding
↓
競合
show ip dhcp conflict
↓
統計
show ip dhcp server statistics

各コマンドは異なる確認情報を提供します。

125. リレー確認フロー

クライアントとサーバーが別サブネットか
↓
リレーが必要か
↓
クライアント側L3インターフェースを特定
↓
ip helper-addressがあるか
↓
サーバーアドレスは正しいか
↓
service dhcpが無効化されていないか

126. 設定識別で重要な組み合わせ

interface GigabitEthernet0/0
 ip address dhcp

ip dhcp excluded-address 10.10.10.1 10.10.10.20

ip dhcp pool USERS
 network 10.10.10.0 255.255.255.0
 default-router 10.10.10.1
 dns-server 10.10.10.53

interface Vlan30
 ip helper-address 10.99.0.10

役割を見分けられるようにします。

127. よくある誤判断

次の判断は避けます。

ip address dhcpがある
→ アドレス取得成功

show dhcp lease
→ サーバーが配布した全クライアントバインディングを表示

show ip dhcp binding
→ ルーター自身のクライアントリースを表示

ip helper-addressがどこかにある
→ リレー設定正常

プールが存在
→ DHCPサーバーサービス稼働中

すべて追加確認が必要です。

128. 除外・バインディング・競合を混同しない

除外
→ 管理者が割り当て対象外にしたアドレス

バインディング
→ サーバーがクライアントへ割り当てているアドレス対応

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

です。

同じアドレス関連情報でも意味が異なります。

129. プール・バインディング・統計を混同しない

プール
→ アドレス範囲・使用状況

バインディング
→ クライアントごとの割り当て

統計
→ DHCPメッセージカウンター

です。

確認したい情報からコマンドを逆算します。

130. クライアント側とサーバー側のリースコマンドを確実に区別する

IOSデバイス自身がクライアント
↓
show dhcp lease

IOSデバイスがサーバー
↓
show ip dhcp binding

この違いは重要です。

131. ヘルパー配置は「ブロードキャストを受ける場所」

ip helper-addressの配置を考えるときは、

DHCPサーバーはどこか

だけでなく、

クライアントブロードキャストが最初に到達するL3インターフェースはどこか

を確認します。

これがクライアント側L3インターフェースです。

132. DHCPサービス状態を最後まで忘れない

プール、バインディング、ヘルパーなどを確認しても、

no service dhcp

がある場合はDHCPサーバー・リレーサービス自体が無効です。

設定要素だけではなく、

サービス状態

も独立した確認対象です。

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

次の対応を確実にします。

インターフェースをDHCPクライアント化
→ ip address dhcp

クライアント設定
→ show running-config interface

現在アドレス
→ show ip interface brief

クライアントリース
→ show dhcp lease

クライアントメッセージ詳細
→ debug dhcp detail

リース返却
→ release dhcp

リース更新
→ renew dhcp

134. サーバー側でも対応を確実にする

アドレス除外
→ ip dhcp excluded-address

プール対象サブネット
→ network

ゲートウェイ通知
→ default-router

DNS通知
→ dns-server

プール確認
→ show ip dhcp pool

バインディング確認
→ show ip dhcp binding

競合確認
→ show ip dhcp conflict

メッセージ統計
→ show ip dhcp server statistics

135. リレー・サービス側でも対応を確実にする

リモートDHCPサーバーへのリレー
→ ip helper-address

ヘルパー配置
→ クライアントブロードキャストを受信するL3インターフェース

no service dhcp
→ サーバー・リレーサービス無効

service dhcp
→ サーバー・リレーサービス有効

まとめ

Cisco IOS・IOS XEでDHCPv4を確認するときは、

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

のどの役割を扱っているかを最初に判断します。

クライアントでは、

ip address dhcp
↓
show running-config interface
↓
show ip interface brief
↓
show dhcp lease
↓
必要ならdebug dhcp detail

を使い分けます。

サーバーでは、

ip dhcp excluded-address

ip dhcp pool
 network
 default-router
 dns-server

という設定と、

show ip dhcp pool
show ip dhcp binding
show ip dhcp conflict
show ip dhcp server statistics

という動作情報を分けます。

リレーでは、

ip helper-address

をクライアントブロードキャストを受信するL3インターフェースへ設定します。

さらに、

no service dhcp

が存在するとIOSのDHCPサーバー・リレーサービスが無効になるため、プールやヘルパーだけでなくサービス状態も確認します。

最も重要なのは、

設定
↓
動作状態
↓
適切な確認コマンド

を対応付け、

どのコマンドで
何を確認しているのか

を判断できるようにすることです。