目录

简介

开始使用前

先决条件

使用的组件

准确确定已达到的性能水平

测量系统的正确部份

确定下载和上载速率

性能差的潜在原因

性能受到 DOCSIS 配置文件的限制

使用次最优方法进行速率限制

上行信道拥塞

下行信道拥塞

回程传输网或互联网拥塞

电缆设备上的噪声和错误

CMTS 中的高 CPU 使用率

动力不足或配置不正确的 CPE 设备

结论

相关信息

简介

存在许多问题，可能影响电缆传输数据服务接口数据规格(DOCSIS)系统中的有线调制解调器的性能和速度。本文寻求从有线服务提供商的角度讨论缓慢吞吐量的主要原因。

本文首先查看如何准确确定最终用户达到什么吞吐量级别，如何确定被测量的性能就是有线网络的性能，而不是覆盖更广泛的互联网的性能。

下一部分探讨造成性能低下的最常见潜在原因和推荐的解决方案。这些问题包括：

- DOCSIS 配置文件中的限制条件对性能造成限制。

- 在有线调制解调器终端系统（CMTS）上使用次佳速率限制机制，会引起突变性或无恒下载性能。

- 上行与下行信道拥塞。

- 回程网络或互联网拥塞。

- 电缆设备发出噪音或或出错。

- 终端用户客户端设备 (CPE) 功率不足。

这些个体或组合都能影响有线网络的吞吐量和性能。

本文不讨论有线网络或有线调制解调器不联机时连接完全损耗的故障排除问题。相反，有关这类问题请参阅对未联机的 uBR 电缆调制解调器进行故障排除。

开始使用前

先决条件

本文档没有任何特定的前提条件。

使用的组件

本文档中的信息基于以下软件和硬件版本。

- 适用于 uBR7200 和 uBR7100 CMTS 的 Cisco IOS® 软件版本 12.1(9)EC。

- CMTS 产品的 Cisco uBR7100、uBR7200 和 uBR7200VXR 套件。

- 本文信息与现在可以使用的其他所有基于DOCSIS 1.0的Cisco IOS软件（用于Cisco CMTS 设备）相关。

本文档中的信息都是基于特定实验室环境中的设备创建的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您是在真实网络上操作，请确保您在使用任何命令前已经了解其潜在影响。

准确确定已达到的性能水平

测量系统的正确部份

有许多方法可以测量系统的速度和性能，但准确了解测试的是系统的什么部件至关重要。请考虑以下图表。

图1(要以视频格式查看此图，请单击此处。)

此图表中有一系列组件：

- 最终用户与 CMTS 之间的混合光纤同轴网络。

- 将 CMTS 连接至有线服务提供商的网络的本地 CMTS 网段。

- 有线服务提供商的内部网络。

- 公用互联网。

在二点之间执行速度测试时，要测量二点之间的所有网络组件的速度。

例如，如果在CPE和服务器3之间执行速度测试，CPE和服务器3通过一条128Kbps ISDN线路连接到互联网，不会出现高于128 Kbps的速度，即使线缆分段的可用带宽的速率高于128 Kbps。

测量电缆分段性能的最准确方式是：在CPE和服务器1之间执行速度测试，CPE和服务器1连接到与CMTS相同的网段。这是因为需要传播数据的唯一路径是同轴电缆分段。数据传播还必须横跨本地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的上传和下载测试仅对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服务器。命令行 FTP 工具用于执行转移。几乎所有版本的 Microsoft Windows 和 UNIX 都提供此工具。

类似的测试是在服务提供商网络安装HTTP网络服务器和执行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上的测试进程，其中电缆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 命令的详细信息，请参阅思科宽带电缆命令参考指南。

性能差的潜在原因

性能受到 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千比特(64千字节)，那么后半秒内，有线调制解调器就不允许下载。这种速率限制行为可能影响突发式下载模式，这种模式似乎是每隔一秒钟或二秒钟就停止和开始一次。

可使用的最佳下行速率限制方案是速率限制令牌桶算法（配有流量整形）。速率限制机制以稳定的速率优化提供平稳的Web浏览体验，同时保证终端用户不超过DOCSIS配置文件规定的预设下载费率。

此机制的工作方式是：测量信息包每次发送到/发送出有线调制解调器时有线调制解调器下载或上载数据的速率。如果发送或收到所讨论的信息包造成调制解调器超出其允许的转发速率，信息包则在CMTS内存中缓冲或缓存，直到CMTS能够发送信息包而不会超出下行带宽限额。

注意：如果下行流量速率始终超过电缆调制解调器允许的下行速率，则数据包最终会被丢弃。

使用这种更平滑的方法，进行速率限制和整形，大多数基于TCP的互联网应用程序（如HTTP Web浏览和FTP文件传输）的运行要比使用默认速率限制机制更平滑更高效。

可以发出以下电缆接口配置命令， 在电缆接口的下行路径上启用令牌桶的流量整形速限（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

有关 cable downstream rate-limit 和 cable upstream rate-limit命令的详细信息，请参阅思科宽带电缆命令参考指南。

使用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 sid counters 命令的详细信息，请参阅思科宽带电缆命令参考指南。

上行信道拥塞

上行信道通常是电缆系统中最珍贵的资源。当前，多数有线服务提供商在上行路径中使用1.6兆赫的信道宽度和正交移相键控(QPSK)调制。这大约等于连接到一个上行信道的所有用户可用上行带宽的2.5 Mbps。重要的是确保上行信道不会过度使用或拥塞，否则该上行分段的所有用户将遭受低性能。

特定上行端口的上行使用情况可以通过执行 CMTS 命令 show interface cable X/Y upstream<z> 获取，其中 cable X/Y 是下行接口号，Z 是上行端口号。如果Z省略，将显示接口电缆X/Y上的所有上行信息。有关 show interface cable upstream 命令的详细信息，请参阅思科宽带电缆命令参考指南。

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 命令的详细信息，请参阅思科宽带电缆命令参考指南。

- 再次将上行数字式调制机制更改为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 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 是要观察的电缆接口。以比特/秒显示的输出速率应与上表中看到的可用下行带宽进行比较。

在以下示例中，分析了使用北美洲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版本进行自动调整。使用思科IOS软件版本12.1(8）EC的早期版本，必须使用cable interface命令带宽< bandwidth-in-kilo-bits-per-second >手工配置该值，否则保持默认值27000 Kbps。

附注的第二个组件是由txload 参数指示的传输负载。此参数指定了255的权值，其中0/255表示没有数据流在下行方向流入255/255，意味着下行数据传输速率为最大可能速率(在这种情况下，速率为27000 Kbps)。 如果此参数在高峰使用时间一直以大于大约75%的值来运行(例如，大于191/255)，最终用户将开始经历更缓慢的互联网接入和更高延迟。

附注的第三个组件是输出速率，该速率显示每秒的平均下行吞吐量比特速率。如果在峰值使用时间内，该数字一直超出可用下行带宽的75%，那么终端用户将遇到互联网访问速度减慢、延迟增加的情况。

默认情况下，计算五分钟移动平均值的统计信息。（关于如何计算平均值的详细信息，请参阅了解 show interfaces 命令输出中每秒位数 (bits/sec) 的定义。） 通过发出cable interface 命令load-interval 30，可将计算此平均值的时间段缩短至30秒。通过将此时间段缩短至30秒，可以为本节讨论的每个参数计算更准确的最新值。

下行信道在日间的使用做了更改，这样不同用户便有机会使用他们的有线调制解调器，因此在日间最繁忙时段（而不是低使用时段）监控下行的使用至关重要。

缓解下行拥塞的方式包括：

- 减少每条下行有线调制解调器的数量-如果有太多有线调制解调器连接到特定下行，或者如果特定下行的用户占用了大量的下行带宽，最佳解决方案就是将拥塞下行信道的一些用户转移到另一条下行信道。解决办法通常是：把与下行相关的下行光纤节点组分成两个独立的组，然后为每一个新组分配独立的下行信道。请参阅什么是每个 CMTS 的最大用户数。

- 将下行数字调制机制更改为256-QAM 。该操作需要对下行光谱进行严谨而详尽的分析，以验证系统是否支持256-QAM信号。如果此分析执行不正确，则可能存在性能进一步降低，或上行储运完全损耗的风险。下行调制方案可以通过发出 cable interface 命令更改，如下所示。

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

有关 cable downstream modulation 命令的详细信息，请参阅思科宽带电缆命令参考指南。

- 降低每个有线调制解调器允许的下行吞吐量---通过在适当DOCSIS配置文件中降低最大下行传输速率，有线调制解调器用户不能在下行方向执行高速率下载，因此解除了下行拥塞。此措施的负作用是有线调制解调器用户被限制到更缓慢的服务级别。请参阅使用Cisco DOCSIS配置器构建DOCSIS 1.0配置文件。

注意：本节中讨论的措施不会显着提高本已不拥塞的系统的性能。

回程传输网或互联网拥塞

在某些情况下，性能问题在电缆装置或CMTS上可能不是什么问题，然而可能与回程传输网中的拥塞或问题有关。在回程传输网中，CMTS用于连接到互联网，或者连接到互联网的内部部件。

确定回程传输网拥塞是否有问题的最简单的方法是：将工作站连接到与CMTS相同的网段，并设法浏览有线调制解调器后面的最终用户试图到达的相同网站。如果性能仍然缓慢，网络中的性能问题便与CMTS或电缆段无关。如果本地CMTS网段的性能明显高于用户连接到有线调制解调器的性能，重点则需要放在CMTS和电缆段上。

图 3

在上述网络中，如果服务器1，和CMTS一样连接到相同网段，浏览互联网时，服务器1的性能会下降，但问题根源不是CMTS。相反，其他地方存在瓶颈或性能问题。为了确定问题根源，在服务器1网络服务提供商(ISP) 网络和公共互联网内部的和各种其他服务器之间执行性能测试。

电缆设备上的噪声和错误

如果电缆系统中具有过多的噪音或入口，有线调制解调器和CMTS之间的信息包可能被损坏和丢失。这可能导致性能的显著下降。

除性能和吞吐量降低以外，某些指示器的噪音或射频（RF）问题包括：

- 电缆调制解调器间歇性脱机或陷于 init(r1) 或 init(r2) 状态中。

- show controller cable X/Y upstream Z 的输出显示预计的 SNR 较低，其中 cable X/Y 是要观察的电缆接口，Z 是要观察的上行端口。DOCSIS规范要求至少在25dB为所有上行信号提供载波噪声比(CNR) 。这相当于 SNR 约为 29 dB。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 命令的详细信息，请参阅思科宽带电缆命令参考指南。

- Corr转发错误(FEC)和Uncorr FEC错误迅速增加的号码显示在show cable hop命令输出中。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 命令的详细信息，请参阅思科宽带电缆命令参考指南。

- show cable flap-list 命令的输出中存在大量的“flap”事件。与可能射频或噪声问题密切相关的抖动统计数据是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命令的详细信息，请参阅思科宽带电缆命令参考指南。

注意：有关识别和解决RF噪音问题的详细信息，请参阅确定CMTS上的RF或配置问题和将Cisco uBR7200系列路由器连接到电缆头端。

CMTS 中的高 CPU 使用率

在某些情况下，由于次优配置、过度使用特定管理功能，或者CMTS路由的信息包数量非常大，思科CMTS有可能超过负荷。

确定Cisco CMTS的CPU使用的最佳方式是执行show process CPU命令。命令输出的第一行指示了当前CPU使用情况。

在第一行下面显示的输出线路中，运行CMTS的每一个进程与该进程所用的CPU部分一起显示。show process cpu output部分用于确定特定流程或功能是否是高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% 用于服务中断。第二张图通常等于用来路由信息包和通过CMTS交换机数据流的CPU部分。

如果在系统的峰值使用时间内，五分钟所占用的CPU容量一直超过80%，那么终端用户可能会遇到运行减慢、等待时间变长等情况。如果在峰值使用时间内，五分钟所用的CPU一直超过95% ，应采取紧急措施保证CMTS处于平稳状态。

降低 CMTS 的 CPU 使用率的常用策略包括：

- 升级到Cisco IOS软件版本12.1(9)EC或以后版本，激活global configuration命令ip cef，确定CMTS上没有接口配置no ip route-cache命令。这通常会导致与流量相关 CPU 使用率下降 10% 到 15%。请确保将所有这些步骤配合使用。

- 确保简单网络管理协议 (SNMP) 管理站不会过于积极地轮询 CMTS。这会导致 IP SNMP 进程中 CPU 使用率升高。

- 不连续多次运行 show tech 命令。这会人为导致虚拟 Exec 进程中 CPU 使用率升高。

- 确保 CMTS 上没有运行任何 debug 命令。

欲知思科路由器的高CPU使用（包括思科CMTS产品）的更多信息，参见思科路由器的故障排除高CPU利用率。

动力不足或配置不正确的 CPE 设备

在许多情况下，缓慢访问有线网络的原因是终端用户的CPE设备存在问题。如果只有一个或几个用户体验到缓慢的吞吐量，而其他用户群没有遇到这样的问题，则明显表示该用户环境内可能存在一个独特的问题。

- CPE 功率不足或过载 - 如果抱怨运行困难的最终用户使用的是过时的 CPE 设备或不足以运行其选定操作系统或互联网访问软件的设备，则该最终用户会遇到运行困难的问题。如果终端用户升级他们的CPE设备，这是唯一的解决方法。

- 防火墙或性能监测软件 - 如果最终用户正在运行任何防火墙、网络性能监测软件或其他类似软件，则一种很好的故障排除方法是让用户关闭此软件，看其对性能是否有任何影响。通常，此类软件可能会对性能产生不利影响。

- 错误配置 TCP/IP 设置 - 大多数服务提供商要求最终用户通过动态主机配置协议 (DHCP) 为其 CPE 设备获取 IP 地址、网络掩码、默认网关和 DNS 服务器。 请确认任何有问题的终端用户配置了他们的CPE设备，以使用DHCP，来获取所有这些参数。

如果最终用户声称没有以上所列的问题，则可以确定最终用户没有超过以上部分所述的最大下载或上载速率。

结论

DOCSIS 有线网络是一个复杂的系统，需进行适当的规划和维护。DOCSIS电缆系统中的大多数性能问题是没有执行适当规划和维护的直接结果。在当今的互联网接入市场上，具有有各种各样的宽带互联网接入方法选择。重要的是，在问题严重影响最终用户之前，有线服务提供商迅速解决他们的系统中的所有性能或拥塞问题，考虑宽带接入的备用方法。

相关信息

- 故障排除 UBR 电缆调制解调器不上线的问题

- 确定CMTS上的RF或配置问题

- 连接Cisco ubr7200系列路由器到电缆头端

- 对 Cisco 路由器上的 CPU 使用率过高进行故障排除

- 技术支持和文档 - Cisco Systems