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

概要

さまざまな問題が、Data-over-Cable Service Interface Specifications（DOCSIS）システムのケーブル モデムのパフォーマンスと速度に影響する可能性があります。このドキュメントでは、ケーブル サービス プロバイダーの観点から低速スループットの主な原因に対処する方法について説明します。

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

次のセクションでは、低速のパフォーマンスに関して最も多く見られる潜在的な原因と解決案を確認します。具体的には、次の問題があります。

• DOCSIS 設定ファイル内の制限によって制約されたパフォーマンス.

• ケーブルモデム終端システム(CMTS)で最適でないレート制限方式を使用することによって発生する、バースト性または不定のダウンロードパフォーマンス。

• アップストリームおよびダウンストリームのチャネル輻輳.

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

• ケーブル装置におけるノイズやエラー.

• Under poweredエンドユーザ宅内機器(CPE)。

これらはそれぞれ個別にまたは組み合わされると、ケーブルネットワークのスループットとパフォーマンスに影響を及ぼす可能性があります。

この文書では、ケーブル ネットワークがまったく接続できないこと、またはケーブル モデムがオンラインにならないことのトラブルシューティングについては説明しません。代わりに、このような問題については、『トラブルシューティング：uBRケーブルモデムがオンラインにならない』を参照してください。

はじめに

前提条件

このドキュメントに関しては個別の前提条件はありません。

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づくものです。

• uBR7200およびuBR7100 CMTSのCisco IOS®ソフトウェアリリース12.1(9)EC

• CMTS製品のCisco uBR7100、uBR7200、およびuBR7200VXRスイート。

• このドキュメントの情報は、シスコブランドのCMTS機器用のDOCSIS 1.0ベースのCisco IOSソフトウェアのその他すべてのリリースに関連しています。

このマニュアルの情報は、特定のラボ環境に置かれたデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。実稼動中のネットワークで作業をしている場合、実際にコマンドを使用する前に、その潜在的な影響について理解しておく必要があります。

達成されるパフォーマンスレベルの正確な決定

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

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

図1 (この図をビデオ形式で表示するには、ここをクリックします)

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

• エンド ユーザと CMTS 間のハイブリッド ファイバ同軸ネットワーク.

• CMTS がケーブル サービス プロバイダーのネットワークに接続する、ローカルの CMTS ネットワーク セグメント.

• ケーブル サービス プロバイダーの内部ネットワーク.

• パブリック インターネット

2点間で速度試験を行う場合、2点間のすべてのネットワークコンポーネントの速度が測定されます。

たとえば、128 Kbps ISDN回線を介してインターネットに接続されているCPEとサーバ3の間で速度テストを実行する場合、ケーブルセグメントで使用可能な帯域幅が128 Kbpsを超えても、128 Kbpsを超える速度はありません。

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

何らかの理由で、サーバをローカルCMTSネットワークセグメントに接続できない場合、ケーブルセグメントのパフォーマンスをテストする次に正確な方法は、CPEとサーバ2間の速度テストです。

ケーブル セグメントのパフォーマンスに関して、最も不正確な確認方法は、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ベースのアップロードおよびダウンロードテストは、約3 Mbps以下のテスト速度でのみ信頼性が高くなります。高速では、CPEデバイス、サーバ、またはネットワークインターフェイスカード(NIC)の処理能力がテストの制限要因になる可能性があります。約3 Mbpsを超える速度のテストには、専用のデータスループットテスト機器を使用する必要があります。

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

同様のテストは、サービスプロバイダーのネットワークにHTTP Webサーバをセットアップし、HTTPダウンロードを実行することによって行われます。

図 2

Note: 
!--- Comments are in blue.

C:\>ftp 172.17.110.132                    


!--- Initiate the FTP session to the server.
 

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


!--- Enter the FTP server username.
 

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


!--- Enter the FTP server password. 


230 User anonymous logged in. 
ftp> dir                                  


!--- View the contents of the current directory.
 

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   


!--- A 3 M file that you can download.


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


!--- Turn on Binary File transfer mode.


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


!--- Retrieve the file cable.txt and wait for it to download.
 
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.35 Seconds 29.43 Kbytes/sec. 


!--- Download complete. It seems that the download occurred !--- at 29.43 Kbytes/sec, which equals 235 Kbits/sec. This is about 90 percent of !--- the allowed 256 Kbps download rate for the modem being tested.
 

ftp> put cable.txt                       


!--- Begin uploading the file. You need to make sure you have !--- the correct access in order to upload a file to the FTP server or !--- you may get an access-denied error.
 

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.49 Seconds 7.58 Kbytes/sec. 


!--- Upload Complete. Here you see the upload !--- occurred at 7.58 Kbytes/sec, !--- which is equivalent to 60.64 Kbits/sec. This !--- is about 90 percent of the allowed !--- 64 Kbps upload rate for the modem being tested.
 

ftp> quit                                


!--- Exit the FTP client application.
 
221 Goodbye.

FTP転送が発生している間、show interface cable X/Y sid Z countersコマンドを使用してCMTSのテストの進行状況を監視できます。ここで、cable X/Yはテスト中のモデムのケーブルインターフェイス、Zはテスト中のモデムのサービスID番号です。このコマンドにより、特定のケーブル モデムからのバイト数、または特定のケーブル モデムへのバイト数が表示されます。たとえば、テスト中の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 5    online     1996    0.25  5   2   10.1.1.24       0001.9659.4461

ダウンロードまたはアップロードの進行中に、clear countersコマンドを使用して、CMTS上のすべてのパケットカウンタをゼロに戻します。カウンタがクリアされた正確なタイミングで、ストップウォッチまたはタイマーを開始します。

uBR7246-VXR# clear counters              


!--- Reset packet counter to zero.

 
Clear "show interface" counters on all interfaces [confirm]     


!--- Start the stopwatch when you hit Enter.

stopwatchまたはtimeが正確に1分を読み取ったら、show interface cable X/Y sid Z countersコマンドを発行します。最初にコマンドを入力し、タイマーが1分を示す場合はEnterキーを押すことが最適です。テストは、より長い期間または短い期間にわたって実行できます。テスト期間が長いほど、結果の精度は高くなりますが、stopwatchタイマーが指定した時間に達する前にダウンロードまたはアップロードが完了していないことを確認してください。そうでないと、測定が不正確になります。

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


!--- Hit enter when stopwatch is at exactly one minute.
 
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 countersコマンドを使用してアップロード速度を調べるには、ケーブルモデムからアップストリーム方向に送信されたバイト数を判別するためにInkots列を使用する必要があります。

show interface cable sid countersコマンドの詳細については、『Cisco Broadband Cable Command Reference Guide』を参照してください。

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

DOCSIS 設定ファイルによるパフォーマンス制限

低速のケーブル モデムに関するトラブルシューティングを行う際には、まず、ケーブル モデムに関するサービス クラス上の規定のスループット制限の情報を収集する必要があります。ケーブル モデムがオンラインになると、DOCSIS 設定ファイルがダウンロードされます。このファイルには、最大アップロード レートや最大ダウンロード レートなどの、動作上の制限が指定されています。通常、ケーブル モデムがこのレートを超えることは許可されません。

最初に、問題のあるケーブルモデムのMACアドレスを特定する必要があります。MACアドレス0050.7366.2223のモデムでは、スロードスループットに問題が発生しています。次の例に示すように、show cable modem <mac-address>コマンドを実行して、このケーブルモデムが使用しているサービスクラス(cos)プロファイルを調べる必要があります。

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  5   0   10.1.1.10       0050.7366.2223

このケーブルモデムのQuality of Service(QoS)プロファイルは5です。このQoSプロファイルが対応するダウンストリームレートとアップストリームレートを調べるには、show cable qos profile 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がダウンストリームで256 Kbpsを提供するサービスに対応し、64 Kbpsがアップストリームであることを示しています。QoSプロファイル5を使用してケーブルモデムに接続されているCPEは、これらの制限を超えることはできません。QoSプロファイルの設定は、ケーブルモデムがプロビジョニングシステムのTFTPサーバからダウンロードしたDOCSISコンフィギュレーションファイルの内容によって決まります。したがって、システムのQoSプロファイル5は、上記の例のQoSプロファイル5と同じではない場合があります。

エンドユーザのダウンロードおよびアップロードパフォーマンスが、QoSプロファイルに示されている制限と相関する場合、ケーブルモデムがプロビジョニングおよび設定されたサービスクラスとスループットレベルを取得しています。アップロードおよびダウンロードのスループットを高くする唯一の方法は、ケーブル モデムがダウンロードする DOCSIS 設定ファイルを、より高いスループットの指定されたファイルに変更することです。DOCSISコンフィギュレーションファイルを作成または変更する方法の詳細については、『Cisco DOCSIS Configuratorを使用したDOCSIS 1.0コンフィギュレーションファイルの構築』というドキュメントを参照してください。

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

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

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

CMTSが使用するデフォルトのレート制限方式は、各ケーブルモデムとの間の1秒間のトラフィックのレートを監視します。ケーブルモデムが1秒未満で1秒当たりのクォータを超える数を送信または受信した場合、CMTSは残りの秒に対して、そのケーブルモデムへのトラフィックの流れを許可しません。

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

ダウンストリームのレート制限に最適な方式は、トラフィックシェーピングを使用したトークンバケットのレート制限アルゴリズムです。このレート制限方式は、安定したレートでスムーズなWebブラウジング体験を実現すると同時に、DOCSISコンフィギュレーションファイルで指定された所定のダウンロードレートを超えないように最適化されています。

この方式は、ケーブル モデムにおいてパケットが送受信されるたびに、ケーブル モデムによるデータのダウンロード レートまたはアップロード レートを測定するように機能します。問題のパケットの送受信によってモデムが許容される転送レートを超えた場合、ダウンストリームの帯域幅制限を超えずにCMTSがパケットを送信できるようになるまで、パケットはCMTSメモリにバッファリングまたはキャッシュされます。

注：ダウンストリームトラフィックレートが、ケーブルモデムで許可されているダウンストリームレートを常に超える場合、最終的にパケットはドロップされます。

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

トークンバケットレート制限とトラフィックシェーピング方式は、次のケーブルインターフェイスコンフィギュレーションコマンドを発行して、ケーブルインターフェイスのダウンストリームパスで有効にできます。

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

注：ユーザのCMTSでトークンバケットシェーピングを有効にすることを強く推奨します。このコマンドは、Cisco IOSソフトウェアリリース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 rate-limitコマンドの詳細については、『Cisco Broadband Cable Command Reference Guide』を参照してください。

ユーザは、show interface cable X/Y sid <Z> countersコマンドを使用して、CMTSが特定のケーブルモデムへのトラフィックをどの程度厳しく制限しているかを確認できます。ここで、cable 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のままになります。ゼロを大幅に上回る場合、ケーブルモデムがアップストリームレート制限を正しく実行していない可能性があります。

注：show interface cable X/Y sid Z countersコマンドで表示される値は、次の例に示すようにclear countersコマンドを発行すると、0にリセットされる場合があります。

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 sid countersコマンドの詳細については、『Cisco Broadband Cable Command Reference Guide』を参照してください。

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

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

特定のアップストリームポートのアップストリーム使用率は、CMTSコマンドshow interface cable X/Y upstream <Z>を実行することで取得できます。ここで、cable X/Yはダウンストリームインターフェイス番号、Zはアップストリームポート番号です。Zを省略すると、インターフェイスケーブルX/Yのすべてのアップストリームの情報が表示されます。show interface cable upstreamコマンドの詳細は、『Cisco Broadband Cable Command Reference Guide』を参照してください。

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ごとの最大ユーザ数』を参照してください。

• アップストリームチャネル幅の増加 – これは、アップストリームスペクトルの厳密かつ徹底した分析を含み、チャネル幅の増加をサポートするために十分な信号雑音比(SNR)特性を持つ十分な広い帯域を見つけることを含みます。アップストリームチャネル幅は、慎重な計画を立てなければ変更しないでください。この変更は、ユーザのケーブルシステム内の他のサービスに影響を与える可能性があるためです。アップストリームチャネルの幅を変更するには、cable interfaceコマンドcable upstream Z channel-width <new-channel-width>を使用します。Zはアップストリームポート番号で、新しいチャネル幅は20000、40000、1600000（デフォルト）または3200000です。

  uBR7246-VXR(config-if)# cable upstream 0 channel-width 3200000
  

  show interface cable upstreamコマンドの詳細は、『Cisco Broadband Cable Command Reference Guide』を参照してください。

• アップストリームのデジタル変調方式を16-Quadrature Amplitude Modulation(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 modulation-profileコマンドの詳細については、『Cisco Broadband Cable Command Reference Guide』を参照してください。「Cisco ケーブルモデム終端システムのケーブル変調プロファイルの設定」も参照してください。

• ケーブルモデムごとに許可されるアップストリームスループットの削減 – 適切なDOCSISコンフィギュレーションファイルで最大アップストリーム送信レートを削減することで、ケーブルモデムユーザはアップストリーム方向で高いレートで送信できず、アップストリーム輻輳は緩和されます。このコースのマイナスの側面は、ケーブルモデムユーザが低速のサービスクラスに制限されることです。「Cisco DOCSISコンフィギュレータを使用した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北米DOCSISを導入しているため、ダウンストリームチャネルごとに27 Mbpsを使用できます。

ダウンストリームチャネルの使用状況は、show interface cable X/Yコマンドを発行して判別できます。ここでcable 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 パラメータによって示されるインターフェイスの帯域幅です。Cisco IOSソフトウェアリリース12.1(8)EC以降では、この値はダウンストリーム変調方式と使用されているDOCSISのバージョンに従って自動的に調整されます。Cisco IOSソフトウェアリリース12.1(8)ECよりも前のリビジョンでは、この値はケーブルインターフェイスコマンドbandwidth <bandwidth-in-kilo-bits-per-second>を使用して手動で設定する必要があり、それ以外の場合はデフォルト値の2770000000000000000000

2番目の注意点は、txloadパラメータで示される伝送負荷です。このパラメータは255のメトリックを示します。0/255は、ダウンストリーム方向のトラフィックが255/255に流れていないことを意味します。これは、データが可能な最大レート（この場合は27000 Kbps）でダウンストリームを伝送されることを意味します。 このパラメータがピーク時に約75 %を超えて一貫して実行されている場合（たとえば、191/255を超える場合）、エンドユーザはインターネットへのアクセスが遅くなり、遅延が長くなります。

3番目に注目すべきコンポーネントは出力レートです。これは、ビット/秒でのダウンストリームの平均スループットレートを示しています。この数がピーク時の利用可能なダウンストリーム帯域幅の約75 %を一貫して超えると、エンドユーザはインターネットアクセスが遅くなり、遅延が大きくなります。

デフォルトでは、これらの統計情報は5分間の移動平均で計算されます。(平均の計算方法の詳細は、『show interfacesコマンド出力のビット/秒(bps)の定義について』を参照してください)。 この平均が計算される期間は、cable interfaceコマンドload-interval 30を発行して30秒まで短縮できます。この期間を30秒に下げることで、このセクションで説明する各パラメータについて、より正確な最新の値が計算されます。

ダウンストリームチャネルの使用状況は、異なるユーザがケーブルモデムを使用する機会があるため、ダウンストリームの使用状況を低い使用時間ではなく、1日の最も混雑する時間帯に監視することが重要です。

ダウンストリーム輻輳を緩和する方法は、次のとおりです。

• ダウンストリームあたりのケーブルモデム数の減少 – 特定のダウンストリームに接続されているケーブルモデムが多すぎる場合、または特定のダウンストリームのユーザがダウンストリーム帯域幅の使用率が高い場合は、輻輳したダウンストリームチャネルの一部のユーザを別のダウンストリームチャネルに移動します。これは通常、ダウンストリームに関連付けられたダウンストリームファイバノードのグループを2つのグループに分割し、新しいグループごとにダウンストリームチャネルを割り当てることで実現されます。「CMTSごとの最大ユーザ数」を参照してください。

• ダウンストリームデジタル変調方式を256-QAMに変更する：このアクションでは、システムが256-QAM信号をサポートできるかどうかを確認するため、ダウンストリームスペクトルの厳密かつ徹底した分析が必要です。この分析が正しく行われないと、パフォーマンスがさらに低下したり、ダウンストリームの完全な停止が発生したりするリスクがあります。次に示すケーブル インターフェイス コマンドを発行することによって、ダウンストリーム変調方式を変更できます。

  uBR7246-VXR(config-if)# cable downstream modulation 256qam
  

  cable downstream modulationコマンドの詳細については、『Cisco Broadband Cable Command Reference Guide』を参照してください。

• ケーブルモデムごとの許容ダウンストリームスループットの削減 – 適切なDOCSISコンフィギュレーションファイルで最大ダウンストリーム伝送レートを削減することで、ケーブルモデムユーザはダウンストリーム方向で高いレートでダウンロードできず、ダウンストリーム輻輳は緩和されます。このコースのマイナスの側面は、ケーブルモデムユーザが低速のサービスクラスに制限されることです。「Cisco DOCSISコンフィギュレータを使用したDOCSIS 1.0コンフィギュレーションファイルの構築」を参照してください。

  注：このセクションで説明する対策では、すでに輻輳が発生しているシステムのパフォーマンスが大幅に向上することはありません。

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

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

バックホールネットワークの輻輳が問題かどうかを判断する最も簡単な方法は、ワークステーションをCMTSと同じネットワークセグメントに接続し、ケーブルモデムの背後にあるエンドユーザが到達しようとしている同じWebサイトを参照することです。それでもパフォーマンスが低下する場合は、CMTSやケーブルセグメントに関係のないネットワークでパフォーマンスの問題があります。ローカルCMTSネットワークセグメントのパフォーマンスが、ケーブルモデムに接続しているユーザのパフォーマンスよりも大幅に優れている場合は、CMTSとケーブルセグメントに対する取り組みに集中してください。

図 3

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

ケーブル設備上のノイズとエラー

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

パフォーマンスとスループットの低下に加えて、ノイズや無線周波数(RF)の問題の主なインジケータには次のものがあります。

• ケーブルモデムがオフラインで散発的にドロップしたり、init(r1)またはinit(r2)状態のままになる。

• show controller cable X/Y upstream Z の出力に見られる低い概算 SNR 値。X/Y には監視対象のケーブル インターフェイスを、Z には監視対象のアップストリーム ポートをそれぞれ指定しますDOCSIS仕様では、すべてのアップストリーム信号に対して少なくとも25 dBの搬送波対雑音比(CNR)が必要です。これは、約29 dBの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 controllers cable upstream spectrumコマンドの詳細については、『Cisco Broadband Cable Command Reference Guide』を参照してください。

• show cable hopコマンドの出力では、Corr Forward Error Correction(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 Broadband Cable Command Reference Guide』を参照してください。

• 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 

• 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または設定の問題の判別とCisco uBR7200シリーズルータのケーブルヘッドエンドへの接続』を参照してください。

CMTSでのCPU高使用率

状況によっては、最適でない設定、特定の管理機能の過剰な使用、またはCMTSによってルーティングされる非常に多くのパケットが原因で、Cisco CMTSが過負荷になる可能性があります。

Cisco CMTSのCPU使用率を判別する最良の方法は、show process cpuコマンドを実行すること。現在のCPU使用率は、コマンドの出力の1行目に表示されます。

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使用率を削減するための一般的な戦略は次のとおりです。

• Cisco IOSソフトウェアリリース12.1(9)EC以降にアップグレードし、グローバル設定コマンドip cefを有効にして、CMTS上のインターフェイスにno ip route-cacheコマンドが設定されていないことを確認します。これは通常、トラフィック関連のCPU使用率を10 ～ 15 %削減します。これらすべてのステップを組み合わせて実行してください。

• Simple Network Management Protocol(SNMP)管理ステーションがCMTSのポーリングでアグレッシブすぎないことを確認します。これにより、IP SNMPプロセスでCPU使用率が高くなります。

• show tech コマンドを、複数回連続で実行しないでください。これにより、仮想EXECプロセスでCPU使用率が人為的に高くなります。

• CMTSでdebugコマンドが実行されていないことを確認します。

Cisco CMTS製品を含むCiscoルータのCPU高使用率の詳細については、『CiscoルータのCPU高使用率のトラブルシューティング』を参照してください。

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

ケーブル ネットワークへのアクセスが低速である原因は、エンド ユーザの CPE 機器の問題に起因する場合が多くあります。1 名または数名のユーザにおいてだけスループットが低速になり、残りのユーザには問題がない場合、ユーザ環境に固有の問題がある可能性を明示しています。

• Under powered or overload CPE：問題のエンドユーザが古いCPE機器、または選択したオペレーティングシステムやインターネットアクセスソフトウェアを実行するのに十分な処理能力がない機器を使用している場合、このエンドユーザには問題があります。この場合の唯一の解決策は、エンド ユーザが CPE 機器をアップグレードすることです。

• ファイアウォールまたはパフォーマンス測定ソフトウェア：エンドユーザがファイアウォール、ネットワークパフォーマンス測定などの類似ソフトウェアを実行している場合、適切なトラブルシューティング手順は、パフォーマンスに影響があるかどうかを確認するためにこのソフトウェアをオフにします。このようなソフトウェアは、パフォーマンスに悪影響を及ぼす可能性があります。

• TCP/IPの設定の誤り：ほとんどのサービスプロバイダーでは、エンドユーザがCPE機器にダイナミックホストコンフィギュレーションプロトコル(DHCP)を使用してIPアドレス、ネットワークマスク、デフォルトゲートウェイ、およびDNSサーバを取得させる必要があります。 問題が発生しているエンドユーザに、DHCPを使用してこれらすべてのパラメータを取得するようにCPEデバイスが設定されていることを確認します。

上記の問題がエンドユーザに発生していない場合は、上記のセクションに従って、エンドユーザが最大ダウンロードまたはアップロード速度を超えていないことを確認します。

結論

DOCSISケーブルネットワークは、適切な計画とメンテナンスを必要とする高度なシステムです。DOCSISケーブルシステムのパフォーマンスの問題のほとんどは、適切な計画とメンテナンスが行われていないことによるものです。現在のインターネットアクセス市場では、さまざまなブロードバンドインターネットアクセスの選択肢がありますが、エンドユーザが影響を受けるほど重大になる前に、ケーブルサービスプロバイダーがシステムのパフォーマンスや輻輳の問題に迅速に対処することが重要です。

関連情報

• トラブルシューティング：uBR ケーブル モデムがオンラインにならない場合
• CMTS における RF または設定の問題の特定
• Cisco uBR7200 シリーズ ルータとケーブル ヘッドエンドの接続
• Cisco ルータの CPU 使用率が高い場合のトラブルシューティング
• テクニカル サポートとドキュメント – Cisco Systems