ブロードバンド ケーブル : ケーブル モデム

低速のケーブル モデム ネットワークのトラブルシューティング

2008 年 5 月 29 日 - ライター翻訳版
その他のバージョン: PDFpdf | 機械翻訳版 (2013 年 2 月 10 日) | 英語版 (2008 年 4 月 24 日) | フィードバック

目次


概要

Data-over-Cable Service Interface Specifications(DOCSIS)システムには、ケーブル モデムのパフォーマンスと速度に影響を与える可能性のある多くの問題があります。 この文書では、ケーブル サービス プロバイダーの見地から、低速スループットに関する主な原因に対処します。

この文書ではまず、エンドユーザ側で達成されているスループットのレベルを正確に確認する方法について述べ、測定したパフォーマンスが広域のインターネットではなくケーブル ネットワークのものであることを確認する方法を説明します。

その次の項で、低速のパフォーマンスに関して最も多く見られる潜在的な原因と解決案について考察します。 具体的には、次の問題があります。

  • DOCSIS コンフィギュレーション ファイル内の制限によって制約されたパフォーマンス
  • Cable Modem Termination System(CMTS; ケーブル モデム終端システム)において完全に最適化されていないレート制限方式を使用した、バースト性のある、または不安定なパフォーマンスのダウンロード
  • アップストリームおよびダウンストリームのチャネル輻輳
  • バックホール ネットワークまたはインターネットの輻輳
  • ケーブル装置におけるノイズやエラー
  • 機能不足の エンド ユーザ Customer Premises Equipment(CPE; 顧客宅内機器)

この文書では、ケーブル ネットワークで接続が完全に喪失されることや、またはケーブル モデムがオンラインにならないことに関するトラブルシューティングについては説明しません。 このような問題に関しては,「トラブルシューティング:uBR ケーブル モデムがオンラインにならない場合」を参照してください。 また、uBR 900 または CVA 120 シリーズのケーブル モデムの使用中にパフォーマンス問題の発生したエンドユーザに関しては、このような問題のトラブルシューティングを「uBR900 シリーズ ケーブル モデム エンド ユーザの初級 FAQ」から開始することをお勧めします。

ハードウェアとソフトウェアのバージョン

この文書の情報は、次のソフトウェアとハードウェアのバージョンに基づいています。
  • uBR7200 および uBR7100 CMTS のソフトウェア リリース 12.1(9)EC
  • Cisco uBR7100、uBR7200 および uBR7200VXR の CMTS 製品群
  • ループットとパフォーマンスに影響を与える場合があります。

    この文書では、ケーブル ネットワークで接続が完全に喪失されることや、またはケーブル モデムがオンラインにならないことに関するトラブルシューティングについては説明しません。 このような問題に関しては、「トラブルシューティング:uBR ケーブル モデムがオンラインにならない場合」を参照してくださいまた、uBR 900 または CVA 120 シリーズのケーブル モデムの使用中にパフォーマンス問題の発生したエンドユーザに関しては、このような問題のトラブルシューティングを「uBR900 シリーズ ケーブル モデム エンド ユーザの初級 FAQ」から開始することをお勧めします。

パフォーマンスの達成レベルを正確に確認する方法

システム上の正しい箇所の測定

システムの速度およびパフォーマンスを測定する方法は数多くありますが、テストされる箇所を正確に理解することが重要です。 次の図について考察します。

図 1(この図を Flash アニメーションとして表示するには、こちらをクリックします。)

この図には、多数のコンポーネントがあります。

  • エンドユーザと CMTS 間のハイブリッド ファイバ同軸ネットワーク
  • CMTS がケーブル サービス プロバイダーのネットワークに接続する、ローカルの CMTS ネットワーク セグメント
  • ケーブル サービス プロバイダーの内部ネットワーク
  • パブリック インターネット
2 地点間で速度テストを行うと、その 2 地点間のすべてのネットワーク コンポーネントの速度が測定されます。

たとえば、128 Kbps ISDN 回線経由でインターネットへ接続される CPE と、サーバ 3 との間の速度テストを行ったとします。この場合、ケーブルセグメントの帯域幅が 128 Kbps より広くても、128 Kbps を超える速度はあり得ません。

ケーブル セグメントそれ自体の最も正確な測定方法は、同じネットワーク セグメントへ CMTS として接続される CPE と サーバ 1 の間で速度テストを行うことです。 これは、パス データが経由する必要があるのは、同軸ケーブル セグメントだけであるためです。 このデータはローカルの CMTS ネットワーク セグメントも経由する必要がありますが、このセグメントの帯域幅は高く(ファーストイーサネット以上)であり、輻輳のレベルが高くないことが考えられます。

何らかの理由でサーバをローカルの CMTS ネットワーク セグメントへ接続できない場合、ケーブル セグメントのパフォーマンスをテストする次に正確な方法は、CPE とサーバ 2 の間の速度テストを行うことです。CMTS と CPE 間にあるケーブル サービス プロバイダーの内部ネットワークで十分な速度が出ていて、リンクが輻輳していない限り、この測定は正確です。

ケーブル セグメントのパフォーマンスに関して、最も不正確な確認方法は、CPE とパブリック インターネット上にあるサーバ間の速度テストを行うことです。 その理由は、サーバと CPE の間のパブリック インターネットで輻輳したリンクが存在するか、または インターネット上のサーバと CPE の間のパスに、非常に低速なリンクが存在する可能性があるためです。

ダウンロード レートおよびアップロード レートの確認

DOCSIS システムにパフォーマンスの問題があるかどうかを最終的に判断する前に、厳密にどれくらいのレベルのアップロードおよびダウンロードのスループットが達成されているかについて、客観的な測定を得ておくことが重要です。

アップロードおよびダウンロードが発生し得る速度を判定する最も簡単な方法は、ケーブル モデムに接続された CPE デバイスと CMTS の背後に配置されたサーバの間で、FTP または HTTP を使用して非常に大きいファイルをアップロードまたはダウンロードすることです。 ほとんどの FTP クライアントおよび HTTP クライアントは、転送中または転送の完了後に、実行されたダウンロードまたはアップロードの速度を表示できます。 FTP または HTTP の動作結果として表示されるこの転送速度は、通常、実際に達成された合計スループットのおよそ 90 % です。 その理由は、表示される FTP または HTTP の転送速度に、CPE デバイスと CMTS 間でやりとりされる必要のある、余分の IP および DOCSIS のオーバーヘッドが考慮に入れられていないためです。

もっと正確にスループットを測定できる方法もあります。たとえば、Netcom Smartbits や IXIA パケット ジェネレータなどの専用のテスト装置を利用する方法です。これらのシステムが必ずしもすぐに入手できたり、実稼動中のケーブル ネットワークに簡単に接続できるとは限りません。 しかし、スループットのテストがラボ環境で実行された場合は、専用デバイスを利用することで 単なる FTP や HTTP のダウンロード テストよりもはるかに詳細な情報が得られることは注目に値します。

FTP または HTTP に基づくアップロードおよびダウンロードのテストは、およそ 3Mbps 以下の速度をテストする場合に限り、信頼性があることに注意してください。 3 Mbps よりも高速である場合、CPE デバイス、サーバ、またはネットワーク インターフェイス カードの処理能力がテストの制限因子となる場合があります。 約 3 Mbps よりも速度の速いテストに関しては、専用のデータ スループット テスト装置を使用する必要があります。

次の例では、ケーブル モデムに接続された CPE デバイスと ケーブル サービス プロバイダーのネットワーク上にある FTP サーバの間で、簡単な FTP ダウンロードおよびアップロードのテストを行います。 ケーブル モデムに、256 Kbps のダウンロード速度および 64 Kbps のアップロード速度を許可する DOCSIS コンフィギュレーション ファイルをダウンロードしました。 このテストでは、IP アドレス 172.17.110.132 の FTP サーバ上に、3 MB のファイルを設置します。 CPE デバイスのユーザがこのファイルを FTP サーバからダウンロードし、FTP サーバへ再びアップロードできるように、FTP サーバにログイン可能なユーザ名とパスワードを用意します。 転送の実行には、コマンドラインの FTP ユーティリティを使用します。 実質的には、Microsoft Windows および UNIX のすべてのバージョンに、このユーティリティがあります。

サービス プロバイダーのネットワーク上に http Web サーバをセットアップし、http ダウンロードを行うことによっても、同様のテストが実行できます。

図 2

注:!--- コメントは青で示します。

C:\>ftp 172.17.110.132                   

!--- サーバへの FTP セッションを開始します。

Connected to 172.17.110.132.
220 Solaris FTP server (SunOS 5.6) ready.
User (172.17.110.132:(none)): anonymous   

!--- FTP サーバのユーザ名を入力します。

331 Guest login ok, send your complete e-mail address as password.
Password: user@samplenetwork.com.au      

!--- FTP サーバのパスワードを入力します。

230 User anonymous logged in.
ftp> dir                                 

!--- 現在のディレクトリ内用を表示します。

200 PORT command successful.
150 ASCII data connection for /bin/ls (64.104.207.118,1282) (0 bytes).
total 74932
-rw-r--r--   1 root     other    3276800 Oct 10 19:31 cable.txt  

!--- ダウンロード可能な 3M ファイルです。

226 ASCII Transfer complete.
ftp: 105 bytes received in 0.12 Seconds 2.46Kbytes/sec.
ftp> bi                                 

!--- バイナリ ファイル転送モードにします。

200 Type set to I.
ftp> get cable.txt                      

!--- cable.txt ファイルの取得を実行し、ダウンロードの完了を待ちます。
200 PORT command successful.
150 Binary data connection for cable.txt (192.168.1.13,3154) (3276800 bytes).
226 Binary Transfer complete.
ftp: 3276800 bytes received in 111.35Seconds 29.43Kbytes/sec.

!--- ダウンロードが完了しました。このダウンロードは、                                                               

!--- 29.43K バイト/秒で実行されたようで、これは                                                               

!--- 235K bps と同等です。                                                               

!--- テスト用のモデムに許可された256K bps の                                                               

!--- およそ 90 % のダウンロード レートです。

ftp> put cable.txt                      

!--- ファイルのアップロードを開始します。アクセスが正しいことを確認して、この                                         

!--- FTP サーバへアップロードする必要があります。                                         

!--- 正しくない場合、アクセス拒否エラーが発生する場合があります。
200 PORT command successful.
150 Binary data connection for cable.txt (192.168.1.13,3157).
226 Transfer complete.
ftp: 3276800 bytes sent in 432.49Seconds 7.58Kbytes/sec.

!--- アップロードが完了しました。ここでは、アップロードが                                                         

!--- 7.58K バイト/秒で実行され、これは                                                         

!--- 60.64K bps と同等です。テスト用の                                                         

!--- モデムに許可された 64Kbps のおよそ 90 % のアップロード レート                                                         

!--- です。

ftp> quit                               

!--- FTP クライアント アプリケーションを終了します。 221 Goodbye.

FTP 転送の実行中に、show interface cable X/Y sid Z counters コマンドを使用して、CMTS におけるテストの経過を監視できます。X/Y にはテスト中のモデムが接続されているケーブル インターフェイス、Z にはテスト中のモデムのサービス ID(SID)番号をそれぞれ指定します。 このコマンドにより、特定のケーブル モデムからのバイト数、または特定のケーブル モデムへのバイト数が表示されます。 テストする CPE が、MAC アドレス 0001.9659.4461 を付けられたケーブル モデムの後ろにあるとします。

まず、show cable modem コマンドを使用して、テストするモデムの SID 番号を調べる必要があります。 ここでは、ケーブル モデムの SID は 5 です。

uBR7246-VXR# show cable modem 0001.9659.4461
Interface   Prim Online     Timing Rec    QoS CPE IP address      MAC address
          Sid  State      Offset Power
Cable3/0/U0    online     1996    0.25  5   2   10.1.1.24       0001.9659.4461

ダウンロードまたはアップロードの処理中に、clear counters コマンドを使用して、CMTS 上のすべてのパケット カウンタをゼロにクリアします。 カウンタのクリアと同時に、ストップウォッチまたはタイマーを開始します。

uBR7246-VXR# clear counters             

!--- パケット カウンタをゼロにリセットします。
Clear "show interface" counters on all interfaces [confirm]    

!--- Enter を押すときにストップウォッチを開始します。

ストップウォッチまたはタイマーが 1 分を示した直後に、show interface cable X/Y sid Z counters コマンドを実行します。 まずコマンドを入力しておき、タイマーが 1 分を示した瞬間に Enter キーを押すことをお勧めします。 当然、テストをより長時間またはより短時間で行うことも可能です。 テスト期間が長いほど、結果はより正確になります。ただし、ストップウォッチ タイマーが指定された時間に到達するまで、ダウンロードまたはアップロードが完了しないことを確認してください。もし先に完了してしまうと、その測定は不正確になってしまいます。

uBR7246-VXR# show interface cable 3/0 sid 5 counters    

!--- ストップウォッチが 1 分を示す瞬間に Enter キーを押します。
Sid   Inpackets  Inoctets   Outpackets Outoctets  Ratelimit  Ratelimit
                                                  BWReqDrop  DSPktDrop
5     4019       257216     3368      1921488    0          149

uBR7246-VXR#

ここでは、ダウンロード速度をテストしています。 show interface cable X/Y sid Z counter コマンドの出力は、ケーブル モデムによって 1 分間に 1,921,488 バイトがダウンロードされたことを示しています。 1,921,488 バイトをビットに変換すると、次の値が得られます。

8 bits per byte * 1,921,488 bytes = 15,371,904 bits.
次に、ダウンロード レートをビット/秒で調べ、この合計ダウンロード ビット数を、ダウンロードにかかった時間(秒)で割ります。
15,371,904 bits / 60 seconds = 256 Kbps
この例では、ダウンロード レートはおよそ 256 Kbps であり、これはテスト用のケーブル モデムに許可されたダウンロード レートと同じになっています。

show interface cable X/Y sid Z counter コマンドを使用してアップロード速度を確認するには、Inoctets 列を使用して、ケーブル モデムからアップストリーム方向への送信バイト数を確認する必要があります。

show interface cable X/Y sid <Z> counters」コマンドの詳細は、「Cisco ケーブル モデム終端システムのコマンド」を参照してください。

低パフォーマンスの潜在的な理由

DOCSIS コンフィギュレーション ファイルによるパフォーマンス制限

低速なケーブル モデムをトラブルシューティングする際に、最初に収集すべき情報は Class of Service(CoS; サービス クラス)上規定されているケーブル モデムのスループット制限についてです。 ケーブル モデムがオンラインになると、DOCSIS コンフィギュレーション ファイルがダウンロードされます。このファイルには、最大アップロード レートや最大ダウンロード レートなどの、動作上の制限が指定されています。 通常の状況では、ケーブル モデムがこのレートを超えることは許可されていません。

最初に、問題のあるケーブル モデムの MAC アドレスを確認する必要があります。 MAC アドレス 0050.7366.2223 のモデムに低速スループットの問題があるとします。 次の例に示すとおり、show cable modem <mac-address> コマンドを実行して、このケーブル モデムによって使用されているサービス クラス プロファイルを調べる必要があります。

uBR7246-VXR# show cable modem 0050.7366.2223
Interface   Prim Online     Timing Rec    QoS CPE IP address      MAC address
            Sid  State      Offset Power
Cable3/0/U1 1    online     1548    0.75    0   10.1.1.10       0050.7366.2223
このケーブル モデムでは、QoS プロファイル 5 が使用されていることがわかります。この QoS プロファイルに対応するダウンストリーム レートとアップストリーム レートを調べるには、show cable qos profile profile-number コマンドを使用する必要があります。確認する QoS プロファイルを profile-number に指定します。

uBR7246-VXR# show cable qos profile 5
ID  Prio Max       Guarantee Max        Max   TOS  TOS   Create  B     IP prec.
         upstream  upstream  downstream tx    mask value by      priv  rate
         bandwidth bandwidth bandwidth  burst                    enab  enab
5   0    64000     0         256000     1600  0x0  0x0   cm      no    no
ここでは、QoS プロファイル 5 が、256Kbps のダウンストリームおよび 64Kbps のアップストリームを提供しているサービスに対応することがわかります。 QoS プロファイル 5 を使用しているケーブル モデムに接続された CPE は、この制限を超えることができません。 QoS プロファイル設定は、プロビジョニング中のシステムの TFTP サーバからケーブル モデムにダウンロードされた DOCSIS コンフィギュレーション ファイルの内容によって決定されます。したがって、システム上の QoS プロファイル 5 が、この例のものと同じではない場合があります。

エンド ユーザのダウンロードとアップロードのパフォーマンスに、QoS プロファイルに設定された制限との相関がある場合、エンド ユーザはケーブル モデムに対して提供および設定されたレベルのサービス クラスとスループットを得ていることになります。 アップロードおよびダウンロードのスループットを高くする唯一の方法は、ケーブル モデムがダウンロードする DOCSIS コンフィギュレーション ファイルを、より高いスループットの指定されたファイルに変更することです。 次の文書を参照してください。「 Cisco DOCSIS Configurator を使用した DOCSIS 1.0 コンフィギュレーション ファイルの構築 (登録済みのお客様専用)」に、DOCSIS コンフィギュレーション ファイルの作成方法および変更方法に関する詳細があります。

完全に最適化されていないレート制限方法の使用

ケーブル モデムの DOCSIS コンフィギュレーション ファイルに、エンド ユーザが許可されたレートを超えてインターネットからデータをダウンロードしようとすると、そのユーザの帯域幅消費が許可された量を超過しないように、ユーザへ送信されるトラフィックのレート制限を CMTS 上で実行する必要があります。

同様に、DOCSIS コンフィギュレーション ファイルに許可されたレートを超えてエンド ユーザがデータのアップロードまたは送信をインターネットに対して行おうとすると、ケーブル セグメントから CMTS への超過トラフィックの送信を、ケーブル モデムそれ自身が中止する必要があります。 何らかの理由で、ケーブル モデムがアップストリームの正常なレート制限に失敗した場合、許可されたレートよりも高いレートでのケーブル モデムからの転送が、CMTS によって明示的に禁止されます。 この CMTS の動作は、ケーブル モデムの特性が「ハッキング」されても、サービス プロバイダーによるアップロード レート制限を破ることができないようにするためです。

CMTS モニタ上で使用されるデフォルトのレート制限方式では、各ケーブル モデムへのトラフィックまたは各ケーブル モデムからのトラフィックのレートが、1 秒の間隔で監視されます。 ケーブル モデムが、その 1 秒当たりの割り当て量を超す量を 1 秒以内に送信または受信した場合、CMTS はその秒の残りの時間、これ以上のトラフィックがこのケーブル モデムを経由することを許可しません。

たとえば、512Kbps のダウンロード レートを許可する QoS プロファイルの設定されたケーブル モデムがあるとします。 ケーブル モデムによって最初の 1/2 秒内に 512 キロビット(64 KB)がダウンロードされた場合、次の 1/2 秒の間、このケーブル モデムには何もダウンロードできません。 この種のレート制限の動作には、1 秒または 2 秒ごとに停止と開始を繰り返すような、バースト性のあるダウンロードの型の影響が見られる場合があります。

ダウンストリームにおける最善のレート制限方式は、トラフィック シェーピング付きトークン バケット レート制限アルゴリズムの使用です。 このレート制限方式は、安定したレートで滑らかな Web ブラウズが可能なように最適化されています。また、エンド ユーザが DOCSIS コンフィギュレーション ファイルに指定された規定のダウンロード レートを超えることはできません。

この方式は、ケーブル モデムにおいてパケットが送受信されるたびに、ケーブル モデムによるデータのダウンロード レートまたはアップロード レートを測定するように機能します。 パケットを送受信することでモデムに許可された転送レートを超える場合、ダウンストリームの帯域幅制限を超えずに CMTS から送信できるようになるまで、このパケットは CMTS メモリ内にバッファまたはキャッシュされます。 ただし、ダウンストリームのトラフィック レートが、ケーブル モデムに許可されたダウンストリーム レートを一定して超えている場合、最終的にはパケットが廃棄されてしまうことに注意してください。

より滑らかなレート制限およびシェーピングを実行するこの方式を使用することによって、HTTP Web ブラウズや FTP ファイル転送などのほとんどの TCP ベースのインターネット アプリケーションは、デフォルトのレート制限方式の使用時よりもより滑らかかつ効率的に動作します。

トラフィック シェーピング スキーム付きのトークンバケット レート制限は、次のケーブル インターフェイスの設定コマンドを発行することによって、ケーブル インターフェイスのダウンストリーム パス上で有効にすることができます。

uBR7246-VXR(config-if)# cable downstream rate-limit token-bucket shaping

注: CMTS 上で token-bucket shaping を有効にすることを強く推奨します。 このコマンドは、12.0(5)T1 および 12.1(1)EC1 以降でサポートされています。

トラフィック シェーピング付きのトークンバケットは、アップストリームのポートにも適用できます。ただし、アップストリームのレート制限はケーブル モデムが担当するため、CMTS に適用されるアップストリームのレート制限方式は、通常、システムのパフォーマンスに影響しません。

uBR7246-VXR(config-if)# cable upstream 0 rate-limit token-bucket shaping
cable downstream rate-limit コマンドおよび cable upstream Z rate-limit コマンドの詳細は、「Cisco ケーブル モデム終端システムのコマンド」を参照してください。

show interface cable X/Y sid <Z> counters コマンドを使用すると、特定のケーブル モデムへのトラフィックに対して、CMTS によるレート制限がどの程度厳密であるかを表示できます。X/Y にはケーブル モデムが接続されているケーブル インターフェイス、Z には監視対象のモデムの SID 番号をそれぞれ指定します。 このコマンドは、モデムに許可されたスループット制限が超過したことが原因で、CMTS がダウンストリームのパケットを廃棄した回数、またはアップストリームのパケットを拒否した回数が表示されます。 Z の値を指定しない場合、インターフェイス ケーブル X/Y に接続されたすべてのケーブル モデムに関するカウンタ情報が表示されます。

uBR7246-VXR# show interface cable 3/0 sid 5 counters
Sid   Inpackets  Inoctets   Outpackets Outoctets  Ratelimit  Ratelimit
                                                 BWReqDrop  DSPktDrop
5     150927     9662206    126529     72008199  0          5681

Ratelimit DSPktDrop フィールドは、モデムが許可されたダウンストリーム スループットを超えつつあることが原因による、CMTS のケーブル モデム向けのパケット廃棄回数を表示します。

Ratelimit BWReqDrop フィールドは、モデムが許可されたアップストリーム スループットを超えつつあることが原因で、ケーブル モデムのアップストリーム パスへのパケットの送信を CMTS が拒否した回数を表示します。 ほとんどの状況において、このカウンタは常に 0 のままです。この値がゼロを超えて著しく増加する場合、監視対象のケーブル モデムのアップストリーム レート制限が正常に動作していない可能性があります。

次の例のとおりに、clear counters コマンドを発行すると、show interface cable X/Y sid Z counters コマンドによって表示される値がゼロにリセットされる場合があることに注意してください。

uBR7246-VXR# show interface cable 3/0 sid counters
Sid   Inpackets  Inoctets   Outpackets Outoctets  Ratelimit  Ratelimit
                                                  BWReqDrop  DSPktDrop
1     7          1834       7          1300       0          0
2     2052       549150     0          0          0          0
3     2          1244       2          708        0          0
4     2          1244       2          714        0          0
5     160158     10253220   134294     76423270   0          6023
6     2          1244       2          712        0          0
7     9          1906       4          858        0          0
9     6          1076       3          483        0          0
12    616        165424     0          0          0          0

uBR7246-VXR# clear counters
Clear "show interface" counters on all interfaces [confirm] <press enter here>
uBR7246-VXR# show interface cable 3/0 sid counters
Sid   Inpackets  Inoctets   Outpackets Outoctets  Ratelimit  Ratelimit
                                                  BWReqDrop  DSPktDrop
1     0          0          0          0          0          0
2     0          0          0          0          0          0
3     0          0          0          0          0          0
4     0          0          0          0          0          0
5     111        7104       92         52728      0          6
6     0          0          0          0          0          0
7     0          0          0          0          0          0
9     0          0          0          0          0          0
12    0          0          0          0          0          0

show interface cable X/Y sid <Z> counters」コマンドの詳細は、「Cisco ケーブル モデム終端システムのコマンド」を参照してください。

アップストリーム チャネルの輻輳

ケーブル システムでは、通常、アップストリーム チャネルのリソースが最も重要です。 現在、ほとんどのサービス プロバイダーが、アップストリーム パスにおいて 1.6MHz のチャネル幅および Quadrature Phase Shift Keying(QPSK; 4 位相偏移変調)変調を使用しています。 これは 1 チャネルのアップストリーム チャネルに接続されたすべてのユーザが使用可能な、およそ 2.5Mbps の合計アップストリーム帯域幅に相当します。 アップストリーム チャネルを使用しすぎないまたは輻輳させないことが重要です。過剰利用または輻輳の場合、このアップストリーム セグメント上にあるすべてのユーザについて、パフォーマンスが低下します。

show interface cable X/Y upstream <Z> CMTS コマンドを実行することによって、特定のアップストリーム ポートに関するアップストリーム利用率を入手できます。X/Y にはダウンストリーム インターフェイス番号を、Z にはアップストリーム ポート番号をそれぞれ指定します。 Z を省略した場合、インターフェイス ケーブル X/Y 上のすべてのアップストリームに関する情報が表示されます。 show interface cable X/Y upstream <Z> コマンドの詳細は、「Cisco ケーブル モデム終端システムのコマンド」を参照してください。

uBR7246-VXR# show interface cable 6/0 upstream 0
     Cable6/0: Upstream 0 is up
     Received 71941 broadcasts, 27234 multicasts, 8987489 unicasts
     0 discards, 140354 errors, 0 unknown protocol
     9086664 packets input, 4394 uncorrectable
     122628 noise, 0 microreflections
     Total Modems On This Upstream Channel : 359 (354 active)
     Default MAC scheduler
     Queue[Rng Polls]  0/64, fifo queueing, 0 drops
     Queue[Cont Mslots]  0/104, fifo queueing, 0 drops
     Queue[CIR Grants]  0/64, fair queueing, 0 drops
     Queue[BE Grants]  0/64, fair queueing, 0 drops
     Queue[Grant Shpr]   0/64, calendar queueing, 0 drops
     Reserved slot table currently has 0 CBR entries
     Req IEs 64609697, Req/Data IEs 0
     Init Mtn IEs 521851, Stn Mtn IEs 569985
     Long Grant IEs 2781600, Short Grant IEs 2067668
     Avg upstream channel utilization : 18%
     Avg percent contention slots : 77%
     Avg percent initial ranging slots : 2%
     Avg percent minislots lost on late MAPs : 0%
     Total channel bw reserved 37858000 bps
     CIR admission control not enforced
     Admission requests rejected 0
     Current minislot count   : 7301855    Flag: 0
     Scheduled minislot count : 7301952    Flag: 0

この例に示されているアップストリーム ポートでは、アップストリーム利用率は現在 18 % であり、359 台のモデムがこのアップストリームに接続されています。

使用のピーク時にアップストリーム チャネルの利用率が一定して 75 % を超える場合、遅延、「ping」時間の遅れ、インターネット全体の遅れなどの問題がエンド ユーザ側で発生しはじめます。 使用ピーク時にアップストリーム チャネルの利用率が一定して 90 % を超える場合、エンド ユーザ側でサービスのレベルが極端に劣化します。これは、エンド ユーザのアップストリーム データの大部分が遅延または廃棄される必要があるためです。

日中は異なるユーザがケーブル モデムを使用する機会があるため、アップストリーム チャネルの利用率は変化します。したがって、あまり使用されない時間帯よりも、日中の最繁時にアップストリームの利用率を監視することが重要です。

アップストリームの輻輳を緩和するには、次の方法があります。

  • アップストリーム当たりのケーブル モデム数を減らす : 特定のアップストリームに接続されているケーブル モデムが多すぎる場合、または特定のアップストリームのユーザがアップストリーム帯域幅を大量に消費するユーザである場合、輻輳しているアップストリーム ポートの一部のユーザを、利用率の低いアップストリーム ポートまたは完全に新しいアップストリーム ポートへ移動するのが最適なソリューションです。 これは通常、あるアップストリーム結合グループから他のグループへファイバのノードを移動する、またはアップストリーム結合グループを 2 つに分割することにより実現できます。 詳細は、「CMTS 当たりの最大ユーザ数」を参照してください。
  • アップストリームのチャネル幅を拡大する : 拡大するチャネル幅をサポートするのに十分な信号対雑音比の特性と帯域幅を備えた帯域を見つけるために、アップストリームのスペクトラムに関する厳密かつ徹底した分析を行います。 アップストリーム チャネル幅の変更は、ケーブル システム内の他のサービスにも影響する可能性があるため、入念な計画を行わずには変更しないでください。 ケーブル インターフェイス コマンド cable upstream Z channel-width <new-channel-width> を使用して、アップストリーム チャネル幅を変更できます。Z にはアップストリーム ポート番号を指定し、new-channel-width には 200000、400000、800000、1600000(デフォルト)、3200000 のいずれかを指定します。次に例を示します。
  • uBR7246-VXR(config-if)# cable upstream 0 channel-width 3200000
    show interface cable X/Y upstream <Z> コマンドの詳細は、「Cisco ケーブル モデム終端システムのコマンド」を参照してください。
     
  • アップストリームのデジタル変調方式を 16-QAM に変更する : ここでも同様に、16-QAM 変調をサポートできるアップストリームの周波数帯域があることを確認するために、アップストリームのスペクトラムに関する厳密かつ徹底した分析が必要です。 この分析を正しく行わない場合、パフォーマンスのさらなる低下、またはアップストリームの完全停止の恐れという危険があります。 16-QAM 変調を使用したアップストリーム変調プロファイルを作成し、そのプロファイルをアップストリーム ポートに適用することによって、アップストリーム変調方式を変更できます。 次に例を示します。
  • uBR7246-VXR(config)# cable modulation-profile 2 mix   

    !--- Create an optimized 16-qam/qpsk modulation profile.
    uBR7246-VXR(config)# interface cable 6/0
    uBR7246-VXR(config-if)# cable upstream 0 modulation-profile 2

    cable modulation-profile コマンドおよび cable upstream Z modulation-profile コマンドの詳細は、「Cisco ケーブル モデム終端システムのコマンド」を参照してください。 「Cisco ケーブルモデム終端システムのケーブル変調プロファイルの設定」も参照してください。
     
  • ケーブル モデムごとに許可されたアップストリーム スループットを縮小する - 適切な DOCSIS コンフィギュレーション ファイル内のアップストリーム最大転送レートを縮小することによって、ケーブル モデムのユーザがアップストリーム方向へ高速で転送できなくなるため、アップストリームの輻輳が緩和されます。 この処置による明らかな欠点は、ケーブル モデム ユーザのサービス クラスが低速なものに制限されることです。 次を参照してください。 Cisco DOCSIS Configurator を使用した DOCSIS 1.0 コンフィギュレーション ファイルの構築 (登録済みのお客様専用)」。
  • このセクションで説明している措置では、すでに輻輳のなくなったシステムのパフォーマンスは大幅には向上しないことに注意してください。

    ダウンストリーム チャネルの輻輳

    ダウンストリーム チャネルには、各アップストリーム チャネルに比べて、共有可能な帯域幅が比較的多くあります。したがって、ダウンストリームでは通常、アップストリームと同程度の輻輳は発生しません。 ただし、通常、どんなアップストリーム チャネルと比べても、ダウンストリーム チャネルは多くのユーザによって共有されます。したがって、ダウンストリーム チャネルが輻輳した場合、そのダウンストリーム セグメントに接続されたすべてのユーザについて、パフォーマンスが低下します。

    DOCSIS システムにある 4 つのダウンストリーム変調方式について、使用可能なダウンストリームの合計帯域幅を、次の表に示します。
     

    ダウンストリーム変調方式
    使用可能なダウンストリーム帯域幅
    64-QAM North American DOCSIS
    27 Mbps
    256-QAM North American DOCSIS
    38 Mbps
    64-QAM Euro DOCSIS
    38 Mbps
    256-QAM Euro DOCSIS
    54 Mbps

    現在主に展開されている DOCSIS ケーブル システムは 64-QAM North American DOCSIS です。したがって、このシステムではダウンストリーム チャネル当たり 27Mbps が使用可能です。

    show interface Cable X/Y コマンドを実行することによって、ダウンストリーム チャネル利用率を確認できます。X/Y に監視対象のケーブル インターフェイスを指定します。 秒当たりのビット数で表示される出力レートを、前述の表に示した使用可能なダウンストリーム帯域幅と比較してください。

    次の例では、North American DOCSIS と 64-QAM デジタル変調を使用したインターフェイスを分析します。

    uBR7246-VXR# show interface cable 3/0
    Cable3/0 is up, line protocol is up
      Hardware is BCM3210 ASIC, address is 0005.5fed.dca4 (bia 0005.5fed.dca4)
      Internet address is 10.1.1.1.1/24
      MTU 1500 bytes, BW 27000 Kbit, DLY 1000 usec,
         reliability 255/255, txload 9/255, rxload 5/255
      Encapsulation MCNS, loopback not set
      Keepalive not set
      ARP type: ARPA, ARP Timeout 04:00:00
      Last input 00:00:00, output 00:00:00, output hang never
      Last clearing of "show interface" counters 00:45:01
      Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
      Queueing strategy: fifo
      Output queue :0/40 (size/max)
      5 minute input rate 587000 bits/sec, 228 packets/sec
      5 minute output rate 996000 bits/sec, 239 packets/sec
         85560 packets input, 8402862 bytes, 0 no buffer
         Received 1013 broadcasts, 0 runts, 0 giants, 0 throttles
         247 input errors, 35 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
         65912 packets output, 38168842 bytes, 0 underruns
         0 output errors, 0 collisions, 0 interface resets
         0 output buffer failures, 0 output buffers swapped out

    この出力において最初に注目する部分は、BW パラメータによって示されるインターフェイスの帯域幅です。 IOS リリース 12.1(8)EC 以降では、ダウンストリーム変調方式および使用される DOCSIS のバージョンに従って、この値が自動的に調整されます。 12.1(8)EC よりも前のリビジョンでは、ケーブル インターフェイス コマンド bandwidth <bandwidth-in-kilo-bits-per-second> を使用して、この値を手動で設定する必要があります。設定しない場合、この値はデフォルトの 27000 Kbps のままです。

    次に注目する部分は、txload パラメータによって示される転送負荷です。 このパラメータは、255 までのメトリックを示します。0/255 はダウンストリーム方向へのトラフィックが何も流れていないことを意味し、255/255 は可能な最大レート(この場合は 27000 Kbps)でダウンストリームにデータが流れていることを意味します。 使用のピーク時において、このパラメータがおよそ 75 % よりも一定して高い(たとえば、191/255 を超える)場合、インターネット アクセスの遅れやより大きい遅延がエンド ユーザ側で発生しはじめます。

    3 つめに注目する部分は、出力レートです。これは、秒当たりのビット数でダウンストリームの平均スループット レートを示します。 使用のピーク時において、使用可能なダウンストリーム帯域幅のおよそ 75 % を、この数が一定して超える場合、インターネット アクセスの遅れやより大きい遅延がエンド ユーザ側で発生しはじめます。

    デフォルトでは、この統計は平均 5 分間で計算されます。 (平均の計算方法に関する詳細は、「sh int にある bits/sec の定義」を参照してください。) ケーブル インターフェイス コマンド load-interval 30 を発行することによって、この平均計算時間を 30 秒まで短縮できます。 この時間を 30 秒まで減らすと、このセクションで説明する個々のパラメータについて、より正確な最新の値が計算されます。

    日中は異なるユーザがケーブル モデムを使用する機会があるため、ダウンストリーム チャネルの利用率は変化します。したがって、あまり使用されない時間帯よりも、日中の最繁時にダウンストリームの利用率を監視することが重要です。

    ダウンストリームの輻輳を緩和するには、次の方法があります。

  • ダウンストリーム当たりのケーブル モデム数を減らす - 特定のダウンストリームに接続されているケーブル モデムが多すぎる場合、または特定のダウンストリームのユーザがダウンストリーム帯域幅を大量に消費するユーザである場合、輻輳しているダウンストリーム チャネルの一部のユーザを、他のダウンストリーム チャネルへ移動するのが最適なソリューションです。 これは通常、ダウンストリームに関連付けられたダウンストリーム ファイバのノードのグループを、2 つのグループに分割し、この新しい各グループに個別のダウンストリームチャネルを割り当てることにより実現できます。 「CMTS 当たりの最大ユーザ数」も参照してください。
  • ダウンストリームのデジタル変調方式を 256-QAM に変更する - ここでは、システムが 256-QAM 変調をサポートできることを確認するために、ダウンストリームのスペクトラムに関する厳密かつ徹底した分析が必要です。 この分析を正しく行わない場合、パフォーマンスのさらなる低下、またはダウンストリームの完全停止の恐れという危険があります。 次に示すケーブル インターフェイス コマンドを発行することによって、ダウンストリーム変調方式を変更できます。
  • このセクションで説明している措置では、すでに輻輳のなくなったシステムのパフォーマンスは大幅には向上しないことに注意してください。

    バックホール ネットワークまたはインターネットの輻輳

    場合によっては、パフォーマンスの問題が、ケーブル装置または CMTS の問題によるものではなく、バックホール ネットワーク上の輻輳または問題に関連している可能性があります。このバックホール ネットワークは、インターネットへの CMTS の接続に使用されたり、インターネット自体の一部であったりします。

    バックホール ネットワークの輻輳が問題であるかどうかを確認する最も簡単な方法は、ワークステーションを CMTS と同じネットワーク セグメントに接続し、ケーブル モデム経由で接続しているエンド ユーザと同じ方法で同じ Web サイトをブラウズすることです。 まだパフォーマンスが低速である場合、CMTS またはケーブル セグメントに関連のないネットワークに、パフォーマンスの問題があります。 ケーブル モデムに接続されたユーザについて、ローカルの CMTS ネットワーク セグメントからのパフォーマンスが非常によい場合、再度、CMTS およびケーブル セグメントの作業に注力する必要があります。

     

    図 3

    このネットワークにおいて、CMTS と同じネットワーク セグメントに接続された Server 1 のインターネットへのブラウズ時のパフォーマンスが低速になってきた場合、その問題の原因は CMTS ではありません。 ボトルネックまたはパフォーマンスの問題は他の場所にあります。 問題のある場所を特定するには、Server 1 とインターネット サービス プロバイダーのネットワーク内、およびパブリック インターネット内にある他のさまざまなサーバとの間で、パフォーマンス テストを実行する必要があります。

    ケーブル装置におけるノイズおよびエラー

    ノイズまたはケーブル システムへの入力の量が過剰である場合、ケーブル モデムと CMTS 間においてパケットが破壊され失われます。 これにより、パフォーマンスが著しく劣化する場合があります。

    パフォーマンスおよびスループットの劣化以外にも、次のノイズを示す事項や RF の問題があります。

    • ケーブルモデムの散発的なオフラインや、init(r1) または init(r2) 状態での停止。
    • show controller cable X/Y upstream Z の出力に見られる低い概算 SNR 値。X/Y には監視対象のケーブル インターフェイスを、Z には監視対象のアップストリーム ポートをそれぞれ指定します DOCSIS 仕様では、すべてのアップストリーム信号において、最低 25dB の CNR が要求されています。 これは、およそ 29dB の SNR に相当します。 Cisco CMTS では、より劣った SNR レベルにおいても QPSK アップストリーム信号が一貫して検出されますが、すべてのケーブル サービス プロバイダーがシステムの DOCSIS CNR 要件を満たすように努める必要があります。 次に、show controller cable X/Y upstream Z の出力例を示します。
      •  
        uBR7246-VXR# show controller cable 6/0 upstream 0
         Cable6/0 Upstream 0 is up
          Frequency 25.200 MHz, Channel Width 1.600 MHz, QPSK Symbol Rate 1.280 Msps
          Spectrum Group is overridden
          SNR 28.6280 dB
          Nominal Input Power Level 0 dBmV, Tx Timing Offset 6446
          Ranging Backoff automatic (Start 0, End 3)
          Ranging Insertion Interval automatic (102 ms)
          Tx Backoff Start 0, Tx Backoff End 4
          Modulation Profile Group 1
          Concatenation is enabled
          part_id=0x3137, rev_id=0x03, rev2_id=0xFF
          nb_agc_thr=0x0000, nb_agc_nom=0x0000
          Range Load Reg Size=0x58
          Request Load Reg Size=0x0E
          Minislot Size in number of Timebase Ticks is = 8
          Minislot Size in Symbols = 64
          Bandwidth Requests = 0x37EB54
          Piggyback Requests = 0x11D75E
          Invalid BW Requests= 0x102
          Minislots Requested= 0x65B74A2
          Minislots Granted  = 0x65B74A2
          Minislot Size in Bytes = 16
          Map Advance (Dynamic) : 2809 usecs
          UCD Count = 23068

      この例では、SNR 測定値の概算は 28.628dB です。 QPSK のアップストリーム動作には十分な値です。 このコマンドから得た SNR 値は単なる概算であり、スペクトラム アナライザなどの適切なテスト機器から得られた SNR 値の代わりにはならない点に注意してください。 show controller cable X/Y upstream Z コマンドの詳細は、「Cisco ケーブル モデム終端システムのコマンド」を参照してください。

         

    • show cable hop コマンド出力に見られる、Corr FEC および Uncorr FEC エラー数の急上昇。 Corr FEC エラーは、アップストリーム ノイズによって破壊されてた後、復元できたデータを示します。 Uncorr FEC エラーは、アップストリーム ノイズによって破壊され、復元できずにデータの損失および低速のパフォーマンスを起こしたデータを示します。 次に、show cable hop コマンドの出力例を示します。
      •  
        uBR7246-VXR# show cable hop cable 3/0
        Upstream    Port       Poll Missed Min    Missed Hop   Hop     Corr    Uncorr
        Port        Status     Rate Poll   Poll   Poll   Thres Period  FEC     FEC
                               (ms) Count  Sample Pcnt   Pcnt  (sec)   Errors  Errors
        Cable3/0/U0 25.200 Mhz 34   * * * set to fixed frequency * * * 196     55
        Cable3/0/U1 25.200 Mhz 34   * * * set to fixed frequency * * * 1655    160
        Cable3/0/U2 25.200 Mhz 34   * * * set to fixed frequency * * * 76525   9790
        Cable3/0/U3 25.200 Mhz 34   * * * set to fixed frequency * * * 501     77
        Cable3/0/U4 admindown  34   * * *   interface is down    * * * 0       0
        Cable3/0/U5 admindown  34   * * *   interface is down    * * * 0       0

      この例では、ケーブル 3/0 上のアクティブ状態の各アップストリーム ポートにおいて、ノイズが原因でパケットが損失したと考えられます。 アップストリーム ポート 0 における影響は最も小さく、アップストリーム ポート 2 が最も影響を受けたと見られます。 FEC 合計エラー数よりも、どの程度の早さでエラーが増加したかが重要です。 show cable hop コマンドの詳細は、「Cisco ケーブル モデム終端システムのコマンド」を参照してください。  

    • show cable flap-list の出力に見られる、高い「フラップ」イベント数。 可能性のある RF またはノイズの問題に最も関連するフラップ統計は、Miss 列です。これはレンジング要求の失敗を示します。P-Adj 列は、アップストリーム電力レベルの急激な変化を示します。 次に、show cable flap-list コマンドの出力例を示します。
      •  
        uBR7246-VXR# show cable flap-list
        MAC Address     Upstream     Ins   Hit   Miss  CRC   P-Adj Flap  Time
        0000.d025.1b99  Cable3/0/U0  23    58    30    0     *27   77    Oct 23 03:08:23
        0002.ddfa.0aa5  Cable3/0/U1  5     518   1260  0     0     131   Oct 23 03:09:43
        0001.e659.43bd  Cable3/0/U1  541   342   1467  0     0     746   Oct 23 03:09:17
        0001.7659.44c7  Cable3/0/U1  0     694   0     0     1     1     Oct 23 01:44:23
        0050.9366.22d3  Cable3/0/U1  0     708   0     0     1     1     Oct 23 01:38:14
        0001.f659.44e7  Cable3/0/U1  0     701   0     0     1     1     Oct 23 02:25:11

      この例では、MAC アドレス 0000.d025.1b99 の付いたケーブル モデムにおいて、多数の P-Adj イベントがあります。 通常、これは接続状態が悪いこと、またはリバース パスの増幅器に不具合があることを示します。 MAC アドレス 0002.ddfa.0aa5 の付いたケーブル モデムでは、ヒット数と比べて大量のミス数があります。これは、ダウンストリームまたはアップストリームのノイズ問題を示す場合があります。 MAC アドレス 0001.e659.43bd の付いたケーブル モデムには、大量の挿入があります。これは、通常、重大な RF 問題、またはどちらかと言えばプロビジョニングの問題を示します。 show cable flap-list コマンドの詳細は、「Cisco ケーブル モデム終端システムのコマンド」を参照してください。
       

    • ケーブル モデムの show cable modem または show cable flap-list の出力における「*」または「!---」の表示。「*」は、アップストリーム電力レベルが急激に変化しているケーブル モデムを示します。 これは、温度などの環境の影響が原因で、ケーブル装置への接続状態がよくないこと、リバース パスの増幅器に不具合があること、またはケーブル装置の減衰量が急激に変化していることを示します。 「!---」は、最大アップストリーム電力レベルに到達したケーブル モデムを示します。 ケーブル モデムと CMTS の間の減衰量が大きすぎること、またはケーブル モデムとケーブル装置の間の接続状態がよくないことを示します。 次に、show cable modem コマンドの出力例を示します。

    •  
        uBR7246-VXR# show cable modem
        Interface   Prim Online     Timing Rec    QoS CPE IP address      MAC address
                    Sid  State      Offset Power
        Cable3/0/U1 1    online     1549  !--- -1.00  5   0   10.1.1.10       005a.73f6.2213
        Cable3/0/U0 2    online     1980    0.75  5   0   10.1.1.16       009b.96e7.3820
        Cable3/0/U0 3    online     1981   *0.75  5   0   10.1.1.18       009c.96d7.3831
        Cable3/0/U1 4    online     1924    0.25  5   0   10.1.1.24       000d.96c9.4441
        Cable3/0/U1 5    online     1925    0.50  5   0   10.1.1.13       000e.96b9.4457


      この例では、MAC アドレス 005a.73f6.2213 の付いたケーブル モデムが最大出力電力で送信しています。 これは、モデムが正しいレベルで送信できていません。 このため、このモデムのアップストリーム送信は、他のモデムからの送信と同程度には明瞭に受信されません。 MAC アドレス 009c.96d7.3831 の付いたケーブル モデムでは、ケーブル システムの減衰量の変化が原因で、電力出力が急激に変化しています。 show cable modem コマンドおよび show cable flap-list コマンドの詳細は、「Cisco ケーブル モデム終端システムのコマンド」を参照してください。

    RF ノイズ問題の確認および解決に関するより詳細な説明は、「CMTS における RF またはコンフィギュレーションの問題の特定」および「ケーブル ヘッドエンドの接続と設定」にあります。

    CMTS における CPU の高利用率

    環境によっては、完全に最適化されていない設定、特定の管理機能の過剰利用、または CMTS での大量のパケットのルーティングが原因で、Cisco CMTS が過負荷になる場合があります。

    Cisco CMTS の CPU 利用率を確認する最もよい方法は、show process cpu コマンドを実行することです。 コマンド出力の 1 行目に、現在の CPU 利用率が示されます。

    1 行目の下にある出力には、CMTS 上で実行されている各プロセスが、そのプロセスによる CPU 使用量とともに表示されます。 show process cpu 出力のこのセクションは、特定のプロセスまたは機能が CMTS の CPU 高利用率の原因であるかどうかを判断するのに便利です。

    uBR7246-VXR# show process cpu
    CPU utilization for five seconds: 45%/21%; one minute: 45%; five minutes: 31%
     PID  Runtime(ms)  Invoked  uSecs    5Sec   1Min   5Min TTY Process
       1          12      9220      1   0.00%  0.00%  0.00%   0 Load Meter
       2       69816  18276677      3  21.79% 22.10%  9.58%   2 Virtual Exec
       3       36368      5556   6545   0.00%  0.06%  0.05%   0 Check heaps
       4           0         1      0   0.00%  0.00%  0.00%   0 Chunk Manager
       5          96      1436     66   0.00%  0.00%  0.00%   0 Pool Manager
       6           0         2      0   0.00%  0.00%  0.00%   0 Timers
       7           0         2      0   0.00%  0.00%  0.00%   0 Serial Backgroun
       8           0         1      0   0.00%  0.00%  0.00%   0 CMTS ping
       9       17020    101889    167   0.00%  0.00%  0.00%   0 EnvMon
      10           0         1      0   0.00%  0.00%  0.00%   0 OIR Handler
      . . . . . . .
      <snip>
      . . . . . . .
      89        3304     81013     40   0.00%  0.00%  0.00%   0 PIM Process
      90          12       769     15   0.00%  0.00%  0.00%   0 CEF Scanner
      92           0       385      0   0.00%  0.00%  0.00%   0 DHCPD Timer
      93          40     13058      3   0.00%  0.00%  0.00%   0 DHCPD Database

    この例では、CMTS における現在の CPU 負荷は 45 %/21 % です。 これは、合計 CPU 利用率がシステム容量の 45 % であることを意味します。 また、CPU の 21 % はサービスの割り込みに利用されています。 この 2 つめの数は、通常、CMTS を経由したパケットのルーティングおよびトラフィックの交換に使用される CPU 使用量に相当します。

    使用ピーク時の 5 分間に、システムの CPU 利用率が一定して 80 % を超える場合、パフォーマンスの遅れや大きい遅延がエンド ユーザ側で発生しはじめます。 使用ピーク時の 5 分間に、システムの CPU 利用率が一定して 95 % を超える場合、CMTS が安定した状態を維持できるように緊急処置を行う必要があります。

    次に、CMTS における CPU の高使用率を緩和する一般的な方法を示します。

    • リリース 12.1(9)EC 以降へアップグレードし、グローバル設定コマンド ip cef を有効にします。次に、CMTS 上に、no ip route-cache コマンドの設定されたインターフェイスがないことを確認します。 通常、これにより、CPU 利用率に関連する 10 〜 15 % のトラフィックが削減されます。 これらすべてのステップを組み合わせて実行してください。
    • SNMP 管理ステーションから CMTS へのポーリングが実行されすぎていないことを確認します。 これにより、IP SNMP プロセスにおける CPU 利用率が高くなります。
    • show tech コマンドを、複数回連続で実行しないでください。 これにより、仮想 Exec プロセスにおける CPU 利用率が人為的に高められます。
    • CMTS 上でデバッグが実行されていないことを確認します。
    Cisco CMTS 製品を含む、Cisco ルータの CPU 高利用率に関する詳細は、「トラブルシューティング:Cisco ルータで CPU 使用率が高い場合」を参照してください。

    CPE 機器の機能不足または設定誤り

    ケーブル ネットワークへのアクセスが低速である原因は、エンド ユーザの CPE 機器の問題に起因する場合が多くあります。 1 名または数名のユーザにおいてだけスループットが低速になり、残りのユーザには問題がない場合、ユーザ環境に固有の問題がある可能性を明示しています。
    • CPE における機能不足または過負荷 - 接続が困難であることを指摘しているエンド ユーザが旧型の CPE 機器を使用している場合、またはユーザが選択したオペレーティング システムやインターネット アクセス ソフトウェアを実行するだけの十分な機能の機器がない可能性がある場合、このエンド ユーザが困難に陥るのは明らかです。 この場合の唯一の解決策は、エンド ユーザが CPE 機器をアップグレードすることです。
    • ファイアウォール ソフトウェアまたはパフォーマンス測定ソフトウェア - エンド ユーザがファイアウォール、ネットワークのパフォーマンス測定や同様のソフトウェアを実行している場合、よいトラブルシューティング方法は、このソフトウェアをオフにするようにユーザに依頼し、パフォーマンスに何らかの効果がないかどうかを確認することです。 この種のソフトウェアがパフォーマンスに悪影響を与えることが非常に多くあります。
    • TCP/IP の設定誤り - ほとんどのサービス プロバイダーにおいて、DHCP を使用して、IP アドレス、ネットワーク マスク、デフォルト ゲートウェイ、DNS サーバを CPE 機器に設定する必要があります。 問題のあったエンドユーザが、これらのすべてのパラメータを取得するために DHCP を使用して CPE デバイスを設定できていることを確認します。
    エンド ユーザにこれらの問題がまったくない場合、前述のセクションのとおりに、エンド ユーザが最大ダウンロード レートまたは最大アップロード レートを超えていないことを確認する必要があります。

    結論

    DOCSIS ケーブル ネットワークは高度なシステムであり、計画および保守を正しく行う必要があります。 DOCSIS ケーブル システムにおけるほとんどのパフォーマンスの問題は、計画や保守が正しく行われていないことに起因しています。 今日のインターネット アクセス市場では、ブロードバンド インターネット アクセスとしてさまざまな選択肢があります。ケーブル サービス プロバイダーでは、システム上のパフォーマンスまたは輻輳の問題が、エンド ユーザが気づくほど重大になり、結果としてユーザが他のブロードバンド アクセスへの変更を考慮する前に、すばやく問題に対処することが重要です。


    関連情報


    Document ID: 12551