Cisco CNS Network Registrar Release 6.1ユーザ ガイド
DHCP サーバの詳細プロパティの管理
DHCP サーバの詳細プロパティの管理
発行日;2012/02/01 | 英語版ドキュメント(2009/03/01 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf | フィードバック

目次

DHCP サーバの詳細プロパティの管理

BOOTP の設定

BOOTP について

スコープに対する BOOTP のイネーブル化

BOOTP クライアントの移動または解放

ダイナミック BOOTP の使用方法

BOOTP リレー

DHCP 転送の設定

ベンダー固有の DHCP オプションの設定

詳細サーバ パラメータの定義

詳細 DHCP サーバ パラメータの設定

リース延長の見送り

カスタム DHCP オプションの設定

カスタム オプションの追加

カスタム オプションの編集と削除

Windows System Management Server の統合

拡張機能の使用による DHCP サーバの動作への影響

DHCP サーバのトラブルシューティング

DHCP サーバの詳細プロパティの管理

この章では、DHCP サーバのいくつかの詳細プロパティのセットアップ方法について説明します。クライアントがアドレスの割り当てに DHCP を使用できるようにするには、少なくとも 1 つのスコープ(ダイナミック アドレス プール)をサーバに追加する必要があります。この作業については、 第 11 章「DHCP のスコープおよびポリシーの設定」 を参照してください。

BOOTP の設定

BOOTstrap Protocol(BOOTP; ブートストラップ プロトコル)は、もともとはディスク装置を持たないコンピュータ用に作成されました。後に、ホストがインターネットを使用する場合に必要な TCP/IP 情報をすべて取得するために使用されるようになりました。BOOTP を使用すると、ホストは要求をネットワーク上でブロードキャストし、BOOTP サーバから必要な情報を取得することができます。BOOTP サーバは、送られてきた BOOTP 要求を受信し、構成データベースからネットワーク上の BOOTP クライアントに対する応答を生成するコンピュータです。BOOTP は、リースやリース期限満了という概念を持たない点で DHCP と異なっています。BOOTP サーバが割り当てるすべての IP アドレスには、期限がありません。

Cisco CNS Network Registrar を設定して、BOOTP サーバのように動作させることができます。また、BOOTP には通常、スタティックなアドレスの割り当てが必要ですが、IP アドレスを予約(したがって、スタティックな割り当てを使用)するか、または BOOT クライアントに IP アドレスをダイナミックに割り当てるかを選択することができます。

BOOTP について

BOOTP パケットを返すように DHCP サーバを設定する場合、BOOTP には、DHCP パケットのオプション空間以外のフィールドの情報が必要になることに注意してください。一般に BOOTP デバイスは、ブートファイル( file )、サーバの IP アドレス( siaddr )、およびサーバのホスト名( sname )という DHCP パケット内の各フィールドの情報を必要とします(RFC 2131 を参照)。

すべての Network Registrar DHCP ポリシーには、 file siaddr 、または sname の各フィールドに直接返す情報を設定できるフィールドがあります。また、Network Registrar DHCP サーバでは、設定パラメータを使用してポリシー オプションを設定し、 file sname 、または siaddr の各値のうち BOOTP デバイスに返す値を決定できます。

Network Registrar でも、類似の設定パラメータを使用してオプションを設定し、 file sname 、または siaddr の各値うち DHCP クライアントに返す値を決定できます。これは、DHCP 要求の dhcp-
parameter-request
オプションで DHCP クライアントによって要求されるオプションとは別のものです。したがって、ご使用のデバイスに応じて適切な BOOTP と DHCP の両方の応答パケットを設定できます。


ステップ 1 次の BOOTP パケット応答フィールドに設定する値を決定します。

file :ブートファイルの名前

siaddr :サーバの IP アドレス

sname :オプションのサーバ ホスト名

ステップ 2 BOOTP クライアントに返すオプションとその値のリストを決定します。

ステップ 3 BOOTP 要求に関連付けるポリシーに次の値を設定します。

BOOTP クライアントに送信する各フィールド( Packet-siaddr packet-file-name
packet-server-name

オプション値(たとえば、BOOTP クライアントに返すサーバ アドレス、ドメイン名など)

BOOTP クライアントに返すフィールドとオプションのリスト

ステップ 4 関連スコープ(複数も可)の BOOTP 処理をイネーブルにします。

ステップ 5 アドレスを要求した BOOTP クライアントに対してこのスコープでアドレスを提供するには、ダイナミック BOOTP 処理をイネーブルにします。ダイナミック BOOTP 処理をイネーブルにしない場合は、このスコープでアドレスを提供する対象の各 BOOTP クライアントを予約する必要があります。


 

スコープに対する BOOTP のイネーブル化

スコープに対して BOOTP 処理をイネーブルにできます。BOOTP を設定するには、ローカル クラスタ Web UI の場合は、作成したポリシーに関する特定のアトリビュートと BOOTP 応答オプションを設定し、CLI の場合は、 policy name create コマンドと policy name set コマンドを使用します。カンマ区切りのリストとして、ポリシーのアトリビュートとオプションを設定します。アトリビュートは、クライアントのブート プロセスで使用されるエンティティです。

packet-siaddr :次サーバの IP アドレス

packet-file-name :ブートファイルの名前

packet-server-name :サーバのホスト名

サーバは bootp-reply-options リストから、これらのアトリビュートに一致するものを探します。ローカル クラスタ Web UI の場合は、Options ドロップダウン リストの BOOTP Compatible セクションでオプションをクリックします。オプションは、ローカル クラスタ Web UI と CLI で同じです。

アトリビュートの設定後、正しいオプション値を設定します。

ローカル クラスタ Web UI の場合は、Options ドロップダウン リストとアトリビュートのオプションをクリックして設定します。

CLI の場合、 policy name setOption コマンドは、値の前にスペース(等号ではない)が必要です。また、必要であれば、BOOTP とダイナミック BOOTP をイネーブルにして、DHCP サーバが BOOTP 要求で DNS サーバを更新するようにします。オプションは次のとおりです。

dhcp-lease-time オプションの設定

dynamic-bootp アトリビュートのイネーブ化

update-dns-for-bootp アトリビュートのイネーブル化

BOOTP クライアントの移動または解放

BOOTP クライアントを移動または解放すると、そのリースを再使用できます。BOOTP クライアントを解放するには、スコープからリース予約を削除して、そのリースを強制的に使用可能にする必要があります。

ローカル クラスタ Web UI の場合はリースを強制的に使用可能にし、CLI の場合は scope name removeReservation コマンドと lease ipaddr force-available コマンドを設定します。

ダイナミック BOOTP の使用方法

BOOTP クライアントは、固定された IP アドレスを割り当てられ、期限満了がないリースを受け取ります。そのため、ダイナミック BOOTP を使用する場合、そのようなスコープでのアドレス使用には別の制限が追加されています。

DHCP フェールオーバーを使用している場合、スコープの dynamic-bootp オプションがイネーブルになっていないサーバは PARTNER-DOWN 状態になると、メイン サーバまたはバックアップ サーバに当初使用可能になっていたかどうかにかかわらず、そのスコープから使用可能な IP アドレスを割り当てることができます。これに対し、 dynamic-bootp オプションがイネーブルになっている場合は、メイン サーバとバックアップ サーバはそのサーバ固有のアドレスしか割り当てることがでません。したがって、 dynamic-bootp オプションをイネーブルにするスコープには、フェールオーバーをサポートするためにより多くのアドレスが必要です。

ダイナミック BOOTP を使用するには、次の手順に従います。

1. ダイナミック BOOTP クライアントを分離して単一スコープにします。DHCP クライアントでそのスコープの使用をディセーブルにします。ローカル クラスタ Web UI の場合は、スコープの BOOTP アトリビュート下の dhcp アトリビュートをディセーブルにします。CLI の場合は、 scope name disable dhcp コマンドを使用します。

2. DHCP フェールオーバーを使用している場合は、DHCP サーバに failover-dynamic-bootp-backup-
percentage
アトリビュートを設定して、このスコープのバックアップ サーバに対して、より高いパーセンテージのアドレスを割り当てます。このパーセンテージは、通常のバックアップのパーセンテージより 50 パーセント高くできます。

BOOTP リレー

BOOTP リレーをサポートするルータはすべて、通常、DHCP サーバを指すアドレスを持っています。たとえば、Cisco ルータを使用する場合は IP helper-address という語が使われますが、これには固有のマシンに対するアドレスが含まれています。この場合、このアドレスを 使用 して、すべての BOOTP(および DHCP)ブロードキャスト パケットを転送します。このアドレスは、ホストに最も近接しているルータに設定してください。


ヒント クライアントがアドレスを受け取らない場合は、ルータが別の DHCP サーバに設定されているために、Network Registrar DHCP サーバがルータを認識できない可能性があります。その場合は、もう 1 つのヘルパー アドレスを設定して、DHCP サーバもパケットに応答できるようにしてください。


DHCP 転送の設定

Network Registrar を使用して、DHCP ト ラフィックを DHCP サーバ間で転送することができます。たとえば、特定の MAC アドレス プレフィックスを持つ特定のクライアントからのアドレス要求を別の DHCP サーバにリダイレクトできます。これは、転送先のサーバが管理対象のサーバでない状況で役立ち、また重要となります。このような状況は、複数のサービス プロバイダーが同じバーチャル LAN 上でクライアントに DHCP サービスを提供する環境で発生します。

DHCP 転送機能をイネーブルにするには、拡張スクリプトの実装が必要です。DHCP サーバは、指定されたクライアントからの要求を代行受信し、その転送コードを呼び出します。転送コードは、転送先サーバ アドレスの指定リストを調べます。その後、その要求を処理せずに、転送します。 dhcp attachExtension コマンドおよび dhcp detachExtension コマンドを使用して、DHCP サーバに対して拡張機能を追加および削除します。

Network Registrar 拡張機能の制御下で、DHCP トラフィックを DHCP サーバ間で転送することができます。DHCP 転送アトリビュートは、転送先のサーバが管理対象のサーバでない状況では重要でます。このような状況は、多くの場合、複数のベンダーが同じバーチャル LAN 上でクライアントに DHCP サービスを提供する環境で発生します。

DHCP 転送アトリビュートは、次のように機能します。

1. DHCP が初期化されると、サーバは UDP ソケットを開きます。サーバは、このソケットを使用して転送パケットを送信します。複数の IP アドレスを持つサーバをサポートするために、ソケット アドレス ペアは INADDR_ANY と任意のポート番号で構成されます。したがって、クライアントは、サーバのどの IP アドレスでも使用できます。

2. DHCP サーバは、クライアントから要求を受け取ると、次の拡張ポイント スクリプトを処理します。

post-packet-decode

pre-client-lookup

post-client-lookup

DHCP サーバは、これらのスクリプトを処理すると、環境ディクショナリを調べて、次の文字列がないか確認します。

cnr-forward-dhcp-request
 

3. この文字列が見つかり、この文字列が値 true (イネーブル)を持っている場合、サーバはその転送コードを呼び出します。

4. 転送コードは、環境ディクショナリを調べて、次のキーを持つ文字列がないか確認します。

cnr-request-forward-address-list
 

転送コードは、次の例のように、コロンで区切られたオプションのポート番号を持つ、カンマで区切られた IP アドレスのリストを必要とします。

192.168.168.15:1025,192.168.169.20:1027
 

デフォルトでは、サーバはポート 67 に転送します。サーバは、クライアント要求全体のコピーを各 IP アドレスおよびポートに次々に送信します。リスト内に無効な要素があった場合、サーバはリストの解析を停止します。

5. 転送コードが戻った後、サーバは要求の処理を停止します。ただし、post-client-lookup 拡張ポイント スクリプトでは、これを行うことにより、client-entry 詳細を含むオプションのログ メッセージが作成されることがあります。

TCL 拡張スクリプトの一部である次の例では、要求内の情報に基づいて別のサーバに要求を転送するよう DHCP サーバに指示しています。同じ環境内に複数のデバイス プロビジョニング システムが存在する場合、このようなスクリプトを使用できます。この場合、ルータがブロードキャスト要求を転送する先の DHCP サーバ上で拡張スクリプトを実行します。スクリプトは、ほかのどのサーバ(存在する場合)が要求を処理するかを決定し、要求を転送するよう元のサーバに指示します。

次のスクリプトの例では、MAC アドレス プレフィックスのスタティック マッピングを使用して、特定のベンダーのモデムからの要求を特定のシステムに送信しています。

proc postPktDecode {req resp env} {
set mac [$req get chaddr]
set addrs ""
;# Very simple, static classifier that forwards all requests from devices
;# with a vendor-id of 01:0c:10 to the DHCP servers at 10.1.2.3 and 10.2.2.3:
switch -glob -- $mac {
01:0c:10* {
set addrs "10.1.2.3,10.2.2.3"
}
}
;# If we decide to forward the packet, the $addrs var will have the IP addresses
;# where to forward the packet:
if {$addrs != ""} {
;# Tell the DHCP server to forward the packet...
$env put cnr-forward-dhcp-request true
;# ...and where to forward it:
$env put cnr-request-forward-address-list $addrs
;# No more processing is required.
return
}
}
 

より柔軟性の高いスクリプトでは、Network Registrar クライアント エントリなど、クライアントごとのコンフィギュレーション オブジェクトを使用して、要求を取得する DHCP サーバを指定できます。

ベンダー固有の DHCP オプションの設定

ベンダー固有のオプション データを送信して、そのデータを要求する DHCP クライアントに対応できます。サーバは、DHCP オプション 43 でベンダー カプセル化オプションを送信します。各ベンダーは、オプションのデータ部分に特別なシンタックスを持っています。Network Registrar Web UI はオプション 43 をサポートしませんが、CLI はサポートします。

クライアントのベンダー固有オプションを設定する場合、次の 4 つの主な手順(およびそのコマンド)があります。

1. ベンダー固有オプションを作成する: vendor-option name create

2. ベンダー固有のデータ タイプを作成および定義する: option-datatype name create および
defineField

3. 必要なサブオプションとそのデータ タイプを定義する: vendor-option name defineSuboption

4. ポリシー内にベンダー オプション値を設定する: policy name setVendorOption


ステップ 1 DHCP クライアント デバイス ベンダーのマニュアルを調べて、クライアントが DHCP オプション 60 で送信する、デバイスのクラス識別子文字列を確認します。 vendor-option name create コマンド内でこの文字列を使用します。次のコマンドでは、ベンダーがデバイスのクラス識別子に使用する正確な文字列を使用して、device1_vso ベンダー オプションが作成されます。クラス識別子は、各ベンダー オプションに対して一意である必要があります。

nrcmd> vendor-option device1_vso create "device1:Arch:xxxxxx:UNDI:yyyzzz"
 

ステップ 2 DHCP クライアント デバイスが要求する DHCP オプション 43 データの形式を指定します。形式は、単なる IP アドレスから複数のサブオプションまで多岐にわたります。各サブオプションは、データ タイプおよび対応するデータを持ちます。Network Registrar は、サブオプション番号を使用してサブオプション データを順番に並べ、クライアントに返すパケットを形成します。サブオプションは、標準の DHCP データ タイプを持つことも、複雑なベンダー固有のデータ タイプを持つこともできます。

すべてのサブオプション番号とそのデータ タイプを列挙します。BYTE、STRING、INT など、標準のデータ タイプを使用する場合は、ステップ 4 に進みます。複数のベンダー データ タイプや、より複雑なベンダー データ タイプを使用する場合は、option-datatype を定義する必要があります。たとえば、suboption_8 は、デバイスで使用できるブート サーバ アドレスの配列を保持し、特別な配列データ タイプを必要とします。

まず、 option-datatype name create コマンドを使用して、 option-datatype を作成します。その後、
option-datatype name defineField コマンドを使用して、データ タイプ フィールドを定義します。
suboption_8 に適用する device1_suboption_8 データ タイプの例では、最初のフィールド
boot_server_type が WORD データ タイプを持ちます。2 番目のフィールド boot_server_IP_list は、カウント配列内で IPADDR データ タイプを持ちます。次のように、最後のコマンドで enable read-only アトリビュートを使用すると、以後この定義に変更を加えることができなくなります。

nrcmd> option-datatype device1_suboption_8 create
nrcmd> option-datatype device1_suboption_8 defineField boot_server_type 1 WORD
nrcmd> option-datatype device1_suboption_8 defineField boot_server_IP_list 2 IPADDR_ARRAY
counted-array
nrcmd> option-datatype device1_suboption_8 enable read-only
 

これらの複雑な option-datatypes は、次の手順の vendor-option コマンドでのみ使用でき、 custom-option コマンドでは使用できないことに注意してください。

ステップ 3 データ タイプまたはそのフィールドを表示または一覧表示することによって、設定を確認します。必要に応じて、フィールドの定義解除または再定義を行います。あるいは、データ タイプを削除してもう一度初めからやり直します(フィールドの定義解除または再定義を行う場合は、まずサブオプションに対する読み取り専用をディセーブルにします)。コマンドは次のとおりです。

nrcmd> option-datatype device1_suboption_8 show
nrcmd> option-datatype list
nrcmd> option-datatype listnames
nrcmd> option-datatype device1_suboption_8 listFields
nrcmd> option-datatype device1_suboption_8 disable read-only
nrcmd> option-datatype device1_suboption_8 undefineField boot_server_type
nrcmd> option-datatype device1_suboption_8 delete
 

ステップ 4 列挙したサブオプション番号に基づいて、 vendor-option name defineSuboption コマンドを使用して各サブオプションを定義し、適切なデータ タイプに割り当てます。サブオプションが標準のデータ タイプを持つ場合は、次のように、標準のデータ タイプを指定してこのコマンドの簡単なバージョンを使用できます。

nrcmd> vendor-option standard_type create "device1:Arch:xxxxxx:UNDI:yyyaaa"
nrcmd> vendor-option standard_type defineSuboption suboption_1 1 IPADDR
 

ただし、device_1_vso の例では、クライアントがサーバから複数のサブオプションを配列として返されることを期待します。この場合は、ステップ 2 で作成した特別な device1_suboption_8
option-datatype
を使用して、suboption_8 を定義します(前の手順でこのサブオプションを削除したため、再び作成する必要があります)。 次のように、array フラグを使用すると、ステップ 5 でサブオプションの複数のインスタンスを設定できます。

nrcmd> option-datatype device1_suboption_8 create
nrcmd> vendor-option device1_vso defineSuboption suboption_8 8 device1_suboption_8 array
 

一部の DHCP クライアントはサブオプションを要求しませんが、その場合でも番号 1 で 1 つのサブオプションを定義する必要があることに注意してください。その後、 no-suboption-opcode フラグを使用して、サブオプションが追加されないようにします。次の例では、サブオプションに標準の STRING データ タイプを使用しています。

nrcmd> vendor-option no_opt create "device1:Arch:xxxxxx:UNDI:yyyxxx"
nrcmd> vendor-option no_opt defineSuboption suboption_1 1 STRING no-suboption-opcode
 

次のように、サブオプションの定義を解除することもできます。

nrcmd> vendor-option no_opt undefineSuboption suboption_1
 

ステップ 5 ポリシーに各サブオプション値を設定します。値を設定するには、 policy name setVendorOption コマンドを使用します。設定を解除するには、 policy name unsetVendorOption コマンドを使用します。標準のデータ タイプで作成したサブオプションの場合は、サブオプションに値を直接設定できます。その後、次のようにベンダー オプションを一覧表示します。

nrcmd> policy default setVendorOption standard_type suboption_2 "string-data"
nrcmd> policy default listVendorOptions
 

複雑な配列の例では、配列のインデックス値を指定する必要があります。配列の定義には、次のように、中カッコと大カッコに囲まれた特別なサブオプション インデックス シンタックス { suboption [ index ]} が必要です。

nrcmd> policy network-1.2.3 setVendorOption device1_vso {suboption_8[0]}
boot_server_type 2
nrcmd> policy network-1.2.3 setVendorOption device1_vso {suboption_8[0]}
boot_server_IP_list 192.168.25.4,192.168.25.5
nrcmd> policy network-1.2.3 setVendorOption device1_vso {suboption_8[1]}
boot_server_type 8
nrcmd> policy network-1.2.3 setVendorOption device1_vso {suboption_8[1]}
boot_server_IP_list 192.168.25.6
 

この例では、network-1.2.3 ポリシーが、device1_vso に対して次の suboption_8 配列要素値を設定しています。

a. 配列要素 0 boot_server_type フィールド:タイプ 2(Microsoft Windows ブート サーバ)

b. 配列要素 0 boot_server_IP_list フィールド:Windows ブート サーバ アドレスのリスト

c. 配列要素 1 boot_server_type フィールド:タイプ 8(HP OpenView ブート サーバ)

d. 配列要素 1 boot_server_IP_list フィールド:OpenView ブート サーバ アドレスのリスト

ステップ 6 結果を表示または一覧表示します。期待した結果でない場合は、ベンダー オプションを削除して、もう一度初めからやり直します。ベンダー オプションは、デフォルトで、書き込み可能です。各ベンダー オプションを読み取り専用に変更するには、次のように入力します。

nrcmd> vendor-option listnames
nrcmd> vendor-option list
nrcmd> vendor-option standard_type show
nrcmd> vendor-option no_opt delete
nrcmd> vendor-option standard_type enable read-only
 


 

詳細サーバ パラメータの定義

カスタム DHCP オプションなど、詳細 DHCP サーバ パラメータを設定できます。

詳細 DHCP サーバ パラメータの設定

表 14-1 で、ローカル クラスタ Web UI および CLI で設定できる詳細 DHCP サーバ パラメータについて説明します。

 

表 14-1 DHCP の詳細パラメータ

詳細パラメータ
アクション
説明

max-dhcp-requests

設定/
設定解除

DHCP クライアントおよびフェールオーバー パートナーからのパケットの受け取り用に DHCP サーバが割り当てるバッファの数を制御します。この設定が大きすぎると、DHCP アクティビティのバーストにより、処理される前に古くなった要求でサーバの動作が妨げられることがあります。その結果、処理負荷が増大し、クライアントが新しいリースを取得しようとするときにパフォーマンスが著しく低下することがあります。バッファの設定が小さいと、要求が抑制され、サーバのスループットに影響が及ぶことがあります。

非フェールオーバー配置では、デフォルト設定で十分です。フェールオーバー配置では、DHCP ログが、使用中の要求バッファの数について一貫して高い値を示す場合は、この設定を 1000 に増やすことができます。その後、DHCP 応答の数
max-dhcp-responses パラメータを参照)を要求バッファの 4 倍に変更することも必要です。

LDAP クライアント ルックアップを使用する場合は、バッファが、LDAP 接続の合計数と各接続で許可される要求の最大数によって定義される LDAP ルックアップ キュー サイズを超えないようにする必要があります。LDAP キュー サイズを、クライアント ルックアップに対応する LDAP サーバの容量と一致するように設定します。

必須。デフォルトは 500 バイトです。

max-dhcp-responses

設定/
設定解除

DHCP クライアントへの応答および DHCP パートナー間のフェールオーバー通信用に DHCP サーバが割り当てる応答バッファの数を制御します。

非フェールオーバー配置では、要求バッファの 2 倍であるデフォルト設定で十分です。フェールオーバー配置では、この数を要求バッファの 4 倍に増やすことができます。通常は、応答バッファの数を増やしても悪影響はありませんが、この数を上記の推奨値よりも小さくすると、サーバの応答性に悪影響が及ぶ可能性があります。

必須。デフォルトは 1000 バイトです。

max-ping-packets

設定/
設定解除

Ping address before offering it オプションをスコープ レベルでイネーブルにすると、パケット バッファは ICMP メッセージの送受信に使用されます。PING をイネーブルにする場合は、予想される PING 要求のピーク負荷に対処するのに十分な PING パ ケットを割り当てる必要があります。デフォルトは 500 PING パケットです。

hardware-unicast

イネーブル/
ディセーブル

クライアントによるユニキャストの受け入れが可能であると示された場合に、DHCP サーバがブロードキャスト応答ではなくユニキャスト応答を送信するかどうかを制御します。この機能は、Windows NT、Windows 2000、および Solaris プラットフォーム上だけで使用できます。ほかのオペレーティング システムでは、ブロードキャスト応答が送信されます。デフォルトはイネーブルです。

defer-lease-extensions

イネーブル/
ディセーブル

期限が半分以上残っているリースの期限を、DHCP サーバが延長するかどうかを制御します。デフォルトは、オンまたは true です。これは、有効期間が半分以上残っているリースを更新するクライアントは、残っているリース期間だけを取得でき、リース期間は延長されないことを意味します。「リース延長の見送り」を参照してください。

last-transaction-time-
granularity

設定/
設定解除

最終トランザクション時間が厳密であることを保証する秒数を指定します。30 秒未満に設定しないでください。最適なパフォーマンスのためには、リース インターバルの半分よりも大きな値にします。デフォルト設定はありません。

ローカル クラスタ Web UI の場合:


ステップ 1 Primary Navigation バーで、 DHCP をクリックします。

ステップ 2 Secondary Navigation バーで、 DHCP Server をクリックします。

ステップ 3 サーバの名前をクリックします。Edit DHCP Server ページが表示されます。

ステップ 4 このページで、アトリビュートを追加または変更します。

ステップ 5 Modify Server をクリックして、変更を行います。


 

CLI の場合は、 dhcp show および dhcp get コマンドを使用して現行のサーバ パラメータを表示し、その後 dhcp set dhcp unset dhcp enable 、および dhcp disable コマンドを使用して、そのパラメータを変更します( 表 14-1 を参照)。

リース延長の見送り

defer-lease-extensions アトリビュートにより、DHCP サーバは、DHCP トラフィックの突然のフラッドへの対応を最適化できます。このパラメータは、デフォルトでイネーブルになっています。このようなトラフィックの急増を引き起こす可能性のあるネットワーク イベントには、ケーブル Internet Service Provider(ISP; インターネット サービス プロバイダー)のデータ センターでの電源障害があります。電源障害が発生すると、そのプロバイダーの Cable Modem Termination Systems(CMTS; ケーブル モデム終端システム)がすべて同時にリブートします。このような場合、CMTS に接続されているデバイスは、すぐにオンラインに戻るときに、DHCP トラフィックのフラッドを生成します。

defer-lease-extensions アトリビュートをイネーブルにすると、有効期間が半分以上残っているリースを DHCP クライアントが更新する場合、そのリースは完全なリース時間に延長されません。その代わり、クライアントは既存のリースの残りの時間に相当するリースを受け取ります。絶対的なリース期限が変わらないため、サーバは、データベースのアップデートを回避できます。したがって、サーバのスループットが大幅に向上します。

クライアントのリース有効期間が半分未満しか残っていない場合、この設定は効果がなく、通常通り、リースは設定済みの完全なリース インターバルに延長され、データベースへの書き込みも行われます。


) この機能は、リースの変更時にクライアント バインディング情報を固定記憶域にコミットすることを規定している DHCP RFC に準拠しながら、サーバのパフォーマンスを大幅に向上させます。


サーバの観点から、次の 3 つの状況について説明します。

クライアントのリトライ:サーバの処理が遅れると、クライアントは要求を再送信できます。DHCP サーバはその要求を再送信として認識するための十分な情報を持っていないため、各要求の処理を完了し、再び完全なリース期間を与えて、データベースを更新します。サーバの処理がすでに滞っている場合は、余分な作業を行うことによって状況がさらに悪化します。これを防ぐため、DHCP サーバは、 defer-lease-extensions アトリビュートの状態に関係なく、経過時間が 30 秒未満のリースを延長しません。

クライアントのリブート:クライアントのリースの事実上の更新時間は、設定済みの更新時間と、クライアントのリブートとリブートの間の時間のうち、短い方の時間です。つまり、多くの環境では、更新時間として多くの日数が設定されている場合でも、クライアントは、新しいリースを 1 日に 1 回(一般的な企業の場合)または 2 回(一般的なケーブル ネットワークの場合)取得します。 defer-lease-extensions アトリビュートを設定することで、このような早期の更新によりデータベース トラフィックが発生することを防止できます。

作為的な短期更新時間:DHCP サーバがリースに関して主体的に DHCP クライアントにアクセスする方法が存在しないため、かなり短いクライアント更新を設定し、ネットワークの番号変更、アドレスの再割り当て、またはネットワークの再設定(たとえば、DNS サーバのアドレス変更)をタイムリーに行う手段を提供できます。目標は、受け入れ不能なデータベース アップデート オーバーヘッドを招くことなく、このような作業を可能にすることです。

厄介な問題として、サーバはクライアントから最後に連絡のあった時間の記録もとります。サイトは、最終トランザクション時間と呼ばれるこの情報を、デバッグのために使用することがあります。この時間を確実に保持するには、クライアントとの対話のたびにデータベースに書き込みを行う必要があります。 last-transaction-time-granularity アトリビュートを設定することをお勧めします。これは、最終トランザクション時間が厳密であることを Network Registrar が保証する時間(秒数)です。

この値をデフォルトの 60 秒未満に設定しないでください。最適なパフォーマンスのためには、リース インターバルの半分よりも大きな値にします。最終トランザクション時間はプロトコルに必須ではないため、この時間を同期的にアップデートする必要はありません。また、最終トランザクション時間は主にデバッグで使用されるため、完全に正確である必要はありません。さらに、メモリ内コピーは常に正確であるため、データベース内でこのデータが最新でない場合でも、 export leases -server コマンドを使用して、現在の情報を表示できます。

カスタム DHCP オプションの設定

あらかじめ設定されている DHCP オプションに値を割り当てるだけでなく、独自のカスタム オプションを作成できます。

カスタム オプションの追加

ポリシーにカスタム オプションを追加して、その値の割り当てや編集を行うことができます。この機能は、Web UI では使用できません。CLI の場合、カスタム オプションを作成するには、
custom-option name create コマンドを使用します。たとえば、オプション myoption を作成し、100 番に割り当て、タイプを BYTE にするには、次のように入力します。

nrcmd> custom-option myoption create 100 BYTE desc="custom option 100"
 

ヒント DHCP または BOOTP によってすでに使用されている番号を、オプションに割り当てないでください。あらかじめ割り当てられている番号のリストについては、付録 B「DHCP オプション」を参照してください。また、必ず、クライアントが要求する番号と同じものをオプション番号に設定してください。


オプションの値を表示するには custom-option name [ show ] コマンドを使用し、すべてのカスタム オプションの表示または名前だけの一覧表示を行うには custom-option list コマンドを使用します。カスタム オプションの個々のプロパティを表示するには、 custom-option name get コマンドを使用します。カスタム オプションを設定解除することもできます。

カスタム オプションの編集と削除

カスタム オプションを編集または削除することができます。


注意 カスタム オプションのプロパティを変更したり、カスタム オプションを完全に削除したりすると、ポリシーに予期しない副作用がもたらされることがあります。カスタム オプションを削除する場合は、そのオプションを含むポリシーからもそのオプションを削除してください。

この機能は、Web UI では使用できません。CLI の場合は、 custom-option name set コマンドを使用して、オプション タイプ( opttype )または説明( desc )を変更します。カスタム オプションの番号を変更するには、オプションを削除して、新しい番号で作成し直す必要があります。 custom-option name delete コマンドを使用して、オプションを削除します。カスタム オプションを削除した後、
policy
name unsetOption コマンドを使用して、そのオプションを含むすべてのポリシーからそのオプションを設定解除します。

Windows System Management Server の統合

DHCP サーバと Microsoft System Management Server(SMS)を対話させることにより、SMS が DHCP の変更について最新の情報を持つようにすることができます。通常、SMS は、DHCPDISCOVER 要求を介して、ネットワークに参加した新しいクライアントに関するアップデート データをサーバから取得します。ただし、 dhcp updateSms コマンドを使用すると、Network Registrar によりこのアップデートが SMS に適用されます。このコマンドを使用する前に、次の点を確認してください。

SMS クライアントのインストールおよび初期化手順が完了している。

Network Registrar Server Agent が、十分な特権を持つログイン アカウントで実行されるよう設定されている。

SMS サイト ID が正しく、SMS サーバのものと一致している。

次の手順では、Windows SMS を Network Registrar に統合する方法について説明します。


ステップ 1 Network Registrar DHCP サーバと同じマシンに Microsoft BackOffice 4.5 Resource Kit をインストールします。インストレーションに関する指示に従います。その際、デフォルト設定を選択します。

ステップ 2 インストール後、System コントロール パネルの Environment タブで、User Variable 検索パスを次のように変更します。

\program files\ResourceKit\SMS\diagnose
 

ステップ 3 DHCP サーバと SMS サーバが異なるマシン上にある場合は、DHCP サーバと同じマシンに SMS クライアントをインストールします。SMS ライブラリには、SMS サーバとの通信に必要な API コールが含まれています。DHCP サーバ マシンから正しいサイト コードを割り当てる必要があります。Network Neighborhood で、パス \\ SMS-servername \SMSLOGON\x86.bin\00000409\smsman.exe に移動します。

このプログラムを実行し、指示に従います。その際、デフォルト設定を使用します。このプログラムにより SMS および Remote Control という 2 つのアイコンが作成されます。後で、コントロール パネルからこれらのアイコンを使用できます。

ステップ 4 Network Registrar サーバ エージェントを停止してから、十分な権限を持つ信頼されているドメインのアカウントで再起動します。DHCP サーバと SMS サーバの両方が、このアカウントを認識する必要があります。次の短い手順を使用します。

a. ローカル クラスタのサーバ エージェント プロセスを停止します。

b. Network Registrar サービスを実行するアカウントを設定します。信頼されている SMS サイト サーバ グループのメンバーであり、かつ DHCP サーバ マシンの管理者グループのメンバーでもあるアカウント名を作成し、対応するパスワードを割り当てます。

c. ローカル クラスタのサーバ エージェント プロセスを再起動します。

ステップ 5 dhcp set sms-library-path コマンド(またはローカル クラスタ Web UI の Edit DHCP Server ページにある Microsoft Systems Management Server カテゴリの sms-library-path アトリビュート)を使用して、SMS にリース情報を適用するよう DHCP サーバを設定します。SMSRsGen.dll へのフル パスを含めます。値を省略すると、このパスは、デフォルトで、内部サーバにおけるこのファイルのデフォルトの場所になります。

nrcmd> dhcp set sms-library-path /conf/dll
 

Microsoft BackOffice Resource Kit のインストール時に、システム パスは SMS Data Link Library(DLL; データ リンク ライブラリ)の場所を反映するようにアップデートされません。次のいずれかの方法を使用して、このアトリビュートを設定します。

このアトリビュートに相対パスを設定する。次の行を DHCP サーバ マシンのシステム パスに追加します。

sms-install-directory\diagnose
 

その後、 sms-library-path アトリビュートを DLL の名前(smsrsgen.dll など)に設定します。

アトリビュートを設定解除して、システム デフォルトを受け入れることもできます。

このアトリビュートを絶対パスに設定する。システム パスを変更しない場合は、次のアトリビュートを DDL の場所の絶対パスに設定します。

"\\Program Files\\Resource Kit\\sms\\diagnose\\smsrsgen.dll"
 

ステップ 6 sms-network-discovery DNS アトリビュートを 1 に設定して、SMS ネットワーク ディスカバリをオンにします。デフォルトの 0 を使用すると、SMS ネットワーク ディスカバリがディセーブルになります。

ステップ 7 sms-site-code DHCP サーバ アトリビュートを設定して、ステップ 3 で入力した SMS サイト コードを入力します。デフォルトの文字列は空ですが、データ ディスカバリを正常に行うためには、サイト コードを入力する必要があります。

ステップ 8 sms-lease-interval アトリビュートを設定して、SMS リース インターバル値を入力します。このリース インターバルは、SMS にアドレスを送信する間隔、つまり server dhcp updateSms コマンドの実行時に、DHCP サーバが SMS サーバに次のリースを適用する前に待つ必要のある時間(ミリ秒)です。初期のバージョンの SMSRsGen.dll ファイル(SMS Version 2.0)では、SMS が 1 秒(1000 ms)以内に複数のアップデートを確実に受信することができませんでした。したがって、デフォルト値は 1.1 秒(1100 ms)に設定されていました。強化されたバージョンの SMSRsGen.dll ファイルを含む将来のバージョンの Microsoft BackOffice Resource Kit をインストールする場合は、この間隔を減らし、0 に設定して、パフォーマンスを向上させます。

ステップ 9 DHCP サーバをリロードし、name_dhcp_1_log ファイルを調べて、ロードに成功したかどうか確認します。

ステップ 10 CLI の場合は、 server dhcp updateSms コマンドを使用して、SMS 処理を開始します。このコマンドでは、オプションの all キーワードを指定して、リースされているすべてのアドレスを DHCP サーバから SMS に送信できます。このキーワードを省略すると、DHCP サーバは、このコマンドが最後に実行された後にアクティブになった新しいリースだけを送信します(このコマンドの処理中に DHCP サーバをリロードした場合、DHCP サーバを再起動するまで、リロードが再開されません)。その後、DHCP ログと SMS ログの両方が、正常な完了を示していることを確認します。


 

拡張機能の使用による DHCP サーバの動作への影響

Network Registrar には、 拡張機能 TCL または C/C++ で記述できるプログラム)を介して DHCP サーバの動作を変更およびカスタマイズする機能が備わっています。

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

次のいずれかの拡張機能を記述することによって、2 つの IP アドレスの問題を解決できます。

DHCP サーバがトークン リング(6)ハードウェア タイプのパケットをドロップするようにする拡張機能。

トークン リング パケットをインターネット パケットに変更し、終了時に再びトークン リング パケットに戻す拡張機能。この拡張機能は複雑ですが、DHCP クライアントは DHCP サーバからのどちらかのリターンを使用できます。

拡張機能は、TCL または C/C++ で記述できます。

TCL:拡張機能の記述を少し簡単かつ迅速にします。拡張機能が短い場合は、TCL のインタープリタ型の性質によってパフォーマンスに重大な影響が及ぼされることはありません。拡張機能を TCL で記述すると、サーバをクラッシュさせる可能性のあるバグの発生が少なくなります。

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

特定の 拡張ポイント に拡張機能を作成します。拡張ポイントには、要求、応答、および環境という 3 つのタイプのディクショナリが用意されています。各拡張ポイントは、これらのディクショナリを 1 つまたは複数使用できます。拡張ポイントを次に示します。

1. init-entry :DHCP サーバが拡張機能を設定または設定解除するときに呼び出す拡張ポイント。これは、サーバを起動、停止、またはリロードするときに発生します。このエントリ ポイントは、拡張機能に対してほかのエントリ ポイントと同じシグニチャを持ちます。使用されるディクショナリ:環境のみ。

2. post-packet-decode :入力パケットをリライトするために使用します。使用されるディクショナリ:要求および環境。

3. post-class-lookup :クライアントクラスでの client-class-lookup-id 処理の結果を評価するために使用します。使用されるディクショナリ:要求および環境。

4. pre-client-lookup :ルックアップを阻止したり、既存のデータを上書きするデータを提供したりすることにより、ルックアップされるクライアントに影響を及ぼすために使用します。使用されるディクショナリ:要求および環境。

5. post-client-lookup :クライアントクラス処理から入力された内部サーバ データ構造を調べるなど、クライアントクラスのルックアップ プロセスの処理を調べるために使用します。DHCP サーバが追加の処理を行う前に、任意のデータを変更するためにも使用できます。使用されるディクショナリ:要求および環境。

6. check-lease-acceptable :リース受け入れ可能性テストの結果を変更するために使用します。これを使用する際には、細心の注意を払ってください。使用されるディクショナリ:要求、応答、および環境。

7. lease-state-change :リース状態が変わるときを特定するために使用します。使用されるディクショナリ:応答および環境。

8. pre-packet-encode :応答として DHCP クライアントに送信されるデータを変更するため、または DHCP 応答の送信先となるアドレスを変更するために使用します。使用されるディクショナリ:要求、応答、および環境。

9. pre-dns-add-forward :DNS 転送(A レコード)要求に使う名前を変更するために使用します。使用されるディクショナリ:環境のみ。

10. post-send-packet :DHCP 要求応答サイクルの厳しい時間制約外で実行する処理のためにパケットの送信後に使用します。使用されるディクショナリ:要求、応答、および環境。

DHCP サーバを拡張するには、次の作業を行います。


ステップ 1 Tcl、C、または C++ で拡張機能を記述し、次の場所にあるサーバ拡張ディレクトリにインストールします。

UNIX:Tcl の場合は、/opt/nwreg2/extensions/DHCP/tcl
C または C++ の場合は、/opt/nwreg2/extensions/DHCP/dex

Windows:Tcl の場合は、\program files\Network Registrar\extensions\dhcp\tcl
C または C++ の場合は、\program files\Network Registrar\extensions\dhcp\dex

TCL 拡張機能または C/C++ 拡張機能用の適切なディレクトリに拡張機能を配置することをお勧めします。その後、ファイル名を設定するときに、スラッシュ(/)もバックスラッシュ(\)も付けずにファイル名だけを入力します。

拡張機能をサブディレクトリに配置する場合は、パス セパレータを付けてファイル名を入力します。パス セパレータは、DHCP サーバを実行するオペレーティング システムによって異なります。


) Windows NT 上でバックスラッシュ(\)を含むファイル名を入力する場合は、CLI ではバックスラッシュ(\)がエスケープ文字であるため、2 つのバックスラッシュ(\\)とともにファイル名を入力する必要があります。たとえば、ファイル名 debug\myextension.tcl は、debug\\myextension.tcl と入力します。


ステップ 2 extension コマンドを使用して、この拡張機能を認識するよう DHCP サーバを設定します。

ステップ 3 dhcp attachExtension コマンドを使用して、設定した拡張機能を 1 つまたは複数の DHCP 拡張ポイントに追加します。

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


 

DHCP サーバのトラブルシューティング

サーバ プロパティの変更後は、必ずサーバをリロードしてください。

DHCP のパフォーマンスを調整する場合に役立つその他のヒントを次に示します。

最適なスループットを得られるように要求バッファ( max-dhcp-requests )と応答バッファ( max-dhcp-responses )を設定する。詳細については、表 14-1を参照してください。

defer-lease-extensions アトリビュートをイネーブルにしておく。これにより、データベースへの書き込みが減少します。

last-transaction-time-granularity アトリビュートを少なくとも 60 秒、最適なパフォーマンスのためにはリース インターバルの半分よりも大きな値に設定する。

実稼働リースを提供するポリシーでは、 allow-lease-time-override アトリビュートをディセーブルにする。

DHCP ログ設定からの選択を行い、既存のログ メッセージをより強力に制御する。 表 14-2 に記載されている DHCP サーバの ログ設定 アトリビュートを 1 つ以上使用します。

 

表 14-2 DHCP ログ設定

ログ設定(対応する数値)
説明

default(1)

低レベルの DHCP ロギングを表示します(デフォルト設定)。

incoming-packets(2)

着信 DHCP パケットごとに個別の行を記録します(デフォルト)。

missing-options(3)

クライアントによって期待される欠落ポリシー オプションを表示します(デフォルト)。

incoming-packet-detail(4)

incoming-packets と同じですが、人間が読める形式です。

outgoing-packet-detail(5)

各着信 DHCP パケットを人間が読める形式で記録します。

unknown-criteria(6)

クライアント エントリが、そのクライアントの現在のネットワーク ロケーションに適切なスコープで見つからない selection-criteria または selection-criteria-excluded を持つ場合は、必ず記録します。

dns-update-detail(7)

送信および応答された各 DNS アップデートを記録します。

client-detail(8)

各クライアントクラス クライアントのルックアップ処理の後、クライアントおよびそのクライアントクラスに対して見つかったデータの複合体を記録します。クライアントクラス コンフィギュレーションを設定する場合、およびクライアントクラス処理における問題をデバッグする場合に役立ちます。

client-criteria-processing(9)

使用可能なリースを見つけるため、またはすでにリースを持っているクライアントにリースが受け入れ可能かどうかを判断するためにスコープが調べられるたびに記録します。クライアントクラスのスコープ基準処理を設定またはデバッグする場合に非常に役立ちます(適度な量の情報が記録されます。イネーブルのままにすることはお勧めしません)。

failover-detail(10)

フェールオーバー アクティビティを詳細に記録します。

ldap-query-detail(11)

DHCP サーバが LDAP サーバに対する照会を開始し、応答を受け取り、結果またはエラー メッセージを取得するたびに記録します。

ldap-update-detail(12)

DHCP サーバが LDAP サーバに対するアップデート リース状態を開始し、応答を受け取り、結果またはエラー メッセージを取得するたびに記録します。

ldap-create-detail(13)

DHCP サーバが LDAP サーバに対するリース状態エントリの作成を開始し、応答を受け取り、結果またはエラー メッセージを取得するたびに記録します。

leasequery(14)

ACK または NAK で応答された各リース照会パケットのメッセージを記録します。

dropped-waiting-packets(15)

max-waiting-packets の値が 0 でない場合、IP アドレスのキューの長さがこの値を超えると、パケットがドロップされます。 dropped-
waiting-packets
が設定されている場合、サーバは、IP アドレスのキューから待機パケットをドロップするたびに記録します。

no-success-messages(16)

成功の発信応答パケットを記録しません。

no-dropped-dhcp-packets(17)

ドロップされた DHCP パケットを記録しません。

no-dropped-bootp-packets(18)

ドロップされた BOOTP パケットを記録しません。

no-failover-activity(19)

フェールオーバーに対する通常のアクティビティおよびいくつかの警告メッセージを記録しません。ただし、重大なエラー ログ メッセージは引き続き記録されます。

activity-summary(20)

5 分ごとのサマリー メッセージの記録(次に示す no- タイプのフラグが設定されている場合に役立ちます)、前の期間のアクティビティの表示( dhcp set-activity-summary-interval コマンドを使用してこの期間を調整できます)をイネーブルにします。

no-invalid-packets(21)

無効なパケットを記録しません。

no-reduce-logging-when-
busy(22)

受信バッファが 66% に達しても記録を減らしません。

no-timeouts(23)

リースおよび提示のタイムアウトを記録しません。

minimal-config-info(24)

ログ内のコンフィギュレーション メッセージの数を減らします。

no-failover-conflict(25)

フェールオーバー パートナー間の競合を記録します。

mcd-blobs-per-bulk-read アトリビュートの値を変更して、DHCP の起動およびリロード時間を調整する。通常、 mcd-blobs-per-bulk-read アトリビュートの値を大きくすると、サーバの起動およびリロード時間が短くなりますが、多くのメモリを消費します。 mcd-blobs-per-bulk-read DHCP サーバ アトリビュートを使用して、1 ~ 2500 の任意の数値を設定できます。現在のデフォルトは 256 ブロブです。