この記事は、 「ネットワーク中級編｜構築・検証・障害切り分けを身につける」 の第21回です。
初級編で学んだDHCPと、中級編で学んだVLAN・Inter-VLAN Routing・ルーティングの知識を使い、 異なるサブネットにいるDHCPクライアントとサーバーを接続する仕組みを理解します。
DHCPリレーとは？異なるサブネットへDHCPを中継する仕組み・設定・切り分けを図解
DHCPクライアントが最初に送信するDHCP Discoverはブロードキャストです。 そのままではルーターを越えられません。DHCPリレーは、クライアント側で受信したDHCPメッセージを DHCPサーバーへ中継し、複数のVLANへ一台または少数のDHCPサーバーからIPアドレスを配布できるようにします。
小規模なネットワークでは、DHCPサーバーとクライアントが同じLANにいる場合があります。 しかし、企業ネットワークでは営業部、技術部、サーバー用など、複数のVLANに分割するのが一般的です。
すべてのVLANへDHCPサーバーを置く必要はありません。 各VLANのデフォルトゲートウェイでDHCPリレーを動作させれば、中央のDHCPサーバーからアドレスを配布できます。
この記事を読み終えるとできること
- DHCPリレーが必要になる理由を説明できる
- DORAの各メッセージがどのように中継されるか説明できる
giaddrを基にDHCPサーバーが配布スコープを選ぶ仕組みを説明できる- Cisco IOSの
ip helper-addressを設定できる - ルーティング・ACL・スコープを順番に確認できる
- パケットキャプチャーから中継箇所を特定できる
DHCPリレーとは何か
DHCPリレーとは、クライアント側サブネットで受信したDHCPメッセージを、 別サブネットにあるDHCPサーバーへ中継する機能です。
DHCPリレーは、ルーターやレイヤー3スイッチ、ファイアウォールなど、 クライアント側ネットワークのレイヤー3ゲートウェイで動作することが一般的です。
Cisco IOS系機器では、クライアント側インターフェースへ
ip helper-address <DHCPサーバーのIPアドレス>を設定する方法が代表的です。
DHCPリレー自身がIPアドレスを払い出すわけではありません。
IPアドレス、サブネットマスク、デフォルトゲートウェイ、DNSサーバーなどの配布内容を決めるのはDHCPサーバーです。 DHCPリレーは、クライアントとサーバーの間でメッセージを運びます。
| 装置・役割 | 主な処理 | 設定する内容 |
|---|---|---|
| DHCPクライアント | アドレスの取得を要求する | 自動取得を有効にする |
| DHCPリレー | クライアントとサーバーのメッセージを中継する | DHCPサーバーの宛先IPアドレス |
| DHCPサーバー | 配布するアドレスとオプションを決定する | サブネットごとのスコープ・プール |
なぜDHCPリレーが必要なのか
DHCPクライアントは、起動直後には自分のIPアドレスもDHCPサーバーのIPアドレスも分かりません。 そのため、最初のDHCP Discoverをブロードキャストで送信します。
ブロードキャストは、基本的に同じブロードキャストドメイン内へ届きます。 ルーターは、受信したレイヤー2ブロードキャストを別のサブネットへそのまま転送しません。
DHCPリレーがない場合
DHCP Discoverを送信
192.168.100.10
DHCPサーバーを各VLANへ置く方法もある
VLANごとにDHCPサーバーを配置すれば、ブロードキャストの範囲内で直接応答できます。 しかし、VLAN数が増えるほどサーバー台数、設定、バックアップ、監視、障害対応の負担が増えます。
| 方式 | メリット | 注意点 |
|---|---|---|
| 各VLANにDHCPサーバーを置く | 同一サブネット内で完結し、構成が直感的 | サーバーと運用対象が増える |
| DHCPリレーで中央サーバーへ集約する | スコープ、ログ、バックアップを集中管理しやすい | リレー、ルーティング、ACLを含む経路全体が必要 |
まず全体を1枚の図で理解する
DHCPリレーを使う基本構成
IPアドレス未取得
helper：192.168.100.10
192.168.100.10
- PC-AがDHCP Discoverをブロードキャストする PC-AはIPアドレスを持っていないため、VLAN 10内へDiscoverを送ります。
- Vlan10のゲートウェイがDiscoverを受信する Vlan10へDHCPリレー設定があるため、L3スイッチはメッセージを処理します。
- DHCPサーバーへ中継する リレーは、どのクライアント側ネットワークから受信したかを示す情報を付加し、192.168.100.10へ送ります。
- サーバーがVLAN 10用スコープを選ぶ DHCPサーバーはリレー情報を見て、192.168.10.0/24用のプールから候補アドレスを選びます。
- DHCPリレーがクライアントへ応答を届ける サーバーから返されたOfferやACKを、VLAN 10内のクライアントへ転送します。
DHCPリレーを理解するポイントは「ブロードキャストをそのままルーティングする機能ではない」ことです。
リレーは、受信したDHCPメッセージを処理し、DHCPサーバーが到達可能な形式で改めて中継します。
DHCPリレーを使ったDORAの流れ
DHCPの基本的なアドレス取得は、Discover、Offer、Request、ACKの4段階です。 頭文字を取ってDORAと呼びます。DHCPリレーがある場合でも、クライアントから見た基本の順番は変わりません。
Discover
クライアントが利用可能なDHCPサーバーを探します。
Offer
DHCPサーバーが候補のIPアドレスを提示します。
Request
クライアントが利用したい提示内容を要求します。
ACK
DHCPサーバーがリースを確定し、設定情報を通知します。
Discoverの中継
Discoverを受信したリレーは、クライアントが存在するネットワークをサーバーへ伝えます。 サーバーはその情報を使って、どのスコープからアドレスを配布するか判断します。
Offerの中継
サーバーは、候補のIPアドレス、サブネットマスク、デフォルトゲートウェイ、DNSサーバー、リース時間などをOfferへ含めます。 リレーは、サーバーから受け取った応答をクライアント側へ届けます。
RequestとACK
クライアントは選択したOfferに対してRequestを送り、DHCPサーバーはACKでリースを確定します。 RequestとACKも、DiscoverとOfferと同様にDHCPリレーを経由します。
| 段階 | クライアント側セグメント | リレー・サーバー間 | 主な確認内容 |
|---|---|---|---|
| Discover | 主にブロードキャスト | リレーからサーバーへ中継 | クライアント要求がリレーへ届くか |
| Offer | リレーからクライアントへ転送 | サーバーからリレーへ応答 | 正しいスコープから候補が返るか |
| Request | クライアントが選択内容を通知 | リレーからサーバーへ中継 | 選択したサーバーとアドレス |
| ACK | リレーからクライアントへ転送 | サーバーからリレーへ確定通知 | リース、GW、DNSなどの内容 |
クライアント側でブロードキャストになるかユニキャストになるかは、クライアントの状態、 DHCPメッセージ内のフラグ、実装などによって変わる場合があります。 障害調査では「必ずすべてブロードキャスト」と決めつけず、実際のパケットを確認します。
giaddrの役割とスコープ選択
DHCPリレーの重要な情報が、BOOTP/DHCPヘッダーにある giaddr（Gateway IP Address）です。
DHCPサーバーへ「この要求は、どのクライアント側サブネットから中継されたか」を伝えるためのアドレスです。
例として、Vlan10のゲートウェイが192.168.10.1であり、そこでDHCP Discoverを受信したとします。 DHCPリレーは、サーバーへ中継するメッセージのgiaddrへ192.168.10.1を設定します。
giaddrを使ったスコープ選択
giaddr：192.168.10.1
スコープを検索
GW：192.168.10.1
サーバーに対応スコープがない場合
giaddrが192.168.10.1であっても、DHCPサーバー側に192.168.10.0/24用のスコープがなければ、 サーバーは適切なアドレスを選べません。結果としてOfferが返らないことがあります。
リレー設定が正しくても、サーバー側スコープが不足していれば取得できません。
「Discoverがサーバーまで届いた」ことと「サーバーがOfferを返せる」ことは別の確認項目です。
リレーのインターフェースアドレスが重要
DHCPリレーは、通常、クライアントから要求を受信したレイヤー3インターフェースのアドレスを基に中継情報を作ります。 そのため、次の状態も確認が必要です。
- クライアントVLAN用SVIまたはサブインターフェースがupしている
- 正しいIPアドレスとサブネットマスクが設定されている
- DHCPリレー設定がクライアント側インターフェースに入っている
- VRFを利用する場合、サーバーへの到達性とリレー動作が同じ論理空間で成立している
DHCP Option 82とは
DHCP Option 82は、DHCPリレーエージェント情報オプションとも呼ばれます。 リレー装置やスイッチが、クライアントの接続位置に関する情報をDHCPメッセージへ付加するために使われます。
Circuit ID
VLAN、ポート、論理回線など、クライアントが接続している回線を識別するための情報です。
Remote ID
リレー装置、スイッチ、加入者装置などを識別するための情報です。
DHCPサーバーはOption 82を使って、接続ポートごとに配布ポリシーを変えたり、 不正な場所からの要求を拒否したり、払い出し履歴を追跡したりできます。
現場での注意
Option 82を有効にすると、サーバー側の受け入れ設定、信頼ポート、DHCP Snoopingなどとの整合が必要になる場合があります。 基本的なDHCPリレー障害を調べるときは、Option 82の有無やサーバーポリシーも確認してください。
小規模な検証ではgiaddrだけでスコープを選択できます。 Option 82は必須ではありませんが、大規模LAN、アクセスネットワーク、厳密な払い出し制御では重要になる機能です。
Cisco IOSの設定例
次の構成を例に、DHCPリレーを設定します。
設定例の構成
DHCPクライアント
Vlan100：192.168.100.1/24
GW：192.168.100.1
1．VLANとSVIを設定する
2．クライアント側SVIへDHCPリレーを設定する
ip helper-addressは、DHCPクライアントが存在する側のレイヤー3インターフェースへ設定します。
この例ではVLAN 10からDHCP Discoverを受信するため、interface Vlan10へ設定します。
DHCPサーバーが接続されているVlan100へ設定するものではありません。
3．複数のクライアントVLANがある場合
VLAN 20にもクライアントがいる場合は、Vlan20へもリレー設定を追加します。
DHCPサーバー側には、少なくとも次の2つのスコープが必要です。
| クライアントVLAN | ネットワーク | 配布例 | デフォルトゲートウェイ |
|---|---|---|---|
| VLAN 10 | 192.168.10.0/24 | 192.168.10.100～192.168.10.200 | 192.168.10.1 |
| VLAN 20 | 192.168.20.0/24 | 192.168.20.100～192.168.20.200 | 192.168.20.1 |
4．ルーター・オン・ア・スティックの場合
物理ルーターのサブインターフェースが各VLANのデフォルトゲートウェイになる場合は、 クライアント側サブインターフェースへ設定します。
5．DHCPサーバーを2台指定する場合
複数の中継先を指定すると、クライアント要求が複数サーバーへ届く構成にできます。 ただし、サーバー間で同じアドレスを重複配布しないように、フェイルオーバー、分割スコープ、クラスタリングなど、 サーバー側の冗長化設計が必要です。
設定コマンドや転送対象は、ベンダー、OS、機種、バージョンによって異なります。
Cisco IOSのip helper-addressは、実装によってDHCP以外のUDPブロードキャストも中継対象になる場合があります。
必要な通信だけを許可する設計、製品ドキュメント、実機のヘルプを確認してください。
確認コマンドと正常性の判断
DHCPリレーは、設定の有無だけでなく、SVIの状態、VLAN、ルーティング、ACL、サーバー側スコープを組み合わせて確認します。
1．インターフェース設定を確認する
次の3点を読み取ります。
- クライアント側インターフェースを確認しているか
- IPアドレスとサブネットマスクが設計どおりか
ip helper-addressの宛先が正しいか
2．SVIと物理ポートの状態を確認する
Vlan10がup/upでなければ、DHCP Discoverを受信できない可能性があります。
SVIがupになる条件は機種や構成によって異なりますが、対象VLANが存在し、VLAN内に有効なポートがあるか確認します。
3．DHCPサーバーへの経路を確認する
DHCPサーバーが別ルーターの先にいる場合は、スタティックルートや動的ルーティングで到達できることを確認します。 リレーからサーバーへの片方向だけでなく、サーバーからリレーへ戻る経路も必要です。
4．VLANとクライアントポートを確認する
PC-Aが接続されたポートがVLAN 10ではなくVLAN 20に入っていれば、 Vlan10のリレー設定ではなく、Vlan20のリレー設定とスコープが必要です。
5．ACLを確認する
インターフェースACL、ファイアウォール、サーバー側OSファイアウォールなどで、DHCP/BOOTPに必要な通信が拒否されていないか確認します。 UDP 67と68が関係しますが、どの区間でどの送信元・宛先・ポートになるかは、リレーの実装と通信方向を踏まえて判断します。
6．パケットキャプチャーで確認する
| 取得位置 | 正常時に見たいもの | 見えない場合に疑う場所 |
|---|---|---|
| クライアント側VLAN | DHCP Discover | 端末、NIC、VLAN、ポート、無線接続 |
| リレーからサーバー側 | 中継されたDiscoverとgiaddr | helper設定、SVI状態、ACL、リレー機能 |
| サーバー側 | Discover受信とOffer送信 | 経路、FW、サーバーサービス、スコープ |
| クライアント側への戻り | OfferまたはACK | 戻り経路、ACL、リレーの転送、VLAN |
正常性は「PCがアドレスを取れた」だけで判断しません。
取得したIPアドレス、サブネットマスク、デフォルトゲートウェイ、DNSサーバー、リース時間が設計どおりか確認します。
DHCPリレー障害の切り分け
DHCPでIPアドレスを取得できない場合は、クライアントからサーバーへ向かって順番に確認します。 いきなりDHCPサーバーだけを調べず、Discoverがどこまで届いているかを追跡します。
STEP 1：クライアントがDHCPを要求しているか
- IPv4設定が自動取得になっているか
- リンクアップまたは無線接続が成立しているか
- 固定IPアドレスが残っていないか
- アドレス解放・再取得を実行するとDiscoverが出るか
- APIPAなどの自動プライベートアドレスになっていないか
Windowsで169.254.0.0/16のアドレスが付いている場合、DHCPによる取得に失敗し、 自動プライベートIPアドレスが設定された可能性があります。
STEP 2：正しいVLANへ収容されているか
- クライアントポートのアクセスポートVLAN
- トランクで対象VLANが許可されているか
- VLANが作成され、activeになっているか
- 無線LANの場合、SSIDとVLANの対応
- 認証後に割り当てられる動的VLAN
設計ではVLAN 10のつもりでも、実際にはVLAN 20へ収容されていれば、 サーバーはVLAN 20用スコープを選ぶ必要があります。
STEP 3：DHCPリレー設定が正しいか
- クライアント側SVIまたはサブインターフェースに設定されているか
- DHCPサーバーのIPアドレスに入力ミスがないか
- 複数VRFを利用している場合、到達先のVRFが正しいか
- インターフェースがup/upか
- 機器全体でリレー機能を無効化する設定がないか
送信元を指定したpingは、リレーインターフェースからサーバーまでの基本的なIP到達性を確認する材料になります。 ただし、pingが通ってもUDP 67/68、DHCPサービス、スコープまで正常とは限りません。
STEP 4：ルーティング・ACL・ファイアウォールを確認する
- リレーからDHCPサーバーへの経路
- DHCPサーバーからリレーへの戻り経路
- 中間ファイアウォールのポリシー
- リレー装置のインターフェースACL
- DHCPサーバーのホストファイアウォール
- NATを介在させていないか
DHCPリレーとサーバー間は、単純なクライアントのブロードキャストではなく、 リレー装置とサーバーのIP通信として扱われます。通信経路上のルーティングとセキュリティ制御を確認します。
STEP 5：DHCPサーバー側を確認する
- DHCPサービスが起動しているか
- giaddrに対応するスコープが存在するか
- スコープが有効になっているか
- 配布可能なアドレスが残っているか
- 除外範囲が広すぎないか
- MACアドレス予約やポリシーで拒否されていないか
- Option 82を要求・拒否する条件が一致しているか
- ログにNO FREE LEASES、unknown subnetなどのエラーがないか
症状から原因候補を絞る
| 症状 | 考えられる原因 | 優先確認 |
|---|---|---|
| 全VLANで取得できない | DHCPサーバー停止、共通経路、共通FW、サーバー側障害 | サーバー状態、全体ログ、共通中継区間 |
| 特定VLANだけ取得できない | helper未設定、SVI down、スコープ不足、VLAN誤り | 対象SVI、giaddr、対象スコープ |
| 一部端末だけ取得できない | 端末設定、ポート、認証、予約、重複、端末FW | 端末パケット、接続ポート、MAC情報 |
| Discoverは届くがOfferがない | スコープなし、プール枯渇、サーバーポリシー、サービス停止 | サーバーログとスコープ |
| Offerはサーバーから出るが端末に届かない | 戻り経路、ACL、リレー処理、VLAN転送 | サーバー側とクライアント側の同時キャプチャー |
| IPは取れるが通信できない | 誤ったGW、マスク、DNS、ACL、重複IP | 取得オプションと疎通経路 |
パケットキャプチャーでの見方
Wiresharkでは、表示フィルターとして次を利用できます。
パケットの詳細で、次の項目を確認します。
- DHCP Message Type：Discover、Offer、Request、ACK
- Client MAC address：対象端末か
- Transaction ID：同じ取得処理の往復か
- Your client IP address（yiaddr）：提示されたアドレス
- Gateway IP address（giaddr）：どのリレーサブネットか
- Server Identifier：応答したDHCPサーバー
- Option 3 Router：デフォルトゲートウェイ
- Option 6 Domain Name Server：DNSサーバー
- Option 82：リレーエージェント情報の有無
効率的な調査方法
クライアント側とサーバー側で同時刻にキャプチャーし、同じTransaction IDを追跡すると、 DiscoverやOfferがどの区間で消えているか判断しやすくなります。
設計時の判断ポイント
1．DHCPリレーはどこへ設定するか
原則として、クライアントのブロードキャストを最初に受信するレイヤー3ゲートウェイへ設定します。 具体的には、次のいずれかです。
- レイヤー3スイッチのSVI
- ルーターのサブインターフェース
- ファイアウォールのVLANインターフェース
- VRF内のクライアント側インターフェース
FHRPでデフォルトゲートウェイを冗長化している場合、実装方式に応じて両方の装置へリレー設定が必要か、 どちらがDiscoverを処理するかを確認します。
2．中央集約と拠点ローカルのどちらにするか
| 判断項目 | 中央集約が向く場合 | 拠点ローカルが向く場合 |
|---|---|---|
| 運用 | 設定・監視・バックアップを一元化したい | 拠点単位で独立運用したい |
| 回線障害 | WAN障害時の影響を許容、または長いリースで補完できる | WAN断でも新規端末へ配布したい |
| 拠点数 | 多数拠点を共通ポリシーで管理したい | 少数拠点で個別要件が強い |
| セキュリティ | 払い出しログと認証情報を集中管理したい | 拠点外へDHCP情報を出したくない |
3．リース時間をどう決めるか
リース時間が短いほど、端末の入れ替わりへ追従しやすく、アドレスを再利用しやすくなります。 一方で、更新通信とDHCPサーバーへの依存度が高まります。
短いリースが向く例
- 来客用Wi-Fi
- 端末の入れ替わりが多い環境
- 小さいアドレスプールを効率利用したい環境
長いリースが向く例
- 端末が固定的な社内LAN
- WAN障害時にも既存リースを維持したい拠点
- DHCP更新負荷を抑えたい環境
4．冗長化をどこまで考えるか
- DHCPサーバーの冗長化
- リレー装置・デフォルトゲートウェイの冗長化
- リレーからサーバーまでのルーティング冗長化
- ファイアウォール経路の冗長化
- DNSや認証など、配布後に必要な関連サービスの冗長化
DHCPサーバーを2台にしても、両方へ到達する唯一のWAN回線が切れれば新規払い出しはできません。 サーバー台数だけでなく、クライアントからサーバーまでの経路全体を見ます。
5．セキュリティをどう組み合わせるか
- 不正DHCPサーバーを抑止するDHCP Snooping
- リレー装置とDHCPサーバー間だけに通信元を制限するACL
- Option 82による接続位置の識別
- 払い出しログの保存と時刻同期
- 管理ネットワークからのみDHCPサーバーを操作できる制御
DHCP Snoopingの信頼ポート設定やOption 82処理を誤ると、正規のDHCP応答まで破棄することがあります。 セキュリティ機能を追加した後は、DORAの全段階を再試験します。
DHCPリレーに関するよくある勘違い
ルーターはレイヤー2ブロードキャストをそのまま別サブネットへ転送しません。 DHCPリレーがメッセージを受信し、サーバーへ中継する処理が必要です。
リレーは通信を運ぶだけです。サーバーには、各クライアントサブネットに対応するスコープと配布オプションが必要です。
基本的には、クライアントのDiscoverを受信する側のSVIまたはサブインターフェースへ設定します。
pingはIP到達性の確認材料です。UDP通信、ACL、DHCPサービス、スコープ、Option 82などは別に確認します。
誤ったデフォルトゲートウェイやDNSサーバーが配布されると、アドレス取得後の通信に失敗します。 取得した全オプションを確認します。
Discover、Offer、Request、ACKが、クライアント側・リレー側・サーバー側のどこまで届いているか確認すると、原因箇所を絞れます。
調査結果の報告方法
DHCP障害の報告では、「IPアドレスを取得できない」だけでなく、 DORAのどこまで確認できたか、影響範囲、暫定対応、次の確認事項を整理します。
- 事象
- VLAN 10の端末がDHCPでIPv4アドレスを取得できない。
- 影響範囲
- VLAN 10の新規接続端末。既存リースを保持する端末は現時点で通信可能。
- 確認結果
- PC-AからDHCP Discoverが送信され、SW1のVlan10までは到達している。
- 原因箇所
- Vlan10の
ip helper-addressが192.168.100.20となっており、正しいDHCPサーバー192.168.100.10と不一致。 - 対応
- 中継先を192.168.100.10へ修正後、DORAが完了し、192.168.10.101を取得した。
- 正常性確認
- サブネットマスク、デフォルトゲートウェイ、DNSサーバー、疎通、名前解決を確認済み。
- 再発防止
- パラメータシートとの突合、設定レビュー、VLANごとのDHCP取得試験を手順書へ追加する。
顧客・上司へ短く説明する例
VLAN 10の端末が送信したDHCP要求はL3スイッチまで届いていましたが、 DHCPリレーの転送先IPアドレスが誤っていたため、正規のDHCPサーバーへ要求が届いていませんでした。 転送先を修正し、IPアドレス、デフォルトゲートウェイ、DNSサーバーの取得と業務通信を確認しました。
「DHCPが壊れていた」ではなく、要求がどこまで届き、どの設定が誤っており、修正後に何を確認したかを伝えると、 調査の根拠が明確になります。
英語ドキュメントで使われる表現
| 英語表現 | 意味 | 調査での使い方 |
|---|---|---|
| DHCP relay agent | DHCPリレーエージェント | 製品のリレー設定・制限事項を検索する |
| gateway IP address / giaddr | リレー元ネットワークを示すアドレス | サーバーが選択するスコープを確認する |
| relay agent information option | リレーエージェント情報オプション | Option 82の仕様・ポリシーを確認する |
| address pool exhausted | アドレスプールが枯渇した | Offerが返らない原因を検索する |
| unknown subnet | 対応するサブネットが不明 | giaddrに対応するスコープ不足を疑う |
| DHCPDISCOVER is not forwarded | Discoverが中継されない | リレー設定、ACL、インターフェース状態を調べる |
ベンダーへ問い合わせる英文例
問い合わせでは、クライアントVLAN、リレーインターフェース、DHCPサーバーIP、 どの区間でパケットが見えないかを具体的に書きます。
理解度チェック
次の6問に答えてください。解答を見る前に、クライアント・リレー・サーバーのどこで行う処理かを考えましょう。
問題1．DHCPリレーが必要になる主な理由はどれですか。
- DHCPサーバーがMACアドレスを持たないため
- DHCP Discoverのブロードキャストが通常はルーターを越えないため
- DHCPではTCPしか使用できないため
- クライアントが必ず固定IPアドレスを持つため
解答を見る
IPアドレス未取得のクライアントはDiscoverをブロードキャストで送ります。 別サブネットのサーバーへ届けるには、DHCPリレーによる中継が必要です。
問題2．Cisco IOSでip helper-addressを設定する基本的な場所はどこですか。
- DHCPサーバーが接続された物理ポートだけ
- クライアントのDHCP Discoverを受信するレイヤー3インターフェース
- すべてのトランクポート
- クライアントPCのNIC
解答を見る
クライアント側VLANのSVIやルーターのサブインターフェースへ設定します。
問題3．giaddrの主な役割は何ですか。
解答を見る
DHCPサーバーへ、どのクライアント側サブネットから要求が中継されたかを伝えることです。 サーバーはgiaddrを基に適切なスコープを選択します。
問題4．DiscoverはDHCPサーバーまで届いていますが、Offerが返りません。優先して確認する項目を3つ挙げてください。
解答例を見る
- giaddrに対応するスコープが存在し、有効か
- 配布可能なアドレスが残っているか
- サーバーポリシーやOption 82条件で拒否されていないか
DHCPサービスの稼働状態とサーバーログも確認します。
問題5．IPアドレスは取得できましたが、Webサイトへ接続できません。DHCP関連で確認する値を3つ挙げてください。
解答例を見る
- サブネットマスク
- デフォルトゲートウェイ
- DNSサーバー
取得したIPアドレスが正しいスコープのものか、重複していないかも確認します。
問題6．次の設定の問題点を答えてください。
解答を見る
DHCPクライアントがVLAN 10にいるなら、ip helper-addressはDiscoverを受信する
interface Vlan10へ設定する必要があります。
Vlan100がサーバー側であれば、そこへ設定してもVLAN 10のDiscoverを中継できません。
実践演習：VLAN 10だけDHCPを取得できない原因を特定する
次の構成で、VLAN 20の端末はIPアドレスを取得できますが、VLAN 10のPC-Aだけ取得できません。
演習用ネットワーク
取得失敗
Vlan20：192.168.20.1
VLAN 10・20用スコープあり
SW1の設定
DHCPサーバーの情報
| 項目 | 値 |
|---|---|
| サーバーIP | 192.168.100.10/24 |
| デフォルトゲートウェイ | 192.168.100.1 |
| VLAN 10用スコープ | 192.168.10.100～192.168.10.200 |
| VLAN 20用スコープ | 192.168.20.100～192.168.20.200 |
課題1．原因を特定する
VLAN 10だけ取得できない原因を答えてください。
課題1の解答を見る
Vlan10のip helper-addressが192.168.100.20となっており、
正しいDHCPサーバー192.168.100.10と一致していません。
VLAN 20は正しい中継先を指定しているため、VLAN 20だけ取得できます。
課題2．修正コマンドを作成する
課題2の解答を見る
課題3．修正後の試験項目を作る
設定修正後に確認すべき項目を5つ以上挙げてください。
2．
3．
4．
5．
課題3の解答例を見る
- Vlan10に正しい
ip helper-addressが設定されている - PC-AでDHCP Discover、Offer、Request、ACKが確認できる
- PC-Aが192.168.10.0/24のアドレスを取得する
- サブネットマスクが255.255.255.0である
- デフォルトゲートウェイが192.168.10.1である
- DNSサーバーが設計どおりである
- デフォルトゲートウェイへpingできる
- 別セグメントへの通信と名前解決が成功する
- VLAN 20のDHCP取得に影響がない
課題4．調査結果を報告する
「事象・原因・対応・確認結果」の4項目で、100～200字程度の報告文を作成してください。
課題4の回答例を見る
VLAN 10の端末がDHCPでIPアドレスを取得できない事象を確認しました。 SW1のVlan10に設定されたDHCPリレー先が192.168.100.20となっており、 正規サーバー192.168.100.10と不一致だったことが原因です。 中継先を修正後、DORAの完了、正しいIP・ゲートウェイ・DNSの取得、業務通信を確認しました。
自分の言葉で説明する課題
「DHCPサーバーが別VLANにあるのに、なぜPCはIPアドレスを取得できるのですか？」と質問されました。 技術に詳しくない人へ60秒程度で説明してください。
説明例を見る
PCが最初に送るDHCP要求は、同じネットワーク内にだけ届くブロードキャストです。 そこで、PCのデフォルトゲートウェイで動くDHCPリレーが要求を受け取り、 別VLANにあるDHCPサーバーへ届けます。サーバーは、どのVLANから届いた要求かを見て、 そのVLAN用のIPアドレスを選び、リレーを経由してPCへ返します。
「ブロードキャストはルーターを越えない」「リレーがサーバーへ中継する」「サーバーは元のサブネットに合うアドレスを選ぶ」 の3点を含めて説明できれば、この記事の目標は達成です。
まとめ
- DHCPリレーは、異なるサブネットのDHCPクライアントとサーバーのメッセージを中継する機能
- DHCP Discoverはブロードキャストであり、通常はルーターを越えない
- リレーはクライアント側インターフェースで要求を受信し、DHCPサーバーへ中継する
- DHCPサーバーはgiaddrを基に、クライアントサブネットに対応するスコープを選択する
- Cisco IOSではクライアント側SVIなどへ
ip helper-addressを設定する - 障害時は、クライアント、VLAN、リレー、経路・ACL、サーバーの順に確認する
- Discoverが届くか、Offerが返るかを区間ごとにキャプチャーすると原因を絞りやすい
- IP取得後も、デフォルトゲートウェイ、DNS、疎通、名前解決を確認する
DHCPリレーの切り分けでは、「設定があるか」だけでなく、DORAの各メッセージがどこまで届いているかを追跡することが重要です。
コメント