はじめに
DHCP のスコープを設定するとき、リース時間の欄で手が止まることがあります。既定値のままでよいのか、短くすべきか、長くしてよいのか、判断の基準が分かりにくいためです。アドレスが足りなくなったときに、とりあえずリース時間を短くするという対応も見かけます。
リース時間は、アドレスの再利用、更新の頻度、障害時に使い続けられる時間、配布内容を見直したときの反映速度に同時に影響します。どれを優先するかは環境によって変わるため、一律の正解はありません。
- リース時間が切れたときに端末がどう動くか
- T1・T2 で誰に、どのように更新を要求するか
- 更新するとアドレスが変わるのか
- 短い設定と長い設定で何が変わるか、判断に使う材料
- 設定を変更したとき、既存端末にいつ反映されるか
結論として、リース時間は「アドレスを利用できる期間」であり、期限が来るたびにアドレスが変わる仕組みではありません。端末は期限の前に更新を試み、成功すれば同じアドレスのまま期間が延びます。更新に成功することと、IP アドレスが変わることは別の話です。
本記事は IPv4 の DHCP（DHCPv4）を対象とし、端末側の確認例は Windows 11 を基本にします。掲載する時刻や出力は説明用に作成したもので、実機で測定した値ではありません。構成が必要な箇所では、クライアント VLAN 10（192.168.10.0/24）と VLAN 20（192.168.20.0/24）、配布範囲 192.168.10.100〜199、DHCP サーバー 192.168.100.2 という構成を使います。
リース時間は「アドレスを利用できる期間」
リースは、サーバーが「この期間はこのアドレスを使ってよい」と貸し出す約束です。期間が終わるたびに別のアドレスへ入れ替わるものではなく、期限を迎える前に端末が更新を試みます。更新が通れば、同じアドレスのまま期限だけが先へ延びます。
更新できないまま期限を迎えた場合、端末はそのアドレスの利用を停止し、取得をやり直します。ただし、期限切れそのものがアドレスの変更を意味するわけではありません。取得し直した結果、以前と同じアドレスが割り当てられる場合もあります。アドレスが変わるのは、取得し直した際に別のアドレスが割り当てられたときです。更新のたびに、あるいは期限を迎えるたびに変わると考えると、実際の挙動と合いません。
混同しやすい 3 つの値
「リース時間」という言葉は、場面によって別のものを指します。設定を見直すときは、次の 3 つを分けて扱います。
| 値 | どこにあるか | 何を表すか |
|---|---|---|
| サーバーに設定したリース時間 | DHCP サーバーのスコープ設定 | これから配布するときに使う値 |
| 端末に通知されたリース時間 | 端末が受け取った応答の中の値 | その端末が実際に受け取った期間 |
| 現在の残り時間 | 端末が保持する期限と現在時刻の差 | あと何時間使えるか |
この区別が重要になるのは、設定を変更したときです。サーバー側の値を書き換えても、すでに配布済みの端末が保持している期間はその場では変わりません。反映のタイミングは後半で扱います。
予約と手動固定設定の扱い
- DHCP 予約による固定割り当て
-
特定の端末へ決まったアドレスを対応付ける方式です。配布は DHCP で行われるため、端末はリースを受け取り、更新のやり取りも発生します。無期限として扱えるかどうかは製品と設定によるため、予約だから DHCP が不要、あるいは必ず無期限になる、とは言えません。
- 端末側の手動固定設定
-
端末に直接アドレスを入力する方式です。IP アドレスの取得・更新に DHCP リースを使用しないため、リース時間や期限の考え方は当てはまりません。リース時間の設定を変更しても、これらの端末には影響しません。
Cisco 機器での予約の設定方法や、識別子の指定でつまずきやすい点は、『Cisco ルーター DHCP サーバー設定｜固定 IP 割り当ての落とし穴と対処』で扱っています。
T1・T2 と期限切れまでの流れ
端末は、リースを受け取った時点から 2 つのタイマーを持ちます。T1 と T2 です。それぞれの時点で端末が取る行動が変わります。
| 状態 | いつ | 端末の行動 |
|---|---|---|
| BOUND | 取得直後から T1 まで | アドレスを通常どおり利用し、タイマーを数える |
| RENEWING | T1 に到達 | 割り当て元のサーバーへユニキャストで更新を要求する |
| REBINDING | T2 に到達 | 応答できるサーバーへ向けてブロードキャストで更新を要求する |
| 期限切れ | リース期限に到達 | そのアドレスの利用を停止し、取得をやり直す |
REBINDING で送るのは、あくまで更新の要求です。新しくサーバーを探し直す段階ではない点に注意します。
T1・T2 の既定値と、固定ではない理由
参考: RFC 2131（Dynamic Host Configuration Protocol）
“T1 defaults to (0.5 * duration_of_lease). T2 defaults to (0.875 * duration_of_lease).”
（T1 の既定値はリース期間の 0.5 倍、T2 は 0.875 倍です。）
https://www.rfc-editor.org/rfc/rfc2131#section-4.4.5
ただし、この値はサーバー側から個別に指定できます。同じタイミングで多数の端末が一斉に更新しないよう、多少のばらつきを持たせることも想定されています。そのため、すべての環境で 50 パーセントと 87.5 パーセントに固定されていると考えないほうが安全です。
もう 1 点、読み違えやすいのが T2 の起点です。T2 はリース開始からの割合で決まる時点であり、T1 からの経過時間ではありません。8 時間のリースであれば、T1 は 4 時間後、T2 は 7 時間後で、T1 から T2 までは 3 時間です。
8 時間のリースで時間の流れを見る
リース時間 8 時間、既定の T1・T2 を使い、09:00 に取得した端末を例にします。この 8 時間は説明のための値で、推奨値ではありません。通信の遅延や再送を省いているため、実際の時刻はこのとおりにはなりません。
| 時刻 | 更新できない場合 | 13:00 ごろに更新できた場合 |
|---|---|---|
| 09:00 | リース開始。期限は 17:00 | 同じ |
| 13:00（T1） | 割り当て元サーバーへユニキャストで要求。応答なし | 要求に対して応答があり、新しいリースを受け取る |
| 16:00（T2） | ブロードキャストで要求。応答なし | この時点は T2 ではない。新しいリースの期間を利用中 |
| 17:00 | 期限。アドレスの利用を停止し、取得をやり直す | 期限ではない。新しい期限は 13:00 を起点に計算される |
更新に成功した場合、期限は元の 17:00 のままではありません。応答に含まれるリース時間をもとに、要求を送った時刻を起点として期限と T1・T2 が計算し直されます。13:00 に 8 時間のリースを受け取ったのであれば、期限は 21:00 ごろへ移り、次の T1 は 17:00 ごろになります。
期限まで必ず使える、とは限らない
更新できないまま期限を迎えると、端末はそのアドレスの利用を停止し、初期状態から取得をやり直します。取得し直した結果、同じアドレスに戻ることもあれば、別のアドレスになることもあります。
一方で、期限まで必ず使い続けられるわけでもありません。更新の要求に対してサーバーが拒否の応答を返した場合、端末は期限を待たずに利用を停止します。端末が別のセグメントへ移動した場合などが該当します。
サーバーが停止したときの残り時間
ここまでの流れから分かるとおり、DHCP サーバーが停止しても、有効なリースを持つ端末はすぐにアドレスを失うわけではありません。ただし、停止後に使える時間は端末ごとに異なります。09:00 に取得した端末と 16:00 に取得した端末では、同じ時刻に障害が起きても残り時間が違うためです。
「リース 8 時間なら、停止してから 8 時間はすべての端末が使える」という理解は成り立ちません。もっとも残り時間が短い端末から順に影響が出ます。また、アドレスを保持していても、経路や DNS サーバーなどが正常であることが前提です。
復旧に必要な時間を見積もるときは、リース時間そのものではなく、障害発生時点で残っている時間の最小値を基準にすると、実態に近づきます。
短い設定と長い設定で何が変わるか
リース時間の長短は、次の 4 つの観点に同時に影響します。どれか 1 つだけを見て決めると、別の面で不都合が出ます。
| 観点 | 短い設定 | 長い設定 |
|---|---|---|
| 離脱した端末のアドレスを再利用できるまで | 早い | 遅い |
| 更新要求の頻度とサーバー・ネットワークへの負荷 | 多い | 少ない |
| DHCP と通信できなくなった場合の残り利用時間 | 短い | 長い |
| 配布する設定を見直したときの反映機会 | 多く、早く行き渡る | 少なく、行き渡るまで時間がかかる |
離脱した端末のリースはすぐには消えない
1 行目の観点を理解するうえで押さえておきたいのが、端末が離脱するときの動きです。端末は、ネットワークから離れるときにアドレスの解放を通知することがありますが、必ず通知するとは限りません。電源が急に落ちた場合、ケーブルを抜いた場合、無線の圏外へ移動した場合などでは通知されません。
解放の通知がなければ、サーバーはその端末がいなくなったことを知る手段がなく、期限まではリースを保持します。このため、現在接続している台数と、サーバー上でリース中になっているアドレスの数は一致しません。使用率を見るときは、この差を前提にします。
利用環境ごとの考え方
- 社内 LAN（端末の入れ替わりが少ない）
-
同じ端末が毎日接続し、離脱もまれな環境です。アドレスを早く回収する必要が薄く、更新の頻度を抑えたい場面が多くなります。一方で、配布する DNS サーバーなどを変更する予定があるなら、反映機会の少なさが不都合になります。
- ゲストネットワーク（来訪者が多い）
-
接続する端末が入れ替わり、滞在時間も数時間程度にとどまる環境です。離脱した端末のアドレスを回収できないと、配布できるアドレスが埋まっていきます。滞在時間に対して極端に長いリースは、回収を遅らせる要因になります。
- イベント環境（短期間に多数が出入りする）
-
入れ替わりが激しく、同時接続数の見積もりも難しい環境です。回収を早める必要がある一方で、更新要求の頻度は上がります。リース時間だけで対応しようとせず、配布できるアドレス数そのものを確保できているかもあわせて確認します。
判断に使う材料
- ピーク時の同時接続数
- 端末の入れ替わりの頻度と、1 台あたりの滞在時間
- 除外設定を引いたあとに実際に配布できるアドレス数
- リースの使用率と、その推移
- DHCP が使えなくなったときに、復旧までどれだけの時間が必要か
たとえばゲスト向けで、滞在が数時間程度、配布できるアドレスが 100 個、ピークの同時接続が 60 台程度という前提であれば、滞在時間に近い数時間単位のリースから検討し、使用率を見て調整するという進め方になります。これは前提付きの検討例であり、公式の推奨値ではありません。前提が変われば適切な値も変わります。
アドレス枯渇とリース短縮を分けて考える
アドレスが足りないときにリース時間を短くする対応は、効く場合と効かない場合があります。原因が違うためです。
| 枯渇の状態 | リース短縮の効果 | 本来の対応 |
|---|---|---|
| 離脱済みの端末のリースが残り、使われていないアドレスが埋まっている | 回収が早まり、効果が期待できる | 滞在時間に見合ったリース時間へ調整する |
| 接続中の端末が更新を続けており、実際に使われている | 効果は期待できない | 配布できるアドレス数を見直す |
| ピーク時の同時接続数が、配布できる数を上回っている | 効果は期待できない | サブネットや配布範囲、セグメント分割を検討する |
接続中の端末が更新を続けている状況では、リース時間を短くしてもアドレスは戻りません。更新の要求が増えるだけで、利用中のアドレスはそのまま保持されます。
本シリーズで使っている 192.168.10.100〜192.168.10.199 の配布範囲は、追加の除外設定がなければ 100 個です。ピーク時に 100 台を超える端末が同時に接続する環境であれば、リース時間をどれだけ短くしても足りません。まず、リース中のアドレス数と、そのうち実際に通信している端末数を分けて確認します。
設定変更と反映確認の進め方
変更は、現状を確認してから、範囲を限って進めます。リース時間を設定するのは DHCP サーバーであり、リレーを担う機器ではありません。確認先を取り違えないようにします。
サーバー側で現在のリース時間の設定値と、スコープの使用率を確認します。あわせて端末側で、実際に通知されているリースの取得日時と有効期限を確認します。設定値と、端末が持っている値が一致しているとは限りません。
回収を早めたいのか、更新の頻度を下げたいのか、配布内容を早く行き渡らせたいのかを決めます。目的が決まれば、変更する対象のスコープも絞れます。全スコープへ一律に適用する必要はありません。
対象のスコープだけを変更します。変更前の値を記録しておくと、戻す判断がしやすくなります。設定方法と既定値は製品によって異なるため、対象製品の資料で確認します。Cisco 機器での指定方法は『Cisco ルーター DHCP サーバー設定｜固定 IP 割り当ての落とし穴と対処』で扱っています。
新しく取得した端末、または更新を終えた端末で、通知されたリースを確認します。変更前から接続している端末では、まだ旧条件のままのことがあります。
スコープの使用率の推移、更新が失敗していないか、利用者からの問い合わせが増えていないかを確認します。短縮した場合は更新の頻度が上がるため、サーバー側のログも見ておきます。
既存端末に反映されるタイミング
サーバーの設定値を変更しても、既存端末が保持する期限はその場では変わりません。端末が新しい条件を受け取るのは、次に更新の要求を出したときか、取得をやり直したときです。
そのため、変更してから全端末に行き渡るまでには、旧条件のリースが残る期間を見込む必要があります。旧条件が 8 時間であれば、多くの端末は次の T1 にあたる 4 時間前後で新しい条件を受け取りますが、その時点で電源が入っていない端末はさらに後になります。既存リースの扱いは製品によって異なるため、対象製品の資料で確認します。
ネットワークの構成変更を控えていて、事前にリースを短くしておきたい場合も同じです。短縮の設定を入れた時点ではなく、端末が新しい条件を受け取ったあとから効果が出ます。作業日から逆算して余裕を持たせ、実際に端末へ反映されたことを確認してから次へ進みます。
端末側での確認方法
Windows 端末では ipconfig /all で、対象アダプターのリースの取得日時と有効期限を確認できます。この 2 つの差が、その端末に通知されたリース時間です。
DHCP 有効 . . . . . . . . . . . . : はい
IPv4 アドレス . . . . . . . . . . : 192.168.10.100(優先)
リースが取得された日時 . . . . . : 2026年9月21日 9:00:00
リースの有効期限 . . . . . . . . : 2026年9月21日 17:00:00
DHCP サーバー . . . . . . . . . . : 192.168.100.2説明用に作成した抜粋です。取得日時と有効期限の差が 8 時間になっており、この端末が 8 時間のリースを受け取ったことが分かります。項目名や表示形式は、バージョンや言語環境によって異なります。
T1 と T2 の値は、この出力には表示されません。確認が必要な場合は、応答のパケットに含まれるオプションを見ます。リース時間はオプション 51、T1 はオプション 58、T2 はオプション 59 です。
参考: RFC 2132（DHCP Options and BOOTP Vendor Extensions）
“the time interval from address assignment until the client transitions to the RENEWING state”
（オプション 58 は、割り当てから RENEWING 状態へ移るまでの時間を示します。）
https://www.rfc-editor.org/rfc/rfc2132
サーバーがこれらのオプションを送っていない場合、端末は既定の割合でタイマーを計算します。値を確認したいときは、応答をキャプチャして該当のオプションを見ます。
再取得を試すときの注意
変更後の値を早く確認したい場合は、対象のアダプターを指定して再取得を実行します。目的は、新しい条件が通知されるかどうかの確認です。
参考: Microsoft Learn（ipconfig）
“Renews DHCP configuration for all adapters (if an adapter is not specified)”
（アダプターを指定しない場合、すべてのアダプターの DHCP 構成を更新します。）
https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ipconfig
解放の操作を常に先に実行する手順や、反映を早めるためにサーバー側でリースを一括削除する対応は推奨しません。通信が中断するうえ、利用中のアドレスの状態が分からなくなります。
まとめ
リース時間は、アドレスの回収、更新の頻度、障害時の残り時間、配布内容の反映速度が同時に動く設定項目です。環境によって優先したい面が変わるため、一律の推奨値を当てはめるのではなく、同時接続数や入れ替わり、配布できるアドレス数といった自環境の条件から決めることをおすすめします。
- リースは利用できる期間で、更新できれば同じアドレスを継続利用
- サーバーの設定値、端末に通知された値、残り時間は別のもの
- T1 は割り当て元へ、T2 はブロードキャストで更新を要求
- 更新に成功すると、その時点を起点に期限とタイマーを再計算
- サーバー停止後に使える時間は端末ごとに異なる
- 利用中の端末が原因の枯渇は、リース短縮では解決しない
- 設定変更は、端末が新しい条件を受け取ってから効果が出る
以上、最後までお読みいただきありがとうございました。
