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

目次

クライアントクラスおよびクライアントの設定

クライアントクラス処理

サーバ上でのクライアントクラスの設定

クライアントクラス処理のイネーブル化

クライアントクラスとそのプロパティの定義

ホスト名プロパティの定義

ポリシーの関連付け

その他のプロパティの設定

クライアントクラスのスコープ選択基準の設定

選択タグとスコープの関連付け

クライアントクラスに対する組み込みポリシーの設定

外部ソースを含むクライアント データの処理

クライアントクラスを決定する処理順序

スコープ選択タグを決定する処理順序

クライアントクラスのトラブルシューティング

クライアント プロパティの設定

クライアントの追加と編集

クライアントに対する組み込みポリシーの設定

Windows クライアント プロパティの設定

Windows クライアントでの設定

DHCP サーバでの設定

暫定アドレスの割り当て

未知のクライアントの暫定アドレス

ワンショット アクションの使用

クライアントクラス処理におけるクライアント エントリのスキップ

クライアント認証の制限

クライアント キャッシング パラメータの設定

オプション 82 を使用した加入者の制限

加入者制限に対する一般的な処理

標準的な制限事例

クライアントクラスの算出とキーの作成

クライアントクラスのルックアップ式の処理

制限処理

加入者制限の式処理

オプション 82 制限の設定

DHCP 更新処理

オプション 82 制限の管理

オプション 82 制限のトラブルシューティング

式の例

LDAP の設定

LDAP ディレクトリ サーバについて

LDAP リモート サーバの追加

LDAP での DHCP クライアント クエリーの設定

DHCP サーバから LDAP クライアントへのクエリーの設定

クライアント エントリの動作停止

LDAP への組み込みポリシーの設定

DHCP LDAP アップデートと作成サービスの設定

リース状態アトリビュート

リース状態アップデート用の LDAP の設定

LDAP アップデートの使用

LDAP 状態アップデートの設定

LDAP エントリ作成の設定

LDAP のトラブルシューティング

LDAP 接続の最適化

標準的な LDAP アトリビュートと推奨値

クライアントクラスおよびクライアントの設定

Cisco CNS Network Registrar のクライアントまたはクライアントクラスの概念を使用して、共通ネットワーク上のユーザに対して異なるサービスを提供できます。管理基準に基づいてクライアントをグループ化し、各グループが適切なサービス クラスを確実に受け取れるようにします。クライアントクラス処理をイネーブルにしない場合、DHCP サーバは、ネットワークの位置だけに基づいてクライアントにリースを提供します。

クライアントクラス処理

DHCP サーバのクライアントクラス処理のイネーブル化やディセーブル化、およびプロパティのセットをクライアント グループに適用できます。クライアントクラス処理をイネーブルにした場合、DHCP サーバは対応するスコープのアドレスにクライアントを割り当てます。サーバは、各パケット内のデータに応じて動作します。クライアントクラスの設定方法は、次のとおりです。

1. DHCP サーバのクライアントクラス処理をイネーブルにします。

2. 選択タブを包含または除外するクライアントクラスを定義します。

3. 選択タグを特定のスコープに適用します。

4. クライアントをこれらのクラスに割り当てます。

このプロセスは、Network Registrar で設定されたクライアント用のものです。外部ソースからのデータによって影響を受ける処理については、「外部ソースを含むクライアント データの処理」を参照してください。

サーバ上でのクライアントクラスの設定

クライアントクラスの設定では、次のことを行います。

1. DHCP サーバのクライアントクラス処理のイネーブル化。

2. スコープ選択タグの作成(6.0 より前のみ)。

3. クライアントクラス自体の作成。

クライアントクラス処理のイネーブル化


ステップ 1 ローカル クラスタ Web UI では、 DHCP をクリックしてから DHCP Server をクリックし、Manage DHCP Server ページを開きます。

ステップ 2 サーバの名前をクリックします。

ステップ 3 Edit DHCP Server ページの Client Class アトリビュート カテゴリで、 client-class を enabled に設定します。

ステップ 4 Modify Server をクリックします。

CLI の場合、クライアントクラス処理をイネーブルにするには、 dhcp enable client-class を使用します。


 

クライアントクラスとそのプロパティの定義

次に、クライアントクラスそのものを定義します。この作業もサーバ レベルで行います。


ステップ 1 ローカル クラスタ Web UI では、 DHCP をクリックしてから Client-Classes をクリックし、List DHCP Client-Classes ページを開きます(図23-1 を参照)。

図23-1 List DHCP Client-Classes ページ(ローカル)

 

ステップ 2 Add Client-Class をクリックして、Add DHCP Client-Class ページを開きます(このページの一部を 図23-2 に示します)。

図23-2 Add DHCP Client-Class ページ(ローカル)

 

ステップ 3 クライアントクラス名、クライアント名(クライアントをクライアントクラスに関連付ける場合)、およびクライアントクラスのドメイン名を入力し、Policy name ドロップダウン リストであらかじめ定義されたポリシーをクリックします。

ステップ 4 Add Client-Class をクリックします。

ステップ 5 List DHCP Client-Classes ページで、新しく作成したクライアントクラスの名前をクリックします。

ステップ 6 Edit DHCP Client-Class ページでアトリビュートを設定します。

ステップ 7 Modify Client-Class をクリックします。

CLI で次のように指定します。

クライアントクラスを作成するには、 client-class name create を使用します。名前は、そのクライアントクラスであることが明確にわかるものにしてください。大文字と小文字は区別されないため、classPC は Classpc と同じになります。

クライアントのプロパティをクライアントクラスに設定するには、 client-class name set attribute
= value を使用します。


 

ホスト名プロパティの定義

クライアントクラスの host-name アトリビュートを使用すると、各クライアントが使用するホスト名を指定できます。これは、DHCP クライアント要求に含まれる値を上書きする絶対有効 DNS 値にするか、または次のいずれかの値にすることができます。

@host-name-option :サーバは、クライアントから送信されたホスト名オプションをそのまま使用します。

@no-host-name-option :サーバは、クライアントから送信されたホスト名を無視します。DNS 名の生成が有効になっていて、ダイナミック DNS アップデートでそのように設定されている場合は、生成された名前が使用されます。

@use-macaddress :サーバは、クライアントの MAC アドレスからホスト名を合成し、オクテットをハイフンでつないで、先頭に x を付加します。たとえば、クライアントの MAC アドレスが 1,6:00:d0:ba:d3:bd:3b の場合、合成されるホスト名は x1-6-00-d0-ba-d3-bd-3b になります。

<Not Specified> :ホスト名を指定しません。

ポリシーの関連付け

クライアントクラスの policy-name アトリビュートを使用すると、クライアントクラスに関連付ける適切なポリシーと、実行するアクションを設定できます。Web UI では、Add or Edit DHCP
Client-Class ページの Policy name フィールドで行います。CLI では、 client-class name set policy-name
=
value を使用します。

その他のプロパティの設定

クライアントに設定できるその他すべてのアトリビュートをクライアントクラスに設定できます。たとえば、ドメイン名、 action user-defined 文字列などです。詳細については、「クライアント プロパティの設定」を参照してください。

Web UI では、これらのアトリビュートが Add DHCP Client-Class ページまたは Edit DHCP Client-Class ページにあります。CLI で次のように指定します。

特定のクライアントクラスのプロパティを表示するには、 client-class name [ show ] を使用します。

作成されたすべてのクライアントクラスのプロパティ、またはその名前だけをリストすることもできます。

クライアントクラスを削除するには、 client-class name delete を使用します。

クライアントクラスの問題をデバッグするには、 dhcp set log-settings=client-criteria-processing を使用します。

クライアントクラスのスコープ選択基準の設定

クライアントクラスに対して実行する一般的なアクションを省略する場合、どのスコープ選択タグを包含または除外するかを指定できます。

次の説明では、スコープに選択タグが割り当てられているものと仮定します。

クライアントクラスが「包含」タグを割り当てる場合、クライアントは当該スコープからアドレスを取得できます。

クライアントクラスが「除外」タグを割り当てる場合、クライアントは当該スコープからアドレスを取得しません。

たとえば、3 つのスコープ A、B、C があり、A は赤色、B は青色、C は青色と緑色のアトリビュートを持っていると仮定します。クライアントクラスが赤色の包含タグを指定した場合、クライアントはスコープ A からアドレスを取得します。青色の包含タグを指定した場合、クライアントはスコープ B または C からアドレスを取得します。青色の包含タグと緑色の除外タグの場合、クライアントはスコープ B からだけアドレスを取得します。


ヒント 包含基準と除外基準が競合しないように設定します。これらの基準は相互に排他的であることを確認してください。



ステップ 1 ローカル クラスタの Web UI で、クライアントクラスを作成します。

ステップ 2 List DHCP Client-Classes ページで、クライアントクラスの名前をクリックします。

ステップ 3 Edit DHCP Client-Class ページで、次の 2 つのアトリビュートを設定します。

a. selection-criteria :このクライアントクラスをスコープに包含するために使用する選択タグを入力します。

b. selection-criteria-excluded :このクライアントクラスをスコープから除外するために使用するタグを入力します。

ステップ 4 Modify Client-Class をクリックします。

CLI の場合、包含基準を設定するには、 client-class name set selection-criteria を使用し、除外基準を設定するには、 client-class name set selection-criteria-excluded を使用します。


 

選択タグとスコープの関連付け

次に、適切な選択タグをスコープに関連付けます。これは、設定したサーバの下に存在する必要があります。


ステップ 1 ローカル クラスタの Web UI で、スコープを作成します。

ステップ 2 List/Add DHCP Scopes ページで、スコープの名前をクリックします。

ステップ 3 Edit DHCP Scope ページの Selection Tags 領域で、Selection Tag フィールドにクライアントクラスの selection-criteria アトリビュートで作成されたカンマ区切りのスコープ選択タグ リストを組み込みます。

ステップ 4 Modify Scope をクリックします。

CLI の場合、既存の選択タグをスコープに関連付けるには、 scope name set selection-tags を使用します。

ステップ 5 DHCP サーバをリロードします。


 

クライアントクラスに対する組み込みポリシーの設定

組み込みポリシーは Network Registrar により、それぞれのクライアントクラスに対して自動的に作成されます。プロパティまたは DHCP オプションを追加しない限り、組み込みポリシーは関連するプロパティまたは DHCP オプションを持ちません。これは、スコープに対する組み込みポリシーに似ています。


ステップ 1 ローカル クラスタの Web UI で、クライアントクラスを作成します。

ステップ 2 List DHCP Client-Classes ページで、クライアントクラスの名前をクリックします。

ステップ 3 Edit Embedded Policy をクリックして、Edit DHCP Embedded Policy for Client-Class ページを開きます。

ステップ 4 このページでフィールド、オプション、およびアトリビュートを変更します。必要に応じて、アトリビュートを設定解除します。

ステップ 5 Modify Embedded Policy をクリックします。

CLI で次のように指定します。

クライアントクラスに組み込みプロパティ値が設定済みかどうかを確認するには、クライアントクラス名をポリシー名として指定して、 client-class-policy を使用します。

クライアントクラス組み込みポリシー アトリビュートのイネーブル化、ディセーブル化、 取得、設定、および設定解除を行うことができます。クライアントクラス ポリシーを削除すると、その組み込みポリシー プロパティがすべて設定解除されることに注意してください。

DHCP オプションおよびベンダー オプションを一覧表示、取得、設定、および設定解除することもできます。

必要に応じて、組み込みクライアントクラスにリース時間を設定します。オプションをリストして確認します。


 

外部ソースを含むクライアント データの処理

DHCP クライアントを実行しているネットワーク ホストとそのユーザに関する情報が、複数の外部ソースから DHCP サーバに到達することがあります。サーバは、このデータをクライアントクラス処理の一部として使用でき、そのデータをリース データベースに取り込んで、Network Registrar 管理システムで使用できるようにすることができます。

最近導入された外部要因で、クライアント定義に影響する可能性があるものは、次のとおりです。

relay-agent-info DHCP オプション(82)の subscriber-id サブオプション。このオプションにより、ネットワーク管理者はネットワーク加入者またはクライアントを定義し、そのデータを DHCP サーバへ送信します。

RADIUS 認証サーバ データ。これは、RADIUS データが DHCP の意思決定に役立つ 802.1x プロトコル展開の一部です。この場合、デバイスは、このデータを relay-agent-info DHCP オプション(82)の中で、 radius-attribute サブオプション アトリビュートの一部として送信できます。

これらの外部オプションは、どちらも 「オプション 82 を使用した加入者の制限」で説明する DHCP オプション 82 を使用します。RADIUS ソースは、次のアトリビュートを送信できます。

クライアント ユーザまたはアカウント名( user アトリビュート)

管理のために定義されたクラス文字列( class アトリビュート)

ベンダー固有データ( vendor-specific アトリビュート)

セッション タイムアウト値( session-timeout アトリビュート)

クライアントに使用する IP アドレス プール( framed-pool アトリビュート)

クライアントに使用する IPv6 アドレス プール( framed-ipv6-pool アトリビュート)

Network Registrar は、subscriber-id サブオプションのほか、RADIUS サブオプションの user、class、および framed-pool アトリビュートのための拡張サポートを提供し( 付録C「DHCP 拡張ディクショナリ」 を参照)、すべてのサブオプションの式をサポートしています(「式の使用方法」を参照)。さらに、DHCP サーバには、RADIUS の class アトリビュートと framed-pool アトリビュートの処理方法を設定するためのアトリビュート設定が組み込まれました。Network Registrar は、それらのサーバ アトリビュートを使用して、RADIUS アトリビュート値をスコープ選択タグまたはクライアントクラス名としてマッピングするか、その値をクライアント データベース内で検出したスコープ選択タグに付加することができます。次の例を参考にしてください。

nrcmd> dhcp set map-radius-class=append-to-tags
 

RADIUS などの外部リソースから決定されたクライアントクラスとスコープ選択タグの場合、処理の順序が 「クライアントクラス処理」で説明したものより少し複雑です。以下の各項を参照してください。クライアントクラス機能を使用するには、DHCP サーバの client-class アトリビュートをイネーブルにする必要があることに注意してください。

クライアントクラスを決定する処理順序

可能なソースを使用してクライアントクラス名が決定される順序を次に示します。

1. 拡張環境ディクショナリの中のクライアントクラス名が使用されます。

2. データベース内で実のクライアント エントリが検出される場合は、そのクライアント エントリの client-class-name が使用されます。それ以外の場合は、 skip-client-lookup DHCP サーバ アトリビュートをイネーブルにして、不要なデータベースの読み取りを防止してください。

3. RADIUS framed-pool 値がクライアントクラスへマッピングされている場合( dhcp set map-radius-pool-name=map-as-class )、その framed-pool 値が使用されます。

4. RADIUS クラス値がクライアントクラスへマッピングされている場合
dhcp set map-radius-class=map-as-class )、そのクラス値が使用されます。

5. dhcp-user-class-id DHCP オプション(77)がクライアントクラスへマッピングされている場合( dhcp set map-user-class-id=map-as-class )、そのオプション値が使用されます(このマッピングの代わりにルックアップ ID 式も使用可能。「クライアントクラスのルックアップ式の処理」を参照)。

6. マッピングまたはユーザ クラス ID が検出されない場合、環境ディクショナリにある default-client-class-name が使用されます。

7. default-client-class-name またはクライアント エントリが検出されない場合は、 default という名前のクライアント(存在する場合)の client-class-name が使用されます。

スコープ選択タグを決定する処理順序

可能なソースを使用してスコープ選択タグが決定される順序は、次のとおりです(サーバは、ヌルでない最初のソースを使用します)。

1. 拡張環境ディクショナリ内のスコープ選択タグ。

2. データベース内で実のクライアント エントリが検出される場合は、そのクライアント エントリの scope-selection-tags が使用されます。それ以外の場合は、 skip-client-lookup DHCP サーバ アトリビュートをイネーブルにして、不要なデータベースの読み取りを防止してください。

3. クライアントのクライアントクラス内にあるスコープ選択タグ。

4. RADIUS framed-pool 値が使用可能で、クライアントクラスへマッピングされている場合( dhcp set map-radius-pool-name=map-as-tag )、その値が使用されます。

5. RADIUS クラス値が使用可能で、タグへマッピングされている場合( dhcp set map-radius-class=map-as-tag )、その値が使用されます。

6. dhcp-user-class-id DHCP オプション(77)が使用可能で、タグへマッピングされている場合( dhcp set map-user-class-id=map-as-tag )、そのオプション値が使用されます。

次に、検出された選択タグ(存在する場合)のリストに、次のいずれかが付加される場合があります。

1. RADIUS framed-pool 値が使用可能で、 map-radius-pool DHCP アトリビュートが、選択タグへの付加を行うように設定されている場合( dhcp set map-radius-pool=append-to-tags )、その値が付加されます。

2. RADIUS クラス値が使用可能で、 map-radius-class DHCP アトリビュートが、選択タグへの付加を行うように設定されている場合( dhcp set map-radius-class=append-to-tags )、その値が付加されます。

3. dhcp-user-class-id が使用可能で、 map-user-class-id DHCP アトリビュートが、選択タグへの付加を行うように設定されている場合( dhcp set map-user-class-id=append-to-tags )、それが付加されます。

クライアントクラスのトラブルシューティング

クライアントクラスの問題を解決するには、Web UI の Edit DHCP Server ページにある log-settings アトリビュートを使用するか、または CLI で dhcp set log-settings= setting を使用して、クライアントクラスのロギングをイネーブルにします。その後、DHCP サーバをリロードします。推奨する設定は次のとおりです。

client-detail :すべてのクライアントクラスのクライアント ルックアップ操作の最後で 1 行を記録します。この行は、クライアントについて検出されたすべてのデータと、クライアントのクライアントクラスで検出されたデータを示します。

client-criteria-processing :サーバがスコープを調べて、使用可能なリースがあるかどうかを確認する場合、またはすでにリースのあるクライアントでまだリースの受け入れが可能かどうかを判別する場合に、常にメッセージを記録します。

ldap-query-detail :DHCP サーバが、LDAP サーバに対してリース状態エントリの作成を開始する場合、LDAP サーバから応答を受信する場合、あるいは LDAP サーバから結果またはエラー メッセージを取得する場合に、常にメッセージを記録します。

問題がユーザの LDAP サーバに関連する可能性がある場合には、LDAP can-query 設定もイネーブルにします。

こうしたログは次の質問に答えるのに役立ちます。

サーバは、予期したデータベースからクライアント エントリを読み取っているのでしょうか。

サーバは LDAP または MCD(Network Registrar の内部データベース)からクライアント エントリを読み取ることができます。 client-detail ログは、サーバがクライアント エントリを読み取っている場所を示しています。

クライアントクラスはイネーブルになっているのでしょうか。

クライアントクラスがイネーブルになっているのに、期待する結果が得られない場合は、Network Registrar サーバが読み取っているデータベースを確認してください。サーバの読み取り元は LDAP ですか、それとも MCD ですか。 ldap-query-detail ログは、LDAP から読み取っているかどうかを示します。LDAP から読み取っていない場合は、DHCP の use-ldap-client-data プロパティをイネーブルにしてください。


) LDAP を使用する場合は、照会用に LDAP サーバの設定が必要です。LDAP can-query アトリビュートを true に設定してください。また、照会に LDAP を使用するように DHCP サーバを設定する必要もあります。


サーバはクライアントに正しいデータを提供しているのでしょうか。そのデータからは誤った結果が示されています。たとえば、クライアントは予想される IP アドレスを受け取っていません。

ネットワークでの明確な関係を確認してください。 client-criteria-processing ログは、サーバがアドレスを取得しているスコープを示しています。サーバが予想されるスコープから取得していない場合、明示関係は誤って定義されている可能性があります。予想したスコープがセカンダリ スコープだった場合には、明確に定義されていない可能性があります。

スコープ選択タグの包含および除外を正しく設定しましたか。

一連のスコープ選択タグを包含するように定義した場合、スコープのタグはクライアントのタグと一致する必要があります。一連のスコープ選択タグを除外するように定義した場合は、クライアントが設定パラメータを取得できるように、スコープにはこうしたタグを 1 つも定義しないようにする必要があります。選択タグの使用を開始するときは、包含および除外の複雑なシナリオは避けてください。

クライアント プロパティの設定

DHCP クライアント プロパティを設定します。これらのプロパティには、クライアントの関与するクライアントクラス、その関連ポリシー、実行するアクション、スコープ選択タグの包含基準および除外基準が含まれます。

クライアントの追加と編集

クライアントは、そのクライアントクラスからプロパティを継承します。プロパティは、別のプロパティを指定することによって上書きしたり追加したりできます。


ステップ 1 ローカル クラスタの Web UI で、 DHCP をクリックしてから Clients を順にクリックし、List/Add DHCP Clients ページを開きます(図23-3 を参照)。

図23-3 List/Add DHCP Clients ページ(ローカル)

 

ステップ 2 クライアントの ID(通常は MAC アドレス)を入力しますが、これは DUID またはルックアップ キーでもかまいません。サーバ アトリビュート validate-client-name-as-mac をイネーブルにすることにより、クライアント名を MAC アドレスとして検証するよう DHCP サーバを設定できます。

ステップ 3 必要により、定義済みクライアントクラスのドロップダウン リストからクライアントクラス名をクリックします。

ステップ 4 Add Client をクリックします。クライアントクラスを選択しなかった場合は、Add DHCP Client ページが開きます(ページの一部を 図23-4 に示します)。

図23-4 Add DHCP Client ページ(ローカル)

 


) クライアントについてクライアントクラスを選択した場合、このページは表示されず、クライアント名は List/Add Client ページにリスト表示されます。


ステップ 5 Add Client ページで、スコープ選択基準を含むクライアントに関するすべてのアトリビュートを追加します。

ステップ 6 ページの下部の Add Client をクリックします。

CLI で次のように指定します。

クライアント ID(MAC アドレス、DUID、またはルックアップ キー)によって名前を指定し、 client name create を使用します。

特定のクライアント コンフィギュレーションを持たない default という名前のクライアントを作成することもできます。たとえば、このクライアントがホスト名として常に MAC アドレスを使用するように設定できます。

クライアントのプロパティを設定するには、 client name set attribute = value を使用します。

host-name アトリビュートを @no-host-name-option に設定して、暫定アドレスを未知のクライアントに提供します。「暫定アドレスの割り当て」を参照してください。

ダイナミック DNS アップデートを行うときに使用するゾーンのドメイン名を設定します。

クライアントに対してポリシーおよびアクションを設定します。 exclude アクションを指定した場合、サーバはこのクライアントからの通信をすべて無視します(パケットは表示されません)。 one-shot アクションを指定した場合、サーバはこのクライアントに対してリースの更新や再提供を行いません。

時間単位数(seconds、minutes、hours、days、weeks)または UNIX 形式の日付(たとえば Mar 24 12:00:00 2002)を選択して認証の有効期限を設定するか、または forever を使用します。

特定のクライアントのプロパティを表示するには、 client name [ show ] を使用します。

すべてのクライアントのプロパティを表示するには、 client list を使用します。名前だけを一覧表示するには、 client listnames コマンドを使用します。

クライアントを削除するには、 client name delete を使用します。


 

クライアントに対する組み込みポリシーの設定

組み込み ポリシーはNetwork Registrarにより、それぞれのクライアントに対して自動的に作成されます。プロパティまたは DHCP オプションをイネーブル化または追加しない限り、組み込みポリシーは関連するプロパティまたは DHCP オプションを持ちません。


ステップ 1 ローカル クラスタの Web UI で、クライアントを作成します。

ステップ 2 List DHCP Clients ページでクライアントの名前をクリックして、Edit DHCP Client ページを開きます。

ステップ 3 Edit Embedded Policy をクリックして、Edit DHCP Embedded Policy for Client ページを開きます。

ステップ 4 このページでフィールド、オプション、およびアトリビュートを変更します。必要に応じて、アトリビュートを設定解除します。

ステップ 5 Modify Embedded Policy をクリックします。

CLI の場合は、クライアント MAC アドレス(または default )をクライアント ポリシー名として指定して、 client-policy を使用します。


 

Windows クライアント プロパティの設定

Windows 2003 および XP クライアントはクラスベースのプロビジョニングをサポートします。クライアントクラス処理に関係する特定のプロパティを CLI で設定できます。次のような処理が可能です。

クライアント エントリを参照して、クライアントクラス処理のためのデフォルト クライアントを指定する。

ユーザ クラス ID をクライアントクラスまたはスコープ選択タグにマッピングする。

クラス ID をスコープ選択タグ名に追加するかどうかを指定する。

Windows クライアントでの設定

Windows クライアント ホストで、 ipconfig /setclassid を使用してクラス ID を設定します。このクライアント ID をクライアントクラスまたは選択タグにマッピングする計画の場合は、同じ名前でなければなりません。次に、 ipconfig /showclassid コマンドを使用して確認します。次に例を示します。

DOS> ipconfig /setclassid adapter engineering
DOS> ipconfig /showclassid adapter
 

DHCP サーバでの設定

Windows クライアントのプロパティは、DHCP サーバでも設定する必要があります。

サーバに Windows クライアントのプロパティを設定するには、ローカル クラスタ Web UI で DHCP サーバ アトリビュートを使用するか、または CLI で dhcp set コマンド アトリビュートを使用します。 skip-client-lookup アトリビュートを true(デフォルト設定は false)に設定すると、DHCP サーバはクライアントクラス処理でクライアント エントリをスキップします。「クライアントクラス処理におけるクライアント エントリのスキップ」を参照してください。次のいずれかの map-user-class-id アトリビュート設定を使用します。

0:ユーザ クラス ID を無視する(デフォルト)。

1:ユーザ クラス ID をスコープ選択タグにマッピングする。

2:ユーザ クラス ID をクライアントクラスにマッピングする。

3:ユーザ クラス ID をスコープ選択タグのリストに追加する。

暫定アドレスの割り当て

クライアントに暫定アドレスを提供できます。

未知のクライアントの暫定アドレス

DHCP サーバでは、ワンショット ベースで未知のクライアントに短期間の暫定アドレスを割り振ることができます。サーバは、(短期に設定された)リース期間の間のみ、未知のクライアントにアドレスを提供し、クライアントはそのリースを更新できません。リースの期限が満了すると、クライアントは猶予期間が満了するまで新規リースを取得できません(クライアントはネットワークにアクセスできなくなります)。つまり、クライアントが登録できる時間を短く設定し、その時間内にクライアントが登録できない場合は、クライアントがネットワークを使用できなくするという方法です。


ステップ 1 たとえば、 unknown というポリシーを作成します(名前は任意です)。

ステップ 2 ローカル クラスタ Web UI の Edit DHCP Policy ページの Grace period フィールドを使用するか、または CLI の policy unknown create grace-period = extended-time 設定を使用します。

ステップ 3 暫定アドレスを未知のクライアントに提供するには、ローカル クラスタ Web UI の Edit DHCP Client ページで default クライアントを使用して Policy name 値を unknown に設定し、 action アトリビュート値を one-shot に設定します。または、CLI で client default create policy-name=unknown action=one-shot を使用します。


) 未知のクライアントのプロビジョニングは、DHCPv6 ではサポートされていません。



 

ワンショット アクションの使用

ワンショット アクションを使用して、暫定アドレスを割り振ります。これは、クライアントに対してアドレスを短時間だけ付与する場合に便利です。 action アトリビュートを one-shot に設定して、デフォルト クライアント(またはデフォルト クライアントの指定するクライアントクラス)を設定します。

次に、サーバは未知のクライアントにリースを与えますが、そのリースの更新は許可しません。リースの期限が満了すると、サーバはリース猶予期間の間、そのクライアントに応答せず、別のクライアントによってリースが使用されるときにのみ応答します。したがって、猶予期間は、クライアントがリースを取得できない最小期間になります。

クライアントには比較的短いリース時間(1 日など)を許可でき、猶予期間は長く(2 週間など)指定できます。このようにして、クライアントには何らかの権限に登録して既知のクライアントになるための誘因を提供でき、その間、別のクライアントにはリースの再割り振りを行いません。リース期間の終了後、クライアントは 2 週間の猶予期間の間、リース用の別のアドレスを取得できません。

リースと猶予期間はスコープごとにそれぞれ設定できるため、暫定リースには通常のリースとは異なるリースおよび猶予期間を設定できます。複数の DHCP サーバを使用している場合、各サーバはワンショット機能を別々に使用するため、暫定アドレスの制限は緩和されます。説明した方法で 2 つの DHCP サーバを使用すると、未登録のクライアントは 2 日間使用できる暫定アドレスを 2 週間ごとに取得できます。

クライアントクラス処理におけるクライアント エントリのスキップ

不要なデータベース読み取りを防止するために、クライアント エントリのクライアントクラス処理を無視することもできます。これを行うには、 skip-client-lookup DHCP サーバ アトリビュートをイネーブルにします(CLI では、 dhcp enable skip-client-lookup )。

クライアント認証の制限

クライアント エントリにはデフォルトで無制限の認証が設定されています。 authenticate-until アトリビュートを使用すれば、有効期限を指定してクライアント エントリの認証を制限できます。

クライアント エントリが認証されなくなると、DHCP サーバはこの DHCP 要求の応答に使用するために、クライアントクラス エントリの名前に関して unauthenticated-client-class-name アトリビュート値を使用します。このアトリビュートが設定されていない場合、またはクライアントクラス エントリがない場合、DHCP サーバは要求を無視します。

認証の有効値を次に示します。

+ num unit :今後の時間。 num は 10 進数で、 unit s m h d 、または w で、それぞれ秒、分、時間、日、または週を示します。たとえば「+3w」は今後の 3 週間を表します。

date :月、日、24 時間表示、および 2 桁または 4 桁の年。たとえば、「Jun 30 20:00:00 2002」。 nrcmd プロセスにはローカル時間の時刻を入力してください。サーバが別の時間帯で稼働している場合は、時間帯を無視して現地時間を代わりに使用します。

forever :このクライアントに対する認証の有効期限はありません。

ここでは、 authenticate-until アトリビュートを使用して認証済みのクライアントと未認証のクライアントとを区別する例を示します。認証の有効期限が切れてクライアントが別のアドレスを要求すると、DHCP サーバは未認証スコープの範囲からクライアントにアドレスを割り当てます。


ステップ 1 認証済みクライアントクラスと、未認証のクライアントクラスを作成します。それぞれに適した選択基準を設定します。

ステップ 2 クライアントを作成し、authenticate-until の有効期限を設定します。 client-class-name アトリビュートと unauthenticated-client-class-name アトリビュートをそれぞれ設定します。

ステップ 3 認証済みスコープと未認証のスコープを作成してそのアドレス範囲を定義し、それぞれのスコープ選択タブに関連付けます。

ステップ 4 サーバのクライアントクラス処理をイネーブルにします。

ステップ 5 DHCP サーバをリロードします。


 

クライアント キャッシング パラメータの設定

DHCP サーバからのクライアントによる最初のアドレス要求は、多くの場合、DHCPDISCOVER-
DHCPOFFER-DHCPREQUEST-DHCPACK サイクルを経ています。このプロセスで DHCP サーバは、要求ごとにクライアント データを 2 回データベースに問い合せる必要があります。クライアント キャッシング パラメータが設定されている場合、DHCP サーバはデータベースへの問い合せが 1 回だけで済むように、クライアント データをメモリにキャッシュします。クライアント キャッシングは、クライアント情報を LDAP に保存するシステムのパフォーマンスを著しく向上させることができます。クライアント キャッシングは、該当するアトリビュートを設定解除しない限り、デフォルトでイネーブルになっています。

最大のキャッシュ回数および TTL パラメータは、予想されるクライアント要求頻度に基づいて調整できます。要求の殺到が予想される場合には、使用可能なメモリに基づく上限までキャッシュ回数を増やすこともできます。長い要求サイクルが予想される場合には、TTL を増やすこともできます。これは、サーバによる要求サイクル中のクライアント キャッシュ問い合せを 1 回にすることが目的です。

サーバがクライアント キャッシュ内で保有するエントリ数に制限を設定するには、ローカル クラスタ Web UI の Edit DHCP Server ページにある client-cache-count アトリビュートを使用するか、または CLI で dhcp set client-cache-count を使用します。デフォルトで、キャッシュに対する最大数は 1000 クライアントになっています。クライアント キャッシュをディセーブルにするには、このアトリビュートを 0 に設定します。

通常、クライアント キャッシュが有効なのは 10 秒間だけで、これをキャッシュ生存可能時間(TTL)と呼びます。TTL が満了した後、サーバは、必要な場合、データベースからクライアント情報を読み取ります。ローカル クラスタ Web UI の Edit DHCP Server ページにある client-cache-ttl アトリビュートを使用するか、または CLI で dhcp set client-cache-ttl を使用して、この TTL を調整できます。

クライアント キャッシュ回数が指定した最大値に達すると、サーバは、クライアント エントリの TTL が満了するまで、それ以上クライアントをキャッシュできません。TTL の満了後、サーバはデータベースから読み取り、またキャッシングを開始します。

オプション 82 を使用した加入者の制限

多くの場合、サービス プロバイダーでは、DHCP サーバが顧客施設内のデバイスに配布する必要のある IP アドレス数を制限しようと考えています。サービス プロバイダーは、顧客施設内のデバイスに DHCP サーバが提供する「実際の」アドレスを与えながら、これらのアドレス数を制限します。これを実現する 1 つの方法としては、各顧客デバイスを登録(または設定)するクライアントクラス機能を使用する方法があります。この場合、IP アドレスはクライアント エントリ データベースに登録されているデバイスに対してだけ発行されます。この手法の主な欠点は、すべての顧客デバイスの登録が必要になり、それによって 各 MAC アドレスの入手が必要になる点です。多くの場合、サービス プロバイダーは、各デバイスの情報を知ることではなく、顧客ごとのデバイス数があまり多くならないことを望んでいます。

加入者ごとに顧客デバイスを制限すると、 relay-agent-info DHCP オプション(RFC 3046 で規定されているオプション 82)の値に基づいてデバイスを制限するという案が生じます。この値は、DHCP リレー エージェントが DHCPDISCOVER メッセージで送信します。このオプションには、顧客デバイスが接続されているスイッチのポートに関するデータが含まれます。ケーブル モデムの場合、ケーブル モデムの先に接続されているデバイスから DHCP 要求が送信されるとき、 relay-agent-info オプションのいずれかのサブオプションには、通常、ケーブル モデムの MAC アドレスが含まれます。一般に、オプション 82 データを生成する多くのデバイスでは、同じアップストリーム デバイスの加入者ごとに値が変動するサブオプションに値を設定します。この値は考えられるすべての加入者(ケーブル モデムの MAC アドレスなど)に対して、一意である場合があります。または、スイッチ上のポートとなるため、そのスイッチに接続している他の加入者に対しては一意になりますが、スイッチ上のすべての加入者に対しては一意にならない可能性があります。

この実装の目的は、ネットワーク管理者が DHCP で割り振ったアドレスを加入者が使用する際の制限事項を、DHCP サーバの他の機能に重大な影響を与えることなく設定できることです。多くの環境で、ネットワーク管理者はオプション 82 制限をあるデバイス クラスに使用し、その他の場合には使用しないようにできます。このサポートの重要な側面は、ネットワーク管理者がオプション 82 制限の適用対象デバイスと適用対象外デバイスとを切り分けられることにあります。

加入者制限に対する一般的な処理

現在のクライアント処理では、すべてのクライアントをクライアント エントリ データベースで参照します。オプション 82 制限の目的の 1 つは、すべての顧客デバイスを明示的にクライアント エントリ データベース(MCD データベースまたは LDAP)に登録(設定)する処理をなくすことです。ただし、加入者を制限する指定数は設定できるようにし、登録解除されたすべての加入者に与えられるデフォルト数をこの指定数で上書きする必要があるという要件があります。

これは、着信パケットごとに評価されて、そのクライアントを置く必要のあるクライアントクラス名を返す を作成することにより、高レベルで設定します。式の使用方法の詳細については、「式の使用方法」を参照してください。

これを処理するには、各クライアントクラスで制限 ID の指定を許可します。この ID は、着信パケットが判別するために使用した後、サーバが実際にデバイス数の制限を実行する後続処理で使用するキーです。同一の制限 ID( limitation-id プロパティ)を持つすべてのデバイスは、同一の加入者が起点であると見なされます。

標準的な制限事例

たとえば、着信パケットを次のように評価する場合があります。

1. オプション 82 の remote-id サブオプションがクライアントのハードウェア アドレス( chaddr )と一致する場合、加入者はケーブル モデムであり、 cm-client-class に割り当てる必要があります。

2. dhcp-class-identifier オプション値の先頭の 6 バイトが文字列 docsis と一致する場合、加入者は DOCSIS モデムであり、 docsis-cm-client-class に割り当てる必要があります。

3. user-class オプション値が文字列 alternative-class と一致する場合、加入者は alternative-cm-client-class に割り当てる必要があります。

クライアントクラスの算出とキーの作成

クライアントクラスを判別する式は、Web UI の場合は DHCP サーバの client-class-lookup-id アトリビュート、CLI の場合は dhcp set client-class-lookup-id= expression コマンドによって設定します。アトリビュート定義に単純式を入れるか、または式がもっと複雑な場合はアトリビュート定義で参照されるファイルに入れます(「式の使用方法」を参照)。

クライアントおよびクライアントクラスは、クライアントまたはクライアントクラスの limitation-id 値も指定できます。サーバはこの識別値(ID)を使用して、同じネットワークまたは LAN セグメント上の同一 ID を持つデバイス数にアドレス制限を設定します。要求しているクライアントがその ID で使用可能なアドレスの限度を超えると、サーバはそのクライアントを
over-limit-client-class-name に割り当てます(設定されている場合)。割り当てない場合は、パケットをドロップします。 limitation-id は、実際には加入者を定義します。

クライアントクラスのルックアップ式の処理

最初のクライアントクラス ルックアップで、クライアントを何らかの制限に入れる必要があるかどうかを決定できます。式は、 client-class-lookup-id アトリビュートを使用してサーバ全体に設定されます。この式は、パケットのクライアントクラスを判別する目的ですべての着信パケット上で実行されます。式は、パケットに使用されるクライアントクラス名の文字列、またはクライアント要求に対してクライアントクラス値が何も考慮されなかったことを示す識別文字列 <none> を返す必要があります。

<none> 文字列が返されるということは、 client-class-lookup-id 値は設定されず、クライアントクラス処理は実行されないという状態に相当します。式がヌルを返す場合、または client-class-lookup-id の評価でエラーがある場合、パケットはドロップされます(ログ メッセージがあります)。

制限処理

DHCP サーバは、同じネットワークまたは LAN セグメントで同じ limitation-id 値を持つ、DHCP クライアントに割り振られた IP アドレスの数を制限します。サーバで、別のアドレスをクライアントに割り振ると限度を超過することがわかる場合、クライアントのパケットを overflow-client-class に配置します(指定されている場合)。これを行うことにより、設定限度を超えるクライアントの特殊処理ができます。こうしたクライアントをセルフ プロビジョニング方式で処理できる点が、(たとえサポートされていても)ハードウェア内でなく、DHCP サーバ上で制限を使用する利点の 1 つです。

限度を超えたクライアントクラスがない場合、パケットのアドレス割り振りがその limitation-id に許可された limitation-count を超えるパケットは、サーバによってドロップされます。この制限は、1 つのネットワークまたは LAN セグメント内だけを対象に実施されます。ネットワーク管理者は、一度に 1 つの LAN セグメントだけに接続する単一の加入者を確認する傾向があるため、これは実際には制限ではありません。

DHCP ポリシーに同一の limitation-id を持つ limitation-count を設定します。制限コードは、他のポリシー項目と同じように、 limitation-count のポリシー チェーンを検索します。これは、クライアントクラスの組み込みまたは名前付きポリシー、スコープの組み込みまたは名前付きポリシー、またはシステムの system_default_policy limitation-count を設定できるという意味です。

limitation-id をクライアントクラスに設定すると、クライアントクラスの制限処理を進める信号を送信することになります。 limitation-id を設定しない場合は、処理を進めないという信号を送信します。 limitation-id を判別する式の実行時に式がヌルを返すと、制限処理は実行する必要があり、リース状態データベースに保存された limitation-id を使用するという信号が送信されます。

制限の処理は、現時点では DHCPv6 クライアントには使用できません。

加入者制限の式処理

式は制限処理でいくつかの箇所にあります。各式は、ヌルと文字列のどちらかに評価するか(一般にクライアントクラスの参照時にクライアントクラス名を判別するため)、あるいは limitation-id の作成時に一連のバイト(blob)に評価します。式は次の処理で使用されます。

クライアントクラスの参照

同じ加入者のクライアント制限で使用するキーの作成( limitation-id

クライアント エントリ データベースで参照するキーの作成( client-lookup-id

オプション 82 制限の設定

オプション 82 制限を正しく設定するには、次のようにします。


) クライアントを明示的に登録していない場合、オプション 82 データの使用時にクライアントクラスを DHCP サーバ プロパティとしてイネーブルにしないでください。



ステップ 1 一部のクライアントを制限してその他を制限しないようにするかどうかを決定します。一部のクライアントを制限する場合は、次の手順を実行します。

a. 各クライアントクラスの DHCP 要求に含まれるいくつかの値に基づいて、対象となるクライアントをその他のクライアントと区別する方法を探します。

b. 制限しないクライアントを置くクライアントクラスの名前を決定し、これらの無制限クライアントに使用する選択タグおよびスコープ(複数も可)を決定します。

ステップ 2 限度を超えたクライアントを別のクライアントクラスに置くか、またはそのパケットをただドロップするかどうかを決定します。限度超過のクライアントクラスに置く場合は、限度を超えたクライアントを置くクライアントクラス名と、選択タグおよびスコープ(複数も可)を決定します。

ステップ 3 制限するクライアントを置くクライアントクラスと、これらのクライアントに使用する選択タグおよびスコープ(複数も可)を決定します。

ステップ 4 これらの選択タグ、クライアントクラス、およびスコープをすべて作成します。

ステップ 5 limitation-count をポリシーに設定します。これは、制限する可能性のあるクライアントのクライアントクラスに関連付けられた名前付きポリシーです。

ステップ 6 着信クライアントを制限対象と制限対象外に分離する式を記述します。 client-class-lookup-id アトリビュートを設定することによって、その式を DHCP サーバ上に設定します。

ステップ 7 制限するデバイスの制限 ID を判別する式を記述します。 limitation-id を設定することにより、制限するクライアントのクライアントクラス上にその式を設定します。Add DHCP Client-Class ページでこの値を設定する方法については、図23-2 を参照してください。


 

DHCP 更新処理

DHCP クライアントからブロードキャストされたパケットだけが、オプション 82 データの付属する状態で DHCP サーバに到達します。BOOTP または DHCP リレー エージェントは、オプション 82 データをクライアント デバイスから最初のアップストリーム ルータに追加します。DHCPRENEW パケットはサーバに対してユニキャストで、オプション 82 データを付属せずに到達します。このため、サーバで加入者制限の設定を試みた場合に問題が起こる可能性があります。

一般に、更新に対応する際には 2 つの方法があります。1 つ目は、オプション 82 データを保有しないすべてのパケットを、関連する選択タグのないクライアントクラスに配置する方法です。これはワイルドカードの選択と同じことで、オプション 82 データのないすべてのパケットを受け入れるという意味です。2 つ目は、オプション 82 データを保有するパケットを置いた同じクライアントクラスで更新を行い、その limitation-id をヌルに評価します。これは制限の確認時に、パケットのものではなく、あらかじめ保存された limitation-id を DHCP サーバで使用する必要があるという信号です。

どちらの方法も有効です。2 つ目の方がより高いセキュリティのように見えますが、実際には 1 つ目の方法よりも高くありません。これは、DHCP サーバの IP アドレスを使用して DHCPRENEW に応答する必要があるためです。ほとんどのクライアントでは、サーバがステートの一部を失わない限り、この方法は使用しません。この場合は、アドレスをクライアントに付与するためにこの方法が必要になります。悪意のあるクライアントの場合は、クライアントへのアドレス付与をサーバに実行させるためにアドレスを引き続き使用する必要があるので、この場合の公開を制限しています。

オプション 82 制限の管理

クライアントが limitation-id を持つクライアントクラスに関係するのが原因で制限を受ける場合は常に、使用された limitation-id が必ずクライアント データの記録時に DHCP ログ ファイルに記録されます。使用された limitation-id はログ ファイルで「...LID: nnn : nnn : nnn ...」と表示されます。記録されるデータは、現在 limitation-count 回数のいずれかを占めているアクティブ リースを持つクライアントだけが対象です。

次のようにすると、 limitation-id を使用しているサブネット内のすべてのクライアントを判別できます。

ローカル クラスタの Web UI では、Manage DHCP Server ページで Commands カラムの Run アイコン( )をクリックし、DHCP Server Commands ページを開きます(図6-4 を参照)。少なくとも現在アクティブなリースの IP アドレスを IP Address フィールドに入力し、Run アイコンをクリックします。 limitation-id 自体を nn : nn : nn の形式で入力するか、文字列( " nnnn " )として入力することもでき、その場合、IP アドレスは検索対象のネットワークになります。

CLI では、 dhcp limitationList を使用します。

nrcmd> dhcp limitationList ipaddr [limitation-id] show
 

ipaddr limitation-id の両方を指定する場合、 ipaddr 値はサブネットを判別する giaddr のように使用されます。ネットワークの任意のスコープ(プライマリまたはセカンダリ)に表示される可能性のあるどの IP アドレスも、サブネットの指定に使用できます。 ipaddr だけを指定する場合は、DHCP サーバで提供するアドレスに指定する必要があり、コマンドはすべてのクライアントとクライアントが使用する対応リースを返します。

limitation-count のオーバーフローが原因でクライアントがサービスを拒否された場合は、次のようなメッセージが DHCP サーバのログ ファイルに表示されます。

Warning Server 0 05646 Could not add Client MAC: '1,6,01:02:03:04:0c:03' with
limitation-id: 01:02:03 using Lease: 10.0.0.23, already 3 Clients with that id.
No over-limit client class specified! Dropping packet!
 

dhcp limitationList を使用すると、現在 limitation-count を使い切っていて、新しいクライアントのサービス拒絶を引き起こしているクライアントを判別できます。コマンドの ipaddr 値は、ログ ファイルの「using Lease:」値に、limitation-id は「imitation-id:」値にする必要があります。ログ ファイルの例を使用した場合、コマンドは次のようになります。

nrcmd> dhcp limitationList 10.0.0.23 01:02:03 show
 

オプション 82 制限のトラブルシューティング

制限サポートをデバッグするには、次のいくつかの方法があります。まず、 dhcp setDebug VX=1 を使用すると、パケット トレースをオンに設定できます(パケット トレースをディセーブルにするコマンドは dhcp setDebug VX=0 )。次に、クライアントクラスのデバッグをイネーブルにするには、 client-criteria-processing および client-detail をログ設定に追加します。

また、サーバ全体の式トレース レベル expression-trace-level もあり、さまざまなレベルに設定できます。レベルを 6 に設定すると、すべての式評価を詳細にトレースします。この設定ではログ スペースをやや使う場合があり、サーバの処理速度も大幅に遅くなりますが、式評価を理解する上できわめて貴重です。「式のデバッグ」を参照してください。

正常に動作しているように見えない場合や、ログ ファイルを送信して問題をレポートする場合は、 dhcp setDebug QR57=9 を使用して、いくつかの追加トレースをイネーブルにすることが重要です(このトレースをディセーブルにするコマンドは dhcp setDebug QR57=0 )。Q と R はどちらも大文字にしてください。Q はクライアントクラス デバッグで、R は応答デバッグです(ログ内の制御フローをクリアするために必要)。5 は式の処理で、7 はクライアントクラスの検索処理です。このコマンドにより、パケットごとに 1 ページほどの出力結果が生成されます。この出力結果はサーバ内部の状況を理解する上で非常に貴重なものです。

式の例

オプション 82 処理の式を使用する方法の例については、「式の例」を参照してください。

LDAP の設定

この項では、Lightweight Directory Access Protocol(LDAP)について説明します。LDAP により、ディレクトリ サービスを使用して Cisco CNS Network Registrar のクライアントとリース情報を統合できます。LDAP ディレクトリに保存されているオブジェクトに対して既存の標準スキーマを作成すると、DHCP クライアント エントリについての情報を処理できます。したがって、クライアント情報を DHCP サーバのデータベースで管理する代わりに、Network Registrar DHCP サーバに要求して、DHCP クライアント要求に応答する情報の照会を 1 つまたは複数の LDAP サーバに発行することができます。

Network Registrar は、iPlanet LDAP Software Development Kit(SDK)バージョン 5.0 をサポートするようになりました。以前のリリースは、SDK バージョン 3.0 を使用していました。

LDAP ディレクトリ サーバについて

LDAP ディレクトリ サーバには、アトリビュートと値のペアの集合を命名、管理、およびアクセスする手段が用意されています。Network Registrar は特定の LDAP オブジェクト クラスやスキーマに依存しないので、どの方法でもユーザの LDAP サーバに情報を入力できます。

DHCP クライアント情報を未使用のアトリビュートに格納できます。たとえば、 givenname アトリビュートを使用して、DHCP client-class name 値を保持できます。

スキーマ チェック処理をディセーブルにすると、新しいアトリビュートをオブジェクト クラスに追加できます。たとえば、組織のユーザのオブジェクト クラスに client-class-name アトリビュートを追加できます。

新しいオブジェクト クラスを作成して該当するアトリビュートを定義できます。たとえば、DHCP クライアント オブジェクト クラスを作成して、使用するクライント アトリビュートを定義できます。

LDAP から読み取るように DHCP サーバを設定すると、照会ディクショナリにより照会する LDAP アトリビュートがサーバに分かります。サーバは結果データを DHCP クライアント データ アトリビュートに変換します。


ヒント LDAP サーバが DHCP サーバからの要求に対して応答を停止または再開したときに SNMP トラップを生成するよう、Network Registrar を設定できます。


LDAP リモート サーバの追加

ローカル クラスタの Web UI で LDAP リモート サーバを追加するには、 DHCP をクリックしてから LDAP をクリックし、List LDAP Remote Servers ページを開きます。Add LDAP Remote Server をクリックして、Add LDAP Remote Server ページを開きます(ページの一部を 図23-5 に示します)。そのページで、少なくとも LDAP サーバの名前と完全修飾ドメイン名を指定します。この操作には、ユーザ名とパスワードが必要です。

CLI では、次のように、 ldap name create domain-name を使用します。

nrcmd> ldap myserver create myserver.example.com
 

図23-5 Add LDAP Remote Server ページ(ローカル)

 

LDAP での DHCP クライアント クエリーの設定

LDAP クライアント エントリに、DHCP クライアント照会の設定および動作停止と、組み込みポリシーの設定を行うことができます。

DHCP サーバから LDAP クライアントへのクエリーの設定

DHCP サーバが LDAP サーバにクライアント データを照会できるようにするには、次の操作を実行します。ローカル クライアント エントリのように、LDAP クライアント エントリはクライアントの MAC アドレスでキーが設定されます。


) LDAP サーバに接続する場合は、ユーザの 識別名 を指定します。識別名で、LDAP スキーマ内のオブジェクトを一意に識別します。これは、データベース内の一意なキーやファイルの完全修飾パス名と同じです。たとえば、ユーザの識別名は dn: cn=Beth Jones, ou=Marketing, o=Example Corporation となります。この会社では、Beth や Jones という名前のユーザは多くいる場合がありますが、Example Corporation の Marketing には Beth Jones という名前は他にはいません。



ステップ 1 ホスト名を指定して、DHCP にユーザの LDAP サーバについて知らせます。ローカル Web UI では、LDAP Remote Server ページ(図23-5 を参照)の name フィールドに値を入力します。ローカル CLI では、たとえば次のコマンドを使用します。

nrcmd> ldap myserver create myserver.example.com
 

あとでサーバを削除する必要がある場合は、 ldap server delete を使用します。

ステップ 2 接続クレデンシャルを設定します。ユーザの識別名を使用します。Web UI では、username フィールドに値を入力します。CLI では、たとえば次のコマンドを使用します。

nrcmd> ldap myserver set username="cn=joe,o=Example Corp,c=US" password=access
 

ステップ 3 検索パス(さらに、必要であれば、検索スコープ)を設定します。パスは、検索を開始するディレクトリ内のポイントです。検索スコープに SUBTREE を指定すると、サーバは検索パスのすべての子を検索します。ONELEVEL を指定した場合、サーバはベース オブジェクトの直接の子だけを検索します。BASE を指定した場合は、ベース オブジェクト自体だけを検索します。この例では、サブツリー検索スコープで、検索のベースを組織 Example Corp、国 US と設定します。

Web UI では、search-path フィールドに値を入力します。CLI では、たとえば次のコマンドを使用します。

nrcmd> ldap myserver set search-path="o=Example Corp,c=US" search-scope=SUBTREE
 

ステップ 4 検索フィルタを、DHCP がクライアントの MAC アドレスを置き換える対象のアトリビュートに設定します。この例では、アトリビュートは通常名です( cn )。Web UI では、search-filter フィールドに値を入力します。CLI では、たとえば次のコマンドを使用します。

nrcmd> ldap myserver set search-filter=(cn=%s)
 

ステップ 5 すべての LDAP-to-DHCP マッピングを含む照会ディクショナリを設定します。 ldap servername setEntry を使用して、次のマッピングを設定します(CLI でのみ可能)。

a. sn LDAP アトリビュートから DHCP サーネームを取得します。

nrcmd> ldap myserver setEntry query-dictionary sn=host-name
 

b. 最初の givenname LDAP アトリビュートからクライアントクラス名を取得します。

nrcmd> ldap myserver setEntry query-dictionary givenname=client-class-name
 

c. localityname LDAP アトリビュートからドメイン名を取得します。

nrcmd> ldap myserver setEntry query-dictionary localityname=domain-name
 

d. いずれかのエントリを設定解除する必要がある場合は、 ldap server unsetEntry attribute key を使用します。 ldap server getEntry attribute key を使用すると、任意の設定をチェックすることもできます。

ステップ 6 LDAP サーバの照会をイネーブルにします。この例では、 myserver についての照会をイネーブルにします。Web UI では、can-query アトリビュートをイネーブルにします。CLI では、次のコマンドを使用します。

nrcmd> ldap myserver enable can-query
 

ステップ 7 DHCP サーバのクライアントクラス処理をイネーブルにします。Web UI では、Edit DHCP Server ページで client-class アトリビュートをイネーブルに設定します。CLI では、次のコマンドを使用します。

nrcmd> dhcp enable client-class
 

ステップ 8 DHCP サーバがクライアント エントリのクエリーに LDAP を使用できるようにします。Web UI では、Manage DHCP Server ページで client-class アトリビュートをイネーブルに設定します。CLI では、次のコマンドを使用します。

nrcmd> dhcp enable use-ldap-client-data
 

ステップ 9 複数の LDAP サーバが設定されている場合は、ラウンドロビンまたはフェールオーバー モードで処理するように設定することもできます。

ラウンドロビン :サーバの優先度値は無視され、クライアントのクエリーを処理するように設定されている LDAP サーバは、サーバはすべてリース状態アップデートを受け入れるように設定されているので、すべて同等に扱われます。

フェールオーバー :DHCP サーバは、優先度の最も低いアクティブ LDAP サーバを常に使用します。設定されたサーバが接続に失敗するかまたは切断されていると、DHCP は次の優先度順のサーバを使用します。ただし、同じ優先度の LDAP サーバはラウンドロビン モードとして処理されます。

Web UI で LDAP サーバ優先度(数値が小さいほど優先度が高い)を設定するには、Add LDAP Remote Server ページの Advanced Settings セクションで preference アトリビュートを設定します。Edit DHCP Server ページの Miscellaneous アトリビュートで ldap-mode が failover に設定されていることを確認してください。

CLI では、 ldap server set preference を使用し、DHCP サーバの LDAP モードを設定するために、 dhcp set ldap-mode を使用します。次に例を示します。

nrcmd> ldap myserver set preference=1
nrcmd> ldap anotherserver set preference=2
nrcmd> dhcp set ldap-mode=failover
 

ステップ 10 LDAP 設定を表示または一覧表示します。Web UI で List LDAP Remote Servers ページに進むか、CLI で次のコマンドを使用します。

nrcmd> ldap myserver
nrcmd> ldap list
nrcmd> ldap listnames
 

ステップ 11 DHCP サーバをリロードします。


 

クライアント エントリの動作停止

LDAP クライアント エントリを動作停止にして、クライアント情報は LDAP に残るが、情報が存在しないように見なして、DHCP サーバがクライアントを処理するようにできます。DHCP サーバはその後、クライアントにデフォルトの動作を提供します。前の ステップ 4 の検索フィルタ セットの設定を、値を持つ指定したアトリビュートを含むクライアント エントリを LDAP サーバが返さないように設定します。

たとえば、LDAP エントリ givenname をプロビジョニング解除するには、次のような CLI コマンドを使用して相応の検索フィルタを設定します。

nrcmd> ldap myserver set search-filter=(&(cn=%s)(!(givenname=unprovision)))
 

LDAP クライアント エントリの givenname アトリビュートが動作停止ストリングに設定されている場合は常に、LDAP サーバはクライアント エントリを DHCP サーバに返しません。つまり、DHCP サーバはクライアントが LDAP クライアント エントリを持っていないようにクライアントを処理します。


) この手順は、DHCP サーバまたは LDAP サーバにパフォーマンス上の影響はあまり与えません。


LDAP への組み込みポリシーの設定


ステップ 1 DHCP サーバについての LDAP サーバを設定し、たとえば、名前を myserver とします。

ステップ 2 DHCP が組み込みポリシーとして解釈する LDAP アトリビュートを内部 embedded-policy プロパティにマッピングします。この例では、businessCategory LDAP アトリビュートをマッピングします。

nrcmd> ldap myserver setEntry query-dictionary businessCategory=embedded-policy
 

ステップ 3 DHCP が組み込みポリシーとして解釈できる LDAP アトリビュートに文字列を追加します。この文字列をどのようなものにするかを判断する最も実際的な方法は、Network Registrar データベース内にダミーのクライアントを作成し、そのクライアントの組み込みポリシー設定からデータを抽出することです。LDAP を使用しているので、このダミー クライアントは使用されません。後で削除できます。組み込みポリシーに必要なオプション データ タイプを組み込みます。

a. たとえば、クライアント 1,6,00:d0:ba:d3:bd:3b の組み込みクライアント ポリシーを作成します。いくつかの応答オプションと複数値オプション(ルータ)を IP アドレス データ タイプで追加します。

nrcmd> client 1,6,00:d0:ba:d3:bd:3b create
nrcmd> client-policy 1,6,00:d0:ba:d3:bd:3b
set v4-reply-options=routers
nrcmd> client-policy 1,6,00:d0:ba:d3:bd:3b setOption routers 1.2.3.4,5.6.7.8
 

b. クライアントの組み込みポリシー データを取得します。

nrcmd> client 1,6,00:d0:ba:d3:bd:3b get embedded-policy
100 Ok
embedded-policy="((ClassName Policy)(name client-policy:1,6,00:d0:ba:d3:bd:3b)(v4reply-options [routers ])(version 1)(option-list [((ClassName Option)(Number 3)(value 01:02:03:04:06:07:08:09)(option-definition-set-name dhcp-config))]))"
 

c. 前のクライアント出力で引用符に囲まれているものを抽出し、LDAP アトリビュート(この例では businessCategory )にします。

businessCategory:((ClassName Policy)(name client-policy:1,6,00:d0:ba:d3:bd:3b)(v4reply-options [routers ])(version 1)(option-list [((ClassName Option)(Number 3)(value 01:02:03:04:06:07:08:09)(option-definition-set-name dhcp-config))]))
 

オプション値は、元はカンマで区切られていた複数値を含む、16 進数フィールド シンタックスに変換されます。

d. このシンタックスを、LDAP の新しい各組み込みポリシー エントリのモデルとして使用します。その他のオプション データ タイプが LDAP 文字列でどのように表示されるかを確認するには、これらのオプションをクライアントに追加するか、またはそれらのオプションを使用してさらにダミー クライアントを作成します。データを抽出すると、CLI を使用してダミー クライアントを削除できます。

nrcmd> client 1,6,00:d0:ba:d3:bd:3b delete
nrcmd> save
 


 

DHCP LDAP アップデートと作成サービスの設定

リース状態データを LDAP サーバ内の既存のアトリビュートにコピーするように、DHCP LDAP サービスを設定できます。このサービスでは、リース状態データを文字列形式に変換し、アップデート ディクショナリを使用して LDAP アトリビュートを DHCP データ値にマッピングします。

リース状態が変化するたびに、DHCP サーバはデータのコピーを作成して、リース状態データを格納するように設定した LDAP サーバに転送します。

リース状態アトリビュート

リースの状態情報についての次のアトリビュートをユーザの LDAP サーバに格納できます。

address :このリースの IP アドレス。

client-dns-name :このクライアントについて DHCP サーバが DNS サーバに入力しようとした名前。

client-domain-name :クライアントの名前が配置されるドメイン。

client-flags :クライアントに関連する各種フラグ。

client-host-name :DNS サーバに配置するようにクライアントが DHCP に要求した DNS 名。

client-id :クライアントにより指定されたクライアント ID、またはこのクライアントに関して DHCP サーバによって合成されたクライアント ID。

client-mac-addr :クライアントが DHCP サーバに提示した MAC アドレス。


) LDAP 内の MAC アドレスは、Network Registrar がローカル クライアント エントリを作成するときにフォーマット設定したとおりに正確にフォーマット設定する必要がありますが、これらは別個のインスタンスであり、したがってリース データに固有です。


expiration :リースが期限満了となる時刻。

flags :リースのフラグ(予約済みまたは非アクティブ状態)。

lease-renewal-time :クライアントがリース更新を発行すると予想される最早時間。 dhcp enable save-lease-renewal-time を使用して、Network Registrar にこれをリース状態の一部として保存させることができます(デフォルトでは保存されません)。

start-time-of-state :状態が現在の値に最後に変更された時刻。

state :リース状態。次の状態が可能です。

Available (1)

Deferred (2)

Leased (3)

Expired (4)

Unavailable (5)

Released (6)

Other_available (7)

Disconnected (8)

Deleted (9)

vendor-class-identifier :ベンダー固有の情報を交換するためにクライアントとサーバで使用されるベンダーの名前。

各リースにこれらのすべてのアトリビュートがあるとは限りません。 client-mac-addr および client-id リース状態アトリビュートは、クライアントがそのリースを解放するか、または Network Registrar により強制的に使用可能にされた場合は、提示されません。さらに、 lease-renewal-time アトリビュートは、 save-lease-renewal-time プロパティが DHCP によりディセーブルであると、提示されないことがあります。同様に、 vendor-class-identifier プロパティは、CLI を使用して、DHCP により
save-vendor-class-id
プロパティがディセーブルであると、提示されないことがあります。

リース状態アップデート用の LDAP の設定

次の手順に従って、リース状態アップデートを設定します。


ステップ 1 リース状態アップデート スキーマを選択します。

ステップ 2 ディレクトリにエントリを追加するかまたは既存のエントリを変更して、リース状態情報を格納します。アトリビュートまたはカスタム オブジェクト クラスを追加して、エントリを拡張する必要がある場合があります。

ステップ 3 アップデートを実行するように、Network Registrar を設定します。

ディクショナリに柔軟性があるので、ディレクトリにリース状態アトリビュートを格納するためにさまざまな方法を選択できます。たとえば、既存のエントリの一部としてリース状態データを格納したり、リース状態データを個別に格納したりできます。


 

既存エントリの一部としてのリース状態データの格納

リース状態データを既存エントリの一部として格納できます。クライアント エントリ、リース状態、および従業員データを同じエントリに格納することもできます。この方法のセットアップの一部として、リース データ アトリビュートの格納方法を決定する必要があります。データ アトリビュートを格納するには、次の方法を使用します。

エントリからアトリビュートをマッピングする。

エントリにアトリビュートを追加する。

新しいオブジェクト クラスを作成してエントリを拡張する。

この方法の利点は、リース データが他の関連クライアント情報とともに直接格納されることです。欠点は、あまり可能性はありませんが、クライアントクラスと予約に関連して、クライアントがサーバによってリースを移動される場合に、短期間にディレクトリに古いデータが存在する状況があります。


) 状態が更新されているリースにクライアントがない場合、そのリースには関連 MAC アドレスがありません。この状況はクライアントがリースを取得して、クライアントクラス処理でそのリースが移動される場合に発生します。これはまた、クライアントに既存のリースと、同じ LAN セグメント内の別のリースの予約がある場合にも発生することがあります。予約されたリースが使用可能であると、サーバはクライアントを既存のリースから予約に移動します。この両方の転送は、クライアント MAC アドレスのない古いリースの LDAP アップデートの結果となります。これは一般的には問題ではありません。クライアントの新しいリース(MAC アドレスに関連付けられている)のアップデートは実行する必要があるからです。


また、この方法は、リース情報を書き込むために 2 つの LDAP インタラクションが必要です。リース状態情報をアップデートする場合、DHCP LDAP サービスは、エントリをアップデートするときにエントリを検出する方法を十分に認識していないので、ディレクトリに 2 度接続します。エントリの識別名を明確に知る必要があります。

DHCP LDAP サービスはまず、検索基準として選択するリース状態アトリビュートの 1 つ(できれば MAC アドレス)を使用して、ディレクトリ内の該当するエントリを探します。これは、どのリース状態アトリビュートもエントリの識別名の一部でないので、必須です。DHCP LDAP サービスがエントリを特定すると、識別名が返されます。その後、DHCP LDAP サービスは該当する情報でその同じエントリをアップデートします。この方法の使用方法例については、「LDAP 状態アップデートの設定」を参照してください。

リース状態データを個別に格納

リース状態データを、IP アドレス別にその独自のエントリに格納できます。この方法の結果は、ディレクトリへのサーバ リース データベースのコピーとなり、データベースを設定する最も簡単な方法です。この方法のセットアップの一部として、サーバが使用できる各 IP アドレスの新しいエントリを作成します。この方法の利点は、ディレクトリ内のリース状態データが古くなる状況がないことです。この欠点は、リース データが他の関連クライアント情報とともに直接格納されないことです。

リース状態情報をアップデートするために、DHCP LDAP サービスはディレクトリ サービスに 1 度接続します。アップデートを行う場合、このサービスは IP アドレスを使用して識別名を作成します。

LDAP アップデートの使用

LDAP アップデート機能は、次の 2 つの目的に使用できます。

LDAP クライアント エントリ情報を使用するクライアントを追跡し、その LDAP ホストのアトリビュートの一部をリース状態アトリビュートと関連付ける。

IP アドレスで特定できるオブジェクトを作成およびアップデートする。Network Registrar がこれらのオブジェクトを作成する場合、DHCP サーバのリース状態と一致するレベルの LDAP オブジェクトを作成できます。

Network Registrar を使用する場合は、次のことに留意してください。

DHCP サーバは 1 つのオブジェクトとの読み取りおよび書き込みしか行いません。別のオブジェクトを使用して、クライアント エンントリ データの読み取りおよびリース データの書き込みを維持できますが、Network Registrar はあるオブジェクトから一部のアトリビュートを読み取って別のオブジェクトから別の部分を読み取ることはできません。

LDAP 照会のパフォーマンスは、すべてのデータベース アクセスのように、インデックス付きアトリビュートに依存します。照会フィルタで使用するように設定するアトリビュートをインデックス付けしなかった場合は、パフォーマンスが低下します。

Network Registrar は、アップデート用に設定されているとディレクトリに新しいオブジェクトを作成しません。DHCP サーバは、既存のオブジェクトにのみ書き込みます。しかし、アップデートおよび作成用に設定すると、新しいオブジェクトを作成します(オブジェクトが存在しない場合)。

LDAP 状態アップデートの設定

LDAP サーバに対するリース状態アップデートの実行に、次の 2 つのオプションを使用できます。

update-search-path :DHCP サーバはまず照会して、アップデートの dn(識別名)を探します。

dn-format :サーバに、アップデートの識別名が提供されます。つまり、DHCP は直接にアップデートして、アップデートの前に照会する必要がありません。

オプション 1:update-search-path オプションの使用

次の例は、最初のオプション update-search-path を示します。これは、LDAP オブジェクトの識別名( dn )をリース状態で使用できるデータから構築できない場合に行う動作を示します。DHCP サーバは、 update-search-xxx 情報に基づいて LDAP 照会を作成し、LDAP オブジェクトを見つけ、その識別名を使用して LDAP アップデートを発行します。

表23-1 に示す例は、標準 LDAP 組織のユーザ オブジェクト クラスのアトリビュートを使用してリース アップデート データを保持することを前提としています。

 

表23-1 LDAP から DHCP へのマッピング、例 2

アトリビュート
DHCP リース エントリ マッピング

uid

アドレス(IP アドレス)

carlicense

状態(リース状態)


ステップ 1 LDAP 設定内のサーバのホスト名を提示して、DHCP にユーザの LDAP サーバについて知らせます。

ステップ 2 LDAP サーバに接続するときに使用するクレデンシャルを設定します。この CLI の例では、管理者を joe とし、そのアクセス用パスワードを設定します。ユーザの識別名を使用します。

nrcmd> ldap myserver set username="cn=joe,o=Example Corporation,c=US" password=access
 

ステップ 3 update-search-path アトリビュートを設定します。これが DHCP サーバがアップデートするオブジェクトのディレクトリ内の開始ポイントです。アップデート検索スコープも設定できます。この CLI の例では、組織単位(ou)IT、組織 Example Corporation、および国 US で開始する検索パスが設定されます。アップデート検索スコープは SUBTREE に設定されます。

nrcmd> ldap myserver set update-search-path="ou=IT,o=Example Corp,c=US"
update-search-scope=SUBTREE
 

ステップ 4 アップデートされる LDAP オブジェクトの検索に使用するアトリビュートの ID を設定します。この CLI の例では、検索アトリビュートをクライアントの MAC アドレスに設定します。

nrcmd> ldap myserver set update-search-attribute=client-mac-addr
 

ステップ 5 update-search-attribute アトリビュートがフォーマット設定されるフィルタ式を設定します。この式には、この CLI の例に示すように、検索アトリビュートのデータが置き換えられる場所を示す「%s」が含まれている必要があります。

nrcmd> ldap myserver set update-search-filter=(cn=%s)
 

ステップ 6 update-dictionary アトリビュートを設定します。この設定により、対応するリース状態アトリビュートの値で設定する LDAP アトリビュートを識別できます。この例では、LDAP UID が IP アドレスを含むようにアップデートされ、 carlicense アトリビュートが DHCP リース状態情報を含むようにアップデートされることを指定します。CLI を使用して、次のように指定します。

nrcmd> ldap myserver setEntry update-dictionary uid=address carlicense=state
 

ステップ 7 次の CLI の例に示すように、新しい LDAP サーバのアップデートをイネーブルにします。

nrcmd> ldap myserver enable can-update
 

ステップ 8 DHCP サーバをリロードします。


 

オプション 2:dn-format オプションの使用

次の例は、2 番目のオプション dn-format の使用法を示します。


ステップ 1 LDAP 設定内のサーバのホスト名を提示して、DHCP にユーザの LDAP サーバについて知らせます。

ステップ 2 LDAP サーバに接続するときに使用するクレデンシャルを設定します。この CLI の例では、管理者を joe とし、そのアクセス用パスワードを設定します。ユーザの識別名を使用します。

nrcmd> ldap myserver_option2 set username="cn=joe,o=Example Corporation,c=US"
password=access
 

ステップ 3 次の CLI の例に示すように、 dn-format 文字列を使用して、LDAP サーバ データベース階層内のアップデートの検索を開始する場所を指定します。

nrcmd> ldap myserver_option2 set dn-format="cn=\"%s\",ou=IT,o=Example Corp,c=US"
 

ステップ 4 dn-format 文字列が参照する dn-attribute アトリビュートを設定します。この CLI の例では、 dn-attribute をクライアントの MAC アドレスに設定します。

nrcmd> ldap myserver_option2 set dn-attribute=client-mac-addr
 

ステップ 5 アップデートするエントリを指定します。CLI を使用して、次のように指定します。

nrcmd> ldap myserver_option2 setEntry update-dictionary uid=address carlicense=state
 

ステップ 6 次の CLI の例に示すように、 can-update アトリビュートをイネーブルにします。

nrcmd> ldap myserver_option2 enable can-update
 

ステップ 7 DHCP サーバをリロードします。


 

LDAP エントリ作成の設定

この項では、LDAP エントリの作成方法について説明します。LDAP エントリ作成には、エントリを見つけて現行のリース情報でそれをアップデートする機能が用意されています。エントリは、状態アップデート操作がエントリを見つけられないために失敗した場合にのみ作成されます。

前の例の手順を実行後、CLI で次の手順に従います。


ステップ 1 次の CLI の例に示すように、リース オブジェクト アトリビュートに関する LDAP サーバの
dn-attribute
プロパティを設定し( client-mac-addr フィールドなど)、 dn-format 文字列を設定します。

nrcmd> ldap myserver set dn-attribute=client-mac-addr
dn-format="cn=\"%s\",ou=IT,o=Example Corp,c=US"
 

このステップは、 update-search-path オプションを使用してリース状態アップデートを設定する場合にのみ必要です(「オプション 1:update-search-path オプションの使用」を参照)。 dn-format 文字列を使用してリース状態アップデートを設定する場合は、このステップをスキップします(「オプション 2:dn-format オプションの使用」を参照)。

ステップ 2 既存の dn-attribute プロパティと組み合せる場合に作成されるエントリの識別名を、次の CLI の例に示すように指定します。

nrcmd> ldap myserver set dn-create-format="cn=\"%s\",ou=IT,o=Example Corp,c=US"
 

Network Registrar の client-mac-addr フィールドでは、 1,6: xx : xx : xx : xx : xx : xx の形式を使用します。カンマは LDAP では特殊な区切り文字なので、識別名の引用には \" を使用する必要があります。

ステップ 3 create-dictionary プロパティを使用し、一連の名前=値のペアを入力して LDAP アトリビュートとリース状態アトリビュートの間のマッピングを設定します。LDAP アトリビュートは、対応するリース状態アトリビュートの値に対するエントリ アトリビュート セットを示します。CLI で次のように指定します。

nrcmd> ldap myserver setEntry create-dictionary sn=client-host-name
nrcmd> ldap myserver setEntry create-dictionary givenname=client-class-name
nrcmd> ldap myserver setEntry create-dictionary localityname=client-domain-name
 

ステップ 4 create-object-classes プロパティを使用して、エントリを作成するときに使用するオブジェクト クラスを、次の CLI の例に示すように指定します。

nrcmd> ldap myserver set create-object-classes=
"top,person,organizationalPerson,inetorgperson"
 

ステップ 5 次の CLI の例に示すように、LDAP サーバ myserver のエントリ作成をイネーブルにします。

nrcmd> ldap myserver enable can-create
 

can-update アトリビュートをイネーブルにしてから、can-create アトリビュートをイネーブルにする必要があります。例については、「LDAP 状態アップデートの設定」を参照してください。


ステップ 6 DHCP サーバをリロードします。

ステップ 7 作成、クエリー、およびアップデートが正常であったかどうかを確認するために、LDAP ログ設定を表示します。


 

LDAP のトラブルシューティング

次の項には、LDAP サーバの詳細な調整および障害検出についてのいくつかのアドバイスが含まれています。

LDAP 接続の最適化

個別に調整可能な読み取りおよび書き込みオブジェクトを使用すると、LDAP 接続を最適化できます。次の CLI の例は、書き込み(作成および更新)処理を調整し、より長いサーバ処理を必要とします。

nrcmd> ldap LDAP-Write create csrc-ldap password=changeme port=389 preference=1
nrcmd> ldap LDAP-Write setEntry query-dictionary csrcclientclasas=client-class-name
nrcmd> ldap LDAP-Write set
search-filter=(&(macaddress=%s)(|(crscclassname=Computer)(csrcclassname=Modem)))
nrcmd> ldap LDAP-Write set search-path=csrcprogramname=csrc,o=NetscapeRoot
nrcmd> ldap LDAP-Write set
username=uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot
nrcmd> ldap LDAP-Write disable can-query
nrcmd> ldap LDAP-Write enable can-create
nrcmd> ldap LDAP-Write enable can-update
nrcmd> ldap LDAP-Write enable limit-requests
nrcmd> ldap LDAP-Write set connections=2 max-requests=8 timeout=10s
 

次の CLI の例は、読み取り(クエリー)処理を調整し、より短いサーバ処理を必要とします。

nrcmd> ldap LDAP-Read create csrc-ldap password=changeme port=389 preference=1
nrcmd> ldap LDAP-Read setEntry query-dictionary csrcclientclasas=client-class-name
nrcmd> ldap LDAP-Read set
search-filter=(&(macaddress=%s)(|(crscclassname=Computer)(csrcclassname=Modem)))
nrcmd> ldap LDAP-Read set search-path=csrcprogramname=csrc,o=NetscapeRoot
nrcmd> ldap LDAP-Read set
username=uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot
nrcmd> ldap LDAP-Read enable can-query
nrcmd> ldap LDAP-Read disable can-create
nrcmd> ldap LDAP-Read disable can-update
nrcmd> ldap LDAP-Read enable limit-requests
nrcmd> ldap LDAP-Read set connections=3 max-requests=12 timeout=4s
 

標準的な LDAP アトリビュートと推奨値

表23-2 に、LDAP アトリビュートの標準的な値を示します。

 

表23-2 LDAP パラメータと推奨値

推奨設定
説明

connections=5 ~ 25

サーバが LDAP サーバに対して行う接続数。これは、主としてパフォーマンス チューニング パラメータです。デフォルトは 1 接続です。複数接続により全体スループットを向上できることがあります。数は、LDAP サーバ上の負荷に依存します。LDAP を使用するアプリケーションが多い場合は、5 接続が適切です。Network Registrar だけが LDAP を使用する場合は、25 接続が適切です。

threadwaittime=2

各 LDAP クライアント接続が、未処理の照会またはアップデートがある場合に、結果をポーリングする間隔(ミリ秒)。

timeout=3

古くてタイムアウトを宣言されるまでに、LDAP 要求が接続キューに残る秒数。3 秒のデフォルト値を推奨します。クライアントのタイムアウト期間後に DHCP クライアントが受信する応答はすべて無効です。

dhcp set ldap-mode=failover および dhcp enable can-update または dhcp enable can-create が設定されていると、Network Registrar DHCP サーバは timeout 間隔でフェールオーバーします。

query-timeout=3

dhcp set ldap-mode=failover および dhcp enable can-query が設定されていると、Network Registrar DHCP サーバは query-timeout 間隔でフェールオーバーします。3 秒のデフォルト値を推奨します。