ネットワーク上に複数のケーブル モデムがある状態での CNR パラメータの変更
概要
Cisco Network Registrar - Dynamic Host Configuration Protocol（CNR - DHCP）サーバは、電源障害の発生とその回復後などのヘッドエンド リブートの際に、大量の要求によって過大な負荷を受ける場合があります。これらの変更により、DHCP サーバはサービス要求に対してより迅速かつ効率的に対応できます。
この例では、max-dhcp-requestsは50に変更されています。50の値は最適ではない可能性があります。たとえば、使用しているシステムの CPU が低速である場合には、50 という値は高すぎる可能性があります。最適値を計算する数学的な公式はありません。まず 50 で試してみて、使用しているシステムに適しているかどうかを調べ、そこから調整していきます。
前提条件
要件
本書の読者は、uBR シリーズ ルータにおける DOCSIS プロトコルと Cisco IOS のコマンドラインの基本事項について、理解している必要があります。
使用するコンポーネント
この文書で使用するハードウェアは、Cisco uBR7200、uBR7100、または uBR10k CMTS と、DOCSIS 準拠のケーブル モデムです。
表記法
ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。
DHCP に対する変更
DHCP の設定に対して、次のような変更を行います。
nrcmd> dhcp set max-dhcp-requests=50
この設定変更を保存します。
nrcmd> save
次のコマンドにより、サーバを再起動します。
nrcmd> dhcp reload
注意：この特定のパラメータに加えて、フィールド内のサーバパラメータを調整することに注意してください。DHCP を参照。
説明
ほとんどの環境では、多数の uBR が同時にリブートするなどの長時間にわたる DHCP メッセージのバーストにサーバが対応できるようにする方法として、max-dhcp-requests の値を 500 から 50 に減らすことが最良の方法です。
ヘッドエンド リブートが行われると、サーバは大量の要求によって過大な負荷を受ける場合がありますmax-dhcp-requests の値を減らすと、サーバが大量のメッセージ、特に古い DHCP メッセージを受信キューに保存するのを防ぐことができます。サーバの受信キューに大量のメッセージがあると、最新の DHCP メッセージ（すべてのクライアントが受け入れるもの）よりも、古い DHCP メッセージ（一部のクライアントがドロップおよびリトライするもの）の処理に時間を取られてしまいます。 最適な値は次の要素によって異なります。
-
サーバ ハードウェア
-
CPU
-
ディスクのスピード
-
ネットワークの特性
max-dhcp-requests パラメータは、着信する要求の保存のために DHCP サーバが割り当てるバッファの数を制御するものです。ヘッドエンド リブートの後には、割り当てられているすべてのバッファは急激に満杯になります。バッファが満杯になると、DHCP サーバは追加の要求を廃棄するようになり、要求を処理してバッファを解放してからのみ、新しい要求を受付けます。サーバは、受け取った最初の数件の要求に迅速に応答します。それらの次の要求は数秒間バッファ キューに残ります。DHCP サーバが処理を行って応答する頃には、要求を送ったクライアントではすでにタイム アウトになっています。したがって、DHCP サーバのリソースが無駄になります。
クライアントはタイムアウトの後、再試行しますが、DHCP サーバの着信バッファ キューは急激に満杯になります。キューを処理して要求を受信するために、クライアントのタイムアウトである 4 秒より長くなるような数にバッファの数が設定されていると、要求への応答が遅くなりすぎます。キューがいっぱいになると、要求が廃棄されたクライアントは再試行します。
フィードバック