2013 年 8 月 21 日 - 機械翻訳について

その他のバージョン： PDF

| ライター翻訳版 (2008 年 5 月 29 日) | 英語版 (2005 年 10 月 26 日) | Feedback

概要

前提条件

要件

使用するコンポーネント

表記法

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 の場合だけです。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。ネットワークが稼働中の場合は、コマンドが及ぼす潜在的な影響を十分に理解しておく必要があります。

表記法

ドキュメント表記の詳細は、『シスコテクニカルティップスの表記法』を参照してください。

CNR のディレクトリ構造

UNIX システム

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 システム

Windows NT と Windows 2000 では、構造が類似しています。 C に CNR をインストールしたら: 、これですインストールディレクトリ駆動して下さい:

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 つのディレクトリに保存して、特定の読み取り専用ファイルにフラグを立てることができます。

ON ウィンドウは、そこにたった 1 プロセスです実行している: AICサーバエージェント 2.0。 Window NT では、これを制御するには Start > Settings > Control Panel > Services の順に選択します。

サーバステータスモニタ

サーバステータスモニタを使用すると、CNR 内の DNS、DHCP、および TFTP の各サーバのステータスを監視できます。このモニタには、指定したサーバの状態が表示されます。

サーバをサーバステータスモニタに追加するには、次の手順でサーバをステータスモニタにドラッグアンドドロップします。

CNR の GUI を起動する。
1. UNIX オペレーティングシステムでは、Xterm を起動して次の手順を実行します。
  1. xhost + コマンドを発行する。
  2. CNR サーバがホスティングされている UNIX システムに telnet する。
  3. 次のコマンドを発行します。
    - setenv TERM xterm
    - setenv DISPLAY your-local-ip-address:0.0
  4. 次のコマンドを発行して、GUI を起動します。
    - /opt/nwreg2/usrbin/ntwkreg &
      
      「注： & により、このウィンドウを他のコマンドに使用できます。
2. 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 のデバッグ設定

このデバッグ設定を使用すると、DHCP 問題のトラブルシューティングに必要な情報を収集できます。この情報は、ログファイルに保存されます。 CNR のデバッグ設定では、GUI と CLI（nrcmd）の両方が使用できます。

GUI を使用した DHCP のデバッグ設定

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 を使用した DHCP のデバッグ設定

デバッグ設定は CLI（nrcmd）でも行えます。

発行するコマンドの形式は次のようになります。

nrcmd> server server-type setDebug categories=level

サーバタイプ—疑わしいサーバ; このセクションのための例では、それは 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

例 1

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 の後に、不正な = 記号が余分に入力されています。

例 2

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 問題のトラブルシューティングが行えます。 DNS のデバッグレベルの設定には、GUI と CLI の両方が使用できます。

GUI を使用した DNS のデバッグ設定

GUI を使用した DNS のデバッグ設定は、次の手順で行います。

Server Manager で、デバッグオプションを設定するサーバを選択します。
Show properties をクリックします。
Properties ダイアログボックスの Advanced タブをクリックします。
Debug Settings（図 4 の赤い矢印）をクリックします。
図 4：DNS のデバッグレベルを設定するダイアログ
Debug settings ダイアログボックスで Enable debug にチェックマークを入れます。

Category フィールドに、表 2 に示されている設定の 1 つを入力します。

表 2：DNS のデバッグ設定の設定、レベル、および説明

サーバカテゴリ（DNS）	レベル	説明
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 を使用した DNS のデバッグ設定

CLI（nrcmd）でデバッグ設定を行えます。

発行するコマンドの形式は次のようになります。

nrcmd> server server-type setDebug categories=level

サーバタイプ—疑わしいサーバ; セクションのためのこの例では、それは 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 のデバッグ設定

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

設定に関する問題：クライアントが  IP アドレスを取得できない

CNR の DHCP サーバをケーブル環境で使用している場合に頻繁に発生する問題の 1 つとして、クライアント（ケーブルモデムとその背後の CPE）が IP アドレスを取得できないという問題があります。このような場合、ケーブルモデムは init(d) 状態のままになっています。この状況についての詳細は、『トラブルシューティング：uBR ケーブルモデムがオンラインにならない場合』を参照してください。この問題の発生原因としては、複数考えられます。このドキュメントでは、これ以降、それぞれの理由の詳細について説明しています。

DHCP DISCOVER パケットは CNR に到達しているか

CNR ログでは、デフォルトレベルでも、CNR でパケットが受信されたかどうかを確認するための情報が十分に提供されています。クライアントの Client Identifier（CID）の MAC アドレスが DHCPDISCOVER パケットに出現するかどうかをチェックできます。 CID では、左端のバイトがイーサネットの htype=1 を示します。このため、実際の MAC アドレスは右側の 6 バイト分です。デフォルトのロギングレベルの場合、Windows NT の C:\Program Files\Network Registrar\LOGS にある「name_dhcp_1_log」の部分は、次のようになります。


!--- Output suppressed.

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 にデバッグレベルが設定されているとパケットについての詳細な情報自体は提供されます。

CNR にクライアント用の適切なスコープがあるか

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.

クライアントにオファーされる IP アドレスを使用して設定されているホストが同じネットワーク上にあるかどうかを確認する

リースをオファーする前に、CNR ではオファー先の IP アドレスに対して PING を実行します。 CNR は、正常な応答を受信すると、ネットワーク上でアドレスが重複しないようにするため、このリースを無効にして、オファーする新しい IP アドレスを選択します。デフォルトでは、この動作はディセーブルになっていますが、GUI からスコープ別にイネーブルにできます。

Advanced タブを Scope > Properties の順に選択し、クリックして下さい; それからそれにチェックボックスを提供する前に PING アドレスを確認して下さい:

図 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

目次

関連するシスコ サポート コミュニティ ディスカッション

関連するシスコサポートコミュニティディスカッション