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

目次

リースの管理

スコープ内のリースの設定

リースの表示

リースの状態

リース時間のガイドライン

リース データのインポートとエクスポート

アドレスを提供する前のホストの PING

リースの非アクティブ化

範囲からのリースの除外

サーバ全体でのリースの検索

リースの予約の作成

リースと予約プロパティの詳細設定

現在リースされているアドレスの予約

リースの予約解除

MAC アドレス以外への予約の拡張

リース アベイラビリティの強制

リース更新の禁止

Unavailable とマークされたリースの処理

使用不可のリースに対するタイムアウトの設定

アドレス レポートとリース レポートの実行

Address Usage レポートの実行

IP Lease History レポートの実行

ローカル クラスタでのリース履歴記録のイネーブル化

IP リース履歴の照会

リース履歴データのトリム

Lease Utilization レポートの実行

リースの通知の受け取り

Solaris および Linux におけるリース通知の自動実行

Windows におけるリース通知の自動実行

リース通知用の設定ファイルの指定

リースの照会

Leasequery の実装

DHCPv4 の RFC 以前の Leasequery

DHCPv4 の RFC 4388 Leasequery

DHCPv6 の Leasequery

Leasequery の統計

Leasequery の例

リースの管理

リースは、Dynamic Host Configuration Protocol(DHCP; ダイナミック ホスト コンフィギュレーション プロトコル)の中核的な要素です。リースとは、特定の期間に個々のクライアントに割り振られる IP アドレスのことです。DHCP サーバは、有効な IP アドレス範囲が含まれるように適切に設定されたスコープを、これらのリースに自動的に割り振ります。2 つのクライアントが、同じリース アドレスを持つことはできません。予約とは、常に同じ IP アドレスを取得するリースです。

この章では、ネットワークでリースと予約を管理する方法を説明します。

スコープ内のリースの設定

スコープに対する IP アドレス範囲を設定したら、DHCP 割り当ての結果によるリースを監視および調整することができます。

リースの表示

リースを表示するには、『 Quick Start Guide to Cisco Network Registrar 』の「Set Up DHCP」の章、または 「スコープの定義と設定」に記載されているように、最初にリースの IP アドレス範囲をスコープ内に作成してから、これらのアドレスに基づいて DHCP サーバがリースを生成するのを待つ必要があります。

ローカル Basic Web UI

リースを表示するには DHCP をクリックしてから Scopes をクリックして Manage Scopes ページを開き、スコープの Leases カラムの View アイコン( )をクリックします。このように操作すると List Leases for Scope ページが開いて、ここで各リースをクリックして管理できます(図22-1を参照)。

図22-1 List Leases for Scope ページ(ローカル Basic)

 

State カラムの値の説明については、「リースの状態」を参照してください。リースの有効期限に関するガイドラインは、「リース時間のガイドライン」を参照してください。

リースの IP アドレスをクリックすると、Manage DHCP Lease ページが開きます(図22-2を参照)。

図22-2 Manage DHCP Lease ページ(ローカル Basic)

 

ローカル Advanced Web UI

DHCP をクリックしてから Scopes をクリックし、List/Add DHCP Scopes ページを開きます。次に、スコープの Leases カラムで View アイコン( )をクリックするか、またはスコープの名前をクリックして Edit DHCP Scope ページを開いてから、ページの Leases 領域の List Leases をクリックします。どちらの方法でも List DHCP Leases for Scope ページが表示され、リースを Basic モードと同様に管理できます。

CLI コマンド

IP アドレスに基づいて特定のリースのプロパティを表示するには、 lease ipaddr show を使用します。指定されたスコープのすべてのリースを表示するには、 scope name listLeases を使用します。出力は、どちらのコマンドでもほとんど同じです。特定の Virtual Private Network(VPN; バーチャル プライベート ネットワーク)内のリースを一覧表示できないことに注意してください。すべての VPN 内のすべてのリースがリストに表示されます。

リースに関連する最新の MAC アドレス、または MAC アドレスに関連するリースを表示できます。 lease addr macaddr コマンドでは、リースが予約されているかどうか、およびアクティブかどうかにかかわらず、リースの MAC アドレスが表示されます。 lease addr list -macaddr コマンドでは、その MAC アドレスに対する IP アドレスが実際にリースされた(かつ予約されていない)場合のみ、リース データが一覧表示されます。 lease addr list -subnet network netaddr netmask を使用して、LAN セグメントとサブネットごとにリースを一覧表示することもできます。

リースの状態

リースは、 表22-1 に示すいずれかの状態になります。

 

表22-1 リースの状態

状態
説明

Available

IP アドレスをリースで使用可能。

Unavailable

リース不可。DHCP サーバでリースを使用不可に設定する方法については、「Unavailable とマークされたリースの処理」を参照してください。

Leased

クライアントが保持。

Offered

クライアントに提示済み。

Expired

リースの猶予期間終了後に使用可能。

Deactivated

リースの期限終了後の更新またはリースは不可。「リースの非アクティブ化」を参照してください。

Pending available

フェールオーバーに関連。 第27章「DHCP フェールオーバーの構成」 を参照してください。


) DHCP サーバは、サーバの ip-history-detail アトリビュートをイネーブルにした場合だけ、リースの状態を記録します。

既存のリースの状態が変更された場合でも(予約済みや非アクティブになるなど)、DHCP サーバはその変更を IP リースの履歴変更としてリージョナル サーバにレポートしません。DHCP サーバは、リースの有効期限が終了した場合、または DHCP サーバが IP アドレスを他のクライアントにリースした場合だけ、リースの履歴変更をレポートします(「IP Lease History レポートの実行」を参照)。


リース時間のガイドライン

リース時間に適切な値を定義するには、次のようなネットワーク上のイベントを考慮する必要があります。

DHCP オプションおよびデフォルト値に対する変更の頻度

IP アドレスを要求しているクライアントに対応した使用可能な IP アドレス数

ネットワーク インターフェイスの障害の数

コンピュータがネットワークに対して追加および削除される頻度

ユーザによるサブネット変更の頻度

これらのイベントによって、クライアントが IP アドレスを解放したり、リースが DHCP サーバで期限終了となる可能性があります。その結果、再使用のためにアドレスがフリーアドレス プールに返されることがあります。ネットワーク上で多数の変更が発生する場合は、アクティブなネットワークに対してはリース時間を 1 ~ 3 日にして、非アクティブなネットワークに対しては 4 ~ 10 日に設定することをお勧めします。このようなリース時間を割り当てることにより、クライアントがサブネットから出たときに IP アドレスを迅速に割り当て直すことができます。

もう 1 つの重要な問題は、接続されているコンピュータに対する使用可能なアドレスの割合です。たとえば、254 個の使用可能なアドレスを持つクラス C ネットワークで、アドレス再使用の需要が低く、40 個のアドレスだけが使用されているとします。そのような場合は、2 ヶ月間といった長期間のリース時間が適しています。同時に接続を試みる 240 ~ 260 のクライアントが存在する場合は、アドレス再使用の需要が非常に高くなります。この場合は、もっと広いアドレス空間を設定する必要があります。アドレス設定を増やすまでは、DHCP リース時間を 1 時間未満にしておきます。


ヒント リース期間を短くすると、クライアントがより頻繁にリースを更新するため、DHCP サーバが継続的に使用可能である必要性が高くなります。DHCP のフェールオーバー機能は、このようなレベルのアベイラビリティの保証に役立ちます。


永久リースを持つポリシーを作成する場合は、注意してください。安定した環境でも、クライアントの入れ替えがある程度発生します。ポータブル ホストの追加や削除、デスクトップ ホストの移動、ネットワーク アダプタ カードの交換などが行われます。永久リースを持つクライアントを削除した場合、その IP アドレスを解放するために、サーバ コンフィギュレーションを手動で変更する必要があります。6 ヶ月など、長期間のリースを作成することをお勧めします。このように作成することで、管理者が介入しなくてもアドレスは最終的に必ず回復されます。

リース期間についての推奨事項を次に示します。

ケーブル モデムのリース時間を 7 日(604800 秒)に設定する。このリースはプライベート アドレス空間からであり、ケーブル モデムはほとんど移動しません。

Customer Premises Equipment(CPE; 顧客宅内機器)またはラップトップのリースは、パブリック アドレス空間からであり、ユーザ群の傾向に合せて設定する必要がある。同時に、できるだけ長いリース期間を設定してサーバの負荷を減らすことも必要です。

リース時間が短いと、DHCP の要求バッファおよび応答バッファが多く必要となる。最適なスループットを得られるように要求バッファと応答バッファを設定します(「DHCP 要求と応答パケット バッファの設定」を参照)。

allow-lease-time-override ポリシー アトリビュートをディセーブル(通常のデフォルト)に設定することによって、サーバがリース期間を決定するのを許可する。イネーブルになっていても、クライアントがリース時間を要求できるのは、リース時間が、サーバに設定されているリース時間より短い場合に限られます。クライアントによっては、常に一定のリース時間(たとえば、1 時間)を要求したり、以前と同じリース時間を要求したりします。このような要求では、クライアントが十分なリース時間を得られずに問題が発生し、結果としてサーバでトラフィックが増えることがあります。

クライアントが、リースの中間点に達する前にリースを更新しようとした場合、リースの延長を見送る。詳細については、「リース延長の見送り」を参照してください。

リース データのインポートとエクスポート

CLI を使用して、テキスト ファイルにリース データをインポートしたり、テキスト ファイルからリース データをエクスポートしたりすることができます。

インポートの前提条件

リースをインポートする前に、いくつかの構成手順を実行する必要があります。

1. インポートするリースに対して DHCP サーバ内に 1 つまたは複数のスコープを設定します。

2. インポートの一部として、リースのホスト名を DNS にダイナミックに入力する場合は、DHCP サーバからのダイナミック アップデートを可能にするよう、DNS サーバ内にゾーンを設定します。

3. DHCP サーバをインポート モードに設定し、リースのインポート中に DHCP サーバが他のリース要求に応答しないようにします。

4. すべての時間フィールドに対して、1970 年 1 月 1 日午前 0 時(GMT)以降の秒数か、または曜日、月、日、時刻、年の形式(Mon Apr 15 16:35:48 2002)を使用します。

5. リースのインポート後、DHCP サーバのインポート モードを終了し、DHCP サーバが他のリース要求に応答できるようにします。


) 永久リース オプションをディセーブルにすると、永久リースのインポートに失敗します。必要に応じて、policy name enable permanent-leases を使用してこのオプションをイネーブルにしてください。


インポート コマンドとエクスポート コマンド

import leases コマンドおよび export leases コマンドは、特別なファイル形式を使用します。ファイルの各レコード(行)は、1 つの DHCP クライアントに対応します。

field-1|field-2|field-3|...|field-13
 

パイプ(|)のデリミタとフィールド値の間にはスペースを入れません。少なくとも最初の 4 つの必須フィールドは含める必要があります。含めるフィールドを増やす場合は、残りのヌル フィールドをすべてパイプ(|)で区切って、13 個のフィールドを作成する必要があります。フィールドの順序は次のとおりです。

1. aa : bb : cc : dd : ee : ff 形式の MAC アドレス(必須)

2. MAC アドレス タイプ(必須)

3. MAC アドレス長(必須)

4. ドット付き 10 進形式の IP アドレス( a . b . c . d )(必須)

5. リース時間の開始(GMT)(オプション)

6. リースの期限終了時間(GMT)(オプション)

7. 延長可能時間(GMT)(オプション)

8. 最後のトランザクション時間(GMT)(オプション)

9. DHCP サーバの IP アドレス(オプション)

10. ホスト名(ドメインなし)(オプション)

11. ドメイン名(オプション)

12. クライアント ID(オプション)

13. VPN 名(オプション、省略した場合はグローバル VPN が使用される)

すべての時間フィールドに対して、1970 年以降の秒数か、 day-month-date-time-year 形式(Mon Apr 9 16:35:48 2007 など)を使用します。

リースをインポートする場合、DHCP サーバがリースを受け取らないことや、通信の失敗によりリース パケットがドロップされることがあります。後者の場合、サーバはインポートを何回か再試行し、約 1 分後に失敗をレポートします。インポートが失敗した場合は、DHCP サーバのログ ファイルを調べて、エラーの原因となったリースを見つけてください。その後、インポート ファイルを編集し、障害を起こしたリース エントリまでのすべてのリース エントリ(障害を起こしたエントリも含む)を削除し、リースのインポートを繰り返します。

export leases を使用する場合は、現在のリースおよび期限終了リースの状態をすべて出力ファイルに書き込むか、現在のリース状態のみを書き込むかを選択できます。例22-1に、Network Registrar DHCP サーバからエクスポートされたリース データの一部を示します。わかりやすくするために、この例ではレコードの間に空白行を挿入していますが、実際の出力にこの空白行はありません。

例22-1 リース データのエクスポート

00:60:97:40:c1:96|1|6|204.253.96.103|Wed Aug 30 08:36:57 2000|Fri Sep 01 13:34:05 2000|
Wed Aug 30 08:36:57 2000|Fri Sep 01 09:34:05 2000|204.253.96.57|nomad|cisco.com|
00:d0:ba:d3:bd:3b|blue-vpn
 
00:d0:ba:d3:bd:3b|1|6|204.253.96.77|Thu Aug 17 13:10:11 2000|Fri Sep 01 14:24:46 2000|
Thu Aug 17 13:10:11 2000|Fri Sep 01 10:09:46 2000|
204.253.96.57|NPI9F6AF8|cisco.com|blue-vpn
 
00:d0:ba:d3:bd:3b|1|6|204.253.96.78|Fri Jun 23 15:02:18 2000|Fri Sep 01 14:11:40 2000|
Fri Jun 23 15:02:18 2000|Fri Sep 01 09:56:40 2000|
204.253.96.57|JTB-LOCAL|cisco.com|blue-vpn
 

インポート ファイル内のリース時間

インポート時に、DHCP サーバは次に示すリース時間よりも少ない時間をクライアントに提供します。

インポート ファイルに指定された時間

クライアントが DHCP サーバの既存の設定を使用してリースを獲得した場合に受け取るリース時間

たとえば、現在午後 2:00 で、スコープが 1 時間のリースに設定されているとします。インポートするファイルに従うと、リース時間は午後 5:00 まで期限切れになりません。ファイルのインポート後、リースは午後 5:00 ではなく午後 3:00 に期限切れになります。


) インポート ファイルが DNS ゾーン名を指定する場合、サーバは DNS のアップデート時にそのゾーン名を使用しません。ファイルでホスト名を指定している場合は、クライアントまたはクライアントクラスのエントリのホスト名の指定でホスト名を上書きしない限り、サーバは DNS のアップデート時に、ファイルで指定されているホスト名を使用します。

DNS アップデートに使用される DNS アップデート設定オブジェクトに関連付けられたゾーン以外のゾーン内にクライアントのホスト名があることを DHCP サーバに示す唯一の方法は、クライアント エントリまたはクライアントクラス エントリ内にそのゾーンを指定することです。


アドレスを提供する前のホストの PING

DHCP サーバが Internet Control Message Protocol(ICMP; インターネット制御メッセージ プロトコル)のエコー メッセージ機能( PING と呼ばれる)を使用して、IP アドレスへの応答があるかどうかを IP アドレスを割り当てる前に確認するように設定できます。このテストにより、DHCP サーバは、アドレスを割り当てる前に、そのアドレスが使用中でないことを確認できます。 PING を使用すると、2 つのクライアントが同じ IP アドレスを使用するのを防ぐことができます。クライアントが PING に応答すると、DHCP サーバはそのアドレスに unavailable のマークを付け、別のアドレスを割り当てます。このテストが機能するのは、電源が投入されているクライアントに対してだけです。クライアントがリースを持っているが、その電源が切断されていることもあります。


ヒント PING のタイムアウト期間は重要です。PING は、特定の IP アドレスを使用するクライアントが存在しないことを確認するために役立つので、各 PING はタイムアウト期間が完全に終了するまで待つ必要があります。この PING タイムアウト期間の後にリースが提供されるため、指定した時間はサーバのパフォーマンスに大きな影響を及ぼします。この時間の設定が長すぎる場合は、リースを提供するプロセスが遅くなります。この時間の設定が短すぎる場合は、その IP アドレスを使用している別のクライアントを検出する PING パケットの有効性が低下します。


IP アドレスを提供する前にホストの PING を実装するには、次のようにしてスコープを修正します。

ping-clients アトリビュートをイネーブルにする。デフォルトでは、これはディセーブルです。

ping-timeout アトリビュートを設定する。デフォルトでは、300 ミリ秒です。

サーバは、正常な ECHO 応答を受け取った IP アドレスをすべて使用不可にします。この動作は、DHCP サーバのアトリビュート ignore-icmp-errors (プリセットされている値)をイネーブルにすることで制御できます。これをディセーブルにすると、DHCP サーバは、ICMP ECHO 要求の送信後に ICMP DEST_UNREACHABLE または TTL_EXPIRED エラー メッセージを受け取った場合も、その IP アドレスを使用不可にします。

リースの非アクティブ化

リースを非アクティブにすると、リースがクライアントから解放されます。リースが使用可能である場合は、リースを非アクティブにすると、DHCP サーバはリースをクライアントに提供できなくなります。リースがアクティブである(クライアントが保持している)場合、リースを非アクティブにすると、クライアントはリースを更新できなくなり、サーバはそのリースを別のクライアントに提供できなくなります。リースを非アクティブにできるのは、サーバが稼働中の場合だけです。DHCP サーバは、リースをすぐに非アクティブにします。


ヒント 同期スコープの編集モードを設定していない場合は、DHCP サーバをリロードする必要があります。

Windows クライアントに強制的にリースを解放させるには、クライアント マシン上で ipconfig /release を実行します。


ローカル Basic Web UI

リースを非アクティブにするには、List Leases for Scope ページでリースのアドレスをクリックします(「リースの表示」を参照)。Manage DHCP Lease ページで、 Deactivate をクリックします。リースが非アクティブになっていることが表示されます。リースを再びアクティブにするには、 Activate をクリックします。

ローカル Advanced Web UI

リースを非アクティブにするには、Basic モードと同じ操作を実行します。ただし、このモードでは List DHCP Leases for Scope ページでリースのアドレスをクリックして Manage DHCP Lease ページを開くという点が異なります。

CLI コマンド

リースを非アクティブにするには、 lease ipaddr deactivate を使用します。リースを再度アクティブにするには、 lease ipaddr activate を使用します。

範囲からのリースの除外

本来、IP アドレスの範囲は連続している必要があります。既存の範囲からリースを除外する場合は、範囲を分割して 2 つの小さな範囲にする必要があります。新しい範囲の 1 つは、元の範囲の最初のアドレスと除外するアドレスの間にあるアドレスで構成され、もう 1 つは、除外するアドレスと元の範囲の最後のアドレスの間にあるアドレスで構成されます。


注意 除外されたアドレスがアクティブなリースを持っている場合は、最初に 「リースの非アクティブ化」に示す手順に従う必要があります。従わない場合、警告メッセージが表示されます。アクティブなリースを削除すると、削除されたアドレスが後で再設定されてから再割り当てされた場合に、IP アドレスが重複する可能性があります。サーバのリロード後、そのリースに関する情報は失われます。

ローカル Basic Web UI

スコープのアドレス範囲からリースを除外するには、次の操作を実行します。


ステップ 1 DHCP をクリックしてから Scopes をクリックし、Manage Scopes (Address Pools) ページを開きます。

ステップ 2 スコープの名前をクリックして、Edit DHCP Scope (Address Pool) ページを開きます。

ステップ 3 Ranges 領域で、削除する IP アドレス範囲の隣にある Delete アイコン( )をクリックします。

ステップ 4 除外された IP アドレスの直前で終了する範囲を追加します。

ステップ 5 除外された IP アドレスの直後に始まる別の範囲を追加します。

ステップ 6 スコープを修正します。ステージ スコープ編集モードを設定する場合は、DHCP サーバをリロードする必要もあります。


 

ローカル Advanced Web UI

スコープ アドレス範囲からリースを除外するには、Basic モードと同じ操作を実行します。ただし、このモードでは List/Add DHCP Scopes ページでスコープの名前をクリックして Edit DHCP Scope ページを開くという点が異なります。

CLI コマンド

スコープ アドレス範囲からリースを除外するには、リース範囲を検出し( scope name listRanges )、リースを非アクティブ化してから( lease ipaddr deactivate )、その IP アドレスの範囲( scope name removeRange )だけを削除します。その結果、範囲は適切に分割されます。

次の例では、192.168.1.55 というアドレスを範囲から削除しています。リースが、定義された VPN を持つスコープ内にある場合は、セッションにその VPN を明示的に定義する必要があります。または、 lease コマンドに VPN プレフィックスを含めることができます。

nrcmd> session set current-vpn=red
nrcmd> scope examplescope1 listRanges
nrcmd> lease red/192.168.1.55 deactivate
nrcmd> scope examplescope1 removeRange 192.168.1.55 192.168.1.55
nrcmd> scope examplescope1 listRanges
 

スコープに対してステージ編集モードを設定した場合は、サーバをリロードします。

サーバ全体でのリースの検索

Network Registrar 7.0 の新機能を使用すると、サーバ全体の中からリースを検索できます。検索は、リースのアトリビュートの組み合せを指定して、ネットワークに設定されている 1 つ以上のリースを絞り込むフィルタ メカニズムです。この検索機能はローカル クラスタだけで使用でき、DHCPv4 および DHCPv6 のリースに対して別々に提供されます。

ローカル Advanced Web UI


ステップ 1 DHCP をクリックしてから Search をクリックし、DHCP Search ページを開きます(このページの DHCPv4 バージョンは、図22-3を参照)。

ステップ 2 必要に応じて、特定の VPNを選択するか([none] VPN が現在の VPN)、すべての VPN の中から検索します。

ステップ 3 ドロップダウン リストから、client-id などの Filter Attribute を選択します。DHCPv4 と DHCPv6 には、別々のフィルタ アトリビュートのリストがあります。要素として選択されたアトリビュートは、リスト内でグレー表示されます。

図22-3 DHCPv4 Lease Search ページ(ローカル Advanced)

 

ステップ 4 ドロップダウン リストからフィルタの Type を選択します。少なくとも Binary または Regular Expression を選択しますが、選択した Filter Attribute に応じて、リストには次のいずれか 1 つ、または複数のアトリビュートを含めることができます。

Binary:値は 2 進表記されます。

Date Range:From の日時から To の日時までの日付の値の範囲です。

Integer:値は整数です。

Integer Range:From の値から To の値までの整数です。

IP Address:値は IP アドレスです。

IP Range:From の値から To の値までの IP アドレスです。

IP Subnet:値は IP サブネットです。

Regular Expression:値は regex シンタックスでの正規表現です(regex の一般的な使用方法については、表5-4を参照)。

ステップ 5 選択した Type に基づいて Value に値を入力します。フィルタをクリアするには、 Clear Filter をクリックします。

ステップ 6 Filter Elements リストに検索要素を追加するには、 Add Element をクリックします。フィルタの表示を展開し、要素の隣の Delete アイコン( )をクリックすると、要素を削除することができます。

ステップ 7 要素リストの構成後は、そのリストで検索できます。複数の要素は AND されて結果が得られます。 Search をクリックします。

ステップ 8 検索されたリースの表をチェックします。この表には、それぞれのリースに対してアドレス、状態、MAC アドレス、ホスト名、フラグ、および有効期限が示されています。必要に応じてページ サイズを変更し、より多くのエントリが表示されるようにします。リースは IP アドレスの順に並べられています。


ヒント フィルタの要素は AND して検索されます。検索結果で該当するものが見つからない場合は、Filter Elements リストから、検索の妨げになっている要素を削除します。



 

CLI コマンド

DHCPv4 空間でリースを検索するには、 lease list -macaddr mac-addr [ -vpn= vpn-name ] を使用します。リースの MAC アドレスを指定します。VPN の指定を省略すると、現在の VPN で検索が行われます。

DHCPv6 空間のリースに対しては、次の lease6 list シンタックスを使用します。

nrcmd> lease6 list
[-duid=client-id]
[-lookup-key=key] [-blob | -string]]
[-macaddr=mac-addr]
[-cm-macadd=cm-mac-addr]
[-vpn=vpn-name]
[-count-only]
 

-macaddr オプションと -cm-macddr オプションは、CableLabs DOCSIS vendor-opts オプション(DHCPv6 オプション 17)で特定されるリースを検索するためのものです。たとえば、次の 2 つのコマンドについて考えてみます。

nrcmd> lease6 -macaddr=01:02:03:04:05:06
nrcmd> lease6 -cm-macaddr=01:02:03:04:05:06
 

-macaddr の行は、オプション 17 device-id サブオプション(36)に、要求された MAC アドレスが含まれているリースを一覧表示します。 -cm-macddr の行は、オプション 17 cm-mac-address サブオプション(1026)が、要求された MAC アドレスと一致するリースを一覧表示します(これらのサブオプションの詳細については、表C-4を参照してください)。

リースの予約の作成

クライアントが必ず同じリースを取得できるようにするために、リースの予約を作成できます。リース予約管理は、ロール クラスタで dhcp-admin ロールを持つ管理者、またはリージョナル クラスタで central-cfg-admin ロールおよび dhcp-management サブロールを持つ管理者だけが実行できます。


ヒント 予約の使用は制限するようにしてください。予約はリースではなくスコープに対して保存されるため、予約を使用すると、失敗した場合に管理の負担と手間が増えます。予約は、1 つのスコープで 1000 未満になるように制限します。長期間のリースを設定する場合は、予約ではなく長い猶予期間を設定する方が適していることがよくあります。



注意 複数の DHCP サーバが同一サブネット上で IP アドレスを配布する場合は、クライアントの予約が同じである必要があります。異なる場合は、リースの予約が存在するクライアントが、異なるサーバから異なる IP アドレスを提供される可能性があります。

リースの予約では、IP アドレスを MAC アドレスまたはルックアップ キーと組み合せます。ネットワーク上の有効な任意の IP アドレスを選択することが可能で、この IP アドレスはいずれかのスコープ範囲に入っていなくてもかまいません。ダイナミック リースに対してスコープ範囲内の IP アドレスを使用し、予約済みのリースに対してはスコープ範囲外のリースを使用することができます。ただし、予約済みの IP アドレスがスコープ範囲になくても、スコープと関連付けられているポリシーがそのアドレスに適用されます。

ローカル Basic Web UI

リースの予約を表示するには、 DHCP をクリックしてから Scopes をクリックし、Manage Scopes (Address Pools) ページを開きます。次に Reservations カラムで View アイコン( )をクリックし、Scope ページの List/Add DHCP Reservations を開きます(図22-4を参照)。

このページで予約を作成するには、予約するリースの IP アドレスを入力し、MAC Address フィールドに MAC アドレスを入力するか、または Lookup Key フィールドにルックアップ キーを入力します。MAC アドレスではなく、Lookup Key フィールドにルックアップ キーを入力する場合は、入力に応じて、string または binary のオプション ボタンをクリックします。 Add Reservation をクリックしてから Modify Scope をクリックします。

図22-4 List/Add DHCP Reservations for Scope ページ(ローカル Basic)

 

ローカル Advanced Web UI でのスコープの予約の表示

リースの予約を表示するには、 DHCP をクリックしてから Scopes をクリックし、List/Add DHCP Scopes ページを開きます。次に、Reservations カラムの View アイコン( )をクリックして、List/Add DHCP Reservations for Scope ページを開きます。Basic Web UIと同じ手順を実行します。

ローカル Advanced Web UI での予約の直接設定

Advanced モードには、スコープに関係なく予約を作成するメカニズムが用意されています。 DHCP をクリックしてから Reservations をクリックし、List Reservations ページを開きます(図22-5を参照)。

図22-5 List Reservations ページ(ローカル Advanced)

 

いくつかのスコープのいずれかに入っている可能性のある予約に関して、予約を正しいスコープに関連付けられるように、この方法ではクライアントクラスを選択、および他の詳細アトリビュートを入力する必要があります。このページで Add Reservation をクリックして Add Reservation ページを開きます(展開された Advanced アトリビュートについては、図22-6を参照)。

図22-6 Add Reservation ページ(ローカル Advanced)

 

IP Address フィールドに予約の IP アドレスを入力してから、その MAC アドレスか、文字列またはバイナリのルックアップ キーを入力します(MAC アドレスとルックアップ キーの両方は入力しないでください)。

さらにページの下の方で、 include-tags relay-info device-name description などの詳細アトリビュートを設定できます(「予約アトリビュートの設定」を参照)(クライアントクラスを選択するか、または include-tags の値を入力します。両方は指定しないでください)。入力が終わったら Add Reservation をクリックします。


) Expert モードでは、List Reservations ページで、DHCP サーバから CCM サーバ上の予約を同期化することも、CCM サーバから DHCP サーバ上の予約を同期化することもできます。Sync CCM Server from DHCP Server をクリックすると、Sync Reservations on CCM Server from DHCP Server ページが開きます。Sync DHCP Server from CCM Server をクリックすると、Sync Reservations on DHCP Server from CCM Server ページが開きます。両方のページで Return をクリックします。


CLI コマンド

あるスコープに対する予約を一覧表示するには、 scope name listReservations を使用します。有効なすべての予約を一覧表示するには、 reservation list [[ vpn / ] ipaddr | -mac | -key ] を使用します。 -mac オプションまたは -key オプションを使用すると、それぞれの予約に対する MAC アドレスまたはルックアップ キーの値が表示されます。

特定のスコープに予約を追加するには、 scope name addReservation ipaddr { macaddr | lookupkey } を使用します。IP アドレスだけに対して予約を追加するには、 reservation [ vpn / ] ipaddr create { macaddr | lookupkey } を使用します。MAC アドレスではなく lookupkey を使用する場合は、コマンドに -blob オプションまたは -string オプションを追加する必要があります。DHCP サーバによって、対象の IP アドレスが含まれているスコープに予約が割り当てられます。予約に対して、 client-class include-tags relay-info device-name description などのアトリビュート値を設定することができます(「予約アトリビュートの設定」を参照)。スコープ編集モードをステージに設定する場合は、保存してから( save )、予約を送信する( lease [ vpn / ] ipaddr send-reservation )必要があります。

予約アトリビュートの設定

VPN、IPv4 アドレス、IPv6 アドレス、MAC アドレス、またはルックアップ キーの他に、リース予約に対してアトリビュートを設定することができます( 表22-2 を参照)。CLI では、 reservation [ vpn / ] ipaddr set attribute = value を使用します。

 

表22-2 予約アトリビュート

アトリビュート
説明

description

この予約を表すデバイスの説明(オプション)。

device-name

この予約を表すデバイスの名前(オプション)。

include-tags

この予約に対するスコープの選択基準。 client-class を設定する場合は、この値を設定しないでください。

relay-info

Leasequery のために必要なリレー エージェント情報オプション(82)(「リースの照会」を参照)。

リースと予約プロパティの詳細設定

リースと予約プロパティの詳細設定には、次の内容を含めることができます。

現在リースされている IP アドレスの予約「現在リースされているアドレスの予約」を参照してください。

リースの予約解除「リースの予約解除」を参照してください。

MAC アドレス以外へのリースの拡張「MAC アドレス以外への予約の拡張」を参照してください。

リース アベイラビリティの強制「リース アベイラビリティの強制」を参照してください。

リース更新の禁止「リース更新の禁止」を参照してください。

Unavailable とマークされたリースの処理「Unavailable とマークされたリースの処理」を参照してください。

使用不可のリースに対するタイムアウトの設定「使用不可のリースに対するタイムアウトの設定」を参照してください。

現在リースされているアドレスの予約

あるクライアントがリースを保持している場合でも、そのクライアントに対する予約を削除し、その予約を別のクライアントで再使用することができます。

ローカル Advanced Web UI

既存のリースを予約するには、次の操作を実行します。


ステップ 1 DHCP をクリックしてから Scopes をクリックし、スコープの名前をクリックして Edit DHCP Scope ページを開きます。

ステップ 2 Leases カラムの View アイコン( )をクリックします。

ステップ 3 List DHCP Leases for Scope ページで、リースの IP アドレスをクリックします。

ステップ 4 IP アドレスが(使用可能な状態で)リースされていない場合は、Manage DHCP Lease ページで、予約のルックアップ キーまたは MAC アドレスを入力します。

ステップ 5 Make Reservation をクリックします。List DHCP Leases for Scope ページで、リースが予約済みとして表示されます。

ステップ 6 スコープを修正します。

ステップ 7 予約を削除するには、Manage DHCP Lease ページで Remove Reservation をクリックしてから、スコープを修正します。リースが、予約済みとして表示されなくなります。


 

既存のリースの予約例

次の CLI コマンド例では、既存のリースから予約を作成します。

nrcmd> reservation 192.168.1.110 create 1,6,00:d0:ba:d3:bd:3b
nrcmd> save
nrcmd> lease 192.168.1.110 send-reservation
nrcmd> lease 192.168.1.110 activate
nrcmd> save
 

クライアント 1,6,00:d0:ba:d3:bd:3b は DHCPDISCOVER を送信し、192.168.96.110 の提示を受けます。その後、このクライアントは DHCPREQUEST を送信し、同じ IP アドレスの ACK メッセージを取得します。

時間経過に伴って、クライアント 1,6,00:d0:ba:d3:bd:3b は更新の DHCPREQUEST をいくつか送信し、それに対してサーバが確認応答します。このような状況において、クライアントのリースの期限前に次のように予約を終了します。

nrcmd> lease 192.168.1.110 deactivate
nrcmd> reservation 192.168.1.110 delete
nrcmd> save
nrcmd> lease 192.168.1.110 delete-reservation
 

その後、別のクライアントにその IP アドレスの予約を追加します。ただし、そのアドレスはまだ最初のクライアントにリースされています。

nrcmd> reservation 192.168.1.110 create 1,6,02:01:02:01:02:01
nrcmd> save
nrcmd> lease 192.168.1.110 send-reservation
nrcmd> lease 192.168.1.110 activate
nrcmd> save
 

このアクションにより、あるクライアントにリースされているが、別のクライアントに予約されている IP アドレスが存在することになります。新しいクライアント(1,6,02:01:02:01:02:01)が元のクライアント(1,6,00:d0:ba:d3:bd:3b)よりも先に DHCPDISCOVER を送信する場合、新しいクライアントは 192.168.96.110 を取得せず、ダイナミック プールからランダムな IP アドレスを取得します。

元のクライアント(1,6,00:d0:ba:d3:bd:3b)は、192.168.96.110 のリースのための次の
DHCPREQUEST/RENEW を送信すると、NAK メッセージを受け取ります。通常、否定応答メッセージを受け取ると、クライアントはすぐに DHCPDISCOVER を送信します。サーバは、その DHCPDISCOVER を受信すると、192.168.96.110 の残りのリース時間を取り消します。

その後、サーバはクライアント 1,6,00:d0:ba:d3:bd:3b に任意の適切なリースを提供します。192.168.96.110 以外の予約またはダイナミック リース(使用可能な場合)を提供することも、何も提供しないことも(ダイナミック リースが使用可能でない場合)あります。新しいクライアント(1,6,02:01:02:01:02:01)が、受け取ったランダムな IP アドレスの更新を試みると、サーバは、予約済みアドレスを新しいクライアントに与える必要があるので、新しいクライアントに NAK を送信します。新しいクライアントは、DHCPDISCOVER を送信すると、予約済みアドレス 192.168.96.110 を取得します。

リースを強制的に使用可能にすることもできます(「リース アベイラビリティの強制」を参照)。ただし、この操作により、元のクライアント(1,6,00:d0:ba:d3:bd:3b)が 192.168.96.110 の使用を中止するわけではありません。また、新しいクライアント(1,6,02:01:02:01:02:01)が 192.168.96.110 を取得することも妨げられません。つまり、クライアントのために予約を行うことは、予約する IP アドレスのリース状態(および実際のリース クライアント)とは無関係です。

したがって、あるクライアントのために予約を行うことによって、別のクライアントがそのリースをすぐに失うわけではありません。ただし、そのクライアントは、次回 DHCP サーバにアクセスすると(数秒後の場合も数日後の場合もある)、NAK 応答を受け取ります。また、IP アドレスを予約したクライアントは、他のクライアントがすでにその IP アドレスを獲得している場合、そのアドレスを取得しません。代わりに、次の処理が完了するまで、他の IP アドレスを取得します。

受け取ることになっている IP アドレスが解放される。

クライアントが更新として DHCPREQUEST を送信し、NAK 応答を受信する。

クライアントが DHCPDISCOVER を送信する。

リースの予約解除

リースの予約はいつでも削除できます。ただし、リースがまだアクティブである場合、クライアントは期限が切れるまで引き続きそのリースを使用します。別のクライアントのためにそのリースを予約しようとすると、警告が表示されます。

ローカル Advanced Web UI

リースを予約解除するには、 DHCP をクリックしてから Reservations をクリックし、List Reservations ページを開いて、削除する予約の隣の Delete アイコン( )をクリックします。これを行うことにより、確認なしで、予約がすぐに削除されます。

CLI コマンド

リースを予約解除するには、 reservation [ vpn / ] ipaddr delete または scope name removeReservation { ipaddr | macaddr | lookupkey } [ -mac | -blob | -string ] を使用します。

lease ipaddr delete-reservation を使用して予約をすべて削除することもできます。ただし、次の点に注意してください。

予約が nrcmd 内部データベースにないことを確認します。

予約が含まれるスコープ上でフェールオーバーを使用する場合は、次の作業を行います。

1. 両方のサーバで reservation [ vpn / ] ipaddr delete または scope name removeReservation を使用する。

2. バックアップ サーバでは、ステージ スコープ編集モードになっている場合、 lease [ vpn / ] ipaddr delete-reservation を使用する。

3. メイン サーバでも同じコマンドを使用する。

lease ipaddr delete-reservation だけを発行するとサーバの内部メモリだけに影響が及ぼされるため、この処理の結果を保存して、その結果がサーバのリロード後も保持されるようにする必要があります。

MAC アドレス以外への予約の拡張

受信クライアント パケットの MAC アドレス以外の何かに基づいた、リース予約の作成が必要になる場合があります。スイッチのあるポートに接続された DHCP クライアント デバイスで、MAC アドレスに関係なく同じ IP アドレスを取得することが必要になる場合がよくあります。この方法は、工場に設置されたデバイスを(MAC アドレスの異なる)同一のデバイスと置き換えるが、同じ IP アドレスを継続使用する場合に有用です。

クライアント ID の上書き

クライアントクラスの override-client-id アトリビュートに式を設定できます。このアトリビュートは relay-agent-info オプション(82)からスイッチの MAC アドレスとポートを取り出し、そこからクライアント ID を作成します。受信パケット内のクライアント ID にかかわらず、IP アドレスの割り振りに使用される ID は、同じスイッチ ポートを経由するすべてのデバイスに対して常に同じになります。アトリビュートに使用する式は、オプション 82 のフォーマットに応じて異なります。DHCP サーバは、パケットをクライアントクラスに割り当てるときに式を計算します。それ以降は、 override-client-id の値がクライアントの ID になります。

ただし、ポリシー内の use-client-id-for-reservations アトリビュートをイネーブルにすると、サーバはその要求のクライアント ID を nn : nn : nn ... nn : nn 形式の文字列にして、この文字列を予約のルックアップに使用します。

クライアントまたはクライアントクラスの add-to-environment-dictionary は、name-value のペアとして指定されたアトリビュート値を DHCP 拡張環境ディクショナリ( 第29章「拡張ポイントの使用」 を参照)に送信するためにも使用されます。 add-to-environment-dictionary アトリビュートは、クライアントとクライアントクラスのどちらでも設定できます。クライアントとクライアントクラスの両方でこのアトリビュートを設定する場合は、クライアント上で設定する name-value のペアを、クライアントクラスで設定する name-value のペアと異なる名前にする必要があります。これらのペアは、すべて同じ環境ディクショナリに入るからです(ここでは、特定の名前に対して 1 つの値だけを持つことができます)。一般的には、クライアントまたはクライアントクラスのどちらか一方でこのアトリビュートを設定し、両方には設定しないことが最もよい方法です。

ローカル Advanced Web UI

override-client-id アトリビュートは、Add DHCP Client-Class ページ( DHCP Client-Class Add Client-Class の順にクリック)、または Edit DHCP Client-Class ページ( DHCP Client-Class の順にクリックし、クライアントクラスの名前をクリック)に表示されます。

また、DHCP サーバのクライアントクラス ルックアップ ID を設定して、特定のクライアントクラスへすべてのパケットを格納する必要があります。このクライアントクラスでは、 override-client-id 式を設定します。 DHCP をクリックしてから DHCP Server をクリックし、Local DHCP Server リンクをクリックして Edit DHCP Server ページを開きます。Client Class アトリビュートに、 client-class-
lookup-id
式を入力します。

予約に対するクライアント ID を使用するには、Add DHCP Policy ページまたは Edit DHCP Policy ページで use-client-id-for-reservations アトリビュートをイネーブルにするようポリシーを設定します(Add DHCP Policy ページでは DHCP Policy Add Policy の順にクリックし、Edit DHCP Policy ページでは DHCP Policies の順にクリックし、ポリシーの名前をクリック)。

CLI コマンド

override-client-id アトリビュートを設定するシンタックスは、 client-class name set override-client-id=
"
expression " です。 client-class-lookup-id アトリビュートを設定するシンタックスは、 dhcp set client-class-lookup-id=" expression " です。 use-client-id-for-reservations アトリビュートを設定するシンタックスは policy name enable use-client-id-for-reservations です。

予約の上書きの例

次の例は、予約のクライアント ID を上書きする方法を示しています。


ステップ 1 予約にスコープを作成します。

a. サブネット アドレスを入力します。

b. ダイナミックな予約が必要な場合は、IP アドレス範囲を追加します。

ステップ 2 スコープに対する予約を追加します。

a. ルックアップ キーの値を含めます。

b. ルックアップ キーのタイプをバイナリで指定します。

ステップ 3 目的のポリシーを作成し、 use-client-id-reservations アトリビュートをイネーブルにします。

ステップ 4 目的のクライアントクラスを作成します。

a. 前の手順で作成したポリシーを指定します。

b. パケットの内容に基づいて blob 値および必要なクライアント ID を返す override-client-id アトリビュートの式を含めます。

ステップ 5 その MAC アドレスを持つクライアントのリースを取得します。このクライアントが上書き ID を取得します。


 

リース アベイラビリティの強制

現在のリースを強制的に使用可能にすることができます。リースを強制的に使用可能にする前に、リースを解放するようユーザに要求するか、または自分で解放する必要があります。リースを強制的に使用可能にするためにサーバをリロードする必要はありません。


) リースを強制的に使用可能にすると、クライアントは DHCP サーバと接続するまで、そのリースを使用し続けます。


ローカル Advanced Web UI

リースを強制的に使用可能にするには、次の操作を実行します。


ステップ 1 DHCP をクリックしてから Scopes をクリックし、List/Add DHCP Scopes ページを開きます。

ステップ 2 Lease カラムで、リースを持つスコープの View アイコン( )をクリックします。

ステップ 3 List DHCP Leases for Scope ページで、リースの IP アドレスをクリックします。

ステップ 4 Manage DHCP Lease ページで、 Force Available をクリックします。List DHCP Leases for Scope ページで、そのリースの Flags カラムに空値が表示されます。


 

CLI コマンド

リースを強制的に使用可能にするには、 lease [ vpn / ] ipaddr force-available を使用します。スコープ内のすべてのリースを強制的に使用可能にするには、 scope name clearUnavailable を使用します。

リース更新の禁止

通常、Network Registrar DHCP サーバは、クライアントと、そのクライアントがリースしている IP アドレスとの関連付けを保持しています。DHCP プロトコルは明示的にこの関連付けを推奨しており、これは一般的には便利な機能です。ただし、ISP など一部のお客様では、長期のリース関連付けを持つクライアントが不要な場合があります。これは、これらのクライアントで IP アドレスを定期的に変更する必要があるためです。Network Registrar には、DHCP クライアントがリース更新またはリブートを試行するときに、お客様がリースの関連付けを強制的に変更できるようにする機能が備わっています。

サーバはクライアントにリースを強制的に変更させることはできませんが、DHCPRENEW または DHCPDISCOVER 要求に基づいてクライアントにリースの変更を強いることはできます。Network Registrar には、お客様がどのインタラクションを使用してクライアントに IP アドレスの変更を強制するかを選択できるコンフィギュレーション オプションが用意されています。

すべてのリース更新を禁止する :リースしたアドレスを使用しているクライアントは、定期的にそのリースを延長しようとします。各更新試行で、サーバはリースを拒否し、クライアントにその IP アドレスの使用を中止させることができます。クライアントは、リース終了時に終了するアクティブな接続を持っていることがあります。したがって、DHCP インタラクションのこの時点における更新の禁止は、多くの場合、ユーザが認識できます。

リブート時に更新を禁止する :DHCP クライアントは、リブート時に、期限が切れていない有効なリース バインディングを記録している場合も、有効なリースを持っていない場合もあります。クライアントがリースを持っていない場合は、クライアントが最後に保持していたリースをサーバが提供することを禁止できます。クライアントが有効なリースを持っている場合、サーバはそのリースを拒否し、クライアントに新しいリースを取得するよう強制します。どちらの場合でも、アクティブな接続はリースされていたアドレスを使用できないため、この禁止による目に見える影響はありません。

予約に対する影響 :予約は更新の禁止よりも優先されます。予約を持っているクライアントは、更新の禁止が設定されているかどうかに関係なく、予約した IP アドレスを使用し続けることができます。

クライアントクラスに対する影響 :更新禁止テストの後、クライアントクラス テストが行われます。更新の禁止によって、クライアントが IP アドレスを変更するよう強制されることがあります。その場合は、クライアントクラス処理により、サーバがクライアントに提供するアドレスに影響が及ぼされることがあります。

ポリシーに対してリース更新の禁止をイネーブルまたはディセーブルにすることができます。これは、システム全体、スコープに対して、またはクライアント ベースで設定できます。 inhibit-all-renews アトリビュートをイネーブルにすると、サーバは、すべての更新要求を拒否し、クライアントが DHCP サーバにアクセスするときにはいつでも新しい IP アドレスを取得するよう強制します。 inhibit-renews-at-reboot アトリビュートをイネーブルにすると、クライアントはリースを更新できますが、サーバは、クライアントがリブートするたびに新しいアドレスを取得するよう強制します。

DHCP サーバは、拒否する必要のあるクライアント メッセージ(更新要求など)と再送信を示すクライアント メッセージを区別する必要があります。サーバは、メッセージを処理するときに、パケットの到着時刻を記録します。また、クライアントへのリース バインディングの作成時刻、およびそのバインディングに関するクライアントからのメッセージを処理した最後の時刻も記録します。サーバは、パケットの到着時刻とリースのバインディング時刻(start-time-of-state)を比較して、バインディング開始時刻から特定の時間間隔内にある、クライアントからのパケットを処理します。デフォルトでは、この時間間隔は 1 分です。

ローカル Advanced Web UI

リースの更新を禁止するには、Edit DHCP Policy ページ( DHCP Policies 、ポリシーの名前の順にクリック)でポリシーを作成し、 inhibit-all-renews アトリビュートまたは inhibit-renews-at-reboot アトリビュートをイネーブルにします(これらの 2 つのアトリビュートはディセーブルにプリセットされています)。次に、ポリシーを修正します。

Unavailable とマークされたリースの処理

効果的なリース メンテナンスの側面の 1 つは、スコープ内にある使用不可のリース数を把握することです。この数は、予想を上回ることがあります。使用不可の各リースは、重大な問題を表す可能性があります。使用不可になっている原因として、次のことが考えられます。

DHCP サーバが、アドレス提供前に PING を実行するよう設定されており、ICMP エコー メッセージが正常に戻ってくる :現在アクティブなクライアントがこの IP アドレスを使用しているため、DHCP サーバが unavailable とマークされます。DHCP サーバがこの処理を行わないようにするには、クライアントにアドレスを提供する前にそのアドレスに PING を実行する機能をディセーブルにします。「アドレスを提供する前のホストの PING」を参照してください。

適切と考えられる IP アドレスをリースしたクライアントから、サーバが DHCPDECLINE メッセージを受け取る :クライアントがローカル LAN セグメント上でその IP アドレスのアドレス解決(ARP)要求を行うと、別のクライアントがそれに応答します。その後、クライアントは DHCPDECLINE パケットでそのアドレスをサーバに返し、別の DHCPDISCOVER パケットを送信して新しいアドレスを取得します。サーバは、クライアントから返されたアドレスを unavailable とマークします。サーバが DHCPDECLINE メッセージに反応しないようにするために、スコープ アトリビュート ignore-declines を設定できます。

サーバがクライアントから「他のサーバの」要求を受け取る :DHCPOFFER メッセージの後の DHCPREQUEST メッセージはすべてブロードキャストされるため、サーバは他の DHCP サーバ宛のメッセージを見ることができます。サーバは、パケット内の server-id オプションの値で、そのメッセージが自分宛であることがわかります。Network Registrar サーバは、 server-id オプションにそれ自身の IP アドレスが表記されていないため、メッセージが別のサーバ宛であると認識したにもかかわらず、そのメッセージ内のリースする IP アドレスがそのサーバが制御する IP アドレスである場合、2 つのサーバが同時にそのアドレスを管理しようとしていると判断します。その場合、サーバはこのローカル アドレスを unavailable とマークします。この動作は、DHCP フェールオーバー コンフィギュレーションでは適用されません。2 つのサーバに、管理対象として同じ IP アドレスが一部またはすべて設定されているか、または(まれなケースですが)DHCP クライアントがパケット内に間違った server-id オプション値を挿入しています。

クライアントが間違った server-id オプションを送信している(パケットが実際に他のサーバ宛ではない)と確信できる場合のために、Network Registrar には、イネーブルにすることによってこの動作をオフにできるサーバ アトリビュートが用意されています。これは、
ignore-requests-for-other-servers
アトリビュートです。

一貫性のないリース データ :これは非常にまれであり、サーバの起動中にリースを設定しているときに、サーバが内部キャッシュのリフレッシュにおいてディスクからリース データを読み取る際に発生します。リースの状態は leased と表示されますが、そのリースに対してクライアントを構成するための完全なデータがありません(リースがまだ client-id オプションの値を持っていない場合など)。サーバは、そのデータを一貫性がないと見なし、その IP アドレスを unavailable とマークします。リースを強制的に使用可能にすると(CLI で lease ipaddr force-available コマンドを使用するなど)、この問題が解決します。

使用不可のリースに対するタイムアウトの設定

リースが使用不可になっている場合(「Unavailable とマークされたリースの処理」を参照)、使用不可のすべてのリースは、設定された期間だけその状態を保ちます。その期間が終わると、そのリースは再び使用可能になります。ポリシーのアトリビュート unavailable-timeout により、この期間が制御されます。 system_default_policy ポリシーでは、デフォルトで、この値が 1 日に設定されています。

このタイムアウト機能を持たない以前のリリースの Network Registrar からのアップグレードを処理するために、サーバ レベルで特別なアップグレード タイムアウト アトリビュート upgrade-
unavailable-timeout
が用意されています(このアトリビュートも、1 日にプリセットされています)。 upgrade-unavailable-timeout 値は、Network Registrar にアップグレードする前に使用不可に設定されていたリースに対して提供されるタイムアウトです。この設定は、実行サーバだけに影響を及ぼし、データベースをリライトしません。サーバがリロードされることなく 1 日中オンであった場合、最後のリロード時に存在していた使用不可のリースはすべてタイムアウトになります。サーバが 1 日経たないうちにリロードされると、次のリロードでこのプロセス全体が再開されます。このプロセスは、アップグレード前に使用不可と設定されたリースにだけ実行されることに注意してください。アップグレード後に使用不可になったリースには、前述のように、ポリシーから unavailable-timeout 値が提供されます。

Network Registrar フェールオーバー サーバが、6.0 より前の Network Registrar を実行する Network Registrar DHCP サーバからアップデートを受け取る場合、使用不可のリースはタイムアウト値を持ちません。この場合、アップグレードされた Network Registrar サーバは、スコープ ポリシーまたは system_default_policy ポリシーに設定されている unavailable-timeout 値を使用不可のリースのタイムアウトとして使用します。リースがタイムアウトになると、そのポリシーにより、両方のフェールオーバー パートナーでそのリースが使用可能な状態に移行されます。

アドレス レポートとリース レポートの実行

IP アドレスおよびリースに関して、次のレポートを実行できます。

Address Usage「Address Usage レポートの実行」を参照してください。

Lease History「IP Lease History レポートの実行」を参照してください。

Current Utilization「Lease Utilization レポートの実行」を参照してください。

Lease Notification「リースの通知の受け取り」を参照してください。

Address Usage レポートの実行

アドレス使用状況のレポートは、リースに割り当てられている IP アドレスを示しています。

ローカル Advanced Web UI

IP アドレスに対するリースを参照するには、Edit DHCP Scope ページの Leases 領域で、 List Leases をクリックして List DHCP Leases for Scope ページを開きます。特定のリースを管理するには、このページでその IP アドレスをクリックします。この操作により、Manage DHCP Lease ページが表示されます。

CLI コマンド

特定のサーバに対する IP アドレスの使用状況を表示するには、 report を使用します。


ヒント まだ lease-notification を自動的に使用していない場合は、サーバの状態の概要をスコープ単位で簡潔に表示するために lease-notification available=100% の実行を試してください。


IP Lease History レポートの実行

特別なデータベースから IP リース履歴データを抽出し、特定の IP アドレスの過去の割り振り情報を確認できます。クライアントにリースが発行された日時、そのリースの期間、リースの期限が切れる前にクライアントまたはサーバがそのリースを解放した日時、サーバがリースを更新したかどうか、および更新した日時と期間についての履歴ビューを取得できます。

Network Registrar は、IP 履歴データの照会を制御するためのクライアントを提供します。このクライアントを介して、次のことを行えます。

特定の期間、特定の IP アドレスに関連付けられていた MAC アドレスを取得する。

IP 履歴データベース全体をカンマ区切りファイルとして表示する。

リース履歴(リース履歴詳細レポート)のアトリビュートを表示する。「IP リース履歴の照会」を参照してください。

追加の管理機能を使用して IP 履歴データベースのレコードをトリムし、データベースのサイズが際限なく拡大することを防止する必要があります。


) 既存のリースの状態が変更されても(たとえば、予約済み IP アドレスとして設定されたり、非アクティブ化されたりした場合)、ip-history-detail アトリビュートがイネーブルでない限り、その変更はリージョナル クラスタのリース履歴変更として表示されません。詳細な収集がディセーブルの場合、リース履歴変更が表示されるのは、リースがリースされた状態からリースされていない状態になった場合、またはリースが別のクライアントに割り当てられた場合だけです。


ローカル クラスタでのリース履歴記録のイネーブル化

ローカル クラスタ DHCP サーバのリース履歴記録は明示的にイネーブルにする必要があります。DHCP サーバは、IP 履歴記録のエラーを通常の DHCP ログ ファイルに記録します。

ローカル Advanced Web UI

リース履歴記録をイネーブルにするには、次の操作を実行します。


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

ステップ 2 Local DHCP Server リンクをクリックします。

ステップ 3 Edit DHCP Server ページで、次の Lease History アトリビュートを探します。

Lease History(ip-history) :イネーブルに設定されていることを確認します。

ip-history-detail :詳細なリース履歴データを取得するには、これをイネーブルにします。

ip-history-max-age :収集するリース履歴の最大経過時間。リース履歴がイネーブルになっている場合、DHCP サーバは定期的にリース履歴レコードを調べて、この経過時間のしきい値よりも古いリース履歴バインディングを持つレコードをすべて削除します。

ステップ 4 ページ下部の Modify Server をクリックします。

ステップ 5 スコープに対してステージ編集モードを設定した場合は、サーバをリロードします。


 

CLI コマンド

リース履歴記録をイネーブルにするには、 dhcp enable ip-history を使用して、IP アドレスに対する IP(リース)履歴の記録を明示的にイネーブルにする必要があります。

IP リース履歴の照会

リースを取得すると、そのリースの履歴を照会できるようになります。リージョナル クラスタの一部として DHCP サーバを含むローカル クラスタをセットアップして、リージョナル クラスタからのリース履歴データのポーリングをイネーブルにします(「リース履歴の収集のイネーブル化」を参照)。

「サブネット使用状況データとリース履歴データのポーリング」で説明しているアトリビュートを使用すると、リージョナル クラスタ Web UI でクラスタのポーリング基準を調整できます。

以下で説明するように、リース履歴データを照会するための選択基準も設定する必要があります。

リージョナル Web UI

IP リース履歴を照会するには、次の操作を実行します。


ステップ 1 Address Space をクリックしてから Lease History をクリックし、Query Lease History ページを開きます。この機能を使用するには、ローカルの DHCP 権限とリージョナル クラスタのアドレス空間権限が必要です。

ステップ 2 次の基準に基づいて、リース履歴を照会できます。

リース データをポーリングするアドレスの Virtual Private Network(VPN; バーチャル プライベート ネットワーク) :VPN を選択できるのは、少なくとも 1 つの VPN がリージョナル クラスタに定義または取得された場合だけです(「バーチャル プライベート ネットワークの管理」を参照)。デフォルトでは、ページの VPN ドロップダウン リストから選択しない限り、特定の VPN に基づいた照会は行われません。すべての VPN に基づいて照会することもできます。

Time Range(照会の期間) :履歴データの期間として、次のいずれかを選択します。

last 10 days(過去 10 日間)

last 30 days(過去 30 日間)

last 60 days(過去 60 日間)

last 90 days(過去 90 日間)

from/to(最大 90 日間)

この期間値を選択する場合は、ドロップダウン リストから Start Date および End Date の月、日、年も選択します。結果は、 poll-lease-hist-interval アトリビュートの値によって異なります。期間を 1 か月に設定したにもかかわらず、1 か月より長いポーリング間隔を設定すると、データは表示されません。

Criteria(基準) :照会に使用する基準を選択します(VPN および期間ごと)。

By IP Address:横にあるフィールドに IP アドレスを入力します。

By MAC Address:横にあるフィールドに MAC アドレスを入力します。

By IP Range:横にあるフィールドに IP アドレスの範囲を入力します(左のフィールドには範囲の開始、右のフィールドには範囲の終了をそれぞれ入力します)。

All:特定の基準なしですべてのリースを選択します。

Current Lease by IP:(横のフィールドに入力した)IP アドレスの現在のリースが表示されます。


) リージョナル CCM サーバは DHCP サーバを参照して、IP アドレスの最新のリース データを取得します。したがって、ローカル クラスタからの一致するサブネットがリージョナル アドレス空間に含まれている必要があり、該当する DHCP サーバが稼働している必要があります。


ステップ 3 Query Lease History をクリックします。


ヒント List Lease History Records ページの左上隅に、Netscape ブラウザの場合は Log アイコン()(クリックするとテキスト形式のレポートを表示できる)、または Internet Explorer ブラウザの場合は Save アイコン()(レポートをファイル(デフォルトでは .txt)に保存できる)が表示されます。ip-history-detail アトリビュートをイネーブルにして CCM サーバを設定した場合、List Lease History ページにも、View アイコン()付きの View Detail カラムが表示されます。View Lease History Detail ページを開くには、このアイコンをクリックします。このページには、各履歴レコードの変更セットが表示されます。



 

iphist ユーティリティ

iphist ユーティリティを使用することによって、ローカル クラスタで IP 履歴データベースを照会し、その結果を標準出力またはファイルに送信できます。このユーティリティは、DHCP サーバと同じマシン上で実行する必要があります。また、データベース ファイルの読み取りおよび変更のための superuser 権限または root 権限が必要です。デフォルトの場所は、次のとおりです。

Windows の場合 :\Program Files\Network Registrar\bin

Solaris および Linux の場合 :/opt/nwreg2/usrbin

コマンド プロンプトから、この場所に移動し、次のシンタックスを使用してこのユーティリティを実行します。

iphist [ options ] { ipaddr | all } [ start-date | start [ end-date | end ]]

IP アドレスには、1 つのアドレスまたはキーワード all を指定します。開始日には、現地時間、またはデータベース内の最も早い日付にする場合はキーワード start を指定します。終了日には、現地時間、またはデータベース内の最も遅い日付にする場合はキーワード end を指定します。ただし、出力は、 -l オプションを使用して現地時間を指定しない場合、デフォルトでグリニッジ標準時(GMT)になります。

コマンド オプションの全リストを 表22-3 に示します。

 

表22-3 iphist コマンドのオプション

オプション
説明

-N username

管理者のユーザ名。省略した場合は、ユーザ名の入力を求めるプロンプトが表示されます

-P password

管理者のパスワード。省略した場合は、パスワードの入力を求めるプロンプトが表示されます

-C cluster [ : port ]

宛先サーバおよびオプションの SCP ポート。

-a

リースのアトリビュートが表示されます(表示レベル 5 および 3)。

-b

ローカルおよびバックアップ サーバのフェールオーバー リースを表示します。

-f " format "

出力行の形式。デフォルトの形式は、 "address,client-mac-addr,binding-start-time,binding-end-time" です。

-l

デフォルトの GMT ではなく、現地時間で出力を表示します。

-m

ローカルおよびメイン サーバのフェールオーバー リースを表示します。

-n vpn

関連する VPN の名前または ID、あるいは all (すべての VPN)または global (VPN のない IP アドレス)。省略した場合は、グローバル VPN に基づいて照会が行われます。または、このオプションで all 値を使用しない場合は、 session set current-vpn コマンドで設定された現在の VPN に基づいて照会が行われます。

-o file

出力をファイルに送信します。

-v

データベースのバージョンを表示します。

-V visibility

出力アトリビュートの表示レベルを設定します。表示レベルのデフォルトは 3 です。

-z debug-args

デバッグの出力レベルを設定します。

日付には、次のシンタックスを使用できます(空白文字が含まれる場合は、引用符が必要です)。

month / day / year @ hour : min : sec (たとえば、8/28/2007@10:01:15)。時刻はオプションです。

month / day / year hour : min : sec (たとえば、"8/28/2007 10:01:15")。時刻はオプションです。

month day year hour : min : sec (たとえば、"Aug 28 2007 10:01:15")。時刻はオプションです。

キーワード start end 、または now (現在の時刻の場合)。

日付でフィルタリングする目的は、その時刻にアクティブになっていたリースに限定して出力を行うためです。つまり、指定開始日の前に開始し、かつ指定開始日の前に終了しないリースが対象になります。また、指定終了日の後に開始するリースは対象になりません。たとえば、次のコマンドを起動します。

# ./iphist -N user -P password all Aug 28 2008 Dec 31 2008
 

次のようなリースがあるとします。

リース 1

開始

2008 年 1 月 1 日

終了

2008 年 6 月 30 日

リース 2

開始

2008 年 3 月 10 日

終了

2008 年 9 月 1 日

リース 3

開始

2008 年 6 月 1 日

終了

2008 年 9 月 30 日

リース 4

開始

2009 年 1 月 1 日

終了

2009 年 3 月 10 日

この場合、リース 2 とリース 3 だけが返されます。これらのリースは両方とも照会の指定開始日の前に開始し、照会の指定開始日の後に終了するためです。他の 2 つのリースは範囲外です。これらのリースは、照会の指定開始日の前に終了するか、または照会の指定終了日の後に開始するためです。

各行の値は、DHCP サーバが格納している特定のリース オブジェクトによって異なります。各行に含める値を指定するには、 iphist -f format コマンドを使用します。 format 引数は、リース アトリビュート名が引用符で囲まれ、名前がカンマで区切られたリストで、出力行に対するテンプレートを提供します。デフォルトの出力は、 ipaddress , client-mac-addr , binding-start-time , binding-end-time です。

次に例を示します。

# ./iphist -f "address,client-mac-addr,binding-start-time,binding-end-time" all
 

出力は、オペレーティング システムに対応する改行シーケンス(UNIX の場合は \n、Windows の場合は \r\n)で終わる一連の行です。各行には、1 つのリース レコードに関するデータが含まれています。行の形式は、通常、引用符で囲まれたカンマ区切り値です。引用符の中でリテラルのバックスラッシュ(\)または引用符(")を使用するには、それぞれの記号の前にバックスラッシュ(\)を 1 つ付けます。アトリビュート内の新しい行は、 \n として出力されます。

出力に含めることができる、一般的ないくつかのリース オブジェクト アトリビュートを 表22-4 に示します。 lease コマンドのヘルプも参照してください。完全なリストを取得するには、 iphist -a を使用します。

 

表22-4 IP 履歴照会出力のアトリビュート

リース アトリビュート
説明

address

リースの IP アドレス

binding-start-time

リース バインディングの開始時刻

binding-end-time

リース バインディングの終了時刻

client-binary-client-id

クライアントの MAC アドレス(バイナリ形式)

client-dns-name

DHCP サーバによって認識されている、クライアントの最新の DNS 名

client-domain-name

クライアントが所属するドメイン

client-flags

いくつかのクライアント フラグ

client-host-name

クライアントが要求するホスト名

client-id

クライアントによって要求されたクライアント ID、またはクライアントのために合成されたクライアント ID

client-last-transaction-time

クライアントが最後にサーバにアクセスした日時

client-mac-addr

クライアントが DHCP サーバに提示した MAC アドレス

client-os-type

リースしたクライアントのオペレーティング システム

expiration

リースの期限が切れる日時

flags

予約済みまたは非アクティブ

lease-renewal-time

クライアントがリース更新を発行すると予想される最小時刻

relay-agent-circuit-id

circuit-id サブオプション(1)の内容

relay-agent-option

最後のクライアント インタラクションからのオプションの内容

relay-agent-remote-id

remote-id サブオプション(2)の内容

relay-agent-server-id-override

server-id-override サブオプション内の IP アドレス

relay-agent-subnet-selection

subnet-selection サブオプション内の IP アドレス

relay-agent-vpn-id

vpn-id サブオプションの内容

start-time-of-state

リースが状態を変えた日時

state

available、expired、leased、offered、または unavailable のいずれか

vendor-class-id

クライアントによって要求されたベンダー クラス ID

vpn-id

VPN の識別情報(ある場合)

リース履歴データのトリム

リージョナル クラスタで IP 履歴のトリムをイネーブルにすると、IP 履歴データベースが自動的にトリムされ、ディスク領域を解放することができます。各履歴レコードには有効期限があります。トリムが必要なのは、DHCP サーバ自体と、履歴データについて DHCP サーバをポーリングする CCM リージョナル サーバです。

CCM サーバはリージョナル クラスタでバックグラウンド トリムを実行し、特定の経過時間より古いリース履歴データを一定の間隔でトリムします。トリム間隔はデフォルトで 24 時間に設定され、経過時間(トリム前にさかのぼる時間)は 24 週に設定されます。ローカル クラスタの DHCP サーバは、トリムを毎日自動的に(現地時間の午前 3 時に)実行し、デフォルトで 4 週間分のデータを格納します。

リージョナル Web UI

リースの履歴データをトリムするには、中央構成管理者になる必要があります。


ステップ 1 Servers をクリックして Manage Servers ページを開きます。

ステップ 2 Local CCM Server リンクをクリックして、Edit CCM Server ページを開きます。

ステップ 3 Lease History Settings の下で、次のアトリビュートを設定します(入力する値に、 s m h d w m y のいずれかのサフィックスを付けられます)。

trim-lease-hist-interval :古いリース履歴データを自動的にトリムする頻度。デフォルトでは、毎日になります。0 に設定するとリースの自動的なトリムが実行されなくなりますが、使用されるディスク容量が増大するので推奨されません。値は 0 から 1 年に制限されています。

trim-lease-hist-age trim-lease-hist-interval が 0 に設定されていない場合に、古い履歴データを自動的にトリムするためにさかのぼる時間の長さ。デフォルト値は 24 週間です。値は 1 日から 1 年に制限されています。

ステップ 4 強制的に即座にトリムするには、ページの下部の Trim/Compact Inputs セクションを使用します(圧縮は、サブネット利用データのみに使用できます)。Trim/Compact age に必要な値を設定します。これは、トリムの対象となるリース履歴データの経過時間です。つまり、この時間を経過したデータがトリムされます。この値に制限はありません。ただし、非常に小さな値(1m など)を設定した場合にはごく最近のデータがトリムまたは圧縮されるため、望ましくない結果になる可能性があります。実際、値をゼロに設定すると、収集したデータはすべて失われます。高すぎる値(10y など)を設定すると、データは何もトリムまたは圧縮されずに終わる場合があります。

ステップ 5 すぐにトリムするには、 Trim All Lease History をクリックします。


 

ip-history-max-age アトリビュートを設定すると、DHCP サーバ自体で実行するトリムを調整できます。 ip-history がイネーブルになっている場合、DHCP サーバはリース バインディングの変化に伴い、データベース レコードを蓄積していきます。このパラメータでは、データベースに保持される履歴レコードの経過時間の限度を設定します。サーバは定期的にリース履歴レコードを調べ、このパラメータに基づいて経過時間のしきい値を設定して、そのしきい値より前にバイディングが終了したレコードをすべて削除します。プリセット値は 4 週間です。

Lease Utilization レポートの実行

Lease Utilization レポートには、アドレス ブロック、サブネット、およびスコープの現在の使用状況が示されます。この両方のユーザ インターフェイスについては、「サブネット使用状況履歴レポートの生成」を参照してください。

ローカル Advanced Web UI

Address Space 機能内のページから、アドレス ブロック、サブネット、およびスコープの現在の使用状況を表示します。

CLI コマンド

Lease Utilization レポートを表示するには、 report を使用します。

リースの通知の受け取り

CLI には、使用可能な IP アドレスの数が特定のしきい値以下になった場合に、通知を送信する機能があります。 lease-notification コマンドは、使用可能なリースが特定のしきい値以下になった場合に通知をいつ生成するかを、 available アトリビュートを介して指定します。ユーザに対して、電子メールでレポートを送ることができます。このコマンドは対話形式で使用できますが、UNIX の cron タスクまたは Windows Scheduled Task などの自動プロシージャにおいて主に使用されます。

次の例では、examplescope のフリー アドレスが 10% になった場合のリース通知を設定しています。これを行うことにより、特定の Windows メール ホスト上の billy、joe、および jane に対してレポートが送信されます。

nrcmd> lease-notification available=10% scopes=examplescope recipients=billy,joe,jane
mail-host=mailhost
 

出力されるものは、説明的なヘッダー、フリー アドレスの数がしきい値以下である各スコープを行ごとに表示するテーブル、要求されたスコープおよびクラスタに関して予想される警告で構成されています。

Network Registrar では、特に指定しない限り、デフォルト クラスタと nrconfig ファイルがデフォルトで使用されます。コマンドのシンタックスについては、 lease-notification コマンドのヘルプを参照してください。

Solaris および Linux におけるリース通知の自動実行

実行するコマンドを crontab(1) に指定することによって、 cron(1) コマンドで定期的に
lease-notification
を実行できます。 crontab に次のように指定すると、月曜日~金曜日の 00:15 と 12:15(午前 0 時と正午の 15 分後)に lease-notification が実行されます(これは単一コマンドラインで指定する必要があることに注意してください)。

15 0,12 * * 1-5 . .profile; /opt/nwreg2/usrbin/nrcmd lease-notification available=10\% config=/home/jsmith/.nrconfig addresses=192.32.1.0-192.32.128.0 recipients=jsmith,jdoe@example.com >/dev/null 2>&1
 

crontab を編集するには、UNIX の crontab -e コマンドを実行します。 ed(1) を使用しない場合は、このコマンドを実行する前に EDITOR 環境変数を設定します。詳細については、 crontab(1) man page を参照してください。

crontab のコマンド ラインで CLI コマンドのフル パスを入力する必要があることに注意してください。UNIX の which nrcmd コマンドを使用して、現在の環境でのフル パスを調べることができます。

また、 crontab によって lease-notification コマンド を実行する場合、 nrcmd コマンドはユーザ環境変数 CNR_CLUSTER、CNR_NAME、および CNR_PASSWORD を無視します。実行中のコマンドを他の者が見ることができるため、セキュリティ上の理由から、コマンドラインで -P オプションを使用してパスワードを入力することは避けてください。

crontab -e を実行するユーザのホーム ディレクトリ内の .profile ファイルまたは他のファイルに、 nrcmd コマンドを実行するクラスタのクラスタ名、ユーザ、およびパスワード情報を入力します。次に例を示します。

CNR_CLUSTER=host1
export CNR_CLUSTER
CMR_NAME=admin1
export CNR_NAME
CNR_PASSWORD=passwd1
export CNR_PASSWORD
 

crontab エントリ内に . .profile を指定することによって、このファイルが明示的に読み込まれます。最初のドット(.)は、このファイルを読み込むシェル コマンドであり、このドットの後に 1 文字以上の空白が必要です。 nrcmd を実行するクラスタとは異なるクラスタに関する通知の場合は、次の情報を指定する必要があります。

config ファイル内にチェックするクラスタを指定する(「リース通知用の設定ファイルの指定」を参照)。

この項の最初に示した crontab エントリの例のように、完全修飾パスを指定する。

作成する .profile ファイルおよび設定ファイルの内容を他のユーザが調べたり変更したりできないようにするには、UNIX の chmod go-rwx config-file コマンドを使用して、ファイルの権限を変更します。

Windows におけるリース通知の自動実行

Windows エクスプローラの My Computer の下にある Scheduled Tasks サービスを使用して、 lease-notification コマンド のスケジュールを設定します。My Computer の下に Scheduled Tasks フォルダがない場合は、Microsoft Internet Explorer 4.0 以降からこのオプションのコンポーネントを追加するか、またはサードパーティのタスク スケジューラを使用する必要があります。 at コマンドを使用して、 nrcmd lease-notification コマンドのスケジュールを設定することもできます。 at キューに複数のエントリ(このジョブを実行する日時ごとに 1 つのエントリ)を追加します。

リース通知用の設定ファイルの指定

設定ファイルを省略すると、 lease-notification は、最初に現在のディレクトリ内、次にホーム ディレクトリ内、最後に CNR_INSTALL_PATH/conf ディレクトリ内でデフォルトの .nrconfig ファイルを検索します。Network Registrar は、最初に検出したファイルを使用します。このファイルの各行は、#(コメント)、大カッコで囲まれたセクション ヘッダー、あるいはパラメータと値のペアまたはその続きで始まる必要があります。Network Registrar は、各行の先頭の空白文字を除去し、空白行を無視します。

リースの照会

Network Registrar は、Cisco ルータと連携して拡張プロビジョニング機能を提供できます。この機能は DHCP Leasequery 仕様(RFC 4388)に記載されており、Network Registrarはこれに準拠しています。Cisco uBR アクセス コンセントレータのリレー エージェント実装の一部として、DHCP リースの要求と応答から情報がキャプチャおよびグリーニングされます。この情報は、次のために使用されます。

サブスクライバのケーブル モデムの MAC アドレスおよびクライアントの MAC アドレスをサーバが割り当てた IP アドレスに関連付ける。

アップストリーム データグラム内の送信元 IP アドレスを確認する。

DOCSIS Baseline Privacy プロトコルを介してユニキャスト ダウンストリーム トラフィックを暗号化する。

ダウンストリーム Address Resolution Protocol(ARP; アドレス解決プロトコル)要求のブロードキャストを避ける。これは、uBR にもサブスクライバ ホストにも負担をかけることがあり、かつ悪意のあるクライアントから被害を受ける可能性があります。

uBR デバイスは、グリーニングを介してすべての DHCP 状態情報をキャプチャするわけではありません。ユニキャスト メッセージのキャプチャには、転送パフォーマンスを低下させる特別な処理が必要であるため、uBR デバイスは、ユニキャスト メッセージ(特に更新と解放)からグリーニングできません。また、このデータは、uBR のリブートや置き換えをはさんで保持されません。したがって、uBR デバイスの DHCP 状態情報の信頼できるソースは、DHCP サーバ自身に限られます。

この理由から、DHCP サーバは、DHCPINFORM メッセージに似た DHCPLEASEQUERY メッセージをサポートしています。これにより、アクセス コンセントレータおよびリレー エージェントは、DHCPv4 アドレスおよび DHCPv6 アドレスに対して、DHCP サーバからクライアントのロケーション データを直接取得することができます。

Leasequery の実装

Network Registrar には、3 つの Leasequery 実装があります。

RFC 4388 以前のシスコ独自の DHCPv4「DHCPv4 の RFC 以前の Leasequery」を参照してください。

RFC 4388 準拠の DHCPv4「DHCPv4 の RFC 4388 Leasequery」を参照してください。

DHCPv6「DHCPv6 の Leasequery」を参照してください。

DHCPv4 のシスコ独自の実装と、最新の RFC 準拠の実装は、わずかな点が異なるだけで共存できます。DHCP サーバは、同じポートで Leasequery の要求を受け取り、指定されたデータを両方の実装用に返します。Network Registrar 7.0 で新しく採用される DHCPv6 の実装は IETF のドラフトに準拠しており、これは間もなく DHCPv6 Leasequery RFC として承認されます。

DHCP サーバでは、DHCPv4 に対する Leasequery 応答にリース予約データを含めることができます。Network Registrar は、応答の中で予約済みの DHCPv4 リースに対して、デフォルトのリース時間である 1 年(31536000 秒)を返します。その IP アドレスが実際にリースされている場合、Network Registrar は、残りのリース時間を返します。

Leasequery は、すべての実装に対してイネーブルにプリセットされています。ディセーブルにするには、Expert モードのアトリビュートの leasequery をディセーブルにします。

DHCPv4 の RFC 以前の Leasequery

Leasequery のメッセージには通常、要求フィールドとオプションが含まれています。説明のため、リレー エージェントのリブートまたは置換後に、リレー エージェントがデータグラムをダウンストリームの公衆ブロードバンド アクセス ネットワークに転送する要求を受け取ると仮定します。リレー エージェントはダウンストリームのロケーション データを持たなくなっているため、DHCP サーバに対して LEASEQUERY メッセージを送信します。このメッセージには、リレー エージェントのゲートウェイ IP アドレス( giaddr )、およびターゲット クライアントの MAC アドレスまたは dhcp-client-identifier (オプション 61)が含まれています。DHCP サーバは、クライアントを検出すると、leasequery に対する応答のクライアント アドレス( ciaddr )フィールドにクライアントの IP アドレスを入れて返します。サーバは、クライアントのアドレスを検出できない場合、DHCPNACK を返します。

RFC 以前の DHCPv4 の実装では、要求元は IP アドレス、クライアント ID、オプション(61)、または MAC アドレスによって照会を行い、サーバから DHCPACK メッセージ(および返されたデータ)または DHCPNACK メッセージを受け取るか、あるいはサーバがパケットをドロップします。要求に複数のクエリー タイプが含まれている場合、DHCP サーバは最初に検出したものに対して応答します。要求元からの giaddr の値は、検索する ciaddr とは無関係で、単にサーバからの応答を返す先の IP アドレスです。クエリー タイプには、次の 3 つがあります。

IP アドレス( ciaddr :要求パケットでは、 ciaddr フィールドに IP アドレスが含まれています。DHCP サーバは、そのアドレスを使用する最新のクライアントのデータを返します。MAC アドレス フィールド( htype hlen chaddr )や dhcp-client-identifier オプション内の値に関係なく、 ciaddr 値を含むパケットは、IP アドレスによる要求です。他の 2 つの方法が DHCP サーバにより多くの負荷をかける可能性があるため、IP アドレスによる照会は最も効率がよく、最も広く使用されている方法の 1 つです。

dhcp-client-identifier オプション(61) :要求パケットに、 dhcp-client-identifier オプションの値が含まれています。DHCP サーバは、最後にアクセスしたクライアントの IP アドレス データを含む DHCPACK パケットを返します。要求に MAC アドレスが含まれていない場合、サーバは要求されたクライアント ID のすべての IP アドレスとそのデータを cisco-leased-ip associated-ip とも呼ばれる)オプションで返します。要求に MAC アドレスが含まれている場合、サーバは、 dhcp-client-identifier および MAC アドレスをクライアント データと照合して IP アドレスを見つけて、そのデータを、 ciaddr フィールドまたは cisco-leased-ip associated-ip とも呼ばれる)オプションで返します。

MAC アドレス :要求パケットでは、ハードウェア タイプ( htype )フィールド、アドレス長( hlen )フィールド、およびクライアントのハードウェア アドレス( chaddr )フィールドに MAC アドレスが含まれ、 ciaddr フィールドは空白になっています。サーバは、リレー パケットの cisco-leased-ip associated-ip とも呼ばれる)オプションで、MAC アドレスのすべての IP アドレスと最新のリース データを返します。

RFC 以前の実装用の dhcp-message-type オプション(53)の DHCPLEASEQUERY メッセージ番号は 13 です。このタイプのメッセージをサポートしていないサーバは、パケットをドロップすることがあります。DHCPACK メッセージの応答には、必ずリースの所有者の物理アドレスが htype hlen 、および chaddr フィールドに含まれています。要求に ciaddr が含まれている場合、返されるデータは必ず、クライアント ID または MAC アドレスではなく、 ciaddr に基づいています。

要求には、アドレスに関する特別なオプションを要求するための parameter-request-list オプション(55)を含めることができます。応答には、 dhcp-lease-time オプション(51)、およびクライアントが送信した relay-agent-info オプション(82)の元の内容が含まれます。サーバは、クライアントに対する有効なリースを検出しない場合はオプション 51 を返しません。また、要求元は、有効なリースがあるかどうかを判断する必要があります。

サーバからの DHCPACK には、次の Leasequery オプションが含まれていることもあります。

cisco-leased-ip (161) :クライアントに関連付けられているすべての IP アドレスのデータ。 associated-ip オプションとも呼ばれます(後で名前変更されました)。

cisco-client-requested-host-name(162) :クライアントが host-name オプション(12)または client-fqdn オプション(81)で要求したホスト名。RFC 4388 実装では、要求したホスト名が削除されました。

cisco-client-last-transaction-time(163) :DHCP サーバがクライアントに最後にアクセスした時間。

DHCPv4 の RFC 4388 Leasequery

Leasequery は、2006 年 2 月に DHCPv4 の正式な RFC 4388 になりました。Network Registrar は、RFC 以前の実装と並行して RFC 4388 の実装を提供しており(「DHCPv4 の RFC 以前の Leasequery」を参照)、これらの 2 つの実装間に競合はありません。ただし、RFC 4388 実装には目立った変更点がいくつかあります。

dhcp-message-type オプション(53)に含まれていた DHCPLEASEQUERY メッセージ タイプは、メッセージ ID が 10 に変更されました(ID 13 は DHCPLEASEACTIVE メッセージに割り当てられました)。また、応答メッセージは、DHCPACK と DHCPNACK から、次のようにさらに詳細に分類されました。

DHCPLEASEQUERY(10):照会用。

DHCPLEASEUNASSIGNED(11):未指定のアドレスの応答用。

DHCPLEASEUNKNOWN(12):不明なアドレスの応答用。

DHCPLEASEACTIVE(13):アクティブなアドレスの応答用。

応答のオプション名と ID が変更されました。また、 cisco-client-requested-host-name オプションは削除され、次の 2 つの応答オプションだけになりました。

client-last-transaction-time(91) :DHCP サーバがクライアントに最後にアクセスした時刻。

associated-ip (92) :クライアントに関連するすべての IP アドレスのデータ。

クライアント ID または MAC アドレスで照会する場合は、要求に dhcp-client-identifier オプション(61)または MAC アドレスだけを含めることができます。パケットに両方が含まれている場合、パケットはサーバによってドロップされます。

DHCPv6 の Leasequery

リリース 7.0 で利用可能な DHCPv6 用の Network Registrar Leasequery(RFC 5007 に基づく)は、次の目的で設計されています。

DHCPv6 対応の ケーブル モデム ターミネーション システム(CMTS)の source-verify 機能をサポートする。

DHCP リースおよびクライアント アクティビティに関するリアルタイム情報を必要とする追加プロセス(Cisco Broadband Access Center など)にデータを提供する。

決定待ちの DHCPv6 Leasequery の RFC を実装する。

DHCPv6 Leasequery のメッセージ タイプには、次のものがあります。

LEASEQUERY(14)

LEASEQUERY_REPLY(15)

クエリーは次によって実行できます。

QUERY_BY_ADDRESS(1)

QUERY_BY_CLIENTID(2)

DHCPv6 LEASEQUERY_REPLY メッセージには、次の 1 つ以上のオプションを含めることが可能です。

lq-query(44) :実行中のクエリー。このオプションは要求でのみ使用され、クエリーに必要なデータを提供するためのクエリー タイプ、リンクアドレス(または 0::0)、およびオプションを含みます。

client-data(45) :単一のリンク上の単一のクライアントに対してデータをカプセル化します。クライアント データには、これらの任意の数のオプション、または要求された他のオプションを含めることができます。

clt-time (46) client-data オプション(45)でカプセル化されたクライアントの最終トランザクション時刻。サーバが最後にクライアントと通信したのがどのくらい前かを秒単位で表します。

lq-relay-data(47) :クライアントがサーバと最後に通信したときに使用されたリレー エージェント データ。フィールドは peer-address と relay-message です。このオプションには、さらにオプションを含めることが可能です。

lq-client-link(48) :クライアントが何らかのバインディングを持っているリンク。リンクアドレスが省略され、複数のリンク上でクライアントが検出された場合は、クライアント クエリーへの応答で使用されます。

DHCPv6 はオプションの応答オプション( oro )を使用して、Leasequery の応答オプションのリストを要求します。

Leasequery の統計

Network Registrar 7.0 では、リース クエリーは Web UI の DHCP Server Statistics ページ(「統計の表示」を参照)、および CLI の dhcp getStats を使用して、統計のアトリビュートを提供します。Leasequery の統計には次のものがあります。

lease-queries :DHCPv4 Leasequery パケットが特定の時間間隔で受け取った、RFC 4388 のメッセージ ID 10(RFC 以前のメッセージ ID 13)の数。

lease-queries-active :RFC 4388 の DHCPLEASEACTIVE パケットの数。

lease-queries-unassigned :RFC 4388 の DHCPLEASEUNASSIGNED パケットの数。

lease-queries-unknown :RFC 4388 の DHCPLEASEUNKNOWN パケットの数。

leasequeries :受け取った DHCPv6 Leasequery パケットの数。

lease-query-replies :成功した、または成功しなかった可能性のある DHCPv6 Leasequery パケットへの応答の数。

Leasequery の例

例22-2に、DHCPv6 クエリーのパケット トレースを、クライアント ID ごとに示します(リンクアドレスではなく、複数のリンク上のアドレスを使用)。この出力の前半はクエリー メッセージを示し、後半は応答データを示しています。 lq-query オプションはクエリーのタイプを示しています。要求の中で Option Request オプション( oro )を通じて要求されたオプションのリスト、および応答の中で lq-client-links オプションで返された 2 つのアドレスに注意してください。

例22-2 リース クエリーのパケット トレースの例

>> +- Start of RELAY-FORW message
> > | msg-type = RELAY-FORW xid = 0x0 hop-count = 0
> > | link-address = 1:2:5::
> > | peer-address = fe80::d02:3ff:fe04:50d
> > | options:
> > | relay-message =
> > | +- Start of LEASEQUERY message
> > | | msg-type = LEASEQUERY xid = 0x10
> > | | options:
> > | | lq-query = 2 query-by-clientid|::|options:
> > | | client-id = duid-ll|1|0f:02:03:04:05:0d
> > | | oro = client-id,server-id,ia-na,ia-ta,iaaddr,domain-list,lq-relay-data
> > | | client-id = duid-ll|1|01:03:05:07:09:11
> > | +- End of LEASEQUERY message
> > | remote-id = 4491|01:02:03
> > | relay-agent-subscriber-id = 03:04:05
> > | interface-id = 05:06:07
> > +- End of RELAY-FORW message
>
> < +- Start of RELAY-REPL message
> < | msg-type = RELAY-REPL xid = 0x0 hop-count = 0
> < | link-address = 1:2:5::
> < | peer-address = fe80::d02:3ff:fe04:50d < | options:
> < | interface-id = 05:06:07
> < | relay-message =
> < | +- Start of LEASEQUERY_REPLY message
> < | | msg-type = LEASEQUERY_REPLY xid = 0x10
> < | | options:
> < | | server-id = duid-llt|1|5/4/07 12:42 PM|00:0a:e4:3b:42:4c
> < | | lq-client-links = 1:2:5:0:955f:926e:b9d3:ca8e,1:2:7:0:9494:8f2a:a9c2:fad1
> < | +- End of LEASEQUERY_REPLY message
> < +- End of RELAY-REPL message