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

目次

リースの管理

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

リースの表示

リースの状態

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

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

インポートの前提条件

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

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

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

リースの非アクティブ化

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

リースの予約の作成

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

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

クライアント ID の上書き

予約の上書きの例

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

リースの予約解除

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

リース更新の禁止

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

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

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

Address Usage レポートの実行

IP Lease History レポートの実行

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

Web UI による IP リース履歴の照会

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

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

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 name 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 セグメントとサブネットごとにリースを一覧表示することもできます。

リースの状態

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

Available:リース可能。

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

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

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

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


) DHCP サーバでリースが期間切れになると、処理では grace-period などのスコープ ポリシー アトリビュートのみが使用されます。クライアントおよびクライアントクラスに設定されたポリシーは使用されません。


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

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


) 既存のリースの状態が変更されても(たとえば、予約済みアドレスとして設定されたり、非アクティブ化された場合など)、その変更はリージョナル サーバに IP リース履歴変更としてレポートされません。リース履歴変更が記録されるのは、リースが期限満了になった場合、またはアドレスが別のクライアントにリースされた場合だけです(「IP Lease History レポートの実行」を参照)。リース履歴変更がログに記録されるのは、サーバの ip-history-detail アトリビュートをイネーブルにした場合だけです。


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

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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

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

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

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)を使用します。

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

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

例21-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 のアップデート時にそのホスト名を使用します。

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

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

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


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


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

ping-clients アトリビュートをイネーブルにする。デフォルトでは、これはディセーブルです。CLI では、 scope name enable ping-clients を使用します。

ping-timeout アトリビュートを設定する。デフォルトでは、300 ミリ秒です。CLI では、 scope name set ping-timeout を使用します。

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

リースの非アクティブ化

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


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



ステップ 1 ローカル Web UI では、 DHCP をクリックしてから Scopes をクリックし、List/Add DHCP Scopes ページを開きます。

CLI の場合は、ステップ 4 に進みます。

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

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

ステップ 4 Manage DHCP Lease ページで、 Deactivate をクリックします。リースが非アクティブになっていることが表示されます。リースを再アクティブ化するには、Manage DHCP Lease ページで Activate をクリックします。

CLI の場合は、 lease ipaddr deactivate を使用します。リースを再アクティブ化するには、 lease ipaddr activate を使用します。

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


 

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

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

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


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


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

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

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

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

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

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

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

次の CLI の例では、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
 

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


 

リースの予約の作成

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


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

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


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



ステップ 1 Web UI では、Edit DHCP Scope ページの Reservations 領域で、予約する IP アドレスと、クライアント ルックアップ キー(文字列、バイナリ、または MAC アドレス)か MAC アドレス プロパーのどちらかを追加します(ルックアップ キーと MAC アドレスの両方を使用することはできません)。この予約が、このページの Ranges 領域内の既存の範囲の一部であることを確認します。ルックアップ キーまたは MAC アドレスは必須です。

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

すべてのリースの予約を一覧表示するには、 reservation list を使用します。

スコープに対する特定のリース予約を一覧表示するには、 scope name listReservations のみを使用します。

出力には、それぞれの予約の MAC アドレスまたはルックアップ キーの値が示されます。

ステップ 2 Web UI で、 Add Reservation をクリックします。10 個を超える予約がある場合、それらは、 List Reservations をクリックするとアクセスできる別の List/Add DHCP Reservations for Scope ページに表示されます。

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

予約を追加するには、 reservation [ vpn / ] ipaddr create { macaddr | lookupkey } を使用します。予約は、その IP アドレスを包むスコープに追加されます。

別の方法として、特定のスコープに予約を追加するには、 scope name addReservation ipaddr { macaddr | lookupkey } を使用します。

lookupkey を使用すると、 -mac -blob 、または -string のいずれかのオプションをコマンドに追加できます。

ステップ 3 Web UI では、 Modify Scope をクリックします。(必ずクリックしてください。そうしないと変更は有効になりません)。

CLI では、保存( save )してから予約を送信( lease ipaddr send-reservation )します。リロードは必要ありません。

ステップ 4 Web UI で既存のリースを予約済みにするには、次の操作を実行します。

a. Edit DHCP Scope ページの Lease カラムで、リースを持つスコープの View アイコン( )をクリックします。

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

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

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

e. Modify Scope をクリックします(必ずクリックしてください。そうしないと変更は有効になりません)。

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

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


 


) デバイスの MAC アドレスに基づく受信 DHCP クライアント ID の使用を上書きする場合は、クライアントまたはクライアントクラスに対して override-client-id アトリビュート(要求パケット内の着信クライアント ID を上書きする式値)を設定するか、クライアントの DHCP ポリシーのuse-client-id-for-reservations アトリビュート(デフォルトでディセーブル)をイネーブルにします(「MAC アドレス以外への予約の拡張」の項を参照してください)。


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

Web UI および CLI で、VPN、IP アドレス、または MAC アドレス/ルックアップ ID 以外の、リース予約の特定のアトリビュートを設定できます。CLI では、 reservation [ vpn / ] ipaddr set attribute = value を使用します。

client-class :複数のスコープから予約を選択するときに使用する、クライアントクラスの名前。

description :デバイスの説明(任意指定)。

device-name :デバイスの名前(任意指定)。

include-tags :この予約の選択基準。

relay-info :リースを照会するときに必要な、リレー エージェント情報オプション(82)値。

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

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

クライアント ID の上書き

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

Web UI では、[ v6- ] override-client-id アトリビュートは、Add DHCP Client-Class ページまたは Edit DHCP Client-Class ページにあります。CLI の場合、このアトリビュートを設定するシンタックスは、次のとおりです。

nrcmd> client-class name set [v6-]override-client-id="expression"
 

ただし、ポリシー内の use-client-id-for-reservations アトリビュートがイネーブルの場合、その要求のクライアント ID は nn : nn : nn ... nn : nn の形式の文字列になり、その文字列が予約のルックアップに使用されます。したがって、MAC アドレス以外の何かに関して予約が必要な場合は、次の操作を実行します。

1. ポリシーを設定して use-client-id-for-reservations アトリビュートをイネーブルにします。

CLI のシンタックスは次のとおりです。

nrcmd> policy name enable use-client-id-for-reservations
 

2. クライアントクラスに対して [ v6- ] override-client-id を設定し、(前述の CLI でのシンタックスを使用して)クライアントに必要な ID をクライアントに与えます。

3. サーバに対して client-class-lookup-id 式を設定し、[ v6- ] override-client-id 式を設定する特定のクライアントクラスにすべてのパケットを格納します。

CLI のシンタックスは次のとおりです。

nrcmd> dhcp set client-class-lookup-id="expression"

クライアントまたはクライアントクラスの add-to-environment-dictionary は、attribute-value のペアとして指定されたアトリビュート値を DHCP 拡張環境ディクショナリ(「拡張ポイントの使用」を参照)に送信するためにも使用されます。クライアントのアトリビュートは、環境ディクショナリの中でクライアントクラスのアトリビュートよりも先に格納されます。そのため、両方のアトリビュートが同じ場合、クライアントのアトリビュートがクライアントクラスのもので置き換えられます。このようになるのは、既存の環境ディクショナリのアトリビュートが、クライアントからのもの(アトリビュートが置き換えられていない)か、以前の操作からのもの(クライアントクラスの値によって置き換えられた)かが不明であるためです。

予約の上書きの例


ステップ 1 予約のためのスコープ(または IPv6 プレフィックス)を作成します。

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

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

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

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

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

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

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

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

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

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


 

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

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

nrcmd> reservation 192.168.1.110 create 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> 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
 

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

元のクライアント(1,6,00:d0:ba:d3:bd:3b)は、192.168.96.180 のリースのための次の
DHCPREQUEST/RENEW を送信すると、NAK メッセージを受け取ります。通常、否定応答メッセージを受け取ると、クライアントはすぐに DHCPDISCOVER を送信します。サーバは、その 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)が、受け取ったランダムな IP アドレスの更新を試みると、サーバは、予約済みアドレスを新しいクライアントに与える必要があるので、新しいクライアントに NAK を送信します。新しいクライアントは、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 でリースを予約解除するには、次の操作を実行します。

reservation [ vpn / ] ipaddr delete を使用します。

scope name removeReservation { ipaddr | macaddr | lookupkey } を使用します(アドレスまたはルックアップ キーを省略すると、そのスコープのリースの予約がすべて削除されます)。

予約を削除したら、ステージ スコープ編集モードでサーバをリロードする必要があります。 lease ipaddr delete-reservation を使用して予約をすべて削除することもできます。この場合はリロードは必要ありません。ただし、このコマンドを使用する場合は、次の作業が必要です。

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

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

1. バックアップ サーバ上で lease ipaddr delete-reservation を使用する。

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

3. 両方のシステムで reservation [ vpn / ] ipaddr delete または scope name removeReservation を使用する。


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


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

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


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


ステップ 1 ローカル Web UI では、 DHCP をクリックしてから Scopes をクリックし、List/Add DHCP Scopes ページを開きます。

CLI の場合は、ステップ 4 に進みます。

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

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

ステップ 4 Manage DHCP Lease ページで、 Force Available をクリックします。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:スコープ内のリースに関する統計情報が表示されます。

Current Utilization:サブネット内のアドレスの現在の使用状況が表示されます。

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

Address Usage レポートの実行

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

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

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

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

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

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

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

図21-1 List DHCP Leases for Scope ページ(ローカル)

 

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

 

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


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


IP Lease History レポートの実行

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

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

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

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

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

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


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


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

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


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

CLI の場合は、ステップ 3 に進みます。

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

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

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

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

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

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

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

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


 

Web UI による IP リース履歴の照会

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

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

リース履歴データを照会するための選択基準も設定する必要があります。


ステップ 1 リージョナル Web UI では、 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 ユーティリティによる IP リース履歴の照会

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 オプションを使用して現地時間を指定しない場合、デフォルトでグリニッジ標準時(GMT)になります。

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

 

表21-1 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 のないアドレス)。省略した場合は、グローバル VPN に基づいて照会が行われます。または、このオプションで all 値を使用しない場合は、 session set current-vpn コマンドで設定された現在の 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 として出力されます。

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

 

表21-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

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

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

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 レポートの実行

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

CLI では、 report によって同じ機能が実行され、同じ出力が表示されます。

この両方のユーザ インターフェイスについては、「サブネット使用状況履歴レポートの生成」を参照してください。

リースの通知の受け取り

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 は、各行の先頭の空白を除去し、空白行を無視します。

リースの照会

Network Registrar は、Cisco ルータと連携して拡張プロビジョニング機能を提供できます。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 は、残りのリース時間を返します。