![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
| この記事を書いた日は 2021/01/29 です |
DHCPの冗長化手法の一つに、アドレスプールが重複しないように設定した DHCP サーバを 同一セグメントに複数配置する方法があります。
自分が愛用しているヤマハの RTX や NVR シリーズに内蔵されている DHCP サーバ機能でもこの方法は可能なのですが、 実際に試したときにハマったところがあったので、今後のためにメモしておきます。
RTX1210 2台を使用し、VRRP で冗長構成を組んでいます。 この構成で DHCP サーバも二重化するため、2台の RTX1210 の DHCP サーバ機能を有効化し、IPアドレスの範囲をずらして各々に設定しました。
 |
この構成に変更して以降、NW内の端末で数秒～十数秒程度の瞬断が発生するようになりました。 頻度は1日に1回程度で、タイミングは各端末ともバラバラ。
直接の原因は、DHCP の再取得のときに選択されていない方の RTX1210 が DHCPNAK メッセージを投げていたことでした。
DHCP クライアントは DHCP で取得したIPアドレスをリース延長などで再取得するとき、 Requested IP Address に現在のIPアドレスを指定した DHCPREQUEST をブロードキャストします。 これに対し、現在のIPアドレスをリースしている方の RTX1210 は DHCPACK を返します。
ここまでは意図した通りの動作です。
ところが、もう一方の RTX1210 はリース情報を持たないクライアントからの DHCPREQUEST を受け取ることになるため、DHCPNAK を返してしまうのです。
 |
DHCPNAK を受け取ったクライアントは DHCP の規定により、アドレス設定シーケンスをふりだしから始めなければならないため、現在のIPアドレスを破棄してしまうわけです。
RTX の DHCP サーバが RFC2131 準拠で動作するようにします
RTX1210 config:
dhcp server rfc2131 compliant on # または no dhcp server rfc2131 compliant
DHCP の仕様を規定した RFC1541 では、サーバが DHCPREQUEST の要件に応じることができない場合、 DHCPNAK を返す規定があります。
つまり、アドレスプール外のIPアドレスが指定された DHCPREQUEST に対して DHCPNAK を返すのは RFC1541 準拠で動作する場合は適切な挙動のようです。
一方、RFC1541 の差し替え版に当たる RFC2131 にも同様の規定がありますが、 こちらはサーバ内でクライアントのリクエストが適切でない保証が取れない場合には DHCPNAK を 返すべきではないという条件付きになっています。
RTX1210 のコンフィグでは `dhcp server rfc2131 compliant` で動作をどちらの RFC に合わせるかの選択が可能です。
この設定が `off` または `except remain-silent` になっていると、未知の DHCPREQUEST に対して DHCPNAK を返す動作になります。
RTX1200 以降の機種では工場出荷時の設定で `dhcp server rfc2131 compliant except remain-silent` が入っているので、他の DHCP サーバと併せて運用する場合は注意が必要です。
Logbook
command snippet
command snippet/windows
Mastodon
さくらのVPS
20190619-rtx-vrrp-dhcp-002.png
20190619-rtx-vrrp-dhcp-001.png
