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

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

2016 年 10 月 27 日 - 機械翻訳について
その他のバージョン: PDFpdf | ライター翻訳版 (2008 年 5 月 29 日) | 英語版 (2015 年 8 月 22 日) | フィードバック


目次


概要

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

このより広いインターネットのそれよりもむしろ、どのようなスループットレベルをエンドユーザがおよび測定されるパフォーマンスはケーブルネットワークのそれであることを確かめる方法を達成しているか正確に判別する方法の最初に資料外観。

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

  • DOCSISコンフィギュレーションファイルの制限によって制限 される パフォーマンス。

  • Cable Modem Termination System (CMTS)の方式を制限する最適でない 比率の使用によって引き起こされるバースト性か不定なダウンロード パフォーマンス。

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

  • バックホール ネットワークかインターネット輻輳。

  • ケーブル設備のノイズかエラー。

  • 動力を与えられたエンドユーザ の 顧客の下で機器(CPE)を前提とします。

これらののそれぞれまたは組み合せのそれぞれはケーブルネットワークのスループットおよびパフォーマンスに影響を及ぼす場合があります。

この資料はケーブルネットワークまたはケーブルモデム来ないオンライン上の完全な接続切断を解決することを説明しません。 その代り、この種の問題のためのトラブルシューティング:uBR ケーブル モデムがオンラインにならない場合を参照して下さい。 さらに、パフォーマンス上の問題に直面している UBR 900 または CVA 120 シリーズ ケーブル モデムのエンドユーザのために最もよいのこの問題を解決するためのインポートを開始して uBR900 シリーズ ケーブルモデムエンドユーザ向けの初心者 FAQ です。

はじめに

表記法

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

前提条件

このドキュメントに関する固有の要件はありません。

使用するコンポーネント

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

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

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

  • この文書に記載されている情報は Cisco ブランド CMTS 機器のための DOCSIS 1.0 ベースの Cisco IOSソフトウェアの他のすべての現在利用できるリリースのために関連しています。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。 対象のネットワークが実稼働中である場合には、どのような作業についても、その潜在的な影響について確実に理解しておく必要があります。

正確に実現するパフォーマンス の レベルを判別します

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

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

/image/gif/paws/12551/troubleshooting_slow_perf3.gif

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

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

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

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

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

  • 公衆インターネット。

2 ポイント間の速度テストを行うとき、2 ポイント間のすべてのネットワークコンポーネントの速度は測定されています。

たとえば、128 キロビット/秒 ISDN回線を通してインターネットに接続されるサーバ 3 間の速度テストをと CPE 行うことがそこに決して 128 キロビット/秒以上の速度でなければ、ケーブル セグメントの利用可能 な 帯域幅がすばらしいそして 128 キロビット/秒でも。

ケーブル セグメントのパフォーマンス自体を測定するほとんどの正確な方法は CMTS と同じネットワークセグメントに接続されるサーバ 1 間の速度テストを行うことですと CPE。 これは唯一のパスデータがである同軸ケーブル セグメント移動する必要があるという理由によります。 データはまたローカル CMTS ネットワークセグメントを渡って移動する必要がありますがこのセグメントは高帯域幅(FastEthernet かより大きい)、輻輳の高レベルがないことを推定されます。

どういうわけか、サーバがローカル CMTS ネットワークセグメントに接続することができなければケーブル セグメントのパフォーマンスをテストする次のほとんどの正確な方法は CPE とサーバ 2.間の速度テストを行うことです。 これは CMTS と CPE 間のケーブルサービスプロバイダーの内部ネットワーク内に十分に高速および輻輳状態でないリンクがある限り正確な測定です。

ケーブル セグメントのパフォーマンスを判別する最も不正確な方法は公衆インターネットの CPE とサーバ間の速度テストを行うことです。 これは、CPE とサーバ間にあるパブリック インターネットのリンクが輻輳している場合があるため、または CPE とインターネット上のサーバ間のパスに非常に低速なリンクが存在する場合があるためです。

ダウンロード レートおよびアップロード レートの判別

アップロードおよびダウンロードのスループットに関する正確な達成レベルを客観的に測定することが重要です。その後、DOCSIS システムにパフォーマンスの問題があるかどうかを結論付けます。

アップロードし、ダウンロードが FTP を使用して大きいファイルかケーブルモデムに接続される CPEデバイス間の HTTP をアップロードするか、またはダウンロードすることである行われている速度を判別する最も簡単な方法および CMTS の後ろのサーバ。 ほとんどの FTP クライアントおよび HTTP クライアントは、転送中または転送の完了後に、実行されたダウンロードまたはアップロードの速度を表示できます。 FTP または HTTP オペレーションの結果として見られる転送速度は達成される本当総スループットの一般的に約 90%です。 この FTP または HTTP の転送速度の表示には、CPE デバイスと CMTS 間でやりとりされる必要のある、余分な IP および DOCSIS のオーバーヘッドが考慮されないためです。

サード パーティ専用試験装置の、Netcom Smartbits か IXIA パケット 生成機能のような使用によるスループットをあります、たとえば測定するより多くの正確な方法がこれらのシステムが本番ケーブルネットワークにすぐに利用できないまたは容易に接続されて常にどんなに。 スループット テストがラボ 環境で遂行される場合無益ことはです、専用装置を使用して FTP または HTTP 簡単なダウンロードより大いに詳細をテスト明らかにします。

FTP-または Http ベース アップ ロードおよびダウンロード テストは 3 Mbps のまわりでの速度をテストするためだけに信頼できるまたはより少しです。 より高い速度で CPEデバイス、サーバまたはネットワーク インターフェース カード(NIC)の処理力はテストの制限要因になるかもしれません。 3Mbps またはそれよりも速い速度のテストをする場合、データ スループット テスト専用の装置を使用してください。

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

同じようなテストは HTTP Webサーバ セットアップをサービスプロバイダーのネットワークの持っていることおよび HTTP ダウンロードを行うことによって行なわれます。

/image/gif/paws/12551/troubleshooting_slow_perf2.gif

図 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転送が発生している間、ケーブル X/Y がテストの下のモデムがに接続される、Z がテストの下にモデムのサービスID (SID)番号であるケーブルインターフェイスどこにであるか show interface cable X/Y sid Z カウンターを使用して CMTS におけるテストのプログレスを監視することは可能性のある命じますであり。 このコマンドにより、特定のケーブル モデムからのバイト数、または特定のケーブル モデムへのバイト数が表示されます。 たとえば、テストされる CPE が MAC アドレス 0001.9659.4461 のケーブルモデムの後ろにある場合。

第 1 は 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.

ストップウォッチか時間以降に 1 分を、発行します show interface cable X/Y sid Z カウンター コマンドを丁度読みます。 タイマーが 1 分を示すときコマンドを最初に入力し、次に入力を丁度押すことが最善であるかもしれません。 テストはより長いですか短期間に実行されたことができます。 しかしより長いテスト期間、より正確結果、ストップウォッチ タイマーが指定時間に達する前にダウンロードかアップロードが終了しないことを確かめます、他では測定単位は不正確です。

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 キロビット/秒であるために示されています。

アップロード速度を show interface cable X/Y sid Z カウンターを使用して検知 するために、Inoctets カラム ケーブルモデムからのアップストリーム 方向で送信 される バイト数を判別するのに使用されるべきです命じて下さい。

show interface cable sid counters コマンドに関する詳細については Cisco ブロードバンドケーブル コマンドレファレンスガイドを参照して下さい。

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

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

収集される必要がある最初の情報は遅いケーブル モデムのパフォーマンスをトラブルシューティングするときケーブルモデムの所定のサービス クラス スループット 制限です。 ケーブル モデムがオンラインになると、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  5   0   10.1.1.10       0050.7366.2223

ここにそれはこのケーブルモデムに 5.の Quality of Service (QoS) プロファイルがどんなダウンストリーム および アップストリーム率この QoS プロファイルがに対応するか知るために、使用するプロファイル数が興味の 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 キロビット/秒を提供するサービスに対応し、64 キロビット/秒がアップストリームであることをここに示します。 QoS プロファイル 5 を使用してケーブルモデムに接続されるどの CPE でもこれらの制限を超過できません。 QoS プロファイル設定はプロビジョニング システムの TFTPサーバからケーブルモデムによってダウンロードされる DOCSISコンフィギュレーションファイルのコンテンツによって確認されます従ってシステムの QoS プロファイル 5 は上に示されている例の QoS プロファイル 5 と同じではないかもしれません。

QoS プロファイルで示されている制限のエンドユーザのダウンロードおよびアップロード パフォーマンス相互的関係がそれからそれらケーブルモデムが提供され、設定されたスループットレベルおよびサービス クラスを得れば。 アップロードおよびダウンロード スループットを増加する唯一の方法はケーブルモデムによってダウンロードされるより高いスループット制限がある 1 つへ DOCSISコンフィギュレーションファイルを変更することです。 Cisco DOCSIS コンフィギュレータを使用した DOCSIS 1.0 コンフィギュレーション ファイルの構築登録ユーザのみ)と資格を与えられる DOCSISコンフィギュレーションファイルを作成または変更する方法に関する詳細な使用説明書に関しては資料を参照して下さい。

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

エンドユーザがケーブルモデムの DOCSISコンフィギュレーションファイル割り当てより大きい比率でインターネットからデータをダウンロードすることを試みているとき CMTS はレートリミット ユーザが帯域幅の割り当てられた共有がより多くを消費しないようにするためにそのユーザに送信 される トラフィックなります。

DOCSISコンフィギュレーションファイルが可能にする何をエンドユーザがより大きい比率でインターネットにデータをアップロードするか、または送信 することを試みるとき同様に、ケーブルモデム自体はから CMTS への過剰なトラフィックをケーブル セグメントに移動停止する必要があります。 ケーブルモデムが、どういうわけか、きちんと制限するアップストリーム レートを行わなければ CMTS は明示的に許可された比率より高く送信からのケーブルモデムを禁止します。 CMTS におけるこの動作は「切り刻まれた」特性のケーブルモデムがアップロード速度制限を割り当てられるサービスプロバイダーを覆すことができないことを確認することです。

CMTS によって使用されるデフォルト レートリミット方式は各 1秒の間隔にわたる各ケーブルモデムに/からトラフィックの比率を監察します。 ケーブルモデムが第 2 よりより少しの毎秒クォータより多くを送信 するか、または受け取る場合、CMTS はもうトラフィックが第 2 の他のためのそのケーブルモデムにフローしないようにしません。

一例として、QoS プロファイルのケーブルモデムを奪取 しま 512 キロビット/秒のダウンロード速度を割り当てます。 ケーブルモデムが第 2 の前半内の 512 キロビット(64 キロバイト)をダウンロードする場合、第 2 の次の半分のために、ケーブルモデムは何でもダウンロードすることができません。 この種のレート制限の動作には、1 秒または 2 秒ごとに停止と開始を繰り返すような、バースト性のあるダウンロードの型の影響が見られる場合があります。

使用する最もよいダウンストリーム レートリミット方式はトラフィック シェーピングを用いるトークンバケットレート制限アルゴリズムです。 このレートリミット方式は同時にエンドユーザが DOCSISコンフィギュレーションファイルで指定どおりに所定のダウンロード速度を超過することができないようにしている間スムーズな Web ブラウジング エクスペリエンスを安定したレートで可能にする最適化されました。

この方式がはたらく方法はケーブルモデムがダウンロードしますか、またはデータをアップロードしていつもパケットがケーブルモデムで送受信される比率を測定することで。 疑わしいパケットを送信 するによりまたは受信することがモデムが割り当てられた転送レートが超過すれば場合パケットは CMTS メモリでバッファリングされるか、または CMTS がダウンストリーム 帯域幅制限を超過しないでパケットを送信できるまでキャッシュされます。

ダウンストリーム トラフィックレートが一貫してケーブルモデムのための割り当てられたダウンストリーム レートが超過する場合、パケットは結局廃棄されます。

制限し、形づく比率のこのスムーズな方式の使用によって HTTP Web ブラウジングおよび FTP ファイル転送のようなほとんどの TCP ベースのインターネットアプリケーションはデフォルト レートリミット方式を使用するときよりもっとスムーズおよび効率的に動作します。

トークンバケット rate-limiting-with-traffic-shaping 方式はケーブルインターフェイスのダウンストリーム パスで次のケーブルインターフェイス 設定コマンドの発行によって有効に することができます:

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

Cisco ブロードバンドケーブル コマンドレファレンスガイドをケーブル ダウンストリーム レート制限に関する詳細については参照し、アップストリーム rate-limit コマンドをケーブル接続して下さい

ユーザはひどく CMTS がケーブル X/Y がケーブルモデムが接続される、Z は観察されるモデムの SID 数ですケーブルインターフェイスである show interface cable X/Y sid <Z> カウンター コマンドのか使用によって特定のケーブルモデムにトラフィックを制限する比率どのようにであるか表示でき。 このコマンドは、モデムに許可されたスループット制限が超過したことが原因で、CMTS がダウンストリームのパケットを廃棄した回数、またはアップストリームのパケットを拒否した回数が表示されます。 No 値なら場合 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 カウンター コマンドによって表示する値はゼロに下記の例に見られるように clear 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 sid counters コマンドに関する詳細については Cisco ブロードバンドケーブル コマンドレファレンスガイドを参照して下さい。

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

アップストリームチャンネルは普通ケーブル システムの最も貴重なリソースです。 現在、ほとんどのケーブルサービスプロバイダーはアップストリームパスで 1.6 MHz チャネル幅および 4位相偏移変調(QPSK)変調を使用しています。 これは 1 チャネルのアップストリーム チャネルに接続されたすべてのユーザが使用可能な、およそ 2.5Mbps の合計アップストリーム帯域幅に相当します。 アップストリームチャンネルが過剰に使用されたり輻輳が生じる過剰に使用されたり輻輳が生じないことを確認することは重要です、他ではそのアップストリーム セグメントのすべてのユーザは貧弱なパフォーマンスに苦しみます。

特定のアップストリームポートのためのアップストリーム使用方法はケーブル X/Y がダウンストリーム インターフェイス番号である Z がアップストリームポート番号である Cmts コマンド show interface cable X/Y upstream <Z> の実行によって得ることができ。 Z が省略される場合、インターフェイス ケーブル X/Y のすべての upstreams のための情報は表示する。 show interface ケーブル アップストリーム コマンドに関する詳細については 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%の上に絶えずある場合、エンドユーザはエンドユーザのアップストリーム データの大きい部分が遅れるか、または廃棄されなければならないのでサービスの非常に悪いレベルを経験します。

アップストリームチャンネル 使用方法は異なるユーザーにケーブルモデムを使用する機会がある従って低い使用 時間によりもむしろ日の使用中時の間にアップストリーム使用方法を監視することは重要ですので日中変更します。

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

  • アップストリームごとのケーブルモデムの数を減らします–特定のアップストリームに接続される余りにも多くのケーブルモデムがあるかまたは特定のアップストリームのユーザがアップストリーム 帯域幅の重いユーザなら、最もよいソリューションは下使用されたアップストリームポート、または全く新しいアップストリームポートへ混雑させたアップストリームポートの何人かのユーザを移動することです。 これはファイバ ノードを 1 アップストリーム結合グループから別のものへ移動するか、または 2 つの別々の結合グループにアップストリーム結合グループを分割することによって通常達成することができます。 詳細については、CMTS ごとの最大ユーザ数はであるもの参照して下さい。

  • アップストリーム チャネル幅増加します–これは増加されたチャネル幅をサポートするには十分な Signal to Noise Ratio (SNR)特性の十分に広くバンドを見つけるようにアップストリーム スペクトルの厳密で、完全な分析を伴います。 アップストリーム チャネル幅は注意深い計画なしでこの変更が可能性としてはユーザのケーブル システムのその他のサービスに影響を与える場合があるので変更するべきではありません。 アップストリーム チャネル幅は Z がアップストリームポート番号である新しいチャネル幅が 200000、400000、800000、1600000 (デフォルト)または 3200000 の 1 つである cable interface コマンド ケーブル アップストリーム Z channel-width <new-channel-width> の使用によって変更することができ。 次に例を示します。

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

    show interface ケーブル アップストリーム コマンドに関する詳細については 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 modulation-profile コマンドに関する詳細については Cisco ブロードバンドケーブル コマンドレファレンスガイドを参照して下さい。 「Cisco ケーブルモデム終端システムのケーブル変調プロファイルの設定」も参照してください。

  • ケーブルモデムごとの許可されたアップストリーム スループットを下げます、最高がアップストリーム 方向およびアップストリーム 輻輳の比率取り除かれるのでケーブルモデム ユーザは–適切な DOCSISコンフィギュレーションファイルの最大アップストリーム送信する 比率の減少によって…で送信できません。 この企画の否定的な側面はケーブルモデム ユーザがより遅いサービス クラスに制限されることです。 Cisco DOCSIS コンフィギュレータを使用した DOCSIS 1.0 コンフィギュレーション ファイルの構築登録ユーザのみ)を参照して下さい。

このセクションで説明されている手段は既に輻輳状態でないシステムのパフォーマンスを大幅に向上しません。

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

ダウンストリーム チャネルには、各アップストリーム チャネルに比べて、共有可能な帯域幅が比較的多くあります。したがって、ダウンストリームでは通常、アップストリームと同程度の輻輳は発生しません。 それにもかかわらず、あらゆる単一 アップストリームチャンネルよりより多くのユーザは一般的に ダウンストリームチャンネル、従ってダウンストリームチャンネルが混雑されるようになれば、ダウンストリーム セグメント エクスペリエンス低下した パフォーマンスに接続されるすべてのユーザを共有します。

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

ダウンストリーム変調方式 使用可能なダウンストリーム帯域幅
64-QAM North American DOCSIS 27 Mbps
256-QAM 北アメリカ DOCSIS 38 Mbps
64-QAM Euro DOCSIS 38 Mbps
256-QAM ヨーロッパの DOCSIS 54 Mbps

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

ダウンストリームチャンネル 使用方法はケーブル X/Y が観察されるケーブルインターフェイスである show interface 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 よりでは、この値は cable interface コマンド 帯域幅 <bandwidth-in-kilo-bits-per-second> を使用して手動で設定する必要がありますか、または他では 27000 キロビット/秒のデフォルト値に残ります。

注意するべき第 2 コンポーネントは txload パラメータによって示されるように伝達 ロードです。 このパラメータは 255 からトラフィックは意味する 255/255 にダウンストリーム 方向でフローしていないことをデータは最大可能性のある 比率でダウンストリームで移動していることを 0/255 が意味するところでメトリックを与えます、(この場合 27000 キロビット/秒で)。 このパラメータがピーク 利用時の間に非常によりおよそ 75%で(たとえば、非常により 191/255)一貫して動作すれば、エンドユーザはより遅いインターネットアクセスおよびより高いレイテンシーを経験し始めます。

注意するべき第 3 コンポーネントはビット/秒で平均ダウンストリーム スループットレートを示す出力レートです。 この数がピーク 利用時の間に一貫して利用可能 な ダウンストリーム 帯域幅のおよそ 75%超過する場合、エンドユーザはより遅いインターネットアクセスおよびより高いレイテンシーを経験し始めます。

デフォルトで、これらの統計情報は 5分間の移動平均計算されます。 (理解することを平均がどのようにの計算されるか詳細については show interfaces コマンド出力からのビット/秒(ビット/秒)の定義を参照して下さい。) ケーブル インターフェイス コマンド load-interval 30 を発行することによって、この平均計算時間を 30 秒まで短縮できます。 30 秒へこの期間を下げることによって、より正確のこのセクションで説明されているパラメータのそれぞれのために最新値計算されます。

ダウンストリームチャンネル 使用方法は異なるユーザーにケーブルモデムを使用する機会がある従って低い使用 時間によりもむしろ日の使用中時の間にダウンストリーム使用方法を監視することは重要ですので日中変更します。

ダウンストリーム輻輳を緩和する方法は下記のものを含んでいます:

  • ダウンストリームごとのケーブルモデムの数を減らします–特定のダウンストリームに接続される余りにも多くのケーブルモデムがあるかまたは特定のダウンストリームのユーザがダウンストリーム 帯域幅の重いユーザなら、最もよいソリューションは別のダウンストリームチャンネルへ混雑させたダウンストリームチャンネルの何人かのユーザを移動することです。 これは 2 つの別々のグループにダウンストリームと関連付けられるダウンストリーム ファイバ ノードのグループの分割によって通常達成することができ、新しいグループのそれぞれを割り当ててダウンストリームチャンネルを分けて下さい。 CMTS ごとの最大ユーザ数はであるもの参照して下さい。

  • ダウンストリーム デジタル モジュレーションスキームの 256-QAM に変更–このアクションはシステムが 256-QAM シグナルをサポートできるかどうか確かめるためにダウンストリーム スペクトルの厳密で、完全な分析が要求します。 この分析がきちんと実行された場合、パフォーマンスが更に低下するか、または完全なダウンストリーム停止が発生するかもしれないことリスクがあります。 ダウンストリーム変調方式は次を見られるように cable interface コマンドの発行によって変更することができます。

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

    cable downstream modulation コマンドに関する詳細については Cisco ブロードバンドケーブル コマンドレファレンスガイドを参照して下さい。

  • ケーブルモデムごとの許可されたダウンストリーム スループットを下げます、最高がダウンストリーム 方向およびダウンストリーム 輻輳の比率取り除かれるのでケーブルモデム ユーザは–適切な DOCSISコンフィギュレーションファイルの最大ダウンストリーム送信する 比率の減少によって…でダウンロードできません。 この企画の否定的な側面はケーブルモデム ユーザがより遅いサービス クラスに制限されることです。 Cisco DOCSIS コンフィギュレータを使用した DOCSIS 1.0 コンフィギュレーション ファイルの構築登録ユーザのみ)を参照して下さい。

    このセクションで説明されている手段は既に輻輳状態でないシステムのパフォーマンスを大幅に向上しません。

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

場合によっては、パフォーマンス問題は CMTS がインターネットに接続するのに使用するまたはインターネットの一部自体かもしれませんことケーブル設備または CMTS における問題の結果ではないかもしれませんが内の輻輳か問題とバックホール ネットワークの関連している。

バックホール ネットワーク 輻輳が問題だったかどうか確認する最も簡単な方法はワークステーションを同じネットワークセグメントに CMTS と接続し、ケーブルモデムの背後にあるエンドユーザが達することを試みているのと同じ Webサイトを参照することを試みることです。 パフォーマンスがそれでも遅い場合、CMTS かケーブル セグメントに関しないネットワークにパフォーマンス問題があります。 ローカル CMTS ネットワークセグメントからのパフォーマンスが CMTS およびケーブル セグメントでケーブルモデム、フォーカス努力に接続されるユーザ向けによりかなりよければ。

/image/gif/paws/12551/troubleshooting_slow_perf3.gif

図3

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

ケーブル プラント上のノイズとエラー

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

パフォーマンスおよびスループットの劣化は別として、いくつかのノイズの主なインジケーターか Radio Frequency (RF)問題は下記のものを含んでいます:

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

  • show controller cable X/Y upstream Z の出力に見られる低い概算 SNR 値。X/Y には監視対象のケーブル インターフェイスを、Z には監視対象のアップストリーム ポートをそれぞれ指定します DOCSIS仕様はすべてのアップストリーム場合のために少なくとも 25 dB の搬送波対雑音比(CNR)を必要とします。 これは、およそ 29dB の SNR に相当します。 Cisco CMTS はすべてのケーブルサービスプロバイダーがシステムの DOCSIS CNR 必要条件を満たすように努力する必要があるどんなに大いにより悪い SNR レベルで QPSK アップストリーム場合を一致して検出する。 次に、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 ケーブル アップストリーム スペクトルに関する詳細については 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 またはノイズ問題に最も適切なフラップ統計情報は抜けていたレンジング要求を示す、および急速にさまざまなアップストリーム電力レベルを示す 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 使用方法

ある状況では Cisco CMTS はある特定の管理機能の使用上の次善の設定が過剰にされた原因、または CMTS によってルーティングされる非常に多くのパケットになることができます。

Cisco CMTS の CPU使用を判別する最もよい方法は show process CPU コマンドを実行することです。 現在の 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 の percent/21 パーセントです。 これは総 CPU使用がシステムのキャパシティの 45%にあることを意味します。 さらに割り込みを保守するのに CPU の 21%使用されています。 この 2 つめの数は、通常、CMTS を経由したパケットのルーティングおよびトラフィックの交換に使用される CPU 使用量に相当します。

5 分 CPU使用がシステムのピーク 利用時の間に一貫して 80%以上である場合、エンドユーザはより遅いパフォーマンスおよび高められた レイテンシーを経験し始めるかもしれません。 5 分 CPU使用がピーク 利用時の間に絶えず 95%以上である場合、CMTS が安定状態を維持するようにする緊急な行為を奪取 して下さい。

CMTS における高CPU 使用方法を減らすためのよくある戦略は下記のものを含んでいます:

  • Cisco IOS ソフトウェア リリース 12.1(9)ec へのまたはそれ以降をアップグレードしに、global configuration コマンド ip cef をアクティブにし、CMTS におけるインターフェイスを確かめないことに設定されるコマンド no ip route-cache があります。 これは 10%からトラフィック関連の CPU使用のリダクション 15%の一般的に原因となります。 これらすべてのステップを組み合わせて実行してください。

  • 簡易ネットワーク管理プロトコル(SNMP) 管理ステーションが CMTS のことをポーリングで余りに積極的ではないことを確かめます。 これは高CPU に IP SNMP プロセスの使用方法を導きます。

  • show tech コマンドを、複数回連続で実行しないでください。 これは高CPU に仮想実行プロセスの使用方法を人工的に導きます。

  • debug コマンドが CMTS で動作していないことを確かめます。

Ciscoルータの高CPU 使用方法に関する詳細については、Cisco CMTS 製品を含んで、トラブルシューティング:Cisco ルータで CPU 使用率が高い場合を参照して下さい。

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

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

  • 動力を与えられたか、または過剰にされた CPE の下—問題のエンドユーザ不平を言うことが古めかしい選択されたオペレーティング システムかインターネットアクセス ソフトウェアを実行するには十分に強力ではないかもしれない CPE装置を、か機器を使用していればこのエンドユーザに問題があります。 この場合の唯一の解決策は、エンド ユーザが CPE 機器をアップグレードすることです。

  • ファイアウォールまたはパーフォーマンス測定 ソフトウェア—エンドユーザがファイアウォール、ネットワーク パフォーマンス測定、または他の同じようなソフトウェアを実行すれば、よいトラブルシューティング の 手順はパフォーマンスに効果をもたらすかどうか見るためにこのソフトウェアを消してユーザにもらうことです。 多くの場合、これらの種類のソフトウェアはパフォーマンスの悪影響がある場合があります。

  • 不適切に設定された TCP/IP 設定—ほとんどのサービスプロバイダーはエンドユーザが CPE装置をダイナミック ホスト コンフィギュレーション プロトコルを通って IP アドレス、ネットワークマスク、デフォルト ゲートウェイおよび DNSサーバを得てもらうことを必要とします。 問題に直面しているこれらのパラメータすべてを得るのにどのエンドユーザでも CPEデバイスを DHCP を使用するように設定してもらうことを確認して下さい。

エンドユーザは上記リストに記載されている問題のどれもあるように要求しない場合エンドユーザが上記のセクションによってダウンロード/アップロード の 最大速度を超過していないことを確認して下さい。

結論

DOCSISケーブル ネットワークは適切な計画およびメンテナンスを必要とする洗練されたシステムです。 DOCSISケーブル システムのほとんどのパフォーマンス上の問題は適切な計画の直接実行された結果およびメンテナンスです。 いろいろなブロードバンド インターネット アクセス 代替の今日のインターネット アクセス 市場では、問題が、および従って著しく影響を受けるべきエンドユーザ用の十分に重要になる前にケーブルサービスプロバイダーがすぐにシステムのパフォーマンスまたは輻輳問題に考慮するブロードバンド アクセスの別 の 方法を対処することは重要です。


関連情報


Document ID: 12551