CCNA-038 · 理解確認
理解確認：DHCPv4 Troubleshooting
単一選択 10 / 複数選択 6 · 16問
DHCPv4 ClientがAddressを取得できない。原因を一度に決め付けず、最初に進めるTroubleshootingの順序として最も適切なものはどれか。
B. Topology / Role → Client設定 → showによる現在状態 → Message / Relay / Serverを段階確認
C. Poolを再作成 → Helperを移動 → Clientを再起動
D. DNS Option → Lease Time → Hostnameの順に変更
答えと解説
答え：B
Page038では、Topologyと役割を確認し、Client設定とshowによる現在状態から範囲を絞り、Message / Relay / Serverへ進みます。最初から設定変更や最大範囲Debugを行いません。
IOS ClientにAddressがなく、DHCP取得要件がある。Client側でDISCOVERも確認できない。最初に確認する内容として適切なものを2つ選択してください。
B. ServerのBindingを全削除する
C. ClientからDHCPDISCOVERが送信されているか
D. OFFERがないのでPool Exhaustionと確定する
答えと解説
答え：A / C
Client DHCP設定と、最初のDHCP MessageであるDISCOVERの有無を確認します。Client側の開始条件が未確認の段階でServer側変更やPool Exhaustion確定へ進みません。
Client VLAN 20とDHCP Serverが別Subnetで、ClientからDISCOVERは送信されている。Vlan20には`ip helper-address`がない。最も直接的な原因候補と修正の組み合わせはどれか。
B. Client DHCP設定不足 → ServerのConflictを削除する
C. Server Identifier不一致 → Lease Timeを変更する
D. Relay設定不足 → Client Broadcastを受信するVlan20へ正しい`ip helper-address`を設定する
答えと解説
答え：D
L3境界を越える構成ではRelayを確認し、HelperはDHCP Serverに近いInterfaceではなくClient Broadcastを受信するL3 Interfaceへ設定します。
別SubnetのClient向けRelay構成で、期待するDHCP転送を妨げるConfiguration上の問題を2つ選択してください。
B. `ip helper-address`が実際のDHCP Serverとは異なるAddressを向いている
C. PoolにDNS Optionが設定されていない
D. Global Configurationに`no service dhcp`がある
答えと解説
答え：B / D
Helper宛先不一致は正しいServerへ転送できず、`no service dhcp`はDHCP Server / Relay Serviceを無効化します。DescriptionやDNS OptionはRelay転送そのものの条件ではありません。
DHCP ServerがRelay経由のDISCOVERを受信し、`giaddr = 10.40.50.1`を確認した。Serverが対応Poolを照合するときの判断として最も適切なものはどれか。
B. Client MAC Addressの先頭Byteだけを見る
C. `giaddr`が属するClient側Subnetに対応するPoolを照合する
D. DNS Server Optionが一致するPoolを選ぶ
答えと解説
答え：C
標準的なRelay構成ではgiaddrがClient側Subnetを示す重要なEvidenceになり、ServerはそのSubnetに対応するPoolを照合します。
ClientでDISCOVER送信を確認し、Relay側でもServer向け転送まで確認できた。しかしServer側のMessage Counter / Packet確認情報ではDISCOVER受信が確認できない。次に優先する範囲はどれか。
B. ACK後のBindingだけ
C. ClientのDNS Optionだけ
D. PoolのLease Timeだけ
答えと解説
答え：A
ClientとRelayまでは正常なEvidenceがありますが、Server受信が最初の未確認地点です。Pool処理より前にRelay→ServerのPathとServer受信を確認します。
ServerがDISCOVERを受信した後、Addressを提案できない原因候補として本文から直接確認すべきPool関連の状態を3つ選択してください。
B. Client / `giaddr`のSubnetとPoolの`network`が一致していない
C. `show ip dhcp pool`で利用可能Addressが0
D. DNS Optionが未設定
E. Excluded Rangeが動的割り当て候補を実質的に使い切っている
答えと解説
答え：B / C / E
Pool選択後は`network`不一致、利用可能Address数、Excluded Rangeを確認します。これらは正しいPool選択やOffer生成可否へ直接関係します。
ServerはDISCOVERを受信し、正しいPoolが選択され、利用可能Addressも残っている。それでもOFFERが生成されないところまでshow / Configurationで絞れた。次の詳細確認として最も適切なものはどれか。
B. 全Bindingを無条件に削除する
C. Helperを別Interfaceへ移動する
D. 必要な範囲でServer側DHCP Packet / Event Debugを使う
答えと解説
答え：D
showとConfigurationでServer内部のOFFER生成段階まで絞った後は、必要な範囲でServer側Debugを使います。Debugは最初から最大範囲で使いません。
複数DHCP Server環境で、Server AはOFFERを送信したがServer Aではその後のREQUESTが見えない。一方ClientはAddressを取得している。状況を説明するため次に確認するものを2つ選択してください。
B. Server AのPool名を変更する
C. ClientのDNS Cacheを削除する
D. DHCPREQUESTのServer IdentifierがどのServerを示すか
答えと解説
答え：A / D
複数Server環境では他ServerのOFFERと、Clientが選択したServerを示すREQUESTのServer Identifierを確認します。Server AでREQUESTがないだけでは異常確定ではありません。
ServerがClientのDHCPREQUESTを受信した後、DHCPNAKを返した。最も適切な解釈はどれか。
B. Serverは要求を受信したが、そのAddress要求をそのまま受け入れられないと判断した
C. Clientは必ず別ServerのOFFERを選択した
D. Relayが必ず停止している
答えと解説
答え：B
NAKはServer無応答ではありません。REQUESTを受信した上で要求を受け入れられないというMessage Evidenceです。
Server側のAddress状態を読むときのEvidence解釈として正しいものを2つ選択してください。
B. `show ip dhcp binding`のEntryはServerがそのClient向けBindingを保持していることを示す
C. `show ip dhcp conflict`のEntryだけでPool `network`不一致を確定できる
D. `show ip dhcp conflict`のEntryはそのAddressを競合確認対象として扱う根拠になる
答えと解説
答え：B / D
BindingとConflictは別のEvidenceです。BindingはServerが保持する割当状態、Conflictは競合確認対象を示しますが、それぞれ単独でEnd-to-End成功や別原因まで断定しません。
Server側でDHCPOFFERの送信を確認した。このEvidenceだけから直接言える範囲として最も適切なものはどれか。
B. ClientのDefault Gatewayまで正常である
C. ServerがOFFER生成・送信段階まで進んだ
D. ACKまで完了しClientにAddressが設定された
答えと解説
答え：C
OFFER送信はServerがその段階まで進んだEvidenceです。Client受信、REQUEST、ACK、最終Address取得まで単独では証明しません。
DISCOVER受信、正しいPool選択、OFFER送信までは確認できたが、ClientからREQUESTが確認できない。最初に失敗している段階として優先すべき範囲はどれか。
B. Clientの`ip address dhcp`設定より前
C. ServerがDISCOVERを受信するより前
D. ACK後のBinding保持だけ
答えと解説
答え：A
最後に成功した地点がOFFER送信で、最初に期待結果が得られないのがREQUESTです。したがってOffer受信・選択・REQUEST生成へ範囲を絞ります。
確認済みRoot Causeと、それに直接対応する最小修正の組み合わせとして正しいものを3つ選択してください。
B. Helper宛先誤り → Serverの全Bindingを削除
C. `no service dhcp` → `service dhcp`
D. Pool `network`不一致 → ClientのDNS設定を変更
E. Pool `network`不一致 → Client Subnetに対応する`network`へ修正
F. Pool Exhaustion → 原因を確認せず常に全Bindingを削除
答えと解説
答え：A / C / E
修正は確認したRoot Causeへ直接対応させます。無関係なDNS変更や、原因を見ずに全Binding削除する方法は採りません。
設定修正後、DHCP由来Leaseを保持しているIOS Clientで既存Leaseを返却し、新しいDHCP Cycleを明示的に再試行して結果まで確認したい。最も適切な流れはどれか。
B. `ip address dhcp`を削除してServer Poolを再作成する
C. `release dhcp`後にClient設定そのものも消えたと判断する
D. `release dhcp <interface>` → `renew dhcp <interface>` → Message Flow・Client Address / Lease・Server Bindingを確認する
答えと解説
答え：D
releaseはLeaseを返却しますが`ip address dhcp`設定自体を削除しません。再試行後はMessage Flow、Client Address / Lease、Server Bindingなどで修正結果を確認します。
修正前は対象PoolのAvailable=0でOFFERなしだった。枯渇原因を適切に解消した後、Availableが1以上となり、次のDISCOVERへOFFERが送信された。この変化が最も強く支持するものはどれか。
B. Pool Exhaustionが問題に寄与していた
C. Helper宛先誤りが必ず残っている
D. Server Identifier不一致だけが原因だった
答えと解説
答え：B
修正前後でAvailableとOFFERが回復したことは、Pool Exhaustionが問題へ寄与していたことを強く支持する修正後Evidenceです。