Cisco CNS Network Registrar Release 6.2 ユーザ ガイド
ダイナミック ホスト コンフィギュ レーションの概要
ダイナミック ホスト コンフィギュレーションの概要
発行日;2012/02/01 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 5MB) | フィードバック

目次

ダイナミック ホスト コンフィギュレーションの概要

DHCP の仕組み

DHCP ユーザ例

標準的な DHCP 管理

リース

スコープとポリシー

の DHCP 実装

DHCP と IPv6

バーチャル プライベート ネットワーク

サブネットの割り振りと DHCP アドレス ブロック

DNS アップデート

リースの取得が DNS に与える影響

リースの解除が DNS に与える影響

リースの再取得が DNS に与える影響

DHCP のフェールオーバー

フェールオーバーの仕組み

フェールオーバーの状態と移行

フェールオーバー時のアドレスの割り振り

クライアントクラス

クライアントクラスを使用しない場合の DHCP 処理

クライアントクラスを使用する場合の DHCP 処理

クライアントクラスのスコープ定義

ネットワークとスコープの選択

ダイナミック ホスト コンフィギュレーションの概要

インターネット アクセスを求めるホストはすべて、IP アドレスを持つ必要があります。インターネット管理者は、新規のユーザや、コンピュータを別のサブネットに移動させたユーザ全員に対して、次の作業を実行する必要があります。

1. 正当な IP アドレスを選択する。

2. そのアドレスを個々のワークステーションに割り当てる。

3. ワークステーションの設定パラメータを定義する。

4. DNS データベースを更新し、ワークステーション名を IP アドレスに割り当てる。

これらの作業は時間がかかり、エラーも発生しやすい作業なので、Dynamic Host Configuration Protocol(DHCP; ダイナミック ホスト コンフィギュレーション プロトコル)を使用します。DHCP を使用すれば、個々に IP アドレスを割り当てるという手間のかかる作業を省くことができます。DHCP は、TCP/IP を使用するときに必要な設定作業を減らす目的で、インターネット技術特別調査委員会(IETF)によって設計されました。DHCP は IP アドレスをホストに割り振ります。また、ホストが接続しているインターネット ネットワーク上で情報の操作や交換の実行に必要なパラメータをすべて提供します。

DHCP は TCP/IP 設定情報をローカライズします。また DHCP を使用するように設定されたシステムに対して IP アドレスを自動的に割り当てることにより、TCP/IP 設定データの割り振りを管理します。したがって、各ホストを個々に設定しなくても、ホストのインターネット アクセスを保証することができます。

DHCP の仕組み

DHCP は、ワークステーションの設定をサーバ レベルのグローバル アドレス プールにシフトすることによって、ダイナミックなアドレス割り振りを可能にします。DHCP はクライアント/サーバ モデルに基づいています。クライアント ソフトウェアはワークステーション上で動作し、サーバ ソフトウェアは DHCP サーバ上で動作します。

DHCP ユーザ例

Beth のワークステーション(bethpc)で DHCP を設定した後、最初に起動すると次の動作が実行されます。

1. ワークステーションは、ネットワーク上の DHCP サーバからの IP アドレスを自動的に要求します。

2. DHCP サーバは、インターネットを使用するのに必要な設定データを持つ IP アドレスであるリースを Beth に提供します。リースされたアドレスを使用するユーザはほかにおらず、このアドレスは Beth のワークステーションでのみ有効です。

3. bethpc は、アドレスのリースの期限満了より前にリースを更新し、期限を延長します。bethpc はサーバに到達できなくなるまで、または期限いっぱいまでリースを使用し続けます。

4. Beth が別の部署に移ってワークステーションを異なるサブネットに移動した場合は、現在のアドレスは期限満了となり、別のワークステーションがそれを利用できるようになります。新しい場所で Beth がワークステーションを最初に起動するとき、ワークステーションはサブネットの適切な DHCP サーバから IP アドレスをリースします(図18-1 を参照)。

DHCP サーバが正しい設定データを持っている限り、DHCP を使用しているワークステーションやサーバに不適切な設定が行われることはありません。したがって、追跡するのが困難な、ワークステーションやサーバの不適切な設定によるネットワークの問題が発生する可能性は低くなります。

図18-1 ホストによる IP アドレスの要求

 

例では、異なるサブネットにアドレスを提供する DHCP プロトコルと DHCP サーバのセットを示します。アドレス プールの管理をさらに容易にするために、ネットワーク ルータを DHCP リレー エージェントとして設定して、クライアント メッセージを中央の DHCP サーバに転送することがよくあります。このサーバは、サブネットのグループのアドレス プールが設定されています。

標準的な DHCP 管理

DHCP を使用するには、ネットワーク上に最低 1 つの DHCP サーバが必要です。サーバをインストールした後、次の操作を実行します。

DHCP サーバが DHCP クライアントに提供できる IP アドレスのスコープを定義します。どのアドレスが使用中で、どのアドレスが使用可能かということを把握する必要はありません。

最初の DHCP サーバがダウンしたときにセカンダリ サーバに配布を分担させたり、リースを処理させたりする場合は、セカンダリ サーバを設定します。これは、DHCP フェールオーバーと呼ばれています。詳細については、「DHCP のフェールオーバー」を参照してください。

リース

DHCP の最も重要な利点の 1 つは、ワークステーションを IP アドレスを使ってダイナミックに設定し、割り当てたアドレスにリースを関連付けられることです。DHCP は安全で信頼できる自動配布のリース メカニズムを使用し、ネットワーク内のアドレスを再利用しますが、管理者の手をわずらわせることはほとんどありません。システム管理者は、そのネットワークに固有のニーズを満たすリース ポリシーを作成することができます。

リースは「スコープ」と呼ばれるアドレス プールにまとめられ、要求元のホストが利用できる IP アドレスのセットがスコープで定義されます。リースは予約済み(ホストは常に同じ IP アドレスを受け取る)またはダイナミック(ホストはスコープ内にある次に利用可能な割り当てられていないリースを受け取る)のいずれでも可能です。サイトの DHCP サーバは、IP アドレス 192.168.1.100 から 192.168.1.199 までをリースするように設定されています(図18-2 を参照)。

スコープに対して設定したアドレスよりも多くのネットワーク装置を設置しない予定であれば、1 ~ 2 週間といった長いリース時間を定義してネットワーク トラフィックと DHCP サーバの負荷を減らすことができます。

図18-2 DHCP サーバからのリースを要求する DHCP ホスト

 

スコープとポリシー

スコープには、サブネットのアドレスのセットおよび必要な設定パラメータが入っています。ダイナミック アドレッシングを行う各サブネットに対し、最低 1 つのスコープを定義する必要があります。

ポリシーには、DHCP サーバがクライアントと通信するためのリース時間などの設定パラメータが入っています。ポリシーを使用すると、DHCP サーバが要求に応じてクライアントに提供する DHCP オプションを設定できます。ポリシーは、DHCP サーバがスコープに関する適切なオプションをすべて提供し、各スコープに対して個別に情報を指定する作業を軽減します(図18-3 を参照)。

図18-3 スコープとポリシー

 

スコープとポリシーの違いは、スコープにはアドレスに関するサーバ情報(どのアドレスがリース可能か、リースを提供する前にクライアントに PING するかどうかなど)が含まれていることです。ポリシーには、リースの期限やローカル DNS サーバのアドレスなどのクライアント設定データが含まれています。

特にサーバ上に複数のスコープがある場合は、ポリシーが役立ちます。ポリシーはすべてのスコープ用に作成することも、選択したスコープ用に作成することもできます。Network Registrar のポリシー階層は、概要のポリシーから詳細なポリシーまでを定義する方法です。たとえば、通常、各ポリシーに対してルータを指定するため、各スコープに対してポリシーが必要です。このポリシーのように、スコープに固有のポリシーは、スコープ組み込みポリシーで定義できます。リース時間を参照するポリシーなど、より一般的なポリシーは、システム全体で設定するポリシーで適用できます(「DHCP ポリシーの設定」を参照)。またポリシー割り当てを処理する拡張の作成も必要です(「拡張機能の使用による DHCP サーバの動作への影響」を参照)。

Network Registrar の DHCP 実装

Network Registrar の DHCP サーバは、ネットワーク上のホストに IP アドレスを自動的に割り当てるための信頼性の高い方法を提供します。DHCP クライアント設定を定義し、Network Registrar のデータベースを使用してクライアント IP アドレスなどのオプション TCP/IP パラメータや、システム設定パラメータの割り当てを管理することができます。TCP/IP が割り当てられるパラメータは次のとおりです。

ホスト内の各ネットワーク アダプタ カードに対する IP アドレス。

物理(サブネット)ネットワーク識別子である IP アドレスの部分を示すサブネット マスク。

サブネットを他のネットワーク セグメントに接続するデフォルト ゲートウェイ(ルータ)。

DHCP クライアントに割り当て可能な追加の設定パラメータ(ドメイン名など)。

Network Registrar は、DHCP サーバ ソフトウェアのインストール時に自動的にデータベースを作成します。DHCP スコープやポリシーを定義したように、Web UI または CLI を介してデータを追加できます。

Network Registrar DHCP サーバは、バーチャル プライベート ネットワーク(VPN)とサブネットでのアドレスの割り振りもサポートして、オンデマンド アドレス プール用のマネージャ デバイスをプールします。これらの機能については、次の項で説明します。

DHCP と IPv6

Network Registrar の DHCPv6 実装の詳細については、「IPv6 アドレスの管理」を参照してください。

バーチャル プライベート ネットワーク

バーチャル プライベート ネットワーク(VPN)を使用すると、別のネットワークの 2 つのプールに同じアドレス空間を持ち、これら 2 つのプールが重複しているプライベート ネットワーク アドレスを持つことができます。これを行うことにより、貴重なパブリック アドレスを使用せずにアドレス リソースを節約できます。ただし、このような VPN アドレスは、他の重複する IP アドレスから区別するための特別な指定文字が必要です。クライアントと同じ VPN 上にない Network Registrar DHCP サーバが、リースとアドレスをこれらのクライアントに割り振り、2 つの異なる VPN のアドレスを区別できるようになりました。

Network Registrar DHCP サーバと Cisco IOS DHCP Relay Agent を変更することにより、DHCP サーバが複数の VPN 上のクライアントを処理できます。 VPN は DHCP サーバ オブジェクトのセットを区別し、他のアドレス空間にある、その他の同一のオブジェクトから独立させます。同じアドレスを含む複数の VPN を定義できます。VPN は、Cisco IOS Relay Agent に設定した VPN 識別子に基づいて作成します。

図18-4 では、一般的な VPN 対応の DHCP 環境を示します。DHCP Relay Agent サービスには blue と red の 2 つの別々の VPN があり、それぞれのアドレス空間が重複しています。Relay Agent は、VPN blue にインターフェイス アドレス 192.168.1.1 を持ち、DHCP Server 1 に 172.27.180.232 として認識されています。VPN blue の DHCP Client 1 からのアドレス要求を処理するサーバは、クライアントと異なるネットワークまたは異なるネットワーク セグメントに存在することができ、DHCP Server 2 とフェールオーバーを構成できます(「DHCP のフェールオーバー」を参照)。Relay Agent は、クライアントのアドレス要求を DHCP サーバに送るための特別で区別されたルートを、Relay Agent と Network Registrar 管理者の間での協定に従って識別できます。DHCP サーバは、重複している IP アドレスに基づいて、両方の VPN のクライアントにリースを発行できるようになっています。

図18-4 バーチャル プライベート ネットワークの DHCP 構成

 

サブネットの割り振りと DHCP アドレス ブロック

Network Registrar は、アドレス プロビジョニングと VPN のネットワーク インフラストラクチャとして、オンデマンド アドレスの作成をサポートします。従来、DHCP サーバは、個別のホスト デバイスとだけ相互作用ができます。サブネット割り振りにより、サーバは VPN ルータや他のプロビジョニング デバイスと相互作用を行って、IP サブネット全体をプロビジョニングできます。この Network Registrar 機能は、現在 Cisco IOS Relay Agent でサポートされているオンデマンド アドレス プール機能を向上させます。

Network Registrar は、明示的にプロビジョニングされたサブネットをサポートします。DHCP サーバのアドレス空間とサブネット割り振りポリシーは、明示的に設定する必要があり、これによってサーバがプールやリースを割り振れるようになります。その結果、サーバをプール マネージャとして設定して、サブネットを管理したり、クライアント デバイスにサブネットを委任したりすることができます。

DHCP サブネット割り振りは、Network Registrar の DHCP サーバ アドレス ブロック オブジェクトを使用して管理します。DHCP アドレス ブロックは、割り当てのために DHCP サーバに委任された連続する IP アドレス の範囲です。サーバは、これらのアドレスをさらに複数のプールに分割することを想定しています。したがって、そのサーバだけでなく他のサーバやデバイスがこれらのアドレスを割り振ることができます。DHCP アドレス ブロックは、サブネットの親です。このような DHCP アドレス ブロックは、Network Registrar Web UI を使用して作成するスタティックなアドレス ブロックとは区別されます。DHCP アドレス ブロックは、スタティックなアドレス範囲やリース予約を含むことはできません。

図18-5 では、DHCP サーバがサブネット全体をアクセス コンセントレータまたは他のプロビジョニング デバイスに割り振り、さらに個別のクライアントを処理している環境の例を示します。従来のクライアント/サーバ関係を図の左側に、アクセス コンセントレータへのサブネット割り振りを図の右側に示します。たとえば、ダイヤルアップのお客様がサービス プロバイダーのネットワークの 2 つの ISP ゲートウェイ(ルータ)に接続し、そのルータが DHCP のある管理ネットワーク セグメントに接続されています。ゲートウェイのプロビジョンは、DHCP サーバから要求されるサブネットに基づき、接続クライアントにアドレッシングします。

図18-5 DHCP サブネット割り振りの構成例

 

DNS アップデート

DHCP を使用すると IP アドレスを配布する手間が省けますが、DHCP クライアント名とアドレスで DNS サーバを更新する必要があります。DNS アップデートによって、現在の名前およびアドレスを維持する作業を自動化できます。Network Registrar の DNS アップデート機能を使用して、DHCP サーバは、ネームからアドレスへの関連付けの発生時または変更時に、対応する DNS サーバを見つけることができます。クライアントがリースを取得すると、Network Registrar はホスト データを追加するように DNS サーバに命じます。リースが期限満了になった場合、またはホストがリースを停止した場合、Network Registrar は関連付けを解除するように DNS サーバに命じます。

正常に動作しているときは、DHCP を介してどれほど大幅にクライアントのアドレスが変更されても、手動で DNS を再設定する必要はありません。Network Registrar は、クライアント ワークステーションから提供されるホスト名を使用します。クライアントから名前が提供されなかった場合は、Network Registrar でクライアントの名前を合成することも可能です。または、クライアント ルックアップ機能を使用して、クライアントの、事前に設定されたホスト名を使用することもできます。

リースの取得が DNS に与える影響

ExampleCo 社では、管理者は DHCP サーバ上にスコープを作成し、100 リース(192.168.1.100~192.168.1.199)をネットワーク上のワークステーションに割り振っています。各ワークステーションは、固有の名前を取得します。また、管理者は DNS アップデートを使用するための DHCP サーバを設定し、それに対応するように設定した DNS サーバに関連付けます。管理者は、DNS サーバのデータベースに名前を登録する必要はありません。

月曜日の朝に、Beth(bethpc のユーザ)はアドレスなしに Web サイトにアクセスするためにログインを試みます。ホストは起動時に、アドレスの要求をブロードキャストします(図18-6 を参照)。

図18-6 ExampleCo 社での DNS アップデート

 

DHCP は次の動作を実行します。

1. 次に使用可能な(割り当てられていない)IP アドレス(192.168.1.125)を bethpc に提供する。

2. ホスト名およびアドレス(bethpc 192.168.1.125)で DNS サーバをアップデートする。

これで、Beth は Web サイトにアクセスできます。また、Beth のマシンの名前を IP アドレスに変換したり、その逆を実行する必要があるプログラムは、DNS サーバに照会できます。

リースの解除が DNS に与える影響

後日、Beth は旅行することになりました。彼女はホストを終了しました。ホストにはリースされたアドレスがありますが、このリースは 3 日後に期限満了になります。リースを解放すると、DHCP サーバは次の動作を実行します。

1. IP アドレスを他のユーザが使えるようになったことを通知します(図18-7 を参照)。

2. ホスト名およびアドレスを削除することにより、DNS サーバを更新します。これで、DNS サーバから bethpc とそのアドレスに関する情報がなくなりました。

図18-7 リースの解放

 

リースの再取得が DNS に与える影響

Beth は旅行から戻ると、ホストを再度起動しました。

1. 彼女のワークステーションは、IP アドレスの要求をブロードキャストします。

2. DHCP サーバは、ホストが適切なネットワーク上にあるかをチェックします。適切なネットワーク上にあった場合は、そのサーバからアドレスが発行されます。適切なネットワーク上になかった場合は、適切なネットワーク上にあるサーバがアドレスを発行します。

3. DHCP サーバは、ホストおよびアドレスのデータによって DNS サーバを再度更新します。

DHCP のフェールオーバー

DHCP は複数のサーバで使用できるので(RFC 2131 を参照)、1 つのサーバが要求元のクライアントにリースを提供できなかった場合はもう 1 つのサーバが引き継ぐことができるように、これらのサーバを設定できます。Network Registrar では、2 つのサーバが冗長パートナーとして動作する場合に、DHCP フェールオーバー機能を提供します。既存の DHCP クライアントは、自分が発した要求にどのサーバが応答しているかを認識しまたは認識を試みなくても、リースの維持および更新ができます。

フェールオーバーの仕組み

フェールオーバーはパートナー サーバ関係に基づいています。パートナーは、同一のスコープ、ポリシー、およびクライアントクラスを持つ必要があります。サーバの起動後、各サーバは互いに接続します。メイン サーバは、アドレスのプライベート プールを提供し、すべてのクライアント操作によってパートナーを更新します。メイン サーバで障害が発生した場合は、パートナーが引き継ぎ、そのプライベート プールを使ってリースを提供、更新します。メイン サーバは、再度動作可能になると、管理者の介入なしにパートナーとの再統合を行います。これらのサーバは、フェールオーバーのペアという関係にあります。

フェールオーバー プロトコルは、次の場合にも DHCP が動作するように設計されています。

メイン サーバの障害:メイン サーバがダウンしている間、パートナーがサービスを引き継ぎます。パートナーの更新前にメイン サーバに障害が発生しても、サーバが重複アドレスを生成することはありません。

通信障害:障害があるのが相手側サーバなのか、サーバとの通信なのかがわからなくても、パートナーは正しく動作します。両方のサーバが動作し、それぞれがクライアントのサブセットとだけ通信していても、重複アドレスは発行しません。

フェールオーバー構成は、通常、基本、バック オフィス、または対称という 3 つの種類があります。フェールオーバーは次のように実行されます。

1. パートナーが接続します。

2. すべての現存するリースに関するデータが、メイン サーバからパートナー サーバに提供されます。

3. バックアップ サーバは、メイン サーバからバックアップ アドレスのプールを要求します。

4. メイン サーバは、各スコープからの利用可能なアドレスのパーセンテージをパートナー サーバに応答します。

5. バックアップ サーバは、メイン サーバがダウンしていることを検出しない限りは、すべての DHCPDISCOVER 要求を無視します。正常動作時には、DHCPRENEW と DHCPREBINDING 要求だけが処理されます。DHCPDISCOVER 要求が、利用可能なサーバを検索するためにブロードキャストされます。

6. メイン サーバは、すべてのクライアントの動作結果によってパートナー サーバを更新します。

Network Registrar 6.2 では、フェールオーバー ペアのサーバを自動的に同期化できます。2 つのサーバは使用可能なリースのバランスをダイナミックに再調整します。メイン サーバが使用可能なリースの大部分を提供した場合、パートナーからリースを解放できます。


) フェールオーバーは常に、サーバがクライアント トラフィックを処理するために使用するインターフェイスと同じインターフェイスで設定します。


フェールオーバーの状態と移行

通常の動作では、フェールオーバー パートナーは 1 つの状態から別の状態に移行します。それらのサーバは、その状態の移行段階でのアクションがすべて完了するか、通信障害の場合は、次の状態が満たされるまで現在の状態を維持します。 表18-1 は、フェールオーバーの状態と移行を示しています。

 

表18-1 フェールオーバーの状態と移行

状態
サーバのアクション

STARTUP

パートナー サーバと連絡してその状態の把握を試み、通常は数秒後にもう 1 つの状態に移行します。

NORMAL

もう一方のサーバと通信できます。メイン サーバとバックアップ サーバは、この状態では別の動作をします。

メイン サーバは、プールを使用してクライアントの要求すべてに応答します。そのパートナーがバックアップ プールを要求する場合、メイン サーバが提供します。

バックアップ サーバはアップデート要求と再バインド要求だけに応答します。メイン サーバからバックアップ プールを要求します。

COMMUNICATIONS-
INTERRUPTED

パートナー サーバと通信できません。パートナー サーバか、このサーバの通信がダウンしています。通信が切断されてから復旧されたとき、またはサーバが稼動状態とダウン状態を繰り返しているとき、サーバはこの状態と NORMAL 状態を繰り返します。この間、サーバは重複アドレスを与えることはありません。

この状態のときは通常介入する必要はなく、サーバを PARTNER-DOWN 状態に移行します。しかし、この操作が実用的でない場合があります。この状態で動作しているサーバは、使用可能なプールを有効にしていません。このため、サーバでクライアントを実際に処理できる時間が制限されることがあります。

COMMUNICATIONS-INTERRUPTED 状態のサーバには次の制限があります。

有効期限が切れた IP アドレスを別のクライアントに再割り振りできません。

現在のリース時間を超えて、最大クライアント リード タイム(MCLT)より長いリースまたは更新を提供できません。MCLT は、クライアントのリース期間をバックアップ サーバのリース期間よりどのくらい前に終了させるかを制限する短い追加時間です。

バックアップ サーバには小さなプールしかなく、メイン サーバにプールのほとんどがあるので、バックアップ サーバに新しいクライアントに提供するアドレスがなくなることはありません。

サーバは、それ自体に割り振られたアドレス数と新しいクライアントの DHCPDISCOVER または INIT-REBOOT パケットの到着率によって制限されます。新しいクライアント到着率や回転率が高い場合、より短時間でサーバを PARTNER-DOWN 状態に移行することが必要な場合があります。

PARTNER-DOWN

次の事実のいずれかに基づいて、1 つのサーバのみが動作しているときと同じように動作します。

シャットダウン時にもう一方のサーバからそれを通知された場合。

管理者がサーバを PARTNER-DOWN 状態に変更した場合。

安全期間が終了し、もう一方のサーバが自動的にこの状態になった場合。

この状態では、サーバは、まだ動作可能であるパートナー サーバが異なるクライアントのセットにサービスを提供していることを無視します。そのすべてのアドレスを制御し、リースと拡張を提供し、アドレスを再割り振りします。COMMUNICATIONS-INTERRUPTED 状態のサーバに対するのと同じ制約は適用されません。

どちらのサーバもこの状態になることはできますが、2 つのサーバが重複アドレスを発行せず、後に正しく同期化できるよう、同時にこの状態になるのは 1 つのサーバだけです。それまで、アドレスはペンディング使用可能状態にあります。

POTENTIAL-
CONFLICT

自動再統合が保証されていない状態であり、もう 1 つのサーバと再統合を試みています。サーバは 2 つのクライアント(稼動していない可能性があります)が同じアドレスを提供されて受け取ったことを判別し、その競合の解決を試みることがあります。

RECOVER

安定した記憶域にデータが保存されていないか、または PARTNER-DOWN 状態から回復した後再統合を試み、安定した記憶域をリフレッシュしようとしています。この状態のメイン サーバは、すぐにリースの提供を再開始しません。したがって、この状態のサーバをリロードしないでください。

RECOVER-DONE

RECOVER または PARTNER-DOWN 状態から、または
COMMUNICATIONS-INTERRUPTED から NORMAL 状態に移行できます。

PAUSED

もう一方のサーバに短時間稼動しなくなることを通知できます。次にパートナー サーバが COMMUNICATIONS-INTERRUPTED 状態に移行し、クライアントの処理を開始します。

SHUTDOWN

サーバは、もう一方のサーバに長時間稼動しなくなることを通知できます。次にもう一方のサーバが PARTNER-DOWN 状態に移行し、完全に処理を引き継ぎます。

フェールオーバー時のアドレスの割り振り

ネットワーク パーティション(両方のサーバがクライアントとは通信できても、互いに通信することができない)の場合でもフェールオーバーのペアを成すサーバの動作を維持するには、1 つのサーバを動作させるために必要とする数より多いアドレスを割り振る必要があります。各スコープのアドレス プール内の現在使用可能な(割り当てられていない)アドレスのパーセンテージをパートナー サーバに割り振るように、メイン サーバを設定する必要があります。その結果、これらのアドレスは、メイン サーバでは使用できなくなります。パートナー サーバは、メイン サーバと通信できずメイン サーバがダウンしているかどうかわからない場合に、これらのアドレスを使用します。

追加のアドレスはいくつ必要でしょうか。すべての環境に対して 1 つのパーセンテージが存在するわけではありません。パーセンテージは、新しい DHCP クライアントの到着率とネットワーク管理スタッフの反応時間によって異なります。バックアップ サーバでは、メイン サーバがダウンしているかどうかが分からない期間に到着する新しい DHCP クライアントすべての要求を満たすために、個々のスコープからの十分なアドレスが必要となります。

バックアップ サーバは、PARTNER-DOWN 状態にある場合でも、任意のリースを再割り振りする前に、リース期間および最大クライアント リード タイム(MCLT)を待ちます。これらの期間が終了すると、バックアップ サーバは次を実行します。

バックアップ サーバのプライベート アドレス プールからリースを提供する。

メイン サーバのアドレス プールからリースを提供する。

期限が終了したリースを新しいクライアントに提供する。

稼動時間中の場合、管理スタッフが 2 時間以内に COMMUNICATIONS INTERRUPTED 状態に応答し、メイン サーバが動作中であるかどうかを判断できる場合、バックアップ サーバでは、その 2 時間の間に到着する可能性のある新しい DHCP クライアントの妥当な範囲の最大数に対処できるだけのアドレスを必要とします。

稼動時間外の場合は、管理スタッフが 12 時間以内に同じ状況に対応できる、DHCP クライアントから事前に通知されていない到着率も低くなることを考慮した場合、バックアップ サーバでは、その 12 時間の間に到着する可能性のある新しい DHCP クライアントの妥当な範囲の最大数に対処できるだけのアドレスを必要とします。

したがって、バックアップ サーバが単独で制御する必要のあるアドレス数は、ピーク時および非ピーク時に提供されたアドレス数のうちの大きい方になり、各スコープで現在使用可能な(割り当てられていない)アドレスのパーセンテージとして表されます。

クライアントクラス

クラスをクライアントに割り当てることは、DHCP のアドレッシングおよびアドレスの Quality of Service の問題にとって重要です。Network Registrar クライアントおよびクライアントクラス機能を使用して、共通のネットワークに接続するユーザに対して異なるサービスを提供することができます。管理基準に基づいてユーザ コミュニティをグループ化し、各ユーザが適切なサービス クラスを確実に受け取れるようにすることが可能です。

Network Registrar のクライアントクラス機能を使用して設定パラメータを制御できますが、次のような設定に使うのが最も一般的です。

リース期間:クライアントのセットがどのくらい長くアドレスを維持するか。

IP アドレス範囲:どのリース プールからクライアントにアドレスを割り当てるか。

DNS サーバ アドレス:クライアントがどこに DNS のクエリーを行うか。

DNS ホスト名:クライアントにどのような名前を割り当てるか。

サービスの拒絶:権限のないクライアントにリースを提供するかどうか。

クライアントクラス機能を利用する方法の 1 つとして、ビジターにネットワークの(すべてではなく)一部に対するアクセスを許可する場合があります。たとえば、ExampleCo 社へのビジターである Joe がラップトップ コンピュータから example.com ネットワークに接続すると、Network Registrar からは外部として認識されます。ExampleCo 社は、ネットワーク全体にアクセス可能と認識されるクライアントクラスを 1 つ作成し、サブネットのみへのアクセスを使用するビジター クラスを別に作成します。Joe が標準のビジター アクセス以上のアクセスを必要とする場合は、彼のラップトップを Network Registrar システム管理者に登録して、適切なサービスが提供される別のクラスに追加してもらう必要があります。

次に、DHCP がアドレスを割り当てる通常のプロセス、およびクライアントクラス機能を使用する場合の処理方法について説明します。

クライアントクラスを使用しない場合の DHCP 処理

クライアントクラスの処理を適用する方法を理解する上で、DHCP サーバによるクライアント要求の処理方法について知ることが役立ちます。サーバは次の 3 種類の作業を実行できます。

IP アドレスを割り当てる。

適切な DHCP オプション(設定パラメータ)を割り当てる。

完全修飾ドメイン名(FQDN)をオプションで割り当て、その名前で DNS サーバを更新する。

DHCP は次の動作を実行します。

1. 定義されたスコープからクライアントにアドレスを割り当てる:DHCP サーバは、クライアントに対するアドレスを選択するために、(要求パケットの内容に基づいて)クライアントのサブセットを決定し、そのサブネットに対する適切なスコープを見つけます。

1 つのサブネットまたはいくつかのネットワーク セグメントに複数のスコープがある(マルチネッティングと呼ばれる)場合は、DHCP サーバがこれらのスコープの中からラウンドロビン方式で選択することがあります。または、DHCP サーバのアドレス割り振り優先機能を使用してスコープ選択の優先度を変更することもできます(「割り振り優先度を使用した複数スコープの設定」を参照)。サーバはスコープを選択した後で、そのスコープから使用可能な(割り当てられていない)アドレスを選択します。

a. 定義されたポリシーから DHCP オプションを割り当てる:Network Registrar はポリシーを使用してオプションをグループ化します。2 種類のポリシーがあります。scope-specific および system default です。クライアントが要求する各 DHCP オプションに対して、DHCP サーバは定義された順序でその値を検索します。

b. scope-specific ポリシーにオプションが含まれている場合は、サーバはその値をクライアントに返し検索を終了します。

c. オプションが見つからない場合は、サーバは system default ポリシーを検索してその値を返し、検索を終了します。

d. いずれのポリシーにもオプションが含まれていない場合は、サーバはクライアントに値を返さず、ログにエラーを出力します。

e. サーバは、要求された各オプションに対して、このプロセスを繰り返します。

2. DNS アップデートが有効な場合、サーバは FQDN をクライアントに割り当てます。DNS アップデートをイネーブルにした場合、Network Registrar はクライアントの名前およびアドレスを DNS ホスト テーブルに追加します。「DNS アップデート」を参照してください。クライアントの名前は次のいずれかです。

クライアントのリース要求で指定されている名前(デフォルト)。

MAC アドレス(たとえば、00:d0:ba:d3:bd:3b のようなハードウェア アドレス)。

デフォルトのプレフィックス dhcp または固有のプレフィックスを使用した一意の名前。

クライアントクラスを使用する場合の DHCP 処理

DHCP サーバに対してクライアントクラス機能をイネーブルにした場合、要求の処理は「クライアントクラスを使用しない場合の DHCP 処理」で説明したものと同じ 3 つの作業(IP アドレスの割り当て、オプションの割り当て、ドメイン名の割り当て)を実行しますが、そこに機能が追加されます。DHCP は次の動作を実行します。

1. アドレスを割り当てる前にクライアント プロパティおよびクライアントクラスが含まれていることを考慮する:通常の DHCP 処理においては、DHCP サーバはクライアントのサブネットを決定します。次に、サーバは、データベースに、クライアントクラス定義済みのアドレスまたはこのクライアントの MAC アドレスがあるかどうかをチェックします。これは次のように処理されます。

a. クライアントクラス ルックアップ ID 式により定義されているクライアントクラスがある場合、クライアントはクライアントクラスのメンバーになります。

b. MAC アドレスがない場合は、デフォルト クライアントを使用します。たとえば、デフォルト クライアントのクライアントクラス名を Guest に設定し、これらのクライアントに許可されるネットワーク オペレーションをクライアントクラスで制限できます(オプションおよびアドレス選択を使用)。

c. MAC アドレスもデフォルト クライアントもない場合は、サーバは通常の DHCP 処理によってクライアントを処理します。

d. クライアント指定子がなく、MAC アドレスがある場合は、MAC アドレスがクライアント指定子に変換されます。デフォルト クライアントが定義されている場合、未知のクライアントはデフォルト クライアントにマッピングされます。

スコープは、クライアントがアクセス可能なサブネット上のアドレスを持つ必要があります。スコープには、アドレスをクライアントクラスに関連付けるスコープ選択タグが必要です。同じクライアントを異なるアドレス プールに割り当てるには、別個のスコープを使用する必要があります。たとえば、スコープは Employee または Guest のいずれかのスコープ選択タグを持ちますが、その両方は持ちません。この場合、各サブネットに 2 つのスコープがあるということです。1 つはスコープ選択タグの Employee を持ち、もう 1 つは Guest を持っています。各スコープには、ユーザ グループに適切なアクセスの権利を提供するための異なる関連ポリシーとアドレス範囲があります。

2. クライアントクラスの DHCP オプションの有無をチェックする:通常の DHCP 処理では、サーバは scope-specific および system default の DHCP オプションをチェックします。クライアントクラスの場合も、最初に client-specific のオプションをチェックしてから、client-class-specific のオプションをチェックします。

3. 追加の FQDN 割り当てオプションを提供する:クライアントから要求されるホスト名を使用する通常のネーム割り当てプロセス以外に、サーバは次の動作を実行できます。

明示的なホスト名を指定してホスト名を上書きする。

クライアントが要求したホスト名を削除し、このホスト名を置き換えない。

クライアントの MAC アドレスからホスト名を合成する。

クライアントクラスのスコープ定義

通常、クライアントクラスを使用することの動機となる要因は、いずれかのアドレス プールからクライアントにアドレスを提供することです。動機となる別の要素は、クライアントに異なるオプション値またはリース時間を提供することです。別個のプールからクライアント アドレスを提供する場合、複数のスコープを定義する必要があります。

1 つのサブネットで複数のスコープを取得するためには、それらが同じネットワーク セグメントにある必要があります。ネットワークは、Network Registrar で直接設定されるのではなく、スコープ設定から推定されます。スコープは次のように関連付けられます(最終的には同じネットワークになります)。

暗黙的:2 つのスコープが同じネットワーク番号とサブネット マスクを持つことです。これらのスコープは、明示的な設定なしに、自然に同じネットワークになります。

明示的:1 つのスコープがもう 1 つのスコープのセカンダリとしてマークされます。これは、セカンダリとしてマークされているスコープが、プライマリと関連しないネットワークサブネット マスクを持つときに必要になります。一例としては、10.0.0.0 ネットワーク アドレスのセットを通常のルート可能なネットワーク セグメントに置く場合です。

Network Registrar DHCP サーバはデータベースからスコープ設定を読み取ると、すべてのスコープをネットワークに配置し、この情報をログに記録します。同じネットワーク番号とサブネット マスクを持つスコープは、同じネットワークになります。またセカンダリ スコープはプライマリ スコープのネットワーク上に配置されます。

ネットワークとスコープの選択

DHCP パケットが到着すると、サーバはそれが次のどのアドレスから来たのかを判断します。

ゲートウェイ アドレス giaddr ):BOOTP リレー経由で送信されるパケット用が存在する場合

ブロードキャスト パケットが到着したインターフェイスのインターフェイス アドレス:DHCP クライアントがあるネットワーク セグメントに、DHCP サーバも直接接続されている場合

どの場合も、DHCP サーバはゲートウェイまたはインターフェイス アドレスからネットワークを判断します。次に、ネットワークに複数のスコープが存在する場合、サーバはどのスコープから DHCP クライアントにアドレスを割り振るかを決定します。サーバは、このタイプのクライアントにアドレスを割り振れるスコープを常に検索します。たとえば、DHCP クライアントは DHCP をサポートするスコープを必要とし、BOOTP クライアントは BOOTP をサポートするスコープを必要とします。クライアントが DHCP クライアントであって、DHCP をサポートする複数のスコープが存在し、それぞれに使用可能な(割り当てられていない)アドレスがある場合、DHCP サーバは、ラウンドロビン方式または割り振り優先度方式で、それらのスコープから 1 つの IP アドレスを割り振ります。

scope-selection タグと client-class を使用すると、次のように IP アドレスを割り振るように DHCP サーバを設定することができます。

ネットワーク上の 1 つ以上のスコープを 1 つのクラスのクライアントに割り当てる。

異なるセットのスコープを異なるクラスのクライアントに割り当てる。

後者の場合、ゲートウェイまたはインターフェイス アドレスがネットワークを決定します。
client-class 機能は、scope-selection タグのメカニズムによって、ネットワーク上で使用するスコープを決定します。