DHCP リレーとは
DHCP クライアントはブロードキャストで DHCP サーバを探しに行くため、普通のやり方では同一セグメント内に DHCP サーバを配置しなければなりません。ですがそのやり方では複数セグメントで DHCP を使いたい場合は各セグメントに DHCP サーバを配置することになり、非常に非効率です。
そんな悩みを解決するのが DHCP リレーです。
L3 機器 (L3 スイッチやルータ) において、DHCP リレーの設定として DHCP サーバの IP アドレスを指定すると、L3 機器の DHCP リレーエージェントが働き始め、DHCP のブロードキャストパケットを DHCP サーバ宛のユニキャストパケットに変換してくれるのです。
DHCP リレーエージェントとは、NW 機器の OS 上で動作しているプログラム (プロセス) と考えて下さい。例えば Cisco であれば Cisco IOS 上で RIP や OSPF , BGP 等がプロセスとして動作しますがそれらと同列です。
DHCP サーバがスコープを識別できる理由
DHCP リレー設定をすると、DHCP サーバは様々な VLAN から DHCP discover/request を受信するようになりますが、各 VLAN に適したスコープを払い出さなければなりません。
DHCP サーバが『どのクライアントからのパケットを受信したのか？』を判断するのは、giaddr (Gateway IP Address) です。
DHCP リレーエージェントは DHCP ブロードキャストを受信したインタフェースの IP アドレスを DHCP パケットの giaddr というフィールドに埋め込んだ上で DHCP サーバにユニキャストするのです。
DHCP サーバは giaddr を確認し、その giaddr が存在するスコープから IP アドレスを払い出します。
このとき、送信元 IP アドレスがどうあるべきかは仕様 (RFC) では決まっていません。大抵は giaddr と同じになるか、DHCP サーバに近いインタフェースの IP アドレスになるかのどちらかです。(UDP port も決まっていません。)
ただし、DHCP サーバからの返信先は giaddr の IP アドレスにユニキャストで返信されるため、giaddr と異なる送信元 IP で投げる場合、間にファイアウォールがあるとステートフル・インスペクションによりパケットがドロップされることがあります。
そのため、設定で giaddr に合わせることのできる機器も増えています。(次のパケットキャプチャ検証で使った VyOS ではできないようですが。)
DHCP とDHCPリレーのパケットキャプチャの比較
DHCP のパケットキャプチャを [① 通常のDHCP]、[② DHCPリレー]の 2 通りで取得しました。いずれも DHCP サーバ上の tcpdump で取得しています。
シーケンスと DHCP Discover の比較。Wireshark の表示上、Relay agent IP address と表示されていますが、この箇所が giaddr です。
DHCP Offer の比較。
DHCP Request の比較。
DHCP ACK の比較。
Option 82 = Relay Agent Information
DHCP のオプション 82 番はリレーエージェントが自身の情報を格納するフィールドです。一般的にはリレーエージェントが設定される L3 機器で付加されます。
オプション 82 を使うと DHCP サーバに DHCP リレーの情報を伝えることができます。伝わる情報は一般的には『リレーを行った機器のホスト識別子 (Remote ID)、およびポート番号 (Circuit ID)』です。
この Option 82 の使われ方は主に 2 つあります。
1 つ目は DHCP サーバでのログに出力し、どのクライアントがどの機器経由で、いつからいつまで IP が払い出されたかを管理する、という使い方です。
特にケーブル TV では各家庭への Global IP アドレスを DHCP リレーで払い出しますが、どの収容機器のどのポートがいつからいつまで IP を使っているかを知ることができます。
2 つ目は DHCP サーバ側で Option 82 の値によって払い出す IP やオプションを変更する、という使い方です。
具体的には、『Option 82 が XXX の場合はIPアドレスの払い出し範囲は 10.1.1.10-15/24 で DGW は 10.1.1.250、YYY の場合は 10.1.1.90-95/24 で DGW は 10.1.1.251』といった具合です。
ですが Cisco の DHCP snooping ではこれ以外の使われ方がされます。DHCP snooping を行う L2 機器にて (DHCPリレーをしないのに) このフィールドに自身の情報をセットし、これを使って DHCP snooping データベースと整合性が合うかどうか照合します。もしマッチしない場合は不正な DHCP 通信として破棄されるのです。
IT/インフラエンジニアの地位とスキル向上のために
あなたが成長の日々を歩めますように。
コメント
お忙しいところ失礼します。
dhcpの要求、応答について質問です。
dhcpリレー出ない場合、クライアント~の要求はブロードキャスト、サーバからの返答の場合ユニキャストの認識です。
dhcpリレーの場合、返答の際にサーバからの返答の際にブロードキャストに変換されると記載がありましたが変換される理由についてご教授いただけませんでしょうか？
そのままリレーを使用しない時と同じでは駄目なのでしょうか？
mario さん
コメントありがとうございます。また、返信が遅くなりすみません。
DHCPリレーについてですが、記事を書いた時の私の理解が浅かったのですが、どうやら返りの通信の挙動はNW機器製品の実装によるようです。(RFCでは定義が無さそう)
以前 dnsmasq でDHCPサーバを立ててみてみたところ、同セグメントのBroadcastによるDiscover/Requestに対し、dnsmasq がブロードキャストでOffer/Ackを返していました。
なので多分リレーについても同様に、製品によってユニキャストであったりブロードキャストになると思います。
もう少し検証してから記事を修正したいと思いますが、取り急ぎ。
今後もよろしくお願いいたします。
DHCPサーバを構築するところだったのですが、どのスコープがどのvlan向けとかの設定項目がなく、
どうやってスコープとvlanを紐づけているのか不思議でならなかったので、この記事で疑問が解け助かりました。
stkyさん
コメントありがとうございます。
この記事を書こうと思った動機はまさに私もVLAN(セグメント)との紐づけの仕組みが分からず、調べるのに苦労したからです。
お役に立てて何よりです。
今後もどうぞ宜しくお願い致します。