Cisco Prime Network Registrar 11.0 アドミニストレーションガイド

サーバーの管理

ccm-admin ロールの server-management サブロールが割り当てられている場合、Cisco Prime Network Registrar サーバーを次のように管理できます。

Start - データベースをロードし、サーバーを起動します。
Stop - サーバーを停止します。
Reload - サーバーを停止し、再起動します。（保護された RR の更新であっても、すべての RR 更新に対してサーバーをリロードする必要はありません。詳細については、『Cisco Prime Network Registrar 11.0 DHCP ユーザーガイド』の「DNS アップデートの管理」の章を参照してください）。
Check statistics - 統計の表示を参照してください。
View logs - ログの検索を参照してください。
Manage interfaces - サーバーインターフェイスを管理する方法については、特定のプロトコルのページを参照してください。

サーバーの起動と停止は説明不要です。サーバーをリロードすると、Cisco Prime Network Registrar は、3 つの手順を実行します。つまり、サーバーを停止し、設定データをロードし、サーバーを再起動します。サーバーをリロードした後にのみ、設定の変更が使用されます。

（注）

CDNS、DNS、DHCP、および SNMP サーバーはデフォルトで有効になっており、リブート時に開始されます。TFTP サーバーは、デフォルトでは有効になっていず、リブート時に起動しません。これを変更するには、CLI で [server ] type enable または disable start-on-reboot を使用します。

（注）

DHCP、DNS、または TFTP サーバーの exit-on-stop 属性が有効になっている場合、属性が無効になっている間は、最後の起動（リロード）からの統計情報とスコープ使用率のデータのみが報告され、リロード全体の情報が表示されます。

ローカル基本または詳細とリージョン Web UI

ユーザーのロールに応じて、次の方法でプロトコルサーバーを管理できます。

Local or regional cluster administrator - [Operate ] メニューから [サーバーの管理（Manage Servers）] を選択して、[サーバーの管理（Manage Servers））] ページを開きます。
サーバー管理へのローカルおよびリージョンクラスタ Web UI アクセスは同じですが、使用可能な機能が異なります。リージョン管理者として、リージョン CCM サーバーとサーバーエージェントの状態と正常性を確認できます。ただし、統計、ログ、またはインターフェイスを停止、開始、リロード、または表示することはできません。

ローカルクラスタで、DHCP、DNS、CDNS、TFTP、または SNMP サーバーを管理するには、[サーバーの管理（Manage Servers）] ペインでサーバーを選択し、次のいずれかを実行します。
- [統計（Statistics）] タブをクリックして、サーバーの統計を表示します。（統計の表示を参照してください）。
- [View Log] 列の [Logs] タブをクリックして、サーバーのログメッセージを表示します。（ログの検索を参照してください）。
- [サーバーの起動（Start Server）] ボタンをクリックして、サーバーを起動します。
- [サーバーの停止（Stop Server）] ボタンをクリックして、サーバーを停止します。
- [サーバーの再起動（Restart Server）] ボタンをクリックして、サーバーを再起動します。

Local cluster DNS administrator - [Deploy ] メニューから [DNS Server ] を選択して、[DNS 権威サーバーの管理（Manage DNS Authoritative Server））] ページを開きます。
統計、起動ログ、ログ、HA DNS サーバーステータス、サーバーの起動、サーバーの停止、およびサーバーの再起動機能のほかに、[コマンド（Commands）] ボタンをクリックして [DNS コマンド（DNS Commands）] ダイアログボックスを開くと、その他の機能を実行することもできます。

サーバーコマンドの機能は、次のとおりです。
- すべてのゾーン転送の強制（『Cisco PrimeNetwork Registrar 11.0 権限のあるキャッシュ DNS ユーザーガイド』の「ゾーン転送の有効化」の項を参照） - [実行（Run）] アイコンをクリックします。これは、CLI の dns forceXfer secondary と同じです。
- すべてのゾーンのスカベンジング（『Cisco Prime Network Registrar 11.0 DHCP ユーザーガイド』の「動的レコードのスカベンジング」の項を参照） - [実行（Run）] アイコンをクリックします。これは、CLI での dns scavenge と同じです。

Local cluster Caching DNS server— [Deploy ] メニューから [CDNS Server ] を選択して、[DNS キャッシングサーバーの管理（Manage DNS Caching Server））] ページを開きます。
統計、起動ログ、ログ、サーバーの起動、サーバーの停止、およびサーバーの再起動機能のほかに、[コマンド（Commands）] ボタンをクリックして [DNS コマンド（DNS Commands）] ダイアログボックスを開くと、その他の機能を実行することもできます。

詳細およびエキスパートモードでは、キャッシング CDNS キャッシュをフラッシュし、リソースレコードをフラッシュできます。コマンドを実行するには、[コマンド（Commands）] ボタンをクリックします。

Local cluster DHCP administrator - [Deploy] メニューの [DHCP サーバー（Server）] をクリックして、[DHCP サーバーの管理（Manage DHCP Server））] ページを開きます。
統計、起動ログ、ログ、サーバーの起動、サーバーの停止、およびサーバーの再起動機能のほかに、[コマンド（Commands）] ボタンをクリックして [DHCP サーバーコマンド（DHCP Server Commands）] ダイアログボックスを開くと、その他の機能を実行することもできます。

このページには、制限 ID を使用したリース取得機能が用意されています。これにより、共通の制限識別子を使用して関連付けられているクライアントを検索できます（『Cisco Prime Network Registrar 11.0 DHCP ユーザーガイド』の「管理オプション 82 の制限」を参照）。[IP アドレス（IP Address）] フィールドに、現在アクティブなリースの IP アドレスを少なくとも 1 つ入力して、[実行（Run）] アイコンをクリックします。また、制限 ID 自体を nn: nn: nn の形式で入力するか、文字列（" nnnn" ）として入力することもできます。その場合は、IP アドレスが検索対象のネットワークになります。この機能は、CLI の dhcp limitationList ipaddress [limitation-id] show と同じです。

CLI コマンド

CLI では、リージョンクラスタは CCM サーバー管理のみを許可します。

サーバーを起動するには、server type start を使用します（または単に type start 、たとえば、dhcp start ）。
サーバーを停止するには、server type stop を使用します（または単に type stop 、たとえば、dhcp stop ）。サーバーを停止する場合は、まず、save コマンドを使用して保存することをお勧めします。
サーバーをリロードするには、server type reload を使用します（または単に type reload 、たとえば、dhcp reload ）。Cisco Prime Network Registrar は、選択したサーバーを停止し、設定データをロードしてから、サーバーを再起動します。
サーバーの属性を設定または表示するには、[server ] type set 属性= 値または [server ]type show を使用します。次に例を示します。
```
nrcmd> ccm set ipaddr=192.168.50.10
```

反復タスクのスケジューリング

ローカルクラスタ Web UI の基本および詳細ユーザーモードでは、多数の反復タスクをスケジュールできます。タスクは、次のとおりです。

DHCP サーバーをリロードします。
DNS サーバーをリロードします。
キャッシング DNS サーバーをリロードします。
DHCP フェールオーバーサーバーペアの同期：
- メイン DHCP サーバーをリロードします。
- フェールオーバー設定をバックアップ DHCP サーバーに同期させます。
- バックアップ DHCP サーバーをリロードします。
高可用性（HA）DNS サーバーペアの同期：
- メイン DNS サーバーをリロードします。
- HA DNS 設定をバックアップ DNS サーバーに同期させます。
- バックアップ DNS サーバーをリロードします。
ゾーン分散マップの同期：
- プライマリ DNS サーバーまたは HA メインサーバーをリロードします。
- ゾーン分散マップを同期します。
- バックアップ HA DNS サーバーをリロードします（設定されている場合）。
- セカンダリ DNS サーバーをリロードします。
DNS 更新マップの同期：
- DNS 更新マップを DHCP サーバーと DNS サーバーに同期します。
- ローカルサーバーとリモートサーバーをリロードします。

ローカル基本または詳細 Web UI

これらの反復サーバータスクを 1 つ以上セットアップするには、次の手順を実行します。

手順

ステップ 1

Operate メニューから、[サーバー（Servers）] サブメニューの Schedule Tasks を選択して、[スケジュールされたタスクの一覧表示/追加（List/Add Scheduled Tasks）] ページを開きます。

ステップ 2

左側の [スケジュールされたタスク（Scheduled Tasks）] ペインの [スケジュールされたタスクの追加（Add Scheduled Task）] アイコンをクリックして、[スケジュールされたタスクの追加（Add Scheduled Task）] ページを開きます。

ステップ 3

適切なフィールドに値を入力します。

スケジュールされたタスクの名前。これは、任意の識別テキスト文字列にすることができます。
次のように、使用可能なタスクタイプのリストからプルダウンします。
- dhcp-reload ：DHCP サーバーをリロードします。
- dns-reload ：DNS サーバーをリロードします。
- cdns-reload ：キャッシング DNS サーバーをリロードします。
- sync-dhcp-pair ：DHCP フェールオーバーサーバーペアを同期し、サーバーをリロードします。
- sync-dns-pair ：HA DNS フェールオーバーサーバーペアを同期し、サーバーをリロードします。
- sync-zd-map ：ゾーン分散マップを同期し、サーバーをリロードします。
- sync-dns-update-map ：DNS 更新マップを同期し、サーバーをリロードします。
[Schedule Interval] フィールドに、15m や 4w2d など、スケジュールされたタスクの時間間隔を入力します。

ステップ 4

Add Scheduled Task をクリックします。

ステップ 5

[スケジュールされたタスクの一覧表示/追加（List/Add Scheduled Tasks）] ページのタスクの名前をクリックした場合、[スケジュール済みタスクの編集（Edit Scheduled Task）] ページで、タスクの実行中に発生した最後のステータスまたは最後のエラー（存在する場合）のリストを（[タスクステータス（Task Status）] セクションで）確認できます。Run Now をクリックして、タスクを今すぐ実行します。

（注）

HA DNS サーバーがパートナーと通信する前に HA が有効になっている場合、DNS サーバーの起動とバックグラウンドのロードが遅くなります。DNS サーバーをリロードまたは再起動する前に、HA DNS サーバーがパートナーと通信できるようにする必要があります。

CLI コマンド

task コマンドにより、スケジュール済みタスクオブジェクトを設定できます。これらのオブジェクトにより、定期的な操作を自動的に実行できます。

スケジュール済みタスクを作成するには、task name create task-type interval [sync-obj] [attribute=value] を使用します。task-type により、スケジュールするタスクのタイプを制御できます。使用可能なタスクタイプは、dhcp-reload、dns-reload、cdns-reload、sync-dhcp-pair、sync-dns-pair、sync-zd-map、および sync-dns-update-map です。

スケジュール済みタスクを削除するには、task name delete を使用します。

スケジュール済みタスクを編集するには、task name set attribute=value [attribute=value ...] を使用します。

ログ

ログファイル

次の表では、/var/nwreg2/{local | regional}/logs ディレクトリ内の Cisco Prime Network Registrar ログファイルについて説明します。

表 1. .../logs ディレクトリ内のログファイル
コンポーネント	/logs ディレクトリ内のファイル	ローカル / リージョン	ログ
インストール	install_cnr_log	両方	インストールプロセス
アップグレード	ccm_upgrade_status_log	両方	アップグレードプロセス
	dns_upgrade_status_log	ローカル	アップグレードプロセス
	dhcp_upgrade_status_log	ローカル	アップグレードプロセス
サーバーエージェント	agent_server_1_log	両方	サーバーエージェントの起動と停止
ポートチェック	checkports_log	両方	ネットワークポート
DNS サーバー	name_dns_1_log	ローカル	DNS アクティビティ
	dns_startup_log	ローカル	DNS の起動アクティビティ
	dns_packet_log	ローカル（Local）	DNS パケットロギングメッセージ¹
CDNS サーバー	cdns_log	ローカル	CDNS アクティビティ
	cdns_startup_log	ローカル	CDNS の起動アクティビティ
	cdns_query_log	ローカル（Local）	CDNS クエリログエントリ²
DHCP サーバー	name_dhcp_1_log	ローカル	DHCP アクティビティ
DHCP サーバー	dhcp_startup_log	ローカル	DHCP の起動アクティビティ
TFTP サーバー	file_tftp_1_log file_tftp_1_trace	ローカル	TFTP アクティビティ
TFTP サーバー	tftp_startup_log	ローカル	TFTP の起動アクティビティ
SNMP サーバー	cnrsnmp_log	両方	SNMP アクティビティ
CCM データベース	config_ccm_1_log	両方	CCM の設定、開始、停止
CCM データベース	ccm_startup_log	両方	CCM の起動アクティビティ
Web UI	cnrwebui_log	両方	Web UI の状態
Tomcat/Web UI（cnrwebui サブディレクトリ内）	catalina.date.log.txt jsui_log.date.txt cnrwebui_access_log.date .txt	両方	Tomcat サーバーおよび Web UI の CCM データベース（新しいファイルが毎日作成されるため、定期的に古いログファイルをアーカイブします）。
リソース制限	ccm_monitor_log	両方	リソース制限アクティビティ。
スマートライセンス	ccm_smartagent_log	リージョン	スマートエージェントログ
	ch_dbg.log		Call Home ログ
	SAEvent*.log		スマートエージェントイベントログ

¹ packet-logging が有効になっており、「packet」が packet-logging-file として設定されている場合は、パケットロギングメッセージが dns_packet_log ファイルにログ記録されます。このログファイルを表示するには、サーバーを再起動します。

² クエリログ設定を有効になっている場合、クエリログエントリが cdns_query_log ファイルにログ記録されます。

DNS、DHCP、CDNS、CCM、および TFTP サーバーは、それぞれ事前設定された最大サイズの 10 MB を持つ多数のログファイルを生成できます。この事前設定値は、新規インストールにのみ適用されます。

（注）

11.0 より前のバージョンからのアップグレードでは、古い事前設定済み（または明示的に設定された）値の 100 万バイトがログファイルに使用されます。

最初のログファイル名には _log サフィックスが付きます。このファイルの最大サイズに達すると、その名前に .01 バージョン拡張子が付加され、バージョン拡張子なしで新しいログファイルが作成されます。各バージョン拡張子は、作成された新しいファイルごとに 1 ずつ増分されます。ファイルが設定された最大数に達すると、最も古いファイルが削除され、次に古いファイルがその名前を引き継ぎます。DNS、DHCP、CDNS、CCM、および TFTP サーバーの場合、通常の最大数は 10 です。

Cisco Prime Network Registrar には server_startup_log ファイルもあります。これは、CCM、DHCP、DNS、および TFTP サーバーに適用されます。これらのファイルは、サーバーの起動フェーズとシャットダウンフェーズをログに記録します（情報は通常のログファイル情報と同様です）。サーバーのスタートアップログファイルは、サーバーが最後に起動したときに報告された問題の診断に役立ちます。

これらの起動ログの数はサーバーに対して 4 で固定されており、サイズはサーバーあたり 10 MB に固定されています。

（注）

一部のユーザーコマンドでは、クラスタへの個別の接続が原因で、サーバーエージェントログにユーザー認証エントリを作成できます。これらを別のユーザーによるシステムセキュリティ違反として解釈しないでください。

ロギングは、Syslog に転送することもできます。cnr.conf ファイルの変更を参照してください。

CLI コマンド

CLI で[server ] type serverLogs show を使用して、DNS、DHCP、および TFTP サーバーの設定済み最大値を確認できます。これらのプロトコルのサーバーログファイルの最大数（nlogs）と最大サイズ（logsize）が表示されます。これらのパラメータは、[server ] type serverLogs set nlogs= nlogs logsize=logsizeを使用して調整できます。その他のログファイルについては、これらの最大値を調整することはできません。

（注）

Cisco Prime Network Registrar を再起動するまで、サーバーログへの変更は有効になりません。

サーバーイベントのロギング

Cisco Prime Network Registrar を起動すると、Cisco Prime Network Registrar システムアクティビティのロギングが自動的に開始されます。Cisco Prime Network Registrar はデフォルトで /var/nwreg2/{local | regional}/logs ディレクトリ内にすべてのログを維持します。これらのログを表示するには tail -f コマンドを使用します。

ローカル基本または詳細とリージョン Web UI

サーバーのロギングを Web UI で使用するには、サーバーの [サーバーの管理（Manage Servers）] ページを開き（サーバーの管理を参照）、[ログ（Logs）] タブをクリックします。サーバーのログページが開きます。ログは時間順に表示され、最新のエントリを含むページから順に表示されます。以前のエントリを確認する必要がある場合は、ページの上部または下部にある左矢印をクリックします。

ロギングの形式と設定

サーバーログエントリには、次のカテゴリが含まれます。

Activity - サーバーのアクティビティをログに記録します。
Info - 起動やシャットダウンなど、サーバーの標準動作をログに記録します。
Warning - 要求の処理中に、無効なパケット、ユーザーのミスコミュニケーション、またはスクリプトのエラーなどの警告をログに記録します。
Error - メモリ不足、リソースの取得ができない、または設定のエラーなど、サーバーが正常に動作しないイベントをログに記録します。

ローカル基本または詳細とリージョン Web UI

ログに記録するイベントに影響を与えることができます。たとえば、ローカルクラスタの DNS および DHCP サーバーのロギングを設定するには、次のようにします。

DNS - [導入（Deploy）] メニューから、[DNS] サブメニューで [DNS サーバー（DNS Server）] を選択して、[DNS サーバーの管理（Manage DNS Server）] ページを開きます。サーバーの名前をクリックして、[DNS サーバーの編集（Edit DNS Server）] ページを開きます。[ログ設定（Log Settings）] セクションを展開して、ログ設定を表示します。必要に応じて属性を変更し、[保存（Save）] をクリックして、サーバーをリロードします。（DNS サーバーのパフォーマンスを最大化するためのログ設定については、『Cisco PrimeNetwork Registrar 11.0 権限のあるキャッシュ DNS ユーザーガイド』の「DNS サーバーのトラブルシューティング」の項の表を参照してください）。
DHCP - [導入（Deploy）] メニューから、[DHCP] サブメニューの [DHCP サーバー（DHCP Server）] を選択して、[DHCP サーバーの管理（Manage DHCP Server）] ページを開きます。サーバーの名前をクリックして、[DHCP サーバーの編集（Edit DHCP Server）] ページを開きます。[Logging] セクションを展開して、ログ設定を表示します。必要に応じて属性を変更し、[保存（Save）] をクリックして、サーバーをリロードします。（DHCP サーバーのパフォーマンスを最大化するためのログ設定については、『Cisco Prime Network Registrar 11.0 DHCP ユーザーガイド』の「DHCP サーバーの調整」の項の表を参照してください）。
CCM - [Operate] メニューで、[Servers] サブメニューから [Manage Servers] を選択し、[Manage Servers] ページを開きます。サーバーの名前をクリックして、[Edit Local CCM Server] ページを開きます。[Logging] セクションを展開して、ログ設定を表示します。属性に必要な変更を加え、[Save] をクリックします（必要なログカテゴリを有効または無効にするには、CCM サーバーの管理の表を参照してください）。

CLI コマンド

それぞれのサーバーについて、dns set log-settings =value、dhcp set log-settings =value、ccm set log-settings =value、および tftp set log-settings =value を使用します。

ログの検索

Web UI は、アクティビティおよび起動ログファイル内のエントリを検索する便利な方法を提供します。正規表現文字列エントリを使用して、特定のメッセージテキスト、ログメッセージ ID、およびメッセージのタイムスタンプを検索できます。ページの上部または下部にある [検索（Search）] アイコンの横にあるテキストフィールドに、正規表現構文で検索文字列を入力します。（たとえば、name? と入力すると、ログファイル内の文字列 name の出現が検索されます）。[検索（Search）] アイコンをクリックすると、ログ検索の結果が表示されます。テーブルビューとテキストビューを切り替えるには、ページの上部と下部で使用可能な [ページ（Page）] アイコンをクリックします。

メッセージの全文を表示するには、ログメッセージの名前をクリックします。[ログ検索結果（Log Search Result）] ページの Close をクリックすると、ブラウザウィンドウが閉じます。

変更ログの表示

Web UI で、設定に関連付けられている変更ログとタスクを表示できます。

ローカルおよびリージョン Web UI

Operate メニューから Change Log を選択します。変更ログを表示するには、ccm-admin または regional-admin ロールのデータベースサブロールが割り当てられている必要があります。

[変更ログの表示（View Change Log）] ページには、すべての変更ログが DBSN 名でソートされて表示されます。リストの下部を表示するには、ページの左下にある右矢印をクリックします。変更ログエントリの DBSN 番号をクリックして、[変更セットの表示（View Change Set）] ページを開きます。

[変更ログの表示（View Change Log）] ページでは、リストをフィルタリングして、手動でトリミングし、ファイルに保存することができます。次によって、リストをフィルタリングできます。

開始日と終了日
変更を開始した管理者
設定オブジェクトクラス
特定のオブジェクト
OID-00:00:00:00:00:00:00:00 の形式のオブジェクト識別子（ID）
サーバー
データベース

Filter List または Clear Filter をクリックします（セッション中に保持されるフィルタをクリアします）。[より古い（older than）] フィールドに日数の値を設定し、[削除（Delete)] アイコンをクリックすることによって、レコードをトリミングするまでの日数を設定することで、変更ログのトリミングを開始できます。

変更ログエントリをカンマ区切り値（CSV）ファイルに保存するには、[CSV 形式で保存（Save to CSV Format）] アイコンをクリックします。

タスクが変更ログに関連付けられている場合は、[変更セットの表示（View Change Set）] ページに表示されます。タスク名をクリックして、[CCM タスクの表示（View CCM Task）] タスクページを開くことができます。

CLI コマンド

expert コマンド ccm trimChangeSets delete-age [db-max-records] を使用し、指定された引数を使用して変更セット（変更ログ）のトリムを開始します。シンタックスと属性の説明については、/docs ディレクトリの CLIGuide.html ファイルの expert コマンドを参照してください。

警告	上記の操作は通常必要ではなく、指定された値を使用します。これは、CCM によって実行される定期的なトリムとは異なる場合があります。このコマンドは、保持する必要があるデータを削除する可能性があるため、十分に注意して使用してください。

変更ログレコード（CSV 形式）をエクスポートするには、export changeLog filename [attribute=value ...] [-all] を使用します。

サーバーログ設定の動的更新

DHCP および DNS サーバーは、サーバーの設定中にのみ、サーバーのログに変更を登録します。これは、リロード時に発生します。サーバーのリロードには時間がかかります。Cisco Prime Network Registrar では、DHCP および DNS サーバーは、リロードせずに、ログ設定に変更を登録できます。

ローカル基本または詳細 Web UI

DHCP サーバーのログ設定を動的に更新するには、次の手順を実行します。

手順

ステップ 1	[展開（Deploy）] メニューから、[DHCP] サブメニューの [DHCP サーバー（DHCP Server）] を選択します。[DHCP サーバーの管理（Manage DHCP Server）] ページが表示されます。
ステップ 2	左側のペインで DHCP サーバーの名前をクリックして、[DHCP サーバーの編集（Edit DHCP Server）] ページを開きます。
ステップ 3	必要に応じて設定を変更します。
ステップ 4	ページ下部の [保存（Save）]をクリックします。新しいログ設定が DHCP サーバーに適用されます。[DHCP サーバーの管理（Manage DHCP Server）] ページに、更新されたページ更新時間が表示されます。

ローカル基本または詳細 Web UI

DNS サーバーのログ設定を動的に更新するには、次の手順を実行します。

手順

ステップ 1

[展開（Deploy）] メニューから、[DNS] サブメニューの [DNS サーバー（DNS Server）] を選択します。[DNS サーバーの管理（Manage DNS Server）] ページが開きます。

ステップ 2

左側のペインで DNS サーバーの名前をクリックして、[DNS サーバーの編集（Edit DNS Server）] ページを開きます。

ステップ 3

必要に応じて設定を変更します。

ステップ 4

ページ下部の [保存（Save）]をクリックします。新しいログ設定が DNS サーバーに適用されます。[DNS サーバーの管理（Manage DNS Server）] ページに、更新されたページ更新時間が表示されます。

（注）

dhcp-edit-mode または dns-edit-mode が synchronous に設定されていて、サーバーが実行中の場合、サーバーログ設定の変更はサーバーに伝達されます。

CLI コマンド

CLI を使用して DHCP または DNS サーバーのログ設定を動的に更新するには、適切な edit-mode が synchronous に設定されている必要があります。サーバーログ設定を変更した後、save コマンドを使用して設定を保存します。

次に例を示します。

nrcmd> session set dhcp-edit-mode=synchronous
nrcmd> dhcp set log-settings=new-settings
nrcmd> save

データ整合性ルールの実行

整合性ルールを使用して、重複するアドレス範囲やサブネットなど、データの不整合をチェックできます。データ整合性ルールは、リージョンおよびローカルクラスタで設定できます。

[整合性ルールの一覧表示（List Consistency Rules）] ページのテーブルには、これらのルールが記載されています。実行するルールの横にあるチェックボックスをオンにします。

（注）

cnr_rules など、Java SDK を使用する Java ツールを実行するときには、UNIX のロケールパラメータを en_US.UTF-8 に設定する必要があります。

[整合性ルールの一覧表示（List Consistency Rules）] ページには、すべてのルールを選択する機能と、選択をクリアする機能が含まれています。各ルール違反の詳細を表示したり、出力を表示したりすることができます。ユーザーが行ったルール選択は、ユーザーセッション中は永続的です。

ローカルおよびリージョン Web UI

整合性ルールを実行するには、次の手順を実行します。

手順

ステップ 1	Operate メニューから、レポート（Reports）] サブメニューの Consistency Reports を選択します。 [整合性ルールの一覧表示（List Consistency Rules）] ページが表示されます。
ステップ 2	リストされた各整合性ルールのうち、適用するルールのチェックボックスをオンにします。すべてのルールを選択するには、Select All Rules リンクをクリックします。すべての選択をクリアするには、Clear Selection リンクをクリックします。
ステップ 3	Run Rules をクリックします。 [整合性ルール違反（Consistency Rules Violations）] ページが表示されます。ルールは違反タイプによって分類されます。違反の詳細を表示するには、Show Details リンクをクリックします。出力を表示するには、ページアイコンをクリックします。 [XML の表示（Display XML）] をクリックして、出力を XML 形式で表示します。
ステップ 4	Return to Consistency Rules をクリックして、[整合性ルールの一覧表示（List Consistency Rules）] ページに戻ります。

CLI ツール

コマンドラインから cnr_rules 整合性ルールツールを使用して、データベースの不整合がないかどうかを確認します。このツールを使用して、ルールの結果をテキストファイルまたは XML ファイルでキャプチャすることもできます。

cnr_rules ツールは .../usrbin/cnr_rules ディレクトリにあります。

cnr_rules ツールを実行するには、次のように入力します。

> cnr_rules -N username -P password [options]

–N username - 指定された username を使用して認証します。
–P password - 指定された password を使用して認証します。
[オプション（options）] - 次の表に示すように、ツールの修飾オプションについて説明します。オプションを入力しなかった場合は、コマンドの使用法が表示されます。

オプション

説明

–list

使用可能な整合性ルールを一覧表示します。

（注）

使用可能なコマンドのリストは、-N オプションの値で指定された管理者の権限に合わせて調整されます。

> cnr_rules -N admin -P changeme -list

–run [rule-match ]

使用可能なルールを実行します。オプションで、大文字と小文字を区別しない rule-match 文字列を適用することで、使用可能なルールのサブセットを実行できます。

すべてのルールを実行します。
```
> cnr_rules -N admin -P changeme -run
```
名前に文字列「dhcp」が含まれているルールのみを実行します。
```
> cnr_rules -N admin -P changeme -run dhcp
```

ヒント

スペースを含む文字列と一致させるには、二重引用符（"）で文字列を囲みます。例：> cnr_rules -N admin -P changeme -run "router interface"

–details

整合性ルールに違反するデータベースオブジェクトの詳細を結果に含めます。

DNS ルールを実行し、データベースオブジェクトの詳細を結果に含めます。

> cnr_rules -N admin -P changeme -run DNS -details

–xml

ルールの結果を XML ファイルで生成します。

（注）

–xml オプションを使用すると、XML ファイルにすべての詳細情報が含まれているため、–details オプションは無視されます。

> cnr_rules -N admin -P changeme -run -xml

–path .classpath

使用可能な整合性ルールを検索する Java のクラスパスを変更します（任意）。

新しいカスタム整合性ルールを実行するために、このオプションを使用できます。これを行うには、サポートエンジニアのサポートを受ける必要があります。

–interactive

インタラクティブセッションでツールを実行します。

> cnr_rules -N admin -P changeme -run -interactive
RuleEngine [type ? for help] > ?
Commands:
  load <class>     // load the specified rule                       class
  run <rule-match> // run rules matching a string,                       or '*' for all
  list             // list rules by name
  xml              // toggle xml mode
  detail           // toggle detail mode (non-xml                       only)
  quit             // quit RuleEngine

–both

Unicode と ASCII の両方でドメイン名を表示します。

上記のコマンドの出力を別のファイルにリダイレクトできます。ルールの結果をキャプチャするには、次の構文を使用します。

テキストファイル：

> cnr_rules -N username -P password -run -details > filename.txt

XML ファイル：

> cnr_rules -N username -P password -run -xml > filename.xml

サーバーステータスのモニターリングと報告

サーバーのステータスのモニターリングには、次のチェックが含まれます。

状態
正常性
統計
ログメッセージ
アドレス使用状況
関連サーバー（DNS および DHCP）
リース（DHCP）

サーバーの状態

すべての Cisco Prime Network Registrar プロトコルサーバー（DNS、DHCP、SNMP、および TFTP）は、次の状態で構成される状態マシンを通過します。

Loaded - サーバーエージェントがサーバーを起動した後の最初のステップ（過渡的）。
Initialized - サーバーが停止したか、設定に失敗しました。
Unconfigured - サーバーは設定の失敗が原因で動作していません（過渡的）。
Stopped - サーバーは管理上停止しており、動作していません（過渡的）。
Running - サーバーは正常に動作しています。

2つの基本的状態が初期化され、実行されます。これは、サーバーの状態遷移が速すぎて、他の状態は基本的に非表示になるためです。通常、サーバーエージェントがサーバーを起動するときには、サーバーに起動するように通知します。サーバープロセスが起動し、状態をロード済みに設定してから、実行状態に移行します。サーバーを停止すると、状態は初期化済みに戻り、再起動すると、再ひ実行中まで移行します。何らかの理由で設定に失敗した場合は、停止した場合と同様に、初期化済みに戻ります。

また、プロセスが終了したときにサーバーが非常に短時間だけ遷移する終了中状態もあります。ユーザーインターフェイスは、サーバーの無効化を検討することもありますが、これはほとんど発生せず、サーバープロセスがまったく存在しない（サーバープロセスを起動しないようにサーバーエージェントが命令された）場合に限られます。

正常性の表示

サーバーの正常性の側面、つまりサーバーがどの程度正常に実行されているかを表示できます。次の項目はサーバーの正常性を損なうことがあるため、ステータスを定期的にモニターする必要があります。次について：

サーバーエージェント（ローカルおよびリージョンクラスタ）
CCM サーバー（ローカルおよびリージョンクラスタ）
DNS サーバー（ローカルクラスタ）:
- 設定エラー
- メモリ
- ディスク領域使用率
- ルートサーバーへの接続不可
キャッシュ DNS サーバー（ローカルクラスタ）
DHCP サーバー（ローカルクラスタ）:
- 設定エラー
- メモリ
- ディスク領域使用率
- パケットキャッシングの低下
- 指定されたパケット制限に適合しないオプション
- 使用可能なリースがない
TFTP サーバー（ローカルクラスタ）:
- メモリ
- ソケットの読み取りまたは書き込みエラー
- 過負荷しきい値の超過と要求パケットのドロップ

サーバーの正常性ステータス

サーバーの正常性ステータスは、0 ~ 10 の値があります。値 0 は、サーバーが動作していないことを意味し、10 はサーバーが稼働していることを意味します。一部のサーバーでは、0 または 10 のみが報告され、その間は何も報告されません。サーバーが 1 ~ 9 の値を報告した場合、問題が発生していることを示す条件が検出されたことを意味します。サーバーの実際のパフォーマンスには関係ありません。そのため、サーバーの正常性が 1 ~ 9 の値である場合、サーバーログファイルを確認して、どのようなエラーが記録されたかを確認する必要があります。

（注）

アクティビティのレベルとログファイルのサイズと数によっては、サーバーの正常性を低下させる条件がログファイルに表示されない場合があります。ログファイルを確認することが重要ですが、サーバーはサーバーの正常性を低下させるすべての条件をログに記録するわけではありません。

次の条件は、DHCP サーバーの正常性を低下させることがあります。

設定エラー（サーバーの起動時または再起動時に発生します）
サーバーがメモリ不足条件を検出したとき
パケット受信障害が発生したとき
サーバーの要求または応答バッファ不足のため、パケットがドロップされたとき
サーバーが応答パケットを構築できないとき

TFTP サーバーにも同様の条件があります。

ヒント

正常性の値の範囲は 0（サーバーが動作していない）から 10（最高レベルの正常性）までです。ゼロはサーバーが動作していないことを意味し、ゼロより大きい値はサーバーが動作していることを意味することを理解したうえで、正常性ステータスの正確な値（1 〜 10）は無視することを推奨します。install-path/usrbin で cnr_status コマンドを実行してローカルクラスタサーバーが実行しているかどうかを確認できます。ローカルクラスタサーバーが実行しているかどうかを確認する方法の詳細については、Cisco Prime Network Registrar 11.0 インストールガイド を参照してください。

ローカル基本または詳細とリージョン Web UI

[操作（Operate）] メニューから、[サーバーの管理（Manage Servers）] を選択します。[サーバーの管理（Manage Servers）] ページで、各サーバーの状態と正常性を確認します。

CLI コマンド

[server ]タイプ getHealth を使用します。数値 10 は、最高レベルの正常性を示し、0 はサーバーが動作していないことを示します。

統計の表示

サーバー統計を表示するには、サーバーが実行している必要があります。

ローカル基本または詳細とリージョン Web UI

[サーバーの管理（Manage Servers）] ページに移動し、左側のペインでサーバーの名前をクリックしてから、[統計（Statistics）] タブをクリックします（使用可能な場合）。[サーバー統計（Server Statistics）] ページで、属性の名前をクリックして、ポップアップヘルプを表示します。

DHCP、DNS、および CDNS 統計は、それぞれ 2 つの統計グループに分かれています。最初のグループは合計統計であり、2 番目のグループはサンプル統計です。合計統計は、時間の経過とともに累積されます。サンプル統計は、設定可能なサンプル間隔の間に発生します。2 つのカテゴリの名前は、サーバーごと、またユーザーインターフェイスごとに異なり、次の表に示されています。

表 3. サーバー統計のカテゴリ
サーバー	ユーザーインターフェイス	合計統計（コマンド）	サンプル統計（コマンド）
DHCP	Web UI	合計統計	アクティビティ要約
DHCP	CLI	最後の DHCP サーバープロセスの開始以降の合計カウンタ。（dhcp getStats ）	最後のサンプル間隔中に収集されたサンプルカウンタ。これらは、サンプル期間ごとに 1 回更新されます。（dhcp getStats server sample ）
DNS	Web UI	合計統計	サンプル統計
DNS	CLI	最後のサーバープロセスの開始以降の合計カウンタ。（dns getStats ）	現在のサンプル間隔中に収集されているサンプルカウンタ。これらは絶えず更新されます。（dns getStats performance sample ）
CDNS	Web UI	合計統計	サンプル統計
CDNS	CLI	最後のサーバープロセスの開始以降の合計カウンタ。 (cdns getStats server total)	最後のサンプル間隔以降にサンプリングされたカウンタ。（cdns getStats server sample ）

サンプルカウンタをセットアップするには、サーバーの collect-sample-counters 属性または activity-summary と呼ばれる log-settings 属性値のいずれかをアクティブにする必要があります。また、各サーバーのサンプル間隔の log-settings 値を設定することもでき、5 分に事前設定されています。collect-sample-counters 属性は、DNS サーバーの場合は true に事前設定されていますが、DHCP サーバーの場合は false に事前設定されています。たとえば、サンプルカウンタを有効にし、DHCP の間隔を設定するには、DHCP サーバーの次の属性を設定します。

collect-sample-counters を有効化（dhcp enable collect-sample-counters ）
activity-summary の log-settings を設定（dhcp set log-settings=activity-summary ）
activity-summary-interval を 5m に設定（dhcp set activity-summary-interval=5m ）

CLI コマンド

CLI では、[server ] type getStats を使用する場合、DNS については表 18、DHCP については表 20、TFTP については表 21、で説明されているように、統計は波カッコで囲まれ、その後に一連のフィールドが続きます。server type getStats all コマンドは、より冗長であり、各統計が 1 行ずつ表示されます。追加の sample キーワードを使用すると、サンプル統計のみが表示されます。

カウンタと合計統計をリセットするには、dhcp resetStats 、dns resetStats 、または cdns resetStats を使用します。

DNS 統計

Web UI の DNS サーバー統計が [DNS サーバー統計（DNS Server Statistics）] ページに表示されたら、統計の名前をクリックして説明を読みます。DNS サーバー統計を更新できます。

DNS 統計情報の完全なリストについては、表 1を参照してください。

DNS サーバー統計の詳細には、サーバー識別子、再帰的なサービス、プロセス稼働時間、リセット以降の時間、サーバーステータス、カウンタリセット時間、サンプル時間、統計間隔、経過時間、合計ゾーン、および合計 RR が含まれ、次に示す合計およびサンプル統計が続きます。

[Performance Statistics] - DNS サーバーのパフォーマンスの統計が表示されます。
[Query Statistics] - クエリの統計が表示されます。
[Update Statistics] - DNS アップデートの統計が表示されます。
[HA Statistics] - HA DNS サーバーの統計が表示されます。
[Host Health Check Statistics] - DNS ホスト正常性チェックの統計が表示されます。
[DB Statistics] - DNS データベースの統計が表示されます。
[Cache Statistics] - DNS クエリキャッシュの統計が表示されます。
[Security Statistics] - セキュリティの統計が表示されます。
[IPv6 Statistics] - 送受信された IPv6 パケットの統計が表示されます。
[Error Statistics] - エラーの統計が表示されます。
[Max Counter Statistics] - 同時スレッド、RR、DNS アップデート遅延、同時パケットなどの最大数の統計が表示されます。
[Top Name Statistics]：トップネームの統計が表示されます。

（注）

最新のデータを取得するには、[統計（Statistics）] ページの左上にある [サーバー統計の更新（Refresh Server Statistics）] アイコンをクリックします。

dns getStats コマンドには、次のオプションがあります。

dns getStats [<performance [,] query [,] update [,] errors [,] security [,] 
maxcounters [,] ha [,] ipv6 [,] cache [,] datastore [,] top-names [,] 
dns-hhc | all> [total | sample]]

最も一般的に使用されているコマンドは dns getStats all であり、表 1で説明されている統計情報を返します。all オプションのない dns getStats コマンドは、1 行の位置値の統計を次の形式で返します（次の表は、これらの値を読み取る方法を示しています）。

nrcmd> dns getStats
 
100 Ok
{1} 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

表 4. DNS 統計
フィールド	統計	説明
{1}	id	実装 ID（リリースおよびビルド情報）。
2	config-recurs	再起サービス - (1) available、(2) restricted、(3) unavailable。
3	config-up-time	最後のサーバーの起動時からの経過時間（秒単位）。
4	config-reset-time	最後のサーバーのリセット（再起動）からの経過時間（秒単位）。
5	config-reset	ネームサーバーの状態を再初期化するステータスまたはアクション -（2）リセットアクションを使用した場合、永続的なネームサーバーの状態が再初期化されます。以下に、読み取り専用ステータスを示します。（1）other - 未知の状態のサーバー、（3）初期化中、または（4）実行中。
6	counter-auth-ans	信頼できる応答が返されたクエリの数。
7	counter-auth-no-names	そのような名前がないという信頼できる応答が返されたクエリの数。
8	counter-auth-no-data-resps	そのようなデータはないという信頼できる応答（空の応答）が返されたクエリの数。（廃止された統計）
9	counter-non-auth-datas	信頼できない応答（キャッシュ）が返されたクエリの数。（廃止された統計）
10	counter-non-auth-no-datas	データなしで信頼できない応答が返されたクエリの数。
11	counter-referrals	他のサーバーに転送されたクエリの数。
12	counter-errors	エラー（0 または 3 以外の RCODE 値）で応答された応答の数。
13	counter-rel-names	1 つのラベル（相対名）のみの名前に対して受信された要求の数。
14	counter-req-refusals	拒否されたクエリの数。
15	counter-req-unparses	解析不能な要求の数。
16	counter-other-errors	他のエラーが原因で中止された要求の数。
17	total-zones	設定済みゾーンの合計数。

CDNS 統計

Web UI の CDNS サーバーの統計情報は、[DNS キャッシングサーバーの統計] ページに表示され、統計の名前をクリックすると、説明が表示されます。CDNS サーバー統計を更新できます。

CDNS サーバーの統計情報の完全なリストについては、表 1を参照してください。

CDNS サーバー統計情報の詳細には、サーバー識別子、再帰的なサービス、現在の時間、プロセス稼働時間、サーバー再起動時間、カウンタリセット時間、サンプル時間、統計間隔、経過時間などが含まれ、次に示す合計およびサンプル統計が続きます。

[Query Details]：クエリの統計情報が表示されます。
[Answer Details]：CDNS クエリ応答に関連する統計情報が表示されます。
[Performance]：DNS サーバーのパフォーマンスの統計情報が表示されます。
[DNS64]：DNS64 の統計情報が表示されます。
[Firewall]：DNS ファイアウォールの統計情報が表示されます。
[Rate Limiting]：レート制限に関連する統計情報が表示されます。
[Top Name Statistics]：トップネームの統計が表示されます。

（注）

最新のデータを取得するには、[統計（Statistics）] ページの左上にある [サーバー統計の更新（Refresh Server Statistics）] アイコンをクリックします。

cdns getStats コマンドには、次のオプションがあります。

cdns getStats [<server | top-names | rate-limit | all> [total | sample]]

cdns getStats コマンドと cdns getStats server コマンドはどちらも、cdns getStats server total と同じです。

cdns getStats top-names コマンドと cdns getStats rate-limit コマンドでは常に「サンプル」データがレポートされ、モードパラメータは無視されます（「合計」データはレポートされない）。

cdns getStats コマンドと cdns getStats all コマンドは表 1に示す統計情報を介します。

DHCP 統計

Web UI の DHCP サーバー統計が [DHCP サーバー統計（DHCP Server Statistics）] ページに表示されたら、統計の名前をクリックして説明を読みます。

DHCP 統計情報の完全なリストについては、表 1を参照してください。

DHCP サーバー統計の詳細情報には、サーバーの開始時刻、サーバーのリロード時間、サーバーの稼働時間、統計リセット時間などが含まれ、次のセクションの統計が続きます。

[合計統計（Total Statistics）] - スコープ、要求バッファ、応答バッファ、パケットなどの合計統計が表示されます。
[リースカウント（Lease Counts）（IPv6）] - アクティブなリース、設定されたリース、予約済みリース、予約済みアクティブリースなど、IPv4 リースカウントの統計が表示されます。
[受信パケット（Packets Received）（IPv6）] - 受信した IPv4 パケットの統計が表示されます。
[[送信パケット（Packets Sent）（IPv6）] - 送信した IPv4 パケットの統計が表示されます。
[失敗パケット（Packets Failed）（IPv4）] - 失敗した IPv4 パケットの統計が表示されます。
[フェールオーバー統計（Failover Statistics）] - DHCP フェールオーバーサーバーの統計が表示されます。
[IPv6統計（IPv6 Statistics）] - 設定されている IPv6 プレフィックス、タイムアウトになった IPv6 オファーパケットなどの統計が表示されます。
[リースカウント（Lease Counts）（IPv6）] - アクティブなリース、設定されたリース、予約済みリース、および予約済みアクティブリースの IPv6 リースカウントの統計が表示されます。
[受信パケット（Packets Received）（IPv6）] - 受信した IPv6 パケットの統計が表示されます。
[送信パケット（Packets Sent）（IPv6）] - 送信された IPv6 パケットの統計が表示されます。
[失敗パケット（Packets Failed）（IPv6）] - 失敗した IPv6 パケットの統計が表示されます。

追加の属性には、使用率の高い集約とアクティビティの要約が含まれます。

（注）

最新のデータを取得するには、[統計（Statistics）] ページの左上にある [サーバー統計の更新（Refresh Server Statistics）] アイコンをクリックします。

dhcp getStats コマンドには、次のオプションがあります。

dhcp getStats [<all | server [,] failover [,] dhcpv6 [,] top-utilized> 
[total | sample]]

最も一般的に使用されているのは dhcp getStats all コマンドで、表 1で説明する統計情報を返します。all オプションのない dhcp getstats コマンドは、1 行の位置値の統計を次の形式で返します（次の表は、これらの値を読み取る方法を示しています）。

nrcmd> dhcp getStats 

100 Ok
{1} 2 3 4 5 6 7 8

表 5. DHCP 統計
フィールド	統計	説明
{1}	start-time-str	テキスト文字列としての最後のサーバーのリロードの日付と時刻。
2	total-discovers	受信された DISCOVER パケットの数。
3	total-requests	受信された REQUEST パケットの数。
4	total-releases	受信された RELEASED パケットの数。
5	total-offers	送信された OFFER パケットの数。
6	total-acks	送信された確認応答（ACK）パケットの数。
7	total-naks	送信された否定応答（NAK）パケットの数。
8	total-declines	受信された DECLINE パケットの数。

TFTP 統計

Web UI の TFTP サーバー統計は、[TFTP サーバー統計（TFTP Server Statistics）] ページに表示され、統計の名前をクリックすると、説明を確認できます。次の表に、汎用の tftp getStats コマンドの出力としてエンコードされた TFTP 統計を示します。

TFTP サーバーが起動すると、使用するセッション（tftp-max-sessions）とパケット（tftp-max-packets）が割り当てられます。TFTP セッションは、TFTP クライアントと TFTP サーバー間の通信を表します。

読み取り要求が TFTP サーバーに到達すると、サーバーは要求にパケットを割り当てて、total-packets-in-use および total-read-requests 値を 1 ずつ増加させ、データパケットでユーザーに応答します。TFTP サーバーは、必要に応じて、最新の通信パケットをバックアップして再送信します。TFTP サーバーは、データパケットとして使用するために、プールから別のパケットを選択します。TFTP サーバーは、クライアントに送信されたデータブロックの確認応答を受信すると、次のデータブロックを送信します。セッションがただちにパケットを処理できない場合、TFTP サーバーはセッションに関連付けられているパケットをキューに入れます。

TFTP サーバー統計の詳細については、次を参照してください。

属性（Attribute）- ポート番号、デフォルトのデバイス、ホームディレクトリ、ルートとしてのホームディレクトリの使用など、サーバーの統計を表示します。
ログ設定（Log Settings）- ログレベル、ログ設定、およびパケットトレースレベルの統計を表示します。

（注）

最新のデータを取得するには、ページの左上にある [サーバー統計の更新（Refresh Server Statistics）] アイコンをクリックします。

TFTP 統計は、汎用の tftp getStats コマンドの出力として次の形式でエンコードされます。

nrcmd> tftp getStats
 
100 Ok
{1} 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

表 6. TFTP 統計
フィールド	属性	説明
{1}	id	実装 ID（リリースおよびビルド情報）。
2	server-state	サーバーの状態（アップまたはダウン）。
3	server-time-since-start	前回の起動からの実行時間。
4	server-time-since-reset	前回のリセットからの実行時間。
5	total-packets-in-pool	プール内のパケット数。
6	total-packets-in-use	サーバーが使用しているパケット数。
7	total-packets-received	前回の起動またはリロード後に受信したパケット数。
8	total-packets-sent	前回の起動またはリロード後に送信されたパケット数。
9	total-packets-drained	前回の起動またはリロード後に読み取られ、破棄されたパケット数。
10	total_packets_dropped	前回の起動またはリロード後にドロップされたパケット数。
11	total-packets-malformed	前回の起動またはリロード後に形式が間違っていた受信パケット数。
12	total-read-requests	前回の起動またはリロード後に読み取られたパケット数。
13	total-read-requests-completed	前回の起動またはリロード後に完了した読み取りパケット数。
14	total-read-requests-refused	前回の起動またはリロード後に拒否された読み取りパケット数。
15	total-read-requests-ignored	前回の起動またはリロード後に無視された読み取りパケット数。
16	total-read-requests-timed-out	前回の起動またはリロード後にタイムアウトした読み取りパケット数。
17	total-write-requests	前回の起動またはリロード後に書き込み要求であった読み取りパケット数。
18	total-write-requests-completed	前回の起動またはリロード後に完了した書き込み要求の数。
19	total-write-requests-refused	前回の起動またはリロード後に拒否された書き込み要求の数。
20	total-write-requests-ignored	前回の起動またはリロード後に無視された書き込み要求の数。
21	total-write-requests-timed-out	前回の起動またはリロード後にタイムアウトした書き込み要求の数。
22	total-docsis-requests	前回の起動またはリロード後に受信された DOCSIS 要求の数。
23	total-docsis-requests-completed	前回の起動またはリロード後に完了した DOCSIS 要求の数。
24	total-docsis-requests-refused	前回の起動またはリロード後に拒否された DOCSIS 要求の数。
25	total-docsis-requests-ignored	前回の起動またはリロード後に無視された DOCSIS 要求の数。
26	total-docsis-requests-timed-out	前回の起動またはリロード後にタイムアウトした DOCSIS 要求の数。
27	read-requests-per-second	1 秒あたりの読み取り要求の数。
28	write-requests-per-second	1 秒あたりの書き込み要求の数。
29	docsis-requests-per-second	1 秒あたりの DOCSIS 要求の数。

IP アドレスの使用状況の表示

IP アドレスの使用状況を表示すると、クライアントに現在どのようなアドレスが割り当てられているかの概要が示されます。

ローカル詳細およびリージョン Web UI

ローカルまたはリージョンクラスタのアドレス空間を確認するか、リージョンクラスタの DHCP 使用率またはリース履歴レポートを生成して、IP アドレスの使用状況を確認できます。これらの機能は、ローカルまたはリージョナルクラスタでアドレス空間権限がある場合、Design > DHCPv4 メニューで使用できます。

ユニファイドアドレス空間、アドレスブロック、およびサブネットの [現在の使用状況（Current Usage）] タブをクリックすることによって、現在のアドレス空間使用率を確認できます（『Cisco Prime Network Registrar 11.0 DHCP ユーザーガイド』の「アドレスブロック、サブネット、およびスコープのアドレス使用状況の表示」の項を参照）。リース履歴を照会することによって、最新の IP アドレス使用状況を取得することもできます（『Cisco Prime Network Registrar 11.0 DHCP ユーザーガイド』の「リースの照会」の項を参照）。後者の場合、リージョン CCM サーバーは適切な DHCP サーバーを直接参照します。このサブネットからサーバーへのマッピングを確保するには、関連するローカルクラスタと一致するようにリージョンのアドレス空間ビューを更新する必要があります。これを行うには、レプリカアドレス空間をプルするか、サブネットを回収して DHCP サーバーにプッシュします（『Cisco Prime Network Registrar 11.0 DHCP ユーザーガイド』の「サブネットの回収」の項を参照）。また、特定の DHCP サーバーが実行していることを確認します。

CLI コマンド

report コマンドを使用して、IP アドレス使用状況レポートを生成できます。コマンドの構文は、次のとおりです。

report [column-separator=string]
						 [dhcp-only]
						 [dhcpv4]
						 [dhcpv6]
						 [file=outputfile]
						 [vpn=name]

列区切りは、レポートの列を区切る文字列を指定します（プリセット値はスペース文字です）。複数のスペースを含める場合は、その前にバックスラッシュ（\ ）エスケープ文字を付けます（引用符で囲まれています）。DHCPv4 または DHCPv6 アドレスを指定できます（dhcp-only は dhcpv4 と同じです）。VPN を指定しないと、現在の VPN のアドレスのみが返されます。

表 7. 永続イベントアルゴリズム
イベントに到達
計算されたサーバごとの制限の 50%（最大保留イベントの値を関連するサーバの合計数で除算したもの）。たとえば、合計 40K の最大保留イベントのうち、関連サーバーのイベントが 5K	制限を超えている限り、2 分ごとに INFO ログメッセージを発行します。 `The queue of events for the name remote server at address has x events, and has reached the info limit of y/2 events out of an upper limit of y events per remote server. The remote server may be misconfigured, inoperative, or unreachable.`
計算されたサーバーごとの制限の 100%、および最大保留イベント値の 50% 未満。たとえば、関連サーバーのイベントが 10K で、最大保留イベントの合計が 10K 未満	制限を超えている限り、2 分ごとに WARNING ログメッセージを発行します。 `The queue of events for the name remote server at address has x events, has exceeded the limit of y events per remote server, but is below the limit of z total events in memory. The remote server may be misconfigured, inoperative, or unreachable.`
計算されたサーバーごとの制限の 100%、および最大保留イベント値の 50% 以上。たとえば、関連サーバーのイベントが 10K で、合計最大保留イベントが 20K	制限を超えている限り、2 分ごとに ERROR ログメッセージを発行します。 `The queue of events for the name remote server at address has x events, and has grown so large that the server cannot continue to queue new events to the remote server. The limit of y events per remote server and z/2 total events in memory has been reached. This and future updates to this server will be dropped. The current eventID n is being dropped.` サーバーは、現在のトリガーイベントとそのサーバーでの後続のすべてのイベントをドロップします。
最大保留イベント値の100%。たとえば、すべての関連サーバーのイベントが 40K	ERROR ログメッセージを発行します。 `The queue of pending events has grown so large that the server cannot continue to queue new events. The queue's size is z, and the limit is z.` サーバーは、すべての関連サーバーで後続のすべてのイベントをドロップします。

ローカル詳細およびリージョン詳細 Web UI

Operate メニューから Reports サブメニューの DHCPv4 Lease History または DHCPv6 Lease History を選択します。クエリパラメータを設定し、リース履歴を照会します。（『Cisco Prime Network Registrar 11.0 DHCP ユーザーガイド』の「リースの照会」の項を参照してください）。

cnr.conf ファイルの変更

Cisco Prime Network Registrar は、基本設定パラメータに cnr.conf ファイルを使用します。このファイルは通常、/var/nwreg2/{local | regional}/conf ディレクトリにあります。Cisco Prime Network Registrar は、インストール時にファイルを作成し、1 行ずつ処理します。

設定パラメータを変更する場合は、このファイルを編集します。通常の操作では、値を変更する必要はありません。ただし、特定の条件では、ディスク領域の理由でデータファイルを移動する場合など、特定の値を変更する必要がある場合があります。

cnr.conf ファイルの形式は、パラメータ名と値のペア（1 行に 1 つ）で構成されます。たとえば、ローカルクラスタのインストールの場合は次のようになります。

cnr.https-port=8443
cnr.regional-ip=ipaddress
cnr.schemadir=/opt/nwreg2/local/schema
cnr.localhost-ipv6=2001:420:54ff:13::403:37
cnr.classesdir=/opt/nwreg2/local/classes
cnr.rootdir=/var/nwreg2/local
cnr.localhost-uuid=0e0eeab2-b235-4d01-81fe-12e042f8768f
cnr.regional-ccm-port=1244
cnr.services=dhcp,dns
cnr.tempdir=/var/nwreg2/local/temp
cnr.install-home=/opt/nwreg2/local
cnr.extensiondir=/opt/nwreg2/local/extensions
cnr.ccm-port=1234
cnr.propsdir=/opt/nwreg2/local/conf
cnr.backup-time=23:45
cnr.java-home=/usr/bin/java
cnr.confdir=/var/nwreg2/local/conf
cnr.ccm-mode=local
cnr.customextensiondir=/var/nwreg2/local/extensions

ディレクトリパスは、オペレーティングシステムのネイティブ構文である必要があります。この形式では、ディレクトリパスにコロン（:）を使用できますが、名前と値のペアの区切り文字として使用することはできません。行の継続や unicode 文字の埋め込みはできません。ファイルに対するその他の変更には、ログディレクトリの場所（ログファイルを参照）、または cnr_shadow_backup バックアップの実行時間（自動バックアップ時間の設定を参照）などがあります。

まれに、ファイルを変更したい場合があります。たとえば、キャパシティの問題により、毎日のバックアップから特定のデータを除外します。これを行うには、適切な設定を手動で追加する必要があります。

注意	このファイルのデフォルト設定を使用することを推奨します。これらの設定を変更する必要がある場合は、Cisco Technical Assistance Center（TAC）または Cisco Prime Network Registrar 開発チームと相談してください。

次の設定がサポートされています。

cnr.backup-dest - バックアップされたデータベースを配置する宛先を指定します。指定されなかった場合のデフォルトは、cnr.datadir です。
cnr.backup-dbs - バックアップするデータベースのカンマ区切りのリストを指定します。ローカルクラスタの場合、デフォルトは cdns,ccm,dhcp,dns,mcd,cnrsnmp です。リージョンクラスタの場合は、ccm,dns,leasehist,lease6hist,subnetutil,replica です。
cnr.backup-files - バックアップの一部としてコピーするファイルのカンマ区切りリスト、ファイルへの完全なパスを指定します。ファイルは cnr.backup-dest にコピーされます。
cnr.dbrecover-backup - バックアップされた Oracle Berkeley データベースに対して db recover と db verify wo実行するかどうかを指定します。デフォルトは true です。この設定は、毎日のバックアップにのみ使用されます。手動バックアップは、この設定を無視します。自動動作を無効にするということは、手動で操作を実行する必要があることを意味します。これは、別のマシンで、または Cisco Prime Network Registrar サーバーが比較的アイドル状態のときに実行する必要があることを意味します。
cnr.daily-backup - 毎日バックアップを実行するかどうかを指定します。デフォルトは true です。

時々問題を発生させる場合がある要因の 1 つは Java パスです。理想としては、Java をデフォルトの場所にインストールします。そのためには、次の行を cnr.conf ファイルに使用する必要があります。

cnr.java-home=/usr/bin/java

ただし、場合によっては異なるパスが使用され（11.0 より前のバージョンからアップグレードされた場合など）、Java へのより明示的なパスによって、Java がアップグレードされると Cisco Prime Network Registrar が正しく起動しなくなる可能性があります。したがって、cnr.conf ファイルでこのパスを確認し、インストールされた Java が正しく取得されるように（アップグレードされている場合も）上記の行に置換してください。

Syslog のサポート

Cisco Prime Network Registrar は syslog サーバーへのロギングをサポートしています。Syslog サポートは、デフォルトでは有効になっていません。ロギングレベルに基づいて、ログに記録する必要があるメッセージを設定するには、cnr.conf ファイルを更新する必要があります。

次の cnr.conf 設定パラメータがサポートされています。

cnr.syslog.enable：syslog サーバーへのロギングが Prime Network Registrar サーバーに対して有効にするかどうかを指定します。
- すべてのロギングを無効にするには、値を 0、off、または disabled にします。
- すべてのロギングを有効にするには、値を 1、on、または enabled にします。
- デフォルトでは、このパラメータは無効になっています。

cnr.syslog.levels：syslog に記録する重大度レベルを指定します。Syslog が有効な場合、デフォルトは warning と error です。値は、大文字と小文字が区別されず、カンマで区切られたキーワード（error、warning、activity、info、debug）のリストです。このパラメータは、Syslog が無効な場合は無視されます。

注意

すべての重大度レベルを有効にすることは可能ですが、すべてのメッセージがサーバーログファイルに書き込まれ、Syslog にも記録されるため、これは推奨されません。Syslog とサーバーのパフォーマンスに与える影響は、ロギングの設定方法によって大きく異なる場合があります。Syslog はメッセージのレート制限を行うことができるため、有用なメッセージも失われる可能性があります。

書き込まれるメッセージの数を最小限に抑えるために、Syslog 設定とメッセージを確認することを強くお勧めします。Syslog に書き込まれるメッセージが多すぎると、Cisco Prime Network Registrar サーバーと Syslog のパフォーマンスに影響を与えます。

cnr.syslog.facility：syslog のログの出力元になるファシリティを指定します。有効なファシリティキーワードは、daemon（デフォルト）、local0、local1、local2、local3、local4、local5、local6、local7 です。
cnr.syslog.ids - ログに記録する（またはログに記録しない）個別のメッセージを、メッセージ ID のカンマ区切りリストまたはメッセージ ID 範囲（x 〜 y）として指定します。メッセージ ID または範囲の前にマイナス記号（ハイフン）または ! （感嘆符）がある場合、そのメッセージ ID または ID 範囲は明示的にログに記録されません。明示的に参照されるメッセージ ID は、他の Syslog 設定（.enable 設定を含む）に関係なくログに記録されたり記録されなかったりします。

メッセージ ID を確認するには、/opt/nwreg2/local/docs/msgid/*.html ファイル（または実際のサーバーログファイル）を参照してください。

次に例を示します。
```
cnr.syslog.ids=4000-4100,-4101-4200,4300 
```
これにより、メッセージ 4000 ～ 4100 と 4300 が syslog に記録され、メッセージ 4101 ～ 4200 は（他の syslog 設定に関係なく）ログに記録されません。

（注）

これらのパラメータは、すべての Cisco Prime Network Registrar サーバー（cnrservagt、ccm、cdns、cnrsnmp、dns、dhcp、および tftp）に適用されます。
cnr.conf パラメータに変更を適用するには、Cisco Prime Network Registrarを再起動する必要があります。

次の cnr.conf 設定パラメータによって、上記のパラメータのサーバー固有のオーバーライドが可能です。server は、cnrservagt、ccm、cdns、cnrsnmp、dns、dhcp、および tftp のいずれかです。

cnr.syslog.server.enable：指定したサーバーに対して syslog を有効にするかどうかを指定します（そのサーバーの cnr.syslog.enable は無視されます）。
cnr.syslog.server.levels - 指定されたサーバーの重大度レベルを指定します（cnr.syslog.levels は、そのサーバーについては無視されます）。
cnr.syslog.server.facility - 指定されたサーバーの Syslog ファシリティを指定します（cnr.syslog.facility は、そのサーバーについては無視されます）。

指定されている場合は、サーバー固有の設定値が使用されます。それ以外の場合は、サーバーのすべてのパラメータが使用されます。たとえば、DHCP についてのみ Syslog を有効にするには、cnr.conf ファイルに次のように追加します。

cnr.syslog.dhcp.enable=1

すべてのサーバーの Syslog 設定を設定する例：

cnr.syslog.enable=1
cnr.syslog.levels=error,warning,activity

権威 DNS サーバーについてのみ Syslog を有効にするには、次のようにします。

cnr.syslog.dns.enable=1
cnr.syslog.dns.levels=error,warning,activity

ヒント

cnr.conf パラメータの構文またはその他のエラーは報告されず、無視されます（つまり、レベルキーワードがタイプミスされた場合、そのキーワードは無視されます）。したがって、設定変更が機能しない場合は、パラメータが正しく指定されているかどうかを確認してください。

（注）

多くの Syslog 実装ではレート制限が実装されており、Cisco Prime Network Registrar サーバーのロギングによってこれが容易にトリガーされ、ログデータの Syslog への喪失が発生します。これが発生している場合は通常、/var/log/messages の「Suppressed number messages from ….」メッセージが表示されます。多くの Syslog 実装には、これをトリガーするレートを制御したり、アクションを無効にしたりする設定があります（ただし無効にすることは推奨されません）。これらの調整を行うか、Syslog に記録する内容を減らすことを検討する必要があります（特に高レベルのアクティビティの場合は、すべてを記録することは推奨されません）。通常、これは /etc/systemd/journald.conf の RateLimitInterval および RateLimitBurst 設定を調整することを意味します。

DHCP および DNS サーバーのトラブルシューティング

以下のセクションでは、設定と DNS、DHCP、および TFTP サーバーのトラブルシューティングについて説明します。

即時のトラブルシューティングアクション

問題が発生したときには、最初の問題を分離して修正する際、損害を拡大しないようにすることが重要です。特に、次のことを実行する（または実行しない）ことが重要です。

512 MB 以上のメモリと 2.5 GB 以上のデータパーティションがあること。
ケーブルモデム終端システム（CMTS）を再起動しないでください。
DHCP フェールオーバーを有効または無効にします。フェールオーバーパートナーのいずれかが動作していない場合は、実行中のサーバーを PARTNER-DOWN モードにします（パートナーがすぐにサービスに戻る可能性が低いと思われる場合）。
フェールオーバーの再同期が進行中は、Cisco Prime Network Registrar をリロード、再起動、または中断しないでください。

サーバー障害のトラブルシューティング

サーバーエージェントプロセス（nwreglocal および nwregregional）は、通常、サーバー障害を検出して、サーバーを再起動します。通常、障害から回復でき、サーバーが再起動後すぐに再び障害を起こすことはありません。まれに、サーバー障害の原因によってサーバーの正常な再起動が妨げられ、再起動するとすぐにサーバーが再び障害を起こすことがあります。このような場合は、次の手順を実行します。

手順

ステップ 1

サーバーの再起動にかなり時間がかかる場合は、サーバーエージェントを停止して再起動します。

systemctl stop nwreglocal or systemctl stop nwregregional
systemctl start nwreglocal or systemctl start nwregregional

ステップ 2

すべてのログファイルのコピーを保存します。ログファイルは /var/nwreg2/{local | regional}/logs ディレクトリにあります。ログファイルには、サーバー障害の原因を特定するのに役立つ有用な情報が含まれていることがよくあります。

ステップ 3

TAC ツールの使用の説明に従って TAC ツールを使用するか、またはコアファイルがあればそれを保存します。コアファイルは install-path にあります。Cisco Prime Network Registrar が上書きしないように、このファイルのコピーを名前を変更して保存します。

トラブルシューティングツール

また、次のコマンドを使用して Cisco Prime Network Registrar のトラブルシューティングを行うこともできます。目的：

すべての Cisco Prime Network Registrar プロセスを表示します。
```
ps -leaf | grep nwr
```
システムの使用状況とパフォーマンスをモニターします。
```
top
vmstat
```
ログインまたはブートアップエラーを表示します。
```
grep /var/log/messages*
```
設定されているインターフェイスおよびその他のネットワークデータを表示します。
```
ifconfig -a
 
```

TAC ツールの使用

多くのトラブルシューティング手順でも問題を解決できないときには、最後の手段として、Cisco Technical Assistance Center（TAC）に連絡して支援を受ける必要がある場合があります。Cisco Prime Network Registrar は、サーバーまたはシステムエラー情報を簡単に収集して、このデータを TAC サポートエンジニアのためにパッケージ化するためのツールを提供します。これにより、TAC の支援によってこの情報を手動で収集する必要がなくなります。このツールによって生成されたパッケージは、エンジニアが問題を迅速かつ簡単に診断し、解決策を提供できるだけの十分なデータを提供します。

cnr_tactool ユーティリティは install-path/usrbin ディレクトリにあります。cnr_tactool ユーティリティを実行します。

> cnr_tactool -N username -P password [-d output-directory] [-c #-cores] [-n]

出力ディレクトリはオプションであり、通常はインストールディレクトリの temp ディレクトリです（/var パスにあります）。-n オプションを指定すると、cnr_exim ツールが実行されるときに、リソースレコードをエクスポートせずに実行することを指定できます（これは、cnr_exim に対して -a none オプションを指定します）。Cisco Prime Network Registrar 11.0 以降、cnr_tactool はデフォルトでは 3 つのコアファイルのみを取得します。これらのファイルは経過日数が 30 日未満のもののみです。-c #-cores オプション（最大 150 コアファイル）を指定すると、より多くのコアファイルを収集できます。

コマンドラインでユーザー名とパスワードを指定しなかった場合は、次のプロンプトが表示されます。

> cnr_tactool 
user:
password:
[processing messages....]

このツールは、名前に日付とバージョンを含むパッケージ化された tar ファイルを生成します。tar ファイルには、すべての診断ファイルが含まれています。cnr_tactool は、過去 60 日間の Cisco Prime Network Registrar の systemd ジャーナルのエントリも抽出します。これは、製品の起動に関する問題を理解するのに役立つ場合があります。

（注）

Cisco Prime Network Registrar のコンテナの場合、コアファイルを収集で『Cisco Prime Network Registrar 11.0 Installation Guide』の「Running Cisco Prime Network Registrar Docker Container」の項に記載されている手順に従っていない場合は、Docker ホストマシンの /var/lib/systemd/coredump ディレクトリ（デフォルトの場所）から手動で tar および gzip を実行する必要があります。

statscollector ユーティリティの使用

Cisco Prime Network Registrar には、ローカルクラスタの CCM サーバーによって収集された統計情報を読み取る statscollector ユーティリティが含まれています。これには、次のようなオプションがあります。

クラスタから CCM サーバーの履歴を取得します。現在利用可能な履歴を取得し、必要に応じて新しい履歴が利用可能になったときに引き続き収集し、それをファイルに書き込むことができます。このファイルは、後で処理したり追加することができます。デフォルトでは statscollector は「恒久的」に実行して履歴を収集し続けることに注意してください。-i 0 を指定することにより、現在の履歴を取得し、そこで終了するように要求することができます。ファイルが存在する場合は、その履歴データを読み取って、収集された「最後の」サンプルを判別し、そこから追加のデータを収集し始めます（そのため、-i 0 を指定して実行することにより、多くの場合、「新しい」履歴だけを取得できます）。1 つのファイルを別のクラスタにも使用すると、2 つのクラスタデータが混在し、ほとんど役立たなくなる可能性があることに注意してください。

例：
```
statscollector -C cluster -N user -P password stats.bin
```
以前にファイルに収集された統計データまたはクラスタから取得された統計データの XML（Excel などのツールへのインポート用）を生成します。
- 例（既存のファイルを使用）：
```
statscollector -e stats.xml stats.bin
```
- 例（クラスタからの収集）：
```
statscollector -C cluster -N user -P password -e stats.xml
```
以前にファイルに収集された統計データまたはクラスタから取得された統計データの HTML（Google Charts API を使用）を生成します。組み込みグラフを使用するか独自のグラフを定義し、それらをプロットできます。
- 例（既存のファイルを使用）：
```
statscollector -h stats.html stats.bin
```
- 例（クラスタからの収集）：
```
statscollector -C cluster -N user -P password -h stats.html
```

次の場所から statscollector を実行できます。

/opt/nwreg2/local/usrbin

次のオプションを使用できます。

表 8. statscollector のオプション
オプション	説明
-C cluster:[port]	接続するローカルクラスタ（デフォルト：localhost）。
-N admin	管理者アカウント名。
-P password	管理者パスワード。
-i interval	新しい統計をポーリングする間隔（デフォルト：60 秒）。これを 0 に設定すると、1 回読み取った後に終了します。
-e file.xml	バイナリデータファイルを XML 形式でエクスポートします。注：-i により、使用するデータのサンプリングの最小間隔が制御されます（デフォルト：1 秒）。
-h file.html	統計グラフを含む HTML ファイルを作成します。注：-i により、使用するデータのサンプリングの最小間隔が制御されます（デフォルト：1 秒）。
-c charts.txt	-h の場合は、オプションのチャート定義ファイルが作成されます。
-s date time	指定した日時より前の統計サンプルを無視します。
-f date time	指定した日時より後の統計サンプルを無視します。
-w width X height	グラフの幅と高さをピクセル単位で指定します（デフォルト：800 X 400）。
-j name,value	Google 注釈グラフオプションを指定します。
-t "title"	グラフのタイトル（デフォルトを上書きする）。
-u infile.html	ソース HTML ファイル内のグラフを更新します。-h オプションが必要です。
file	バイナリデータファイル（-e または -h が指定されていない場合に必要）。ファイルが存在する場合、データはファイルに追加されます。

（注）

XML または HTML にエクスポートする場合、収集される統計情報によっては、生成されるファイルが非常に大きくなる可能性があります。-i、-s、および -f オプションを使用することにより、データを制限できます。たとえば、-i 300 は、エクスポートされたデータが 5 分ごとにのみレポートされることを意味します。ただし、特定の（より短い）時間間隔のデータを表示するには、-s と -f の方が効果的である場合があります。

TFTP サーバーのトラブルシューティングと最適化

特定の属性を設定して、TFTP サーバーのパフォーマンスをトラブルシューティングし、最適化することができます。

TFTP サーバーアクティビティのトレース

TFTP サーバーのアクティビティをトレースするには、TFTP サーバーでトレースファイルへのメッセージの書き込みに使用する冗長性のレベルに応じて、packet-trace-level 属性を 1 ~ 4 の値に設定します。トレースファイルは、インストールディレクトリの /logs サブディレクトリにあります。トレースは /var/nwreg2/{local | regional}/logs/file_tftp_1_log と file_tftp_1_trace ファイルに移動します。

次にトレースレベルを示します。レベルが高いほど累積的です。

0 - すべてのサーバートレースを無効にします（デフォルト）。
1 - トレースファイル内のすべてのログメッセージを表示します。
2 - すべてのパケットのクライアント IP アドレスとポート番号を表示します。
3 - パケットのヘッダー情報を表示します。
4 - パケットの最初の 32 バイトを表示します。

（注）

トレースレベルの設定と取得は、TFTP サーバーが起動している場合にのみ機能します。パフォーマンス上の理由から、パケットトレースはデバッグ目的でのみ有効にして、その後は長時間使用しないようにします。

TFTP メッセージロギングの最適化

ロギングとトレースを制限することによって、TFTP サーバーのパフォーマンスを向上させることができます。デフォルトでは、サーバーはエラー、警告、および情報メッセージを file_tftp_1_log ファイルに記録します。次のいくつかの TFTP サーバーパラメータを使用して、ログレベルを設定できます。

Log level （log-level 属性を使用）：サーバーロギングのプライマリコントローラであり、レベル 3（エラー、警告、および情報メッセージのすべてをログに記録）に事前設定されており、そのままにしておくことをお勧めします。パケットトレースと同様に、ロギングレベルが高いほど累積的です。0 に設定すると、サーバーロギングは行われません。
Log settings （log-settings 属性を使用）- これはロギング制御の第 2 レベルであり、default または no-success-messages の 2 つの値のいずれかを取ります。default ログ設定では、ログレベル 3 のデフォルト値は変更されません（エラー、警告、および情報メッセージ）。ただし、ログ設定を no-success-messages に変更することによって、成功情報メッセージの書き込みを無効にして、サーバーのパフォーマンスを向上させることができます。
Log file count and size （log-file-count 属性を使用）- /logs ディレクトリに維持するログファイルの数と、最大許容サイズを設定します。デフォルト値では、それぞれ 10 MB のファイルを最大 10 個まで維持します。

（注）

これらの値を変更した後は、TFTP サーバーをリロードしてください。

TFTP ファイルキャッシングの有効化

サーバーのファイルキャッシングを有効にすることで、TFTP サーバーのパフォーマンスを大幅に向上させることができます。これは、無効に事前設定されているため、明示的に行う必要があります。また、ファイルキャッシュディレクトリを作成してポイントする必要があります。また、このディレクトリの最大サイズを設定することができます。次に、手順を示します。

手順

ステップ 1	TFTP キャッシュファイルの移動先を決定します。これは TFTP ホームディレクトリのサブディレクトリになり、/var/nwreg2/{local \| regional}/data/tftp に事前設定されています。別の場所を使用する場合は、home-directory 属性を設定します。
ステップ 2	TFTP ホームディレクトリに移動し、mkdir Cachedir コマンドを使用して、ホームディレクトリに CacheDir などのキャッシュディレクトリを作成します。Cisco Prime Network Registrar は、このキャッシュディレクトリのサブディレクトリにあるすべてのファイルを無視することに注意してください。
ステップ 3	file-cache-directory 属性を使用して、キャッシュディレクトリを指すように TFTP サーバーを設定します。ディレクトリ名に絶対パスまたは相対パスを使用することはできません。file-cache-directory 名は home-directory か、またはデフォルトのホームディレクトリパスで指定されたパスに付加されます（いずれかを指定しなかった場合）。
ステップ 4	file-cache-max-memory-size 属性を使用して、キャッシュの最大メモリサイズをバイト単位で設定します。プリセット値は 32 KB です。Cisco Prime Network Registrar は、このメモリサイズに累積的に適合するすべてのファイルをキャッシュにロードします。値を 0 に設定した場合、ファイルキャッシングを有効にした場合でも、Cisco Prime Network Registrar はデータをキャッシュしません。
ステップ 5	キャッシュしたいすべてのファイルを、サブディレクトリではなく、キャッシュディレクトリにコピーします。このディレクトリ内のすべてのファイルはキャッシュにロードされるため、大きなファイルを含めないでください。
ステップ 6	file-cache 属性を有効にして、ファイルキャッシングを有効にし、サーバーをリロードします。Cisco Prime Network Registrar は、キャッシュされた各ファイルの名前を記録し、ロードできないものをすべてスキップします。すべてのファイルをバイナリデータとして読み取り、TFTP クライアント要求として変換します。たとえば、クライアントが NetASCII としてファイルを要求した場合、クライアントはその形式でキャッシュされたデータを受信します。
ステップ 7	キャッシュへの書き込みは許可されていません。キャッシュファイルを更新する必要がある場合は、キャッシュディレクトリで上書きしてから、サーバーをリロードします。

偏向のない言語

翻訳について

検索結果

章のタイトル： サーバーとデータベースの保守

サーバーとデータベースの保守

サーバーの管理

ローカル基本または詳細とリージョン Web UI

CLI コマンド

反復タスクのスケジューリング

ローカル基本または詳細 Web UI

手順

CLI コマンド

ログ

ログ ファイル

CLI コマンド

サーバー イベントのロギング

ローカル基本または詳細とリージョン Web UI

関連項目

ロギングの形式と設定

ローカル基本または詳細とリージョン Web UI

CLI コマンド

ログの検索

変更ログの表示

ローカルおよびリージョン Web UI

CLI コマンド

サーバー ログ設定の動的更新

ローカル基本または詳細 Web UI

手順

ローカル基本または詳細 Web UI

手順

CLI コマンド

データ整合性ルールの実行

ローカルおよびリージョン Web UI

手順

CLI ツール

サーバー ステータスのモニターリングと報告

関連項目

サーバーの状態

正常性の表示

サーバーの正常性ステータス

ローカル基本または詳細とリージョン Web UI

CLI コマンド

統計の表示

ローカル基本または詳細とリージョン Web UI

CLI コマンド

DNS 統計

CDNS 統計

DHCP 統計

TFTP 統計

IP アドレスの使用状況の表示

ローカル詳細およびリージョン Web UI

CLI コマンド

関連サーバーの表示

関連項目

永続イベントを使用したリモート サーバーのモニターリング

DNS ゾーン分散サーバー

ローカル基本または詳細 Web UI

リージョン Web UI

CLI コマンド

DHCP フェールオーバー サーバー

ローカル基本または詳細 Web UI

CLI コマンド

リースの表示

ローカル基本または詳細 Web UI

ローカル詳細およびリージョン詳細 Web UI

cnr.conf ファイルの変更

Syslog のサポート

DHCP および DNS サーバーのトラブルシューティング

関連項目

即時のトラブルシューティング アクション

サーバー障害のトラブルシューティング

手順

トラブルシューティング ツール

TAC ツールの使用

statscollector ユーティリティの使用

TFTP サーバーのトラブルシューティングと最適化

関連項目

TFTP サーバー アクティビティのトレース

TFTP メッセージ ロギングの最適化

章のタイトル：サーバーとデータベースの保守

ログファイル

サーバーイベントのロギング

サーバーログ設定の動的更新

サーバーステータスのモニターリングと報告

永続イベントを使用したリモートサーバーのモニターリング

DHCP フェールオーバーサーバー

即時のトラブルシューティングアクション

トラブルシューティングツール

TFTP サーバーアクティビティのトレース

TFTP メッセージロギングの最適化

TFTP ファイルキャッシングの有効化