test

TCP/IP とデータ通信

パート IV 動的なホスト構成プロトコル

動的なホスト構成プロトコル (DHCP) を使用すると、ホストはインターネットプロトコル (IP) アドレスおよび他のインターネット構成パラメータを取得することができ、ユーザーによる事前定義の必要がなくなります。この新しいプロトコルは、システム管理者が各 IP アドレスを個別に割り当ておよび変更を行う必要があった、従来のインターネットアーキテクチャを改善します。

DHCP を使用すると、管理者が何度も IP アドレスを割り当てたり、変更したりする必要がなくなるため、ネットワークの管理費用が削減されます。

第 14 章 DHCP の概要

この章では、動的なホスト構成プロトコル (DHCP) を紹介し、クライアント側とサーバー側の両方のプロトコルについて説明します。また、DHCP の動作内で使用できるブートストラッププロトコル (BOOTP) の中継エージェントについても説明します。

DHCP とは何か

DHCP は、インターネットプロトコル (IP) アドレスやその他のインターネット構成パラメータをホストに提供します。DHCP を使用すると、ユーザーが事前に構成を行う必要がなくなります。この新しいプロトコルにより、システム管理者が個々の IP アドレスを個別に割り当てたり変更したりする必要があった、従来のインターネットアーキテクチャが改善されます。手作業による処理には、費用がかかる、難しい、エラーが発生しやすい、時間がかかる、という短所があります。

DHCP は、管理者が何度も IP アドレスを割り当てたり変更したりする必要性をなくすことにより、ネットワークの管理費用を削減します。使用されていない IP アドレスのプールから動的 IP アドレスを選択して、一時使用または永久使用のために自動的にホストに割り当てます。さらに、割り当てた IP アドレスが不要になるまたは使用期限が切れた場合には、DHCP はその他のクライアントに使用させるために当該 IP アドレスを回収します。

DHCP と BOOTP のパケットフォーマットは同じですが、BOOTP パケットは固定長、DHCP パケットは可変長です。DHCP パケットの長さについては、クライアントとサーバーとの間でネゴシエーションが行われます。

インターネット技術タスクフォース (IETF) の動的なホスト構成のための作業グループは、約 5 年間にわたって、現在の IP アドレス割り当てのアーキテクチャが持っている問題について作業を行なってきました。IETF は、DHCP の標準化を行なっている途上です。現状は、複数のコメント要求 (RFC)、すなわち RFC 1542、2131、2132 が出されている状態です。

インターネットが急速に成長しているため、ネットワークアドレスが不足しています。この問題に対処するために、クラスレスドメイン間ルーティング (CIDR) が開発されました。IP アドレスは、大規模、中規模、小規模のネットワークに対応するクラス A、B、C に分けられていました。クラス B の IP アドレスが不足したため、CIDR の設計が使用されることになりました。CIDR は、65,536 個のアドレスから構成されるクラス B ネットワークを 1 つの組織に 1 つ割り当てるのではなく、必要な数だけのクラス C アドレスを割り当てるという考えをベースにしていました。

CIDR 戦略に従って割り当てられたクラス C ネットワーク番号は、ランダムではありません。番号は連続しており、同じ接頭辞を共有しています。このことが、非常に大きいルーティングテーブルを操作することによって引き起こされる問題の大部分を軽減するのに役立ちます。

以前は、IP アドレスのブロックが個別の要求者や企業に割り当てられていましたが、CIDR 戦略の場合は、個別の ISP に割り当てられます。したがって、ISP を簡単に変更するためには、簡単に番号の付け直しができることが重要になります。DHCP では、ネットワークの番号を簡単に付け直すことができ、したがって、ISP を簡単に変更することができます。

DHCP の技術では、以下の便利な機能を使用することができます。

さらに、DHCP は BOOTP をベースとしているため、既存の BOOTP 中継機能を活用することができます。これにより、ネットワーク管理者は、ルーターを設定して BOOTP/DHCP トラフィックをリモート BOOTP/DHCP サーバーへ転送することができます。その結果として、in.rarpd と bootparams による構成サービスの場合には必要であった、ネットワークセグメントごとのネットワークパラメータサーバーは必要なくなりました。

ネットワーク管理者は、このコマンドを使用して、Solaris サーバー上に DHCP サービスと BOOTP サービスを迅速かつ容易に構成することができます。このコマンドは、DHCP サービスを立ち上げて、ローカルネットワークとリモートネットワークを構成します。ローカルネットワークは、サーバーが直接接続されているネットワークです。リモートネットワークは、サーバーが直接には接続されていないネットワークであり、BOOTP 中継エージェントを介してアクセスします。

リモートネットワーク上のクライアントにサービスを提供するには、クライアントのネットワーク上で BOOTP 中継エージェントを設定する必要があります。BOOTP 中継エージェントの機能は、普及している数多くのルーターや交換機内に存在します。ルーターがこの機能をサポートしていない場合は、クライアントのネットワーク上の任意の Solaris マシン上で、in.dhcpd デーモン (in.dhcpd(1M) マニュアルページを参照) を中継エージェントモードで動作させることができます。これは、Solaris 2.6 から利用できるようになった方法です。図 14-1 に、DHCP と BOOTP の概要を示します。

図 14-1 DHCP アーキテクチャ

Graphic

DHCP クライアント

DHCP プロトコルには、クライアントに関連する 2 つの機能があります。1 つは、クライアントがネットワーク通信の終端を確立することができるように、クライアントに対して十分な情報を配信することです。もう 1 つの機能は、システムレベルとアプリケーションレベルのソフトウェアに必要な、その他のパラメータを提供することです。

クライアント情報の配信

最初の機能を実行するにあたり、DHCP プロトコルはクライアントのハードウェアインタフェースに接続されているネットワークに対して有効な IP アドレスを提供します。IP アドレスを使用する権利は設定された期間だけ与えられ、これをリースと呼びます。この点が、従来の静的構成と異なります。クライアントが、元のリースよりも長い期間に渡ってこの IP アドレスを使用したいと希望する場合は、サーバーとの間で DHCP を介してリースの延長についてネゴシエーションを定期的に行う必要があります。クライアントに IP アドレスが不要になった場合、マシンのユーザーはリースを放棄して、使用可能な IP アドレスのプールへ IP アドレスを戻すことができます。ユーザーが戻さない場合、その IP アドレスはリースの期限が切れると自動的に回収されます。

クライアント側の DHCP プロトコルを Solaris 上に実装する場合には、複数の条件を満たす必要があります。サンのワークステーションを起動することは、構成や起動が必要なサービスが多様でかつその数が多いため、複雑なプロセスです。DHCP による解決策はすべて、すでに使用されているその他の方法 (特に、逆アドレス解決プロトコル (RARP) および静的な構成) と併存する必要があります。ワークステーションの起動後、スーパーユーザーがネットワークのアドレスを変更することができることを認識できる必要があります。複数のインタフェースが構成できる必要があります。人間による制御に応答する必要があり、さらにプロトコルの状態についての報告と統計を提供できる必要があります。

Solaris DHCP クライアントは、複数の機能を実装することによってこれらの条件を満たします。最初の起動から数日または数週間後にはリースを更新する必要があるため、DHCP を受け持つエージェントを、クライアント上でデーモンとして動作させる必要があります。このデーモン、すなわち DHCP エージェントあるいは dhcpagent(1M) (dhcpagent(1M) のマニュアルページを参照) は、プロトコルの対話をすべて受け持ちます。デーモンは、サーバーへの接続の際には、DHCP プロトコルの全パケットの送受信を行います。このデーモンは、以下のことを実行します。

エージェントの役割はこれですべてです。クライアントが動作している可能性がある、より上位のレベルについては、このデーモンはまったく関知しません。

開始時点では、エージェントは DHCP がどのインタフェースを構成するかについては何も想定しないで他のエンティティからの命令を待機します。これらの命令は制御プロトコルによってエージェントへ引き渡されますが、さらに、この制御プロトコルによって状態とその他の情報がエージェントからコントローラへ戻されます。ユーザーはこのコントローラによってエージェントの動作を制御することができ、エージェントの動作の制御は、このコントローラによって ifconfig(1M) コマンドの新規機能を介して実現されます。

ifconfig コマンドには、インタフェース上での DHCP の開始や終了を行う、DHCP 専用の新しいコマンド行オプションがあります。DHCP が開始されると、エージェントはプロトコルの命令に応じてサーバーとの間でパケットの送受信を行います。

最も簡単な例として、DHCP によってインタフェースが正常に構成された場合を考えます。エージェントは、リースの存続期間を記録し、インタフェースが構成済みである旨を ifconfig に通知し、受け取った構成をディスクに書き込んで休眠状態になります。

事前に設定された将来のある時点 (通常はリース存続期間を 50% 経過した時点) になると、エージェントは再び休眠状態から覚めて、リースの延長についてネゴシエーションを行います。このネゴシエーションは、ワークステーションが動作している間は何回でも無制限に行うことができます。最後には、システムを停止する時が来ます。その場合は、ifconfig によってエージェントに通知して、リースを放棄することができます。リースを放棄すると、ディスク上に格納されている構成情報はもはや有効でなくなるため削除されます。

エージェントは、数多くの別々のインタフェースを同時に追跡することができますが、それらのインタフェースの更新を同時に行う必要はありません。

上記の例は最も単純な場合ですが、状況がより複雑な場合も考えられます。エージェントが、自己のプロトコルメッセージに対する応答をまったく受け取らない場合もあります。その場合、エージェントはディスクに格納されていた構成を使用することができます。ただし、それが可能なのは、その構成に関連付けられたリースの期限が切れていない場合に限られます。有効な構成が見つからない場合、エージェントは定義済みの再伝送スケジュールを使用して DHCP を再試行を継続することもできますが、インタフェースの構成に失敗することもあります。どちらになるかは、インタフェースが主インタフェースとして指定されているかどうかに依存します。インタフェースが主インタフェースとして指定されている場合、エージェントは DHCP の再試行を継続します。インタフェースが主インタフェースとして指定されていない場合、エージェントは ifconfig コマンドに失敗します。

さらにエージェントは、人間の介入が発生した可能性も考慮する必要があります。エージェントが休眠状態から覚めた際に、IP アドレスとインタフェースの状態が受け取った構成と一致していないことを発見した場合、エージェントはそのインタフェースをアクティブリストからはずします。リースの取得がエージェントに対して再度要求されるまでは、インタフェースに対しては DHCP 操作は何も発生しません。

追加情報の提供

2 番目の機能、すなわちアプリケーションレベルとシステムレベルの情報の配信を実行するにあたり、Solaris DHCP クライアントは別のプログラムの dhcpinfo(1) を使用します。エージェントはこれらのサービスについては何も知らないため、dhcpinfo が取り出すのを待機し、DHCP プロトコルを介して受け取った構成情報をすべて格納します。

dhcpinfo コマンドは、指定されたパラメータを用いてコマンド行の引数を解釈し、当該パラメータの値についてエージェントに問い合わせ、その結果を (人間が読める) テキストの文字列として標準出力に表示します。ただし、dhcpinfo の応答を主に使用するのはユーザーではなく Solaris の起動スクリプトです。シェルコマンドの置換や出力の切り替えの際にこの出力を容易に使用することができるからです。

DHCP が提供するデータは、ホスト全体についてのデータもあれば、インタフェース専用のデータもあります。DHCP が構成可能なインタフェースを 1 つだけ持つクライアントではこの違いは意味がありませんが、数多くのインタフェースをもつホストでは dhcpinfo パラメータに関する解釈の疑問が生じます。たとえば、エージェントが 2 つのインタフェースを構成可能であり、かつこの 2 つのインタフェースに対して戻された NIS+ ドメイン名が異なる場合があります。この状況は、インタフェースを 2 つのカテゴリ、すなわち主インタフェースと二次インタフェースに分けることによって解決することができます。

主インタフェースは、ホスト全体の構成の場合に優先されるインタフェースです。dhcpinfo は、値を尋ねられると主インタフェースに問い合わせます。インタフェース固有のデータの場合も同じように行われます。戻される値は、主インタフェースついて受け取ったデータになります。たとえば dhcpinfo は、IP アドレスを尋ねられると主インタフェースの IP アドレスを標準出力に表示します。ifconfig に対するコマンド行の引数によって、インタフェースを主インタフェースとして指定します。

dhcpinfo コマンドでは、その他のコマンド行オプションによってデフォルトの動作を無効にすることができます。それらのオプションのうちの 1 つを使用すると、インタフェース名を明示的に指定することができます。その場合、戻される値は当該インタフェースに対して DHCP が配信した値になります。

ホスト全体についてのデータの大部分は、Solaris クライアントを正常にブートするために非常に重要なので、1 つのインタフェースを主インタフェースとして指定すると、エージェントがその主インタフェースを構成できない限りシステムがブートできません。dhcpagent が主インタフェースの構成を完了するまで無期限に待機するように、コマンド行の引数によって ifconfig コマンドに命令します。

DHCP サーバー

DHCP サーバーは、そのサーバーに直接接続されているネットワークの IP アドレス空間を管理します。この環境をその他のネットワークに拡張する場合は、DHCP サーバーまたは BOOTP 中継エージェントをそれらのネットワーク上で構成する必要があります。

DHCP サーバーは、主サーバーとしても二次サーバーとしても動作することができます。主サーバーであるためには、一定の範囲の IP アドレスを受け持つ必要があります。

注 -

主という用語は、クライアントとサーバーでは異なる意味で使用されます。

すでに主 DHCP サーバーが存在するネットワークに DHCP サーバーを追加する場合は、新規サーバーを、主サービスと二次サービスを提供するように構成することも、また二次サービスだけを提供するように構成することもできます。新規サーバーを両方のサービス用に構成した場合は、それぞれが異なる IP の範囲を受け持っている限り、両方のサーバーが主サーバーの役割を実行することができます (IP アドレスを配付することができます)。確認を求める要求に 1 つの主サーバーが応答できない場合に、その主サーバーが提供する既存の構成を確認することによって、各サーバーはその他のサーバーの二次サーバーとして動作することができます。各主サーバーは、自動的に 1 つの二次サーバーとして動作します。

DHCP サーバーの IP アドレスの範囲は、そのサーバー上にソフトウェアをインストールして設定する際に指定します。主 DHCP サーバーになると、サーバーは、新規設定を要求するクライアントに対して、自己が受け持つ IP アドレスの範囲から IP アドレスを配付することができます。クライアントが既存の設定の確認を要求した場合は、当該クライアントの IP アドレスを受け持っているサーバーが設定を確認します。二次サーバーとして動作する場合は、ネットワーク上の別の DHCP サーバーが提供した設定を確認することができます。

二次サービスを提供する場合、DHCP サーバーはネットワーク上の別のサーバーが提供した設定を確認します。これを行うのは、IP アドレスを受け持つ主サーバーが応答することができない場合です。待機時間経過後に、主サーバーに代わって二次サーバーが応答します。

DHCP サーバーを二次サーバーとしてのみ構成することもできます。DHCP サーバーを二次サーバーとしてのみ構成したい場合は、dhcpconfig プログラムを使用し、新規設定を要求するクライアントに対して配付する IP アドレスの範囲を持たないサーバーの構成を選択します。この構成では、DHCP サーバーは、データの記憶領域として NIS+ を使用している必要があります。

DHCP サービスは、DHCP が dhcpconfig ユーティリティを用いて動作しているマシン上で有効にして構成することができます。このユーティリティを使用すると、起動オプションの設定、DHCP サービスのデータベースの形式と位置の設定、任意のローカル接続またはリモートネットワークの dhcptab テーブルと dhcp_network テーブルの初期化を行うことができます。

dhcpconfig を起動するとメニューが表示されます。このメニューには、DHCP サービスを構成するオプション、BOOTP 中継エージェントを設定するオプション、DHCP の構成または中継サービスの構成を削除するオプション、終了オプションがあります。管理者がメニューオプションのうちの 1 つを選択すると、必要な情報を収集するための一連の質問が表示されます。次に、dhcpconfig により、選択した機能をオンに設定するための処理が実行されます。

同じネットワーク上の複数の DHCP サーバーは、NIS+ または NFS を介して DHCP データベースを共有すると、より効率的に動作します。共有を行うと、DHCP サーバーが共通のデータストアを介して通信できるために、冗長性が増えて連携するサービス間で負荷が分散されます。

新規 DHCP クライアントがネットワークに追加されると、そのクライアントは、到達範囲内にある使用可能なすべての DHCP サーバーまたは BOOTP サーバー、あるいはその両方を検出する目的でメッセージを送ります。このメッセージを受け取った DHPC サーバーは最初に、割り当て可能な IP アドレスがあるかどうかを検査します。割り当て可能な IP アドレスがある場合、サーバーは、それがまだ使用されていない IP アドレスであるかどうかを確認します。まだ使用されていない IP アドレスがない場合、サーバーは、その IP アドレスとその他の構成情報をクライアントに提供します。IP アドレスが使用中であった場合、サーバーはその IP アドレスを使用不可とマークし、状態を管理者に通知して、別の IP アドレスを選択します。

クライアントは、独自の条件にもとづいて、クライアント自身に提供された 1 つの IP アドレスを選択し、自己の選択を特定するメッセージを送ります。

サーバーのデータベース

DHCP/BOOTP サーバーは、dhcptab データベースと dhcp_network データベースという 2 種類のデータベースを使用します。

dhcptab データベースは、termcap に似た構文を使用して定義されたマクロを格納しています。この構文を使用すると、ネットワーク管理者はクライアントに戻す DHCP 構成パラメータのグループを定義することができます。現在のところ、77 の定義済みパラメータがあります。

DHCP/BOOTP サーバーは、そのサーバーと同じネットワークに接続されているクライアントによって要求された場合には、ホスト名、ネットワークブロードキャスト通信アドレス、ネットワークのサブネットマスク、IP 最大転送ユニット (MTU) のいずれかを戻します。この情報は、dhcptab 内に明示的に設定する必要はありません。dhtadm コマンドによって dhcptab サーバー構成テーブルを管理します。

分散型 dhcptab テーブルを共有する 2 つのサーバーが存在し、かつ 2 つのサーバーが同じ NIS+ ドメイン内にある場合、管理者はそのテーブル内の DHCP パラメータを設定して 2 つのサーバーに相互のバックアップを行わせることができます。ただし、本来の構成として、それぞれが異なる範囲の IP アドレスを受け持つ必要があります。さらに、クライアントが他のネットワーク上のサーバーに到達することを可能にするため、個々のネットワークに BOOTP 中継エージェントが必要な場合もあります。

dhcp_network データベースは、クライアント識別子と IP アドレスとの間のマップを格納しています。このデータベースの名前は、サポート対象のネットワークにちなんで付けられています。dhcp_network データベースは、DHCP/BOOTP サービスを提供するネットワークごとに 1 つ存在します。dhcp_network データベースは、実行時にサーバーによって動的に検出され、問い合わせを受けます。dhcp_network データベースが存在しないネットワークから受け取ったクライアントの要求は無視されます。

dhcp_network データベースは、IP アドレスとその IP アドレスに関連付けられている構成パラメータに対して、DHCP クライアントのクライアント識別子を対応づけます。このデータベースは、実行時に DHCP サーバーによって検出されますが、検出は DHCP 要求が発信されたネットワークの IP ネットワークアドレスとサブネットマスクを使用して dhcp_network データベース名を生成することにより行われます。たとえば、10.0.0.0 ネットワークをサポートする dhcp_network データベースは 10_0_0_0 と呼ばれます。dhcp_network データベースは、NIS+ テーブルまたは ASCII ファイルとして存在が可能です。dhcp_network データベースを管理する場合は、pntadm コマンドを使用します。

in.dhcpd デーモンには、DHCP サーバー (オプションの BOOTP 互換モードを含む) および BOOTP 中継エージェントモードという 2 つの動作モードがあります。

BOOTP 中継エージェント

複数のネットワークと、ネットワークを特定するためのネットマスクの使用によって、TCP/IP をベースとしたネットワークの機能が複雑化しています。たとえば、IP を使用したブロードキャスト通信は、ネットワーク同士を接続するゲートウェイを介して行うことはできません。つまり、あるネットワーク上のクライアントは、その他のネットワーク上のサーバーに対して DHCP 要求または BOOTP 要求の一斉同報通信を行うことができません。BOOTP 中継エージェントがゲートウェイを介してサーバーへ要求を送り、次にサーバーからの応答をクライアントに戻す必要があります。

ルーターに組み込み BOOTP 中継エージェントはないけれども、DHCP サーバーにインストールしたサービスの利点をその他のネットワーク内のクライアントにも利用させたいと希望する場合は、それらのネットワーク上に BOOTP 中継エージェントをインストールすることができます。BOOTP 中継エージェントを使用すると、DHCP サーバーが動作していないネットワークから DHCP サーバーへアクセスすることが可能になります。

in.dhcpd デーモンを BOOTP 中継エージェントとして動作させることができます。BOOTP 中継エージェントモードを指定する場合は、オプションの引数により、中継エージェントが BOOTP 要求を転送する必要がある転送先の DHCP サーバーまたは BOOTP サーバーの IP アドレスまたはホスト名のコンマ区切り形式のリストを指定します。このモードでデーモンを開始すると、DHCP データベースがすべて無視されて、デーモンが BOOTP 中継エージェントとして動作します。

BOOTP 中継エージェントは、UDP ポート 68 での受信を待機し、このポートで受信した BOOTP 要求のパケットをコマンド行に指定された転送先へ転送します。中継エージェントは、ローカルなルーターの情報を持つマシン上であれば動作可能であるため、インターネット用のゲートウェイマシンである必要はありません。

-r IPaddr | hostname ... オプションによって、BOOTP 中継エージェントが使用可能になります。netmasks データベースに正しいエントリを作成して、BOOTP 中継エージェントが役割を果たす対象の DHCP サーバーが、外部の BOOTP/DHCP クライアントのネットワークのサブネットマスクを特定できるようにする必要があります。

BOOTP 中継エージェントをインストールした後で、分散型 DHCP データベースにエントリを追加して、BOOTP 中継エージェントを介して要求を送信するクライアントに DHCP サーバーがサービスを提供できるようにする必要があります。

pntadm コマンドのマクロオプション (-M) は、特定の IP アドレスを使用して、クライアントに返す構成パラメータを、ネットワーク管理者が選択できるようにします。このマクロオプションは、サーバーに固有な情報を含むマクロを配信する場合にも使用することができます。この場合は、当該マクロ定義を特定のサーバーが所有するすべての dhcp_network データベースのエントリに含めます。

リース

DHCP/BOOTP サーバーは、dhcptab データベースと dhcp_network データベースに格納されている情報を使用して、クライアントの IP アドレスのリースを計算します。サーバーが調べるのは、dhcptab データベース内の LeaseTim シンボルと LeaseNeg シンボル、選択された dhcp_network データベースレコードの Flags フィールドと Lease フィールドです。

サーバーは最初に、特定された dhcp_network レコードの Flags フィールドを調べます。PERMANENT フラグまたは BOOTP フラグがオンの場合、クライアントのリースは永久的であるとみなされます。

PERMANENT フラグがオンではない場合、サーバーは dhcp_network レコード内の Lease フィールドに表示されているクライアントのリースが期限切れになっているかどうかを検査します。期限切れになっていない場合、サーバーはクライアントが新規リースを要求しているのかどうかを検査します。クライアントの dhcptab パラメータ内に LeaseNeg シンボルが含まれていない場合、クライアントが要求しているリースの延長は無視され、リースは Lease フィールド内に表示されている残り時間に設定されます。

LeaseNeg シンボルが含まれていて、かつ要求されたリースが、現在時刻にクライアントの LeaseTim dhcptab パラメータの値を加えた値以下である場合、サーバーはクライアントのリースをクライアントが要求した値まで延長します。クライアントが要求したリースがポリシーにより許容される値 (ポリシーは LeaseTim の値) より大きい場合は、現在時刻に LeaseTim の値を加えた値に等しいリースがクライアントに与えられます。LeaseTim が設定されていない場合は、デフォルトで LeaseTim の値が 1 時間となります。

第 15 章 DHCP への移行

この章では、DHCP、BOOTP、RARP の各プロトコル間の違いについて説明します。また DHCP の利点と DHCP へ移行する方法についても説明します。

DHCP へ移行する理由

BOOTP または RARP を使用していたユーザーの中には、DHCP との違いや DHCP の利点について疑問に思われる方がいらっしゃるかもしれません。DHCP とそれ以前のプロトコルとの間の主要な違いは、DHCP 以前のプロトコルでは、ホスト情報をサーバーのデータベース内に手動で構成するように設計されていましたが、DHCP では新しく接続されたホストに IP アドレスと構成を動的に割り当てることが可能になりました。

さらに、DHCP のリースのメカニズムにより、IP アドレスの自動的な回収と再割り当ても可能になりました。DHCP は BOOTP のスーパーセットであり、より高度の柔軟性を提供します。DHCP は BOOTP をベースにしており、いくつか機能が追加されていますが、同じプロトコルパケット形式とメカニズムを使用します。DHCP では、ルーターに組み込み済みの BOOTP 中継エージェントの機能を利用することができ、BOOTP クライアントを直接サポートすることができます。

RARP ではマシンが自己の IP アドレスを見つけ出しますが、DHCP または BOOTP では IP アドレスはクライアントシステムに引き渡されるプロトコルパラメータの 1 つです。RARP の欠点は、その他のパラメータがサポートされていないこと、および RARP を提供するサーバーが、直接に接続されたネットワーク以外にはサービスを提供できないことです。

DHCP と BOOTP のトラフィックは、一般的なルーターに組み込まれている BOOTP 中継エージェントの機能を利用することができます。つまり、ネットワーク管理者は、ネットワークセグメントごとに BOOTP サービスを配置する必要はありません。

手動で設定した IP アドレスをサポートしようとすると、管理者は以下のような複数の困難に直面します。

DHCP の利点

DHCP サーバーには、これまでの IP アドレスを取得する方法に比べて、優れた点があります。DHCP サーバーが提供できる機能を以下に示します。

  1. IP アドレスの重複問題の防止を含む、IP アドレスの自動管理。

  2. BOOTP クライアントのサポートが可能、これによりネットワークを BOOTP から DHCP へ容易に移行することが可能。

  3. 管理者がリース時間を設定することが可能であり、手動で割り当てた IP アドレスに対しても設定することが可能。

  4. 動的な IP アドレスを用いてサービスを提供する対象の MAC アドレスを制限することが可能。

  5. 管理者が、BOOTP の場合に可能である範囲を超えた、追加の DHCP オプションの種類を構成することが可能。

  6. 動的に割り当てることができる IP アドレスのプール (複数可) を定義することが可能。ユーザーのサーバーで、プールが 1 つのサブネットまたはネットワーク全体になるよう強制するものがありますが、1 つのプールが連続した IP アドレスから構成されることを強制するサーバーは望ましくありません。

  7. 別個の IP ネットワーク (またはサブネット) に対する、複数の動的な IP アドレスのプールを関連付けることが可能。この関連付けは、二次ネットワークに対する基本サポートであり、複数の IP ネットワークアドレスまたはサブネット IP アドレスを持つインタフェースの BOOTP 中継としてルーターが動作することを可能にします。

DHCP サーバーの機能の一部ではありませんが、DHCP サーバーを管理する方法に関連したいくつかの機能を以下に示します。

  1. 複数のサーバーの集中管理

  2. サーバーが動作中で、かつリースが追跡されている状態でも、変更を行う能力。たとえば、IP アドレスをプールに追加したりプールから削除すること、またはパラメータを変更することができます。

  3. パラメータに対して広域的変更 (すべてのエントリに対して適用される変更) を行うか、あるいはクライアントまたはプールのグループに対して変更を行う能力

  4. リースの監査トレール (たとえば、貸し出し中のリースのログ) の保守

DHCP は、IP アドレスを割り当てる 4 つの方法をサポートします。これらの方法は独立した機能です。特定の 1 つのサーバーに注目すると、そのサーバーはすべての機能を提供できるか、あるいは 1 つも提供できないかのいずれかです。

移行

DHCP は BOOTP と BOOTP のパケット構造をベースにしているため、大部分のサイトでは DHCP への移行を容易に行うことができます。数多くの DHCP サーバーが、以前の BOOTP クライアントと新しい DHCP クライアントの両方をサポートします。

Solaris DHCP サーバーは、DHCP 照会だけでなく BOOTP 照会も処理するため、BOOTP クライアントは DHCP サーバーからブートすることができます。DHCP クライアントに BOOTP サーバーからの応答を使用するように書き込まれている場合、DHCP クライアントは BOOTP サーバーからブートすることができます。Windows 95 を用いて組み込まれた TCP/IP スタックには、この機能はありません。

サブネット

DHCP クライアントのメッセージは、通常 IP ルーターの機能である BOOTP 中継エージェントによってリモートサーバーへ送信されます。BOOTP 中継エージェントを介して、DHCP サーバーは要求元のサブネットを見分けることができます。BOOTP 中継エージェントは、メッセージの発信元のサブネットを DHCP のメッセージヘッダーに記録します。つまり、DHCP サーバーはその記録を使用して、クライアントが存在するネットワークを判定することができます。

BOOTP サーバーと DHCP サーバーを同じマシン上で動作させることはできません。その理由は、両方のサーバーが同じポート番号を使用するためです。BOOTP 互換モードをオンに設定すると、Solaris DHCP サーバーを BOOTP クライアントとして機能させることができます。

DHCP プロトコルを用いると、すでにリースされた IP アドレスまたは永久 IP アドレスを保持しているクライアントが、別のサブネット上の別の一時リースを取得することができます。この取得は、別の位置へ移動する必要があるマシンにとって役立ちます。このオプションは、サーバーが当該機能をサポートしている場合に使用可能です。

ルーター

DHCP には不揮発性の記憶領域が必要です。このため、DHCP サービスのタスクはサーバーとは互換性が保たれますが、専用のルーターとは互換性がなくなります。中継用と DHCP 用の両方に構成可能な、サーバーの種類がいくつかあります。たとえば、Web サーバー、ファイアウォールなどの用途で使用できるように設計されたオールインワンのインターネットゲートウェイがあります。ただし、専用のルーターは存在しません。

DHCP の RFC では、DHCP はルーターの構成に使用することを目的としていない旨が明記されています。ルーターの保守および障害追跡においては、構成が自動に設定されるがままにしておくのではなく、正確な構成を把握しておくこと、およびルーターの動作を別のサーバーの動作に依存させないことが重要だからです。

汎用性がより強い特定の種類のコンピュータまたはサーバーを構成して、それらの IP アドレスを DHCP から取得し、ルーターとして動作させることが可能な場合があります。さらに、厳密にはルーターではありませんが、自己のクライアントに与える IP アドレスを DHCP を使用して取得するリモートアクセスサーバーも存在します。

第 16 章 DHCP の管理

この章では、DHCP を管理する方法、すなわち DHCP を実行するネットワークを設定する方法、リース時間ポリシーを決定する方法、BOOTP 中継エージェントを追加する方法について説明します。また、DHCP が使用するデータベースの種類と、特定のデータベース内でマクロを作成する方法についても説明します。さらに、DHCP に実装されたオプション、DHCP に追加可能なオプションについても説明します。

情報を収集してから DHCP のサービスを設定

DHCP を実行するネットワークを設定する場合は、まず既存のネットワークについての情報を収集する必要があります。必要な情報は、ネットワークトポロジについての情報 (ルーター、スイッチ、その他のネットワークなど) とサービスについての情報 (ネームサービス、ファイルおよび出力サービスなど) です。

リモートネットワーク上のクライアント (すなわち、DHCP サービスを配置する予定のネットワークとは別のネットワーク上のクライアント) をサポートすることを予定している場合は、リモートネットワークのサブネットマスクも収集する必要があります (ただし、リモートネットワークがサブネット化されている場合)。DHCP サービスが使用する netmasks テーブルが、この情報を用いて変更済みであることを確認してください。さらに、リモートネットワーク上のルーターの IP アドレスを収集するか、またはルーター検出機能を使用するようにリモートネットワーク上のクライアントを構成する必要があります。

必要な情報をすべて取得したら、ネットワーク内を移動するデータを NIS+ とファイルのどちらに格納するかを決める必要があります。複数サービス環境または事業用の場合は、NIS+ が適しています。単一サーバーまたは小規模な環境の場合は、ファイルが適しています。情報の収集が終了したら、dhcpconfig(1M) を実行してリモートネットワークを構成します。

DHCP データ用のデータストアの選択

DHCP ネームサービスの設定では、テーブルを格納する際とホスト情報にアクセスする際に DHCP サーバーが使用するデータストア資源を決定します。dhcpconfig スクリプトは、/etc/default/dhcp ファイル内に DHCP サービスを設定します。実行時デーモンと管理ユーティリティはこのファイルを使用して、処理の際の問い合わせ先のネームサービスを決定します。

データストアのサービスを選択する方法

まず最初に、dhcpconfig コマンドにより、サーバーが現在使用しているのが NIS+ とファイルのどちらであるのかを判定します。システムが NIS+ を使用中である場合は、nisplus が Enter data store プロンプトにおけるデフォルト値です。システムがファイルを使用中である場合は files がデフォルト値です。

NIS+ を選択して、サーバーが NIS + を実行していない場合は、警告メッセージと NIS+ の設定方法が表示されます。dhcpconfig スクリプトの処理が継続します (ただし、次に DHCP テーブルを作成する際におそらくエラーが発生します)。

複数のサーバーを持つ環境、または事業用の環境の場合は、NIS+ を使用する必要があります。NIS+ を使用すれば、データをサーバー間で共有することができます。単一サーバーのみの場合は、NFS を使用してデータの共有を行う場合を除いて、ファイルを使用することができます。

初期 DHCP テーブルの作成

dhcpconfig スクリプトにより、表 16-1 に示すように、選択したデータストア内に以下の空 DHCP テーブルを作成します。

表 16-1 dhcpconfig スクリプトにより作成するテーブル

dhcptab

DHCP 構成情報テーブル 

dhcp_network

DHCP クライアントのマップテーブル、DHCP サーバーのあるネットワークごとに 1 つ 

DHCP テーブル

DHCP は、2 種類のデータベース、すなわちネットワークテーブルと dhcptab 構成マクロテーブルとを使用します。これらのデータベースは、NIS+ を使用している場合は NIS+ テーブルであり、NIS+ を使用していない場合はファイルです。

DHCP ネットワークテーブル

DHCP ネットワークテーブルは、IP アドレスの割り当てに関連する情報を格納しています。ネットワークごとに別個のネットワークテーブルがあります。DHCP において dhcp_network テーブルと呼ばれるテーブルの名前は、サービスを提供しているネットワークの IP アドレスから派生しています。たとえば、ネットワーク 120.146.5.0 のネットワークテーブルは、IP アドレス指定の中のピリオドを下線に置換して 120_146_5_0 となります。

DHCP 内の各サブネットには、サブネット内のクライアントのエントリを格納している dhcp_network テーブルがあります。ブートしたクライアントからのパラメータを求める要求に DHCP サーバーが応答すると、そのクライアントの dhcp_network エントリとして情報が記録されます。このテーブルには、クライアントの IP アドレスと、dhcptab テーブルへのポインタとが含まれています。

ネットワークテーブルは、以下の固有情報を格納しています。

ネットワークテーブルは、特定のネットワークに対して DHCP サーバーが割り当てることができる IP アドレスのリストとして機能します。各ネットワークには独自のネットワークテーブルがあります。ネットワークテーブルの基本要素は IP アドレスのリストです。テーブル内のその他の要素は、すべて IP アドレスとの関係において意味を持ちます。たとえば、クライアント ID は特定の IP アドレスが現在割り当てられているクライアントを特定します。IP アドレスが未割り当てである場合、その IP アドレスのクライアント ID は 0 です。有効期限も 0 です。IP アドレスが割り当て済みである場合は、クライアント ID とリースの有効期限が記入されています。

特定の実装状態では、クライアント ID はネットワークの種類を表す接頭辞を付けてクライアントマシンのハードウェアアドレスになります。たとえば、イ−サネットアドレスを持つクライアントのクライアント ID が 0102608BA614C1 である場合は、01 によりクライアントがイ−サネットネットワークであることが示されます。DHCP の実装状態によっては、その他の識別子 (DNS 名やプロパティ番号など) を使用する場合があります。重要なことは、クライアント ID はネットワーク内で一意である必要があることです。

IP アドレスが割り当て済みの場合、その IP アドレスのリースの有効期限は特定の日付と時刻に設定されるか、または "No Expiration" とマークされます。

lease フラグと dhcptab 構成マクロの名前は、IP アドレスがクライアントに割り当てられているかどうかにかかわらず同じです。クライアントが特定の IP アドレスを取得すると、lease フラグにより指定されたリースの種類と、プロパティ名により指定された構成も取得します。lease フラグは、IP アドレスを割り当てることができる条件を表示します。pntadm コマンドにより、dhcp_network テーブルを管理することができます。例 16-1 に pntadm の出力例を示します。

例 16-1 pntadm -P 129.146.86.0 の出力例

Client ID       Flags  Client IP        Server IP       Lease         Macro     Comment
                                                        Explanation

010800207CBA2C   04    129.146.86.153   129.146.86.181   Zero         mrcoffee
0108002022519C   00    129.146.86.205   129.146.86.181   7/3/1996     inet11
01080011043B65   08    129.146.86.29    129.146.86.181   Zero         inet11
0100A024A9BCEE   08    129.146.86.198   129.146.86.181   7/22/1996    inet11 	
0100A024A791DE   00    129.146.86.200   129.146.86.181   8/4/1996     inet11 
0100A02463D6EC   00    129.146.86.199   129.146.86.181   8/1/1996     inet11 
0100A024636AB7   00    129.146.86.201   129.146.86.181   8/3/1996     inet11 
010080C72EE4A3   00    129.146.86.206   129.146.86.181   7/5/1996     inet11 
010020AF4A3B31   0     129.146.86.214   129.146.86.181   Zero         hobbs
00               00    129.146.86.202   129.146.86.181   Zero         inet11

dhcptab 構成テーブル

dhcptab テーブルは、クライアントの構成に関連する情報を格納しています。このテーブルは、ネットワーククライアントを構成するのに必要な全情報を格納する、一連のマクロ定義として編成されます。クライアントは、ネットワークテーブルから IP アドレスを割り当てられる際に構成を取得します。IP アドレスに関連付けられたマクロ名は、dhcptab テーブル内のマクロ名に対応します。クライアントは、ネットワークテーブルから IP アドレスを取得した後に、dhcptab テーブルからネットワーク構成を取得します。

DHCP サーバーの初期構成の際に、構成済みネットワークごとに dhcptab テーブルとマクロが作成されます。各マクロには、ネットワークに固有の情報、すなわちサブネットマスク、ネットワークブロードキャスト通信アドレス、IP パケット生存時間、データグラムの最大サイズ、デフォルトのルーター、静的送信経路、DNS ドメイン、NIS ドメイン、DNS サーバー、NIS サーバーのうち、サーバーの構成時に使用可能なものが格納されます。

マクロ内に格納されている情報を変更することによって、クライアントマシンがネットワークを利用する方法を制御することができます。たとえば、特定のクライアントマシンが使用するマクロの名前を変更すると、そのマシンのネットワーク構成が変更されます。別の例としては、あるマクロ内の 1 つのオプションを変更することにより、そのマクロセットを使用する全マシンの動作が変更されます。IP アドレスを管理する能力は、DHCP の主要機能の 1 つです。dhtadm コマンドにより、dhcptab サーバー構成テーブルを管理します。例 16-2 にdhtadm の出力例を示します。

例 16-2 dhtadm -P の出力例

Name          Type    Value

mrcoffee      Macro   :Subnet=255.255.255.0:Router=129.146.86.1:Broadcst=129.146.86.255: ¥
                      :BootSrvA=129.146.86.175:BootFile="/export/root/JavaDesktop/kona": ¥
                      :NISservs=129.146.86.33:NISdmain=sunsoft.eng.sun.com: ¥
                      :DNSdmain=Eng.Sun.COM: ¥
                      :DNSserv=129.146.1.151 129.146.1.152 129.144.1.57 129.144.134.19: ¥ 
                      :Include=Locale: ¥
                      :Timeserv=129.144.1.3:LeaseTim=3600:T1Time=1800: ¥
                      :T2Time=3060:	

Locale        Macro   :UTCoffst=25200:SN_TZ="PST8PDT":

inet11        Macro   :Include=Locale:Timeserv=129.146.86.181:LeaseTim=259200: ¥
                      :DNSdmain=Eng.Sun.COM: ¥
                      :DNSserv=129.146.1.151 129.146.1.152 129.144.1.57 129.144.134.19:

hobbs         Macro   :Subnet=255.255.255.0:Router=129.146.86.1:Broadcst=129.146.86.255: ¥
                      :BootSrvA=129.146.86.32:BootFile="819256D6.PREP":

129.146.89.0  Macro   :Subnet=255.255.255.0:Router=129.146.89.1:Broadcst=129.146.89.255: ¥
                      :NISdmain=sunsoft.eng.sun.com:NISservs=129.146.89.33: ¥
                      :NetBNms=129.146.171.31:NetBNdT=8:

129.146.88.0  Macro   :Subnet=255.255.255.0:Router=129.146.88.1:Broadcst=129.146.88.255: ¥
                      :NISdmain=sunsoft.eng.sun.com:NISservs=129.146.88.33: ¥
                      :NetBNms=129.146.171.31:NetBNdT=8:

129.146.87.0  Macro   :Subnet=255.255.255.0:Router=129.146.87.1:Broadcst=129.146.87.255: ¥
                      :NISdmain=sunsoft.eng.sun.com:NISservs=129.146.87.33: 
                      :NetBNms=129.146.171.31:NetBNdT=8:	

129.146.86.0  Macro   :Broadcst=129.146.86.255:Subnet=255.255.255.0:MTU=1500: ¥
                      :Router=129.146.86.1:NISdmain=sunsoft.eng.sun.com: ¥
                      :NISservs=129.146.86.33:NetBNms=129.146.171.31:NetBNdT=8: ¥
                      :BootSrvA=129.146.86.32:

129.146.85.0  Macro   :Subnet=255.255.255.0:Router=129.146.85.1:Broadcst=129.146.85.255: ¥
                      :NISdmain=sunsoft.eng.sun.com:NISservs=129.146.85.33: ¥
                      :NetBNms=129.146.171.31:NetBNdT=8:

129.146.84.0  Macro   :Subnet=255.255.255.0:Router=129.146.84.1:Broadcst=129.146.84.255: ¥
                      :NISdmain=sunsoft.eng.sun.com:NISservs=129.146.84.33: ¥
                      :NetBNms=129.146.171.31:NetBNdT=8:

129.146.83.0  Macro   :Subnet=255.255.255.0:Router=129.146.83.1:Broadcst=129.146.83.255: ¥
                      :NISdmain=sunsoft.eng.sun.com: ¥
                      :NISservs=129.146.83.33:NetBNms=129.146.171.31:NetBNdT=8:

129.146.82.0  Macro   :Subnet=255.255.255.0:Router=129.146.82.1:Broadcst=129.146.82.255: ¥
                      :NISdmain=sunsoft.eng.sun.com:NISservs=129.146.82.33: ¥
                      :NetBNms=129.146.171.31:NetBNdT=8:

129.146.81.0  Macro   :Subnet=255.255.255.0:Router=129.146.81.1:Broadcst=129.146.81.255: ¥
                      :NISdmain=sunsoft.eng.sun.com:NISservs=129.146.81.33: ¥
                      :NetBNms=129.146.171.31:NetBNdT=8:

SN_TZ         Symbol  Vendor=SUNW,13,ASCII,1,0

DHCP の各サブネットの構成

この節では、dhcpconfig を使用し、各サブネットについての以下の 3 つの質問に対する答えをもとにして、サブネットを構成する方法について説明します。

DHCP の各サブネットを構成する方法

dhcpconfig スクリプトにより、サーバーシステム上に構成するサブネットごとに、dhcp_network テーブルと呼ばれるテーブルを作成します。テーブル名は IP アドレスと同じですが、小数点は下線に置換されます。たとえば、サブネット 129.148.5.0 の dhcp_network テーブルは、DHCP が使用しているネームサービス内では 129_148_5_0 です。これは、NIS+ の場合は org_dir オブジェクト内のテーブルであり、ファイルの場合は /var/dhcp ディレクトリ内のファイルです。

DHCP が管理しているクライアントシステムごとに、dhcp_network テーブル (クライアントマシンが接続されているサブネットに対応するテーブル) 内にエントリが 1 つあります。エントリが永久である場合もありますが、この場合は IP アドレスが永久的にマシンに割り当てられています。あるいはエントリが動的である場合もありますが、この場合はクライアントが最初に構成される際に DHCP サーバーが IP アドレスを割り当てて、さらに IP アドレスを使用できる時間の長さを指定したリースを与えます。この段階で設定するのは、これらの動的クライアントです。永久クライアントは、DHCP の環境をすべて構成した後で、pntadm を用いて設定することができます。

DHCP サービスデーモンの開始

この節では、dhcpconfig スクリプトが実行する、以下の 3 つの機能について説明します。

start/stop スクリプトの名前は dhcp であり、リンクは S34dhcp (デーモンを開始する場合) と K34dhcp (デーモンを停止する場合) です。このスクリプトは、デーモンプロセス実行用の標準 SVR4 手続きをブート時に実行します。

デーモンプロセス in.dhcpd を開始します。in.dhcpd デーモンは DHCP サーバープロセスであり、クライアントの要求に応答して、dhcptab テーブル内に確立済みのネットワーク構成を転送します。

リース時間ポリシー

DHCP は IP アドレスを動的に割り当てるメカニズムを提供します。IP アドレスにはリース期間が伴っており、永久または一時に設定することができます。ユーザーサイトのポリシーとして、一時 IP アドレスと永久 IP アドレスの数を決定し、さらに一時 IP アドレスのリース期間を決定する必要があります。

DHCP サービスを最大限利用するには、DHCP に IP アドレスの割り当てを動的に管理させることが最善です。DHCP を用いた場合には、クライアントとサーバーが特定の期間に渡る IP アドレス設定の貸し出し (リース時間と呼ぶ) についてネゴシエーションを行います。dhcptab 内の特定のマクロ定義の LeaseTim シンボルと LeaseNeg シンボルを使用することによって、サーバー、ネットワーク、クライアントのベンダークラス、個別のクライアント IP アドレスのいずれかをベースにしてリース時間ポリシーを設定することができます。

LeaseNeg シンボルと LeaseTim シンボルを使用すると、ユーザーサイトのポリシーを設定することができます。LeaseTim は相対的な時間であり、24時間、2 時間、または 10 時間などとなります。クライアントに IP アドレスが割り当てられると (または、すでに割り当てられている IP アドレスのリースについて再度ネゴシエーションを行うと)、クライアントが DHCP の回答を受け取った絶対時間に LeaseTim の値が追加されます。絶対時間は現在時刻であり、たとえば 1996 年 9 月 27 日です。絶対的な現在時刻に LeaseTim の値を加算した時刻は、IP アドレスについてのクライアントのリースが期限切れとなる絶対時間として、クライアントの dhcp_network レコード内に格納されます。

LeaseTim シンボルの設定は、クライアントに対して許可することができる、リースの最大時間間隔を定義します。一般的にはこの値を相対的に小さな値にしておく必要がありますが、その理由は、クライアントとサーバーの同期を維持するため、使用されていない IP アドレスを遅滞なく回収するため、さらにネットワークの再番号付けをより円滑に行うためです。

ただし、DHCP サーバーが使用不可能になった場合に DHCP サービスを実行しているマシン (複数可) が修復されるまでの間、クライアントが機能を継続することができる程度には大きい値である必要があります。1 〜 3 日が最善の LeaseTim ポリシーとなります。所定の環境において適切に動作する値を選択してください。

LeaseNeg シンボルは、リースの期限が切れる前にクライアントがサーバーとリースについて再度ネゴシエーションを行うことを可能とするかどうかを決定します。このシンボルが存在する場合、クライアントはリースについて再度ネゴシエーションを行うことができます。LeaseNeg が存在する場合、クライアントは既存の接続に対してリース関連の割り込みを行わないでネットワーク上で動作することができます。

IP アドレスよりマシンの方が数が多く、したがって IP アドレスの使用に時間制限を実施したい環境では、LeaseNeg を省略する方が実用的です。このような場合の例として、コンピュータサイエンスの教室内のマシンに対して時間制限を実施する場合があります。LeaseTim と同様に、LeaseNeg を dhcptab の各種マクロ内で使用することができます。詳細は、dhcptab(4) および dhcp_network(4) を参照してください。

サービス (たとえば、メールや Web ページ) をエクスポートするマシンは IP アドレスを保持する必要がありますが、当該ノードが使用する IP アドレスがもはや使用されていない場合に (おそらくは廃棄された場合に)、その事実を検出可能であることを希望する場合もあります。この希望は、手動で割り当てられた旨を (必要に応じて割り当て者も) 当該ノードの dhcp_network レコードにマークし、そのノードのフラグフィールドを MANUAL に設定することによって実現することができます。たとえば、ホスト名が gandalf でネットワークが 10.50.0.0 である場合は、pntadm gandalf -f MANUAL 10.50.0.0 と入力します。

永久リースで IP アドレスを割り当てることもできますが、DHCP サービスを使用して自動的に IP アドレスを回収することはできません。したがって、永久 IP アドレスの数は最小限の管理可能な数に抑えてください。

DHCP サービスは、このフラグフィールドを使用して、dhcp_network レコードエントリの期限が切れて回収可能となる時点を判定します。この値は、pntadm コマンドの e オプションを使用することによって変更できます。このコマンドを使用すると、クライアントのリースの有効期限を過去の時間に設定することができますが、クライアントとそのクライアントのユーザー (複数可) に悪影響を及ぼすことを避けるために、未来の時間にのみ設定してください。

DHCP サービスが動的に IP アドレスを割り当てるか、または既存の有効期限について再度ネゴシエーションを行うたびに、dhcp_network テーブル内のこのフィールドが更新されます。

lease フラグは IP アドレスを割り当てる条件を表します。フラグの設定は、以下を結合したものになります。

0 (Dynamic)

IP アドレスのこのリースには有効期限があります。リースが期限切れとなった場合は、更新が可能である旨がサイトのポリシーに指示してあれば更新することができます。現在のクライアントがリースを更新しない場合、その IP アドレスは別のクライアントに割り当てることができます。フラグが 0 に設定されている場合は、リース時間を変更することができます。

1 (Permanent)

この IP アドレスのリースは永久的に割り当てられており、クライアントがリース時間を変更することはできません。ただし、IP アドレスを使用しているクライアントがその IP アドレスの割り当てを解除することは可能です。割り当て解除された IP アドレスは、別のクライアントに割り当てることができます。

2 (Manual)

この IP アドレスは特定のクライアントのマシンに割り当てられます。クライアントが割り当てを解除することはできません。フラグが 2 に設定されている限り、その IP アドレスを再度割り当てることができるのは、管理者が手動で変更した場合だけです。

4 (Unusable)

この IP アドレスは使用できません。フラグを 4 に設定することにより、IP アドレスの割り当てを防止することができます。DHCP サーバーは、IP アドレスの配置を試行してそれがすでに使用中であることがわかった場合に、その IP アドレスを使用不可とマークします。DHCP サーバーは、IP アドレスを割り当てる前に、通常は ping コマンドを用いてすでに使用中であるかどうかを確認します。この設定は、dhcpconfig 内に構成可能です。

フラグが設定の結合であることがあります。たとえば、フラグが 3 に設定されている場合は、1 と 2 を結合したものです。つまり、この設定は永久かつ手動という設定であり、この IP アドレスのリースは永久リースで、かつ管理者が割り当てたリースになります。

BOOTP 中継エージェントの設定

最初に、組み込み中継エージェントがルーター (単数の場合も複数の場合もあります) にあるかどうかを判定します。組み込み中継エージェントがルーターにある場合は、マニュアルを読んで中継エージェントの使用法を理解してください。組み込み中継エージェントがルーターにない場合は、クライアントネットワーク上にある、中継エージェントとして機能させる Solaris マシンを選択します。マシンに SUNWdhcsr と SUNWdhcsu をインストールしてから、dhcpconfig を実行して Configure BOOTP relay agent を選択します。

希望の BOOTP/DHCP 要求送信先の BOOTP/DHCP サーバーの IP アドレス、またはホスト名を入力します。

標準 DHCP オプション

Solaris DHCP サーバーでは、標準 DHCP オプションがすべて導入されます。これらのオプションには、以下のネットワーク情報が含まれています。

ベンダーオプション

ベンダーオプションは、DHCP クライアントソフトウェアのベンダーが定義する DHCP オプションです。クライアントは、構成を求める要求を送る際にベンダーのクライアントクラスを組み込みます。dhcptab データベース内にこのクライアントクラスと一致するクライアントクラスがある場合には、そのクラスに対して指定されているオプションとその他の構成オプションがクライアントに送信されます。Solaris DHCP サーバーを構成して、任意の DHCP クライアントベンダーのオプションをサポートすることができます。

ベンダーオプションとサイトオプションの追加

追加のベンダーオプションまたはサイトオプションを作成するには、以下を定義する必要があります。

サイトオプションはサイトに固有であるため、必要な任意のオプションを作成できますが、ベンダーオプションの場合は、特定のクライアントベンダーに対して必要なオプションだけ作成できます。オプションは定義済みのものもありますが、作成する必要があるものもあります。作成する場合には、特定のベンダーに適用するベンダーオプションのリストをサーバー上に作成することが必要な場合があります。リストの例はクライアントのベンダーが提供します。

マクロ定義の作成

dhcptab テーブルのマクロを作成する場合は、関連する標準オプション、ベンダーオプション、サイトオプションをすべて指定する必要があります。使用可能なオプションをすべて指定する必要はありません。指定する数は、ネットワークの構成に応じて異なります。

IP アドレスのリース

IP アドレスのリースは、デフォルトでは一時として割り当てられます。一時リースは、ユーザーとユーザーのマシンが頻繁にサブネットを変更する場合、またはシステムへの出入りが激しい場合に便利です。

サイトごとに、当該サイトでの一時リースを更新可能とするかどうかを指定することができます。このサイトのポリシーは、LeaseNeg シンボルを用いてプロパティテーブル内に設定することができます。このシンボルを省略した場合は、リースが期限切れとなった際にクライアントがリースについて再度ネゴシエーションを行うことはできません。IP アドレスが期限切れとなった際にクライアントがその IP アドレスを更新しない場合、その IP アドレスは再使用することができます。

カスタマイズ例

ネットワーク 126.147.100.0 の NIS サーバーの値を変更する場合は、以下のようにします。

  1. マクロ 129.147.100.0 を以下のように編集します。


    dhtadm -M -m 129.147.100.0 -e `NISserv = 129.147.100.1 129.147.100.2'

  2. 以下のように入力します。


    /etc/init.d/dhcp stop

  3. 以下のように入力します。


    /etc/init.d/dhcp start

    あるいは、2 と 3 の代わりに、in.dhcpd に対して -t オプションを使用します。

    10-15 のアドレスを 129.147.100.0 へ追加するには、以下のようにします。


    for addr in 10 11 12 13 14 15  
do  
	pntadm -A 129.147.100.$addr -m server -h hundred-$addr 129.147.100.0
done

タイムゾーン SN_TZ のシンボル定義を追加するには、以下のようにします。

  1. 以下のように入力します。


    dhtadm -A -s SN_TZ -d  'Vendor="SUNW.PCW.LAN SUNW.Solaris", 13, ASCII, 1, 0'

  2. 以下のように入力します。


    dhtadm -M -m Locale -e `:SN_TZ = "EST5EDT4":'

  3. 以下のように入力します。


    /etc/init.d/dhcp stop

  4. 以下のように入力します。


    /etc/init.d/dhcp start
    あるいは、-t オプションを使用します。

jurassic マクロから Timeserv 値を削除するには、以下のようにします。

  1. 以下のように入力します。


    dhtadm -D -m jurassic -e `Timeserv=`

  2. 以下のように入力します。


    /etc/init.d/dhcp stop

  3. 以下のように入力します。


    /etc/init.d/dhcp start
    あるいは、-t オプションを使用します。

常にホスト名をサーバー jurassic のクライアントに戻すには、以下のようにします。

  1. 以下のように入力します。


    dhtadm -M -m jurassic -e `Hostname= _NULL_VALUE_'

  2. 以下のように入力します。


    /etc/initd/dhcp stop

  3. 以下のように入力します。


    /etc/init.d/dhcp start
    あるいは、-t オプションを使用します。

canoepoint という名前のホストと 1 つの IP アドレスとの間の、ホスト名 〜 IP アドレス間関連付けを維持することが重要な場合は、peds ネットワーク上の canoepoint エントリを MANUAL とマークします。

  1. 以下のように入力します。


    pntadm -M canoepoint -f MANUAL peds

    あるいは

  2. 以下のように入力します。


    pntadm -M canoepoint -f 02 peds

129.147.100.87 を BOOTP かつ永久とマークするには、以下のようにします。

  1. 以下のように入力します。


    pntadm -M 129.147.100.87  -f `BOOTP + PERMANENT' 129.147.100.0

    あるいは

  2. 以下のように入力します。


    pntadm -M 129.147.100.87 -f 09 129.147.100.0

保守

このシェルスクリプトは最初に、使用不可とマークされている IP アドレスをすべて検査して、使用されていないかどうかを確認します。使用されていない場合は、このスクリプトが IP アドレスを回収します。

#!/bin/ksh
# This shell script reclaims addresses which were marked as unusable, after
# first verifying that they're no longer in use.

if [ ${#} -eq 0 ]
then
     echo "reclaim <network> ..." >&2
     exit 1
fi

while [ ${#} -ne 0 ]
do
     pntadm -P ${1} | awk ' $2 == 04 { printf("%s %s¥n", $1, $3); }' |
     while read cid addr
     do
        if [ ${?} -ne 0 ]
        then
             pntadm -M ${addr} -i 00 -f DYNAMIC -e 0 ${1}
             if [ ${?} -eq 0 ]
             then
                 echo "${addr} has been reclaimed from client ${cid}."
             fi
             else
                 echo "${addr} is in use!" >&2
             fi
     done
     shift
done
exit 0

Solaris DHCP クライアントを有効にする方法

デフォルトでは、Solaris DHCP クライアントは無効にされています。有効にするには、DHCP を用いて構成したいと希望するネットワークインタフェースごとに、DHCP イネーブルファイルを 1 つ作成する必要があります。DHCP イネーブルファイルの書式は /etc/dhcp.interface_name であり、interface_name は DHCP によって構成したいと希望するネットワークインタフェースの名前です。

たとえば、DHCP を使用してネットワークインタフェース le1 を構成したい場合は、空ファイル /etc/dhcp.le1 を作成します。DHCP を使用して構成したいネットワークインタフェースが複数ある場合は、インタフェースごとに DHCP イネーブルファイルを 1 つ作成する必要があります。

ブートプロセスが一時停止する時間の増加

DHCP を使用してインタフェースを構成すると、ブート時間が増加することがあります。特に、クライアントの要求に応答する DHCP サーバーが存在しない場合には、インタフェースごとに約 30 秒の遅延が発生します。ネットワークインタフェースが構成されるまで、Solaris DHCP クライアントがブートプロセスを一時停止する (所要時間の長さにかかわらず) ことを希望する場合は、ネットワークインタフェースの DHCP イネーブルファイル (/etc/dhcp.interface_name) を編集して、wait forever というフレーズを追加します。

クライアントがブートプロセスを一時停止する時間をより短くしたいと希望する場合は、キーワード forever を使用する代わりに、待機する秒数を指定することができます。たとえば、DHCP がネットワークインタフェースを構成する時間として 1 時間待機してからブートプロセスを継続したいと希望する場合は、wait 3600 と指定します。

注 -

一時停止時間が経過した場合でも、Solaris DHCP クライアントは、ネットワークインタフェースの構成が正常終了するまで非同期的に構成を継続します。この継続を回避するために、ifconfig(1M) コマンドに drop オプションを指定することができます。たとえば、ifconfig le0 dhcp drop とします。これにより、指定されたインタフェース (この例では le0) が DHCP エージェントの制御から削除されて、非同期的なアドレス割り当て試行が終了します。

主ネットワークインタフェースとして指定する方法

大部分の DHCP 構成パラメータは 1 つのネットワークインタフェースに固有ではありません。パラメータには、より一般的な情報を指定します。この種の一般パラメータの例として、NIS サーバー、NIS ドメイン、DNS サーバー、DNS ドメインがあります。Solaris マシンに 1 つのネットワークインタフェースだけがある場合は、一般パラメータとインターフェースに固有なパラメータとを区別する必要はありません。

マシンに複数のネットワークインタフェースがあり (すなわち、複数のホームがあり)、DHCP が複数のインタフェースの構成を行う場合は、複数のセットの一般構成パラメータを受け取って、パラメータ同士が衝突する可能性があります。たとえば、DHCP を使用してインタフェース le0 を構成する際に受け取った DNS パラメータを使用すべきなのでしょうか、それとも le1 用に受け取った DNS パラメータを使用すべきなのでしょうか。

1 つのネットワークインタフェースを主ネットワークインタフェースとして指定すれば、Solaris DHCP クライアントはこの問題を解決することができます。インタフェースに固有なパラメータ (たとえば、サブネットマスク) は各インタフェースから取り出され、一般パラメータは、主インタフェースから受け取った DHCP 情報だけから取り出されます。

ネットワークインタフェースを主インタフェースとして指定するには、そのインタフェースの DHCP イネーブルファイルにキーワード primary を追加します。たとえば、qe2 を主インタフェースとして使用したいと希望する場合は、/etc/dhcp.qe2 を編集して、primary という語を追加します。

キーワード primary が追加されていない場合 (主インタフェースとして指定されているインタフェースがない場合)、Solaris マシンは、構成が最初に正常終了したインタフェースからパラメータを受け取ります。

DHCP/BOOTP の有効利用を制限するネットワークトポロジ

DHCP クライアントと BOOTP クライアントは最初、ローカル IP ネットワークについての情報を持っていません。したがって、自己の IP アドレスとして 0.0.0.0 (デフォルトのネットワークアドレス) を使用します。DHCP 要求または BOOTP 要求が、これらのクライアントから 255.255.255.255 IP アドレス (ブロードキャスト通信アドレス) へ送信され、ローカル IP ネットワークに接続されている全 IP デバイスが受信します。

DHCP サーバーと BOOTP サーバーは、以下の要素をベースにしてクライアントの IP ネットワークのアタッチメントを判定します。

  1. DHCP 要求または BOOTP 要求を受け取ったネットワークのハードウェアインタフェース

  2. 受け取った DHCP 要求または BOOTP 要求は、BOOTP 中継エージェントからのものであったかどうか

    BOOTP 中継エージェントは、DHCP クライアントまたは BOOTP クライアントと同じ IP ネットワークに接続されている、自己のネットワークのハードウェアインタフェースの IP アドレスを挿入します。この IP アドレスが欠落している場合は、クライアントが直接接続された IP ネットワーク上にある旨の信号がサーバーへ送信されます。この IP アドレスが存在する場合は、サーバーから離れたリモート IP ネットワークにクライアントが接続されていること、および BOOTP 中継エージェントの IP アドレスを使用してサーバーがクライアントへ応答を返信することを表しています。

  3. クライアントが接続されている IP ネットワークがサブネット化されているかどうか

    サーバーは、IP アドレスをキーとして使用して、netmasks テーブル (サブネットのマスク情報を格納しています) の内容を調べます。この場合に使用する IP アドレスは以下のうちのいずれかです。

    • クライアントが直接接続された IP ネットワーク上にある (パケットの中継アドレスフィールド内の 0.0.0.0 という IP アドレスによって示されます) 場合は、サーバーのネットワークのハードウェアインタフェースの IP アドレス

    • BOOTP 中継エージェントがクライアントの要求内に IP アドレスを指定していた場合は、その指定された IP アドレス

クライアントの IP ネットワークのアタッチメントを判定するこの手順が有効なのは、ネットワークのハードウェア媒体 (たとえば、イ−サネット) 上に存在する IP ネットワークが 1 つだけである場合のみです。複数のネットワークハードウェアインタフェースを使用するか、または複数の論理インタフェースを使用することによって、複数の IP ネットワークが同じネットワークハードウェア媒体を共有している IP ネットワーク環境では、DHCP は適切に動作しません。この場合には、DHCP クライアントの要求が全ネットワークハードウェアインタフェース上に表示され、「外観上は」そのクライアントがすべての IP ネットワークに同時に接続されているかのように見えます。DHCP サーバーは IP アドレスを動的に要求元のクライアントへ割り当てるため、そのクライアントへ割り当てるべき IP アドレスをサーバーが決定することはできません。それは、その時点でサーバーが保持している IP アドレスの妥当性検査を試行すると、DHCP クライアントは、割り当てられたネットワーク上だけではなく、すべての論理 IP ネットワーク上に存在するように見えるからです。

このようなネットワークトポロジは回避する必要があります。そのためには、より効率的なサブネット化を行い、可変長サブネットマスク (VLSM) を使用して IP ネットワーク間のハードウェア媒体のマップを一対一に保持するか、あるいは、ただ 1 つの論理 IP ネットワークがサービスの対象となるように DHCP または BOOTP のサービスを構成します。詳細は、netmasks(4) を参照してください。

第 17 章 DHCP の障害追跡

この章では、DHCP の使用時に検出される可能性がある問題の障害追跡を行う方法について説明します。最初の DHCP サーバーをインストールして構成する時点で発生する可能性のある問題に対する解決策も説明します。DHCP サーバーの構成スクリプト (dhcpconfig) についての内容説明 (種々のスクリプト構成要素の目的と、スクリプトがインストール手順を実行する過程) も記載されています。さらに、ネットワークに DHCP クライアントを初めて追加する際と後続して追加する際に検出される可能性がある問題についても説明します。

方法および注意事項

以下の障害追跡手法は、原因を特定できない場合の問題解決に役立ちます。

この章では、上記の手法を詳細に説明します。また、本書を使用しても問題を解決することができない場合の問い合わせ先を紹介します。

snoop を使用してネットワークのトラフィックを監視

snoop コマンドを使用してネットワークのトラフィックを監視することができます。

snoop を使用してネットワークのトラフィックを監視するには

  1. クライアントと同じサブネット上の Solaris サーバーまたは BOOTP/DHCP 中継エージェントに、スーパーユーザーとしてログインします。

  2. snoop コマンドを使用してネットワークのトラフィックを監視します。たとえば、以下のように入力します。


    snoop -o /tmp/output udp port 67 または udp port 68

  3. クライアントをブートして、クライアントとサーバー (複数可) との間の DHCP メッセージの交換を監視します。

  4. 以下のように入力します。


    snoop -i /tmp/output -x 0 -v

クライアントのハードウェアアドレスを指定することによって snoop の適用範囲を制限することができます。DHCP/BOOTP プロトコルを解釈できる snoop は、Solaris 2.5 オペレーティング環境およびその互換バージョンで使用できます。

DHCP クライアントをデバッグモードで動作

DHCP クライアントをデバッグモードで動作させると、クライアントとサーバーとの間で進行中のほとんどの対話が明らかになります。クライアントが動作しているベースの製品については、関連のマニュアルを参照してください。

Solaris クライアントをデバッグモードで動作させるには

DHCP クライアントのデバッグは、DHCP クライアントをブートした後でのみ可能です。DHCP に問題が発生した場合は、DHCP を無効にしてブートする必要があります。以下の手順は、ホストのブート後に一度だけ実行することができます。ただし、シングルユーザーモードでの実行を推奨します。

  1. DHCP エージェントを設定して、サーバーと交換するパケットの詳細をログに記録することができます。この記録を行うには、以下のようにして、デバッグモードをオンに設定してエージェントを開始する必要があります。


    /sbin/dhcpagent -n -d3 &

    -d3 フラグはレベル 3 でのデバッグをオンに設定し、-n フラグは「DHCP が正常な場合でもインタフェースを構成してはならない」という意味です。

    注 -

    レベル 3 およびそれより下位のレベルでは、ユーザーに適切な情報が戻されます。レベル 3 より上位のレベルは、情報が生のパケットのまま戻されるため、開発者の方または高度な専門知識を持つ方だけが使用します。

  2. dhcpagent のインスタンスは一度に 1 つだけが実行可能なため、ここでエージェントを開始する前に、すでに起動済みのエージェントをすべて停止する必要があります。エージェントを停止するには、エージェントのプロセス ID を調べて、以下のように終了シグナルを送信します。


    kill -TERM process_id_of_dhcpagent

  3. エージェントをデバッグモードで開始した後で、以下のように入力して、手動でインタフェースの構成を試行します。


    ifconfig interface_name auto_dhcp

    送受信されたパケットが表示されます。

    注 -

    DHCP がインタフェースの構成を試行している間、インタフェースはパケットの送受信を行うことができません。インタフェースがダウンしている間は、その他のネットワークサービス (たとえば NIS や NFS) が悪影響を受ける場合があります。

DHCP サーバーをデバッグモードで動作させるには

DHCP サーバーを停止して、デバッグモードで再起動します。以下に例を示します。

  1. 停止スクリプトを使用してサーバーを停止します。


    /etc/init.d/dhcp stop

  2. サーバーをデバッグ・冗長モードで再起動します。ただし、/etc/init.d/dhcp 起動スクリプト内に指定されているフラグに加えて、-d フラグと -v フラグを使用します。たとえば、i オプションが存在する場合は、以下の形式でコマンドを入力します。


    /usr/lib/inet/in.dhcpd -i interface_names  -d -v

DHCP クライアントの再起動

DHCP クライアントをデバッグモードで動作させた後で、リブートを試行することができます。リブートを行うと、ネットワークのハードウェアとソフトウェアがリセットされます。

DHCP クライアントを再起動するには

    クライアントをリブートします。

DHCP サーバーを再起動するには

  1. DHCP サーバーにスーパーユーザーでログインします。

  2. 以下のように入力します。


    /etc/init.d/dhcp stop

    約 10 秒間待機します。

  3. 以下のように入力します。


    /etc/init.d/dhcp start

デバッグの完了後に DHCP サーバーを再起動するには

  1. DHCP サーバーのデーモンを再起動します。

  2. DHCP サーバーにスーパーユーザーでログインします。

  3. 以下のように入力します。


    /etc/init.d/dhcp stop

    約 10 秒間待機します。

  4. 以下のように入力します。


    /etc/init.d/dhcp start

一般的な問題

この節では、DHCP に関して検出される可能性がある、より一般的な問題の一部と、それらの問題に対する処置について説明します。

問題

DHCP クライアントが DHCPDISCOVER または DHCPREQUEST というメッセージを送出しているが、DHCP サーバーが応答しない。

検証: サーバーマシンのコンソール出力を確認します。割り当てるべき IP アドレスがサーバーに残っていないことが考えられます。

解決策: より多くの IP アドレスを追加します。

検証: サーバーマシンのコンソール出力を確認します。クライアントが認識されていないことをサーバーが示している場合は、DHCP サーバーのデータベースがフラッシュして、その結果としてクライアントの認識に失敗していることが考えられます。

解決策: クライアント上の DHCP キャッシュファイルをすべて削除します。

  1. Ctrl -C を入力してブートに割り込みます。

  2. 以下のように入力して、キャッシュを削除します。


    cd /etc/dhcp; rm interface_name.dhc

  3. 以下のように入力して、初期化プロセスを再起動します。


    ifconfig interface_name dhcp release

検証: サーバーマシンのコンソール出力を確認します。クライアントのネットワークに対するサポートが DHCP データベースに追加されていないことが考えられます。

解決策: dhcpconfig を使用して、クライアントのネットワークに対するサポートを追加します。

検証: クライアントが DHCP サーバーのネットワークとは別個のネットワーク上にあり、かつ BOOTP 中継エージェントがインストールされていないか、または設定されていません。

解決策: BOOTP 中継エージェントをインストールして設定します。さらに、リモートネットワークの netmasks(4) データベースにエントリを追加することが必要な場合があります。

問題

クライアントのログに、アドレスがすでに使用中であるというメッセージが記録される。

検証: アドレスが他で使用中であるかどうかを検査します。同じメッセージがクライアントのログに継続して記録される場合は、サーバーがアドレスを検査していないか、またはアドレスを拒否するクライアントのメッセージを無視しているかのいずれかが考えられます。 n オプション付きで in.dhcpd コマンドを使用していないことを検査して確認します。

解決策: サーバーが不良なアドレスを配付したかどうかを確認します。サーバーが誤動作しているか、または別のユーザーが同じアドレスを不法使用しているかのいずれかです。

問題

以下のエラーメッセージが表示される。


DHCP renewal on interface_name failed


(interface_name に対する DHCP の更新が失敗した)

検証: DHCP クライアントが、指定したインタフェースについてのリースを更新することができませんでした。

解決策: DHCP サーバーが適正に動作していることを確認します。

問題

以下のメッセージが表示される。


Address of interface name has changed


(インタフェース name のアドレスが変更されている)

検証: インタフェースのアドレスまたは状態が、DHCP エージェントが予期するものと異なっています。アドレスが手動で変更されたことが考えられます。

解決策: 解決策はありません。エージェントは、インタフェースを構成する試行を停止します。

支援の要請先

上記の方法を適用しても問題を解決できない場合は、Solaris のご購入先にお問い合わせください。最善のサービスを確実に受けるために、以下の情報をあらかじめご確認の上、お問い合わせください。

DHCP サーバーの障害追跡

この節では、DHCP サーバーに発生する可能性がある問題について説明します。

ファイルの使用時

ネームサービスとして files を使用している際に問題が発生した場合は、以下の指示に従います。

問題

/var/dhcp ディレクトリにアクセスできない。そのディレクトリが存在しないか、または UNIX のファイル読み取り権を持っていない。

検証: 以下のコマンドを使用します。


ls -d /var/dhcp

解決策: DHCP サーバーがまだ構成されていません。dhcpconfig を実行します。

NIS+ の使用時

ネームサービスとして NIS+ を使用している際に問題が発生した場合は、以下の指示に従います。

問題

NIS+ ドメイン内にルートオブジェクトが存在しない。

検証: 以下のコマンドを入力します。


niscat -o org_dir

解決策: Solaris NIS+ 設定用のマニュアルを参照してください。

問題

root のアカウントに、org_dirオブジェクトの下でテーブルを作成するアクセス権がない。

検証: 以下のコマンドを入力します。


niscat -o org_dir

解決策: nischmod コマンドを使用して table.org_dir.domainname. に対するアクセス権を変更します。

問題

root のアカウントに、org_dir の下でテーブルを作成するアクセス権がない。通常これは、root のアカウントの主体名が org_dir オブジェクトの所有グループのメンバではないか、または所有グループが存在しないかのいずれかを表します。

検証: 以下のコマンドを入力して、所有グループ名を検索します。

niscat -o org_dir

解決策:

  1. nisgrpadm -l group と入力して、グループのメンバーを確認します。

  2. 現システムの主体名がグループ内にない場合は、nisgrpadm -a group principalname と入力して主体名を追加します。通常グループは admin です。グループが admin ではない場合は、dhcpconfig スクリプトを編集してグループを変更し、使用中のグループ名と一致させます。

  3. /usr/lib/nis/nisctl -fg と入力して、変更が即時に行われるようにキャッシュをフラッシュします。

問題

ドメイン名が設定されていない。

検証: 以下のコマンドを入力します。


domainname

このコマンドにより空文字列が表示された場合、当該ドメインにはドメイン名が設定されていません。

解決策: domainname コマンドを使用して正しいドメイン名を設定します。ドメイン名の値を /etc/default ドメイン内に置きます。

問題

NIS_COLD_START ファイルが存在しない。

検証: サーバーシステム上で以下のコマンドを入力します。


strings /var/nis/NIS_COLD_START

解決策: NIS+ クライアントを 1 つ作成します。『Solaris NIS+ QuickStart』を参照してください。

問題

NIS+ を選択したが、サイトで NIS+ が動作していない。

検証: サーバーにログインして、以下のコマンドを入力します。


 ps -ef | grep nis

NIS+ が動作している場合は、/usr/sbin/rpc.nisd -YB という出力に類似した出力が表示されます。

解決策: 以下のようにして、NIS+ サーバーを作成します。

  1. クライアント上で、NIS+ の root のマスターサーバーをドメイン用に設定します。たとえば、以下のようにします。


    /usr/lib/nis/nisserve -r

  2. ローカルの /etc ファイルから NIS+ テーブルを生成します。たとえば、以下のようにします。


    nispopulate -F /etc

  3. サーバー上で、NIS+ が動作していることを確認します。たとえば、以下のようにします。


    /usr/lib/nis/nisstat
nisls org_dir  
niscat hosts.org_dir

ネームサービスとして NIS+ を使用できない場合

以下のエラーメッセージのうちのいずれかまたは両方が表示されます。


!!! warning !!! trailing dot ignored - use dns domain name syntax


(!!! 警告 !!! 後尾のドットが無視された - DNS のドメイン名構文を使用してください)


Error 20 from NIS+; unable to use NIS+ as name service.


(NIS+ でエラー 20。NIS+ をネームサービスとして使用できない)

上記のメッセージは、NIS+ ドメイン内に該当する名前が存在しないか、または NIS+ ドメインが存在しないかのいずれかを表します。以下の情報を使用し、NIS+ の構成内のエラーを見つけ出して解決します。

問題

サーバーシステムのドメイン名の末尾は、ピリオド 1 つで終わる。

検証: nisdefaults コマンドを入力して、ドメイン名の末尾にピリオドが 2 つあるかどうかを確認します。

解決策:

  1. /etc/defaultdomain ファイルを編集して、ドメイン名から末尾のピリオド (.) を削除します。

  2. システムをリブートし、dhcpconfig スクリプトを再度実行します。

問題

ホスト名にドメイン名が含まれている。たとえば、ホストが myhost ではなく myhost.Faxco.COM と設定されている。

検証: nisdefaults コマンドを入力して、ドメイン名を含んでいるホスト名を 2 度表示します。

解決策:

  1. ホスト名が間違っている場合は、sys-unconfig コマンドを入力し、構成設定値を削除してシステムを停止します。

  2. システムをリブートし、ホスト名とドメイン名の適正な設定値を指定します。

問題

root のアカウントに、NIS+ ドメイン内の org_dir オブジェクトに対する作成のアクセス権がない。

検証: 以下のコマンドを入力します。


niscat -o org_dir

解決策: nischmod コマンドを使用して、table.org_dir.domainname に対するアクセス権を変更します。

ファイルのネームサービスを利用する際の入出力エラー

以下のエラーメッセージが表示されます。


File system I/O error number accessing file datastore.


(ファイルのデータストアにアクセスする際に入出力エラー number が発生)

上記のエラーメッセージを受け取った場合は、以下に示すエラーメッセージのリストを調べます。以下に示すエラーメッセージは、/var/dhcp 内のファイルのオープン、読み取り、書き込みのいずれかをオペレーティングシステムが試行した際に、オペレーティングシステムが返すエラーメッセージです。

問題

エラー番号 2 (ENOENT)。

検証: ファイルまたはディレクトリが存在しません。

解決策: dhcpconfig コマンドを入力してファイルまたはディレクトリを作成します。

問題

エラー番号 13 (EACCES)。

検証: ファイルまたはディレクトリにアクセスした際に、UNIX のアクセス権エラーが発生しました。

解決策: su コマンドを使用して UNIX のアクセス権を変更します。

ユーザーに DES 資格がない場合

問題

以下のエラーメッセージが表示されます。


The user user does not have DES credentials in the NIS+ name service.


(ユーザー user には、NIS+ ネームサービスにおける DES 資格がない)

検証: 現システムの root のアカウントは、有効なデータ暗号化規格 (DES) 資格を NIS+ cred テーブル内に持っていません。

解決策: nisaddcred コマンドを使用して、 root のアカウントの資格を追加します。コマンド行に、UNIX ネット名と NIS+ 主体名を入力する必要があります。

ドメイン Faxco.COM 内のシステム mercury の DES 資格を追加する方法を以下の例に示します。


nisaddcred -p unix.mercury@Faxco.COM¥
-P mercury.Faxco.COM. DES Faxco.COM

このコマンドでは、root のパスワード (暗号化された秘密鍵を作成するために必要です) を求めるプロンプトが表示されます。

データストア内にテーブルを作成するアクセス権がない場合

以下のエラーメッセージが表示されます。


You do not have permission to create the tablename table in the servicename data store.


(servicename データストア内に tablename テーブルを作成するアクセス権がない)

テーブルをデータストア内に作成する際に問題が発生した場合は、以下の情報を検査します。

問題

root のアカウントに、org_dir オブジェクトの下でテーブルを作成するアクセス権がない。

検証: 通常これは、root のアカウントの主体名が org_dir オブジェクトの所有グループのメンバーではないか、または所有グループが存在しないかのいずれかを表します。

解決策:

  1. niscat -o org_dir と入力して、所有グループの名前を確認します。

  2. nisgrpadm -l admin と入力して、グループのメンバーを確認します。

  3. 現システムの主体名がグループ内にない場合は、nisgrpadm -a group principalname と入力して主体名を追加します。

  4. /usr/lib/nis/nisctl -f g と入力して、変更が即時行われるようにキャッシュをフラッシュします。

ネームサーバーを判定できない場合

DHCP サーバーの構成の際にネームサーバーを見つけることができない場合の解決策を以下に示します。

問題

dhcpconfig スクリプトで、サーバー名と IP アドレスが一致しなかった。

検証: コマンド getent hosts name を入力して、サーバーの IP アドレスを検索します。

解決策: hosts データベース内にエントリを作成します。

問題

dhcpconfig スクリプトが、サーバーの間違ったネームサービスを使用している。

検証: /etc/nsswitch.conf ファイル内の hosts エントリを調べて、IP アドレスの検索に使用されているネームサービス (xfn、files、nis、nisplus、dns のいずれか) を確認します。

解決策: /etc/nsswitch.conf ファイル内の hosts 命令を適正なネームサービスに変更します。nscd を停止して再起動します。

問題

dhcpconfig スクリプトがネームサービスを検査しなかった。

検証: /etc/nsswitch.conf ファイル内の [NOTFOUND=RETURN] 命令に先行するネームサービスが優先しています。指定されたネームサービスがエントリを見つけられなかった場合は、この命令の後に表示されているネームサービスはすべて検査されません。

解決策: /etc/nsswitch.conf ファイルから [NOTFOUND=RETURN] 命令を削除し、再度 dhcpconfig スクリプトを実行します。nscd を停止して再起動します。

DHCP テーブルの設定を試行した際のエラー

以下のエラーメッセージのうちの 1 つが表示されます。


The user username does not have permission to update the dhcptab table in the servicename resource.


(ユーザー username には、servicename リソース内の dhcptab テーブルを変更するアクセス権がない)


Error 10 from the Table subsystem accessing dhcptab table, message: NIS+ error while executing nis_modify_entry for [key=SUNW.PCNFS.5.1.1,flag=m],dhcptab.org_dir.island.ocean.: Permission denied Error trying to set up DHCP table, exiting.


(dhcptab テーブルにアクセスした際の Table サブシステムのエラー 10 の場合のメッセージ。[key=SUNW.PCNFS.5.1.1,flag=m],dhcptab.org_dir.island.ocean. に対して nis_modify_entry を実行中にNIS+ のエラー: DHCP テーブルの設定を試行した際にアクセス権拒否のエラーが発生して終了した)


Error 10 from the Table subsystem accessing dhcptab table, message: NIS+ error while executing nis_modify_entry for [key=SUNW.PCNFS.5.1.1,flag=m],dhcptab.org_dir.island.ocean.: Object with same name exists Error trying to set up DHCP table, exiting.


(dhcptab テーブルにアクセスした際の Table サブシステムのエラー 10 の場合のメッセージ。[key=SUNW.PCNFS.5.1.1,flag=m],dhcptab.org_dir.island.ocean. に対して nis_modify_entry を実行中に NIS+ のエラー: DHCP テーブルの設定を試行した際に同じ名前のオブジェクトが存在するというエラーが発生して終了した)

上記のエラーメッセージのうちの 1 つを受け取った場合は、以下の情報を検査すれば、DHCP サーバーの構成中に DHCP テーブルの設定を試行した際に発生した問題の解決策があります。

問題

NIS+ または UNIX のファイルシステムから DHCP テーブルにエントリを追加するアクセス権を持っていない。

検証: アクセス権を検査して、DHCP テーブルに対する必要なアクセス権を設定します。

解決策: 管理者が所定の管理グループのメンバーであり、NIS+ のマスターサーバーに書き込むアクセス権を持っていることを確認します。

dhcp_network テーブルへのアクセス権がない場合

以下のエラーメッセージが表示されます。


You do not have permission to create {update} the tablename table in the servicename data store.


(servicename データストア内で tablename テーブルを作成する {変更する} アクセス権がない)

上記のメッセージを受け取った場合は、以下の情報を検査します。以下に示すのは、DHCP サーバーの構成中に dhcp_network テーブルにアクセスした際に発生した問題に対する解決策です。

問題

NIS+ または UNIX のファイルシステムから dhcp_network テーブルにエントリを追加するアクセス権がない。

検証: アクセス権を検査して、 dhcp_network テーブルに対する必要なアクセス権を設定します。

解決策: 管理者が所定の管理グループのメンバーであり、NIS+ のマスターサーバーに書き込むアクセス権を持っていることを確認します。

DHCP クライアントの障害追跡

DHCP クライアントの障害追跡を行う場合は、クライアントの構成とクライアント〜サーバー間の通信についての問題点を理解しておく必要があります。DHCP がサーバーと通信できなかったか、または受け取った構成応答が間違っていたかのいずれかのために、DHCP がクライアントを正しく構成することに失敗する場合があります。さらに、クライアントが自己の IP アドレスを更新することができない場合には、DHCP のリースの期間の終わり頃になって問題が発生することがあります。

クライアントがサーバーと通信できない場合

クライアントとサーバーが相互に通信を行うことができない場合は、以前の DHCP のトランザクションからキャッシュに書き込んだ構成をクライアントが持っているかいないかに応じて結果が異なります。クライアントがキャッシュに書き込まれた構成を持っていて、かつリースがまだ有効な場合は、キャッシュのデータを使用してインタフェースを構成します。

ただし、キャッシュに書き込まれている構成が有効であるという外部での確認をクライアントが受け取っていないため、IP アドレス、ルーターのアドレス、およびその他の情報が有効であるという保証はありません。構成を受け取った際のネットワークとは別のネットワークにインタフェースが接続された場合は 2 種類のエラーが発生する可能性があり、発生する場合にはいずれか 1 つが発生します。その他のネットワークサービスを開始した際にいずれかのエラーが表示される場合があります。あるいはネットワーク上のその他のホストとの通信ができない場合があります。

逆に、期限が切れていないリースを持つキャッシュが存在しない場合、インタフェースは構成されません。

受け取った DHCP 構成が無効な場合

以下の 2 つの理由から、構成が無効なことがあります。

  1. クライアントに提供された IP アドレスが他で使用中であることを ARP によってクライアントが判定する。

    この場合、クライアントはサーバーに DHCPDECLINE メッセージを送信します。サーバーが不良なアドレスを 3 つ以上提供すると、dhcpagent は失敗します。

  2. クライアントは IP アドレスを取得したが、確認を試行するとサーバーが確認ではなく DHCPNAK メッセージを送信する。

クライアントが DHCPNAK メッセージを 3 回以上受け取ると、dhcpagent は失敗します。このことは、サーバーが誤動作していることを示します。

問題をクライアントまたはサーバーに切り離す場合

問題をクライアントマシンまたはサーバーマシンのいずれかの問題として切り離す場合は、以下の処置を実行します。

問題

DHCP サーバーマシンが動作していない。

検証: クライアントと同じサブネット上の別のマシンにログインし、ping コマンドを使用してサーバーへの接続を試行します。

解決策: サーバーマシン上で問題を診断します。

問題

DHCP サーバーが動作していない。

検証: サーバーにログインして、以下のコマンドを入力します。


ps -ef | grep dhcp

解決策:

  1. DHCP サーバーを停止して再起動します。

  2. 以下のコマンドを入力します。


    /etc/init.d/dhcp stop

  3. 約 10 秒間待機してから、以下のコマンドを入力します。


    /etc/init.d/dhcp start

問題

DHCP の際、ブートプロセスがハングする。

検証: インタフェースが primary とマークされますが、有効な DHCP トランザクションは発生していません。

解決策: control-C を入力して DHCP に割り込みます。ブートが継続します。

注 -

ブートは継続しますが、ホストが接続されているネットワークに対しては、ホストの間違った構成が行われる場合があります。

クライアントが DHCP サーバーに接続できない場合

問題

DHCP クライアントのソフトウェアを構成し、そのクライアントを再起動した後で、ネットワーク上のサーバーにクライアントから接続することができない。DHCP のネットワークコマンドがすべて失敗し、DHCP サーバーへの接続をクライアントが試行したが失敗した、というメッセージが表示される。

一般的なエラーメッセージは以下のとおりです。


DHCP or BOOTP server not responding


(DHCP サーバーまたは BOOTP サーバーが応答しない)


A request to access nonexistent dhcp_network database: databasename in datastore: datastore.


(データストア datastore 内の、存在しない dhcp_network データベース databasename へのアクセス要求である)


No more IP addresses for network_address network.


(network_address には、もう IP アドレスがない)

検証: 問題を正確に突き止めるために、以下の処置を実行します。

  1. クライアントをデバッグモードで動作させます。

  2. 手動でインタフェースの構成を試行して、ハードウェアが機能していることを確認します。

  3. DHCP サーバーをデバッグモードで実行します。

  4. snoop コマンドを使用して、DHCP サーバーとクライアントとの間で送信されるメッセージを追跡します。

  5. 問題がクライアントマシン側にあるのかサーバーマシン側にあるのかを調べます。

  6. エラーメッセージを調べて、以下の情報から解決策を選択します。

クライアントをデバッグモードで動作させる

クライアントをデバッグモードで動作させます。稼働している製品のマニュアルを参照してください。

Solaris クライアントの場合

  1. 以下のように入力して起動します。


    /sbin/dhcpagent -d3

DOS クライアントの場合

PC-NFS DOS クライアント上で、以下を実行します。

  1. AUTOEXEC.BAT ファイルを編集し、SNCLIENT を SNCLIENT /D に置換します。

  2. クライアントを再起動します。

インタフェースを手動で構成する

dhcpagent をデバッグモードで開始した後で、以下のように入力して、手動でインタフェースの構成を試行することができます。


ifconfig interface_name auto_dhcp

送受信されたパケットが表示されます。

サーバーをデバッグモードで動作させる

  1. クライアントと同じサブネット上の DHCP サーバーにスーパーユーザーでログインします。

  2. デバッグモードで、DHCP サーバーを終了して再起動します。たとえば、以下のようにします。


    /etc/init.d/dhcp stop
/usr/lib/inet/in.dhcpd -d -v

    あるいは、i オプションが存在する場合には、コマンドを以下の形式で入力します。


    /usr/lib/inet/in.dhcpd -i interface_names -d -v

snoop を使用してネットワークのトラフィックを監視する

  1. クライアントと同じサブネット上の DHCP サーバーまたは BOOTP 中継エージェントにスーパーユーザーでログインします。

  2. snoop コマンドを使用して、ネットワークのトラフィックを追跡します。たとえば、以下のように入力します。


    snoop -o /tmp/output udp port 67 または udp port 68
    あるいは 

    snoop -o /tmp/output udp port bootps または udp port bootpc
    インタフェースごとの引数が存在する場合は、その引数を加えます。

  3. クライアントをブートして、サーバー上でネットワークのメッセージを監視します。

  4. 以下のように入力します。


    snoop -i /tmp/output -x 0 -v
    このコマンドにより、パケットのトレースを参照することができます。

エラーメッセージを調べる

デバッグモードで in.dhcpd コマンドを実行した結果の出力を調べ、調べたエラーメッセージまたは状態を使用して、以下の情報から解決策を見つけ出します。

問題

以下のエラーメッセージが表示される。


Datagram received on network device: le0


(ネットワークデバイス le0 上でデータグラムを受け取った)


ICMP ECHO reply to OFFER candidate: ip_address disabling


(OFFER 候補 ip_address に対する ICMP ECHO の応答が無効にされた)

検証: DHCP サーバーは、クライアントに対して IP アドレスを提供する前に、その IP アドレスに対して ping コマンドを使用して当該アドレスが使用中ではないことを確認します。クライアントが応答した場合、その IP アドレスは使用中です。

解決策: 設定した IP アドレスがまだ使用中ではないことを確認します。

問題

以下のエラーメッセージが表示される。


No more IP addresses for network_address network


(network_address ネットワークには、もう IP アドレスがない)

検証: クライアントの dhcp_network テーブル内に、使用可能な IP アドレスがありません。

解決策: dhcpconfig コマンドを使用して、さらに IP アドレスを割り当てます。DHCP デーモンが複数のサブネットを監視している場合は、追加の IP アドレスが、クライアントが配置されているサブネットに対するものであることを確認します。

問題

dhcp_network データベース内に id_name という不良なクライアント ID がある。

検証: dhcp_network テーブル内のクライアント ID (MAC アドレス) が間違っています。

解決策: イ−サネットを使用している場合、クライアント ID は 01 の後にイ−サネットアドレスが続きます。アドレス内のすべての文字が大文字になっていることを確認します。00 は、アドレスが割り当てられていないことを表します。

問題

以下のエラーメッセージが表示される。


Request to access nonexistent dhcp_network database: database_name in datastore: nisplus_datastore.


(データストア nisplus_datastore 内の、存在しない dhcp_network データベース database_name へのアクセス要求である)

検証: DHCP サーバーの構成時に、dhcpconfig スクリプトがサブネットの dhcp_network テーブルを作成しませんでした。テストネットワークとして、LAN (たとえば、サーバー 1 つとクライアント 2 つ) を設定して切り離した場合に起こることがあります。

解決策: dhcpconfig コマンドを使用して、dhcp_network テーブルと新規 IP アドレスを初期化します。

問題

以下のエラーメッセージを受け取る。


Client client_id is trying to verify unrecorded address ip_address, ignored.


(クライアント client_id が、記録されていないアドレス ip_address の確認を試行して無視された)

検証: このメッセージを受け取る場合は、考えられる理由が 2 つあります。

  1. dhcp_network テーブルが削除されている場合に、このメッセージを受け取ることがあります。Solaris DHCP サーバーのみを使用している場合は、通常これが理由です。

  2. データストア用に NIS+ が使用されていないことが原因で情報が共有されていない場合に、このメッセージを受け取ることがあります。サーバーがデータを共有していることを確認します。

異機種システムが混在しているサーバーのグループがある場合、このメッセージを無視します。

解決策: 以下のように入力して、クライアント上の古いキャッシュファイルを削除します。


ifconfig interface_name dhcp release

問題

DHCP は開始されているが、必要なネットワークサービスの一部が開始しない。

検証: DHCP サーバーが、必要な構成を供給していません。

解決策: サーバーが、必要なパラメータを送信しない理由を調べます。必要なパラメータを送信するようにサーバーを構成します。

問題

DHCP は開始されているが、特定のネットワークサービス (たとえば、NIS や NIS+) がエラーを報告するか、またはハングする。ホストが、ネットワーク上のその他のホストと通信を行うことができない。

検証: dhcpagent コマンドが、DHCP と通信を行うことができない (DHCP が使用可能でないため、と考えられます) ために、キャッシュに書き込まれているデータを使用しました。

解決策: キャッシュを削除します。以下のように入力します。


ifconfig interface_name dhcp release

キャッシュを削除しても、正しい構成を取得するという問題は解決されないため、ホストを手動で構成する必要がある場合があります。以下のように入力してトリガーファイルを削除することにより、ブート時に DHCP を無効にする必要があります。


rm /etc/dhcp.interface_name

問題

クライアントはブートして適正に動作するが、以下のメッセージが表示される。


DHCP renewal on interface_name failed


(interface_name に対する DHCP の更新が失敗した)

検証: DHCP は動作していますが、dhcpagent によりサーバーに接続してリースの延長を行うことができません。

解決策: サーバーが応答しない理由を調べます。dhcptab 内に設定されているルーターの値が間違っているか、またはクライアントのネットワークに対して期限が切れていることが理由である可能性があります。

問題

失敗した DHCP の更新についてのメッセージを受け取り、その後で以下のメッセージがコンソールに表示される。


DHCP lease expired on interface_name: interface is now down


(interface_name に対する DHCP のリースの期限が切れて、インタフェースは現在ダウンしている)

ネットワークサービスがこの時点でハングすることが考えられる。

検証: リースの期限が切れました。クライアントは複数回の試行を行いましたが、リースを延長することができませんでした。

解決策: サーバーが応答しない理由を調べます。クライアントを再起動します。

BOOTP 互換モードにおいて、一部のクライアントが DHCP サーバーからブートしない場合

問題

DHCP デーモンが BOOTP 互換モードで動作している (-b オプション)。

検証: BOOTP はリース時間を使用しません。DHCP サーバーは、BOOTP フラグが設定されている空きアドレスを探して、BOOTP クライアントに割り当てます。

解決策: BOOTP アドレスを割り当てます。dhcpconfig を使用して、デーモンのオプションを変更します。

NIS + 構成の問題の診断

以下の情報を使用して、NIS+ ネームサービスの構成内にある、ブート時にクライアントがサーバーにアクセスできないというエラーを修正します。

問題

dhcptab テーブル内で、クライアントに対してネームサービスが構成されていない。

検証: サーバーにログインして、以下のコマンドを入力します。


dhtadm -P | grep ip_address

NISdmain、DNSdmain、NISservs などのエントリを検査します。エントリに対して入力されているアドレスが適正であることを確認します。たとえば、以下のようになります。


# dhtadm -P | grep 129.148.3.129.148.3.m:Subnet=255.255.255.0:Router=129.148.3.11: 
Broadcast=129.148.3.255:NISdmain="island.ocean":NISservs=129.148.3.3:

注 -

上記の行は、実際には 2 行に分かれないで 1 行で表示されます。

解決策: dhtadm を使用して、間違っているアドレスがあればすべて変更します。

問題

NIS+ を使用しているが、サーバーが NIS+ 互換モードで動作していない。NIS+ テーブルには Nobody カテゴリ用の読み取り権がないため、NIS クライアントが NIS+ テーブルに格納されている情報を読み取ることができない。

検証: 以下のコマンドを実行します。


nisls -l org_dir
このコマンドにより、.r---rmcdrmcdr--- のアクセス権が表示されます。

rpc.nisd デーモンに対して Y オプションが設定されているかどうかを検査します。たとえば、以下のように入力します。


ps -deaf | grep nis

解決策:

  1. NIS+ サーバーにスーパーユーザーでログインします。

  2. 以下のコマンドを入力します。


    /usr/lib/nis/nisserver -r -Y -d domainname

問題

デフォルトのルーターが間違っているため、クライアントが別のネットワーク上のサーバーに接続することができない。

検証: dhcptab テーブル内のルーターのシンボルの定義が本当にルーターであることを確認します。

解決策: dhtadm を使用して、テーブル内のルーターのシンボルを訂正します。

問題

NIS+ を動作させているが、NIS クライアントに対する DNS 転送がオンに設定されていない。

検証: 以下のコマンドを使用します。


ps -ef | grep rpc.nisd

-B オプションは、DNS 転送がオンに設定されて NIS が動作していることを表します。たとえば、以下のようになります。


/usr/sbin/rpc.nisd -B

解決策: DNS 転送を有効にして、NIS 互換モードで NIS+ サーバーを起動します。たとえば、以下のように入力します。


/usr/sbin/rpc.nisd -YB

ネームサービス構成の問題の診断

以下の情報を使用して、NIS ネームサービスの構成内にある、ブート時にクライアントがサーバーにアクセスできないというエラーを修正します。

問題

デフォルトのルーターが間違っているため、クライアントが別のネットワーク上のサーバーに接続することができない。

検証: dhcptab テーブル内のルーターのシンボルの定義が本当にルーターであることを確認します。デフォルトのルーターに問題がある場合は、サーバーベースのツールを用いて訂正を行います。

解決策: dhtadm を使用して、テーブル内のルーターのシンボルを訂正します。

問題

dhcptab テーブル内で、クライアントに対してネームサービスが構成されていない。クライアントに対しては、ネームサービスは DNS、NIS または NIS+ である必要があり、さらに必要なパラメータをクライアントごとに指定する必要がある。881

検証: クライアントの構成に関連する、ネットワークに固有なマクロを検査します。

  1. サーバーにログインし、以下のコマンドを入力します。


    dhtadm -P

  2. クライアントのネットワークに一致するエントリを探します。

解決策: dhtadm を使用し、以下に従って、ネームサービス用のクライアントのマクロを訂正します。

クライアントが、ネットワーク上の最初のクライアントである場合は、以下のようにします。

  1. dhtadm を使用してエントリを訂正します。

  2. 次に、サーバー上で以下のように入力します。


    /etc/init.d/dhcp stop,
/etc/rc3.d/S34dhcp start
    さらに、クライアントを再起動します。

    注 -

    クライアントに対して、ネームサービスの選択をサーバーが指定することはありません。サーバーは関連する情報を提供するだけです。クライアントが自己のネームサービスを選択します。

マクロの変更がクライアントに伝達されない場合

dhtadm を用いて、クライアントの 1 つまたは複数のマクロを変更しましたが、マシン上で変更が反映されません。たとえば、クライアントのルーターを変更しましたが、クライアントは依然として古いルーターを使用しています。

以下の情報を使用して、変更済みのクライアントのマクロが DHCP サーバー上に反映されないという問題を解決します。

問題

dhcptab テーブルに加えられた変更を読み込むための、DHCP サーバーの再初期化が行われていなかった。マクロ定義を変更するたびに、DHCP サーバーの再初期化を行う必要がある。

解決策: dhcpconfig に rescan オプションセットを使用します。あるいは以下に従います。

以下のようにして、DHCP サーバーの再初期化を行います。

  1. DHCP サーバーにスーパーユーザーでログインします。

  2. 以下のように入力します。


    /etc/init.d/dhcp stop

  3. 以下のように入力して、DHCP デーモンを再起動します。


    /etc/init.d/dhcp start