網路線插好了、網卡燈也亮著，Windows 卻顯示：
無法辨識的網路
打開命令提示字元，執行：
ipconfig
接著看到一個有點陌生的位址：
169.254.87.21
這不是公司最近偷偷新增的網段，也不是 DHCP Server 想給你一點驚喜。
它叫做 APIPA。
簡單來說，就是 Client 找不到 DHCP Server，只好先替自己安排一個臨時 IP。多少有點像到餐廳等不到帶位，最後自己找了一張空桌坐下。
問題是，其他設備通常不知道你坐在哪裡。
上一篇提到，網卡與 Switch Port 出現 Link，代表 Layer 1 基本連線已建立。
但這只能證明：
它不能證明 Client 已經取得：
因此，網路線插好後想正常通訊， Client 通常還要先從 DHCP 取得一套能使用的網路設定。
DHCP 全名是：
Dynamic Host Configuration Protocol
它可以自動提供 Client 所需的網路資訊，例如：
如果沒有 DHCP，每台電腦都要手動設定 IP。
公司有幾百、幾千台裝置時，光是避免 IP 重複，大概就足以讓我們每天都很想直接躺平。
DHCP 的價值不只是「自動給 IP」，而是集中管理網路設定。
當 DNS 或 Gateway 需要更換時，可以透過 DHCP Option 統一調整，而不是逐台電腦遠端進去改到天荒地老。
Client 取得 IP 的過程，常用 DORA 記憶：
這四個階段分別在做什麼？
Client 剛連上網路時，通常還沒有可用 IP，也不知道 DHCP Server 在哪裡。
因此會發送 DHCP Discover：
這個網路上有 DHCP Server 嗎？我需要一組設定。
因為 Client 不知道 Server 位址，所以這個封包通常使用廣播。
常見資訊如下：
Source IP：0.0.0.0
Destination IP：255.255.255.255
Source Port：UDP 68
Destination Port：UDP 67
封包裡會帶有 Client 的 MAC Address、Transaction ID 及其他參數，讓 Server 知道是誰提出要求。
DHCP Server 收到 Discover 後，會從可用的 Address Pool 中挑選一個 IP，送出 Offer。
Offer 可能包含：
意思大概是：
我可以提供你
10.10.20.35/24，Gateway 是10.10.20.1，要不要？
若網路中存在多台 DHCP Server，Client 可能收到多個 Offer。
這也是 Rogue DHCP 危險的地方——只要它回得夠快，Client 可能就拿走了錯誤設定。
Client 選擇其中一個 Offer 後，會發出 DHCP Request，表示：
我想使用這組 IP，而且我選擇的是這台 DHCP Server。
Request 通常也會以廣播方式送出，讓其他提供 Offer 的 Server 知道 Client 沒有選擇它們，可以把位址保留給別人。
被選中的 DHCP Server 收到 Request 後，會回覆 DHCP ACK。
它代表：
這組租約正式給你，請開始使用。
Client 收到 ACK 後，便會套用：
至此，基本的 DHCP 取得流程完成。
除了 ACK，DHCP Server 也可能回覆 NAK，也就是 Negative Acknowledgement。
常見情況包括：
收到 NAK 後，Client 通常會放棄原本設定，重新開始 Discover 流程。
因此，如果使用者剛從另一個網路移動過來，短暫重新取得 IP 並不一定代表故障，也可能只是 DHCP 在修正舊租約。
在 Windows 等系統中，如果 Client 無法從 DHCP 取得設定，可能會使用 APIPA：
169.254.0.0/16
實際常見範圍為：
169.254.1.0 ～ 169.254.254.255
Client 會挑選一個位址，並確認是否衝突。
這能讓同一個 Layer 2 網段中的 APIPA 裝置進行有限通訊，但通常沒有：
所以看到 169.254.x.x 時，可以先理解成：
實體連線可能存在，但 DHCP 流程沒有成功完成。
不過也不要看到 APIPA 就直接宣布 DHCP Server 故障。
它只是一個症狀，原因可能發生在 Client、Switch、VLAN、Relay、Server，甚至是無線認證流程。
Windows 可以執行：
ipconfig /all
不要只看 IP Address，還要注意：
例如正常設定可能是：
DHCP Enabled：Yes
IPv4 Address：10.10.20.35
Subnet Mask：255.255.255.0
Default Gateway：10.10.20.1
DHCP Server：10.10.10.20
DNS Servers：10.10.10.53
異常 Client 則可能顯示：
DHCP Enabled：Yes
Autoconfiguration IPv4 Address：169.254.87.21
Subnet Mask：255.255.0.0
Default Gateway：
DHCP Server：
這時可以確定 Client 沒拿到有效租約，但還不知道 Discover 消失在哪裡。
Windows 常用：
ipconfig /release
ipconfig /renew
/release 會釋放目前 DHCP 租約，/renew 則重新要求設定。
這組指令適合：
但如果：
那麼一直執行 Renew 並不會突然召喚出 Offer。
它只能重新測試 DHCP 流程，不能取代根因分析。
看到 Client 拿不到 IP 時，第一個重要問題是：
只有這一台，還是其他設備也一樣？
不同影響範圍，代表不同的調查方向。
優先檢查：
可以找一台正常設備接上同一條線：
也可以讓原 Client 接到已知正常的網路：
這就是對照測試的價值。
優先檢查：
若這些座位原本位於同一 VLAN，又同時拿不到 IP，很可能共享某個故障節點。
此時逐台重裝 Driver，只會讓場面看起來很忙。
可能原因包括：
如果其他 VLAN 可以正常取得 IP，代表 DHCP Server 本身未必全面故障。
這時應比較正常與異常 VLAN：
優先檢查：
但仍要確認 Client 是真的拿不到 IP，而不是 DNS 或 Internet 故障。
使用者說「大家都沒網路」，不代表所有人都在 DHCP 階段失敗。
先看實際設定，別讓一句口語描述把整間機房都判成有罪。
DHCP Discover 是廣播。
Router 預設不會把 Layer 2 Broadcast 轉送到其他網段。
假設：
Client VLAN：10.10.20.0/24
DHCP Server：10.10.10.20
Client 和 DHCP Server 不在同一 VLAN。
如果沒有額外機制，Discover 到達 VLAN 20 的 Gateway 後就會停止，DHCP Server 永遠聽不到。
這時需要 DHCP Relay。
Cisco 環境常在 Client VLAN 的 Layer 3 Interface 設定：
ip helper-address 10.10.10.20
Relay 會將 Client 的 DHCP Broadcast 轉成可以跨網段傳送的封包，再送到 DHCP Server。
它也會提供來源網段資訊，讓 Server 知道應該從哪一個 Scope 分配 IP。
Relay 通常設定在最接近 Client、負責該 VLAN Routing 的 Layer 3 Interface。
例如：
interface Vlan20
ip address 10.10.20.1 255.255.255.0
ip helper-address 10.10.10.20
如果 Relay：
Client 就可能拿不到 IP。
排錯時可比較正常 VLAN 與異常 VLAN 的 Gateway 設定。
若 VLAN 10 正常、VLAN 20 異常，而兩者唯一明顯差異是 VLAN 20 缺少 Helper Address，那方向就很清楚了。
DHCP Scope 定義一個網段可以分配的位址與 Option。
例如 VLAN 20 的 Scope：
Network：10.10.20.0/24
Range：10.10.20.50 ～ 10.10.20.200
Gateway：10.10.20.1
DNS：10.10.10.53
Lease：8 Hours
其中可能排除：
如果 Scope 不存在或沒有啟用，Server 即使收到 Discover，也不知道該提供哪個網段的 IP。
如果可分配範圍裡的 IP 全部被租出去，新 Client 就無法取得位址。
常見原因包括：
例如 Scope 只有：
10.10.20.100 ～ 10.10.20.150
總共約五十個位址，但辦公區現在已有八十台裝置。
這不是 Client 多按幾次 Renew 就能解決的問題。地址池裡沒有位址，DHCP Server 也不能憑空變出第 51 個。
短期可以：
長期可能需要：
但不要看到 Scope 快滿，就直接刪除所有 Lease。
正在使用的 Client 可能仍持有那些 IP，貿然清除或重新分配，可能造成 IP Conflict。
先理解租約狀態，再進行變更。
DHCP 分配的 IP 通常不是永久屬於 Client，而是在一段時間內租用。
Client 會在租約期間嘗試續租。
常見流程概念：
Lease 太長：
Lease 太短：
辦公室固定設備與訪客 Wi-Fi 的需求不同，不一定應使用相同 Lease。
Rogue DHCP 是未經授權的 DHCP Server。
企業現場常見情境是：
有人把家用無線路由器接進公司網路，而且使用的是 LAN Port。
這台路由器非常熱心，開始對公司 Client 發放：
結果使用者可能拿到：
IP：192.168.1.100
Gateway：192.168.1.1
DNS：192.168.1.1
但公司正確設定應為：
IP：10.10.20.x
Gateway：10.10.20.1
DNS：10.10.10.53
此時 Client 並不是「拿不到 IP」，而是拿到了不該拿的 IP。
症狀可能時好時壞，因為正常 DHCP 和 Rogue DHCP 都在回應，Client 有時選到公司 Server，有時選到家用設備。
可以觀察：
如果 Client 拿到陌生 DHCP Server，可進一步：
交換器也可使用 DHCP Snooping，將 Port 分為：
通常只有連向正式 DHCP Server 或上游的介面設為 Trusted，使用者端 Port 不允許送出 DHCP Offer。
如此可以降低 Rogue DHCP 影響。
但 DHCP Snooping 設定錯誤，也可能把合法 Server 的回覆一起擋掉。安全功能很有用，前提是別順便把自己鎖在門外。
Client 拿不到 DHCP 時，有人會先手動填一組 IP。
如果填寫正確，它可能立即恢復連線。
這可以作為診斷或緊急 Workaround，但不能直接代表問題解決。
因為真正的原因仍可能是：
手動 IP 只是繞過 DHCP。
而且若隨意選擇位址，可能和其他設備衝突。
使用靜態設定前，至少要確認：
不然今天修好一台 Client，明天可能多出兩台 IP Conflict。
取得 IP 並不代表 DHCP 一切正常。
還要確認：
例如 Client 位於 VLAN 20，卻拿到 VLAN 30 的 IP，可能代表：
有時候「拿到錯的 IP」比完全拿不到更難查，因為畫面上看起來什麼都有。
若有權限與合適工具，可以使用封包擷取觀察 DHCP 流程。
可能出現以下情況。
代表 Client 正在尋找 DHCP，但沒有收到回覆。
可能原因：
可能原因：
可能原因：
可能表示 Client 想使用的位址已不適用目前網段，需要重新開始 DORA。
把 DHCP 拆成四個可觀察階段後，就不必把所有問題都叫作「DHCP 掛了」。
使用者回報：
員工 Wi-Fi 可以連線，但一直顯示沒有 Internet。
初步確認：
169.254.x.x
根據影響範圍，可以先推論：
正常流量應為：
Client
→ SSID-STAFF
→ AP
→ VLAN 120
→ Switch Trunk
→ VLAN 120 Gateway
→ DHCP Relay
→ DHCP Server
檢查後發現，AP 所接 Switch Port 的 Trunk Allowed VLAN 中沒有 VLAN 120。
因此：
將 VLAN 120 加入經核准的 Trunk 後，Client 成功取得 IP。
問題表面上是 DHCP，真正的失敗點卻在 Layer 2。
這也再次證明，網路故障不會因為文章主題是 DHCP，就乖乖只發生在 DHCP Server。
遇到 Client 無法取得 IP，可以依照以下流程。
執行：
ipconfig /all
確認：
看到 169.254.x.x 時，可以先判斷 Client 沒有成功取得 DHCP 租約。
但真正原因可能位於：
排錯時，先確認影響範圍，再沿著這條路徑調查：
Client
→ Access Port／AP
→ VLAN
→ Trunk
→ Gateway／Relay
→ DHCP Server
→ 回程
DORA 不只是考試要背的四個單字，它也能幫助我們判斷 DHCP 流程究竟停在哪一段。
iThome鐵人賽
看影片追技術