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

目次

リースの管理

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

リースの表示

リースの状態

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

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

インポートの前提条件

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

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

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

リースの非アクティブ化

範囲からのアドレスの除外

リースの予約

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

リースの予約解除

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

リース更新の禁止

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

アップグレードを含む、使用不可のリースに対するタイムアウトの設定

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

Address Usage レポートの実行

Lease History レポートの実行

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

Web UI によるリース履歴の収集

iphist ユーティリティによるリース履歴の照会

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

Lease Utilization レポートの実行

リースの通知の受け取り

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

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

リース通知用のコンフィギュレーション ファイルの指定

リースの照会

リース照会の要求

リース照会の応答

リースの照会と予約

リースの管理

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

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

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

スコープに対するアドレス範囲を設定したら、DHCP 割り当ての結果によるリースを監視および調整することができます。各スコープに対して設定できるリースの数は無制限ですが、スコープに数千のリースを含むと、Network Registrar がリースをソートするのに多少時間がかかる場合があります。

リースの表示

スコープ アドレス範囲に対するリースの現在の状態を表示できます。

ローカル クラスタ Web UI の場合は、「スコープの定義と設定」の説明に従って、スコープを作成します。リースは、次の 2 つの方法で表示できます。

List/Add DHCP Scopes ページの Leases カラムでスコープの View アイコン( )をクリックします。

List/Add DHCP Scopes ページでスコープ名をクリックし、Edit DHCP Scope ページを開きます。このページの Leases 領域で、 List Leases をクリックします。

どちらの方法でも、List DHCP Leases for Scope ページが表示され、各リースをクリックして管理できます。

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

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

リースの状態

リースの状態は、次のいずれかです。

Available:リース可能。

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

Leased:クライアントが保持。

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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

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

インポートの前提条件

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

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

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 つの必須フィールドは含める必要があります。含めるフィールドを増やす場合は、残りの NULL フィールドをすべてパイプ(|)で区切って、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-day-time-year 形式(たとえば、Mon Apr 10 16:35:48 2000)を使用します。

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

例12-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 サーバの既存のコンフィギュレーションを使用してリースを獲得した場合に受け取るリース時間

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


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

クライアントのホスト名が、スコープに関連付けられているデフォルト以外のゾーン内にあることを DHCP サーバに示す唯一の方法は、クライアント エントリまたはクライアントクラス エントリ内にそのゾーンを指定することです。

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

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


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


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


ステップ 1 Edit DHCP Scope ページの Miscellaneous アトリビュートで、 ping-clients アトリビュートをイネーブルにします。デフォルトでは、これはディセーブルです。

ステップ 2 Miscellaneous アトリビュートで、 ping-timeout アトリビュートを設定します。デフォルトでは、300 秒です。

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


 

CLI の場合は、 scope name enable ping-clients コマンドを使用します。応答するクライアントがないと見なされるまで待機するタイム インターバルは 300 ミリ秒です。これを変更するには、 scope name set ping-timeout コマンドを使用します。前述の「ヒント」を参照してください。

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

リースの非アクティブ化

リースを非アクティブにするのは、リースをクライアントから解放するためです。リースが使用可能である場合は、リースを非アクティブにすると、Network Registrar はリースをクライアントに提供できなくなります。リースがアクティブである(クライアントが保持している)場合、リースを非アクティブにすると、クライアントはリースを更新できなくなり、そのリースは別のクライアントに提供されます。サーバが動作している場合にのみ、リースを非アクティブにできます。Network Registrar はリースを即座に非アクティブにするため、DHCP サーバをリロードする必要はありません。


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


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


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

ステップ 2 Secondary Navigation バーで Scopes タブをクリックします。

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

ステップ 4 List DHCP Leases for Scope ページで、リース名をクリックします。

ステップ 5 Manage DHCP Lease ページで、 Deactivate をクリックします。List DHCP Leases for Scope ページで、そのリースの Flags カラムに deactivated と表示されます。


 

CLI の場合は、 lease ipaddr deactivate コマンドを使用します。非アクティブなリースを再びアクティブにするには、 lease ipaddr activate コマンドを使用します。

範囲からのアドレスの除外

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

ただし、現在除外しようとしているアドレスがアクティブなリースを持っている場合は、まず 「リースの非アクティブ化」の手順を実行する必要があります。これを行わないと、警告メッセージが表示されます。


注意 アクティブなリースを削除すると、削除されたアドレスが再割り当てされた場合に、ネットワーク上でアドレスが重複する可能性があります。サーバのリロード後、そのリースに関する情報は失われます。

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


ステップ 1 Edit DHCP Scope ページの Ranges 領域で、削除するアドレス範囲の隣にある Delete アイコン( )をクリックします。

ステップ 2 除外するアドレスの直前で終わる範囲を追加します。

ステップ 3 Add Range をクリックします。

ステップ 4 除外するアドレスの直後で始まる別の範囲を追加します。

ステップ 5 Add Range をクリックします。

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


 

CLI の場合は、単にそのアドレスの範囲を削除します。その結果、範囲は適切に分割されます。最初に、リースを非アクティブにします。 scope name listRanges コマンド、 lease ipaddr deactivate コマンド、および scope name removeRange コマンドを使用してから、サーバをリロードします。次の例では、192.168.1.55 というアドレスを範囲から削除しています。リースが、定義された VPN を持つスコープ内にある場合は、セッションにその VPN を明示的に定義する必要があります。または、 lease コマンドに VPN プレフィックスを含めることができます。

nrcmd> session set current-namespace=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
nrcmd> dhcp reload
 

リースの予約

クライアントが必ず同じリースを取得できるようにするために、リースの予約を作成できます。常にアドレスを一定にする必要がある DHCP クライアントに対して、リースを予約する必要があります。


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

リースの予約は、IP アドレスと MAC アドレスのペアで構成されます。ネットワーク上の有効なアドレスを任意に選択できます。そのアドレスは、スコープの範囲外にすることもできます。実際、ダイナミック リースに対してスコープの範囲内のアドレスを使用し、予約済みリースに対して範囲外のアドレスを使用する場合があります。


) 予約済みのアドレスがスコープの範囲になくても、スコープと関連付けられたポリシーがそのアドレスに適用されます。


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


ステップ 1 Edit DHCP Scope ページの Reservations 領域で、予約するアドレスの IP アドレスと MAC アドレスを追加します。この予約が、このページの Ranges 領域内の既存の範囲の一部であることを確認します。MAC アドレスは必須です。

ステップ 2 Add Reservation をクリックします。

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


 

CLI の場合:

スコープのリース予約を一覧表示するには、 scope name listReservations コマンドを使用します。

リースを予約するには(IP アドレスおよび MAC アドレスを含む)、 scope name addReservation コマンドを使用します。予約を保存してから、 lease ipaddr send-reservation コマンドを使用して、その予約を送信します。この場合は、サーバをリロードする必要はありません。保存して送信せずに、単にサーバをリロードすることもできます。

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

あるクライアントの予約を削除して、そのクライアントがまだリースを保持している場合でも、別のクライアントにその予約を再使用することができます。次の例では、このような状況で Network Registrar がどのように動作するかを説明します。次のように予約とリースを設定するとします。

nrcmd> scope examplescope1 addReservation 192.168.1.110 1,6,00:d0:ba:d3:bd:3c
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.180 の提示を受けます。その後、このクライアントは DHCPREQUEST を送信し、同じ IP アドレスの ACK メッセージを取得します。

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

nrcmd> lease 192.168.1.110 deactivate
nrcmd> scope examplescope1 removeReservation 192.168.1.110
nrcmd> save
nrcmd> lease 192.168.1.110 delete-reservation
 

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

nrcmd> scope examplescope1 addReservation 192.168.1.110 1,6,00:d0:ba:d3:bd:3d
nrcmd> save
nrcmd> lease 192.168.1.110 send-reservation
nrcmd> lease 192.168.1.110 activate
nrcmd> save
 

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

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

その後、サーバはクライアント 1,6,00:d0:ba:d3:bd:3b に任意の適切なリースを提供します。
192.168.96.180 以外の予約またはダイナミック リース(使用可能な場合)を提供することも、何も提供しないことも(ダイナミック リースが使用可能でない場合)あります。

新しいクライアント 1,6,02:01:02:01:02:01 は、DHCPDISCOVER を送信すると、192.168.96.180 を取得します。

lease ipaddr force-available コマンドを使用すると、リースを強制的に使用可能にすることもできます。ただし、これにより、元のクライアント(1,6,00:d0:ba:d3:bd:3b)が 192.168.96.180 の使用を中止するわけではありません。また、新しいクライアント(1,6,02:01:02:01:02:01)が 192.168.96.180 を取得することも妨げられません。つまり、クライアントのために予約を行うことは、予約する IP アドレスのリース状態(および実際のリース クライアント)とは無関係です。したがって、あるクライアントのために予約を行うことによって、別のクライアントがそのリースをすぐに失うわけではありません。ただし、そのクライアントは、次回 DHCP サーバにアクセスすると(数秒後の場合も数日後の場合もある)、NAK 応答を受け取ります。また、IP アドレスを予約したクライアントは、ほかのクライアントがすでにその IP アドレスを持っている場合、そのアドレスを取得しません。その代わり、次に示す処理が完了するまで、ほかの IP アドレスを取得します。

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

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

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

リースの予約解除

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

ローカル クラスタ Web UI の場合は、Edit DHCP Scope ページの Ranges 領域で、削除するアドレス範囲の隣にある Delete アイコン( )をクリックします。これを行うことにより、確認なしで、予約がすぐに削除されます。次に、 Modify Scope をクリックします。

CLI の場合は、 scope name removeReservation コマンドを使用して、クライアントの MAC アドレスまたは IP アドレスを指定します(アドレスを省略するとすべてのリース予約が削除されることに注意してください)。予約を削除したら、サーバをリロードする必要があります。 lease ipaddr
delete-reservation
コマンドを使用して、予約の削除と消去を組み合せることもできます。このコマンドを使用する場合は、サーバをリロードする必要はありません。ただし、このコマンドを使用する場合は、次の作業が必要です。

予約が nrcmd 内部データベースからすでに削除されていることを確認する。

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

a. バックアップ サーバ上で lease ipaddr delete-reservation コマンドを使用する。

b. メイン サーバ上で lease ipaddr delete-reservation コマンドを使用する。

c. 両方のシステム上で scope name removeReservation コマンドを使用する。


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


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

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

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


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

ステップ 2 Secondary Navigation バーで Scopes タブをクリックします。

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

ステップ 4 List DHCP Leases for Scope ページで、リース名をクリックします。

ステップ 5 Manage DHCP Lease ページで、 Force Available をクリックします。

ステップ 6 List DHCP Leases for Scope ページで、そのリースの Flags カラムに空値が表示されます。


 

CLI の場合は、 lease ipaddr force-available コマンドを使用します。スコープ内のすべてのリースを強制的に使用可能にするには、 scope name clearUnavailable コマンドを使用します。

リース更新の禁止

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

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

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

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

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

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

ローカル クラスタ Web UI の場合は、Edit DHCP Policy ページで、ポリシーを作成して、
inhibit-all-renews
または inhibit-renews-at-reboot アトリビュートをイネーブルにします。デフォルトでは、これらは両方共ディセーブルです。 Modify Policy をクリックします。

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

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

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

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

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

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

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

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

一貫性のないリース データ:これは非常にまれであり、サーバの起動中にだけ発生します。一貫性のないリース データは、リースの設定中、サーバが内部キャッシュのリフレッシュ中にディスクからリース データを読み取るときに発生します。リースの状態は leased と表示されますが、そのリースに対してクライアントを構成するための十分なデータがありません。たとえば、 client-id オプション値がない場合があります。サーバは、そのデータを一貫性がないと見なし、そのアドレスを unavailable とマークします。 lease address force-available コマンドによって、この問題に対処できます。

アップグレードを含む、使用不可のリースに対するタイムアウトの設定

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

このタイムアウト機能を持たない以前のリリースの Network Registrar からのアップグレードを処理するために、サーバ レベルで特別なアップグレード タイムアウト アトリビュート
upgrade-unavailable-timeout
が用意されています。このアトリビュートも、デフォルトで、1 日に設定されています。

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

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

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

IP アドレスおよびリースに関する次のレポートを実行できます。これらのレポートについて、後続の項で説明します。

Address Usage:DHCP サーバによって使用されている IP アドレスが表示されます。

Lease History:ネットワーク内のリースの履歴が提供されます。

Lease Utilization:スコープ内のリースに関する統計情報が表示されます。

Lease Notification:スコープ内の使用可能なアドレスが特定のレベルを下回る場合、通知を受け取ります。

Address Usage レポートの実行

ローカル クラスタ Web UI の場合は、Edit DHCP Scope ページの Leases 領域で、 List Leases をクリックして List DHCP Leases for Scope ページを開きます(図 12-1 を参照)。

図 12-1 List DHCP Leases for Scope ページ

 

特定のリースを管理するには、このページでその名前をクリックします。Manage DHCP Lease ページが表示されます(図 12-2 を参照)。

図 12-2 Manage DHCP Lease ページ

 

このページで、リースを強制的に使用可能にでき、またリースを非アクティブ化することもできます。

リースを強制的に使用可能にするには、 Force Available をクリックします。

アクティブなリースを非アクティブにするには、 Deactivate をクリックします。

ページを取り消すには、 Cancel をクリックします。

各アクションは List DHCP Leases ページに戻ります。

CLI の場合は、 report コマンドを使用して、指定したサーバに対する IP アドレス使用状況を表示します。設定できる追加のオプションについては、『 CLI Reference Guide 』を参照してください。


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


Lease History レポートの実行

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

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

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

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

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


) 既存のリースの状態が変更されても(予約済みアドレスとして設定されたり非アクティブ化された場合など)、その変更はリージョナル クラスタのリース履歴変更として表示されません。リース履歴変更が表示されるのは、リースが期限満了になった場合、またはリースが別のクライアントに割り当てられた場合だけです。


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

ローカル クラスタ DHCP サーバのリース履歴記録は明示的にイネーブルにする必要があります。この処理は、ローカル Web UI および CLI で行うことができます。

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


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

ステップ 2 Manage DHCP Server ページで、 Local DHCP Server リンクをクリックします。

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

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

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

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

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


 

CLI の場合は、アドレスの IP(リース)履歴記録を明示的にイネーブルにする必要があります。この処理を行うには、 dhcp enable ip-history コマンドを使用します。履歴記録をイネーブルにした場合は、イネーブルのままにしておくことをお勧めします。

DHCP サーバは、IP 履歴記録のエラーを通常の DHCP ログ ファイルに記録します。また、DHCP サーバは、使用可能な空きディスク領域が特定のポイントを下回った場合、履歴記録を停止します。

Web UI によるリース履歴の収集

リース履歴を収集するには、最初に、ローカル クラスタ上のスコープ、アドレス範囲、および収集基準を設定してリースを指定します。次に、リージョナル クラスタの一部として DHCP サーバを含むローカル クラスタをセットアップして、リージョナル クラスタからのリース履歴データのポーリングをイネーブルにします。この手順については、「リース履歴の収集のイネーブル化」を参照してください。

CCM サーバに対してポーリング基準をグローバルに設定できます。また、設定されたポーリング基準は、クラスタごとまたはフェールオーバー ペアごとに上書きできます。

このデータのポーリングをイネーブルにする際に設定する DHCP サーバ アトリビュートには、次の 2 つがあります。

ip-history :明示的にイネーブルに設定します。

ip-history-max-age :履歴レコードの経過時間を限定します(デフォルトでは、4 週間に設定されます)。

リージョナル クラスタ Web UI でクラスタのポーリング基準を設定するには、次のアトリビュートを使用します。

poll-lease-hist-interval :ポーリング間隔。0 より大きい妥当な時間間隔に設定してください。

poll-lease-hist-retry :ポーリングに失敗した場合の再試行回数。デフォルトの再試行回数は 1 回です。

poll-lease-hist-offset :ポーリングを開始する固定時刻。たとえば、オフセットを 1h(午後 1:00)に設定し、間隔を 2h に設定すると、毎日午後 1:00 にポーリングが開始され、以後 2 時間ごとにポーリングが行われます。

リージョナル クラスタに対して、リース履歴データを照会するための選択基準も設定する必要があります。


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

ステップ 2 Secondary Navigation バーで、 Lease History をクリックします。Query Lease History ページが表示されます(図 12-3 を参照)。この機能を使用するには、ローカルの DHCP 権限とリージョナル クラスタのアドレス スペース権限が必要です。

図 12-3 Query Lease History ページ

 

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

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

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

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:特定の基準なしですべてのリースを選択します。

ステップ 4 これらの値を入力または選択したら、 Query Lease History をクリックして List Lease History Records ページを開きます。


ヒント List Lease History Records ページの左上隅に、Netscape ブラウザの場合は Log アイコン()(クリックするとテキスト形式のレポートを表示できる)、または Internet Explorer ブラウザの場合は Save アイコン()(レポートをファイル(デフォルトでは .txt)に保存できる)が表示されます。


 

iphist ユーティリティによるリース履歴の照会

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

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

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

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

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

IP アドレスには、1 つのアドレスまたはキーワード all を指定します。開始日付には、現地時間、またはデータベース内の最も早い日付にする場合はキーワード start を指定します。終了日には、現地時間、またはデータベース内の最も遅い日付にする場合はキーワード end を指定します。ただし、出力は、 -l オプションを使用して現地時間を指定しない場合、デフォルトで Universal Time(GMT; 世界時)になります。たとえば、Solaris では次のようになります。

# cd /opt/nwreg2/usrbin
# ./iphist -N user -P password
-f "address,client-mac-addr,binding-start-time,binding-end-time"
-o output.txt
-l all
 

これらのオプションやその他のコマンド オプションについては、 表 12-1 を参照してください。

 

表 12-1 iphist コマンドのオプション

オプション
説明

-N username

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

-P password

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

-C cluster [ : port ]

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

-a

リースのアトリビュートを表示します。

-b

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

-f " format "

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

-l

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

-m

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

-n vpn

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

-o file

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

-v

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

-V visibility

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

-z debug-args

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

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

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

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

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

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

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

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

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

リース 1 開始 2003 年 1 月 1 日 終了 2003 年 6 月 30 日
リース 2 開始 2003 年 3 月 10 日 終了 2003 年 9 月 1 日
リース 3 開始 2003 年 6 月 1 日 終了 2003 年 9 月 30 日
リース 4 開始 2004 年 1 月 1 日 終了 2004 年 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 として出力されます。

出力に含めることができる、リース オブジェクトのアトリビュートを 表 12-2 に示します。詳細については、『 Network Registrar CLI Reference Guide 』の lease コマンドも参照してください。

 

表 12-2 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

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

namespace-id

ネームスペースの識別情報(ある場合)

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 サブオプション内のアドレス

relay-agent-subnet-selection

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

relay-agent-vpn-id

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

start-time-of-state

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

state

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

vendor-class-id

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

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

IP 履歴のトリムをイネーブルにした場合は、IP 履歴データベースを定期的にトリムして、ディスク領域を解放する必要があります。各履歴レコードには有効期限があります。

CCM サーバはリージョナル クラスタでバックグラウンド トリムを実行し、特定の経過時間より古いリース履歴データを一定の間隔でトリムします。トリムの間隔はデフォルトで 1 週間に設定され、経過時間(この時間を経過したデータがトリムの対象となる)は 24 週間に設定されています。

リージョナル クラスタ Web UI の場合、リース履歴のトリム値を調整できるのは中央構成管理者だけです。


ステップ 1 Primary Navigation バーで Administration をクリックし、次に、Secondary Navigation バーで Servers をクリックします。Manage Servers ページが表示されます。

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

ステップ 3 Lease History Settings で、次のアトリビュートを設定します。

trim-lease-hist-interval :古いリース履歴データを自動的にトリムする頻度。デフォルトでは、データはトリムされません。バックグラウンド トリムをトリガーするには、この値を 0 以外に設定する必要があります。値の範囲は 0 ~ 1 年で、秒(s)、分(m)、時(h)、日(d)、週(w)、月(m)、および年(y)の単位を使用できます。

trim-lease-hist-age :自動的にトリムする対象となるリース履歴データの経過時間。デフォルトは 24 週間です(ただし、トリムを実際に有効にするには trim-lease-hist-interval の値を 0 以外に設定する必要があります)。値の範囲は 24 時間~ 1 年で、秒(s)、分(m)、時(h)、日(d)、週(w)、月(m)、および年(y)の単位を使用できます。

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

ステップ 5 トリムを即時に実行するには、ページの下部のコントロールの中にある Trim All Lease History をクリックします。


 

DHCP サーバに対して次のトリム アトリビュートを設定すると、DHCP サーバ自体で実行するトリムを制御することもできます。

ip-history (Web UI の Lease History ):デフォルトではディセーブルになっています。

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

「iphist ユーティリティによるリース履歴の照会」の説明に従って、 iphist ユーティリティを再び実行し、その結果を調べることによって、履歴データがトリムされたことを確認できます。

Lease Utilization レポートの実行

CLI を使用して、1 つまたは複数のクラスタ上のスタティック アドレスおよびダイナミック アドレスの使用状況の概要を生成できます。Web UI の場合は、「リースの表示」を参照してください。

CLI の場合は、 report コマンドを使用すると、スコープによって指定された各サブネット、または、スコープの外の DNS スタティック アドレス割り当てから導き出された各サブネットに関する情報の行が表示されます。複数のスコープが共通のサブネットを共有している場合、および、アドレスが共通のサブネットを共有している場合は、アドレスおよびマスクによって指定されたとおりに小計の行が表示されます。 report コマンドは、スタティック アドレスとスコープ範囲の間に重複がないと仮定します。

各スコープまたはサブネットに対して、 report コマンドは次の情報を表示します。

セッションの現在の VPN に基づくネットワーク番号(16 進数)

サブネット マスクのビット数

ネットワーク番号(標準のドット付きオクテット形式)

各スコープ固有のサブネットに対しては、 report コマンドは、 表 12-3 で説明する値も表示します。

 

表 12-3 スコープ固有のサブネットに対して表示されるレポート値

レポート値
説明

クラスタ名

クラスタの名前。

Scope role

メイン サーバまたはバックアップ サーバで安全なフェールオーバーを使用する場合に表示されます。

スコープ名

スコープの名前。

Addresses

スコープ範囲内のアドレスの合計数。これは、フリーのアドレス、ダイナミックにリース済みのアドレス、予約済みのアドレス、使用不可のアドレス、非アクティブなアドレス、その他の使用可能なアドレスの数をすべて加算した値です。

Free

範囲内のアドレスで、使用可能な状態にあり、予約済みまたは非アクティブのフラグが設定されていないもの。

% free

スコープ範囲内のすべてのアドレスに対するフリー アドレスのパーセンテージ。

予約済み

範囲内にあり、予約済みのフラグが設定されていて、使用可能なアドレス。

Leased

範囲内にあり、リース済み、提供済み、期限終了、または解放状態にある(予約済みまたは非アクティブのフラグが設定されている場合も含む)リース済みのアドレス。

Dynamically leased

範囲内にあり、リース済み、提供済み、または期限終了の状態にあり、予約済みまたは非アクティブのフラグが設定されていないダイナミックにリース済みのアドレス。

Unavailable

範囲内にあり、フラグにかかわらず、サーバによって使用不可のマークが付けられている使用不可のアドレス。

De-activated

範囲内にあり、非アクティブのフラグが設定されていて、使用不可でない非アクティブなアドレス。

Other available

通信が中断された場合に安全なフェールオーバー パートナーがリースできるように確保されているリース。

Other reservations

スコープ範囲外にある、予約済みのマークが付けられたアドレス。

リース期限終了後のアドレスには、現在の状態と待ち状態の両方があります。リース済みおよび使用不可というカテゴリは、現在の状態を表します。 dynamically leased reserved 、および de-activated というカテゴリは、現在の状態または待ち状態のいずれかを表す場合があります。 free というカテゴリは、現在の状態が available であるアドレスから、予約済みまたは非アクティブのフラグが設定されているアドレスを除いたものです。leased というカテゴリはほかのカテゴリと重複し、スコープの合計には加えられないことに注意してください。 表 12-4 に、アドレス状態の概要を示します。

 

表 12-4 アドレス状態のカテゴリ

カテゴリ
状態

deactivated

現在の状態または待ち状態

dynamically leased

現在の状態または待ち状態

free

現在の状態が available であるアドレスから、予約済みまたは非アクティブのフラグが設定されているアドレスを除いたもの

leased

現在の状態(leased というカテゴリはほかのカテゴリと重複し、スコープの合計には加えられません)

reserved

現在の状態または待ち状態

unavailable

現在の状態

各小計行に対して、 report コマンドはサブネット内の各スコープ値の概要だけでなく、次の値も表示します。

合計:サブネット内のすべてのアドレス。

スタティック:スタティックに割り当てられたアドレス。

未割り当て:DHCP スコープ範囲に割り当てられていないアドレスで、これ以外の場合は予約済みまたはスタティックに割り当てられている。スコープ範囲へのスタティックな割り当てや分配に使用可能。

総計:レポートの最後に、各サブネット内のすべてのデータをまとめたもの。

レポートの最後に、各サブネット内のすべてのデータをまとめた総計が表示されます。

カンマ区切りのテキスト形式は、データベース、スプレッドシートなどのツールへのインポートに最適です。カストマイズされたレポートを簡単に作成できます。 report コマンドで column-separator キーワードを使用して、この形式を指定します。

表 12-5 の行とカラムは、DHCP スコープ内のアドレスが保持できる状態とフラグを示しています。表内のセルは、所定の状態およびフラグを持つアドレスを Network Registrar が配置する先のカテゴリを示します。複数のフラグが設定されている場合、非アクティブのフラグは予約済みのフラグよりも優先され、予約済みのフラグはレポート目的の残りのどのフラグよりも優先されます。

 

表 12-5 IP アドレスの考えられる状態とフラグ

状態
フラグ
なし
予約済み
非アクティブ
予約済みと非アクティブ

available

free

reserved

deactivated

deactivated

leased

dynamically
leased、leased

dynamically
leased、leased

deactivated、leased

deactivated、leased

expired

dynamically
leased、leased

dynamically
leased、leased

deactivated、leased

deactivated、leased

offered

dynamically
leased、leased

dynamically
leased、leased

deactivated、leased

deactivated、leased

other-available

other available

reserved

deactivated

deactivated

pending-available

dynamically
leased、leased

dynamically
leased、leased

deactivated、leased

deactivated、leased

unavailable

unavailable

unavailable

unavailable

unavailable

リースの通知の受け取り

Network Registrar クラスタ上のすべてのスコープを調査し、すべてのリースに関するレポートを作成できます。これは Web UI ではリース ビューとして使用でき、リージョナル クラスタではリース履歴レポートとして使用できます。CLI では、使用可能なアドレスの数が特定のしきい値以下になった場合に、通知を送信する機能が追加されています。

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


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

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

ステップ 3 List/Add DHCP Scopes ページで、編集するスコープを選択します。

ステップ 4 Edit DHCP Scope ページで、このページの Leases セクションにある List Leases をクリックします。List DHCP Leases for Scope ページが表示され、リースの一覧を参照できます。


 

リージョナル クラスタでは、リース履歴レポートを生成することもできます。「Lease History レポートの実行」を参照してください。

CLI の場合は、 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 ファイルがデフォルトで使用されます。コマンド シンタックスの詳細については、『 Network Registrar CLI Reference 』の 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) マン ページを参照してください。

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 を指定することによって、このファイルが明示的に読み込まれます。最初のドット(.)は、このファイルを読み込むシェル コマンドであり、このドットの後に空白が必要です。 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 は、先頭の空白を除去し、空白行を無視します。

リースの照会

Cisco uBR アクセス コンセントレータのリレー エージェント実装の一部として、DHCP リースの要求と応答から情報がキャプチャおよびグリーニングされます。これにより、次のことが可能になります。

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

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

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

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

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

この理由から、DHCP サーバは、DHCPINFORM メッセージに似た DHCPLEASEQUERY メッセージをサポートしています。 dhcp-message-type オプション(53)の DHCPLEASEQUERY メッセージの番号は 13 です。uBR デバイスのリレー エージェントは、DHCPLEASEQUERY 要求を DHCP サーバに送信します。この要求により、必ず、サーバからの DHCPACK 応答または DHCPNAK 応答が生成されます。このタイプのメッセージをサポートしていない DHCP サーバは、DHCPLEASEQUERY パケットをドロップすることがあります。

リース照会の要求

DHCPLEASEQUERY 要求では、ゲートウェイ IP アドレス( giaddr )フィールドに、要求するリレー エージェントの IP アドレスが必要です。 giaddr フィールドは、検索するクライアント アドレス( ciaddr )とは無関係で、単に、サーバからの応答を返す先のアドレスです。リレー エージェントは、次のタイプの DHCPLEASEQUERY 要求を送信できます。

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

MAC アドレスによる:要求パケットのハードウェア タイプ( htype )フィールド、アドレス長( hlen )フィールド、およびクライアント ハードウェア アドレス( chaddr )フィールドに MAC アドレスが含まれ、クライアント アドレス( ciaddr )フィールドには値がありません。DHCP サーバは、DHCPLEASEQUERY パケットの associated-ip オプションで、この MAC アドレスのすべての IP アドレスと最新のリース データを返します。「リース照会の応答」の項を参照してください。

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

リース照会の応答

サーバからの DHCPACK 応答内の parameter-request-list オプション(55)には、 dhcp-lease-time (51)オプションや relay-agent-info (82)オプションの値など、要求元に関連するデータが含まれている必要があります。

dhcp-lease-time (51)の値は、リースの期限が切れるまでの残りの時間を示します。

relay-agent-info (82)の値は、クライアントからサーバへの最新の DHCPDISCOVER メッセージまたは DHCPREQUEST メッセージからの値です。

Network Registrar には、DHCPLEASEQUERY メッセージに応答するために次のオプションが用意されています。

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

cisco-client-requested-host-name (162):クライアントが host-name オプション(12)または client-fqdn オプション(81)で要求したホスト名を含みます。

cisco-associated-ip (161):クライアントに関連するすべての IP アドレスについてのデータを含みます。

リースの照会と予約

DHCP サーバは、DHCPLEASEQUERY の応答にリース予約データを組み込みます。以前のリースの Network Registrar では、DHCPLEASEQUERY の応答は、MAC アドレスが格納されている、リース中または以前にリースしていたクライアントに対してのみ可能でした。たとえば、Cisco uBR リレー エージェントは、MAC アドレスとリース時間( dhcp-lease-time オプション)を持たない DHCPLEASEQUERY データグラムを破棄します。

Network Registrar は、DHCPLEASEQUERY の応答内で予約済みのリースに対してデフォルトのリース時間である 1 年(31536000 秒)を返します。そのアドレスが実際にリースされている場合、Network Registrar は、残りのリース時間を返します。