Resolución de problemas en redes de cablemódem de rendimiento lento

Introducción

Existen varios problemas que pueden afectar el rendimiento y la velocidad de cablemódems en un sistema de Data-over-Cable Service Interface Specifications (DOCSIS). Este documento intenta identificar las causas principales del bajo rendimiento desde la perspectiva de un proveedor de servicio de cable.

Este documento primero analiza cómo determinar con precisión qué tipos de niveles de rendimiento está alcanzando un usuario final y cómo asegurarse de que el rendimiento que se mide es el de la red por cable, en lugar de el de Internet en general.

La siguiente sección describe las posibles razones más comunes del bajo rendimiento y resoluciones sugeridas. Estos problemas incluyen:

• El rendimiento está restringido por los límites del archivo de configuración de DOCSIS.

• Rendimiento de descarga irregular o irregular causado por el uso de un esquema de limitación de velocidad por debajo del nivel óptimo en el sistema de terminación de cablemódem (CMTS).

• Congestión de canal ascendente y descendente.

• Congestión de Internet o de la red de retroceso.

• Ruido o errores en el cableado.

• En Equipo en las instalaciones del cliente (CPE) del usuario final con alimentación.

Cada una de estas opciones, individualmente o en combinación, puede afectar al rendimiento y al rendimiento de una red por cable.

Este documento no trata la resolución de problemas de pérdida completa de conectividad en la red de cable o los cablemódems que no se conectan. En su lugar, consulte Resolución de problemas de los cablemódems uBR que no se conectan para este tipo de problemas.

Antes de comenzar

Prerequisites

No hay requisitos previos específicos para este documento.

Componentes Utilizados

La información que contiene este documento se basa en las versiones de software y hardware indicadas a continuación.

• Software Cisco IOS® versión 12.1(9)EC para el CMTS uBR7200 y uBR7100.

• El conjunto de productos CMTS uBR7100, uBR7200 y uBR7200VXR de Cisco.

• La información de este documento es relevante para todas las otras versiones actualmente disponibles del software Cisco IOS basado en DOCSIS 1.0 para el equipo CMTS de la marca Cisco.

La información que se presenta en este documento se originó a partir de dispositivos dentro de un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si la red está funcionando, asegúrese de haber comprendido el impacto que puede tener un comando antes de ejecutarlo.

Determinación precisa de los niveles de rendimiento que se obtienen

Medición de las partes correctas del sistema

Existen varios métodos para estimar la velocidad y el rendimiento de un sistema; sin embargo, es importante comprender exactamente qué partes del sistema se comprueban. Considere el siguiente diagrama.

Figura 1 (Para ver este diagrama en formato de vídeo, haga clic aquí.)

En este diagrama se muestran varios componentes:

• La red híbrida coaxial de fibra entre el usuario final y el CMTS.

• El segmento de red CMTS local donde el CMTS se conecta a la red del proveedor de servicios de cable.

• La red interna del proveedor de servicios de cable.

• Internet público.

Al realizar una prueba de velocidad entre dos puntos, se mide la velocidad de todos los componentes de la red entre los dos puntos.

Por ejemplo, si se realiza una prueba de velocidad entre el CPE y el servidor 3, que está conectado a Internet a través de una línea ISDN de 128 Kbps, nunca habrá velocidades superiores a 128 Kbps, incluso si el ancho de banda disponible en el segmento de cable es superior a 128 Kbps.

La manera más precisa de medir el rendimiento del segmento de cable en sí es realizar una prueba de velocidad entre el CPE y el Servidor 1, que está conectado al mismo segmento de red que el CMTS. Esto se debe a que la única ruta por la que deben viajar los datos es el segmento de cable coaxial. Los datos también deben viajar a través del segmento de red CMTS local, pero se presume que este segmento es de un ancho de banda alto (FastEthernet o superior) y no tiene un alto nivel de congestión.

Si por alguna razón, no se puede conectar ningún servidor al segmento de red CMTS local, la siguiente manera más precisa de probar el rendimiento del segmento de cable es realizar una prueba de velocidad entre el CPE y el Servidor 2. Esta es una medición precisa siempre que haya enlaces de alta velocidad y no congestionados adecuados dentro de la red interna del proveedor de servicios de cable entre el CMTS y el CPE.

La forma más imprecisa de determinar el rendimiento del segmento de cable es realizar una prueba de velocidad entre el CPE y un servidor en la Internet pública. Esto es así debido a que puede haber links congestionados en Internet pública entre el CPE y el servidor, o puede haber links de muy baja velocidad en el trayecto entre el CPE y el servidor en Internet.

Determinación de la velocidad de carga y descarga

Es muy importante obtener una medida objetiva de los niveles exactos de rendimiento que se alcanzan para la carga y descarga antes de poder sacar cualquier conclusión sobre si existe o no un problema de rendimiento en un sistema DOCSIS.

La forma más sencilla de determinar la velocidad a la que se producen las cargas y descargas es cargar o descargar un archivo de gran tamaño mediante FTP o HTTP entre un dispositivo CPE conectado a un cable módem y un servidor detrás del CMTS. La mayoría de los clientes FTP y HTTP pueden mostrar la velocidad a la que se produce una descarga o una carga durante la transferencia o una vez que se ha completado la transferencia. La velocidad de transferencia observada como resultado de la operación FTP o HTTP suele ser aproximadamente el 90% del rendimiento total real obtenido. Esto se debe a que la velocidad de transferencia FTP o HTTP mostrada no tiene en cuenta la sobrecarga adicional de IP y DOCSIS que debe viajar entre el dispositivo CPE y el CMTS.

Existen métodos más precisos para medir el rendimiento, por ejemplo, mediante el uso de equipos de prueba dedicados de terceros, como un Netcom Smartbits o un generador de paquetes IXIA; sin embargo, estos sistemas no siempre están disponibles o se conectan fácilmente a una red de cable de producción. Vale la pena señalar que si las pruebas de rendimiento se llevan a cabo en un entorno de laboratorio, el uso de un dispositivo dedicado revelará mucha más información que la simple prueba de descarga FTP o HTTP.

Nota: La prueba de carga y descarga basada en FTP o HTTP solo es fiable para probar velocidades de alrededor de 3 Mbps o menos. A velocidades más altas, la potencia de procesamiento del dispositivo CPE, el servidor o las tarjetas de interfaz de red (NIC) puede convertirse en un factor limitante de la prueba. Para velocidades de prueba superiores a unos 3 Mbps, se debe utilizar un equipo de prueba de rendimiento de datos dedicado.

En el siguiente ejemplo, se realiza una prueba simple de carga y descarga por FTP entre un dispositivo CPE conectado a un cable módem y un servidor FTP en la red del proveedor de servicios por cable. El cable módem ha descargado un archivo de configuración DOCSIS que permite una velocidad de descarga de hasta 256 Kbps y una velocidad de carga de hasta 64 Kbps. En esta prueba, se ha colocado un archivo de 3 Mb en el servidor FTP en la dirección IP 172.17.110.132. Se asigna un nombre de usuario y una contraseña al usuario del dispositivo CPE para que pueda iniciar sesión en el servidor FTP y descargar este archivo desde el servidor FTP y, a continuación, cargarlo de nuevo en el servidor FTP. La utilidad FTP de línea de comando se utiliza para realizar la transferencia. Esta utilidad está disponible en prácticamente todas las versiones de Microsoft Windows y UNIX.

Una prueba similar se lleva a cabo mediante la configuración de un servidor web HTTP en la red del proveedor de servicios y la realización de una descarga HTTP.

Figure 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.

Mientras se produce la transferencia FTP, es posible monitorear el progreso de la prueba en el CMTS usando el comando show interface cable X/Y sid Z counters donde cable X/Y es la interfaz de cable a la que está conectado el módem bajo la prueba, y Z es el número de ID de servicio (SID) del módem bajo la prueba. Este comando muestra cómo se transfieren muchos bytes desde o hacia un cablemódem particular. Por ejemplo, si el CPE que se está probando está detrás de un cablemódem con la dirección MAC 0001.9659.4461.

En primer lugar, busque el número SID del módem que se está probando mediante el comando show cable modem. En este caso, la SID del cable módem es 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

Mientras la descarga o la carga progresa, borre todos los contadores de paquetes en el CMTS de nuevo a cero usando el comando clear counters. Exactamente cuando se borren los contadores, inicie un cronómetro o un temporizador.

uBR7246-VXR# clear counters              


!--- Reset packet counter to zero.

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


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

Después de que el cronómetro o el tiempo se lean exactamente un minuto, ejecute el comando show interface cable X/Y sid Z counters. Puede ser mejor escribir el comando primero y luego presionar Enter exactamente cuando el temporizador indica un minuto. La prueba puede realizarse durante un período más largo o más corto. Cuanto más largo sea el período de prueba, más preciso será el resultado; no obstante, asegúrese de que la descarga o la carga no finalizan antes de que el temporizador del cronómetro alcance el tiempo especificado; de lo contrario, la medición no será precisa.

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# 

En este caso, se está probando la velocidad de descarga. La salida del comando show interface cable X/Y sid Z counter indica que, durante un período de un minuto, el cablemódem descarga 1.921.488 bytes. La conversión de 1.921.488 bytes en bits revela lo siguiente:

8 bits per byte * 1,921,488 bytes = 15,371,904 bits.

Luego, para encontrar la velocidad de descarga en bits por segundo, divida este número total de bits descargados por el tiempo que toma descargarlos en segundos.

15,371,904 bits / 60 seconds = 256 Kbps.

La velocidad de descarga de este ejemplo es de aproximadamente 256 Kbps, que resulta ser la velocidad de descarga permitida para el cable módem sometido a la prueba.

Para observar la velocidad de carga mediante el comando show interface cable X/Y sid Z counters, se debe utilizar la columna Inoctets para determinar el número de bytes enviados en la dirección ascendente desde el cablemódem.

Vea la Guía de Referencia de Comandos de Cable de Banda Ancha de Cisco para obtener más información sobre el comando show interface cable sid counters.

Razones posibles de un rendimiento pobre

Rendimiento restringido por el archivo de configuración de DOCSIS

La primera información que se debe recopilar al solucionar problemas de rendimiento lento del cable módem es la clase prescrita de limitaciones de rendimiento del servicio del cable módem. Cuando un cable módem se conecta, descarga un archivo de configuración DOCSIS que contiene límites operativos para el cable módem, incluidas las velocidades máximas de carga y descarga. En circunstancias normales, no se permite que el módem de cable exceda estas velocidades.

Inicialmente es necesario identificar la dirección MAC de un cable módem que tiene problemas. Tomando un módem con la dirección MAC 0050.7366.2223 que tiene problemas con el rendimiento lento,. es necesario averiguar qué clase de perfil de servicio está utilizando este cable módem mediante la ejecución del comando show cable modem <mac-address>, como se muestra en el siguiente ejemplo.

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

Aquí se muestra que este cablemódem tiene un perfil de Calidad de servicio (QoS) de 5. Para averiguar a qué velocidades de flujo descendente y ascendente corresponde este perfil de QoS, utilice el comando show cable qos profile profile-number, donde profile-number es el perfil de QoS de interés.

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

Aquí se muestra que el perfil de QoS 5 corresponde a un servicio que proporciona 256 Kbps en el flujo descendente y 64 Kbps en el flujo ascendente. Ningún CPE conectado a los cable módems que utilizan el perfil de QoS 5 puede exceder estos límites. La configuración del perfil de QoS está determinada por el contenido de los archivos de configuración de DOCSIS descargados por los cablemódems del servidor TFTP del sistema de aprovisionamiento, por lo tanto, el perfil de QoS 5 en el sistema puede no ser el mismo que el perfil de QoS 5 en el ejemplo anterior.

Si el rendimiento de carga y descarga de un usuario final se correlaciona con los límites mostrados en su perfil de QoS, obtendrá la clase de servicio y los niveles de rendimiento para los que se ha aprovisionado y configurado el cable módem. La única manera de aumentar el rendimiento de carga y descarga es cambiar el archivo de configuración DOCSIS que descarga el cable módem a uno que tenga límites de rendimiento más altos. Consulte el documento titulado Creación de archivos de configuración de DOCSIS 1.0 mediante Cisco DOCSIS Configurator para obtener instrucciones detalladas sobre cómo crear o modificar un archivo de configuración de DOCSIS.

Uso de un método subóptimo para la limitación de velocidad

Cuando un usuario final intenta descargar datos de Internet a una velocidad mayor que la permitida por el archivo de configuración DOCSIS de su cable módem, el CMTS debe limitar la velocidad del tráfico que se envía a ese usuario para asegurarse de que el usuario no consume más de su cuota de ancho de banda permitida.

De manera similar, cuando un usuario final intenta cargar o enviar datos a Internet a una velocidad mayor que la permitida por el archivo de configuración DOCSIS, el cablemódem en sí mismo debe evitar que el exceso de tráfico viaje a través del segmento de cable al CMTS. Si el cablemódem, por alguna razón, no puede realizar correctamente la limitación de velocidad ascendente, el CMTS explícitamente prohíbe que el cablemódem transmita a una velocidad mayor que la permitida. Este comportamiento en el CMTS es para garantizar que incluso un cablemódem con características "hackeadas" no pueda subvertir los límites de velocidad de carga asignados por el proveedor de servicios.

El esquema de límite de velocidad predeterminado utilizado por el CMTS monitorea la velocidad del tráfico hacia o desde cada cablemódem en cada período de un segundo. Si el cablemódem envía o recibe más de su cuota por segundo en menos de un segundo, el CMTS no permite que más tráfico fluya a ese cablemódem por el resto del segundo.

Por ejemplo, puede utilizar un cable módem con un perfil de QoS que permita una velocidad de descarga de 512 Kbps. Si el cable módem descarga 512 kilobits (64 kilobytes) en la primera mitad de un segundo, el cable módem no podrá descargar nada durante la siguiente mitad del segundo. Este tipo de comportamiento de limitación de la velocidad puede resultar en un patrón de descarga intermitente que parece detenerse e iniciarse cada uno o dos segundos.

El mejor esquema de limitación de velocidad descendente que se puede usar es el algoritmo de limitación de velocidad token bucket con modelado de tráfico. Este esquema de limitación de velocidad se ha optimizado para permitir una experiencia de navegación web fluida a una velocidad constante, al mismo tiempo que se garantiza que los usuarios finales no puedan superar la velocidad de descarga prescrita según se especifica en el archivo de configuración DOCSIS.

La forma en que funciona este esquema consiste en medir la velocidad a la que un cablemódem descarga o carga datos cada vez que se envía un paquete hacia o desde el cablemódem. Si enviar o recibir el paquete en cuestión hace que el módem exceda sus velocidades de transferencia permitidas, entonces el paquete se almacena en memoria intermedia o en caché en la memoria CMTS hasta que el CMTS pueda enviar el paquete sin exceder el límite de ancho de banda de flujo descendente.

Nota: Si la velocidad de tráfico descendente supera constantemente la velocidad descendente permitida para el cable módem, los paquetes se descartan finalmente.

Al utilizar este método más sencillo de limitación y modelado de velocidad, la mayoría de las aplicaciones de Internet basadas en TCP, como la navegación web HTTP y las transferencias de archivos FTP, funcionan de forma más fluida y eficaz que cuando se utiliza el esquema de limitación de velocidad predeterminado.

El esquema de limitación de velocidad con modelado de tráfico de token-bucket se puede habilitar en la trayectoria descendente en una interfaz de cable mediante la ejecución del siguiente comando de configuración de la interfaz de cable:

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

Nota: Se recomienda habilitar el modelado de token-bucket en el CMTS del usuario. Este comando es compatible con las versiones 12.0(5)T1 y 12.1(1)EC1 del software del IOS de Cisco.

El token-bucket con el esquema de modelado de tráfico también se puede aplicar a los puertos ascendentes, pero dado que es responsabilidad de los cablemódems realizar la limitación de velocidad ascendente, el esquema de limitación de velocidad ascendente aplicado al CMTS normalmente no tendrá ningún impacto en el rendimiento de un sistema.

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

Vea la Guía de Referencia de Comandos de Cable de Banda Ancha de Cisco para obtener más información sobre los comandos cable downstream rate-limit y cable upstream rate-limit .

Los usuarios pueden ver qué tan severamente el CMTS limita la velocidad del tráfico a un cablemódem determinado mediante el comando show interface cable X/Y sid <Z>counters, donde cable X/Y es la interfaz de cable a la que está conectado el cablemódem y Z es el número SID del módem que se observa. Este comando muestra la cantidad de veces que el CMTS dejó caer un paquete descendente o se negó a permitir un paquete ascendente debido a que el módem excede los límites de caudal. Si no se especifica ningún valor para Z, se muestra la información del contador de todos los cable módems conectados al cable de interfaz 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

El campo Ratelimit DSPktDrop muestra cuántas veces el CMTS ha descartado paquetes destinados al cablemódem debido a que el módem intenta exceder su rendimiento descendente permitido.

El campo RateLimit BWReqDrop muestra cuántas veces el CMTS se ha negado a permitir que un cablemódem envíe un paquete en la trayectoria ascendente debido a que el módem intenta exceder su rendimiento ascendente permitido. En la mayoría de las circunstancias, este contador siempre debe permanecer en 0. Si se eleva significativamente por encima de cero, puede ser que el cablemódem que se observa no esté ejecutando correctamente la limitación de velocidad ascendente.

Nota: Los valores mostrados por el comando show interface cable X/Y sid Z counters pueden restablecerse a cero mediante la ejecución del comando clear counters como se muestra en el ejemplo a continuación.

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

Vea la Guía de Referencia de Comandos de Cable de Banda Ancha de Cisco para obtener más información sobre el comando show interface cable sid counters.

Congestión de canal ascendente

El canal ascendente es normalmente el recurso más valioso en un sistema de cable. Actualmente, la mayoría de los proveedores de servicios de cable utilizan una modulación de ancho de canal de 1,6 MHz y modulación de desplazamiento de fase en cuadratura (QPSK) en la ruta ascendente. El ancho de banda ascendente disponible total para todos los usuarios conectados al canal ascendente es equivalente a aproximadamente 2.5 Mbps. Es importante asegurarse de que el canal ascendente no se utilice en exceso ni se congestione, de lo contrario todos los usuarios de ese segmento ascendente sufrirán un rendimiento deficiente.

El uso ascendente para un puerto ascendente determinado se puede obtener ejecutando el comando CMTS show interface cable X/Y upstream <Z>, donde cable X/Y es el número de interfaz descendente y Z es el número de puerto ascendente. Si se omite Z, se mostrará la información de todos los flujos ascendentes en el cable de interfaz X/Y. Vea la Guía de Referencia de Comandos de Cable de Banda Ancha de Cisco para obtener más información sobre el comando 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

En el puerto ascendente que se ve en el ejemplo, el uso ascendente es actualmente del 18 por ciento y hay 359 módems conectados a este puerto ascendente.

Si el uso del canal ascendente se mantiene por encima del 75% durante el tiempo de uso máximo, los usuarios finales comienzan a sufrir problemas como la latencia, tiempos de "ping" más lentos y una experiencia de Internet generalmente más lenta. Si el uso del canal ascendente está constantemente por encima del 90% durante el tiempo de uso máximo, los usuarios finales experimentan un nivel de servicio extremadamente bajo porque una gran parte de los datos ascendentes del usuario final se tendrán que retrasar o descartar.

El uso del canal ascendente cambia durante el día, ya que los diferentes usuarios tienen la oportunidad de utilizar su cable módem, por lo que es importante supervisar el uso ascendente durante las horas más concurridas del día en lugar de en las horas de uso bajo.

Las maneras de aliviar la congestión ascendente incluyen:

• Reducción del número de cablemódems por flujo ascendente: si hay demasiados cablemódems conectados a un flujo ascendente determinado, o si los usuarios de un flujo ascendente determinado son usuarios de gran ancho de banda ascendente, la mejor solución es trasladar algunos usuarios del puerto ascendente congestionado a un puerto ascendente infrautilizado o a un puerto ascendente completamente nuevo. Esto se consigue normalmente trasladando un nodo de fibra de un grupo de combinación ascendente a otro, o dividiendo un grupo de combinación ascendente en dos grupos de combinación independientes. Para obtener más información, consulte ¿Cuál es el número máximo de usuarios por CMTS?

• Aumentar el ancho del canal ascendente: esto implica un análisis riguroso y exhaustivo del espectro ascendente para encontrar una banda lo suficientemente ancha con características adecuadas de la relación señal-ruido (SNR) para admitir el aumento del ancho del canal. El ancho del canal ascendente no se debe cambiar sin una planificación cuidadosa porque este cambio puede afectar potencialmente a otros servicios en el sistema de cable del usuario. El ancho del canal ascendente se puede cambiar usando el comando cable interface cable upstream Z channel-width <new-channel-width> , donde Z es el número de puerto ascendente y el ancho del nuevo canal es 200000, 400000, 800000, 1600000 (el valor predeterminado) o 3200000. A continuación se muestra un ejemplo.

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

  Vea la Guía de Referencia de Comandos de Cable de Banda Ancha de Cisco para obtener más información sobre el comando show interface cable upstream.

• Cambio del esquema de modulación digital ascendente a modulación de amplitud en 16 cuadraturas (QAM): una vez más, esto requiere un análisis riguroso y exhaustivo del espectro ascendente para verificar si hay una banda de frecuencia disponible en el flujo ascendente que pueda admitir la modulación de 16 QAM. Si este análisis no se realiza correctamente, existe el riesgo de que el rendimiento siga disminuyendo o de que se produzca una interrupción completa de la corriente ascendente. El esquema de modulación ascendente puede modificarse mediante la creación de un perfil de modulación ascendente que utilice modulación 16-QAM y la posterior aplicación de eso a un puerto ascendente. A continuación, se presenta un ejemplo:

  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
  
  

  Vea la Guía de Referencia de Comandos de Cable de Banda Ancha de Cisco para obtener más información sobre los comandos cable modulation-profile y cable upstream modulation-profile . Vea también Configuración de los perfiles de modulación de cable en los Sistemas de terminación del cablemódem de Cisco.

• Reducción del rendimiento de flujo ascendente permitido por cable módem: al reducir la velocidad de transmisión de flujo ascendente máxima en los archivos de configuración DOCSIS adecuados, los usuarios de cable módem no pueden transmitir a una velocidad tan alta en la dirección de flujo ascendente y se alivia la congestión de flujo ascendente. El aspecto negativo de este curso de acción es que los usuarios de cable módem están limitados a una clase de servicio más lenta. Consulte Creación de archivos de configuración de DOCSIS 1.0 mediante Cisco DOCSIS Configurator.

Nota: Las medidas descritas en esta sección no aumentan significativamente el rendimiento de un sistema que ya no está congestionado.

Congestión del canal descendente

El canal descendente tiene mucho más ancho de banda para compartir que un canal ascendente individual; por lo tanto, el canal descendente no está tan sujeto a la congestión como el canal ascendente. Sin embargo, un mayor número de usuarios suele compartir un canal de bajada que cualquier otro canal de subida, por lo que si el canal de bajada se congela, todos los usuarios conectados al segmento de bajada experimentarán una reducción del rendimiento.

La siguiente tabla muestra el ancho de banda de flujo descendente total disponible asociado con los cuatro esquemas de modulación de flujo descendente posibles disponibles en los sistemas DOCSIS.

Esquema de modulador en sentido descendente	Ancho de banda descendente disponible
DOCSIS norteamericanas de 64-QAM	27 Mbps
DOCSIS norteamericanas de 256-QAM	38 Mbps
64-QAM Euro DOCSIS	38 Mbps
256-QAM Euro DOCSIS	54 Mbps

La mayoría de los sistemas de cable DOCSIS implementan actualmente DOCSIS de 64-QAM para Norteamérica y, por lo tanto, tienen 27 Mbps disponibles por canal descendente.

El uso del canal descendente se puede determinar mediante la ejecución del comando show interface cable X/Y, donde cable X/Y es la interfaz de cable que se está observando. La velocidad de salida visualizada en bits por segundo debe compararse con el ancho de banda descendente disponible como se observa en la tabla anterior.

En el siguiente ejemplo, se analiza una interfaz utilizando modulación DOCSIS norteamericana y modulación digital 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

El primer componente de este resultado que debe tenerse en cuenta es el ancho de banda de la interfaz indicado por el parámetro BW. En Cisco IOS Software Releases 12.1(8)EC y versiones posteriores, este valor se ajusta automáticamente según el esquema de modulación descendente y la versión de DOCSIS que se utilice. En las revisiones anteriores a Cisco IOS Software Release 12.1(8)EC, este valor se debe configurar manualmente usando el comando de interfaz de cable bandwidth <bandwidth-in-kilo-bits-per-second> o, de lo contrario, se mantiene en el valor predeterminado de 27000 Kbps.

El segundo componente que debe tenerse en cuenta es la carga de transmisión indicada por el parámetro txload. Este parámetro proporciona una métrica de 255, donde 0/255 significa que no hay tráfico fluyendo en la dirección descendente a 255/255, lo que significa que los datos viajan en la dirección descendente a la máxima velocidad posible (en este caso a 27000 Kbps). Si este parámetro se ejecuta de forma coherente en más de un 75% aproximadamente durante el tiempo de uso máximo (por ejemplo, en más de 191/255), los usuarios finales comienzan a experimentar un acceso a Internet más lento y una latencia más alta.

El tercer componente a tener en cuenta es la velocidad de salida, que muestra la velocidad promedio de flujo descendente en bits por segundo. Si este número supera constantemente aproximadamente el 75% del ancho de banda de flujo descendente disponible durante el tiempo de uso máximo, los usuarios finales comienzan a experimentar un acceso a Internet más lento y una latencia más alta.

De forma predeterminada, estas estadísticas se calculan en un promedio móvil de cinco minutos. (Consulte Comprensión de la Definición de bits por segundo (bits/seg) del Resultado del Comando show interfaces para obtener detalles sobre cómo se calcula el promedio.) El período durante el cual se calcula este promedio puede reducirse a tan solo 30 segundos mediante la ejecución del comando cable interface load-interval 30. Al reducir este período a 30 segundos, se calcula un valor más preciso y actualizado para cada uno de los parámetros tratados en esta sección.

El uso del canal descendente cambia durante el día, ya que los diferentes usuarios tienen la oportunidad de utilizar su cable módem, por lo que es importante supervisar el uso descendente durante las horas más concurridas del día en lugar de hacerlo en las horas de menor uso.

Entre las formas de aliviar la congestión descendente se incluyen:

• Reducción del número de cablemódems por flujo descendente: si hay demasiados cablemódems conectados a un flujo descendente particular, o si los usuarios de un flujo descendente particular son usuarios de gran volumen de ancho de banda de flujo descendente, la mejor solución es mover algunos usuarios del canal descendente congestionado a otro canal descendente. Esto se consigue normalmente dividiendo un grupo de nodos de fibra de flujo descendente asociados con el flujo descendente en dos grupos independientes y asignando cada uno de los nuevos grupos a canales de flujo descendente independientes. Consulte Cuál es el número máximo de usuarios por CMTS.

• Cambio del esquema de modulación digital descendente a 256-QAM - Esta acción requiere un análisis riguroso y exhaustivo del espectro descendente para verificar si el sistema puede soportar una señal 256-QAM. Si este análisis no se realiza correctamente, existe el riesgo de que el rendimiento disminuya aún más o de que se produzca una interrupción completa del flujo descendente. El esquema de modulación descendente se puede cambiar mediante la ejecución del comando cable interface como se muestra a continuación.

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

  Vea la Guía de Referencia de Comandos de Cable de Banda Ancha de Cisco para obtener más información sobre el comando cable downstream modulation.

• Reducción del rendimiento de flujo descendente permitido por cable módem: al reducir la velocidad de transmisión descendente máxima en los archivos de configuración DOCSIS adecuados, los usuarios de cable módem no pueden descargar a una velocidad tan alta en la dirección descendente y se alivia la congestión descendente. El aspecto negativo de este curso de acción es que los usuarios de cable módem están limitados a una clase de servicio más lenta. Consulte Creación de archivos de configuración de DOCSIS 1.0 mediante Cisco DOCSIS Configurator.

  Nota: Las medidas descritas en esta sección no aumentan significativamente el rendimiento de un sistema que ya no está congestionado.

Congestión de Internet o de la red de retroceso

En algunos casos, los problemas de rendimiento pueden no ser el resultado de problemas en la planta de cable o el CMTS, pero pueden estar relacionados con la congestión o problemas en la red de retorno que el CMTS utiliza para conectarse a Internet, o dentro de partes de la propia Internet.

La manera más fácil de determinar si la congestión de red de retorno es un problema es conectar una estación de trabajo al mismo segmento de red que el CMTS e intentar navegar por los mismos sitios web que los usuarios finales detrás de los cable módems están tratando de alcanzar. Si el rendimiento sigue siendo lento, hay un problema de rendimiento en la red no relacionado con el CMTS o el segmento de cable. Si el rendimiento del segmento de red CMTS local es significativamente mejor que el de los usuarios conectados a los cablemódems, vuelva a concentrar sus esfuerzos en el CMTS y el segmento de cable.

Figure 3

En la red anterior, si el Servidor 1, que está conectado al mismo segmento de red que el CMTS, está obteniendo un rendimiento lento al navegar por Internet, entonces el origen del problema no es el CMTS. En su lugar, el cuello de botella o el problema de rendimiento en otro lugar. Para determinar dónde está el problema, se realizan pruebas de rendimiento entre el servidor 1 y varios otros servidores dentro de la red del proveedor de servicios de Internet (ISP) y la red pública de Internet.

Interferencia y errores en la planta de cable

Si hay una cantidad excesiva de ruido o ingreso en un sistema de cable, los paquetes entre los cablemódems y el CMTS pueden dañarse y perderse. Esto puede conducir a una degradación significativa del funcionamiento.

Además de la degradación del rendimiento, algunos de los principales indicadores de problemas de ruido o radiofrecuencia (RF) son:

• Los cablemódems se desconectan esporádicamente o quedan atascados en los estados init(r1) o init(r2).

• Un SNR estimado bajo como se observa en la salida de un show controller cable X/Y upstream Z, donde cable X/Y es la interfaz de cable que se observa y Z es el puerto ascendente que se observa. La especificación DOCSIS requiere una relación portadora-ruido (CNR) de al menos 25 dB para todas las señales ascendentes. Esto equivale a un SNR de aproximadamente 29 dB. El CMTS de Cisco puede detectar de manera coherente señales ascendentes QPSK en niveles SNR mucho peores; sin embargo, todos los proveedores de servicios de cable deben esforzarse por cumplir los requisitos DOCSIS CNR en su sistema. A continuación se muestra un ejemplo de salida 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 

  En el ejemplo anterior, la lectura SNR estimada es de 28,628 dB. Esto es adecuado para el funcionamiento ascendente de QPSK. Nótese que la cifra SNR dada en la salida de este comando es solamente una estimación y no es sustituto de una cifra SNR derivada de un analizador de espectro u otro equipo de prueba apropiado. Vea la Guía de Referencia de Comandos de Cable de Banda Ancha de Cisco para obtener más información sobre el comando show controllers cable upstream spectrum.

• Un número que aumenta rápidamente de errores Corr Forward Error Correction (FEC) y Uncorr FEC en la salida de un comando show cable hop. Los errores Corr FEC señalan datos dañados por ruido en la transmisión ascendente que sin embargo pudieron ser recuperados. Los errores FEC imposibles de corregir señalan información dañada por el ruido ascendente y que no se pudo recuperar, y que como consecuencia originó pérdida de información y un rendimiento más lento. A continuación se muestra un ejemplo de salida del comando 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 

  En el ejemplo anterior, cada puerto ascendente activo en el cable 3/0 parece haber experimentado la pérdida de paquetes debido al ruido. El puerto ascendente 0 parece ser el menos afectado y el puerto ascendente 2 parece ser el más seriamente afectado. El factor importante que debe señalarse es la velocidad a la que se incrementan los errores de FEC en vez de la cantidad total de errores. Vea la Guía de Referencia de Comandos de Cable de Banda Ancha de Cisco para obtener más información sobre el comando show cable hop.

• Un alto número de eventos "flap" en la salida de un comando show cable flap-list. Las estadísticas de inestabilidad más relevantes para posibles problemas de RF o ruido son la columna Miss, que indica solicitudes de medición perdidas, y la columna P-Adj, que indica niveles de energía ascendente que varían rápidamente. A continuación se muestra un ejemplo de salida del comando 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 

• Módems por cable que muestran un "*" o un "!—" en la salida de un comando show cable modem o show cable flap-list. Un "*" indica un cable módem que está variando rápidamente sus niveles de energía de flujo ascendente. Esto es indicativo de una mala conexión a la planta de cable, un amplificador de trayectoria inversa defectuoso o atenuación de planta de cable que cambia rápidamente debido a la temperatura u otros efectos ambientales. Un "!—" indica un cable módem que ha alcanzado su nivel máximo de potencia ascendente. Esto es indicativo de demasiada atenuación entre el cable módem y el CMTS, o de una mala conexión entre el cable módem y la planta de cable. Se muestra abajo un resultado de ejemplo del comando 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 

  En el ejemplo anterior, el cable módem con dirección MAC 005a.73f6.2213 transmite a su potencia de salida máxima. Esto hace que el módem no pueda transmitir en el nivel correcto. En consecuencia, las transmisiones ascendentes de este módem no se escuchan con la misma claridad que las transmisiones de otros módems. El cablemódem con dirección MAC 009c.96d7.3831 tiene una salida de tensión rápidamente variable debido a una atenuación variable en el sistema de cable. Vea la Guía de Referencia de Comandos de Cable de Banda Ancha de Cisco para obtener más información sobre los comandos show cable modem y show cable flap-list .

Nota: Puede encontrar más detalles sobre la identificación y resolución de problemas de ruido de RF en Determinación de RF o Problemas de Configuración en el CMTS y Conexión del Router de la Serie uBR7200 de Cisco a la Cabecera del Cable.

Uso elevado de la CPU en el CMTS

En algunas circunstancias, un CMTS de Cisco puede sobrecargarse debido a una configuración subóptima, al uso excesivo de ciertas funciones de administración o a un número muy alto de paquetes enrutados por el CMTS.

La mejor manera de determinar el uso de CPU de un CMTS de Cisco es ejecutar el comando show process cpu. El uso actual de la CPU se indica en la primera línea del resultado del comando.

En las líneas de salida que se muestran a continuación, cada proceso que se está ejecutando en el CMTS se muestra junto con la porción de CPU que está utilizando el proceso. Esta sección del resultado de show process cpu es útil para determinar si un proceso o función en particular es la causa de una CPU CMTS alta.

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

En el ejemplo anterior, la carga actual de la CPU en el CMTS es del 45%/21%. Esto significa que el uso total de la CPU es del 45% de la capacidad del sistema. Además, el 21% de la CPU se utiliza para realizar interrupciones de servicio. Esta segunda cifra por lo general se corresponde con la parte del CPU que se está utilizando para rutear paquetes y conmutar el tráfico a través del CMTS.

Si el uso de la CPU durante cinco minutos es constante en más del 80% durante el tiempo de uso máximo del sistema, los usuarios finales pueden empezar a experimentar un rendimiento más lento y una latencia mayor. Si el uso de CPU de cinco minutos es constantemente superior al 95 por ciento durante el tiempo de uso máximo, tome medidas urgentes para asegurarse de que el CMTS permanezca en un estado estable.

Las estrategias comunes para reducir el uso elevado de la CPU en el CMTS incluyen:

• Actualizando a Cisco IOS Software Release 12.1(9)EC o posterior, activando el comando de configuración global ip cef y asegurándose de que ninguna interfaz en el CMTS tenga el comando no ip route-cache configurado. Esto normalmente conlleva una reducción del 10 al 15% en el uso de la CPU relacionado con el tráfico. Asegúrese de que todos estos pasos se realicen de manera conjunta.

• Asegurarse de que las estaciones de administración del Protocolo simple de administración de red (SNMP) no sean demasiado agresivas en el sondeo del CMTS. Esto conduce a un uso elevado de la CPU en el proceso IP SNMP.

• No ejecute el comando show tech varias veces sucesivamente. Esto conduce a un uso artificialmente alto de la CPU en el proceso Virtual Exec.

• Asegúrese de que no se esté ejecutando ningún comando debug en el CMTS.

Para obtener más información sobre el uso elevado de la CPU en los routers de Cisco, incluidos los productos CMTS de Cisco, consulte Resolución de problemas de uso elevado de la CPU en routers de Cisco.

Equipo CPE con poca alimentación o mal configurado

En muchos casos, la causa de un acceso lento a una red de cable es un problema en el equipo CPE del usuario final. Si solo uno o un puñado de usuarios experimentan un rendimiento lento y el resto de la población de usuarios no experimenta ningún problema, esto es una fuerte indicación de que puede haber un problema único dentro del entorno de ese usuario.

• Con CPE alimentado o sobrecargado: si los usuarios finales que se quejan de dificultades utilizan equipos CPE anticuados o equipos que pueden no ser lo suficientemente potentes para ejecutar el sistema operativo o el software de acceso a Internet que han elegido, el usuario final tendrá dificultades. La única solución, si este es el caso, es que el usuario final actualice el equipamiento CPE.

• Firewall o software de medición de rendimiento: si el usuario final está ejecutando algún firewall, medición de rendimiento de red u otro software similar, un buen paso para solucionar el problema es hacer que el usuario apague este software para ver si tiene algún efecto en el rendimiento. A menudo, estos tipos de software pueden tener un impacto negativo en el rendimiento.

• Configuración TCP/IP mal configurada: la mayoría de los proveedores de servicios requieren que los usuarios finales tengan su equipo CPE que adquiera una dirección IP, una máscara de red, una puerta de enlace predeterminada y servidores DNS mediante el protocolo de configuración dinámica de host (DHCP). Asegúrese de que todos los usuarios finales que experimenten problemas tengan sus dispositivos CPE configurados para utilizar DHCP para adquirir todos estos parámetros.

Si un usuario final afirma no tener ninguno de los problemas enumerados anteriormente, confirme que el usuario final no está excediendo su velocidad máxima de carga o descarga según las secciones anteriores.

Conclusión

Una red de cable DOCSIS es un sistema sofisticado que requiere una planificación y un mantenimiento adecuados. La mayoría de los problemas de rendimiento en los sistemas de cable DOCSIS son resultado directo de la planificación y el mantenimiento adecuados que no se realizan. En el mercado actual de acceso a Internet, donde existen diversas alternativas de acceso a Internet de banda ancha, es importante que los proveedores de servicios de cable aborden rápidamente cualquier problema de rendimiento o congestión en su sistema antes de que los problemas se vuelvan lo suficientemente significativos como para que los usuarios finales se vean afectados de forma notable y, en consecuencia, consideren un medio alternativo de acceso de banda ancha.

Información Relacionada

• Troubleshooting de uBR Cable Modems que no funcionan
• Determinación de RF o problemas de configuración en el CMTS
• Conexión del router de la serie Cisco uBR7200 al cable de cabecera
• Resolución de problemas por uso excesivo de las CPU de los routers de Cisco
• Soporte Técnico y Documentación - Cisco Systems