CNR の設定と管理に関する推奨事項

ダウンロード オプション

  • PDF     (314.5 KB)
    Adobe Reader を使ってさまざまなデバイスで表示
  • ePub     (87.8 KB)
    iPhone、iPad、Android、ソニーの Reader、または Windows Phone 上で、さまざまなアプリを使って表示
  • Mobi (Kindle)     (83.3 KB)
    Kindle デバイスで、または Kindle アプリを使って複数のデバイスで表示
Updated: 2005 年 10 月 26 日
Document ID:13390

偏向のない言語

この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブ ランゲージの取り組みの詳細は、こちらをご覧ください。

翻訳について

シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版（リンクからアクセス可能）もあわせて参照することを推奨します。

概要

この記事には 2 つの目的があります。第 1 に、パフォーマンスと安定性を最適化するための Cisco Network Registrar（CNR）の設定方法、および CNR のインストールを監視する方法に関する推奨事項を説明します。第 2 に、問題発生時の対処法に関する推奨事項を説明します。理想的には、問題が発生する前にこの記事を読み、設定と監視の推奨事項に基づいて対策を行うことが望まれます。これにより、問題を回避できます。CNR で問題が発生したために、初めてこの記事を読んでいる場合は、ただちに「Immediate Actions When Facing a Problem」の項を参照してください。推奨事項の詳細な説明については、CNR のユーザ ガイド、およびコマンド リファレンスを参照してください。

前提条件

要件

このドキュメントに特有の要件はありません。

使用するコンポーネント

このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

表記法

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

標準設定

ここで説明する設定の推奨事項が、出発点になります。使用中のシステムの設定がここでの説明とは異なる場合は、設定を見直してください。設定は、旧バージョンの CNR から発展している場合があります。CNR 5.0 以降のバージョンは、旧バージョンと比較するとパフォーマンスが大きく向上していますが、パフォーマンスを最大にするには、パラメータを変更する必要があります。この文書は主に大規模なサービス プロバイダー環境を対象としていますが、推奨事項の多くはその他の CNR 環境にも適用できます。このドキュメントの想定事項を以下に示します。

  • 加入者が 10,000 名以上のブロードバンド ネットワークを運営しているサービス プロバイダーである。

  • CNR 5.0.3 以降を使用している。

  • Lightweight Directory Access Protocol（LDAP）を使用している。CNR は LDAP なしで動作しますが、多くのサービス プロバイダーで LDAP が使用されています。

  • ネットワークの IP アドレスの飽和度は中程度である。

  • UNIX サーバで CNR を実行している。ほとんどの推奨事項が Windows NT にも同じように適用されますが、ほとんどのサービス プロバイダーが UNIX サーバで CNR を実行しているため、UNIX と NT が異なる場面では、UNIX の例を使用します。

  • 別のサーバで実行されているその他のシステム（課金、カスタマー ケア、プロビジョニングなど）へのアップストリーム接続がある。

  • ダイナミック ドメイン ネーム システム（DDNS）がサイトでアクティブにならない（ほとんどのサービス プロバイダーが DDNS を使用していないため）。

設定とセットアップの推奨事項

初期計画およびセットアップ

  • IP アドレスの割り当てを計画し、文書化します。

  • ディスク集約型処理を分離します。プライマリ DHCP サーバを、LDAP サーバおよびプライマリ DNS サーバとは異なるコンピュータに配置します。

  • ケーブル モデム終端システム（CMTS）の設定を文書化します。CMTS と CNR の設定が一致することを確認します。

  • 災害復旧計画を準備します。

  • ネットワーク トポロジを文書化します。

  • CMTS の Cisco IOS® Software バージョンをメモします。

ネットワークの正常性を長期間維持するための最も効率的なステップは次のとおりです。a) 設定を計画して、b) その計画を記録し、c) 変更が計画され、実行に移されたときに変更を記録します。選択の理由を文書化しておくと、将来の計画セッションで役立ちます。

一般的なシステムの設定

  • セーフ フェールオーバーを使用します。1 つのサーバがすべてのスコープのメインになり、もう 1 つのサーバがすべてのスコープのバックアップになる単純なフェールオーバー（両方のサーバが個別のスコープに応じて同時にメインとバックアップになる対称フェールオーバーとは対照的）を強くお勧めします。これは、管理タスクが大幅に簡素化されるためです。

  • Simple Network Management Protocol（SNMP）トラップをオンにします。次に例を示します。

    nrcmd> trap enable address-conflict
nrcmd> trap enable dhcp-failover-config-mismatch
nrcmd> trap enable other-server-not-responding
nrcmd> trap set free-address-low-threshold=15%
nrcmd> trap set free-address-high-threshold=30%
nrcmd> trap enable free-address-low

  • 十分な RAM（512 MB 以上）が搭載されていることを確認します。

  • データ区画が十分な大きさ（2.5 GB 以上）であることを確認します。

  • ログとデータには別々の区画を使用します。

  • サーバ間の高速/低遅延接続を保証します。インターフェイス設定を確認します。

SNMP トラップを使用すると、ネットワーク モニタから DHCP サーバを監視できます。必ず DHCP サーバでトラップを設定し、トラップを受信し表示するようモニタを設定します。また当然ですが、必ずモニタに注意を払ってください。

実稼働システムの設定では、コストとシステム効率のトレードオフが必要となります。およそ 100,000 名の加入者が、フェールオーバーを実行する E250 クラスのシステム上に存在することを想定して、これらの値を設定することをお勧めします。ポリシー、クライアント クラス、スコープ、要求バッファと応答バッファ、DHCP 拡張などの複雑な機能を多用すると、メモリのニーズとパフォーマンスに影響が出ます。

ログの数とサイズが大きくなった場合は、ログの区画（/var/nwreg2）を大きくする必要があります。

DHCP 設定。

  • スループットを最適化するように、要求と応答のバッファを設定します。これらの推奨事項は、CNR 5.0 で変更されていることに注意してください。

    nrcmd> DHCP set max-dhcp-requests=500
nrcmd> DHCP set max-dhcp-responses=2000

  • ケーブル モデムのリース時間 = 604800（7 日）以上

  • 顧客宅内機器（CPE）のリース時間：できるだけ長く（トレードオフについては、「注」を参照してください）。

  • 次のように、DHCP と TFTP のログ サイズを大きくします。

    nrcmd> server DHCP serverLogs nlogs=15 logsize=10M
nrcmd> server DNS serverLogs nlogs=15 logsize=10M
nrcmd> server TFTP serverLogs nlogs=10 logsize=10M

  • 問題を特定するのに十分な情報を提供するが、過剰な詳細（問題の判別を困難にし、サーバに不必要な負荷をかける）は生成しないように、ログ設定を構成します。 一般的に適用可能な推奨設定を次に示します。必要に応じて設定を調整して、ネットワークの問題に対処します。

    • Activity-summary

    • デフォルト

    • No-failover-activity

    • defer-lease-extensions を有効化

    • last-transaction-time-granularity = 1/2 リース間隔の設定

    • production lease を提供するポリシーの allow-client-lease-override の無効化

    • fall-back-to-local の有効化、LDAP が使用できない場合は、CNR でローカル データが使用される

      nrcmd> session set visibility=3
nrcmd> dhcp enable fallback-to-local-client-data
nrcmd> session set visibility=5

  • CNR 5.5 以降を使用している場合は、LDAP クエリを半分に減らすように client-cache 機能を設定します。

    nrcmd> dhcp set client-cache-count=2000
nrcmd> dhcp set client-cache-ttl=5

CNR のスループット能力を最も効率的に使用するには、要求バッファの 3 ～ 4 倍の応答バッファが必要になります。システムは、必要な量のバッファのみを使用します。リース時間が短くなるほど、必要な応答バッファが増えます。

注：リース時間は実用的な限り設定する必要があります。ケーブル モデムのリースはプライベート アドレス空間（通常は net-10）から発生し、またモデムはネット上で別の場所に移動することはまずありません。このようなリースは、1 週間以上にする必要があります。一方、CPE リースはパブリック アドレス空間から発生し、また CPE（特にラップトップ）は頻繁に移動します。リース期間は、ユーザ グループの傾向と一致するように設定する必要があります。リースを長くすると、DHCP サーバの負荷が軽減されます。短いリース（8 時間以下）を使用する場合は、応答バッファを 2500 まで大きくします。

allow-client-lease-override を無効にして、クライアントが、CNR 設定で指定されたリース時間を順守するようにします。クライアントによって、指定された設定をオーバーライドしようとする場合があります。

LDAP サーバに障害が発生した場合にもネットワークの稼働を維持するため、fall-back-to-local を有効にします。この設定を使用すると、LDAP サーバが応答しない場合でも、DHCP サーバは引き続きリース要求を満たします。サーバは、LDAP サーバに格納されている特定のクライアント情報にアクセスできないため、デフォルト設定を使用してそれぞれの要求を満たします。ネットワークに適したデフォルトを設定する必要があります。

最後に、LDAP から取得されたクライアント データを client-cache 機能がメモリ内に保持します。これにより DHCP サーバが discovery-offer-request-ack サイクル中に一回だけ LDAP に問い合わせるため、DHCP サーバ パフォーマンスが向上します。

DNS 設定

  1. 次のように、差分転送機能を有効にします。

    nrcmd> dns enable ixfr-enable

  2. 通知を有効にします。通知を有効にする必要がある引数については、『CNR CLI Command References』を参照してください。

  3. プライマリとセカンダリの DNS サーバを、別々のネットワーク セグメントに配置します。

  4. セカンダリ DNS サーバを照会するようクライアントを設定します。

セカンダリ DNS サーバは、次の 2 つの方法のどちらかでプライマリ サーバからデータを受信します：a) 「完全ゾーン転送」または b) 「notify/ixfr」（増分転送）。 notify/ixfr を使用すると、プライマリ サーバからセカンダリ サーバに転送しなければならないレコードの数が少なくなります。これは、名前空間が比較的ダイナミックである場合に非常に重要です。

TFTP の設定

  • 次のように、initial-packet-timeout を 2 に設定します。

    nrcmd> tftp set initial-packet-timeout = 2

  • CNR 5.5 以降を使用している場合は、TFTP ファイル キャッシュを有効にしてパフォーマンスを向上させます。

    nrcmd> tftp set home-directory=/var/nwreg2/data/tftp
nrcmd> tftp set file-cache-directory=CacheDir
nrcmd> tftp set file-cache-max-memory-size=32000
nrcmd> tftp enable file-cache
nrcmd> tftp reload

TFTP ファイル キャッシュは、メモリ内に保存されたケーブル モデム コンフィギュレーション ファイルを維持することによって、ケーブル モデムがコンフィギュレーション ファイルを要求するたびにディスクを読み取らなくても済むようにします。ハード ドライブ上にファイル キャッシュ ディレクトリ（上の例では CacheDir）を作成する必要があり、最大サイズをそれに割り当てます。システム内の RAM の総容量と必要なさまざまなコンフィギュレーション ファイルの数を考慮してサイズを選択します。

TFTP プロトコルでは、クライアントがファイルの受信時に最終確認応答（ACK）パケットを送信する必要がありません。ACK が受信されない場合は、サーバがタイムアウトするまでクライアント接続を維持する必要があるため、新しい要求を処理する能力が制限されます。TFTP サーバにリソースのキャパシティがある場合は、max-tftp-packets の値を大きくして、より多くのクライアント接続をサポートすることもできます。このパラメータのデフォルト値は512です。最大値は1000です。

CNR LDAP の設定

以下の設定は、CNR がリースの更新を LDAP に書き込む設定を示しています。可能であれば、これが必要ないようにネットワークを設計します。ここでこの設定が示してあるのは、リースの更新を書き込まなければならない場合の推奨事項を説明するためです。個別に調整可能な READ/WRITE LDAP オブジェクトを使用して、LDAP 接続を最適化します（オブジェクトごとに個別のスレッド グループが割り当てられます）。

# Create and Configure a New LDAP Create/Update object
     ldap LDAP-Write create csrc-ldap
     ldap LDAP-Write set password=changeme
     ldap LDAP-Write set port=389
     ldap LDAP-Write set preference=1
     ldap LDAP-Write setEntry query-dictionary csrcclientclass=client-class-name
     ldap LDAP-Write set reactivate-interval=60s
     ldap LDAP-Write set search-filter=
     (&(macaddress=%s)(|(csrcclassname=Computer)(csrcclassname=Modem)))
     ldap LDAP-Write set search-path=csrcprogramname=csrc,o=NetscapeRoot
     ldap LDAP-Write set username=
     "uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot"
     ldap LDAP-Write set can-query=disabled
     ldap LDAP-Write set can-create=enabled
     ldap LDAP-Write set can-update=enabled
     ldap LDAP-Write set connections=2
     ldap LDAP-Write set limit-requests=enabled
     ldap LDAP-Write set max-requests=8
     ldap LDAP-Write set timeout=30s

### Create and Configure a New LDAP Read object
     ldap LDAP-Read create csrc-ldap
     ldap LDAP-Read set password=changeme
     ldap LDAP-Read set port=389
     ldap LDAP-Read set preference=1
     ldap LDAP-Read setEntry query-dictionary csrcclientclass=client-class-name
     ldap LDAP-Read set reactivate-interval=60s
     ldap LDAP-Read set search-filter=
     (&(macaddress=%s)(|(csrcclassname=Computer)(csrcclassname=Modem)))
     ldap LDAP-Read set search-path=csrcprogramname=csrc,o=NetscapeRoot
     ldap LDAP-Read set username=
     "uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot"
     ldap LDAP-Read set can-query=enabled
     ldap LDAP-Read set can-create=disabled
     ldap LDAP-Read set can-update=disabled
     ldap LDAP-Read set connections=3
     ldap LDAP-Read set limit-requests=enabled
     ldap LDAP-Read set max-requests=12
     ldap LDAP-Read set timeout=3s

上記の設定には、CNR にリースの更新を LDAP へ書き込ませる処理が含まれています。この設定を行うと、アプリケーションが現在のリース情報を LDAP に照会できるようになりますが、このような設定が必要なアプリケーションの構成は避けるようにする必要があります。IP アドレスのリース状態に関する情報を使用できるようにする必要がある場合は、NRCMD lease コマンドを使用して、現在のリース状態に関する MAC アドレスや有効時間、またはその他の情報を取得します。

LDAP ディレクトリは高速かつ効率的に読み取れるよう設計されていますが、LDAP ディレクトリへの書き込みは非効率的です。LDAP にリース情報を書き込むように CNR を設定した場合は、LDAP がシステム全体のパフォーマンスに対するボトルネックになります。LDAP リース書き込みを設定する必要がある場合は、推奨設定を使用します。LDAP への CNR のアクセスは、独立した「read」および「update LDAP」オブジェクトを使用して最適化されていることに注意してください。また、30 秒の書き込みタイムアウトにも注意してください。タイムアウト時間が短いと、LDAP の負荷が大きい場合に、LDAP 書き込みがタイムアウトになるリスクが生じます。また CNR が書き込みを再試行し、LDAP への負荷がさらに大きくなります。

LDAP サーバへの接続の総数は、使用可能なスレッドの最大数を超えることができません。LDAP サーバが接続あたり複数のスレッドをサポートしている場合、接続の最適数は、スレッドの総数を接続あたりのスレッド数で割った値になります。

LDAP サーバの調整パラメータ

  • ルックアップ フィールドのインデックスを作成します。

  • メモリ内にキャッシュされるエントリの数を大きくするため、キャッシュ サイズを設定します。ただし、キャッシュは使用可能なメモリの 3 分の 1 以下にする必要があります。

  • サポート可能な同時接続の数を大きくするため、最大スレッドを設定します。ただし、これは使用可能なリソースの半分以下にする必要があります。

  • 問題を特定するのに十分な情報を提供するが、過剰な詳細（問題の判別を困難にし、サーバに不必要な負荷をかける）は生成しないように、ログ設定を構成します。

  • ログとデータには別々の区画を使用します。

LDAP サーバによって実装が異なります。これらの推奨事項を実装するには、サーバのマニュアルを参照してください。

通常の手順

  • CNR データベースを定期的にバックアップします。その手順については、ユーザ ガイドを参照してください。1 日 1 回以上、CNR データベースをバックアップしてください。バックアップ ファイルは、少なくとも 2 週間は保持してください。

  • LDAP を定期的にバックアップします。

  • ログを定期的にバックアップしてアーカイブします。

  • CNR を変更した後には、フェールオーバー シナリオのメイン サーバとバックアップ サーバの設定が一貫していることを確認してください。CNR バージョン 5.5 以前では cnrFailoverConfig -compare ツールを使用し、CNR 6.0 以降では WebUI を使用してコンフィギュレーションを比較します。

  • ネットワーク トポロジの変更を計画している場合は、DHCP の更新時間とリース時間を小さな値に設定します。

  • IP アドレスの使用状況を監視します（SNMP トラップを使用）。

  • システムの使用状況（メモリ、ディスク、CPU、およびスワップ）を監視します。 これには、ユーティリティ top が便利です。

  • 定期的にログを確認して、通常のケースに関する知識を深めます。正常なログの状態を理解しておくと、より迅速に問題に対処できます。

  • 定期的にログを調べて例外を確認します。"error"、"warn"、または "connect" で grep 検索します（たとえば、UNIX では grep -i warn name_dhcp_1_log を使用します）。

DHCP セーフ フェールオーバーでは、スコープに関して、プライマリ サーバとバックアップ サーバでそのスコープの設定は同じである必要があります。設定を変更する際には、必ず両方のサーバで変更を行います。定期的に、cnrFailoverConfig -compare または CNR 6.0 以降の WebUI を使用して、違いがないことを確認します。

ネットワーク トポロジの変更または IP アドレス割り当ての変更により、クライアントが別のアドレスを取得する必要が生じる場合があります。サブネット上の一部のクライアントが古い範囲からのアドレスを保持し、また一部のクライアントがアドレスを更新し新しい範囲からのアドレスを取得する期間を計画しておく必要があります。すべてのクライアントが短期リースを保持するように変更を行う前に、リースの長さを短くすることで、両方のアドレスのセットがアクティブである期間を短くすることができます。これにより、クライアントはリースを頻繁に更新する必要があるため、ユーザが変更を加えた直後にクライアントは新しい範囲からリースを得るようになります。変更を反映させるためにサーバを停止/再起動している間にリースが使い果たされる可能性があるため、リース時間を短く設定しすぎないようにしてください。変更後は、サーバの負荷が増大しないように、必ず元のリース期間に戻してください。

問題を解決する最も効果的な方法は、問題を回避することです。前述の推奨事項に従うことによって、管理者は円滑な運用を維持し、深刻な問題を回避することができます。（原因不明の I/O 待機時間の増加やメモリ使用量の増加などの）問題が発生していると思われる場合は、ログを追跡してください。物理環境や CNR 設定への最近の変更を見直して、それが問題の発生源である可能性があるかどうかを確認します。

CNR のログは問題解決に役立ちます。CNR の使用開始時、CNR のアップグレード時、または CNR 設定の変更時には、説明した grep コマンドを使用して、ログに問題がないかをチェックします。その後、ログを過去に遡って、いつどのようにして問題が発生したかを調べ、問題を修復します。

問題発生時の緊急措置

  • シスコのサポート スタッフに指示された場合を除き、CMTS をリブートしないでください（ケーブル環境にのみ適用されます）。

  • シスコのサポート スタッフに指示された場合を除き、CNR を再起動しないでください。

  • シスコのサポート スタッフに指示された場合を除き、セーフ フェールオーバーを無効にしないでください。

  • セーフ フェールオーバーの再同期中に、CNR のリロード/再起動/中断を実行しないでください。

  • 上書きされないディレクトリに、ログ ファイルをコピーしてください。CNR がクラッシュした場合、上書きされないディレクトリにコア ファイルをコピーしてください。

  • 次のコマンドを使用して、

    nrcmd> server dhcp getRelatedServers

    セーフ フェールオーバーの設定ミスを切り離します。

  • ログを調べて、例外がないかを確認してください。特に起動シーケンスを検査します（これは古いログに存在する可能性があります）。この場合、「error」、「warn」、「connect」などを grep で検索（たとえば grep -i error name_dhcp_1_log* を使用）します。

問題に直面した場合は、最初の問題を特定して修復している間に、それ以上悪化させないことが非常に重要です。CMTS をリブートしたり CNR を再起動すると、システムがすでに不安定になっている場合には、負荷が急上昇します。目的は、最短時間でシステムの完全な機能を回復することです。最後のアクションを行うまでの経過時間が重要です。the time to your first action does not count.つまり、復旧作業に迅速に取りかかることのみに目を奪われて、拙速に復旧作業を行わないようにしてください。復旧作業の前には十分な検討が必要です。

システム内のあらゆる場所で実行されたすべてのステップとすべての変更のログから開始します。DHCP、DNS、または TFTP サーバと CMTS またはケーブル モデムに対する変更を含みます。観察可能な動作のみの、問題とログを詳細まで記述します。

ログ ファイルの分析

ログ（/var/nwreg2/logs）を収集します。 これらを分析し、エラーや警告を探します。テキスト エディタを使用して、関連するエラーをさらに分析します。エラーを先頭に、エラーに関連付けられた MAC アドレス、IP アドレス、またはドメイン名に関連するすべてのエントリを、ログファイルで遡って検索します。

DHCP の問題を診断するには、追加のロギングを有効にしなければならない場合もあります。DHCP サーバは、広範囲のロギング機能をサポートしています。ロギング オプションのリストとそれぞれの説明については、『CNR CLI Command References』を参照してください。ログ メッセージを追加すると、サーバへの負荷が増えることに注意してください。CNR に記録させる情報量とサーバ パフォーマンスのトレードオフを考慮する必要があります。

LDAP 問題のチェック

問題が LDAP サーバに関連する場合があります。CNR は、LDAP サーバに対する要求のキューを作成します。LDAP サーバが負荷を処理しきれない場合は、キューが蓄積されます。/var/nwreg2/data/dhcpeventstore ディレクトリを調べてください。イベント ストア ファイルのサイズは固定されているため、キューが蓄積されると、CNR が作成するファイル数が増えます。ディレクトリ内に複数のファイルが存在する場合は、キューが滞っていることを示しています。DDNS サーバに対する要求のキューイングに同じキューが使用されるため、キューが滞っていて、DDNS が使用されている場合には、DNS サーバに対する要求でキューがいっぱいになっている可能性があります。問題が LDAP に関するものであるかどうかを判別するには、追加の CNR LDAP インターフェイス ロギングを有効にします。ログ フラグ ldap-create-detail、ldap-query-detail、および ldap-update-detail を有効にします。ログ メッセージには、LDAP がシステムのボトルネックになっているかどうかの判別に役立つ、タイム スタンプが付けられています。

CNR の内部データベースの検証

CNR の 1 つ以上の内部データベースで完全性が失われた可能性がある場合は、CNR のユーザ ガイドで、データベース妥当性チェック ユーティリティの実行方法を参照してください。このようなユーティリティのいずれかが問題を指摘している場合は、ユーザ ガイドの指示に従って問題を解決します。

nslookup を使用した DNS データの検査

ユーティリティ nslookup は UNIX システムと Windows NT の両方に付属しています。DNS サーバの問い合わせに使用できるため、サーバにより格納されるデータの確認に便利です。オペレーティング システムのマニュアルには、その機能に関する詳細な情報が記載されています。

関連情報

このドキュメントは役に立ちましたか?

Feedbackフィードバック

シスコに問い合わせ