| 機械翻訳版 (2013 年 8 月 21 日) | 英語版 (2005 年 10 月 26 日) | 
フィードバック| 2008 年 5 月 29 日 - ライター翻訳版 |
| その他のバージョン： PDF | 機械翻訳版 (2013 年 8 月 21 日) | 英語版 (2005 年 10 月 26 日) | フィードバック |
概要
前提条件
要件
使用するコンポーネント
表記法
CNR のディレクトリ構造
UNIX システム
Windows システム
サーバ ステータス モニタ
DHCP のデバッグ設定
GUI を使用した DHCP のデバッグ設定
CLI を使用した DHCP のデバッグ設定
DNS のデバッグ設定
GUI を使用した DNS のデバッグ設定
CLI を使用した DNS のデバッグ設定
TFTP のデバッグ設定
設定に関する問題：クライアントが IP アドレスを取得できない
DHCP DISCOVER パケットが CNR に到達しているかどうかを確認する
CNR にクライアント用の適切なスコープがあるかどうかを確認する
スコープに空きアドレスがあるかどうかを確認する
オファーがクライアントに到達するかどうかを確認する
同じネットワーク上に同じスコープが設定されているサーバがある場合
クライアントにオファーされる IP アドレスを使用して設定されているホストが同じネットワーク上にあるかどうかを確認する
関連するシスコ サポート コミュニティ ディスカッション
関連情報
Data-over-Cable Service Interface Specifications（DOCSIS）では、DHCP での IP アドレスのネゴシエーションはケーブル モデムに任されています。Cisco Network Registrar（CNR）により、Domain Name System（DNS; ドメイン ネーム システム）および DHCP を包括的に管理する機能が提供されています。CNR では TFTP サーバの機能も提供されています。
DHCP ネゴシエーションは、IP データを転送するケーブル ネットワーク環境では共通の問題です。CNR でデバッグをイネーブルにすると、DHCP ネゴシエーションのトラブルシューティングが可能です。このドキュメントでは、CNR の機能の説明から開始して、その後で、デバッグをイネーブルにする方法を説明しています。最後に、ケーブル モデムがオンラインにならない状況や、ケーブル モデムの背後にある宅内装置（CPE）がインターネットに接続できない状況の一般的な例を紹介しています。
このドキュメントが適用されるのは CNR 5.0 です。
このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づくものです。
UNIX システム
Solaris
HP/UX
AIX
Windows NT
Windows 2000
注：UNIX システムで GUI インターフェイスを使用できるのは、Solaris の場合だけです。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。対象のネットワークが実稼働中である場合には、どのような作業についても、その潜在的な影響について確実に理解しておく必要があります。
ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。
UNIX では、次のディレクトリからディレクトリ構造が始まります。
/opt/nwreg2
このディレクトリには次のサブディレクトリが含まれています。
skyshark# ls -l total 18 drwxr-xr-x 2 root bin 1024 Mar 28 18:34 bin/ drwxr-xr-x 2 root bin 512 Mar 28 18:35 conf/ drwxr-xr-x 3 root bin 512 Mar 28 18:33 docs/ drwxr-xr-x 3 root bin 512 Mar 28 18:31 examples/ drwxr-xr-x 3 root bin 512 Mar 28 18:31 extensions/ drwxr-xr-x 3 root bin 1024 Mar 28 18:35 lib/ drwxr-xr-x 2 root bin 512 Mar 28 18:33 misc/ drwxr-xr-x 2 root bin 512 Apr 2 18:39 usrbin/ drwxr-xr-x 5 root bin 512 Mar 28 18:31 WebUI/
これらのサブディレクトリには、次のコンポーネントが含まれています。
bin：実行可能プログラム
conf：コンフィギュレーション ファイル
lib：実行可能ファイルで使用されるライブラリ
usrbin：GUI や nrcmd（Network Registrar Command、CNR のコマンドライン インターフェイス（CLI））を起動するサブディレクトリ
GUI の起動には、ntwkreg を発行します。CLI の起動には、nrcmd を発行します。
/opt/nwreg2/usrbin ディレクトリには次のファイルがあります。
skyshark# pwd /opt/nwreg2/usrbin skyshark# ls -l total 11422 -r-xr-xr-x 1 root bin 980 Mar 28 18:35 aicstatus* -r-xr-xr-x 1 root bin 365 Mar 28 18:34 cnrFailoverConfig* -r-xr-xr-x 1 root bin 179 Mar 28 18:34 mcdadmin* -r-xr-xr-x 1 root bin 180 Mar 28 18:35 mcdshadow* -r-xr-xr-x 1 root bin 385 Mar 28 18:34 nrcmd* -r-xr-xr-x 1 root bin 1986 Mar 28 18:35 ntwkreg*
データベースおよびログは、/var/nwreg2 ディレクトリにあります。これらのファイルには、書き込みアクセスが必要です。
/var/nwreg2 skyshark# ls -l total 6 drwxr-xr-x 9 root other 512 Mar 28 18:36 data/ drwxrwxrwt 3 root other 512 APR 16 09:07 logs/ drwxr-xr-x 2 root other 512 Mar 28 18:42 temp/
これらのサブディレクトリには、次のコンポーネントが含まれています。
data：データベース データとバックアップのファイルの場所
db：アクティブなデータベース
db.bak：データベースのコピー（このコピーは毎晩、サーバ時刻の 11:45 PM に作成されます。）
dns：キャッシュ ファイルおよび現在の権限ゾーン フィールドであり、サーバによって読み出されて、ゾーン転送でセカンダリに渡されます。
logs：ログ ファイルは、このディレクトリにあります。よくある間違いは、/opt/ のサブディレクトリを検索してしまうことです。ログは、サーバで書き込まれるため、書き込みアクセスがあるディレクトリに配置される必要があります。ログはトラブルシューテュイングには頻繁に使用され、このドキュメントでは最もよく使用するものです。
temp：AIC サーバ エージェントを稼働させるのに使用される、ロックされているテンポラリ ファイル。
UNIX では、稼働中の CNR に関連するプロセスがいくつかあります。ステータスをチェックするには、次のコマンドを実行します。
skyshark# /opt/nwreg2/usrbin/aicstatus Server Agent running (pid: 112) MCD lock manager running (pid: 118) MCD server running (pid: 116) DNS server running (pid: 119) DHCP server running (pid: 120)
各サーバ エージェントのインスタンスは 1 つだけ稼働させてください。
プロセスの停止と開始には、次のコマンドを発行します。
skyshark# /etc/init.d/aicservagt stop skyshark# /etc/init.d/aicservagt start # Starting AIC Server Agent for Network Registrar
Windows NT と Windows 2000 では、構造が類似しています。CNR が C: ドライブにインストールされている場合、インストール ディレクトリは次の場所になります。
C:\Program Files\Network Registrar\
このディレクトリには次のファイルとサブディレクトリが含まれています。
C:\Program Files\Network Registrar> dir
Volume in drive C is W2K
Volume Serial Number is D439-C697
Directory of C:\Program Files\Network Registrar
01/24/2001 03:22p <DIR> .
01/24/2001 03:22p <DIR> ..
01/24/2001 03:22p <DIR> BIN
04/14/2001 11:46p <DIR> DATA
01/24/2001 03:23p 15,037 DeIsL1.isu
01/24/2001 03:22p <DIR> DOCS
01/24/2001 03:22p <DIR> EXAMPLES
01/24/2001 03:21p <DIR> EXTENSIONS
01/24/2001 03:22p <DIR> lib
04/09/2001 08:38a <DIR> LOGS
01/24/2001 03:22p <DIR> MISC
12/25/2000 05:12p 2,083 README.TXT
01/24/2001 03:21p <DIR> TEMP
12/25/2000 10:12p 58,880 unregistrar.dll
01/24/2001 03:21p <DIR> WebUI
3 File(s) 76,000 bytes
12 Dir(s) 1,426,918,400 bytes free
NT のディレクトリ構造は Unix とは異なっています。NT は、この点においてさらに柔軟性があり、すべてのファイルを 1 つのディレクトリに保存して、特定の読み取り専用ファイルにフラグを立てることができます。
Windows の場合、実行されるプロセスは、AIC Server Agent 2.0 だけです。Window NT では、これを制御するには Start > Settings > Control Panel > Services の順に選択します。
サーバ ステータス モニタを使用すると、CNR 内の DNS、DHCP、および TFTP の各サーバのステータスを監視できます。このモニタには、指定したサーバの状態が表示されます。
サーバをサーバ ステータス モニタに追加するには、次の手順でサーバをステータス モニタにドラッグ アンド ドロップします。
CNR の GUI を起動する。
UNIX オペレーティング システムでは、Xterm を起動して次の手順を実行します。
xhost + コマンドを発行する。
CNR サーバがホスティングされている UNIX システムに telnet する。
次のコマンドを発行する。
setenv TERM xterm
setenv DISPLAY your-local-ip-address:0.0
次のコマンドを発行して、GUI を起動します。
/opt/nwreg2/usrbin/ntwkreg &
注：& により、このウィンドウを他のコマンドに使用できます。
Windows オペレーティング システムでは、Start > Programs > Network Registrar の順に選択します。
GUI を起動すると、ユーザ名およびパスワードを入力するようにシステムから要求されます。CNR の最初のインストールでは、ユーザ名に admin、パスワードに changeme が使用されています。
注意：このパスワードを変更してください。
監視対象のクラスタの横にある + 記号をクリックします。
図 1 のような画面が表示されます。
図 1：CNR 5.0.1 の Server Manager ウィンドウ
監視するサーバを右クリックして、Add to Status Monitor を選択します。監視する各サーバに対して、この操作を実行します。
Status Monitor ウィンドウには、稼働中のサーバの横に緑色のライトが表示されています。図 2 では、クラスタ 172.16.30.3 の DNS サーバと DHCP サーバはアクティブですが、同じクラスタの TFTP サーバはアクティブではありません（赤色のライトが表示されています）。
図 2：CNR 5.0.1 の Status Monitor ウィンドウ
注：Status Monitor ウィンドウからサーバを削除するには、サーバを右クリックして Remove を選択します。
このデバッグ設定を使用すると、DHCP 問題のトラブルシューティングに必要な情報を収集できます。この情報は、ログ ファイルに保存されます。CNR のデバッグ設定では、GUI と CLI（nrcmd）の両方が使用できます。
GUI を使用した DHCP のデバッグ設定では、次の手順を使用します。
Server Manager で、デバッグ オプションを設定するサーバを選択します。
Show properties をクリックします。
Properties ダイアログ ボックスの Advanced タブをクリックします。
Debug Settings（図 3 の赤い矢印）をクリックします。
図 3：DHCP のデバッグ レベルを設定するダイアログ
Debug settings ダイアログ ボックスで Enable debug にチェックマークを入れます。
Category フィールドに、表 1 に示されている設定の 1 つを入力します。
表 1：DHCP のデバッグ設定の設定、レベル、および説明| サーバ カテゴリ （DHCP） |
レベル | 説明 |
|---|---|---|
|
VX= |
1 |
着信および発信の詳細パケット トレース |
|
KP= |
1-9 |
Dynamic DNS パケット トレースおよび Lightweight Directory Access Protocol（LDAP）のすべてのメッセージに関する完全な詳細（値属性を含む） |
|
Q= |
1-9 |
サービス クラス（CoS）のトレース |
|
Y= |
1 |
log-failover-detail ログ設定 |
|
Y= |
2 |
フェールオーバーに関する中程度の詳細 |
|
Y= |
3 |
フォーマット済みフェールオーバー パケットポール パケットは含まれません。VX=1 の場合と同じ出力ですが、フェールオーバー パケットだけが対象です。 |
|
Y= |
4 |
ポール パケットを含むフォーマット済みフェールオーバー パケット |
|
A-LZ-Z= |
9 |
すべての DHCP ロギング |
MLOG オプション ボタンをクリックします。これにより、出力が適切なログ ファイルに出力されます。
Debug settings ダイアログ ボックスで OK をクリックし、次に Properties ダイアログ ボックスで OK をクリックします。
デバッグ設定は CLI（nrcmd）でも行えます。
発行するコマンドの形式は次のようになります。
nrcmd> server server-type setDebug categories=level
server-type：対象のサーバで、このセクションの例では dhcp。
categories：表 1 のサーバ カテゴリ（DHCP）列に対応。
level：表 1 のレベル列からの数値の 1 つで categories に対応。
必要な引数（変数）がすべて指定されていない場合は、次のメッセージが表示されます。
nrcmd> dhcp setDebug 310 Too few arguments - usage: server <server> setDebug <categories>=<level>..
デバッグ設定をすべて無効にするには、unsetDebug コマンドを発行します。
nrcmd> server dhcp unsetDebug 100 OK
DHCP サーバのデバッグ設定を、着信および発信の詳細パケット トレース（VX=1）に設定するには、次のコマンドを発行します。
nrcmd> server dhcp setDebug VX=1 100 OK
注：100 OK メッセージは、コマンドが受け付けられたことを示しています。何らかの失敗をした場合は、次に類したメッセージが表示されます。
nrcmd> server dhcp setDebug= vx=1 306 Unknown command - dhcp method 'setDebugs='
このエラーでは、setDebug の後に、不正な = 記号が余分に入力されています。
DHCP サーバのデバッグ設定を、最も詳細な DHCP ロギングに設定するには、次のコマンドを発行します。
nrcmd> server dhcp setDebug A-LN-Z=9 100 OK
CLI で、表 1、表 2、表 3 で指定されているものよりも高レベルな数字が受け付けられる場合があります。このような高デバッグ レベルが受け付けられても、これらの表で指定されているよりも詳細な情報が提供されるわけではありません。
この例では、レベルは 100 に設定されており、コマンドが受け付けられていますが、ログに出力される詳細はレベル 9 のものと同じです。
nrcmd> dhcp setDebug A-LN-Z=100 100 OK
DNS のデバッグ設定を使用して、DNS 問題のトラブルシューティングが行えます。DNS のデバッグ レベルの設定には、GUI と CLI の両方が使用できます。
GUI を使用した DNS のデバッグ設定は、次の手順で行います。
Server Manager で、デバッグ オプションを設定するサーバを選択します。
Show properties をクリックします。
Properties ダイアログ ボックスの Advanced タブをクリックします。
Debug Settings（図 4 の赤い矢印）をクリックします。
図 4：DNS のデバッグ レベルを設定するダイアログ
Debug settings ダイアログ ボックスで Enable debug にチェックマークを入れます。
Category フィールドに、表 2 に示されている設定の 1 つを入力します。
表 2：DNS のデバッグ設定の設定、レベル、および説明| サーバ カテゴリ （DHCP） |
レベル | 説明 |
|---|---|---|
|
D |
基本 DNS トレース |
|
|
1 |
失敗、エラー、不正な設定、いくつかの設定の詳細 |
|
|
2 |
重大ではないエラー（応答、転送、再転送の形式エラー） |
|
|
3 |
復旧可能な失敗、不正なネームサーバ、設定スレーブ モード/XFER クライアントのメジャー状態の変化 |
|
|
4 |
各レコードをパックする Incremental transfer（IXFR）サーバ、IXFR/transfer zone contents（AXFR）およびゾーン転送 |
|
|
5 |
名前別のバックグラウンド ゾーン ロードの完了 |
|
|
6 |
ゾーン履歴トリミングのスケジュールと実行完了パケット別の XFER クライアント ロギング |
|
|
U |
ダイナミック アップデート トレース |
|
|
1 |
エラー、失敗、非成功応答 |
|
|
2 |
パケット別ロギング ソース、ゾーン、ld、prereq、およびアップデート リソース レコードのカウント |
|
|
3 |
パケット別着信パケット ロギング、パケット/要求検証エラー |
|
|
4 |
パケット別発信パケット基本ロギング |
|
|
5 |
ゾーンでの着信 dup、ゾーンでの新規着信 req、ゾーンに対する通知要求への XFER クライアントの対応 |
|
|
P |
パケット |
|
|
1 |
基本パケット検証後のクエリー パケット別 |
|
|
2 |
着信パケット別、検証前ロギング |
|
|
3 |
発信パケット別、応答データ ロギング |
|
|
DNUP |
すべての DNS ロギング |
|
|
A-Z |
10 |
すべての内部 DNS サーバ、データベース、ライブラリ サブシステムに対する、すべての着信/発信パケット、要求、転送メッセージ、ダイナミック アップデート、通知メッセージ、差分ゾーン転送と完全ゾーン転送、および数多くの詳細機能固有の決定ツリー情報メッセージ |
MLOG オプション ボタンをクリックします。これにより、出力が適切なログ ファイルに出力されます。
Debug settings ダイアログ ボックスで OK をクリックし、次に Properties ダイアログ ボックスで OK をクリックします。
CLI（nrcmd）でデバッグ設定を行えます。
発行するコマンドの形式は次のようになります。
nrcmd> server server-type setDebug categories=level
server-type：対象のサーバ。このセクションの例では dns です。
categories：表 2 のサーバ カテゴリ（DNS）列に対応。
level：categories に対応する表 2 のレベル列からのいずれかの数値。
デバッグ設定を無効にするには、unsetDebug コマンドを発行します。これにより、すべての設定が無効になります。
nrcmd> server dns unsetDebug 100 OK
nrcmd> server dns setDebug D=5 100 OK nrcmd> server dns setDebug AZ=10 100 OK
TFTP サーバに問題がある場合は、CLI を使用してデバッグ レベルを設定します。この場合、GUI は使用できません。表 3 に、TFTP サーバの CNR に設定できるデバッグ レベルを示します。
表 3：TFTP サーバのデバッグ設定の設定、レベル、および説明
| サーバ カテゴリ （TFTP） |
レベル | 説明 |
|---|---|---|
|
C |
1-3 |
サーバの設定 |
|
D |
1-3 |
統計情報 |
|
E |
1-3 |
CSCR 拡張オブジェクト |
|
F |
1-3 |
ファイル処理 |
|
P |
1-3 |
パケット処理 |
|
S |
1-3 |
TFTP セッション処理 |
|
T |
1-3 |
タイマー処理 |
上記の Level は、次のデバッグ タイプに対応しています。
1：予期しない条件
2：詳細情報
3：可能な各デバッグ
TFTP CNR サーバで、最も詳細なサーバ設定ロギング用にデバッグ設定を行うには、次のコマンドを発行します。
nrcmd> server tftp setDebug C=3 100 OK
注：100 OK メッセージが表示されない場合、このコマンドは CNR で受け付けられていません。
デバッグ設定をすべて無効にするには、unsetDebug コマンドを発行します。
nrcmd> server tftp unsetDebug 100 OK
CNR の DHCP サーバをケーブル環境で使用している場合に頻繁に発生する問題の 1 つとして、クライアント（ケーブル モデムとその背後の CPE）が IP アドレスを取得できないという問題があります。このような場合、ケーブル モデムは init(d) 状態のままになっています。この状況についての詳細は、『トラブルシューティング：uBR ケーブル モデムがオンラインにならない場合』を参照してください。この問題の発生原因としては、複数考えられます。このドキュメントでは、これ以降、それぞれの理由の詳細について説明しています。
CNR ログでは、デフォルト レベルでも、CNR でパケットが受信されたかどうかを確認するための情報が十分に提供されています。クライアントの Client Identifier（CID）の MAC アドレスが DHCPDISCOVER パケットに出現するかどうかをチェックできます。CID では、左端のバイトがイーサネットの htype=1 を示します。このため、実際の MAC アドレスは右側の 6 バイト分です。デフォルトのロギング レベルの場合、Windows NT の C:\Program Files\Network Registrar\LOGS にある「name_dhcp_1_log」の部分は、次のようになります。
!--- 出力を省略。
08/24/2000 17:40:09 name/dhcp/1 Activity Server 0 04619 Server received
a DHCPDISCOVER packet 'R1' from:
Host: 'dell-port-pc' CID: 01:00:10:a4:ff:61:8e
with IP source address: 0.0.0.0 via: Interface 10.200.68.200,
1 in use.
この出力には、DHCPDISCOVER パケットが受信されたことが示されています。
次に、さらに詳細なロギングによる同じ出力を示します。ここでは、デバッグ レベルとして VX=1 が示されています。
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
----- RECEIVED -- R1 -----
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
-> port = 68 received from = 0.0.0.0
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
-> packet length = 300
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
-> op = 1 request
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
-> htype = 1 ethernet hlen = 6
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
-> hops = 0
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
-> xid = 0xec9e secs = 0 flags = 0x0
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
-> ciaddr = 0.0.0.0
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
-> yiaddr = 0.0.0.0
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
-> siaddr = 0.0.0.0
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
-> giaddr = 0.0.0.0
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
-> chaddr = 0:10:a4:ff:61:8e
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
-> dhcp-message-type = 1 discover
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
-> dhcp-client-identifier =1 0 16 164 255 97 142
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
-> ethernet? = 0:10:a4:ff:61:8e
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
-> dhcp-requested-address = 10.200.68.100
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
-> host-name = "dell-port-PC"
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
-> end
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
-> sname = ""
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
-> file = ""
08/24/2000 17:45:19 name/dhcp/1 Info Protocol 0 04935 R1:
----- END OF RECEIVED -- R1 -----
上記の出力からわかるように、DHCPDISCOVER に関する同じ情報を取得していますが、デバッグ レベルが VX=1 に設定されているため、パケット自体に関するより詳細な情報が示されています。
DHCP では、IP のサブネット マスクの概念は認識されません。CNR では DHCPDISCOVER を受信すると、GIADDR フィールドか hops フィールドを確認します。これらのフィールドが空白または 0 の場合、CNR ではその要求がローカル ネットワークから転送されたものと見なされます。CNR は、そのパケットを受信したインターフェイスの IP アドレスを確認し、その IP アドレスを使用してスコープを選択します。GIADDR フィールドが空白ではない場合、DHCPDISCOVER は DHCP リレー エージェントにより転送されています。通常、DHCP リレー エージェントは ip helper-address コマンドで Cisco のルータに設定されています。この場合、CNR では、スコープの選択に GIADDR フィールドにある IP アドレスが使用されます。この IP アドレスは、クライアントのブロードキャスト要求を受信したルータ インターフェイスのものです。いずれの場合も、要求内にサブネット マスク情報がないため、CNR では、設定されているすべてのスコープの中から最も一致しているスコープが選択されます。
10.0.0.0/8 と設定した CNR を想定します。これは、10.200.68.200 からの要求に対しては適切です。10.200.0.0/16 や 10.200.68.0/24 のように、より限定的に設定すると、最も長いマスクのアドレスが選択されます。割り当てられているネットワークと同じサブネット マスクでスコープを作成するのが、より適切です。この理由は、スコープのサブネット マスクはクライアントに割り当てられるサブネット マスクであり、ネットワーク セグメントでは、すべてのホストが同じサブネット マスクを共有する必要があるためです。DHCP オプションの get-subnet-mask-from-policy を使用して、スコープで定義されているサブネット マスクとは異なるサブネット マスクをクライアントに割り当てることができます。次の例では、CNR にはスコープがないため、要求が破棄されています。
08/24/2000 17:45:19 name/dhcp/1 Warning Protocol 0 04663
Received DHCPDISCOVER packet but found no Scopes
for source network = '10.200.68.200'. Dropping packet.
次の出力例には、リレー エージェントによって転送されたパケットが示されています。hops フィールドおよび GIADDR フィールドの値を確認して、前述の例の値と比較します。CNR には 10.200.71.1 に適したスコープがないため、結果は同じになります。
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
----- RECEIVED -- R61 -----
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
-> port = 67 received from = 10.200.71.1
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
-> packet length = 296
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
-> op = 1 request
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
-> htype = 1 ethernet hlen = 6
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
-> hops = 1
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
-> xid = 0x2127 secs = 0 flags = 0x8000 broadcast
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
-> ciaddr = 0.0.0.0
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
-> yiaddr = 0.0.0.0
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
-> siaddr = 0.0.0.0
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
-> giaddr = 10.200.71.1
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
-> chaddr = 0:1:96:59:47:c1
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
-> dhcp-message-type = 1 discover
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
-> dhcp-max-message-size = 1152
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
-> dhcp-client-identifier = 1 0 1 150 89 71 193
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
-> ethernet? = 0:1:96:59:47:c1
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
-> dhcp-parameter-request-list = 20
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
-> 1 subnet-mask
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
-> 2 time-offset
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
-> 4 time-servers
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
-> 66 tftp-server
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
-> 128 mcns-sec-server
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
-> 3 routers
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
-> 7 log-servers
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
-> 67 boot-file
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
-> dhcp-class-identifier = "docsis1.0"
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
-> dhcp-option-overload = 3
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
-> relay-agent-info = 1 4 128 6 0 9 2 6 0 1 150 89 71 193
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
->
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
->
08/24/2000 18:11:23 name/dhcp/1 Info Protocol 0 04935 R61:
----- END OF RECEIVED -- R61 -----
08/24/2000 18:11:23 name/dhcp/1 Warning Protocol 0 04663
Received DHCPDISCOVER packet but found no Scopes
for source network = '10.200.71.1'. Dropping packet.
アドレスのプールが非常に小さくなるようにスコープを設定することができます。そのような場合、一般に、プール内のアドレスが使い尽くされる可能性があります。次の出力例には、クライアントが IP アドレスを取得しようとしたけれども、スコープではプールのすべてのアドレスがすでに使用されている場合のデバッグ メッセージが示されています。
08/24/2000 19:14:26 name/dhcp/1 Warning Server 0 04440
No more leases are AVAILABLE, unable to respond
to DHCP DISCOVER Request: R9 = from Client: Host:
dell-port-PC CID: 01:00:10:a4:ff:61:8e in Network:
10.200.68.0-255.255.255.0 via: Interface 10.200.68.200
CNR がスコープを選択してオファー パケットを作成すると、この情報はクライアントに送信される必要があります。
注：パケットの宛先がリレー エージェントの場合は、CNR マシンに GIADDR へのルートが含まれているかどうかを確認してください。
このような例の場合は、CNR マシン 10.200.71.1 から正常に PING を実行できるかどうかを確認します。
リースがオファーされた後、このリースがネットワークの実際の IP アドレスになる前には、いくつかの手順があることを思い起こしてください。
サーバからクライアントへの 1 つあるいは複数の DHCPREQUEST と 1 つあるいは複数の DHCPOFFER が、同じサーバで確認されるはずです。これらは DHCP オプションの要求と取得に使用されるものです。
サーバからクライアントへの最後の DHCPACK で DHCP プロセスが終了しているのが確認されるはずです。
DHCPOFFER だけが検出された場合は、パケットがクライアントに届いているかどうかと、後続の DHCPREQUEST がサーバに戻されているかどうかを確認してください。
次に、リースが付与されたことを示すログ エントリを示します。この情報から、クライアントの MAC アドレス、割り当てられている IP アドレス、およびリースの有効期限がわかります。
08/24/2000 13:13:15 name/dhcp/1 Activity Protocol 0 04994 10.200.68.200
Lease granted to Host: dell-port-PC CID: 01:00:10:a4:ff:61:8e
packet 'R207' until Thu, 31 Aug 2000 13:13:15 +0200. 320 ms.
このような場合、両方のサーバで DHCPDISCOVER が受信されてオファーが作成されますが、クライアントが選択するのは 1 つだけです。ここでは、dhcp-server-identifier に、どちらのサーバからオファーを受け付けているかが示されています。相手側のサーバで、オファーしたのと同じ IP アドレスの DHCPREQUEST が検出されていながら、dhcp-server-identifier にはそれ以外のサーバが示されている場合、このサーバでは、アドレスが重複しないようにリースを無効にします。
次の出力例の最後の行に、この無効化が示されています。
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
----- RECEIVED -- R7 -----
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
-> port = 68 received from = 0.0.0.0
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
-> packet length = 300
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
-> op = 1 request
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
-> htype = 1 ethernet hlen =3D 6
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
-> hops = 0
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
-> xid =0xddaadeaa secs = 0 flags = 0x0
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
-> ciaddr = 0.0.0.0
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
-> yiaddr = 0.0.0.0
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
-> siaddr = 0.0.0.0
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
-> giaddr = 0.0.0.0
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
-> chaddr = 0:10:a4:ff:61:8e
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
-> dhcp-message-type = 3 request
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
-> dhcp-client-identifier = 1 0 16 164 255 97 142
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
-> ethernet? = 0:10:a4:ff:61:8e
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
-> dhcp-requested-address = 10.200.68.201
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
-> dhcp-server-identifier = 10.200.68.17
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
-> hostname = "dell-port-PC"
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
-> dhcp-parameter-request-list = 20
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
-> 1 subnet-mask
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
-> 3 routers
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
-> 15 domain-name
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
-> 6 domain-name-servers
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
-> 44 netbios-name-servers
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
-> 46 netbios-node-type
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
-> 47 netbios-scope
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
-> vendor-encapsulated-options = 55 2 0 0
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
-> end
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
-> sname = ""
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
-> file = ""
09/01/2000 12:21:05 name/dhcp/1 Info Protocol 0 04935 R7:
----- END OF RECEIVED -- R7 -----
09/01/2000 12:21:05 name/dhcp/1 Activity Protocol 0 04993 10.200.68.201
Lease offered to Host: dell-port-PC CID: 01:00:10:a4:ff:61:8e
packet 'R5' until Fri, 01 Sep 2000 12:23:05 +0200. 150 ms.
09/01/2000 12:21:05 name/dhcp/1 Error Protocol 0 04684 Client:
'Host: dell-port-PC CID: 01:00:10:a4:ff:61:8e ' sent a
REQUEST for Lease: '10.200.68.201' to Server: '10.200.68.17'
instead of us. Marking Lease UNAVAILABLE
異なる IP アドレスの DHCPREQUEST が検出されると、サーバでは、この DHCPREQUEST をログに記録します。この出力例では、相手側のサーバ 10.200.68.17 が 10.200.68.201 をオファーしています。
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
----- RECEIVED -- R3 -----
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
-> port = 68 received from = 0.0.0.0
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
-> packet length = 300
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
-> op = 1 request
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
-> htype = 1 ethernet hlen = 6
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
-> hops = 0
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
-> xid = 0x8a7d8b7d secs = 0 flags = 0x0
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
-> ciaddr = 0.0.0.0
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
-> yiaddr = 0.0.0.0
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
-> siaddr = 0.0.0.0
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
-> giaddr = 0.0.0.0
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
-> chaddr = 0:10:a4:ff:61:8e
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
-> dhcp-message-type = 3 request
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
-> dhcp-client-identifier = 1 0 16 164 255 97 142
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
-> ethernet? = 0:10:a4:ff:61:8e
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
-> dhcp-requested-address = 10.200.68.201
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
-> dhcp-server-identifier = 10.200.68.17
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
-> hostname = "dell-port-PC"
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
-> dhcp-parameter-request-list = 20
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
-> 1 subnet-mask
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
-> 3 routers
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
-> 15 domain-name
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
-> 6 domain-name-servers
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
-> 44 netbios-name-servers
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
-> 46 netbios-node-type
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
-> 47 netbios-scope
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
-> vendor-encapsulated-options = 55 2 0 0
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
-> end
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
-> sname = ""
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
-> file = ""
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 04935 R3:
----- END OF RECEIVED -- R3 -----
09/01/2000 12:19:33 name/dhcp/1 Info Protocol 0 05005 10.200.68.202
Offer to Host: dell-port-PC CID: 1:00:10:a4:ff:61:8e packet
'R3' was rejected in favor of an offer from another server.
リースをオファーする前に、CNR ではオファー先の IP アドレスに対して PING を実行します。CNR は、正常な応答を受信すると、ネットワーク上でアドレスが重複しないようにするため、このリースを無効にして、オファーする新しい IP アドレスを選択します。デフォルトでは、この動作はディセーブルになっていますが、GUI からスコープ別にイネーブルにできます。
Scope > Properties の順に選択し、Advanced タブをクリックしてから、Ping address before offering it チェックボックスにチェックマークを入れます。
図 5：Scope ダイアログ ボックス
逆に、CLI でコマンドを入力することもできます。
nrcmd> scope name enable ping-clients
スコープ UBR7246_C4_0 で、オファーされる前にアドレスに PING する場合、次のコマンドを発行します。
nrcmd> scope UBR7246_C4_0 enable ping-clients 100 OK ping-clients=enabled
次の出力例には、この状況でのデバッグが示されています。
09/01/2000 12:52:26 name/dhcp/1 Warning Protocol 0 0467
Unexpected ping reply received for AVAILABLE lease
'10.200.68.201' - it is being marked UNAVAILABLE
シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。