DHCP で IP アドレスを取得できない｜169.254 の意味と確認手順

はじめに

「インターネットにつながらない」という問い合わせの中には、端末が IP アドレスを取得できていないケースが含まれます。ただし、同じ症状に見えても、原因は端末のアダプター設定からスイッチのポート設定、リレー、DHCP サーバーまで広い範囲に散らばります。手当たり次第に設定を変えると、状態が変わって切り分けが難しくなります。

本記事では、端末の表示と発生範囲から確認先を絞り、要求と応答がどこで止まっているかを順に確かめる手順を整理します。

最初に押さえておきたいのは、症状の切り分けです。IP アドレスを取得できないことと、取得後に通信できないことは別の問題です。前者は DHCP のやり取りが成立していない状態、後者は配布された値や経路の問題です。ここを混ぜると、調べる範囲が一気に広がります。

本記事は IPv4 の DHCP（DHCPv4）を対象とし、端末側の操作例は Windows 11、ネットワーク機器の確認例は Cisco Catalyst 9300（IOS XE）を基本にします。掲載する出力や障害の例は説明用に作成したもので、実機で検証した結果ではありません。

本記事で使う構成例

説明には、L3 スイッチ SW1 が各 VLAN のゲートウェイと DHCP リレーを担い、DHCP サーバーをサーバー VLAN へ集約した構成を使います。

DNS サーバーは 192.168.10.53 で、両方のクライアント VLAN から到達できる前提です。DHCP サーバーとクライアントが同じ VLAN にある構成では、後述するリレーの確認を飛ばして読み進めてください。

まず「取得できない」の状態を分ける

調査の入口は端末の表示です。同じ「つながらない」でも、状態によって次に照合する項目が変わります。この表は原因を確定するためのものではなく、表示から言える範囲と、次に何を照合するかを整理したものです。

169.254 で始まるアドレスが示すこと

DHCP による取得を試みた対象アダプターが期待する応答を得られなかった場合、Windows は自動構成が有効であれば、169.254.0.0/16 の範囲からアドレスを選んで使います。IPv4 リンクローカルアドレスと呼ばれる範囲で、同じリンク内の通信にだけ使えます。

参考: RFC 3927（Dynamic Configuration of IPv4 Link-Local Addresses）
“MUST NOT forward a packet with an IPv4 Link-Local source or destination address”
（ルーターは、送信元または宛先が IPv4 リンクローカルアドレスのパケットを転送しません。）
https://www.rfc-editor.org/rfc/rfc3927

このため、169.254 のアドレスが付いた端末は、ゲートウェイを越えた通信ができません。ここまでは確実に言えることです。一方で、この表示は「DHCP サーバーが故障している」ことを示すものではありません。ケーブルが抜けている、ポートの VLAN が違う、リレーが設定されていない、スコープが枯渇している、経路や ACL で遮断されているなど、どの原因でも端末の表示は同じになります。

169.254 の表示から言えるのは、「DHCP 有効」が「はい」のアダプターで DHCP による取得を試みたものの、期待するアドレスを取得できていない、というところまでです。原因の特定には使わず、次の手順で絞ります。なお、「DHCP 有効」が「いいえ」であれば、そのアダプターは IP アドレスの取得・更新に DHCP を使用していません。その場合は DHCP の取得失敗として扱わず、手動設定の内容を確認します。

イーサネット アダプター イーサネット:

   DHCP 有効 . . . . . . . . . . . . : はい
   自動構成有効. . . . . . . . . . . : はい
   自動構成 IPv4 アドレス . . . . . : 169.254.13.45(優先)
   サブネット マスク . . . . . . . . : 255.255.0.0
   デフォルト ゲートウェイ . . . . . :

説明用に作成した抜粋です。DHCP が有効なアダプターに自動構成のアドレスが付き、ゲートウェイも DHCP サーバーも表示されていない状態を示しています。この表示だけでは、どこで止まっているかは分かりません。

正常そうな表示でも、現在の状態とは限らない

逆のパターンにも注意が必要です。想定どおりの IP アドレスが表示されていても、それはすでに保持しているリースを使い続けている状態や、手動設定の可能性があります。表示だけを根拠に「DHCP サーバーは今も正常」と判断すると、原因の特定が遅れます。

判断材料になるのは、「DHCP 有効」と、リースの取得日時と有効期限、DHCP サーバーの欄です。「DHCP 有効」が「はい」でこれらが表示されていれば、その端末は DHCP で取得した設定を持っています。ただし、取得した時点で配布が成立していたことを示すだけで、現在も配布が成立している証拠にはなりません。現在の状態は、新しく接続する端末が取得できるかで確認します。

発生範囲と直前の変更から確認先を絞る

次に見るのは、どこまで影響が出ているかです。範囲が分かると、共通する要素から確認先を絞れます。

この表は、原因を確定するためのものではなく、調べる順番を決めるためのものです。範囲が複数にまたがる場合は、共通部分から確認します。

正常な端末と比較するときの前提

「隣の端末は使えている」という情報は有効ですが、比較の前提をそろえる必要があります。同じ VLAN か、同じスイッチの同じ種類のポートか、有線と無線のどちらか、といった条件が違えば、比較にならないためです。

さらに注意したいのが、既存端末の扱いです。既存端末が通信できていることは、新しい割り当てが正常である証拠にはなりません。すでに有効なリースを持つ端末は、DHCP サーバーとやり取りできない状態でも、期限まではそのアドレスを使い続けられるためです。判断は、新規接続やリースを持たない端末の結果で行います。

範囲から確認先を絞る例

例 1: VLAN 20 の端末だけ取得できない

VLAN 10 の端末は取得できているため、サーバー本体とサーバーまでの経路は共通して動作していると考えられます。確認先は Vlan20 の SVI の状態とリレー設定、VLAN 20 向けスコープの有無と空き、VLAN 20 からサーバーへの経路に絞れます。

例 2: 1 台だけ 169.254 のアドレスになる

同じ島の別端末が正常であれば、VLAN 全体やサーバーの問題である可能性は下がります。接続ポートの VLAN 所属とリンク状態、端末側のアダプター設定、ケーブルや変換アダプターといった端末固有の条件から確認します。

端末側から順に確認する

確認は端末から始め、経路をたどってサーバーへ進みます。重要なのは、設定変更や再取得の操作を行う前に、現在の状態を記録しておくことです。

ipconfig /all

出力はすべて残しておきます。操作の後では、元の状態が分からなくなり、引き継ぎの際にも説明できなくなります。

対象アダプターを取り違えない

ipconfig /all の出力には、VPN の仮想アダプター、仮想マシン用のアダプター、使用していない無線アダプターなども並びます。調査対象は、実際に接続しているアダプターです。未接続のアダプターには「メディアは接続されていません」と表示されるため、まず対象を特定してから各項目を読みます。

表の右列は原因を示すものではなく、次に照合する項目です。想定と違う値があれば、手動設定の有無、接続先 VLAN、応答した DHCP サーバー、そのスコープの配布値の順に照合します。

確認の順序

リレーの設定先については、公式ガイドでも設定位置が示されています。

参考: Cisco IP Addressing Services Configuration Guide, IOS XE 17.15.x（Catalyst 9300）
“configured on the SVI of the DHCP client”
（DHCP クライアント側の SVI に設定されている必要があります。）
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9300/software/release/17-15/configuration_guide/ip/b_1715_ip_9300_cg/configuring_dhcp.html

! 接続ポートの状態と VLAN 所属
SW1# show interfaces status
SW1# show vlan brief

! 対象 SVI の状態とリレー先の設定
SW1# show ip interface brief
SW1# show ip interface Vlan20 | include Helper

! サーバーへの到達性（クライアント側 SVI を送信元にする）
SW1# ping 192.168.100.2 source Vlan20

端末側の操作で注意すること

再取得の操作は、記録を取った後に、目的と対象を決めてから実行します。

ipconfig /renew

DHCP の構成を再取得します。対象アダプターを指定して実行すると、他のアダプターに影響しません。有効なリースを持つ端末では更新のやり取りになり、リースを持たない端末では初回取得と同じ流れになります。結果として観測されるメッセージが変わる点に注意します。

ipconfig /release

現在のアドレス設定を破棄する操作です。実行すると通信が中断するため、リモート接続で作業している場合は接続が切れる可能性があります。最初の共通手順にはせず、意図しないサーバーから受け取った設定を取り直す場合など、目的がはっきりしている場面に限って使います。

参考: Microsoft Learn（ipconfig）
“Sends a DHCPRELEASE message to the DHCP server to release the current DHCP configuration”
（DHCPRELEASE を送信し、現在の DHCP 構成を解放します。）
https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ipconfig

ipconfig /flushdns は DNS のキャッシュを消す操作で、IP アドレスの取得失敗を解消するものではありません。名前解決の問題を扱うときに使い分けます。

要求と応答がどこで止まっているか確認する

設定の確認で原因が絞れない場合は、実際の通信を観測します。ここで重要なのは、どこで取得したキャプチャなのかを意識することです。

観測の前提をそろえる

• クライアント側は対象ポートのミラー、サーバー側はサーバーの受信インターフェースで取得する
• 端末が要求を送る前からキャプチャを開始し、取得を試みた時刻を記録する
• 複数端末の通信が混在する場合は、トランザクション ID とクライアントのハードウェアアドレスで対応付ける

# キャプチャフィルター（BPF）
udp port 67 or udp port 68

# 表示フィルター（Wireshark 3.0 以降のプロトコル名）
dhcp

クライアントからの要求は DHCP サーバー用のポート（67）宛て、クライアントへの応答は DHCP クライアント用のポート（68）宛てです。リレーとサーバーの間はどちらもサーバー用のポートを使うため、UDP 68 だけで絞り込むと、その区間の通信が取得できません。表示フィルターの名称は Wireshark 3.0 で bootp から dhcp へ変更されています。

観測結果と次に調べること

この表で最も間違えやすいのが 1 行目と 4 行目の区別です。クライアント側で応答が見えないことは、サーバーが応答していない証拠にはなりません。サーバー側でも観測して初めて、どの区間で止まっているかを判断できます。

もう 1 点、観測されるメッセージの数にも注意します。すでにアドレスを保持している端末の再取得や更新では、探索のメッセージから始まらない場合があります。4 つのメッセージがすべて見えないことを、そのまま異常と判断しないでください。初回取得と更新で流れが異なる理由は、RFC 2131 に規定されています。

原因に応じた対処と復旧確認

対処は、確認できた結果と対応付けて実施します。確認していない箇所へ先回りして手を入れないことが、復旧を早める近道です。

サーバー側のプール作成、除外設定、固定割り当ての具体的な手順は、『Cisco ルーター DHCP サーバー設定｜固定 IP 割り当ての落とし穴と対処』で扱っています。

共通の対処として行わないこと

原因を特定する前に、リースの一括削除やサーバーの再起動を行う対応は推奨しません。影響範囲が広がるうえ、状態が変わって切り分けの材料が失われます。ファイアウォールの全面無効化や、空いていそうなアドレスを手動設定して回る対応も同様です。

また、ping の結果だけで判断しないようにします。ping が通っても DHCP が正常とは限らず、通らないことが DHCP の障害を示すとも限りません。

導入済み環境で追加確認する項目

DHCP Snooping を導入している環境では、信頼するポートの設定によってメッセージが破棄される場合があります。リレーが付与する Option 82 の扱いや、サーバー側でハードウェアアドレスを条件にした割り当てポリシーを使っている場合も、確認対象に加えます。

サーバーの払い出し記録と、リレー装置や DHCP Snooping が持つ情報は別のものです。どちらを見ているかを区別しないと、割り当ての有無を誤って判断することがあります。

復旧の確認

対処後は、次の 4 点を分けて確認します。まとめて「つながった」で終わらせないことが、再発時の調査を楽にします。

• 対象端末が DHCP でアドレスを取得できた（リースの取得日時が更新されている）
• 配布された IP アドレス、サブネットマスク、ゲートウェイ、DNS サーバーが設計どおり
• 業務で必要な通信と、名前解決ができる
• 当初の発生範囲に応じて、ほかの対象端末でも改善している

引き継ぐときに渡す情報

その場で解決しない場合は、次の内容をまとめて引き継ぎます。何を確認済みかが分かると、同じ確認の繰り返しを避けられます。

• 発生時刻と、いつから発生しているか
• 対象端末のホスト名、ハードウェアアドレス、接続ポート、VLAN
• 影響範囲（1 台、同一 VLAN、複数 VLAN のいずれか）
• 操作前に取得した ipconfig /all の記録
• リレーとサーバーで確認した項目と、その結果
• 要求と応答をどこまで確認できたか、どの地点で観測したか
• 直前の変更内容と実施者、実施した操作と時刻

まとめ

IP アドレスを取得できない問題は、端末の表示で状態を分け、発生範囲で確認先を絞り、要求と応答をどこで観測したかを押さえれば、調べる範囲を段階的に狭められます。表示や ping の結果だけで原因を断定せず、確認できた事実と対処を対応付けることが、復旧と引き継ぎの両方に効きます。

• 取得できない問題と、取得後の通信の問題を分けて扱う
• 169.254 のアドレスは未取得を示すが、原因までは示さない
• 既存端末が使えていても、新規の割り当てが正常とは限らない
• 発生範囲から、端末・VLAN・サーバーのどこを見るかを決める
• 操作の前に ipconfig /all で現在の状態を記録
• 観測地点を分けないと、どの区間で止まっているか判断できない
• 原因を特定する前の一括操作は、切り分けの材料を失わせる

以上、最後までお読みいただきありがとうございました。