Cisco Network Registrar ユーザー ガイド 7.0
DHCP サーバの詳細プロパティ
DHCP サーバの詳細プロパティ
発行日;2012/01/16 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 9MB) | フィードバック

目次

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

BOOTP の設定

BOOTP について

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

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

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

BOOTP リレー

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

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

リース延長の見送り

Windows System Management Server の統合

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

拡張機能の記述

拡張機能を使用した、パケット送信量の過大なクライアントの抑制

DHCP サーバの調整

バーチャル プライベート ネットワークの設定とサブネット割り振り

DHCP を使用したバーチャル プライベート ネットワークの設定

一般的なバーチャル プライベート ネットワーク

バーチャル プライベート ネットワークの作成と編集

VPN の使用

DHCP のサブネット割り振りの設定

VPN とサブネット割り振りの調整パラメータ

DHCP 転送の設定

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

この章では、DHCP サーバのいくつかの詳細プロパティのセットアップ方法について説明します。クライアントがアドレスの割り当てに DHCP を使用できるようにするには、少なくとも 1 つのスコープをサーバに追加する必要があります。これについては、 第20章「スコープとネットワークの設定」 で説明しています。追加のプロパティは次のとおりです。

「BOOTP の設定」

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

「Windows System Management Server の統合」

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

「DHCP サーバの調整」

「バーチャル プライベート ネットワークの設定とサブネット割り振り」

「DHCP 転送の設定」

BOOTP の設定

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

Cisco 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 :サーバのホスト名

サーバはポリシー階層を検索して、これらのアトリビュート値の最初のインスタンスを探します。

CLI の場合、 policy name setOption は、値の前にスペース(等号ではない)が必要です。

また、必要であれば、BOOTP とダイナミック BOOTP をイネーブルにして、DHCP サーバが BOOTP 要求で DNS サーバを更新するようにします。オプションは次のとおりです。

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

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

update-dns-for-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 クライアントを 1 つのスコープに分離します。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 クライアントが DHCP サーバからアドレスを受信しない場合は、ネットワーク構成、特にルータまたはリレー エージェントの設定をチェックして、ネットワーク デバイスが Network Registrar DHCP サーバ アドレスをポイントするように設定されていることを確認します。


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

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

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

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

 

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

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

max-dhcp-requests

set/
unset

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

高負荷が予想される場合(安定した状態、またはストレス時間が頻繁に発生するとき)、または高速なマルチプロセッサ システムがある場合は、一般にバッファを増加すると効果的です。

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

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

max-dhcp-responses

set/
unset

max-ping-packets

set/
unset

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

hardware-unicast

enable/
disable

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

defer-lease-extensions

enable/
disable

期限が半分以上残っているリースの期限を、DHCP サーバが延長するかどうかを制御します。これはパフォーマンス調整アトリビュートです。リース状態データベースへのディスク書き込み回数を最小限に抑えるために役立ちます。デフォルトは、オンまたは true です。これは、有効期間が半分以上残っているリースを更新するクライアントは、残っているリース期間だけを取得でき、リース期間は延長されないことを意味します。「リース延長の見送り」を参照してください。

last-transaction-time-
granularity

set/
unset

最終トランザクション時間が厳密であることを保証する秒数を指定します。これはパフォーマンス調整アトリビュートです。このアトリビュートにより、サーバは設定された細分性で重複するクライアント アクティビティ(更新など)を無視することで、リース状態データベースへの頻繁なディスク書き込みを防止します。30 秒未満に設定しないでください。最適なパフォーマンスのためには、リース間隔の半分よりも大きな値にします。デフォルトは 60 秒です。

ローカル Basic または Advanced Web UI


ステップ 1 DHCP をクリックしてから DHCP Server をクリックし、Manage DHCP Server ページを開きます。

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

ステップ 3 Edit DHCP Server ページでアトリビュートを追加または修正します。

ステップ 4 Modify Server をクリックして変更を加えます。


 

CLI コマンド

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

リース延長の見送り

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

defer-lease-extensions アトリビュートがイネーブルの場合、DHCP サーバは、クライアントの更新要求のためにリース期限の延長を遅らせることがあり、これは通常 T1 の前(普通はリースの半分を経過する前)に発生します。サーバは、設定されたリース時間のすべてをクライアントに与えるのではなく、既存のリースの残り時間を付与します。絶対的なリース期限が変わらないため、サーバは、データベースのアップデートを回避できます。したがって、サーバのスループットが大幅に向上します。さらに、延長したリース期限に関して、フェールオーバー パートナーを更新しなくても済むという利点もあります。

クライアントが T1 (通常はその有効期限の中間点)にあるか、それを超えている場合は、このアトリビュートをイネーブルまたはディセーブルにしても影響はなく、サーバは常にリース期限の延長を試みます。ただし、フェールオーバーおよび他のプロトコルによる制限を受ける場合は、設定された全期間分だけ、サーバがリースを延長できないことがあります。


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


リース延長を見送る場合、ポリシー アトリビュート allow-lease-time-override をそのデフォルトのディセーブルのままにしておくか、イネーブルの場合はディセーブルに変更することをお勧めします。

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

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

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

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

厄介な問題として、サーバはクライアントから最後に連絡のあった時間の記録もとります。サイトは、最終トランザクション時間と呼ばれるこの情報を、デバッグのために使用することがあります。この時間を確実に保持するには、クライアントとの対話のたびにデータベースに書き込みを行う必要があります。 last-transaction-time-granularity アトリビュートを設定することをお勧めします(表23-1のアトリビュートの説明を参照してください)。最終トランザクション時間は主にデバッグで使用されるため、値が完全に正確である必要はありません。さらに、メモリ内コピーは常に正確であるため、データベース内でこのデータが最新でない場合でも、 export leases -server コマンドを使用して、現在の情報を表示できます。

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 (または 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; データ リンク ライブラリ)の場所を反映するようにアップデートされません。次のいずれかの方法を使用して、このアトリビュートを設定します。

a. sms-library-path アトリビュートを相対パスに設定する。

最初に、システムの PATH 変数を修正して、DLL がインストールされているディレクトリのパスを追加します。

sms-install-directory\diagnose
 

次に、 sms-library-path を DLL の名前(smsrsgen.dll など)に設定します。このアトリビュートを設定しないで、システム デフォルトのままにすることもできます。

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

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

ステップ 6 sms-network-discovery DNS アトリビュートを 1 に設定して、SMS ネットワーク ディスカバリをオンに設定します。

デフォルトの 0 を使用すると、SMS ネットワーク ディスカバリがディセーブルになります。

ステップ 7 ステップ 3 の SMS サイト コードを入力することによって、 sms-site-code DHCP サーバ アトリビュートを設定します。

デフォルトの文字列は空ですが、データ ディスカバリを正常に行うためには、サイト コードを入力する必要があります。

ステップ 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 ログと SMS ログの両方が、正常な完了を示していることを確認します。SMS アップデート中にサーバをリロードすると処理が中断されますが、サーバの再起動後に処理が再開されることに注意してください。


 

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

Network Registrar には、 拡張機能 TCL または C/C++ で記述できるプログラム)を介して DHCP サーバの動作を変更およびカスタマイズする機能が備わっています。拡張機能は、要求パケットまたは応答パケットを修正するか、環境ディクショナリに保存されている環境変数を使用するという、2 つの方法でサーバと対話します(詳細については、 第29章「拡張ポイントの使用」 を参照してください)。

たとえば、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 サーバが拡張機能を設定または設定解除するときに呼び出す拡張ポイント。これは、サーバを起動、停止、またはリロードするときに発生します。このエントリ ポイントは、拡張機能に対して他のエントリ ポイントと同じシグニチャを持ちます。DHCPv6 の処理に必要です。ディクショナリ:環境のみ。

2. pre-packet-decode :要求が到着したときに DHCP サーバが最初に検出し、パケットのデコード前に呼び出す拡張ポイントです。ディクショナリ:要求および環境。

3. post-packet-decode :入力パケットをリライトします。ディクショナリ:要求および環境。

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

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

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

7. generate-lease :DHCPv6 アドレスまたはプレフィックスを生成および制御します。ディクショナリ:要求、応答、および環境。

8. check-lease-acceptable :リース受け入れ可能性テストの結果を変更します。これは、非常に注意して行ってください。ディクショナリ:要求、応答、および環境。

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

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

11. post-packet-encode :パケットをクライアントに送信する前、またはドロップする前に、サーバがパケットを検査および変更できるようにします。ディクショナリ:要求、応答、および環境。

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

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

14. environment-destructor :保持しているコンテキストを拡張機能でクリーンアップできるようにします。ディクショナリ:環境。

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


ステップ 2 この拡張機能を認識するように DHCP サーバを設定するには、List DHCP Extensions ページを Web UI で使用し(図23-1を参照)、CLI では extension コマンドを使用します。

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

 

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

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


 

拡張機能を使用した、パケット送信量の過大なクライアントの抑制

拡張機能の効果的な使用例の 1 つが、不必要なトラフィックでサーバをフラッドするクライアントに対する保護です。ChattyClientFilter 拡張機能を使用すると、このようなパケット送信量の過大なクライアントのパケットを処理する作業のほとんどを、サーバが実行しなくても済むようにすることができます。ネットワークに多数のクライアントがある場合は、この拡張機能の実装を検討してください。

ChattyClientFilter 拡張機能は、Network Registrar インストール先の /examples/dhcp/dex ディレクトリにあり、コンパイル済みの /extensions/dhcp/dex/dexextension.so または
/extensions/dhcp/dex/dexextension.dll が使用できるようになっています。この拡張機能は、MAC アドレスに基づいてクライアント要求を監視し、一定の時間間隔内で特定の数を超えるパケットをクライアントが生成する場合に、そのクライアントをディセーブルにします。クライアントをディセーブルにするというのは、サーバがそのクライアントからのパケットを破棄するということです。ただし、サーバは、クライアントからのトラフィックを監視し続けるので、クライアントを完全に無視するわけではありません。ある時間内にクライアントが生成するパケット数が、一定の数未満になったことをサーバが検出すると、サーバはクライアントを再びイネーブルにして、そのクライアントからのパケットの受信を再開します。

ディセーブル化とイネーブル化の条件は、ChattyClientFilter 拡張機能に対する引数を使用して設定します。デフォルトでは、サーバは、30 秒以内に 16 個以上のパケットを受信するとそのクライアントをディセーブルにし、クライアントが送信するパケット数が 10 秒間に 4 個以下になると、そのクライアントを再びイネーブルにします。このデフォルトは控えめな設定であり、すべての状況で保護されるわけではありません。たとえば、サーバは、3 秒ごとにパケットを送信するクライアントをディセーブルにしません。少々の再送信が発生する可能性はありますが、短期間に 6 個以上のパケットを、クライアントが送信する必要はありません。

クライアントのパケット送信量が多すぎる可能性がある場合は、DHCP サーバのログを調べて着信率を確認し、ChattyClientFilter コードに次の引数を適切に設定してください。

-h packet-count :SampleHitsToDisable。デフォルトは 15 パケットです。

-i seconds :SampleTimeInterval。デフォルトは 30 秒です。

-l packet-count :QuietHitsToLeaveDisabled。デフォルトは 5 パケットです。

-q seconds :QuietTimeInterval。デフォルトは 10 秒です。

-s :ドロップされたパケットを無条件で破棄します。デフォルトはオフです。

-n :更新または再バインドの場合に、クライアントに否定応答します。デフォルトはオフです。SampleHitsToDisable のレートを超えているクライアントが DHCPREQUEST を実行した場合、サーバはパケットを破棄する代わりに DHCPNAK をクライアントに送信します。これにより、何らかの理由でリースを更新できないクライアント(ケーブル モデムなど)の問題を解決できる場合があります。DHCPNAK が送信されると、クライアントは DHCP ステート マシンを再起動して、DHCPDISCOVER を送信します。この引数を使用する場合は、ChattyClientFilter を check-lease-acceptable 拡張ポイントにも追加してください。

-r seconds :統計レポート間隔。デフォルトは 300 秒(5 分)です。この引数は、ディセーブル化および再イネーブル化されたクライアントの数を定期的にロギングする頻度を制御します。

引数の設定方法および拡張機能をイネーブルにする方法については、ChattyClientFilter.cpp ファイル内のコメントを参照してください。多くの場合、 post-packet-decode 拡張ポイントに拡張機能を追加します( -n 引数を使用する場合は、 check-lease-acceptable にも追加します)。

DHCP サーバの調整

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

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

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

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

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

ロギングとデバッグの設定を最小限にする。ロギングが必要な場合、 表23-2 の説明に従って、特定の数のアトリビュートとともに DHCP サーバの log-settings アトリビュートを使用します。

 

表23-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)

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

atul-detail(26)

DHCP サーバが ATUL プロトコル サーバから Address-to-User Lookup(ATUL)パケットを受信すると、メッセージを記録します。

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

クライアント キャッシュを設定することを検討する(「クライアント キャッシュ パラメータの設定」を参照)。

サーバのパフォーマンスを監視するためにサーバの統計を確認する(「統計の表示」を参照)。

スコープ割り振り優先度を設定することを検討する(「割り振り優先度を使用した複数スコープの設定」を参照)。

アドレスの提供前にホストに PING を送る場合、PING タイムアウト期間の調整を検討する(「アドレスを提供する前のホストの PING」を参照)。

パフォーマンスを改善するために、スコープ選択タグの個数を制限することを検討する。

Lightweight Directory Access Protocol(LDAP)サーバを使用する場合、「Network Registrar での LDAP の使用の設定」で説明しているパフォーマンス上の問題を検討する。

DHCP フェールオーバーを使用する場合、ロード バランシング機能の使用を検討する(「ロード バランシングの設定」を参照)。


ヒント DHCP サーバ アトリビュートの変更後は、必ずサーバをリロードしてください。


バーチャル プライベート ネットワークの設定とサブネット割り振り

この項では、Virtual Private Network(VPN; バーチャル プライベート ネットワーク)、およびオンデマンド アドレス プールのサブネット割り振りをサポートするよう Cisco Network Registrar DHCP サーバを設定する方法について説明します。

VPN の設定には、通常の DHCP ホスト IP アドレス指定の調整が含まれます。VPN は、インターネット上で一意ではない可能性のあるプライベート アドレス空間を使用します。このため、Network Registrar は、VPN 識別情報によって区別される IP アドレスをサポートします。ルータ上のリレー エージェントもこの機能をサポートする必要があります。VPN 識別情報により、クライアントが所属する VPN が選択されます。DHCP の VPN は、現在、Cisco IOS ソフトウェアだけでサポートされています。最新バージョンの Cisco IOS では、リレーされる DHCP メッセージ内に VPN ID を含めることができます。

サブネット割り振り、サブネットをクライアント(通常は、ルータまたはエッジ デバイス)にリースすることで、クライアントが逆に DHCP サービスを提供できるようにするための方法です。これは、個々のクライアント アドレスを管理しながら行うことも、管理せずに行うこともできます。サブネット割り振りは、サブネットのダイナミックな管理を DHCP インフラストラクチャに依存することにより、IP アドレスのプロビジョニング、集約、特性付け、および配布の機能を大幅に向上させることができます。DHCP を介したサブネット割り振りは、現在 Cisco IOS ソフトウェアだけでサポートされています。最新バージョンの Cisco IOS には、オンデマンド アドレス プール機能が組み込まれています。

DHCP を使用したバーチャル プライベート ネットワークの設定

作成する VPN は、次の操作に対応したフィルタリング メカニズムを備えています。

統合されたアドレス空間の表示(「アドレス空間の表示」を参照)

アドレス ブロックの一覧表示(「アドレス ブロックの追加」を参照)

サブネットの一覧表示(「アドレス ブロックとサブネット」を参照)

サブネット使用状況のクエリー(「サブネット使用状況履歴レポートの生成」を参照)

リース履歴のクエリー(「IP Lease History レポートの実行」を参照)

VPN を設定しない場合、Network Registrar は、0 のグローバル VPN を各スコープ上で使用します。

クライアントがリレー エージェントを使用して DHCP サーバに IP アドレスを要求できるように VPN を設定するには、VPN を定義して、スコープをその VPN に関連付ける必要があります。具体的には、次の作業を行います。

1. DHCP VPN トラフィックを処理するリレー エージェントに Cisco IOS ソフトウェアが設定されており、その Cisco IOS のバージョンが DHCP の relay-agent-info オプション(82)の vpn-id サブオプションをサポートすることを確認します。

2. Cisco IOS リレー エージェントの管理者と協力して、VPN が VPN ID によって識別されるか、VPN Routing and Forwarding instance(VRF; VPN ルーティング/転送インスタンス)名によって識別されるかを決定します。

3. VPN にスコープを作成します。

一般的なバーチャル プライベート ネットワーク

VPN blue の一部として DHCP クライアント 1 が存在し、VPN red 内に DHCP クライアント 2 が存在する一般的な VPN シナリオを、図19-4に示します。たとえば、VPN blue 内の DHCP クライアント 1 と VPN red 内のクライアント 2 の両方が同じプライベート ネットワーク アドレス 192.168.1.0/24 を持っています。DHCP リレー エージェントは、2 つの VPN の内部にもグローバル VPN にもゲートウェイ アドレスを持っています(172.27.180.232)。2 つのフェールオーバー DHCP サーバが存在し、その両方が外部ゲートウェイ アドレスによってリレー エージェントを認識しています。

サーバが VPN サポート アドレスをクライアントに発行する場合の処理は、次のとおりです。

1. DHCP クライアント 1 が DHCPDISCOVER パケットをブロードキャストします。このパケットには、クライアントの MAC アドレス、ホスト名、および要求するすべての DHCP オプションが含まれています。

2. アドレス 192.168.1.1 の DHCP リレー エージェントが、このブロードキャスト パケットを取得します。このリレー エージェントは、パケットに relay-agent-info オプション(82)を追加し、192.168.1.0 をサブネットとして識別する subnet-selection サブオプションを含めます。パケットには、VPN を blue として識別する vpn-id サブオプションも含まれます。DHCP サーバが要求側のクライアントと直接通信できないため、 server-id-override サブオプションには、クライアントによって認識されるリレー エージェントのアドレス(192.168.1.1)が指定されます。リレー エージェントは、外部ゲートウェイ アドレス giaddr )172.27.180.232 もパケットに追加します。

3. リレー エージェントが、サブネット上に設定されている DHCP サーバに DHCPDISCOVER パケットをユニキャストします。

4. DHCP サーバ 1 がパケットを受信し、 vpn-id サブオプションと subnet-selection サブオプションを使用して、適切な VPN アドレス空間から IP アドレスを割り振ります。DHCP サーバ 1 は、そのサブネットおよび VPN で使用可能なアドレス 192.168.1.37 を見つけ、そのアドレスをパケットの yiaddr フィールド(クライアントに提供するアドレス)に入力します。

5. サーバが、 giaddr 値によって識別されるリレー エージェントに DHCPOFFER パケットをユニキャストします。

6. リレー エージェントが relay-agent-info オプションを削除し、パケットを DHCP クライアント 1 に送信します。

7. DHCP クライアント 1 が、提示された IP アドレスと同じ IP アドレスを要求する DHCPREQUEST メッセージをブロードキャストします。リレー エージェントが、このブロードキャスト メッセージを受信します。

8. リレー エージェントが、DHCPREQUEST パケットを DHCP サーバ 1 に転送し、DHCP サーバ 1 がユニキャスト DHCPACK パケットでクライアントに応答します。

9. リース更新を行う場合は、クライアントが DHCPRENEW パケットを、DHCPACK メッセージの dhcp-server-identifier オプション内の IP アドレスにユニキャストします。これは、リレー エージェントのアドレス 192.168.1.1 です。リレー エージェントは、このパケットを DHCP サーバにユニキャストします。サーバは、最初に元のアドレスを配布したのがそのサーバ自身であるかどうかを必ずしも認識せずに、通常の更新処理を行います。サーバは、ユニキャスト DHCPACK パケットで応答します。その後、リレー エージェントが DHCPACK パケットを ciaddr フィールドの値によって識別されるクライアント IP アドレスに転送します。

relay-agent-info オプション(82)の server-id-override サブオプションが存在する場合、DHCP サーバはその値を応答パケット内で dhcp-server-identifier オプションの値と比較するために使用します。したがって、DHCP クライアントがユニキャストするどのパケットも、サーバではなく、リレー エージェントに直接送信されます(実際、クライアントからサーバにアクセスできない可能性があります)。パケットに server-id-override サブオプションが含まれる場合、フェールオーバー環境にある両方のパートナーがリースを更新できます。

バーチャル プライベート ネットワークの作成と編集

VPN および VPN インデックスを設定するには、次の操作を実行します。


ステップ 1 Cisco IOS リレー エージェントの管理者と協力して、VPN がリレー エージェント上で VPN ID によって設定されるか、VRF 名によって設定されるかを決定します。これによって、Network Registrar で VPN を識別する方法が決まります。

ステップ 2 VPN を作成し、IOS スイッチまたはルータに設定されている VPN への DHCP クライアントのプロビジョニングを許可します。

VPN インデックスを入力します。VPN インデックスには、予約語 all および global を除く任意の一意なテキスト文字列を使用できます。関連付ける ID も一意である必要があります。インデックスを追加するには、次の操作を実行します。

ローカル クラスタ DHCP をクリックしてから VPNs をクリックし、List/Add VPNs ページを開きます(図23-2を参照)。VPN にクラスタでのキー識別番号および一意な名前を指定します。

図23-2 List/Add VPNs ページ(ローカル)

 

リージョナル クラスタ :VPN を含むローカル クラスタを追加します( Clusters をクリックしてから Cluster List をクリックします)。次に、 DHCP Configuration をクリックしてから VPNs をクリックします。この操作により、List/Add VPNs ページが表示されます。このページで VPN を作成するか、あるいはローカル クラスタから VPN を取得することができます。

VPN を作成する場合は、キー識別番号と一意な名前を指定します。

ローカル クラスタから VPN を取得する場合は、List/Add VPNs ページで Pull Replica VPNs をクリックし、選択したクラスタから特定の VPN またはすべての VPN を取得します。

List/Add VPNs ページで Push VPN または Push All VPNs をクリックして、VPN をクラスタに適用することもできます。その場合には Push VPN Data to Local Clusters ページで同期モードと VPN の適用先クラスタを選択します。

CLI の場合 vpn name create key を使用します。次に例を示します。

nrcmd> vpn blue create 99

ステップ 3 VPN ID または VRF 名によって、適切な VPN 識別情報を指定します。両方使用することは、ほとんどありません。

VPN ID を使用する場合は、VPN に vpn-id アトリビュート値を設定します。この値は、通常、IETF RFC 2685 に準拠する oui : index 形式の 16 進数です。この値は、VPN 所有者または ISP に対応する 3 オクテットの VPN Organizationally Unique Identifier(OUI)、次にコロン、その次に VPN 自身の 4 オクテットのインデックス番号が続くという構成です。List/Add VPNs ページに VPN ID 値を追加します。CLI では、 vpn-id アトリビュートを設定します。次に例を示します。

nrcmd> vpn blue set vpn-id=a1:3f6c
 

VPN ルーティング/転送(VRF)インスタンス名を使用する場合は、VPN に vrf-name アトリビュート値を設定します。Cisco ルータは VRF 名を頻繁に使用します。List/Add VPNs ページに VRF Name 値を追加します。CLI では、 vrf-name アトリビュートを設定します。次に例を示します。

nrcmd> vpn blue set vrf-name=framus
 

ステップ 4 VPN の説明を追加します(オプション)。

ステップ 5 Add VPN をクリックします。Edit VPN ページで、VPN を編集して値を変更できます。

ステップ 6 VPN にスコープを作成します。識別しやすいように、VPN 名とスコープ名をできるだけ似たものにします。

DHCP をクリックしてから Scopes をクリックし、List/Add DHCP Scopes ページを開きます。スコープを作成するか、または既存のスコープを編集します。Miscellaneous アトリビュートで、 vpn-id アトリビュートを探します。ドロップダウン リストから、VPN を選択します。

CLI では、次の 3 つの方法のいずれかで、スコープが所属する VPN を指定できます。

VPN 名。 vpn アトリビュート(VPN ID をスコープに適用するアトリビュート)を使用します。

VPN ID 自体。 vpn-id アトリビュートを使用します。

現在のセッションの VPN 名。コマンドラインで、VPN も VPN ID も省略します。

現在のセッションにデフォルトの VPN を設定するには、 session set current-vpn を使用します。その後、スコープの通常のアドレス範囲と必要なオプション プロパティを設定できます。次に例を示します。

nrcmd> scope blue-1921681 create 192.168.1.0 255.255.255.0 vpn=blue
 

または

nrcmd> scope blue-1921681 create 192.168.1.0 255.255.255.0 vpn-id=99
 

または

nrcmd> session set current-vpn=blue
nrcmd> scope blue-1921681 create 192.168.1.0 255.255.255.0
 

その後

nrcmd> scope blue-1921681 addRange 192.168.1.101 192.168.1.200
nrcmd> scope-policy blue-1921681 setOption routers 192.168.1.1
 

ステップ 7 ステージ スコープ編集モードの場合は、すべての VPN とスコープを作成してから DHCP サーバをリロードします。


 

VPN の使用

VPN 名は、Network Registrar 内で、IP アドレス(リース)、スコープ、およびサブネットなどの多くの DHCP オブジェクトを修飾するのに使用されます。たとえば、リース名には次のシンタックスを使用できます。

vpn / ipaddress

たとえば、red/192.168.40.0

VPN には、予約語 global および all を除く任意の一意なテキスト文字列を使用できます。アドレスまたはリース データをエクスポートする場合は、 global および all を使用できます。 global VPN は [none] VPN にマップされ、 all VPN は特定 VPN と [none] VPN の両方にマップされます。

CLI では、オブジェクトの定義で VPN もその ID も省略した場合、VPN はデフォルトで session set current-vpn によって設定されている値になります。Web UI では、現在の VPN が定義されていない場合、VPN はデフォルトで [none] VPN となります。この VPN には、定義済み VPN 外部のすべてのアドレスが含まれます。

次のオブジェクトは、関連する VPN プロパティを持ちます。

アドレス ブロック :アドレス ブロックの VPN を定義します。

Address Space をクリックしてから、 Address Blocks をクリックします。List/Add Address Blocks ページで Select VPN ドロップダウン リストから VPN を選択します。

CLI では、 dhcp-address-block 作成およびアトリビュート設定コマンドを使用します。次に例を示します。

nrcmd> dhcp-address-block red create 192.168.50.0/24
nrcmd> dhcp-address-block red set vpn=blue
nrcmd> dhcp-address-block red set vpn-id=99
 

クライアントとクライアントクラス :Network Registrar の外部ではなく内部で VPN をプロビジョニングするのが最適な場合もあります。その場合は、各 Cisco IOS デバイスに VPN を設定する必要が生じることがあります。この機能をサポートするため、クライアントまたはクライアントクラスに VPN を指定できます。次の 2 つのアトリビュートが用意されています。

default-vpn :着信パケット内に vpn-id 値も vrf-name 値も存在しない場合に、パケットが取得する VPN。クライアントおよびクライアントクラスでこのアトリビュートを使用できます。

override-vpn :着信パケット内に設定されている vpn-id 値または vrf-name 値に関係なく、パケットが取得する VPN。クライアントおよびクライアントクラスでこのアトリビュートを使用できます。クライアントクラスで上書き VPN を指定し、クライアントにデフォルト VPN を指定した場合は、クライアントクラスの上書き VPN がクライアントのデフォルト VPN よりも優先されることに注意してください。

ローカル クラスタの場合 DHCP をクリックしてから Client-Classes をクリックします。クライアントクラスを作成または編集し、 default-vpn アトリビュート値および override-vpn アトリビュート値を入力します。

リージョナル クラスタの場合 DHCP Configuration をクリックしてから Client-Classes をクリックします。クライアントクラスを作成または取得してから編集し、 default-vpn アトリビュート値および override-vpn アトリビュート値を入力します。

CLI の場合 client-class 作成およびアトリビュート設定コマンドを使用します。次に例を示します。

nrcmd> client 1,6,00:d0:ba:d3:bd:3b set default-vpn=blue
nrcmd> client-class CableModem set override-vpn=blue
 

たとえば、ケーブル モデム展開では、 override-vpn アトリビュートを使用してケーブル モデムをプロビジョニングできます。クライアントクラスによりケーブル モデムのスコープが決まり、スコープにより uBR の VPN が決まります。ケーブル モデムを介したユーザ トラフィックには vpn-id サブオプションが設定され、そのトラフィックは特定の VPN を使用します。また、 override-vpn 値は、クライアントに設定されている default-vpn をすべて上書きします。

リース :複数のリースを一覧表示するか、1 つのリースを表示するか、またはリースのアトリビュートを取得します。

CLI の場合:リースをインポートするには、 import leases filename を使用します。ファイル内の各リース エントリは、行の末尾に VPN を含むことができます。VPN が欠落している場合、Network Registrar が [none] VPN を割り当てます(「リース データのインポートとエクスポート」も参照)。

nrcmd> import leases leaseimport.txt
 

VPN を含むアドレス データまたはリース データをエクスポートするには、 vpn アトリビュートを指定して export addresses を使用するか、または -vpn オプションを指定して export leases を使用します。VPN 値には、予約語 global または all を使用できます。

Global :定義済み VPN([none] VPN)の外部にある任意のアドレス。

All :[none] VPN を含むすべての VPN。

VPN を省略すると、 session set current-vpn によって設定された現在の VPN がエクスポートで使用されます。現在の VPN が設定されていない場合、サーバは [none] VPN を使用します。

nrcmd> export addresses file=addrexport.txt vpn=red
nrcmd> export leases -server -vpn red leaseexport.txt
 

スコープ「バーチャル プライベート ネットワークの作成と編集」で説明したように、スコープには VPN 名またはその ID を含めることができます。

ローカル クラスタの場合 DHCP をクリックしてから Scopes をクリックします。スコープを作成または編集し、Miscellaneous アトリビュート vpn-id を設定します。

リージョナル クラスタの場合 DHCP Configuration をクリックしてから Scope Templates をクリックします。スコープ テンプレートを作成または取得してから編集し、Miscellaneous アトリビュート vpn-id を設定します。

CLI の場合 scope 作成およびアトリビュート設定コマンドを使用します。次に例を示します。

nrcmd> scope examplescope1 set vpn=blue
nrcmd> scope examplescope1 set vpn-id=99
 

サブネット :複数のサブネットを一覧表示するか、1 つのサブネットを表示するか、またはサブネットの vpn アトリビュートまたは vpn-id アトリビュートを取得すると、VPN が表示されます。「DHCP のサブネット割り振りの設定」を参照してください。

DHCP サーバ vpn-communication アトリビュートが(デフォルトの)イネーブルになっている場合、DHCP サーバは、拡張 DHCP リレー エージェント機能を使用することで、DHCP サーバの VPN から、別の VPN 上の DHCP クライアントと通信できます。この機能は、リレー エージェント情報オプション(82)内の server-id-override サブオプションによって示されます。

DHCP のサブネット割り振りの設定

次の項では、DHCP サーバを使用してサブネット割り振りを設定する例を示します。図19-5に、プロビジョニング デバイスにサブネットが割り当てられているサブネットの割り振り構成例を、従来の DHCP クライアント/サーバ構成とともに示します。

サブネットを割り振る前に、DHCP サーバは、どの VPN 上にクライアントがあるかを次の順序で判定します。

1. サーバは、受信 VPN オプションを探し、VPN の値を使用します。

2. VPN オプションが見つからない場合、サーバは、リレー エージェント サブオプションの値を使用し、VPN とサブネット アドレスを組み合せて一意の ID を作成します。

3. リレー エージェント サブオプションが見つからない場合、サーバはクライアントクラス情報(選択タグ)を探します。


ステップ 1 サブネット用の DHCP アドレス ブロックを作成し、初期サブネット マスクとそのインクリメントを設定して、他のサブネット割り振り要求アトリビュートを設定します。また、ポリシーを関連付けるか、組み込みポリシーを定義します。

VPN を使用する場合は、 vpn アトリビュートまたは vpn-id アトリビュートを指定できます(「DHCP を使用したバーチャル プライベート ネットワークの設定」を参照)。


CLI で VPN ID を設定解除すると、その値が現在のセッションの VPN に戻ります。


サーバは、要求パケットに subnet-alloc DNS オプション(220)があるかどうかによって、そのパケットがサブネット割り振り要求かどうかを判定します。サーバまたは VPN に対して subnet-name アトリビュートを設定すると、 addr-blocks-use-selection-tags サブオプション(3)を選択タグとして使用するようにサーバを設定できます。

DHCP サーバまたは VPN オブジェクトに対して addr-blocks-default-selection-tags アトリビュートを設定することで、オプションでデフォルト選択タグを設定できます。この設定により、アドレスの割り振り元の 1 つ以上のサブネットが識別されます。サブネットに関連付けられている VPN 文字列をリレー エージェントが(VPN オプションまたはリレー エージェント サブオプションで)送信すると、 addr-blocks-default-selection-tags の値の 1 つとしてこの文字列を持つすべてのアドレス ブロックが、そのサブネットを使用します。

サーバおよび VPN でのデフォルトの動作では、DHCP サーバが、クライアントの使用済みアドレス ブロックを使って、そのクライアントにサブネット割り振りを試みます。
addr-blocks-use-client-affinity
アトリビュートをディセーブルにすると、サーバはクライアントのメッセージ内にある他の選択データに基づいて、適切なアドレス ブロックからサブネットを提供します。

1 つの LAN セグメント上で複数アドレス ブロックの構成をサポートする場合は(プライマリ スコープとセカンダリ スコープの使用に似ている)、DHCP アドレス ブロックに segment-name アトリビュート文字列値を追加します。リレー エージェントは、1 つのサブネット選択アドレスを送信する場合、その segment-name 文字列値のタグが付いたアドレス ブロックを選択します。ただし、サーバ レベルまたは VPN レベルで LAN セグメント機能( addr-blocks-use-lan-
segments
)も明示的にイネーブルにする必要があります。

ポリシーを関連付ける代わりに、アドレス ブロックの組み込みポリシーにプロパティを設定できます。クライアント、クライアントクラス、およびスコープの組み込みポリシーと同様に、アドレス ブロック ポリシーのアトリビュートをイネーブル化、ディセーブル化、設定、設定解除、取得、および表示することができます。アドレス ブロック ポリシーの DHCP オプションも設定、設定解除、取得、および一覧表示できます。また、ベンダー オプションも設定、設定解除、および一覧表示できます。アドレス ブロックの組み込みポリシーを削除すると、すべての組み込みポリシー プロパティが設定解除されることに注意してください。

ステップ 2 サーバは、リレー エージェントの要求に基づいてサブネットを割り振ることに注意してください。要求がない場合、デフォルトのサブネット サイズは 28 ビットのアドレス マスクです。必要に応じて、DHCP アドレス ブロックの default-subnet-size アトリビュートを設定することにより、このデフォルトを変更できます。次に例を示します。

nrcmd> dhcp-address-block red set default-subnet-size=25
 

ステップ 3 DHCP サーバがアドレス ブロックから作成する任意のサブネットを制御できます。
vpn-name
/ netipaddress / mask の形式で、サブネットを指定します。 vpn-name はオプションです。サブネットの制御には、リースを行うサブネットのアクティブ化および非アクティブ化が含まれます。同様に、サブネットを強制的に使用可能にすることができます。ただし、これを行う前に、そのサブネットを割り当てられたクライアントが、すでにそのサブネットを使用していないことを確認する必要があります。まず、作成済みのサブネットをすべて表示します。

ステップ 4 ステージ スコープ編集モードの場合は、DHCP サーバをリロードします。


 

VPN とサブネット割り振りの調整パラメータ

VPN およびオンデマンド アドレス プールに対する次の調整パラメータを検討してください。

存在しない VPN を持つ孤立したリースを保持する :Network Registrar は、通常、関連する VPN を持たないリースを Network Registrar の状態データベース内に保持します。DHCP アトリビュート delete-orphaned-leases をイネーブルにして、この設定を変更できます。サーバは、クライアントをリースと関連付けるリース状態データベースを保持します。スコープの修正によって既存のリースが無効になると、リース データベースには孤立したリース エントリが存在することになります。今後、サーバがこのデータを使用してクライアントをリースに再度関連付けようとするため、こうしたエントリは通常、リース期限が切れても削除されません。これには、リース データベースがディスク領域を過度に消費する可能性があるという欠点があります。 delete-orphaned-leases アトリビュートをイネーブルにすると、サーバの次回のリロード時に、このようなリース データベース エントリが削除されます。ただし、リースが無効になると、リースを使用しているものとサーバが認識するクライアントはフリーになる可能性があるため、このアトリビュートをイネーブルにするときは注意してください。ネットワークの安定性が損なわれる可能性があります。

存在しない VPN またはアドレス ブロックを持つ孤立したサブネットを保持する :これは、デフォルトの動作です。ただし、DHCP アトリビュート dhcp enable delete-orphaned-subnets をイネーブルにして、この設定を変更できます。DHCP サーバは起動時に、そのサブネット データベースを読み取って、各サブネットの親 VPN および親アドレス ブロックを検出しようとします。このアトリビュートがイネーブルであれば、サブネットがサーバ内ですでに設定解除された VPN を参照した場合、またはサーバがそのサブネットを含む親アドレス ブロックを検出できなかった場合に、サーバは状態データベースからそのサブネットを完全に削除します。

VPN 通信をオープンしたまま保持する :これは、デフォルトの動作です。ただし、DHCP アトリビュート vpn-communication をディセーブルにして、この設定を変更できます。サーバは、拡張 DHCP リレー エージェント機能を使用して、サーバの VPN とは異なる VPN 上に存在するクライアントと通信できます。これは、 relay-agent-info オプション(82)の vpn-id サブオプションが表示されることでわかります。サーバ側でサーバとは異なる VPN 上のクライアントとの通信を想定していない場合には、 vpn-communication アトリビュートをディセーブルにできます。通常は、権限のない DHCP クライアントのアクセスを防止して、ネットワーク セキュリティを強化するために実施します。

DHCP 転送の設定

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

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