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.

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

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

• Rendimiento restringido por los límites del archivo de configuración DOCSIS.

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

• Congestión de canales ascendente y descendente.

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

• Ruido o errores en la planta de cable.

• En el equipo de las instalaciones del cliente (CPE) del usuario final con alimentación.

Cada una de estas opciones de forma individual o combinada puede afectar al rendimiento y al rendimiento de una red por cable.

Este documento no explica cómo resolver problemas de una pérdida completa de conectividad a través de la red de cable o los cablemódems que no se conectan. En su lugar, consulte Solución de problemas de 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.

• Cisco IOS® Software Release 12.1(9)EC para uBR7200 y uBR7100 CMTS.

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

• La información de este documento es relevante para todas las demás versiones disponibles actualmente del software Cisco IOS basado en DOCSIS 1.0 para equipos 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. All of the devices used in this document started with a cleared (default) configuration. 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 consiguen

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:

• Red híbrida de fibra óptica 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 está midiendo la velocidad de todos los componentes de red entre los dos puntos.

Por ejemplo, si 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 forma 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 el único trayecto que deben recorrer los datos es el segmento de cable coaxial. Los datos también deben atravesar el segmento de red CMTS local, pero se supone 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, entonces 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. Se trata de una medida precisa siempre y cuando haya links de alta velocidad y sin congestión adecuados dentro de la red interna del proveedor de servicios de cable entre el CMTS y el CPE.

La manera más inexacta 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 manera más fácil de determinar la velocidad a la que se realizan las cargas y descargas es cargar o descargar un archivo grande mediante FTP o HTTP entre un dispositivo CPE conectado a un cablemó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 la transferencia ha finalizado. La velocidad de transferencia observada como resultado de la operación FTP o HTTP es generalmente alrededor del 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 necesita 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 Netcom Smartbits o un generador de paquetes IXIA; sin embargo, estos sistemas no siempre están disponibles o conectados fácilmente a una red de cable de producción. Cabe destacar que si las pruebas de rendimiento se realizan 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 sólo es fiable para velocidades de prueba de aproximadamente 3 Mbps o menos. A velocidades mayores, la potencia de procesamiento del dispositivo CPE, las tarjetas de interfaz de red (NIC) o el servidor pueden convertirse en un factor limitante en 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 FTP entre un dispositivo CPE conectado a un cablemódem y un servidor FTP en la red del proveedor de servicios de 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. El usuario del dispositivo CPE recibe un nombre de usuario y una contraseña para poder iniciar sesión en el servidor FTP de modo que puedan descargar este archivo del 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 realiza al tener un servidor web HTTP configurado en la red del proveedor de servicios y realizando 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 el cable X/Y es la interfaz de cable a la que está conectado el módem sometido a prueba, y Z es el número de ID de servicio (SID) del módem sometido a 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 dirección MAC 001.9659.4461.

Primero, busque el número SID del módem que se está probando usando 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 carga avanza, 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 cronómetro.

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 la hora se lean exactamente un minuto, ejecute el comando show interface cable X/Y sid Z counters. Puede ser mejor escribir primero el comando y luego pulsar Intro exactamente cuando el temporizador indica un minuto. La prueba se puede realizar 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; sin embargo, asegúrese de que la descarga o la carga no finalice antes de que el temporizador de cronómetro alcance el tiempo especificado; de lo contrario, la medición es incorrecta.

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:

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 se tarda en descargarlos en segundos.

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

Se muestra que la velocidad de descarga en este ejemplo es de aproximadamente 256 Kbps, que resulta ser la velocidad de descarga permitida para el cable módem bajo prueba.

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

Consulte 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 debe recopilarse al solucionar problemas de rendimiento lento del cablemódem es la clase de servicio prescrita que limita el rendimiento del cablemódem. Cuando un cablemódem se conecta, descarga un archivo de configuración DOCSIS que contiene los límites operativos para el cablemódem, incluyendo 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 cablemódem con problemas. Tomando un módem con la dirección MAC 0050.7366.2223 que está teniendo problemas con el rendimiento lento, es necesario averiguar qué clase de perfil de servicio está utilizando este cablemódem ejecutando el comando show cable modem <mac-address>, como se muestra en el ejemplo siguiente.

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 cable módem tiene un perfil de calidad de servicio (QoS) de 5. Para averiguar a qué tasas 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 es el flujo ascendente. Cualquier CPE conectado a cablemódems que utilicen el perfil 5 de QoS no puede superar estos límites. La configuración del perfil de QoS se determina por el contenido de los archivos de configuración DOCSIS descargados por 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 que se muestran en su perfil de QoS, obtendrán la clase de servicio y los niveles de rendimiento para los que se ha aprovisionado y configurado el cablemódem. La única manera de aumentar el rendimiento de carga y descarga es cambiar el archivo de configuración DOCSIS que está descargando el cable módem a uno que tiene límites de rendimiento más altos. Consulte el documento titulado Creación de archivos de configuración DOCSIS 1.0 mediante Cisco DOCSIS Configurator para obtener instrucciones detalladas sobre cómo crear o modificar un archivo de configuración 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 que permite el archivo de configuración DOCSIS de su cablemó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.

Del mismo modo, cuando un usuario final intenta cargar o enviar datos a Internet a una velocidad mayor que la que permite el archivo de configuración DOCSIS, el cablemódem mismo debe impedir que el tráfico excedente pase por el segmento de cable al CMTS. Si el cablemódem, por alguna razón, no puede realizar la limitación de la velocidad ascendente correctamente, entonces el CMTS prohíbe explícitamente que el cablemódem transmita una velocidad superior a la permitida. Este comportamiento en el CMTS es asegurar que incluso un cablemódem con características "hacked" no pueda subvertir los límites de velocidad de carga asignados por el proveedor de servicios.

El esquema de limitación de velocidad predeterminado utilizado por el CMTS monitorea la velocidad de 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, entonces el CMTS no permite que más tráfico fluya a ese cablemódem por el resto del segundo.

A modo de ejemplo, tome un cable módem con un perfil de QoS que permita una velocidad de descarga de 512 Kbps. Si el cablemódem descarga 512 kilobits (64 kilobytes) en la primera mitad de un segundo, entonces en la siguiente mitad del segundo, el cablemódem no puede descargar nada. 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 debe utilizar es el algoritmo de limitación de velocidad de cubeta con ficha 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 un ritmo constante, al tiempo que se garantiza que los usuarios finales no puedan superar la velocidad de descarga prescrita, como se especifica en el archivo de configuración DOCSIS.

El funcionamiento de este esquema es medir la velocidad a la que un cablemódem descarga o carga datos cada vez que se envía un paquete desde o hacia el cablemódem. Si el envío o la recepción del 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 memoria caché en la memoria CMTS hasta que el CMTS pueda enviar el paquete sin exceder el límite de ancho de banda descendente.

Nota: Si la velocidad del tráfico descendente excede de manera consistente la velocidad de flujo descendente permitida para el cablemódem, los paquetes finalmente se descartan.

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 sencilla y eficiente que cuando se utiliza el esquema de limitación de velocidad predeterminado.

El esquema Token-bucket rate-limit-with-traffic-shaping 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 cubeta con ficha en el CMTS del usuario. Este comando se soporta a partir de las versiones 12.0(5)T1 y 12.1(1)EC1 del software del IOS de Cisco.

La cubeta con ficha 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 el límite 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

Consulte 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 la gravedad con la que el CMTS limita la velocidad del tráfico a un cable módem particular usando el comando show interface cable X/Y sid <Z> counters, donde el cable X/Y es la interfaz de cable a la que está conectado el cable mó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 cablemó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 de flujo 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 mantenerse en 0. Si se eleva significativamente por encima de cero, puede ser que el cable módem que se observa no esté realizando un límite de velocidad ascendente correctamente.

Nota: Los valores mostrados por el comando show interface cable X/Y sid Z counters pueden restablecerse a cero ejecutando el comando clear counters como se ve en el siguiente ejemplo.

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

Consulte 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 de un sistema de cable. En la actualidad, la mayoría de los proveedores de servicios de cable utilizan una modulación de ancho de canal de 1,6 MHz y de modulación por 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 sobrecargue o se concentre demasiado, 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. Consulte 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 visto en el ejemplo, el uso ascendente es actualmente del 18% y hay 359 módems conectados a este flujo ascendente.

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

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

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 intensos del ancho de banda ascendente, la mejor solución es mover algunos usuarios del puerto ascendente congestionado a un puerto ascendente bajo uso o a un puerto ascendente completamente nuevo. Esto se logra normalmente al mover un nodo de fibra de un grupo de combinación ascendente a otro o dividir 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 minucioso del espectro ascendente para encontrar una banda lo suficientemente ancha con características adecuadas de la relación señal-ruido (SNR) para soportar el ancho de canal aumentado. 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 de interfaz de cable cable ascendente Z channel-width <new-channel-width> donde Z es el número de puerto ascendente y el ancho del canal nuevo es uno de 200000, 400000, 800000, 160000 (el predeterminado) o 3200000. A continuación, se presenta un ejemplo:

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

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

• Cambiar el esquema de modulación digital ascendente a Modulación de amplitud (QAM) de 16 cuadraturas - Una vez más, esto requiere un análisis riguroso y minucioso del espectro ascendente para verificar si hay una banda de frecuencia en el flujo ascendente disponible que pueda soportar la modulación de 16-QAM. Si este análisis no se realiza correctamente, existe el riesgo de que el rendimiento se reduzca aún más o de que se produzca una interrupción completa del flujo 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
  
  

  Consulte 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 ascendente permitido por cablemódem - Al reducir la velocidad máxima de transmisión ascendente en los archivos de configuración DOCSIS adecuados, los usuarios de cablemódem no pueden transmitir a una velocidad tan alta en la dirección ascendente y se libera la congestión ascendente. El aspecto negativo de este curso de acción es que los usuarios de cablemódem se limitan a una clase de servicio más lenta. Consulte Creación de Archivos de Configuración de DOCSIS 1.0 con Cisco DOCSIS Configurator.

Nota: Las medidas examinadas en esta sección no aumentan significativamente el rendimiento de un sistema ya descongestionado.

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, por lo general, más usuarios comparten un canal descendente que cualquier canal ascendente, de modo que si el canal descendente se congestiona, todos los usuarios conectados al segmento descendente experimentarán un rendimiento reducido.

La siguiente tabla muestra el ancho de banda descendente total disponible asociado a los cuatro posibles esquemas de modulación descendente 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 actualmente implementan 64-QAM North American DOCSIS 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 observa. 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 esta salida a tener 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 posteriores, este valor se ajusta automáticamente según el esquema de modulación descendente y la versión de DOCSIS que se está utilizando. En las revisiones anteriores a la versión 12.1(8)EC del software Cisco IOS, este valor se debe configurar manualmente usando el comando de interfaz de cable bandwidth <bandwidth-in-kilo-bits-per-second> o, de lo contrario, permanece en el valor predeterminado de 27000 Kbps.

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

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

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) desde la Salida del Comando show interfaces para obtener detalles sobre cómo se calcula el promedio.) El período durante el cual se calcula este promedio se puede reducir a tan sólo 30 segundos ejecutando el 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 analizados en esta sección.

El uso del canal descendente cambia durante el día, ya que diferentes usuarios tienen la oportunidad de utilizar su cablemódem, por lo que es importante monitorear el uso descendente durante las horas más activas del día en lugar de a las horas de uso bajas.

Las formas de aliviar la congestión descendente incluyen:

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

• Cambio del esquema de modulación digital de flujo descendente a 256-QAM - Esta acción requiere un análisis riguroso y minucioso del espectro de flujo 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 se reduzca aún más o de que se produzca una interrupción completa en la fase descendente. El esquema de modulación descendente se puede cambiar ejecutando el comando cable interface como se ve a continuación.

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

  Consulte 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 cablemódem - Al reducir la velocidad máxima de transmisión descendente en los archivos de configuración DOCSIS adecuados, los usuarios de cablemódem no pueden descargar a una velocidad tan alta en la dirección descendente y se libera la congestión descendente. El aspecto negativo de este curso de acción es que los usuarios de cablemódem se limitan a una clase de servicio más lenta. Consulte Creación de Archivos de Configuración de DOCSIS 1.0 con Cisco DOCSIS Configurator.

  Nota: Las medidas examinadas en esta sección no aumentan significativamente el rendimiento de un sistema ya descongestionado.

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 red de retorno que el CMTS utiliza para conectarse a Internet o dentro de partes de Internet en sí.

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 CMTS e intentar navegar en los mismos sitios web que los usuarios finales detrás de los cablemódems que intentan 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 para los usuarios conectados a cablemódems, entonces concentre los 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 problema de cuellos de botella o rendimiento se produce 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 Internet pública.

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 ser dañados y perdidos. Esto puede conducir a una degradación significativa del funcionamiento.

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

• Los cablemódems caen esporádicamente desconectados o se atascan en los estados init(r1) o init(r2).

• Un SNR bajo estimado como se ve 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. Cisco CMTS puede detectar de forma coherente las señales ascendentes QPSK en niveles SNR mucho peores; sin embargo, todos los proveedores de servicios de cable deben esforzarse por cumplir los requisitos de 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 28.628dB. Esto es adecuado para la operación ascendente QPSK. Tenga en cuenta que la cifra SNR dada en el resultado de este comando es sólo una estimación y no sustituye a una cifra SNR derivada de un analizador de espectro u otro equipo de prueba adecuado. Consulte 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 de corrección de errores de Corr Forward (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 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. Consulte 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 pertinentes para posibles problemas de ruido o de RF son la columna Miss, que indica solicitudes de medición de distancias perdidas, y la columna P-Adj, que indica niveles de potencia 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 

• Los cablemódems que muestran un "* "!—" en la salida de un comando show cable modem o show cable flap-list. Un "*" indica un cablemódem que cambia rápidamente sus niveles de potencia ascendente. Esto indica una conexión deficiente a la planta de cable, un amplificador de trayectoria inversa defectuoso o una atenuación de la planta de cable en rápida evolución 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 indica demasiada atenuación entre el cable módem y el CMTS, o una conexión defectuosa 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 tan claramente como 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. Consulte 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: Se pueden encontrar más detalles sobre la identificación y resolución de problemas de ruido de RF en la determinación de problemas de RF o configuración en el CMTS y conexión del Cisco uBR7200 Series Router al Cabecero de Cable.

Uso elevado de la CPU en 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 que el CMTS está enrutando.

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 de la salida show process cpu es útil para determinar si un proceso o función en particular es la causa de la CPU de 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 de CPU actual 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 atender interrupciones. 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 consistente en más del 80% durante el tiempo máximo de uso del sistema, los usuarios finales pueden empezar a experimentar un rendimiento más lento y una mayor latencia. Si el uso de la CPU de cinco minutos es constantemente superior al 95% durante el tiempo pico de uso, tome medidas urgentes para asegurarse de que el CMTS permanezca en un estado estable.

Entre las estrategias comunes para reducir el uso elevado de la CPU en el CMTS se incluyen las siguientes:

• 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 conduce a 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 se muestran demasiado agresivas a la hora de sondear el 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 de CPU artificialmente alto 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 Cisco CMTS, refiérase a Resolución de Problemas por el Uso Excesivo de la CPU en los 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 sólo uno o varios usuarios experimentan un rendimiento lento y el resto de la población de usuarios no experimenta ningún problema, esto indica claramente que puede haber un problema único en el entorno de ese usuario.

• Bajo CPE con alimentación o sobrecargado: si los usuarios finales que se quejan de dificultades utilizan equipos CPE antiguos o equipos que pueden no ser lo suficientemente potentes para ejecutar el sistema operativo o el software de acceso a Internet que han elegido, este 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 del rendimiento: si el usuario final está ejecutando algún firewall, medición del rendimiento de la red u otro software similar, un buen paso para la resolución de problemas es hacer que el usuario apague este software para ver si tiene algún efecto en el rendimiento. A menudo, este tipo de software puede 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 para adquirir una dirección IP, una máscara de red, una gateway predeterminada y servidores DNS mediante el protocolo de configuración dinámica de host (DHCP). Asegúrese de que los dispositivos CPE de cualquier usuario final que experimente problemas estén 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 excede su velocidad máxima de descarga o carga 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 que no se realiza el mantenimiento y la planificación adecuados. En el mercado actual del acceso a Internet, donde hay una variedad de 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 notablemente 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 a la cabecera de cable
• Resolución de problemas por uso excesivo de las CPU de los routers de Cisco
• Soporte Técnico y Documentación - Cisco Systems