Cisco CNS Network Registrar Release 6.2 ユーザ ガイド
拡張ポイントの使用
拡張ポイントの使用
発行日;2012/02/01 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 5MB) | フィードバック

目次

拡張ポイントの使用

拡張機能の作成

拡張機能の作成

タスクの決定

アプローチの決定

拡張言語の選択

言語独立の API

ルーチンのシグニチャ

ディクショナリ

ディクショナリ内のユーティリティ メソッド

Init-Entry 拡張ポイント

設定エラー

拡張機能の認識

TCL 拡張機能

TCL アプリケーション プログラム インターフェイス

TCL エラーの処理

ブール変数の処理

TCL 拡張機能の設定

TCL の Init-Entry 拡張ポイント

C/C++ 拡張機能

C/C++ API

タイプの使用

C/C++ 拡張機能の構築

スレッドセーフな拡張機能の使用

C/C++ 拡張機能の設定

C/C++ 拡張機能のデバッグ

DHCP サーバ メモリへのポインタ

C/C++ の Init-Entry エントリ ポイント

拡張機能を使用した DHCP 要求処理

パケットの受信

パケットのデコード

クライアントクラスの判別

クライアントクラスの変更

クライアントクラスの処理

応答コンテナの構築

ネットワークの判別

リースの検索

リース要求のシリアル化

リースの受け入れ可能性の判別

応答パケット データの収集

応答パケットのエンコード

安定した記憶域の更新

パケットの送信

DNS 要求の処理

リース状態の変化のトレース

拡張ディクショナリ

環境ディクショナリ

環境ディクショナリのデータ項目

初期環境ディクショナリ

要求ディクショナリと応答ディクショナリ

デコード済みの DHCP パケット データ項目

パラメータ リスト オプションの使用

拡張ポイントの説明

post-packet-decode

post-class-lookup

pre-client-lookup

pre-client-lookup の環境ディクショナリ

pre-client-lookup へのクライアントクラス データの入力

pre-client-lookup の要求ディクショナリ

post-client-lookup

post-client-lookup の環境ディクショナリ

post-client-lookup の要求ディクショナリ

check-lease-acceptable

lease-state-change

lease-state-change の応答ディクショナリ

lease-state-change の環境ディクショナリ

pre-packet-encode

pre-packet-encode の要求ディクショナリ

pre-packet-encode の応答ディクショナリ

pre-dns-add-forward

拡張ポイントの使用

拡張機能を作成すると、Cisco CNS Network Registrar が DHCP 要求を処理し、それに応答する方法を制御できます。また DHCP サーバの動作について、ユーザ インターフェイスから通常できないような変更を行えます。

ここでは、拡張機能を追加できる拡張ポイントについて説明します。


) 拡張機能は、式とは異なります。式(「式の使用方法」を参照)は、一般的にクライアント ID の作成またはクライアントのルックアップに使用します。拡張機能は、要求パケットまたは応答パケットを変更するために使用されます。


拡張機能の作成

Network Registrar DHCP サーバの操作を変更またはカスタマイズするには、TCL または C/C++ で 拡張機能 を作成して使用します。

DHCP サーバで使用する拡張機能を作成するには、次の手順を実行します。

1. 実行するタスク(どの DHCP パケット プロセスを変更するか)を決定する。

2. 使用するアプローチ(パケットプロセスをどのように変更するか)を決定する。

3. 拡張機能を追加する拡張ポイントを決定する。

4. 言語を選択する(TCL または C/C++)。

5. 拡張機能を記述する(またコンパイルしてリンクする)。

6. DHCP サーバの設定に拡張機能を追加する。

7. 拡張ポイントに拡張機能を追加する。

8. DHCP サーバをリロードして、拡張機能を認識できるようにする。

9. 結果をテストしデバッグする。

拡張機能の作成

Web UI で DHCP 拡張機能を作成するには、 DHCP をクリックしてから Extensions をクリックし、List DHCP Extensions ページを開きます。 Add DHCP Extension をクリックして、Add DHCP Extension ページを開きます(図28-1 を参照)。

図28-1 Add DHCP Extention ページ(ローカル)

 

拡張機能を追加する拡張ポイントを表示するには、List DHCP Extensions ページでページ上部にある Show Extension Points をクリックし、List DHCP Extension Points ページを開きます(図28-2 を参照)。作成してある拡張機能をこのページで 1 つまたは複数の拡張ポイントに追加してから、 Modify DHCP Extension をクリックします。

図28-2 List DHCP Extention Points ページ(ローカル)

 

CLI では、 extension コマンドを使用します。このコマンドでは、次のシンタックスを使用する必要があります。

nrcmd> extension name create language extension-file entry-point
 

entry-point は、 extension-file 内のエントリ ポイント名です。DHCP サーバがファイルを毎回ロードしたときの初期エントリ ポイントについて、オプションの init-entry アトリビュートを設定することもできます(「Init-Entry 拡張ポイント」を参照)。この関数は、このモジュールがバインドされているエクステンション ポイントから呼び出されます。 extension list を使用して、拡張機能を一覧表示することもできます。

拡張機能を追加および削除するには、DHCP サーバに対する dhcp attachExtension および dhcp detachExtension を使用します。それに必要なシンタックスは次のとおりです(シーケンス番号はオプションです)。

nrcmd> dhcp attachExtension extension-point extension-name [sequence-number]
nrcmd> dhcp detachExtension extension-point [sequence-number]
 

タスクの決定

拡張機能を適用するタスクは、通常、それぞれの環境に合せて DHCP サーバの処理を一部変更します。拡張機能は、要求の受け取りからクライアントへの応答まで、次のようなあらゆる DHCP サーバの処理ポイントに適用できます。

1. パケットの受信とデコード

2. あらゆるクライアントクラスの参照、変更、および処理

3. 応答タイプの構築

4. サブネットの決定

5. 既存のリースの検索

6. リース要求のシリアル化

7. クライアントのリース受け入れ可能性の判別

8. 応答パケットの収集とエンコード

9. パケットの安定記憶域のアップデート

10. パケットのリターン

これらの手順については、「拡張機能を使用した DHCP 要求処理」で説明します。

たとえば、BOOTP コンフィギュレーションを使用する特殊なルーティング ハブがあるとします。このデバイスは、 chaddr フィールド内にイーサネット ハードウェア タイプ(1)と MAC アドレスを入れて、BOOTP 要求を発行します。その後、同じ MAC アドレスで、ただしハードウェア タイプをトークン リング(6)として、別の BOOTP 要求を送信します。2 つの異なるハードウェア タイプを指定すると、DHCP サーバがそのデバイスに 2 つの IP アドレスを割り振ります。DHCP サーバは、通常、ハードウェア タイプ 1 の MAC アドレスと、タイプ 6 の MAC アドレスを区別し、異なるデバイスであると見なします。この場合、DHCP サーバが同じデバイスに 2 つの異なるアドレスを渡すことを防ぐ拡張機能を記述できます。

アプローチの決定

多くの場合、1 つの問題を解決するにも多くの解決策があります。どういう種類の拡張機能を作成するかの選択にあたっては、まず入力 DHCP パケットのリライトを検討してください。この方法では、DHCP サーバの内部処理について知る必要がないので、好ましいアプローチといえます。

「タスクの決定」に説明されている問題については、次のいずれかの方法で拡張機能を作成して問題を解決できます。

トークン リング(6)ハードウェア タイプのパケットをドロップする。

パケットをイーサネット パケットに変更してから、終了時に再び元のパケットに戻す。

2 番目の方法の拡張機能は複雑ですが、DHCP クライアントは DHCP サーバからのどちらかのリターンを使用できます。2 番目の方法はパケットをリライトしますが、ここでは post-send-packet 拡張ポイントを使用します(「パケットの送信」を参照)。異なるアプローチを使用する場合は、違う拡張機能と拡張ポイントが必要です。

拡張言語の選択

拡張機能は、TCL または C/C++ で記述できます。DHCP が関係する限りにおいては、これらの言語の機能はよく似ていますが、言語設計のアプローチが大きく異なるので、これらをサポートするためのアプリケーション プログラミング インターフェイス(API)が若干異なります。

TCL:TCL のスクリプティングは C/C++ のスクリプティングよりいくらか簡単ですが、これはシングルスレッドのインタプリタ言語であり、より多くのリソースが必要です。しかし、C/C++ よりも重大なバグが生じる可能性が低いので、サーバがクラッシュする可能性も低くなります。

C/C++:この言語は、可能な限り高いパフォーマンスと柔軟性(外部プロセスとの通信など)を提供します。ただし、拡張機能が DHCP サーバ自体と同じコード空間で動作するので、C/C++ API の方が複雑であり、サーバをクラッシュさせるバグが拡張機能内で発生する可能性が TCL より高くなります。

言語独立の API

次の概念は、TCL と C/C++ のどちらで拡張機能を記述するかに依存しません。

ルーチンのシグニチャ

拡張機能はファイル内のルーチンとして定義する必要があります。また、同じファイル内に複数の拡張機能を格納できます。そこで 1 つ以上の DHCP サーバ拡張ポイントに拡張を追加することになります。DHCP サーバは、拡張ポイントに達すると、拡張機能によって定義されるルーチンを呼び出します。ルーチンは、正常終了または異常終了を返します。拡張機能が異常終了したときに、DHCP サーバがパケットをドロップするように設定できます。

1 つのファイル(TCL ソース ファイルまたは C/C++ .dll か .so ファイル)を DHCP サーバの複数の拡張機能として設定できます。これには、設定した拡張機能ごとに別のエントリ ポイントを指定します。

サーバは、すべてのルーチン エントリ ポイントを最低 3 つの引数、つまり、要求、応答、および環境の 3 つのディクショナリを使用して呼び出します。それぞれのディクショナリは、キー値ペアの表現です。

拡張機能は、特定のデータ項目のディクショナリで get メソッドを実行して DHCP サーバからデータ項目を取得できます。

拡張機能は、同じ名前のデータ項目で put 操作を実行してデータ項目を変更できます。

どの拡張ポイントでもすべてのディクショナリが使用できるわけではありませんが、すべての拡張ポイントにおいて、どのルーチンの呼び出しシーケンスも同じです。拡張機能は、特定の拡張ポイントに存在しないディクショナリを参照しようとすると、エラーが発生します。「環境ディクショナリ」「要求ディクショナリと応答ディクショナリ」を参照してください。

ディクショナリ

要求、応答、およびサーバ内のデータには、ディクショナリ インターフェイスからアクセスします。拡張ポイントには、要求、応答、および環境という 3 つのタイプのディクショナリが用意されています。

要求ディクショナリ:DHCP 要求に関する情報と要求そのものに含まれるすべての情報。データの値は、文字列、整数、IP アドレス、および blob です。

応答ディクショナリ:DHCP クライアントに返す DHCP 応答パケットの生成に関する情報。データの値は、文字列、整数、IP アドレス、および blob です。

環境ディクショナリ:DHCP サーバと拡張機能との間で受け渡される情報。

ディクショナリについては、「拡張ディクショナリ」を参照してください。

環境ディクショナリは、異なる拡張ポイントで実行される 2 つの拡張機能間の通信にも使用できます。DHCP サーバは、拡張機能が設定された最初の拡張ポイントに達すると、環境ディクショナリを作成します。環境ディクショナリは、許容されるデータ項目の名前が DHCP サーバによって固定されない唯一のディクショナリです。このディクショナリを使用すると、任意の文字列値のデータ項目を挿入できます。

DHCP クライアントの要求と応答の間の制御フローにあるすべての拡張ポイント
pre-dns-add-forward 以外のすべての拡張ポイント)は、同じ環境ディクショナリを使用します。その結果、拡張機能は何らかの条件が存在することを判別し、環境ディクショナリに番兵を置き、後続の拡張機能が同じ条件を判別しないようにします。

前の例では、 post-packet-decode 拡張ポイントにある拡張機能が、パケットを興味深いパケット(特定のメーカーのデバイス、BOOTP、およびトークン リングからのパケット)であったと判別し、ハードウェア タイプをトークン リングからイーサネットにリライトします。拡張機能はまた、環境ディクショナリに番兵を置いた後、 pre-packet-encode 拡張ポイントの非常に単純な拡張機能で、ハードウェア タイプをトークン リングに戻します。

ディクショナリ内のユーティリティ メソッド

各ディクショナリは、拡張機能の追跡レベルをリセットし、値を出力ファイルにロギングできるユーティリティ メソッドがあります。

Init-Entry 拡張ポイント

init-entry 拡張ポイントは、DHCP サーバが拡張機能を設定または設定解除したときに呼び出される追加の拡張ポイントです。これは、サーバを起動、停止、またはリロードするときに発生します。このエントリ ポイントは、拡張機能に対して他のエントリ ポイントと同じシグニチャを持ちますが、ユーザが使用するのは環境ディクショナリのみです。 init-entry 拡張ポイントは、CLI で dhcp attachExtension コマンドを使用して設定するのではなく、すでに設定済みの拡張機能で init-entry を暗黙に設定します。

init-entry の設定には、エントリ ポイントの名前を使用する方法のほかに、 init-entry ポイントの呼び出し前に、DHCP サーバが環境ディクショナリの文字列 arguments の下にロードする文字列を設定する方法もあります。引数を使用すると、初期化引数の値を変えることでカスタマイズした拡張機能を作成できるので、コードを変更せずに動作を変更することができます。

引数を設定するには、既存の拡張ポイント上に init-args を設定します。これらの引数は、 init-entry 拡張ポイントの設定呼び出しと設定解除呼び出しの両方に対して存在します。設定呼び出しの拡張ポイント名は initialize であり、設定解除呼び出しは uninitialize です。


) 拡張機能が init-entry ポイントで呼び出される順序は不確実です。この順序はリロードによって、またはリリースによって異なる可能性があります。


設定エラー

拡張機能が失敗する理由は数多くあります。次に例を示します。

ファイルが見つからない。

ファイル内にエントリ ポイントまたは init-entry ポイントが存在しない。

拡張機能自体が init-entry 呼び出しからエラーを返す。

拡張機能のエラーは、それ自体重大なエラーではなく、これによって DHCP サーバが始動しないということはありません。しかし、その拡張ポイントの設定は失敗します。DHCP サーバで、その拡張ポイントのいずれかの設定に失敗している場合、サーバは始動しません。したがって、設定プロセスをデバッグするために、拡張機能と init-entry ポイントを設定し、拡張ポイントに追加しないという方法が考えられます。そのプロセスを終了した時点で、拡張子を拡張ポイントに追加します。

拡張機能の認識

DHCP サーバが拡張機能を認識できるのは、それ自体が最初に設定されたとき、またはリロード時のみです。拡張機能や拡張機能の設定の変更は、一般に可能です。しかし、サーバをリロードまたは再始動するまで、変更は有効ではありません。拡張のデバッグ時に、DHCP サーバのリロードを忘れることがエラーの原因となることがよくあります。

Network Registrar がリロードを必要とする理由は、拡張機能を事前にロードし、サーバの設定時にそれらの準備を完了することにより、処理のインパクトを最小限に抑えるためです。このアプローチは実稼動モードでは有用ですが、拡張機能のデバッグ時には面倒に感じられることがあります。

TCL 拡張機能

拡張機能を TCL で記述する場合、TCL API、エラーとブール変数の処理、および TCL 拡張機能を初期化する方法について理解しておく必要があります。

TCL アプリケーション プログラム インターフェイス

すべての TCL 拡張機能は、同じルーチン シグニチャを持ちます。

proc yourentry { request response environ } { # your-code }
 

任意のディクショナリでデータ項目を操作するには、次の引数をコマンドとして扱う必要があります。したがって、入力パケットの giaddr を取得するには、次のように記述します。

set my_giaddr [ $request get giaddr ]
 

この記述により、TCL 変数 my_giaddr が、パケット内の giaddr の文字列値に、たとえば 10.10.1.5 や 0.0.0.0 のように設定されます。

入力パケットの giaddr は、次の TCL 文を使用してリライトされます。

$request put giaddr "1.2.3.4"
 

1 つのルーチン エントリを複数の拡張ポイントに設定し、それが呼び出される拡張ポイントに応じて動作を変える場合、拡張ポイントの ASCII 名が、環境ディクショナリのキー extension-point の下に渡されます。

TCL 拡張機能のサンプルについては、次の Network Registrar ディレクトリを参照してください。

Solaris および Linux の場合:/opt/nwreg2/examples/dhcp/tcl

Windows の場合:\Program Files\Network Registrar\examples\dhcp\tcl

TCL エラーの処理

TCL エラーは次の場合に生成されます。

利用できないディクショナリを参照した場合

利用できないディクショナリのデータ項目を参照した場合

無効なデータ項目(たとえば無効な IP アドレス)に対して、 put 操作を要求した場合

これらの場合、文を catch { } エラー文で囲まない限り、拡張機能が即座に失敗します。

catch { $request put giaddr "1.2.3.a" } error
 

ブール変数の処理

環境ディクショナリでは、ブール変数は文字列値であり、 true または false の値を持ちます。DHCP サーバは、拡張機能によって値が true または false に設定されると想定します。しかし、要求または応答ディクショナリでは、ブール値はシングルバイトの数値形式であり、 true 1 false 0 となります。このアプローチは C/C++ 拡張機能では効率的ですが、TCL API がやや複雑になります。

TCL 拡張機能の設定

拡張機能を設定するには、拡張機能を記述して拡張機能のディレクトリに保存します。UNIX および Linux では、/opt/nwreg2/extensions/dhcp/tcl ディレクトリになります。Windows では、\Program Files\Network Registrar\extensions\dhcp\tcl ディレクトリになります。

DHCP サーバは、始動時に拡張機能を設定するとき、TCL ソース ファイルをインタープリターに読み込みます。ソース ファイルにシンタックス エラーがあって、TCL インタープリターがファイルをロードできない場合も拡張機能が失敗します。通常、DHCP サーバによって TCL からログファイルにエラー トレースバックが生成され、ユーザがエラーを見つけるのに役立ちます。

TCL の Init-Entry 拡張ポイント

TCL 拡張機能は、 init-entry 拡張ポイントをサポートし、コマンドラインの init-args パラメータに供給された引数が、キー arguments に関連付けられた環境ディクショナリに表示されます。

パフォーマンス向上のため、DHCP サーバで複数の TCL インタープリタを、それぞれ独自の TCL コンテキストで実行できます。サーバは、それが実行するすべての TCL コンテキスト(インタープリター)に対して、 init-entry ポイントで一度だけ TCL 拡張機能を呼び出します。複数の呼び出しが存在する場合は、TCL 拡張機能の init-entry が堅牢であることを確認する必要があります。

複数の TCL 間で情報を交換することはできませんが、 init-entry が TCL インタープリター内のグローバル TCL 変数を初期化でき、TCL 拡張機能がそのインタープリターに関係なくグローバル TCL 変数にアクセスできます。

TCL インタープリターは、すべての TCL 拡張機能で共有されることに注意してください。TCL 拡張機能がグローバル変数を初期化するか、手順を定義している場合、他の TCL 拡張機能のグローバル変数や手順名と競合していないことを確認します。

C/C++ 拡張機能

すべての DHCP C/C++ 拡張機能は、 dex 拡張機能と呼ばれます。これは、「DHCP Extension」の短縮形です。

C/C++ API

C/C++ API のエントリと init-entry ルーチンの両方に対するルーチン シグニチャは次のとおりです。

typedef int (DEXAPI * DexEntryPointFunction)(
int iExtensionPoint,
dex_AttributeDictionary_t* pRequest,
dex_AttributeDictionary_t* pResponse,
dex_EnvironmentDictionary_t* pEnviron );
 

拡張ポイントの整数値は、3 つの構造へのポインタとともに、各ルーチンのパラメータの 1 つです。

C/C++ API は、共有ライブラリを Network Registrar DHCP サーバ ファイルにリンクしなくてもいいように特に構成されています。ルーチンへのエントリは、拡張機能を設定するときに設定します。要求、応答、環境のそれぞれのディクショナリで実行する操作に必要なコールバック情報は、3 つのディクショナリ パラメータから構成される構造であり、拡張ルーチンに渡されます。

DHCP サーバはすべてのバイナリ情報をネットワーク順に返しますが、これは必ずしも実行中のアーキテクチャに適した順序とは限りません。

タイプの使用

C/C++ ルーチンには、たとえば getByType() のようなタイプが使用できるルーチンが数多くあります。これらは、パフォーマンスが重視される環境で使用するためのルーチンです。これらのルーチンを使用すると、拡張機能がたとえば init-entry ポイントでタイプへのポインタを一度取得すれば、その後は、文字列値の名前の代わりにそのポインタを使用して、C/C++ API のルーチンを呼び出せます。このようにタイプを使用すると、拡張機能の実行処理フローからハッシュ テーブル ルックアップを 1 つ削除できるので、あらゆる拡張機能のパフォーマンスが(少なくとも若干は)向上します。

C/C++ 拡張機能の構築

ディレクトリ /opt/nwreg2/examples/dhcp/dex(UNIX)および \Program Files\Network Registrar\examples
\dhcp\dex(Windows)には、サンプルの C/C++ 拡張コードとともに、サンプル拡張機能を構築するための簡単なメイクファイルが用意されています。独自の拡張機能を構築するには、このファイルを変更する必要があります。これには、Microsoft Visual C++ V5.0、GNU C++、および SunPro C++ 用のセクションがあります。単にコメント行を移動し、環境に合せてファイルを設定します。

拡張機能は、インクルード ファイル dex.h を参照する必要があります。このファイルには、作成したプログラムが C/C++ API を使用するために必要な情報が含まれています。Windows で C/C++ 拡張機能を構築する場合は、必ずエントリ ポイントを .def ファイルに追加します。

.dll(Windows)または .so(UNIX)ファイルは、構築した後(すべての dex 拡張機能が共有ライブラリとなります)、/opt/nwreg2/extensions/dhcp/dex ディレクトリ(UNIX)または \Program Files\Network Registrar\extensions\dhcp\dex ディレクトリ(Windows)に移動する必要があります。その後、それらのファイルを設定します。

スレッドセーフな拡張機能の使用

DHCP サーバはマルチスレッドなので、DHCP サーバ用に記述された C/C++ 拡張機能は、スレッドセーフ である必要があります。 それらの拡張機能は、同じエントリ ポイントで複数のスレッドから、また複数のプロセッサから同時に呼び出せる必要があります。Network Registrar の C/C++ 拡張機能を設計するには、マルチスレッド環境用にコードを記述した豊富な経験が必要です。


注意 すべての C/C++ 拡張は、スレッドセーフである必要があり、そうでない場合は DHCP サーバが正しく動作せずに、診断がきわめて困難な形でクラッシュします。これらの拡張機能が使用するライブラリおよびライブラリ ルーチンも、スレッドセーフである必要があります。

オペレーティング システムによっては、使用される実行時機能が本当にスレッドセーフであることを確認する必要があります。各機能のマニュアルを確認してください。オペレーティング システムによっては、スレッドセーフの特別なバージョンが提供されることがあります(多くの場合、 functionname _r)。Windows は、マルチスレッド アプリケーション用に、スレッドセーフなライブラリを数バージョン用意しているので、通常このような問題はありません。

スレッドの いずれかが 非スレッドセーフな呼び出しを行うと、セーフ バージョンまたはロック バージョンの呼び出しを行っている他のスレッドすべてに影響します。これによってメモリの破壊やクラッシュが生じる可能性があります。

このような障害は、その原因が明らかになることがほとんどないので、診断がきわめて困難です。クラッシュを発生させるには、サーバに非常に高い負荷をかけるか、マルチプロセッサ マシンで多くの処理を行う必要があります。場合によっては、数日間、実行を続ける必要があります。拡張機能の実装に問題があっても、重い負荷が長期間続いた後でなければ問題が発現しません。

ランタイム ライブラリやサードパーティ ライブラリによっては、検出できない非スレッドセーフ呼び出しを行っていることがあるので、どの外部ファイルとリンクされているかを実行可能ファイルで確認します(UNIX 上の nm)。

次のリストのいずれかの機能のシングル スレッド バージョンがスレッドによって呼び出された場合(_r サフィックスのないバージョンが、Solaris 上のスレッドによって呼び出された場合)は、それらを使用しないでください。これらのライブラリ ルーチンのスレッドセーフ バージョンへのインターフェイスは、オペレーティング システムによって異なる場合があります。

スレッドセーフ バージョンは次のとおりです。

 

asctime_r

gethostbyname_r

getservbyport_r

ctermid_r

gethostent_r

getservent_r

ctime_r

getnetbyaddr_r

getspent_r

fgetgrent_r

getnetbyname_r

getspnam_r

fgetpwent_r

getnetent_r

gmtime_r

fgetspent_r

getprotobyname_r

lgamma_r

gamma_r

getprotobynumber_r

localtime_r

getgrid_r

getprotoent_r

nis_sperror_r

getgrnam_r

getpwent_r

rand_r

getlogin_r

getrpcbyname_r

readdir_r

getpwnam_r

getrpcbynumber_r

strtok_r

getpwuid_r

getrpcent_r

tmpnam_r

getgrent_r

getservbyname_r

ttyname_r

gethostbyaddr_r

C/C++ 拡張機能の設定

.dll ファイルや .so ファイルは、サーバの動作中はアクティブなので上書きしないでください。サーバ停止後は、.dll ファイルおよび .so ファイルが使用されないので、新しいバージョンに上書きできます。

C/C++ 拡張機能のデバッグ

C/C++ 共有ライブラリは、DHCP サーバと同じアドレス空間で動作し、DHCP サーバ内の情報へのポインタを受け取るので、C/C++ 拡張機能にバグがあると、DHCP サーバのメモリが簡単に破壊され、サーバのクラッシュにつながります。このため、C/C++ 拡張機能を記述してテストするときには慎重に行う必要があります。まず TCL 拡張機能を使用して拡張機能を作成する方法を試し、さらにパフォーマンスを向上させるために C/C++ の拡張機能を使用します。

DHCP サーバ メモリへのポインタ

C/C++ 拡張機能のインターフェイス ルーチンは、次の 2 つの形式でポインタを DHCP サーバに返します。

一連のバイトへの char* ポインタ

(dex.h で定義された)指定された長さの一連のバイトへのポインタを持つ abytes_t という構造へのポインタ

いずれの場合も、拡張機能がその拡張ポイントで実行されている間、DHCP サーバ メモリへのポインタが有効です。それらのポインタは、この要求を処理するシリーズ内の残りの拡張ポイントに対しても有効です。したがって、 post-packet-decode 拡張ポイントに返された abytes_t ポインタは、 post-send-packet 拡張ポイントでも有効です。しかし、このポインタは pre-dns-add-forward 拡張ポイントでは有効ではありません。この拡張ポイントが、要求と応答の処理サイクルの一部ではなく、別のサブシステムで処理されているからです。

ポインタは、環境ディクショナリに保存された情報が有効である限り有効です。しかしこれには 1 つ例外があります。getType という C/C++ ルーチンは、タイプを参照する abytes_t というポインタを返します。これらのポインタは、拡張機能の寿命を通じて有効です。通常は、このルーチンを init-entry 拡張ポイントで呼び出し、タイプを定義する abytes_t 構造へのポインタを共有ライブラリのスタティック データに保存します。 getType によって返される abytes_t 構造へのポインタは、初期化のための init-entry 呼び出しから非初期化のための呼び出しまで有効です。

C/C++ の Init-Entry エントリ ポイント

DHCP サーバは、各拡張機能を設定したときと、それを設定解除したときに 1 回ずつ init-entry 拡張機能を呼び出します。dex.h ファイルは、設定呼び出しと設定解除呼び出しの拡張ポイントとして渡される 2 つの拡張ポイントとして、設定のための DEX_INITIALIZE と設定解除のための DEX_UNINITIALIZE を定義します。拡張データ項目の環境ディクショナリの値は、それぞれの呼び出しで initialize または uninitialize です。

initialize init-entry 拡張ポイントを呼び出しているとき、環境ディクショナリ データ項目 persistent に値 true が含まれていれば、 uninitialize 呼び出しから戻る前であれば、いつでも環境ディクショナリ ポインタを保存し、使用できます。このように、バックグラウンド スレッドは、環境ディクショナリを使用してサーバのログ ファイルにメッセージをロギングできます。同時に複数のスレッドがディクショナリへの呼び出しを行わないように、ディクショナリへのすべてのアクセスをインターロックする必要があります。保存済みのディクショナリ ポインタは、拡張機能が uninitialize 呼び出しから戻る時点まで使用できます。このように、バックグラウンド スレッドが終了時のメッセージをロギングできます。

拡張機能を使用した DHCP 要求処理

Network Registrar DHCP サーバには、独自の拡張機能を追加できる拡張ポイントがあります。それらの拡張ポイントには、処理フローのどこでそれらを使用するかを示すわかりやすい名前が付いています。

拡張ポイントは、DHCP クライアントからの入力要求の処理に関連付けられているので、DHCP サーバが要求を処理する方法を理解するのに役立ちます。DHCP サーバでは、次の段階に従って要求が処理されます。

1. DHCP クライアントからパケットを受信します。

2. パケットをデコードします。

3. クライアントクラス ルックアップ識別子を使用して、クライアントクラスを参照します(クライアントクラスが存在する場合)。

4. 限定的な識別子を含め、クライアントクラスを変更します。

5. クライアントクラスが存在する場合は、それを処理します。

6. 要求から応答コンテナを構築します。

7. 要求の発信元であるネットワークを判別します。

8. このクライアントにすでに関連付けられているリースが存在する場合はそれを検索し、そうでない場合はクライアントに対して新しいリースを手配します。

9. このリースに関連付けられているすべての要求をシリアル化します。

10. この要求がシリアル化キューの先頭に来たときに、このクライアントが(まだ)このリースを使用できるかを判別します。

11. すべてのデータを収集して、応答パケットに保存します。

12. DHCP クライアントに伝送できるように、応答パケットをエンコードします。

13. 必要に応じて、安定した記憶域をアップデートします。

14. パケットを DHCP クライアントに送信します。

これらの手順および拡張機能を使用するその他の機会については、次の項で説明します。拡張ポイントは、 太字 で示します。

パケットの受信

DHCP サーバはポート 67(DHCP 入力ポート)でパケットを受信し、処理のためにキューに追加します。またできるだけ素早く UDP 入力キューを空にするように努めます。受信したすべての要求は内部リストに保存され、それらを処理する空きスレッドができるとすぐに処理されます。これらのキューの長さは設定可能ですが、あらかじめ設定されている長さを超えることはできません。

パケットのデコード

空きスレッドができると、DHCP サーバはそれに入力要求の処理というタスクを割り振ります。DHCP サーバが取る最初のアクションは、入力パケットをデコードして、それが有効な DHCP クライアント パケットであるかを判別することです。このデコード プロセスの一部として、DHCP サーバはすべてのオプションをチェックして、それらが有効であるかどうか、つまり、これらのオプションの長さが要求パケットの全体の文脈から判断して意味があるかを確認します。また DHCP 要求パケットのすべてのデータをチェックしますが、この段階ではパケット内の情報に対しては何のアクションも行いません。

post-packet-decode 拡張ポイントを使用して入力パケットをリライトします。DHCP サーバはこの拡張ポイントを渡した後、パケットのすべての情報を複数の内部データ構造に保存して、後続の処理を効率化します。

クライアントクラスの判別

client-class-lookup-id 内に設定されている式が存在する場合は、この段階で、その式が評価されます(式の説明については、「式の使用方法」を参照)。式の結果は、<null> となるか、それ以外の場合は文字列に変換されます。文字列の値は、クライアントクラス名か <none> です。<none> の場合、サーバは、 client-class-lookup-id が設定されていない場合と同じように、パケットの処理を続けます。<null> 応答または client-class-lookup-id を評価するエラーの場合、サーバはエラー メッセージをロギングし、パケットをドロップします( post-class-lookup 拡張ポイントに設定された拡張機能が、サーバがパケットをドロップしないように特に設定されている場合を除く)。クライアントクラスを設定するプロセスの一環として、そのクライアントクラスについて設定されている limitation-id がすべて評価され、要求とともに格納されます。

クライアントクラスの変更

client-class-lookup-id が評価され、クライアントクラスが設定されると、 post-class-lookup 拡張ポイントに追加されている拡張機能がすべて呼び出されます。その拡張機能を使用すると、 limitation-id を含め、クライアントクラスによって要求に関連付けられたすべてのデータを変更できます。拡張機能はまた、 client-class-lookup-id の評価の結果、パケットがドロップされたかどうかについての情報を受け取ります。拡張機能は、パケットがドロップされたかどうかを確認するだけでなく、必要に応じて、サーバがパケットをドロップしないように指定します。

また、 post-class-lookup 拡張ポイントで実行される拡張機能は、要求に対して新しいクライアントクラスを設定でき、そのクライアントクラスから得られた情報が、現在のクライアントクラスから得られる情報の代わりに使用されます。これは、クライアントクラスを設定することによって、実際にそのクライアントクラスが要求に対して使用されるようになる唯一の拡張ポイントです。

クライアントクラスの処理

クライアントクラスの処理をイネーブルにした場合、DHCP サーバがこの段階でそれを実行します。

pre-client-lookup 拡張ポイントを使用して、ルックアップを阻止したり、既存のデータを上書きするデータを提供したりすることにより、ルックアップされるクライアントに影響を及ぼします。DHCP サーバが pre-client-lookup 拡張ポイントを渡すと、ローカル データベースまたは LDAP データベースが設定されている場合は、(拡張機能が特にそれを禁止していない限り)そのデータベースでクライアントをルックアップします。

サーバはクライアントをルックアップした後、クライアント エントリのデータを使用して追加の内部データ構造に入力します。DHCP サーバは、指定したクライアントクラス エントリ内のデータを使用して、クライアント エントリで指定されていない情報を補完します。DHCP サーバは、すべてのデータを取得し、他の処理で使用できるようにサーバの内部データ構造内のさまざまな場所に格納した後、次の拡張ポイントを実行します。

post-client-lookup 拡張ポイントを使用して、クライアントクラス処理から入力された内部サーバ データ構造を調べるなど、クライアントクラスのルックアップ プロセスの処理を調べます。DHCP サーバが追加の処理を行う前に、任意のデータを変更するためにも使用できます。

応答コンテナの構築

この段階では、DHCP サーバが要求タイプを判別し、適切な応答コンテナを構築します。たとえば、要求が DHCPDISCOVER の場合、サーバは処理を実行するために DHCPOFFER 応答を作成します。入力要求が BOOTP 要求の場合、サーバは応答処理を実行するために BOOTP 応答を作成します。

ネットワークの判別

DHCP サーバは、すべての要求について発信元のサブネットを判別し、それらをアドレス プールのセットまたは IP アドレスを持つスコープにマップする必要があります。

DHCP サーバ内部とは ネットワーク の概念であり、この文脈では LAN セグメント または物理ネットワークを指します。DHCP サーバでは、すべてのスコープが 1 つのネットワークに属します。ネットワーク番号が同一であるという理由で、同じネットワークにグループ化されるスコープもあります。また、プライマリスコープ ポインタによって関連しているという理由でグループ化されるスコープもあります。

Network Registrar DHCP サーバは、DHCP クライアントの処理に使用するネットワークを次の方法で判別します。

ソース アドレスによって判別します。 giaddr 、または giaddr が 0 の場合は、要求が到着したインターフェイスのアドレスを使用します。

このアドレスを使用して、スコープの中から、このアドレスと同じサブネット上のサーバ内に設定されているスコープを検索します。サーバによってスコープが見つからない場合は、要求がドロップされます。

スコープを見つけた後、それ以降の処理にそのネットワークを使用します。

リースの検索

これでネットワークが確立されたので、DHCP サーバはネットワーク レベルに保存されているハッシュ テーブルを検索して、クライアントの client-id が、このネットワークで 既知 であるかを調べます。この文脈で「既知」とは、このクライアントが以前にこのネットワークで提供またはリースを受け取っており、かつそれ以降そのリースが別のクライアントに提供またはリースされていないことを意味します。したがって、現在のリースまたは期限を満了した使用可能なリースが、ネットワーク レベルのハッシュ テーブルに表示されます。DHCP サーバはリースを見つけると、次の手順、つまり、同じ IP アドレスへのすべての要求のシリアル化に進みます。

DHCP サーバがリースを見つけられず、これが BOOTP または DHCPDISCOVER 要求の場合、ネットワーク内のスコープで予約済みのリースを検索します。予約済みのリースが見つかると、サーバはそのスコープとリースがともに受け入れ可能かをチェックします。予約済みのリースとそれを含むスコープは、次の要件を満たす必要があります。

リースが利用可能であること(他の DHCP クライアントにリースされていないこと)

スコープが要求タイプ(BOOTP または DHCP)をサポートしていること

スコープが非アクティブでないこと

リースが非アクティブでないこと

scope-selection タグに、クライアントのすべての selection-criteria が含まれ、クライアントの selection-criteria-excluded が含まれていないこと

スコープが更新専用でないこと

予約済みリースが受け入れ可能であれば、DHCP サーバは次の手順、つまり、その IP アドレスへのすべての要求のシリアル化に進みます。このクライアントの既存のリースまたは予約済みリースが見つからなかった場合、サーバは次にこのクライアントで使用可能なすべての IP アドレスを検索します。

DHCP サーバが採用する一般的なプロセスとしては、このネットワークに関連付けられたすべてのスコープをラウンドロビン順にスキャンし、このクライアントで受け入れ可能であるとともに、使用可能なアドレスを持つスコープを探します。受け入れ可能なスコープには、次の特徴があります。

クライアントに selection-criteria が関連付けられている場合は、scope-selection タグにクライアントのすべての包含基準が含まれている。

クライアントに selection-criteria-excluded が関連付けられている場合は、scope-selection タグにクライアントの除外基準が含まれていない。

スコープがクライアントの要求タイプをサポートしている。クライアントの要求が DHCPREQUEST の場合、スコープが DHCP についてイネーブル化されている必要があります。同様に、要求が BOOTP 要求の場合、スコープが BOOTP とダイナミック BOOTP についてイネーブル化されている必要があります。

更新専用でない。

非アクティブでない。

使用可能なアドレスがある。

受け入れ可能なスコープが見つからない場合、DHCP サーバはメッセージをロギングしてパケットをドロップします。

リース要求のシリアル化

1 つのクライアントとリースについて、複数の DHCP 要求を同時に処理できるので、要求をリースのレベルでシリアル化する必要があります。それらの要求はリースに対するキューに追加され、追加された順に処理されます。

リースの受け入れ可能性の判別

DHCP サーバはここで、リースが(まだ)そのクライアントで受け入れ可能かを判別します。初めてのクライアントが新しく取得したリースの場合は、受け入れ可能になります。しかし、サーバが既存のリースの更新を処理する場合は、リースが許可された後に受け入れ可能性の基準が変更されていることがあるので、再度チェックする必要があります。

クライアントが現在のリースと異なる 予約 を持つ場合は、サーバはまず予約済みのリースが受け入れ可能かを判別します。リリースの受け入れ可能性についての基準は次のとおりです。

予約済みのリースが使用可能なこと

予約済みのリースが非アクティブでないこと

スコープが非アクティブでないこと

要求が BOOTP の場合は、スコープが BOOTP をサポートしていること

要求が DHCP の場合は、スコープが DHCP をサポートしていること

クライアントに selection-criteria がある場合は、scope-selection タグにクライアントのすべての包含基準が含まれていること

クライアントに selection-criteria-excluded がある場合は、scope-selection タグにクライアントのすべての除外基準が含まれていないこと

以前このリースに関連付けられていたクライアントが現在のクライアントと異なる場合は、スコープが更新のみであること

予約されたリースがこれらの基準すべてを満たす場合、DHCP サーバは現在のリースが受け入れ不能だと判断します。このクライアントについて予約されたリースが存在しない場合、または予約されたリースが受け入れ可能性の基準を満たさない場合、DHCP サーバは、 現在の リースの受け入れ可能性を調べます。

受け入れ可能性の基準は次のとおりです。

リースが非アクティブでないこと

スコープが非アクティブでないこと

要求が BOOTP の場合は、スコープが BOOTP をサポートしていること、また、要求が DHCP の場合は、スコープが DHCP をサポートしていること

このリースについての予約がクライアントに存在せず、要求が BOOTP の場合は、スコープがダイナミック BOOTP をサポートしていること

このリースの予約がクライアントに存在しない場合、他のクライアントも予約できないこと

クライアントに selection-criteria がある場合は、scope-selection タグにクライアントのすべての包含基準が含まれていること

クライアントに selection-criteria-excluded がある場合は、scope-selection タグにクライアントのすべての除外基準が含まれていないこと

以前このリースに関連付けられていたクライアントが現在のクライアントと異なる場合は、スコープが更新のみであること

DHCP サーバ プロセスのこの時点で、 check-lease-acceptable 拡張ポイントを使用できます。この拡張ポイントを使用すると、受け入れテストの結果を変更できます。これは、非常に注意して行ってください。

リースを受け入れ不能と判別した場合、DHCP サーバは、現在処理中の具体的な DHCP 要求に応じて異なるアクションを行います。

DHCPDISCOVER:DHCP サーバは、現在のリースをリリースし、このクライアント用に別の受け入れ可能なリースの取得を試みます。

DHCPREQUEST SELECTING:リースが無効なので、DHCP サーバは DHCP クライアントに NACK を送信します。これを受けてクライアントは、すぐに DISCOVER 要求を発行して新しい DHCPOFFER を取得します。

DHCPRENEW、DHCPREBIND:DHCP サーバは DHCP クライアントに NACK を送信して、DHCP クライアントを INIT フェーズにします(DHCP クライアントが DHCPDISCOVER 要求を発行するようにします)。このリースは、クライアントが実際に要求を発行するまで有効です。

BOOTP:DHCP サーバは、現在のリースをリリースし、このクライアント用に別の受け入れ可能なリースの取得を試みます。

check-lease-acceptable 拡張ポイントを使用する場合には、相当な注意が必要です。拡張ポイントから返された答えが、DHCPDISCOVER またはダイナミック BOOTP 要求で実行される使用可能なリースの検索で行われた受け入れ可能チェックの結果と一致しない場合、(次の DHCPDISCOVER または BOOTP 要求ですぐに)無限サーバ ループが生じる可能性があるからです。この場合、サーバは使用可能なリースを新しく取得し、それが受け入れ不能だと判別し、さらに使用可能なリースを新しく取得し、それが受け入れ不能だと判別するというループにずっと入ったままになります。

応答パケット データの収集

この段階の処理で、DHCP サーバは、DHCP 応答によって送信するすべてのデータを収集するとともに、応答の送信先アドレスとポートを判別します。 pre-packet-encode 拡張ポイントを使用して、応答として DHCP クライアントに送信されるデータを変更するか、または DHCP 応答の送信先となるアドレスを変更します。


注意 pre-packet-encode 拡張ポイントでドロップしたすべてのパケットは、DHCP パケットでも BOOTP パケットでも、リース時間が残っている限り、リースされるアドレスが Network Registrar リース データベースに表示されます。このため、もっと早い時点でパケットをドロップすることをお勧めします。

応答パケットのエンコード

この段階で、DHCP は応答データ構造内の情報をネットワーク パケットにエンコードします。この DHCP クライアントで DNS アクティビティが必要な場合、DHCP サーバが、DNS 作業要求を DHCP サーバにある DNS 処理サブシステムのキューに追加します。その要求は可能であればいつでも実行されますが、一般に、パケットをクライアントに送信するまで実行されません。「DNS 要求の処理」の項を参照してください。

安定した記憶域の更新

この段階で、DHCP サーバは、処理を行う前に、IP アドレスに関してディスク上にある情報が最新であることを確認します。

パケットの送信

post-send-packet 拡張ポイントは、DHCP 要求応答サイクルの厳しい時間制約外で実行する処理のために使用します。DHCP サーバはパケットを DHCP クライアントに送信した後、この拡張ポイントを呼び出します。

外部環境への接続に長時間かかる場合、拡張機能はパフォーマンス向上のために別のスレッドを使用する必要があります。DHCP サーバには、要求処理のためのスレッドが限られた数しかないので、一部または(最悪の場合)すべてのスレッドが何らかの外部条件のために拡張機能で待ち状態に陥ると、DHCP サーバのパフォーマンスが低下します。どの程度の待ち時間が長すぎるかについての明確な指針はありませんが、一般に、拡張機能が 2、3 秒以内に終了するのであれば、DHCP サーバのパフォーマンスに影響はありません。3 秒を超えるようなら、明らかに長すぎます。したがって、要求を拡張機能の内部キューに追加し、制御がすぐに戻るように拡張機能を構成する必要があります。このキューの処理には、拡張機能が所有する別のスレッドを使用します。

C/C++ 拡張機能の init-entry ルーチンへの初期化呼び出しには、別のスレッドを作成することができます。その場合は、対応する init-entry uninitialization 呼び出しにあるスレッドを必ず破壊します。

通常、キューを処理するスレッドが実行されるまでに、C/C++ に返されたポインタが無効になっているので、要求を後で処理するために内部キューに追加するときは、ディクショナリの get 要求によって返されたデータをコピーします。

DNS 要求の処理

DHCP サーバは、DNS 作業項目要求を処理するために次の操作を行います。

1. A レコードに使用する名前の構築:DHCP サーバは、転送(A レコード)DNS 要求で使用する名前を作成します。

2. この時点で、 pre-dns-add-forward 拡張ポイントを使用して、DNS 転送(A レコード)要求に使う名前を変更します。

3. 名前がまだ存在しないことをアサートして名前の追加を試みます。この段階では、DNS 名アップデート要求の前提条件として、名前が存在しないことが必要です。これに成功すると、DHCP サーバは次のタスクとして、逆レコードのアップデートに進みます。

4. 名前が DHCP サーバによって供給されることをアサートして名前の追加を試みます。DHCP サーバはそのホスト名が存在し、すでに送信されたレコードと同じ TXT レコードを持っていることをアサートしてホスト名の追加を試みます。これに成功すると、サーバは次のタスクとして、逆レコードのアップデートに進みます。失敗した場合、サーバはその命名のリトライ回数を使い切ってしまったかをチェックします。リトライ回数に残りがない場合、終了してエラーがロギングされます。残りがある場合は、最初の手順である A レコードの名前の構築に戻ります。

5. 逆レコードのアップデート:これで DHCP サーバは、どの名前に逆(PTR)レコードを関連付けるかがわかり、それがレコードの所有者だと想定できるので、前提条件なしに逆レコードをアップデートできます。アップデートができない場合は、DHCP サーバがエラーをロギングします。

リース状態の変化のトレース

lease-state-change 拡張ポイントは、リースの状態が変化したときに呼び出されます。既存の状態は、応答ディクショナリの lease-state データ項目にあります。新しい状態は、環境ディクショナリの new-state にあります。new-state が既存の状態と等しくなることはありません(この場合拡張機能は呼び出されません)。この拡張機能は、読み取り専用と考える必要があります。ディクショナリ項目はサーバのあらゆる場所から呼び出されるので、変更を加えないでください。この拡張ポイントは、リースの状態の変化をトレースするためだけの目的で使用します。

拡張ディクショナリ

すべての拡張機能は、3 つの引数を持つルーチンとして定義されます。これらの引数とは、要求ディクショナリ、応答ディクショナリ、環境ディクショナリです。すべての拡張機能ですべてのディクショナリが使用できるわけではありません。拡張ポイントとそれらで使用できるディクショナリについて、拡張ポイントとディクショナリ に示します。

 

表28-1 拡張ポイントとディクショナリ

拡張ポイント
ディクショナリ

check-lease-acceptable

要求、応答、環境

init-entry

環境

post-packet-decode

要求、環境

pre-client-lookup

要求、環境

post-client-lookup

要求、環境

post-class-lookup

要求、環境

check-lease-acceptable

要求、応答、環境

lease-state-change

応答、環境

pre-packet-encode

要求、応答、環境

pre-dns-add-forward

環境

post-send-packet

要求、応答、環境

これら 3 つのディクショナリは、名前と値のペアで構成されます。環境ディクショナリは、すべての拡張ポイントで使用できる最も単純なディクショナリです。これは、名前と値のペアのセットで構成され、名前と値はともに文字列です。要求ディクショナリと応答ディクショナリはそれよりも複雑で、データはタイプ分けされています。そのため、これらのディクショナリのいずれかに値を設定するときは、データ タイプを値に合せる必要があります。ディクショナリは、値の取得、追加、および削除に使用します。

環境ディクショナリ

環境ディクショナリは、すべての拡張ポイントで使用できます。これは、名前と値のペアのセットで厳格に構成され、名前と値はともに文字列です。

DHCP サーバは環境ディクショナリを使用して、異なる拡張ポイントで異なる方法を使用して拡張機能と通信できます。拡張ポイントによっては、サーバが情報を環境ディクショナリに保存し、拡張機能がそれを変更する場合があります。また、拡張機能が環境ディクショナリに値を保存し、拡張機能が処理を終了した後、フローやデータを制御する場合もあります。

環境ディクショナリは、拡張機能が任意の名前と値のペアを追加できる点が特徴です。ドキュメント化されていない名前と値を使用してもエラーは発生しませんが、サーバがそれらを認識できません。

DHCP サーバは、DHCP 要求が到着したときに環境ディクショナリを作成し、ディクショナリは処理の間その要求とともに残ります。したがって、 post-packet-decode 拡張ポイントで実行される拡張機能がデータを環境ディクショナリに追加でき、 pre-packet-encode 拡張ポイントで実行される拡張機能がその情報をこのディクショナリから読み取ることができます。


) 拡張ポイント pre-dns-add-forward には環境ディクショナリがありますが、これは他の拡張ポイントが使用する環境ディクショナリと同じではありません。拡張ポイント init-entry にあるのも、独自の環境ディクショナリのみです。


環境ディクショナリのデータ項目

次のデータ項目は、環境ディクショナリで常に有効です。

drop (読み取り/書き込み):拡張機能の終了時に、 drop の値が文字列 true に等しい場合、DHCP サーバは入力パケットをドロップし、メッセージをログ ファイルにロギングします。

extension-name (読み取り専用):拡張機能の設定に使用した名前。コードの同じ部分を、複数の異なる拡張機能として、複数の異なる拡張ポイントに設定できます。この設定により、同じコードをその設定方法に応じて異なる目的に使用できます。コードはまたこの文字列を使用して extension-name-sequence 文字列の中でそれ自体の名前を検索できます。これにはそれ自体の名前を知る必要があります。

extension-name-sequence (読み取り専用):この拡張ポイントの設定を表すカンマで区切られた文字列にマップします。これにより拡張機能は、それが動作する環境を判別できます。この拡張ポイントに対して設定したすべての拡張機能は、シーケンシャル順にリストし、カンマで区切る必要があります。シーケンスの中で拡張機能が設定されていない位置は、カンマを並べて示す必要があります。たとえば、 tclfirst をシーケンスの先頭位置として設定し、 dexscript をシーケンスの 5 番目の位置として設定するには、 tclfirst,,,,dexscript を使用します。

extension-point (読み取り専用):拡張ポイントの名前。この名前が拡張機能で使用できるようになるので、1 つの拡張機能が複数の拡張ポイントで実行できるとともに、どのポイントから呼び出されたかを判別できます。たとえば、 post-packet-decode などです。

extension-sequence (読み取り専用):この拡張ポイントでのこの拡張機能のシーケンス番号である文字列。

log-drop-message (読み取り/書き込み):拡張機能の終了時に、 drop の値が文字列 true に等しく、 log-drop-message の値が文字列 false に等しい場合、DHCP サーバは入力パケットをドロップしますが、メッセージをログ ファイルにロギングしません。要求ディクショナリを持つすべての拡張ポイントで、 log verbose-logging が頭に付くデータ項目は、いつでも設定できます。DHCP サーバは必要に応じてそれらを読み取ります。

trace-level (書き込み専用):これに数値を設定すると、この要求を処理するすべての拡張機能について、その数値が extension-trace-level サーバ アトリビュートの現在の設定になります。

user-defined-data (読み取り/書き込み):要求が処理される前に、リースと一緒に格納されたリースの user-defined-data アトリビュートを使用して設定されます。 pre-packet-encode にディスクに書き込むことができます。ヌルに設定された場合、リースからの user-defined-data は無視されます。このデータ項目は、すべての要求について書き込むことができるわけではありません(特に pre-packet-encode 拡張ポイントと post-packet-encode 拡張ポイントの場合)。

初期環境ディクショナリ

init-args init-entry を使用して拡張機能を設定できます。その代わりに、拡張機能の設定情報を指定して、環境ディクショナリから読み取ることもできます。DHCP プロパティ
initial-environment-dictionary は、一連のアトリビュートと値のペアを使用して設定でき、各ペアはすべての環境ディクショナリで使用できます。この機能を使用すると、さまざまな設定やカスタマイズした情報が指定できます。あらゆる拡張機能が環境ディクショナリから直接簡単に読み取れ、 init-args init-entry を使用したアプローチと違って、スタティック データ領域に保存する必要がありません。

initial-environment-dictionary のアプローチを使用して定義した値は、あらゆる環境ディクショナリから読み取れます。また、 initial-environment-dictionary に表示される任意のアトリビュートに対して、新しい値を定義することもできます。これらの新しい値は、環境ディクショナリの寿命を通じて(通常、要求パケットが処理されている寿命の間)使用可能です。ただし、これによって他の環境ディクショナリの内容が変更されるわけではありません。新しい環境ディクショナリ(異なる要求と関連付けられている)は、DHCP サーバの initial-environment-dictionary プロパティによって定義されるアトリビュートと値のペアを参照します。

加えて、 initial-environment-dictionary で定義されたこれらのアトリビュートと値のペアは、環境ディクショナリの値列挙に表示されません。これらのペアが使用できるのは、環境ディクショナリに現在定義されていないアトリビュート値を要求した場合のみです。アトリビュートと値のペアは、環境ディクショナリに実際に表示されません。したがって、アトリビュートのいずれかに対して新しい値を定義すると、新しい値が環境ディクショナリに表示されます。後にその値を削除し、そのアトリビュート値を要求すると、元の値が提供されます。

要求ディクショナリと応答ディクショナリ

これらのディクショナリには、規定のセットのアクセス可能な名前があります。しかし、すべての名前がすべての拡張ポイントからアクセス可能なわけではありません。これらのディクショナリによって、拡張機能が、内部サーバ データ構造に読み取りと書き込みアクセスまたは場合によっては読み取り専用アクセスできます。それぞれのデータ項目には特定のデータ タイプがあります。put 操作で正しいデータ タイプを省略した場合(C/C++ 拡張機能)、または DHCP サーバがそれを正しいデータ タイプに変換できない場合(TCL 拡張機能)、拡張機能でエラーが発生します。

要求ディクショナリは、要求を処理し始めるときに使用できます。DHCP サーバが要求を作成すると、要求ディクショナリと応答ディクショナリが使用可能になります。応答ディクショナリが使用可能になる前にアクセスするのは誤りです。

一般に、サーバで設定可能な情報は、拡張機能を使用して変更できません。場合によっては、設定済みの情報を拡張機能を使用して変更できますが、その変更はその 1 つの要求について処理の間だけ有効です。

デコード済みの DHCP パケット データ項目

DHCP プロトコルは、UDP ベースの要求と応答のプロトコルであり、DHCP サーバ操作を開始するのは、通常、クライアントからの DHCP 要求です。また結果は通常、そのクライアントに返信される DHCP 応答です。

DHCP 拡張機能によって、ほとんどの拡張ポイントにある拡張機能が、DHCP 要求への情報入力を使用できるようになり、 pre-packet-encode 拡張ポイントで使用可能な DHCP 要求に対する応答として情報を送信できるようになります。

この DHCP パケットベースの情報に加え、DHCP 要求の処理時に DHCP サーバが使用する追加情報があります。この情報は、DHCP サーバのアーキテクチャの一部として、DHCP 要求または DHCP 応答のいずれかに関連付けられます。この情報の多くは、拡張機能でも使用できるようになり、その多くが読み取りと書き込みの両方が可能です。これは多くの場合、DHCP サーバの処理アルゴリズムを変更します。

したがって、要求ディクショナリと応答ディクショナリは、それぞれのディクショナリに 2 クラスの情報を含みます。含まれるのは、デコード済みのパケット データとその他の要求または応答に関連するデータ項目です。デコード済みのパケット データ項目とは、DHCP 要求または DHCP 応答に直接含まれる、またはそれから派生したデータ項目です。デコード済みパケット データ項目にアクセスすることで、DHCP 要求および DHCP 応答パケットの読み取りと、場合によってはリライトが可能です。図28-3 は、要求ディクショナリと応答ディクショナリの関係を示しています。

図28-3 拡張機能の要求ディクショナリと応答ディクショナリ

 

情報には、要求ディクショナリのデコード済みのパケット データ項目を使用して、 giaddr ciaddr などの DHCP 要求パケットから、およびすべての着信 DHCP オプションからアクセスできます。同様に、応答ディクショナリのデコード済みパケット データ項目にアクセスすることによって、 ciaddr giaddr を設定したり、発信 DHCP 応答で DHCP オプションを追加、削除したりできます。

デコード済みのパケット データ項目によって提供されるパケット情報すべてにアクセスできるわけではないことに注意してください。各拡張ポイントの説明には、その拡張ポイントで使用可能なデータ項目がリストされています。デコード済みのパケット データ項目は常にグループとしてアクセス可能なので、それらはグループとしてリストされます。表B-2 を参照してください。

DHCP オプションには名前によってアクセスします。このオプションが存在しない場合、そのオプションに対してデータが返されません。デコード済みの要求またはデコード済みの応答にオプションを配置すると、既存のデータを残したままデータを追加するように put 操作で特に指定されていない限り、デコード済みの要求またはデコード済みの応答内にすでに存在する同じ名前のオプションが、配置したオプションによって置き換えられます。

DHCP オプションの中には、複数の値を持つオプションもあります。たとえば、ルータ オプションに、1 つ以上の IP アドレスが関連付けられている場合があります。これら複数の値は、オプション名に対してインデックス付きの操作を使用してアクセスします。


) 要求または応答ディクショナリに clear 操作を行うと、デコード済みのパケットにあるすべてのオプションが削除されます。


パラメータ リスト オプションの使用

dhcp-parameter-request-list というオプションがあり、特に次の 2 つの方法で使用します。

dhcp-parameter-request-list という名前の、複数値を持つバイト オプションとして使用できます。

dhcp-parameter-request-list-blob という名前の、blob 値(バイトのシーケンス)を持つオプションとしても使用できます。

get または put 操作はいずれかの名前を使用して行います。DHCP サーバは、
dhcp-parameter-request-list
(およびその blob バージョン)の応答ディクショナリでの扱いが、要求ディクショナリでの扱いと異なります。要求ディクショナリでアクセスする場合、このオプションは、要求ディクショナリのもう 1 つの DHCP オプションに過ぎません。しかし応答ディクショナリでは、特別な処理が行われます。

応答ディクショナリで dhcp-parameter-request-list オプションを使用して、DHCP または BOOTP クライアントに返されるオプションの順序を制御できます。応答ディクショナリでオプションを put すると、オプションにリストされている既存のオプションを先頭としてリストに表示される順番になるように、DHCP サーバが既存のオプションを並べ替えます。次に、リストにあった最後のオプションの後に、残りのオプションが現在の順序で表示されます。DHCP サーバは新しいリストで置き換えられるまでこのリストを維持し、後でオプションが応答に put された場合に、このリストを使用してそのオプションの順序を決定します。

拡張機能は応答ディクショナリの dhcp-parameter-request-list に対して get 操作を行うとき、デコード済みの応答パケットを調べてオプションを見つけることはしません。その代わりに、DHCP サーバが、デコード済みの応答パケットに現在存在するすべてのオプションのリストを含むものを合成します。

拡張ポイントの説明

ここでは、拡張ポイントとそれらのアクション、およびデータ項目について説明します。すべての拡張ポイントについて、 extension-point を表示し、環境ディクショナリに trace-level データ項目の値を設定できます。ほとんどの拡張ポイントで、サーバがパケットをドロップするように指示することもできます。

post-packet-decode

post-packet-decode に使用可能なディクショナリは、要求ディクショナリと環境ディクショナリです。

この拡張ポイントは、要求が到着したときに DHCP サーバが最初に検出する拡張ポイントです。この拡張ポイントの直後に入力パケットのデコードが行われ、続いてパケットのデータに対する処理が行われます。この時点における拡張機能の主なアクティビティは、入力パケットの情報を読み取ってそれに何らかの処理を行うことです。たとえば、この拡張ポイントを使用して入力パケットをリライトできます。

post-packet-decode 拡張ポイントは、最も簡単に使用できる拡張ポイントの 1 つです。サーバ動作の変更が、入力 DHCP または BOOTP パケットのリライトとして表現できる場合は、この拡張ポイントを使用する必要があります。パケットはすでにデコードされていますが、何も処理されていないので、副作用は非常に限られています。

post-packet-decode 拡張ポイントはデコード済みの入力パケットを変更できる唯一のポイントなので、すべての変更点が網羅されているかを確認する必要があります。拡張機能がパケットをドロップし、それ以降の処理を終了する場合、環境ディクショナリの drop データ項目を使用してそれを行います。

表28-2 に、 post-packet-decode 要求ディクショナリで使用できるデータ項目のリストを示します。

 

表28-2 post-packet-decode 要求ディクショナリのデータ項目

要求ディクショナリのデータ項目
操作

client-ipaddress

IP アドレス

読み取り/書き込み

client-port

整数

読み取り/書き込み

os-type

文字列

読み取り/書き込み

release-by-ip

整数

読み取り/書き込み

transaction-time

整数

読み取り専用

post-class-lookup

post-class-lookup に使用可能なディクショナリは、要求ディクショナリと環境ディクショナリです。

この拡張ポイントが呼び出されるのは、 client-class-lookup-id が存在する場合だけです。それ以外は、 post-packet-decode と同様です。この拡張ポイントは client-class-lookup-id を評価した後に呼び出され、このクライアントのクライアントクラス情報を設定します。この拡張ポイントには、 post-packet-decode 拡張ポイントと同じディクショナリがあります。

この拡張ポイントへの入力時に、環境ディクショナリは drop データ項目を true または false に設定します。これは拡張機能によって変更することでパケットをドロップするかどうかを設定でき、その変更が認識されます。また log-drop-message を調べて、ドロップをロギングするかどうかを決定します。

この拡張ポイントはまた環境ディクショナリで client-class-name を設定して、以前のクライアントクラスと無関係に、指定したクライアントクラスをこのパケットに対して設定することもできます。これが有効なのは、 drop 環境ディクショナリのデータ項目が、既存の拡張ポイントに対して false に設定されている場合のみです。

pre-client-lookup

pre-client-lookup に使用可能なディクショナリは、要求ディクショナリと環境ディクショナリです。

この拡張ポイントを使用できるのは、DHCP サーバについて、クライアントクラス処理をイネーブルにした場合だけです。この拡張ポイントを使用すると、拡張機能が次のアクションのどれでも、またはすべてを実行できます。

クライアントクラス処理時にルックアップするクライアントを変更する。

現在のエントリやそれが指定するクライアントクラスから検出されたデータ項目を上書きするための個々のデータ項目を指定する。

サーバがクライアントのルックアップをすべて省略するように設定する。この場合、使用されるクライアント データは、拡張機能が環境ディクショナリに提供したデータのみです。

この拡張ポイントで実行される拡張機能の操作については、要求ディクショナリを使用して決定できますが、環境ディクショナリを使用するとすべての操作が制御されます。

pre-client-lookup の環境ディクショナリ

次の項目は、 pre-client-lookup でクライアントクラスの制御に使用できます。

client-specifier (読み取り/書き込み):クライアントクラスの処理コードが、MCD または LDAP においてルックアップするクライアントの名前。クライアント名をこの拡張ポイントで変更すると、DHCP サーバがクライアントについての指定をルックアップします。

default-client-class-name (読み取り/書き込み):次の場合に、サーバが default-client-class-name オプションに指定されている値を class-name として使用するように指示します。

client-specifier データ項目が pre-client-lookup スクリプトで指定されていない場合

特定のクライアント エントリの場所が特定できない場合

default-client-class-name データ項目は、デフォルト クライアントに関連付けられている クラス名 に優先すると想定されます。

release-by-ip (読み取り/書き込み):リースが client-id (DHCPRELEASE 要求から派生)によって取得できない場合に、サーバが IP アドレスによってリースをリリースするように指示します。

skip-client-lookup (読み取り/書き込み):この項目を true に設定すると、DHCP サーバは、この拡張機能の終了直後に実行する正常クライアント ルックアップを省略します。この場合、このクライアントの記述に使用されるデータ項目は、環境ディクショナリに配置されたデータ項目のみです。

user-defined-data (読み取り/書き込み):要求が処理される前に、リースと一緒に格納されたリースの user-defined-data アトリビュートを使用して設定されます。ヌルに設定された場合、 user-defined-data は無視されます。

pre-client-lookup へのクライアントクラス データの入力

次のデータ項目を設定すると、クライアント ルックアップ(内部データベース内または LDAP からの)によって決定された値が、設定した値で上書きされます。ディクショナリに何も追加しない場合、サーバはクライアント値に入っている値、つまりキーを使用します。

host-name (読み取り/書き込み):これは、入力パケットで指定された host-name オプション、またはクライアントやクライアントクラス エントリによるデータに優先するクライアントについて使用します。これを none に設定すると、DHCP サーバはクライアントやクライアントクラス エントリによる情報を使用せず、クライアントの要求による名前を使用します。

domain-name (読み取り/書き込み):このドメイン名は、スコープで指定したドメイン名に優先するクライアントの DNS 操作について使用します。スコープ内でドメインのプライマリ サーバとして表示される DNS サーバは、指定したドメインのプライマリ サーバでもある必要があります。クライアントまたはクライアントクラス エントリでドメイン名の上書きがない場合、DHCP サーバはスコープのドメイン名を使用します。クライアント エントリまたは拡張機能に none という語が含まれている場合、DHCP サーバはスコープのドメイン名を使用します。

policy-name (読み取り/書き込み):このポリシーを、クライアント エントリに対して指定されたポリシーとして使用し、そのクライアント エントリによって指定されたすべてのポリシーを上書きします。

action (読み取り/書き込み):この文字列を数値に変換し、その結果をアクションとして使用します。使用できる数値は、 0x1 (除外)および 0x2 (ワンショット)です。

selection-criteria (読み取り/書き込み):カンマで区切られた文字列のリストで、各文字列はこのクライアントのスコープ選択基準を(この入力パケットについて)指定します。このクライアントが使用するスコープは、これらの scope-selection タグをすべて持っている必要があります。

このデータ項目は、クライアントまたはクライアントクラス エントリで指定された基準を上書きする場合に使用します。これを使用すると、クライアント エントリのスコープ選択基準がローカルまたは LDAP データベースのどちらに格納されているかとは無関係に、DHCP サーバはそのスコープ選択基準を使用しません。これを none に設定すると、DHCP サーバはこのパケットに scope-selection タグを使用しません。これをヌル文字列に設定すると、DHCP サーバはそれを設定されていない場合と同様に扱って、クライアントまたはクライアントクラス エントリのスコープ選択基準を使用します。

selection-criteria-excluded (読み取り/書き込み):カンマで区切られた文字列のリストで、各文字列はこのクライアントの除外基準を(この入力パケットについて)指定します。このクライアントが使用するスコープには、これらの選択タグが存在してはなりません。

このデータ項目は、指定されたクライアントまたはクライアントクラス エントリを上書きする場合に使用します。これを使用すると、クライアント エントリのスコープ除外基準がローカルまたは LDAP データベースのどちらに格納されているかとは無関係に、DHCP サーバはそのスコープ除外基準を使用しません。これを none に設定すると、DHCP サーバは、このパケットに scope-exclusion タグを使用しません。これをヌル文字列に設定すると、DHCP サーバはそれを設定されていない場合と同様に扱って、クライアントまたはクライアントクラス エントリのスコープ除外基準を使用します。

client-class-name (読み取り/書き込み):このデータ項目によって指定されるクライアントクラスは、クライアント エントリで欠けている情報を補うために使用します。指定した名前に対応するクライアントクラスが存在しない場合は、DHCP サーバが警告をロギングして処理を続行します。 none を指定すると、DHCP サーバは、このクライアント エントリにクライアントクラス名が指定されていない場合と同様に動作します。

authenticate-until (読み取り/書き込み):1970 年 1 月 1 日からの経過時間を秒数で計測した絶対時刻。クライアント認証の期限が満了する時刻を示すために使用します。クライアント認証の期限が満了すると、DHCP サーバは、クライアントクラスではなく、クライアントの unauthenticated-client-class オプションに指定された値を使用して、クライアント エントリの欠けているデータ項目を補完します。

unauthenticated-client-class-name (読み取り/書き込み):クライアントが認証されていない場合に使用するクライアントクラスの名前。 unauthenticated-client-class-name が指定されていないことを示す場合は、このデータ項目の値として無効なクライアントクラスの名前を使用します。値 none を使用することも、クライアントクラス名でない名前を使用することもできます。DHCP サーバは、クライアントクラスが存在しないというエラーをロギングします。

user-defined-data (読み取り/書き込み):要求が処理される前に、リースと一緒に格納されたリースの user-defined-data アトリビュートを使用して設定されます。ヌルに設定された場合、 user-defined-data は無視されます。

pre-client-lookup の要求ディクショナリ

表28-3 で説明するデコード済みのパケット データ項目は、すべてが使用可能です。 pre-client-lookup 拡張ポイントに対して使用できる要求情報のデータ項目は、 client-ipaddress client-port 、および transaction-time です(表28-2を参照)。 表28-3 ではこの拡張ポイントで使用可能なクライアント情報のデータ項目、 表28-4 ではクライアント理解データ項目について、それぞれ説明します。

 

表28-3 pre-client-lookup 要求ディクショナリのクライアント情報のデータ項目

クライアント情報のデータ項目
操作

client-id

blob

読み取り/書き込み

client-id-created-from-mac-address

整数

読み取り専用

client-mac-address

blob

読み取り/書き込み

client-os-type

文字列

読み取り/書き込み

mac-address

blob

読み取り/書き込み

 

表28-4 pre-client-lookup 要求ディクショナリのクライアント理解データ項目

クライアント理解データ項目
操作

client-wants-nulls-in-strings

整数

読み取り/書き込み

import-packet

整数

読み取り/書き込み

reply-to-client-address

整数

読み取り/書き込み

post-client-lookup

post-client-lookup に使用できるディクショナリは、要求ディクショナリと環境ディクショナリです。

この拡張ポイントを使用すると、クライアントクラス処理操作全体の結果を検査し、それらの結果に基づいて措置を講じることができます。たとえば、それを使用して結果の一部をリライトしたり、パケットをドロップしたりします。 post-client-lookup 拡張ポイントで実行されている拡張機能のクライアントクラス処理から返されたパケット内のホスト名を上書きするには、ホスト名を要求ディクショナリの client-requested-host-name データ項目に設定します。この操作により、Network Registrar は、データ項目で指定した文字列がパケットに指定されている場合と同様に、そのサーバを参照します。

また、この拡張ポイントを使用して、環境ディクショナリにデータ項目を設定し、 pre-packet-encode 拡張ポイントで実行されている拡張機能の処理に対し、応答パケットに別のオプションをロードしたり、他の措置を講じたりといった影響を与えることもできます。

post-client-lookup の環境ディクショナリ

post-client-lookup では、次の環境ディクショナリ データ項目が使用できます。

client-specifier (読み取り専用):クライアントクラスの処理の中でルックアップするクライアントの名前。

cnr-ldap-query-failed (読み取り専用):DHCP サーバは、LDAP サーバの障害からの回復を容易にするために、このアトリビュートを設定します。その結果、post-client-lookup スクリプトが LDAP サーバの障害に対応できるようになります。DHCP サーバは、クライアントのルックアップの後 LDAP サーバのエラーが原因で LDAP クエリーが失敗した場合に、このフラグを true に設定します。サーバが LDAP サーバから応答を受け取ると、次の 2 つの状況のいずれかが発生します。

フラグが false に設定される。

cnr-ldap-query-failed アトリビュートが、環境ディクショナリに表示されない。

user-defined-data (読み取り/書き込み):要求が処理される前に、リースと一緒に格納されたリースの user-defined-data アトリビュートを使用して設定されます。ヌルに設定された場合、リースからの user-defined-data は無視されます。

post-client-lookup の要求ディクショナリ

表28-5 で説明するデコード済みのパケット データ項目は、すべてが使用可能です。 post-client-lookup 拡張ポイントで使用可能な要求情報のデータ項目は、 client-ipaddress client-port 、および
transaction-time
です(表28-2を参照)。クライアント情報のデータ項目は、 pre-client-lookup 拡張ポイントの場合と同じです(表28-3を参照)。 表28-5 は、クライアント理解データ項目を示しています。

 

表28-5 post-client-lookup 要求ディクショナリのクライアント理解データ項目

クライアント理解データ項目
操作

client-class-name

文字列

読み取り専用

client-class policy

文字列

読み取り/書き込み

client-domain-name

文字列

読み取り/書き込み

client-host-name

文字列

読み取り/書き込み

client-policy

文字列

読み取り/書き込み

client-requested-host-name

文字列

読み取り/書き込み

client-wants-nulls-in-strings

整数

読み取り/書き込み

import-packet

整数

読み取り/書き込み

reply-to-client-address

整数

読み取り/書き込み

selection-criteria

文字列

読み取り/書き込み

selection-criteria-excluded

文字列

読み取り/書き込み

check-lease-acceptable

check-lease-acceptable に使用可能なディクショナリは、要求、応答、および環境の各ディクショナリです。

この拡張ポイントには、現在のリースをこのクライアントで受容できるかどうかをサーバが判別した直後に到達します。この拡張機能を使用すると、その操作の結果を検査し、ルーチンが別の結果を返すようにすることができます。「リースの受け入れ可能性の判別」を参照してください。

acceptable データ項目は、この拡張ポイントの環境ディクショナリで使用できます。これは読み取りと書き込みのデータ項目であり、リースがこのクライアントで受け入れ可能かどうかに応じて、DHCP サーバが初期化します。この結果は、拡張機能を使用して読み込みや変更ができます。受け入れ可能なデータ項目を true に設定すると、それが受け入れ可能であることが示され、 false に設定すると、受け入れ不能であることが示されます。

pre-packet-encode で使用可能なすべての要求データ項目は、 check-lease-acceptable で使用可能です。

pre-packet-encode に使用できるすべての応答ディクショナリ データ項目は、 check-lease-acceptable に使用でき、加えて client-os-type データ項目も使用できます。これは読み取り/書き込みデータ項目であり、拡張機能を使用して読み取りと変更ができます。ただし、 client-os-type データ項目の設定は、 post-packet-decode 要求ディクショナリで os-type データ項目を変更することによってのみ可能です。

lease-state-change

lease-state-change に使用可能なディクショナリは、応答ディクショナリと環境ディクショナリです。

この拡張ポイントは、リースの状態が変更されたときに必ず呼び出されます。既存の状態は、応答ディクショナリの lease-state というリース情報のデータ項目にあります( 表28-7 を参照)。新しい状態は、環境ディクショナリのデータ項目 new-state にあります。新しい状態が既存の状態と同一の場合、この拡張ポイントは呼び出されません。

この拡張ポイントは主に読み取り専用で役立ちますが、データを環境ディクショナリに設定し、それを他の拡張ポイントが取得することもできます。

lease-state-change の応答ディクショナリ

lease-state-change 拡張ポイントには、 pre-packet-encode と同じ応答ディクショナリ データ項目がありますが、有用度が高いのはクライアント情報とリース情報のデータ項目だけです( 表28-6 および 表28-7 を参照)。この拡張ポイントでは、応答パケットが伝送されないことが多いので、応答ディクショナリのオプションやエンコード済みのパケット データ項目(たとえば、 giaddr ciaddr )にアクセスしないでください。

 

表28-6 lease-state-change 応答ディクショナリのクライアント情報のデータ項目

クライアント情報のデータ項目
操作

client-domain-name

文字列

読み取り/書き込み

client-expiration-time

blob

読み取り専用

client-host-name

文字列

読み取り/書き込み

client-id

blob

読み取り/書き込み

client-id-created-from-mac-address

整数

読み取り専用

client-mac-address

blob

読み取り/書き込み

client-requested-host-name

文字列

読み取り/書き込み

domain-name-changed

整数

読み取り/書き込み

host-name-changed

整数

読み取り/書き込み

host-name-in-dns

整数

読み取り/書き込み

last-transaction-time

整数

読み取り専用

mac-address

blob

読み取り/書き込み

reverse-name-in-dns

整数

読み取り/書き込み

 

表28-7 lease-state-change 応答ディクショナリのリース情報のデータ項目

リース情報のデータ項目
操作

lease-deactivated

整数

読み取り専用

lease-ipaddress

IP アドレス

読み取り専用

lease-reserved

整数

読み取り専用

lease-state

文字列

読み取り専用

start-time-of-state

整数

読み取り専用

lease-state-change の環境ディクショナリ

現在の状態は、応答ディクショナリの lease-state リース情報のデータ項目にあり(表28-7を参照)、変更後の状態は、環境ディクショナリの new-state データ項目にあります。これはすべて読み取り専用です。

この拡張ポイントに追加されているスクリプトの初期化エントリ ポイントでは、終了時に環境ディクショナリにアトリビュート exiting-state があると、そのアトリビュートの値が保存され、スクリプトはリースがその状態から 別の状態に 移行するときにのみ呼び出されます。したがって、 exiting-state leased に設定すると、既存の状態がリース済みで、かつ新しい状態がそれ以外の場合のみ拡張ポイントが呼び出されます。他の方法で他のリースが移行するのを検出したが(たとえば、 post-send-packet 拡張ポイント)、本当に意図する移行以外、この拡張ポイントを呼び出すオーバーヘッドをかけたくない場合に、このように設定することができます。

有効なリース状態は次のとおりです。

available

offered

leased

expired

unavailable

released

other-available

pending-available

これらの状態についての厳格な状態移行テーブルはありません。フェールオーバー環境では、通常、バインディング アップデート メッセージを受け取ったサーバが、特定の状態の移行を行うことなく、相手側サーバの指示に従って状態を設定します。

pre-packet-encode

pre-packet-encode に使用可能なディクショナリは、要求、応答、および環境の各ディクショナリです。

pre-packet-encode の要求ディクショナリ

表28-8 で説明するデコード済みのパケット データ項目は、すべてが使用可能です。
pre-packet-encode
拡張ポイントで使用可能な要求情報のデータ項目は、 client-ipaddress client-port 、および transaction-time です(表28-2を参照)。 表28-8 に、クライアント情報のデータ項目を示します。クライアント理解データ項目は、 post-client-lookup 拡張ポイントの場合と同じです(表28-5を参照)。

 

表28-8 pre-packet-encode クライアント情報のデータ項目

クライアント情報のデータ項目
操作

client-id

blob

読み取り/書き込み

client-id-created-from-mac-address

整数

読み取り専用

client-macaddress

blob

読み取り/書き込み

mac-address

blob

読み取り/書き込み

pre-packet-encode の応答ディクショナリ

表28-9 で説明するデコード済みのパケット データ項目は、すべてが使用可能です。 pre-packet-encode 拡張ポイントには、次の応答ディクショナリのデータ項目があります。

一般: 表28-9 を参照してください。

クライアント情報: 表28-10 を参照してください。

リース情報:表28-11 を参照してください。

スコープ アドレス情報:表28-12 を参照してください。

スコープ受け入れ可能性情報:表28-13 を参照してください。

スコープ DNS 情報:表28-14 を参照してください。

 

表28-9 pre-packet-encode 応答ディクショナリのデータ項目

応答ディクショナリのデータ項目
操作

auto-configure

整数

読み取り/書き込み

reply-ipaddress

IP アドレス

読み取り/書き込み

reply-port

整数

読み取り/書き込み

scope-ping-clients

整数

読み取り専用

scope-renew-only

整数

読み取り専用

scope-renew-only-expire-time

整数

読み取り専用

scope-selection-tags

文字列

読み取り専用

scope-send-ack-first

整数

読み取り専用

transaction-time

整数

読み取り専用

 

表28-10 pre-packet-encode クライアント情報のデータ項目

クライアント情報のデータ項目
操作

client-domain-name

文字列

読み取り/書き込み

client-expiration-time

blob

読み取り専用

client-host-name

文字列

読み取り/書き込み

client-id

blob

読み取り/書き込み

client-id-created-from-mac-address

整数

読み取り専用

client-mac-address

blob

読み取り/書き込み

client-requested-host-name

文字列

読み取り/書き込み

domain-name-changed

整数

読み取り/書き込み

host-name-changed

整数

読み取り/書き込み

host-name-in-dns

整数

読み取り/書き込み

last-transaction-time

整数

読み取り専用

mac-address

blob

読み取り/書き込み

reverse-name-in-dns

整数

読み取り/書き込み

 

表28-11 pre-packet-encode リース情報のデータ項目

リース情報のデータ項目
操作

lease-deactivated

整数

読み取り専用

lease-ipaddress

IP アドレス

読み取り専用

lease-reserved

整数

読み取り専用

lease-state

文字列

読み取り専用

lease-start-time-of-state

整数

読み取り専用

 

表28-12 pre-packet-encode スコープ アドレス情報のデータ項目

スコープ アドレス情報のデータ項目
操作

scope-network-number

IP アドレス

読み取り専用

scope-primary-network-number

IP アドレス

読み取り専用

scope-primary-subnet-mask

IP アドレス

読み取り専用

scope-subnet-mask

IP アドレス

読み取り専用

 

表28-13 pre-packet-encode スコープ受け入れ可能性情報のデータ項目

スコープ受け入れ可能性情報のデータ項目
操作

scope-allow-bootp

整数

読み取り専用

scope-allow-dhcp

整数

読み取り専用

scope-allow-dynamic-bootp

整数

読み取り専用

scope-available-leases

整数

読み取り専用

scope-deactivated

整数

読み取り専用

 

表28-14 pre-packet-encode スコープ DNS 情報のデータ項目

スコープ DNS 情報のデータ項目
操作

scope-dns-forward-server-address

IP アドレス

読み取り専用

scope-dns-forward-zone-name

文字列

読み取り専用

scope-dns-number-of-host-bytes

整数

読み取り専用

scope-dns-reverse-server-address

IP アドレス

読み取り専用

scope-dns-reverse-zone-name

文字列

読み取り専用

scope-update-dns-enabled

整数

読み取り専用

scope-update-dns-for-bootp

整数

読み取り専用

pre-dns-add-forward

pre-dns-add-forward に使用可能なディクショナリは、環境ディクショナリです。

この拡張ポイントを使用して、名前を選択したり、アップデート操作時の DNS 再試行の設定を変更することができます。これらのデータ項目は、この拡張ポイントの環境ディクショナリで使用できます。

host-name (読み取り/書き込み):DNS サーバのアップデート時に、DHCP サーバが次に試みるホスト名。名前の読み取りと変更には、拡張機能が使用できます。

txt-string (読み取り/書き込み):DHCP サーバが DNS に書き込む TXT レコード。デフォルトでは blob として返されるクライアント ID ですが、どんなレコードでもかまいません。このレコードにより、このクライアントがこの名前の所有者として認識されるので、正しい操作が行われるかどうかは、このテキスト文字列とクライアントの間の 1 対 1 対応に依存します。

domain-name (読み取り/書き込み):DHCP サーバが DNS アップデートに使用するドメイン名。

renaming-retries (読み取り/書き込み):現在残っているリトライ回数。

maximum-renaming-retries (読み取り/書き込み):残りのリトライ回数の最大値。

last-name-number (読み取り/書き込み):DNS 名を明確にするために使用する最後の数値。

last-name-number-length (読み取り/書き込み):その数値の長さ、つまり、10 進数に変換するときに名前に使用する文字数。

ignore-prerequisites (読み取り/書き込み): true に設定すると、DHCP サーバは DNS A レコードのアップデートに関する前提条件の設定を無視するので、 最後の クライアントが成功するための名前を取得しようとします。DHCP サーバのデフォルトの動作では、 最初の クライアントが、名前を使用して後続のクライアントの名前を取得することによって、明確な名前を確保します。

continue (読み取り/書き込み):リトライ回数が残っている場合、DHCP サーバは DNS のアップデートを続けます。これを false に設定すると、リトライ回数が残っていても、DHCP サーバは DNS のアップデートの試みを停止します。