remote-id-mismatch (DHCP Local Server and DHCP Relay Agent)

構文

階層レベル

形容

DHCP ローカル サーバーまたは DHCP リレー エージェントを構成して、エージェント リモート ID 値の不一致を検出し、新しい接続要求をトリガーします。加入者のサービス プランに関する情報はエージェント リモート ID にエンコードされます。このリモート ID は、DHCPv4 クライアントの場合はオプション 82、サブオプション 2、DHCPv6 クライアントの場合はオプション 37 で伝達されます。サブスクライバーセッションがアクティブ化されると、許可サービスプランのエージェントリモートID値がセッションデータベースに保存されます。 remote-id-mismatch を設定すると、DHCP ローカルサーバーとリレーエージェントは、着信メッセージ、更新メッセージ、および再バインドメッセージを検査し、メッセージ内のエージェントリモートIDを、DHCPがデータベースに保存した初期値と比較します。DHCPローカルサーバーは、保存されている値とメッセージ内の値の間に不一致を検出すると、NAKをクライアントに送信し、クライアントバインディングを破棄します。クライアントが DHCPv6 クライアントの場合、DHCPv6 は明示的な NAK メッセージをサポートしていないため、ローカル サーバーは、論理 NAK を示すためにライフタイムを 0 に設定した応答パケットを送信します。

DHCP リレー エージェントは、不一致を検出すると、NAK または論理 NAK(DHCPv6 の場合)を DHCP クライアントに送信します。リレー エージェントはバインド自体を破棄できないため、解放メッセージをローカル サーバーに送信し、ローカル サーバーにバインドを破棄させます。このためには、DHCP リレー エージェントで send-release-on-delete ステートメントを構成する必要があります。構成しないと、解放メッセージがローカル サーバーに送信されません。その場合、ローカルサーバーは、タイムアウトするか、IPアドレスが別のバインディングに使用されるまで、データベースにクライアントエントリを保持します。

手記：

remote-id-mismatch 機能は、デフォルトの DHCP リレーエージェントのリクエスト時のバインド動作よりも優先されます。既定では、迷子の DHCP 要求を受信すると、つまり、ローカル サーバー データベースにはエントリはあるがリレー エージェント データベースにエントリがない要求を受信すると、リレー エージェントとローカル サーバーとの完全なバインドが自動的に行われます。

DHCP クライアントは、NAK を受信すると、再ネゴシエーションを開始します。変更されたエージェント・リモートID値は、要求の一部として伝達され、新しいサービス・プランを認可のために送信することができます。

remote-id-mismatchステートメントは、通常、RADIUS認証ではなくローカル認証を使用する環境で使用されます。

手記：

[edit system services dhcp-local-server]、グローバル レベルで remote-id-mismatch ステートメントと reauthenticate ステートメントの両方を設定することはできません。ただし、DHCP の優先順位ルールでは、異なるレベルにある両方のステートメントを設定することができます。たとえば、グローバル レベルで reauthenticate を設定し、DHCPv6 の[edit system services dhcp-local-server dhcpv6]階層レベルや、特定のグループ[edit system services dhcp-local-server group name]階層レベルなどに対してremote-id-mismatchを設定できます。

必要な権限レベル

system:設定でこのステートメントを表示します。

システム制御—このステートメントを設定に追加します。

リリース情報

Junos OSリリース16.1で導入されたステートメント。