ブロードバンド ケーブル : ケーブル管理とサービス

ネットワーク上に複数のケーブル モデムがある状態での CNR パラメータの変更

2003 年 3 月 3 日 - ライター翻訳版
その他のバージョン: PDFpdf | 機械翻訳版 (2013 年 8 月 21 日) | 英語版 (2005 年 10 月 26 日) | フィードバック

目次

概要
はじめに
     表記法
     前提条件
     使用するコンポーネント
DHCP に対する変更
説明
関連するシスコ サポート コミュニティ ディスカッション
関連情報

概要

Cisco Network Registrar - Dynamic Host Configuration Protocol(CNR - DHCP; CNR - ダイナミック ホスト コンフィギュレーション プロトコル)サーバは、電源障害の発生とその回復後などのヘッドエンド リブートのイベントの際に、大量の要求によって過大な負荷を受ける場合があります。 以下で説明する変更を行うと、DHCP サーバがサービス要求をより迅速に、かつ効率的に処理できるようになります。

ここでは例として使用するために、max-dhcp-requests を 50 に設定しています。50 という値が、必ずしも常に最適な値というわけではありません。 たとえば、使用しているシステムの CPU が非常に低速である場合には、50 という値は高すぎる可能性があります。 唯一の最適値を計算する数学的な公式はありません。 まず 50 で試してみて、使用しているシステムに適しているかどうかを調べ、そこから調整していく必要があります。

はじめに

表記法

文書表記の詳細については、「シスコ テクニカル ティップスの表記法」を参照してください。

前提条件

本書の読者は、uBR シリーズ ルータにおける DOCSIS プロトコルと Cisco IOS(R) のコマンドラインの基本事項について、理解している必要があります。

使用するコンポーネント

この文書で使用するハードウェアは、Cisco uBR7200、uBR7100、または uBR10k CMTS と、DOCSIS 準拠のケーブル モデムです。

DHCP に対する変更

DHCP の設定に対して、次のような変更を行います。

nrcmd> dhcp set max-dhcp-requests=50
  

この設定変更を保存します。

nrcmd> save
  

次のコマンドにより、サーバを再起動します。

nrcmd> dhcp reload
  

caution 注意: このパラメータの他にも、このフィールドのサーバ パラメータを調整する際には、十分に注意してください。 「DHCP」を参照してください。

説明

ほとんどの環境では、多数の uBR が同時にリブートするなどの長時間にわたる DHCP メッセージのバーストにサーバが正しく対応できるようにする方法として、max-dhcp-requests の値を 500 から 50 に減らすことが最もよく知られています。

サーバがヘッドエンド リブートのイベントでの要求によって高い負荷を受けている場合は、 max-dhcp-requests の値を減らすことで、サーバに過剰な量のメッセージ、特に受信キューの中に古い DHCP メッセージが蓄積しないようにすることができます。 サーバの受信キューに大量のメッセージがあると、サーバが最新の DHCP メッセージ(すべてのクライアントが受け入れるもの)の処理よりも、古い DHCP メッセージ(一部のクライアントがドロップおよびリトライするもの)の処理に時間を取られてしまいます。 最適な値はサーバのハードウェアの CPU とディスク速度、ネットワーク特性などによって異なります。

パラメータ max-dhcp-requests は、着信する要求の保存のために DHCP サーバが割り当てるバッファの数を制御するものです。 ヘッドエンド リブートの後には、割り当てられているすべてのバッファは急激に満杯になります。 バッファが満杯になると、DHCP サーバは追加の要求を廃棄するようになり、要求を処理してバッファを解放してからのみ、新しい要求を受付けます。 最初に到着する少数の要求には、即座に応答があります。 その後に到着する要求は、着信バッファ キューに数秒間入れられます。 DHCP サーバが処理を行って応答する頃には、要求を送ったクライアントではすでにタイム アウトになっています。 これでは、DHCP サーバでの要求処理と応答のためのリソースが無駄になっていることになります。

クライアントではタイム アウトになるとリトライを行いますが、DHCP サーバではすぐに着信バッファ キューが満杯の状態になってしまっています。 キューが長く、すべてのキューを一掃して要求を受信するまでの時間がクライアントのタイムアウトである 4 秒より長くなるような数にバッファの数が設定されていると、要求への応答が遅くなりすぎます。 キューがいっぱいになると、要求が廃棄されたクライアントはリトライを行います。


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

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


関連情報


Document ID: 11094