對纜線資料機網路中的效能緩慢進行排解疑難
目錄
簡介
有許多問題可能會影響有線電纜資料服務介面規範(DOCSIS)系統中纜線資料機的效能和速度。本文試圖從有線服務提供商的角度解決吞吐量緩慢的主要原因。
本文檔首先介紹如何準確地確定終端使用者正在達到的吞吐量級別型別，以及如何確保所測量的效能是有線網路的效能，而不是更廣闊的網際網路的效能。
下一節將介紹效能低下的最常見潛在原因和建議的解決方案。這些問題包括：
-
效能受DOCSIS配置檔案中的限制限制。
-
在纜線資料機終端系統(CMTS)上使用次最佳速率限制方案所引起的突發或不穩定的下載效能。
-
上行和下行通道擁塞。
-
回傳網路或網際網路擁塞。
-
電纜裝置上的噪音或錯誤。
-
在供電終端使用者現場裝置(CPE)下。
其中每個單獨或組合都會影響電纜網路的吞吐量和效能。
本文不討論對電纜網路完全失去連線或電纜數據機無法聯機進行故障排除的問題。有關此類問題，請參閱排除uBR纜線資料機無法聯機故障。
開始之前
必要條件
本文件沒有特定先決條件。
採用元件
本檔案中的資訊是根據以下軟體和硬體版本。
-
適用於uBR7200和uBR7100 CMTS的Cisco IOS®軟體版本12.1(9)EC。
-
Cisco uBR7100、uBR7200和uBR7200VXR的CMTS產品套件。
-
本文檔中的資訊與適用於Cisco品牌CMTS裝置的基於DOCSIS 1.0的所有其他當前可用版本Cisco IOS軟體相關。
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您在即時網路中工作，請確保在使用任何命令之前瞭解其潛在影響。
準確確定達到的效能水準
測量系統的正確部件
評估系統的速度和效能的方法有很多，但準確瞭解系統哪些部分正在測試非常重要。請看下圖。
圖1(要以影片格式檢視此圖，請單擊此處。)
在此圖中有許多元件：
-
終端使用者和CMTS之間的混合光纖同軸網路。
-
CMTS連線到有線服務提供商網路的本地CMTS網段。
-
電纜服務提供商的內部網路。
-
公共網際網路。
當在兩個點之間執行速度測試時，測量兩個點之間所有網路元件的速度。
例如，如果在CPE和伺服器3（通過128 Kbps ISDN線路連線到網際網路）之間執行速度測試，即使纜線段上的可用頻寬大於128 Kbps，速度也絕不會超過128 Kbps。
測量電纜段本身效能的最準確的方法是在CPE和伺服器1（它與CMTS連線到同一網段）之間執行速度測試。這是因為資料需要經過的唯一路徑是同軸電纜段。資料還必須通過本地CMTS網段傳輸，但假定此網段具有高頻寬（FastEthernet或更高），並且沒有嚴重的擁塞。
如果由於某種原因，沒有伺服器可以連線到本地CMTS網段，則測試電纜段效能的下一個最準確的方法是在CPE和伺服器2之間執行速度測試。這是一個精確的測量，只要在CMTS和CPE之間的電纜服務提供商的內部網路中有足夠高的速度和未擁塞的鏈路。
確定電纜段效能的最不準確的方法是在CPE和公共Internet上的伺服器之間執行速度測試。這是因為CPE和伺服器之間的公共Internet中可能存在擁塞的鏈路，或者CPE和Internet上的伺服器之間的路徑中可能存在非常低速的鏈路。
確定下載和上傳速率
在對DOCSIS系統中是否存在效能問題得出任何結論之前，能夠客觀地衡量所達到的上載和下載吞吐量級別非常重要。
確定上傳和下載速度的最簡單方法是在連線到電纜數據機的CPE裝置與CMTS後面的伺服器之間使用FTP或HTTP上載或下載大型檔案。大多數FTP和HTTP客戶端都能夠顯示傳輸期間或傳輸完成後下載或上載的速度。由於FTP或HTTP操作而導致的傳輸速度通常約為實際總吞吐量的90%。這是因為顯示的FTP或HTTP傳輸速度沒有考慮在CPE裝置和CMTS之間傳輸所需的額外IP和DOCSIS開銷。
有更精確的測量輸送量的方法，例如使用第三方專用測試裝置，例如網通Smartbits或IXIA封包生成器，但這些系統並不總是容易獲得或連線到生產電纜網路。值得注意的是，如果在實驗室環境中執行吞吐量測試，則使用專用裝置將會顯示比簡單的FTP或HTTP下載測試更多的資訊。
注意：基於FTP或HTTP的上傳和下載測試僅可用於測試3 Mbps或更低的速度。在更高的速度下，CPE裝置、伺服器或網路介面卡(NIC)的處理能力可能成為測試中的限制因素。對於高於3 Mbps的測試速度，應使用專用的資料吞吐量測試裝置。
在以下範例中，將在連線到纜線資料機的CPE裝置與纜線服務供應商網路上的FTP伺服器之間執行簡單的FTP下載和上傳測試。纜線資料機已下載一個DOCSIS組態檔，允許下載速度最高為256 Kbps，且上傳速度最高為64 Kbps。在此測試中，已將一個3 Mb的檔案放在IP地址為172.17.110.132的FTP伺服器上。CPE裝置的使用者將獲得使用者名稱和密碼，以便能夠登入到FTP伺服器，以便他們能夠從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(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 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.
在秒錶或時間讀數正好為一分鐘後，發出show interface cable X/Y sid Z counters命令。最好先鍵入命令，然後在計時器指示一分鐘時準確按Enter鍵。該測試可在較長或較短的時段內執行。測試週期越長，結果就越準確，但是，請確保下載或上載沒有在秒錶計時器達到指定時間之前完成，否則測量不準確。
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,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命令檢視上傳速度，應使用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
此處顯示此纜線資料機的服務品質(QoS)設定檔為5。若要瞭解此QoS設定檔對應的下游和上游速率，請使用show cable qos profile profile-number 指令，其中profile-number 是所關注的QoS設定檔。
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配置器構建DOCSIS 1.0配置檔案的文檔。
使用次優方法限制速率
當終端使用者嘗試以超過其有線數據機的DOCSIS配置檔案允許的速率從網際網路下載資料時，CMTS必須速率限制傳送到該使用者的流量，以確保使用者使用的頻寬不超過其允許的頻寬份額。
同樣，當終端使用者嘗試以大於DOCSIS配置檔案允許的速率將資料上傳或傳送到網際網路時，纜線資料機本身應停止多餘的流量通過纜線分段傳送到CMTS。如果纜線資料機由於某種原因未能正確執行上游速率限制，則CMTS明確禁止纜線資料機傳送高於允許速率的資料。CMTS上的這種行為是為了確保即使是「被駭客攻擊」特徵的纜線資料機，也不能破壞服務提供商指定的上傳速率限制。
CMTS使用的預設速率限制方案會監控每過一秒時間內進出每個纜線資料機的流量速率。如果纜線資料機在不到一秒內傳送或接收超過其每秒鐘配額，則CMTS不會允許任何其他流量在第二秒的其餘時間內流向該纜線資料機。
例如，以具有QoS配置檔案的電纜數據機為例，該配置允許下載速率為512 Kbps。如果纜線資料機在前半秒內下載512 KB(64 KB)，則在後半秒內，纜線資料機不允許下載任何內容。這種速率限制行為可能造成突發下載模式，該模式似乎每隔一兩秒就會停止並啟動。
使用的最佳下游速率限制方案是具有流量調整的令牌桶速率限制演算法。此速率限制方案已經過最佳化，以便以穩定的速率提供流暢的Web瀏覽體驗，同時確保不允許終端使用者超過DOCSIS配置檔案中指定的規定下載速率。
此方案的工作方式是測量每次將封包傳送到纜線資料機或從纜線資料機上傳資料時的纜線資料機下載或上傳資料速率。如果傳送或接收有問題的資料包導致數據機超過其允許的傳輸速率，則該資料包在CMTS記憶體中緩衝或快取，直到CMTS可以傳送資料包而不超過下游頻寬限制。
註：如果下行流量速率始終超過電纜數據機允許的下行速率，則最終會丟棄資料包。
通過使用這種更平滑的速率限制和整形方法，大多數基於TCP的Internet應用程式（如HTTP Web瀏覽和FTP檔案傳輸）比使用預設速率限制方案時更順暢和高效地運行。
可通過發出以下電纜介面配置命令，在電纜介面上的下游路徑上啟用令牌桶速率限制 — 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
有關cable downstream rate-limit和cable upstream 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
Raterlimit 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 sid counters 命令的詳細資訊，請參閱Cisco寬頻電纜命令參考指南。
上行通道擁塞
上行通道通常是電纜系統中最寶貴的資源。目前，大多數有線服務提供商在上游路徑上使用1.6 MHz通道寬度和正交相移鍵控(QPSK)調制。這相當於連線到一個上行通道的所有使用者可用的上行頻寬總量約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命令參考指南。
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%，則終端使用者會遇到極差的服務級別，因為終端使用者的絕大部分上游資料將被延遲或丟棄。
上行通道使用量在一天中會發生變化，因為不同的使用者有機會使用他們的電纜數據機，因此在一天中最繁忙的時段監控上行通道使用量非常重要，而不是在使用時間很短的時段。
緩解上游擁塞的方法包括：
-
減少每個上游的纜線資料機數量 — 如果連線到特定上游的纜線資料機過多，或者如果特定上游的使用者是上游頻寬的大量使用者，則最佳解決方案是將擁塞上游埠上的某些使用者移動到未使用的上游埠，或移動到全新的上游埠。這通常通過將光纖節點從一個上游組合組移動到另一個上游組合組，或將上游組合組分割成兩個單獨的組合組來完成。如需詳細資訊，請參閱每個CMTS的最大使用者數量是多少。
-
增加上行通道寬度 — 這涉及對上行頻譜進行嚴格和全面的分析，以找到具有足夠的訊雜比(SNR)特徵的足夠寬的頻帶，以支援增加的通道寬度。在沒有仔細規劃的情況下，不應更改上游通道寬度，因為這種更改可能會影響使用者電纜系統中的其他服務。可以使用cable interface命令cable upstream Z channel-width <new-channel-width> (其中Z是上游埠號，新通道寬度是200000、400000、800000、1600000（預設值）或3200000之一)來更改上游通道寬度。以下為示例。
uBR7246-VXR(config-if)# cable upstream 0 channel-width 3200000
有關show interface cable upstream命令的詳細資訊，請參閱Cisco Broadband Cable命令參考指南。
-
將上行數字調制方案改為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 命令的詳細資訊，請參閱思科寬頻電纜命令參考指南。另請參閱在思科電纜數據機終端系統上配置電纜調制配置檔案。
-
降低每個纜線資料機所允許的上游輸送量 — 通過降低適當DOCSIS組態檔中的最大上游傳輸速率，纜線資料機使用者無法在上游方向以最高的速率傳輸，且上游擁塞得以緩解。本操作過程的負面影響是電纜數據機使用者只能享受較慢的服務級別。請參閱使用Cisco DOCSIS配置器構建DOCSIS 1.0配置檔案。
註：本節中討論的措施不會顯著提高已不擁塞系統的效能。
下游通道擁塞
下行通道與單個上行通道相比要共用的頻寬明顯更多，因此下行通常不像上行通道那樣容易發生擁塞。儘管如此，共用下游通道的使用者通常多於任何單個上游通道，因此，如果下游通道變得擁塞，連線到下游段的所有使用者將體驗到效能降低。
下表顯示了與DOCSIS系統中可用的四種可能下行調制方案相關的總可用下行頻寬情況。
| 下游調制方案 | 可用下游頻寬 |
|---|---|
| 64-QAM北美DOCSIS | 27 Mbps |
| 256-QAM北美DOCSIS | 38 Mbps |
| 64-QAM歐洲DOCSIS | 38 Mbps |
| 256-QAM歐洲DOCSIS | 54 Mbps |
大多數DOCSIS纜線系統目前部署64-QAM北美DOCSIS，因此每個下游通道具有27 Mbps的可用速度。
可通過發出show interface cable X/Y命令來確定下游通道的使用情況，其中cable X/Y是觀察到的電纜介面。所顯示的輸出速率（以位/秒為單位）應與上表所示的可用下行頻寬進行比較。
在以下示例中，分析了使用北美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 <bandwidth-in-kilo-bits-per-second>手動設定此值，否則此值會保留為預設值27000 Kbps。
要注意的第二個分量是txload引數所指示的傳輸負載。此引數提供255中的一個度量，其中0/255表示沒有流量在下游方向流到255/255，這表示資料在下游以最大可能速率(在此情況下為27000 Kbps)傳輸。 如果此引數在使用高峰期（例如，大於191/255）始終以大約75%的速度運行，則終端使用者會開始遇到更慢的Internet訪問速度和更高的延遲。
要注意的第三個元件是輸出速率，它顯示平均下游吞吐率（以位/秒為單位）。如果這一數字在峰值使用時間始終超過可用下行頻寬的約75%，則終端使用者會開始遇到網際網路訪問速度較慢和延遲較高的情況。
預設情況下，這些統計資訊是通過五分鐘移動平均值計算的。(有關如何計算平均值的詳細資訊，請參閱從show interfaces命令輸出瞭解每秒位數的定義（位/秒）。) 通過發出cable interface命令load-interval 30可將此平均值計算的時段縮短至30秒。通過將此時段縮短至30秒，可針對本節中討論的每個引數計算更準確的最新值。
由於不同的使用者有機會使用他們的電纜數據機，因此在一天中最繁忙的時段監控下行使用非常重要，而不是在使用時間較短的時段。
緩解下游擁塞的方法包括：
-
減少每個下游的電纜資料機數量 — 如果連線到特定下游的電纜資料機過多，或如果特定下游的使用者是大量使用下游頻寬的使用者，則最佳解決方案是將擁塞的下游通道上的某些使用者移動到另一個下游通道。這通常通過將一組與下游相關的下游光纖節點分成兩個獨立的組並將每個新組分配分開的下游通道來實現。請參閱每個CMTS的最大使用者數量是多少。
-
將下游數字調制方案更改為256-QAM — 此操作需要對下游頻譜進行嚴格而全面的分析，以驗證系統是否支援256-QAM信號。如果此分析未正確執行，則存在效能進一步降低或可能發生完全下游故障的風險。通過發出cable interface命令可以更改下游調制方案，如下所示。
uBR7246-VXR(config-if)# cable downstream modulation 256qam
請參閱Cisco寬頻電纜命令參考指南瞭解有關電纜下游調制命令的詳細資訊。
-
降低每個纜線資料機所允許的下游輸送量 — 透過降低適當DOCSIS組態檔中的最大下游傳輸速率，纜線資料機使用者無法在下游方向上以高速率下載，且下游擁塞得以緩解。本操作過程的負面影響是電纜數據機使用者只能享受較慢的服務級別。請參閱使用Cisco DOCSIS配置器構建DOCSIS 1.0配置檔案。
註：本節中討論的措施不會顯著提高已不擁塞系統的效能。
回傳網路或網際網路擁塞
在某些情況下，效能問題可能不是電纜裝置或CMTS上的問題導致的，而可能是CMTS用於連線到Internet的回程網路中的擁塞或問題，或者是Internet本身的一部分中的問題。
判斷回傳網路擁塞是否構成問題的最簡單方法是將工作站連線到與CMTS相同的網段，並嘗試與纜線資料機之後的最終使用者嘗試連線相同的網站。如果效能仍然很慢，則表示網路中存在與CMTS或電纜段無關的效能問題。如果本地CMTS網段的效能明顯優於連線到電纜數據機的使用者，則應將工作重點重新放在CMTS和電纜網段上。
圖 3
在上述網路中，如果伺服器1（與CMTS連線到同一網段）在瀏覽Internet時效能較慢，則問題的來源不是CMTS。相反，瓶頸或效能問題發生在其他地方。為了確定問題所在，在伺服器1與網際網路服務提供商(ISP)網路和公共Internet內的各種其他伺服器之間執行效能測試。
電纜裝置上的噪音和錯誤
如果纜線系統中存在過多的噪音或輸入，則纜線資料機和CMTS之間的封包可能會損毀和遺失。這可能導致效能顯著下降。
除了效能和吞吐量下降外，雜訊或射頻(RF)問題的一些主要指標包括：
-
纜線資料機偶爾離線或停滯在init(r1)或init(r2)狀態。
-
在show controller cable X/Y upstream Z的輸出中可看到低估計的SNR，其中cable X/Y是所觀察的電纜介面，Z是所觀察的上游埠。DOCSIS規範要求所有上行訊號的載波雜訊比(CNR)至少為25 dB。這相當於SNR大約29dB。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 命令的詳細資訊，請參閱思科寬頻電纜命令參考指南。
-
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命令參考指南。
-
show cable flap-list命令輸出中的許多「flap」事件。與可能的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 Broadband纜線命令參考指南。
注意：有關識別和解決RF噪音問題的更多詳細資訊，請參閱確定CMTS上的RF或配置問題和將Cisco uBR7200系列路由器連線到電纜頭端。
CMTS上的CPU使用率高
在某些情況下，Cisco CMTS可能會因為配置不佳、過度使用某些管理功能或CMTS路由大量資料包而超載。
確定Cisco CMTS的CPU使用率的最佳方法是執行show process cpu命令。當前CPU使用率顯示在命令輸出的第一行中。
在第一行下面的輸出行中，顯示在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%。此外，21%的CPU用於服務中斷。第二張圖通常等於CPU中用於通過CMTS路由資料包和交換流量的部分。
如果在系統的高峰使用時間內，五分鐘的CPU使用率始終超過80%，則終端使用者可能會開始遇到效能降低和延遲增加的情況。如果在峰值使用時間的5分鐘CPU使用率始終超過95%，則採取緊急措施以確保CMTS保持穩定狀態。
用於減少CMTS上高CPU使用率的常見策略包括：
-
升級到Cisco IOS軟體版本12.1(9)EC或更高版本，啟用全域性配置命令ip cef，並確保CMTS上的任何介面均未配置命令no ip route-cache。這通常會導致與流量相關的CPU使用率降低10%到15%。確保所有這些步驟都同時執行。
-
確保簡單網路管理通訊協定(SNMP)管理站不會在輪詢CMTS時過於積極。這會導致IP SNMP進程中的CPU使用率高。
-
未連續多次運行show tech命令。這會導致虛擬Exec進程中的CPU使用率過高。
-
確保CMTS上未運行任何debug命令。
有關Cisco路由器（包括Cisco CMTS產品）上的CPU使用率較高的詳細資訊，請參閱排除Cisco路由器上的CPU使用率過高。
在通電或配置錯誤的CPE裝置下
在許多情況下，電纜網路接入緩慢的原因都是終端使用者CPE裝置的問題。如果只有一個或少數使用者正經歷吞吐量緩慢，而其餘使用者群沒有遇到問題，則這強烈表明該使用者的環境中可能存在唯一的問題。
-
在供電或超載CPE下 — 如果抱怨有困難的終端使用者使用過時的CPE裝置，或者裝置不夠強大，無法運行他們選擇的作業系統或Internet訪問軟體，則此終端使用者將遇到困難。在這種情況下，唯一解決方法是終端使用者升級其CPE裝置。
-
防火牆或效能測量軟件 — 如果終端使用者正在運行任何防火牆、網路效能測量或其他類似軟體，一個好的故障排除步驟是讓使用者關閉此軟體，看它是否對效能有任何影響。通常，這些型別的軟體會對效能產生負面影響。
-
TCP/IP設定配置錯誤 — 大多數服務提供商要求終端使用者讓其CPE裝置通過動態主機配置協定(DHCP)獲取IP地址、網路掩碼、預設網關和DNS伺服器。 確保任何遇到問題的終端使用者都將其的CPE裝置配置為使用DHCP獲取所有這些引數。
如果終端使用者聲稱沒有出現上述任何問題，請確認終端使用者沒有超出上述部分規定的最大下載或上傳速率。
結論
DOCSIS有線網路是一種需要正確規劃和維護的複雜系統。DOCSIS纜線系統中的大多數效能問題都是未執行正確規劃和維護的直接結果。在當今的網際網路接入市場中，有多種寬頻網際網路接入方案，因此電纜服務提供商必須快速解決其系統中的任何效能或擁塞問題，以免問題變得嚴重到使終端使用者受到顯著影響，從而考慮寬頻接入的替代方法。
意見