複数のサブネット環境のための DHCP 構成

このシナリオでは、マルチ (複数の) サブネットに含まれるクライアントに対して構成情報を提供し、かつそのフォールト トレランスが維持され、セキュリティで保護されるように、動的ホスト構成プロトコル (DHCP) サーバーを構成する方法を紹介します。

トピック

目的
設計のロジック
IP アドレスとホストの自動構成
フォールト トレランス
承認されていない DHCP サーバーからの保護
ユーザー クラスのサポート
機能するしくみ
実装した方法
セットアップ手順
その他の参考資料

目的

このシナリオの目的は、次のとおりです。

• マルチ サブネット企業内の複数のサイトに含まれる Windows 2000 クライアントと Windows 2000 以外のクライアントの両方に IP アドレスとホスト構成を自動的に割り当てます。これが、このシナリオの第一の目的です。

• 主要な DHCP サーバーが使用できなくなった場合に備えて、サーバーの冗長性を確保することによってフォールト トレランスを実現します。

• 承認されていない Windows 2000 DHCP サーバーによるアクセスから保護します。

• デスクトップ コンピュータ用のリースとは異なるポータブル コンピュータ用のリースの割り当てに使用されるユーザー クラスをサポートします。

次の「設計のロジック」では、上に指摘した目的に対応する方法を紹介します。

設計のロジック

このシナリオで例として扱っている Resource Kit Corporation という企業では、Milan と Seville にサイトを構築しています。これらのサイトには、IP アドレスとサブネット マスク、および関連する IP ホスト情報を自動構成する必要がある Windows 2000 ベースのコンピュータと Windows 2000 ベース以外のコンピュータが含まれています。また、各サイトには、手動で構成でき、自動構成する必要がないコンピュータも含まれています。

この企業の物理的および論理的レイアウトは、この場合のソリューションの設計と実装に大きな影響を与えます。そのレイアウトを図 1 に示します。

図 1: シナリオのトポロジ

このシナリオに含まれているサイトは、Milan、Seville、および Seattle に構築されています。Milan サイトは、172.16.128.0/22、172.16.132.0/22、および 172.16.136.0/22 という 3 つのサブネットで構成されています。Milan サイトのこれらのサブネットのうちで、Windows 2000 ベースのクライアントと Windows 2000 ベース以外のクライアントが含まれているのは、172.16.136.0/22 です。一方、Seville サイトは、172.16.160.0/24 と 172.16.161.0/24 という 2 つのサブネットで構成されています。Seville サイトのクライアント サブネットは、172.16.161.0/24 です。

Milan サイトでは、仮想ローカル エリア ネットワーク (VLAN) を使用して、ネットワークをレイヤ 2 で定義されたさらに小さなセグメントに分割しています。その結果、各ネットワーク セグメントの帯域幅を増加することが可能になっています。Milan サイト内に設置されている Cisco 6006 レイヤ 2 スイッチ (MIL-EU-CISCO-02) は、ネットワークを 3 つの VLAN に分割する役割を果たしています。また、エッジ ルーターの MIL-EU-CISCO-01 は、3 つの VLAN の間と外部のサブネットワークに対して、パケットのレイヤ 3 ルーティング機能を提供しています。

Milan サイトと Seville サイトは、一連のルーターを介してほかのサイトと接続されています。Milan サイトでは、Cisco 製のルーター MIL-EU-CISCO-01 が Milan の 3 つのサブネットに対するゲートウェイとしての機能を果たしています。Milan サイトは、T1 回線によって Seattle サイトと Seville サイトに直接接続されています。

Seville サイトでは、ルーティングとリモート サービスを実行している Windows 2000 ベースのサーバー (SEV-SV-W2RT-01) が、Seville の各サブネットに対するゲートウェイとしての機能を果たしています。Seville サイトは、Windows 2000 ベースのサーバー ルーターを介して T1 回線によって Milan サイトに接続されています。

IP アドレスとホストの自動構成

このシナリオの第一の目的である IP アドレスとホストの構成情報の自動割り当ては、Milan サイトと Seville サイト内に動的ホスト構成プロトコル (DHCP) を実装することによって実現されています。DHCP は、ホストの IP 構成の管理を単純化するための TCP/IP 標準です。DHCPの標準では、 DHCP サーバーを使用して、ネットワーク内の DHCP 対応クライアントに IP アドレスとその他の関連する構成の詳細情報を動的に割り当てる処理を管理する方法が規定されています。

ただし、利用可能な範囲に含まれる IP アドレスの一部は、DHCP で使用する範囲から除外し、将来サブネット内にインストールする可能性のある静的ホストのために予約しておきます。表 1 に、各サブネットで利用可能な IP アドレスと除外されている IP アドレスの範囲を示します。

表 1 利用可能な IP アドレスと除外されている IP アドレス

各サイト内で DHCP サーバーが設置されている場所は、このソリューションの実装の重要な要素になっています。Reskit ネットワークのほかの部分との間でネットワーク設計における一貫性を維持するために、すべての

DHCP サーバーは、クライアント サブネットとは別のサブネットに設置されています。たとえば Milan サイトの場合には、サブネット 172.16.132.0/22 に設定されている Windows 2000 ベースのサーバーである MIL-EU-DHCP-01 が、サブネット 172.16.136.0/22 に含まれるクライアントに対して DHCP サービスを提供するように構成されています。また、Sevilleサイトの場合には、サブネット 172.16.160.0/24 に設置されている Windows 2000 ベースのサーバーである

SEV-SV-DHCP-01 が、サブネット 172.16.161.0/24 に含まれるすべてのクライアントの DHCP サーバーとして機能します。

DHCP サーバーと DHCP クライアントの間のすべてのルーターは、DHCP リレー用に構成しなければなりません。または、DHCP リレー エージェントをクライアント サブネット内に含める必要があります。Microsoft® Windows® 2000 Server と Cisco IOS バージョン 12.1 (2) のルーティングとリモート アクセス サービスでは、両方ともサブネット間の DHCP メッセージのリレーをサポートしています。これらの環境のそれぞれに対する DHCPリレーの構成については、このシナリオの「実装した方法」で詳細に説明します。

フォールト トレランス

サイト内の主要な DHCP サーバーへの接続 (またはサーバーそのもの) が使用できなくなった場合でも、DHCP クライアントに対するサービスを継続できるようにするために、フォールト トレランス機能を構成しておかなければなりません。Reskitでは、一貫した DHCP サービスを確実に行えるようにするために、次のような 2 とおりの最適な運用形態を採用しています。

• フォールト トレランスを実現するために、個々の独立したサブネットに複数の DHCP サーバーを設置します。そのうちの 1 つは DHCP リースの主要な提供元として機能し、その他は代替サーバーとして機能するように構成します。

• 使用可能な IP アドレスの範囲を複数のサーバーの間で分割します。つまり、アクティブな DHCP スコープの 80% を主要な DHCP サーバーでクライアントに割り当て、残りの 20% を代替サーバーで割り当てるように振り分けます (80/20 ルール) 。

これらの 2 とおりの最適な運用形態に従って、Milan サイト Seville サイトの両方に対して代替 DHCP サーバーとして機能するようにもう 1 台のコンピュータが構成されています。

Seattle サイトに設置されている DHCP サーバー SEA-NA-DHCP-04 は、企業全体の代替 DHCP サーバーとして構成されています。つまり、このサーバーは、Milan サイトと Seville サイトを含む企業内のすべてのサブネットに含まれるホスト用のスコープで構成されています。Seattle サイトの既存の DHCP サーバーを使用することによって、DHCP サービスのサポート、管理、およびハードウェア コストを企業全体にわたって分散し、その結果としてコスト効率の高いフォールト トレランス ソリューションを実現しています。

さらに堅牢なフォールト トレランス ソリューションを実現するために、サーバー SEA-NA-DHCP-04 は、実際には SEA-NA-DHCP-02 と SEA-NA-DHCP-03 という 2 つのサーバーで構成されています。これらは、クラスタ サーバーである SEA-NA-DHCP-04 のノードとして構成されています。クラスタ ノードは、クラスタ サービスを実行し、スコープの共有ディスクとその他の DHCP データベース情報にアクセスできるように構成されます。

80/20 ルールを使用した場合、Milan サイトと Seville サイトで使用可能な IP リースの 20% は、サーバー SEA-NA-DHCP-04 上で構成されます。使用可能な IP リースの残りの 80% は、Milan サイトと Seville サイトのローカルな DHCP サーバー上で構成されます。

この論理的および物理的構成によって、ヨーロッパのサイト (Milan と Seville) では、次に説明するような複数のレベルでフォールト トレランスが実現されます。

• 正常な状況の場合、クライアントから IP リースの割り当ておよび更新が要求されると、それぞれのサイトの DHCP サーバーである MIL-EU-DHCP-01 または SEV-SV-DHCP-01 によってそれらの要求が満たされます。これらのサーバーには、Milan または Sevilleのサブネットで使用可能な IP アドレスの 80% が含まれています。

• Milan または Seville の DHCP サーバーが使用できなくなった場合、DHCP メッセージは Seattle の DHCP サーバーに転送されます。このサーバーは、Milan と Seville のそれぞれのサブネットで使用可能な IP アドレスの 20% を含むスコープで構成されています。

• Seattle の DHCP サーバーは、クラスタ サーバーとして構成されています。クラスタの 1 つのノードが使用できなくなった場合には、クラスタ サービスによって別のノードが自動的にオンラインになります。

Milan サイトまたは Seville サイトの DHCP 機能を使用できなくなる状況は、次のような場合に発生する可能性があると考えられます。

• ローカルな DHCP サーバー (MIL-EU-DHCP-01 または SEV-SV-DHCP-01) および仲介となっているルーターまたはスイッチのいずれか (MIL-EU-CISCO-02、SEV-SV-W2RT-01、または SEA-NA-CISCO-01) が同時に使用できなくなる場合。

• ローカルな DHCP サーバー (MIL-EU-DHCP-01 または SEV-SV-DHCP-01) およびクラスタ サーバー SEA-NA-DHCP-04 の両方のノードが使用できなくなる場合。

• Milan サイトのスイッチ MIL-EU-CISCO-02 または Seville サイトのルーター SEV-SV-W2RT-01 が使用できなくなる場合。

DHCP サーバーと DHCP クライアントの間の接続が失われると、DHCP クライアントで新しいリースを取得できなくなるか、あるいは DHCP サーバーで T1 または T2 時刻に既存のリースを更新できなくなります。DHCP クライアントがリースを取得した場合、T1 時刻に達するまで正常に動作します。T1 時刻に達すると、DHCP クライアントは、そのリースの更新を試みます。DHCP クライアントのリースが T1 時刻の後で更新されたが、まだ T2 時刻には達していない場合には、それまでと変わらず正常に動作し続けます。クライアントが T2 時刻までにアドレスを更新することができなかった場合、そのクライアントはリバインド状態に入り、そのリースを更新できる機能を持つほかのサーバーを検索するために DHCPDISCOVER メッセージをブロードキャストします。

DHCP サーバーは地理的に広く分散して配置されるのが普通ですが、これらのサーバーを中央で集中的にインストールしてメンテナンスを行うことも可能です。Windows 2000 の機能であるターミナル サービスを使用すると、技術的なサポートが制限されていたり利用できなかったりするリモート コンピュータ上に、DHCP サービスを初期インストールすることができます。DHCP サービスをインストールした後は、Microsoft 管理コンソール (MMC) を使用して、そのメンテナンスを行うことができます。適切な権限を承認されたユーザーなら、MMC を使用してリモート環境に設置されている DHCP サーバーに接続し、その管理作業を実行できます。

承認されていない DHCP サーバーからの保護

承認されていない (認証されていない) Windows 2000 ベースの DHCP サーバーによってネットワークにアクセスされ、不正な IP アドレスが発行される可能性があるという懸念に対しては、Windows 2000 に組み込まれているディレクトリ サービスである Active Directory・に、その構成プロセスにおいてすべての Windows 2000 DHCP サーバーを登録するという方法で対処できます。この方法によって、承認されていない Windows 2000 ベースの DHCP サーバーによってネットワーク内で初期化が行われる可能性が防止されます。

ユーザー クラスのサポート

もう 1 つの要件として、デスクトップ型のクライアントから発行された DHCP 要求とポータブル型のクライアントから発行された DHCP 要求を区別できる機能が求められています。これは、後者に割り当てる IP リースの有効期間を比較的短くする必要があるからです。この要件を満たす手段としては、ユーザー クラスを使用します。この機能を使用すると、リース期間を始めとするクラス固有の DHCP オプションを構成し、要求側のクライアントの種類に応じてそれらを関連付けることができます。また、DHCP サーバーの側でユーザー クラスを作成して構成することに加えて、Windows 2000 では ipconfig /setclassid コマンドを使用することによって、クライアント コンピュータの側で DHCP ユーザー クラス ID を設定することもできます。

このシナリオでは、Millap と Sevlap という 2 つのユーザー クラスを作成し、それらによって Milan サイトと Seville サイトにおけるポータブル コンピュータのリース要求をそれぞれ区別しています。なお、Windows 2000 ベース以外のクライアントではユーザー クラスがサポートされていないので、各サイト用に構成されたスコープ オプションを使用しなければなりません。

機能するしくみ

次に、IP アドレスと DHCP ホスト構成データを DHCP クライアントに割り当てるときに DHCP がどのように動作するかを、図 2 に示したレイアウトに基づいて順番に紹介します。このシナリオでは、ローカル サイトに設置されている DHCP サーバーを DHCP リースの主要なプロバイダとして使用し、リモート サブネットに設置されているリモート DHCP サーバーを代替サーバーとして使用します。

注意
シナリオ全体には Seville サイトも含まれていますが、次に紹介する動作例では、Milan サイトと Seattle サイトの間の通信だけに焦点を当てて説明します。シナリオに含まれている、すべてのサイトに関する完全な説明は、このシナリオの「実装した方法」で行います。

図 2: DHCP 構成に使用されるハードウェア

1. DHCP クライアントが有効になっている Microsoft® Windows® 2000 Professional ベースのコンピュータが Milan サイトのサブネット 172.16.136.0/22 内で起動されます。このコンピュータの DHCP クライアントが、DHCPDISCOVER メッセージを作成します。このメッセージには、任意の DHCP サーバーに対して IP アドレスの割り当てを求める要求が含まれています (図 3 を参照) 。

   

   図 3: DHCP クライアントによる DHCPDISCOVER メッセージの作成

2. クライアントが、DHCPDISCOVER メッセージをローカル ネットワーク上にブロードキャストします。このとき、クライアントは、ユーザー データグラム プロトコル (UDP) ポート 68 (DHCP クライアント ポート) から UDP ポート 67 (DHCP サーバー ポート) にブロードキャストします。Milan のスイッチで DHCPDISCOVER メッセージを受信すると、次に Milan のルーターに転送します (図 4 を参照) 。

   

   図 4: クライアントによる DHCPDISCOVER メッセージのブロードキャスト

3. Milan の DHCP サーバーでは、次のプロセスに従って DHCPDISCOVER メッセージを受信します (図 5を参照) 。

   1. Milan のルーターが DHCPDISCOVER メッセージを受信します。ルーター内の DHCP リレー エージェントによって、メッセージ ヘッダーの giaddr フィールドに格納されている IP アドレスがそのルーターのアドレスに置き換えられます。

   2. Milan のルーターが、変更後の DHCPDISCOVER メッセージを Milan のスイッチ経由で Milan の DHCP サーバーに転送します。このときには、DHCP リレー エージェントのデータベースで指定されている Milan の DHCP サーバーの IP アドレスが使用されます。Milan の DHCP サーバーでは、UDP ポート 67 上でメッセージを受信します。

   

   図 5: Milan のルーターによる Milan の DHCP サーバーへの DHCPDISCOVER メッセージの転送

4. Seattle の DHCP サーバーでは、次のプロセスに従って DHCPDISCOVER メッセージを受信します (図 6 を参照) 。

   1. Milan のルーターが DHCPDISCOVER メッセージを受信します。ルーター内の DHCP リレー エージェントによって、メッセージ ヘッダーの giaddr フィールドに格納されている IP アドレスがそのルーターのアドレスに置き換えられます。

   2. Milan ルーターが、変更後の DHCPDISCOVER メッセージを、途中に設置されているルーターとスイッチ経由で Seattle の DHCP サーバーに転送します。このときには、DHCP リレー エージェントのデータベースで指定されている Seattle の DHCP サーバーの IP アドレスが使用されます。Seattle の DHCP サーバーでは、UDP ポート 67 上でメッセージを受信します。

   

   図 6: Milan のルーターによる Seattle の DHCP サーバーへの DHCPDISCOVER メッセージの転送

5. Milan と Seattle の DHCP サーバーでは、メッセージ ヘッダーの giaddr フィールドの値を、要求側の DHCP クライアントに IP アドレス リースを割り当てるために使用可能な DHCP スコープに対して比較検査します (図 7 を参照) 。

   

   図 7: DHCP サーバーによる DHCPDISCOVER の giaddr フィールドとスコープの比較

6. 2 つの DHCP サーバーでは、DHCPOFFER メッセージをそれぞれ作成します。このメッセージには、要求側の DHCP クライアントに割り当てられる IP アドレス、サブネット マスク、リース期間、および構成パラメータが含まれています (図 8 を参照) 。

   

   図 8: DHCP サーバーによる DHCPOFFER メッセージの作成

7. Milan の DHCP クライアントでは、次のプロセスに従って Milan の DHCP サーバーから DHCPOFFER メッセージを受信します (図 9 を参照) 。

   1. Milan の DHCP サーバーが、DHCPOFFER メッセージを Milan のスイッチ経由で Milan のルーターに転送します。このときには、元の DHCPDISCOVER メッセージの giaddr フィールドで指定されていた IP アドレスが使用されます。メッセージは、UDP ポート 67 (DHCP サーバー ポート) から UDP ポート 68 (DHCP クライアント ポート) に送信されます。

   2. Milan のルーターが DHCPOFFER メッセージを受信します。次にルーターの DHCP リレー サービスが、DHCPOFFER メッセージを UDP ポート 68 経由でサブネット内のすべてのクライアントにブロードキャストします。

   

   図 9: Milan の DHCP サーバーから DHCP クライアントへの DHCPOFFER メッセージの送信

8. Milan の DHCP クライアントでは、次のプロセスに従って Seattle の DHCP サーバーから DHCPOFFER メッセージを受信します (図 10 を参照) 。

   1. Seattle の DHCP サーバーが、DHCPOFFER メッセージを途中に設置されているルーターとスイッチ経由で Milan のルーターに転送します。このときには、元の DHCPDISCOVER メッセージの giaddr フィールドで指定されていた IP アドレスが使用されます。メッセージは、UDP ポート 67 (DHCP サーバー ポート) から UDP ポート 68 (DHCP クライアント ポート) に送信されます。

   2. Milan のルーターが DHCPOFFER メッセージを受信します。次にルーターの DHCP リレー サービスが、DHCPOFFER メッセージを UDP ポート 68 経由でサブネット内のすべてのクライアントにブロードキャストします。

   

   図 10: Seattle の DHCP サーバーによる DHCPOFFER メッセージの送信

9. DHCP クライアントは、送信されてくるうちで最初の DHCPOFFER メッセージを受信し (この動作例の場合には、Milan の DHCP サーバーからのメッセージ) 、それ以降に送信されてくる DHCPOFFER メッセージをすべて破棄します (図 11 を参照) 。

   

   図 11: DHCP クライアントによる最初の DHCPOFFER メッセージの受信

10. クライアントが、DHCPREQUEST メッセージをブロードキャストします。このメッセージには、受け取った情報を送信してきた DHCP サーバー (この動作例の場合は、Milan の DHCP サーバー) の IP アドレスを含む DHCP サーバーの識別子が含まれています (図 12 を参照) 。

    

    図 12: DHCP クライアントによる DHCPREQUEST メッセージの作成

11. Seattle の DHCP サーバーでは、次のプロセスに従って DHCPREQUEST メッセージを受信します (図 13 を参照) 。

    1. Milan の DHCP クライアントが DHCPREQUEST メッセージをブロードキャストします。

    2. DHCP リレー エージェント対応の Milan のルーターが、ブロードキャストされた DHCPREQUEST メッセージを Milan のスイッチ経由で受信します。

    3. ルーターが、DHCPREQUEST メッセージの giaddr フィールドにそのルーターの IP アドレスを挿入し、次に変更後のメッセージを Seattle の DHCP サーバーに転送します。

    

    図 13: Seattle の DHCP サーバーによる DHCPREQUEST メッセージの受信

12. Seattle の DHCP サーバーでは、Milan の DHCP サーバーの DHCP サーバー識別子を含む DHCPREQUEST メッセージを受信します。その後で、このサーバー自体がリースを割り当てようとしたことを撤回し、そのリースを使用可能な IP アドレスのプールに戻します (図 14 を参照) 。

    

    図 14: Seattle の DHCP サーバーによるリースの割り当ての撤回

13. Milan の DHCP サーバーでは、次のプロセスに従って DHCPREQUEST メッセージを受信します (図 15 を参照) 。

    1. Milan の DHCP クライアントが DHCPREQUEST メッセージをブロードキャストします。

    2. DHCP リレー エージェント対応の Milan のルーターが、ブロードキャストされた DHCPREQUEST メッセージを Milan のスイッチ経由で受信します。

    3. ルーターが、DHCPREQUEST メッセージの giaddr フィールドにそのルーターの IP アドレスを挿入し、次に変更後のメッセージを Milan の DHCP サーバーに転送します。

    

    図 15: Milan の DHCP サーバーによる DHCPREQUEST メッセージの受信

14. Milan の DHCP サーバーは、それ自体が割り当てようとしたリースがクライアントによって受け付けられたので、改めて DHCPACK メッセージを作成します。このメッセージには、DHCP クライアントが必要とする完全な IP 構成が含まれています。つまり、IP アドレス、サブネット マスク、リースの有効期間、スコープ、およびユーザー クラスの構成オプションなどが含まれています (図 16 を参照) 。

    

    図 16: Milan の DHCP サーバーによる DHCPACK メッセージの作成

15. Milan の DHCP サーバーが DHCPACK メッセージを Milan のルーターに転送します。すると、DHCP リレー サービスが DHCPACK メッセージをローカル サブネットにブロードキャストします。DHCP クライアントはその DHCPACK メッセージを受信し、割り当てられた IP 構成をそのネットワーク インターフェイスにバインドします (図 17 を参照) 。

    

    図 17: DHCP クライアントによる DHCPACK メッセージの受信と適用

実装した方法

次に紹介するセットアップ手順は、Microsoft® Windows® 2000 リソース キット導入実験シナリオをセットアップするために実際に使用したものです。また、セットアップの前提となるハードウェア、ソフトウェア、および管理権限も併せて紹介します。

注意
このシナリオにおいてコンピュータおよびデバイスを構成するために使用した手続きはサンプルとして紹介したものです。実際のネットワークでは、類似したコンピュータおよびデバイスを構成する場合でも、必要になる手順はそれぞれのケースで異なります。さらに各シナリオでは、目的とする機能を実現するために必要な手順だけを示しています。運用ネットワークにおいて必要になるその他の手順については取り上げていません。

管理者は、ここに記載したセットアップ手順で必要になる構成を各コンピュータで実行するための適切な権限を持たなければなりません。サンプルにおいて実際に使用したアカウントについては、それぞれのセットアップ手順で説明します。

このセットアップ手順では、以下の構成を仮定しています。

• すべてのコンピュータ、ルーター、およびスイッチに、表 2 に示すように、適切なオペレーティング システムがインストールされています。

• 各コンピュータに適切な名前を付けてあります。

• 各コンピュータで通信を行うために適切なルーティングをセットアップしています。各コンピュータには次の IP アドレスを割り当てます。

注意
これらの IP アドレスは、プライベート ネットワーク用の IP アドレス空間内のアドレスです。これらの IP アドレスは、テスト環境またはファイアウォールの背後のプライベート ネットワーク内で使用できます。インターネットに接続したネットワークでは使用できません。詳細については、RFC 1918 を参照してください。

• すべての Windows 2000 Professional ベースのコンピュータを DHCP クライアントとして構成しています。

• DHCP リレー サービスを表 2 に示した Cisco 製のルーターにインストールしています。

• SEA-NA-DHCP-02 と SEA-NA-DHCP-03 の 2 つのサーバーでは Windows 2000 Advanced Server を実行しています。それぞれのサーバーには、ネットワーク アダプタが 2 つずつ必要です。1 つは公衆ネットワーク用に構成し、もう 1 つはノード間の通信用に構成しておきます。

次の表 2 は、Resource Kit Deployment Lab のこのシナリオで使用したハードウェアとソフトウェアを一覧にしたものです。

表 2 Resource Kit Deployment Lab で DHCP の導入に使用したコンポーネント

注意
このシナリオでは、その目的を考慮して SCSI 記憶装置を使用しましたが、企業への導入に際しては、ファイバ チャネル記憶装置を使用することが推奨されています。

セットアップ手順

このシナリオをセットアップするために、以下の作業を実施しました。

1. Seville のルーター用の DHCP リレーの構成

2. Milan のルーターの構成

3. Milan の DHCP サーバーの構成

4. Seville の DHCP サーバーの構成

5. Seattle のクラスタ ノードの構成

6. クラスタ サービスのインストールと構成

7. Seattle の クラスタ化 DHCP サーバーの構成

8. DHCP スコープのアクティブ化

9. ユーザー固有クラスを使用する Windows 2000 ベースのラップトップ型クライアントの有効化

   

   図 18: このシナリオで使用したハードウェア

その他の参考資料

DHCP および DHCP に関連する話題の詳細については、次の資料を参照してください。

Windows 2000 リソース キット

• TCP/IP の詳細については、『Microsoft Windows 2000 Server リソース キット 6 TCP/IP ガイド』の「第 1 章 TCP/IP 入門」と「第 2 章 Windows 2000 TCP/IP の実装」を参照してください。

• DHCP の詳細については、『Microsoft Windows 2000 Server リソース キット 6 TCP/IP ガイド』の「第 4 章 DHCP (動的ホスト構成プロトコル) 」を参照してください。

ツール

• Ipconfig は、DHCP クライアントまたは DHCP サーバーの TCP/IP 構成設定を表示するコマンドライン ツールです。

  Ipconfig の詳細については、『Microsoft Windows 2000 Server リソース キット 6 TCP/IP ガイド』の「第 3 章 TCP/IPのトラブル シューティング」を参照してください。

Windows 2000 オンライン ドキュメント

• DHCP の詳細については、Windows 2000 Server ヘルプの「ネットワーク」を参照してください。

Requests for Comments (RFC)

• ユーザー クラス オプションの詳細については、RFC Editor Web サイト (英語) の RFC 1542、「Clarifications and Extensions for the Bootstrap Protocol」を参照してください 。

• プライベート IP アドレスの割り当ての詳細については、RFC Editor Web サイト (英語) の RFC 1918、「Address Allocation for Private Internets」を参照してください 。

• DHCP の詳細については、RFC Editor Web サイト (英語) の RFC 2131、「Dynamic Host Configuration Protocol」を参照してください 。

Cisco Network Registrar

Cisco Network Registrar (CNR) は、スケーラブルな名前付けおよびアドレス割り当てサービスを企業およびサービス プロバイダのネットワークに提供するための完全な機能を備えた DNS/DHCP システムです。Cisco Network Registrar の DHCP サーバーがサポートしている機能として、DHCP セーフ・フェールオーバ (冗長性のある DHCP サーバー) 、動的な DNS の更新、DOCSIS ケーブル モデム、および LDAPv3 によるディレクトリ サービスとの統合などがあります。CNR は、Windows 2000 Server または Advanced Server、Windows NT 4.0 (サービス パック 4 または 5) で使用できます。詳細については、次のリンクにアクセスしてください。

• Cisco Network Registrar 製品トップページ

• Cisco Network Registrar 3.5 (英語)

• Cisco Network Registrar 3.5 Datasheet (英語)

導入実験の詳細と協力企業について

• 導入実験、および導入実験に提供されたハードウェアに関する情報については、『導入実験のハードウェア仕様』を参照してください。

リソース キット導入実験シナリオの凡例

• Microsoft Windows 2000 リソース キット導入実験シナリオのネットワーク図で使用されている略語や記号について詳しくは、『導入実験シナリオの凡例』を参照してください。

リソース キット導入実験のネットワーク図

• ネットワークの設計、ネットワーク ルーティング設計、ドメイン ネーム システム (DNS) 設計、および Active Directory 階層の高水準の編成については、『導入実験のネットワーク図』を参照してください。

関連資料

• Windows 2000 Server リソース キット 購入ページ

• Windows 2000 Professional リソース キット 購入ページ

• Windows 2000 リソース キットの詳細については、こちらを参照してください。

注意
このシナリオにおいて、コンピュータおよびデバイスを構成するために使用した手続きは、サンプルとして紹介したものです。実際のネットワークでは、類似したコンピュータおよびデバイスを構成する場合でも、必要になる手順はそれぞれのケースで異なります。さらに各シナリオでは、目的とする機能を実現するために必要な手順だけを示しています。運用ネットワークにおいて必要になる、その他の手順については取り上げていません。すべてのシナリオは、特に表記しない限り Windows 2000 を使用してテストされています。また、ブラウザとして Microsoft Internet Explorer 5 以上を推奨します。