Banda ancha por cable : Cable módems

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

18 Octubre 2015 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Contenido


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 mira cómo determinar exactamente qué clase de niveles de caudal un usuario final está alcanzando y cómo aseegurarse que el funcionamiento que es medido es el de la red de cable, bastante que el del Internet más amplio.

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

  • Funcionamiento que es restringido por los límites en el archivo de configuración de DOCSIS.

  • Bursty o rendimiento de descarga irregular causado usando una tarifa subóptima que limita el esquema en el Sistema de terminación del cablemódem (CMTS).

  • Congestión del canal ascendente y descendente.

  • Red de retroceso o congestión de Internet.

  • Ruido o errores en la planta de cable.

  • Bajo el equipo de premisas de cliente usuario final accionado (CPE).

Cada uno de estos individualmente o en la combinación puede afectar a la producción y al funcionamiento en una red de cable.

Este documento no discute el localizar averías de una pérdida de conectividad completa sobre la red de cable o el Cable módems que no viene en línea. En lugar, refiera al Online que no viene del Cable módems del uBR del troubleshooting para estas clases de problemas. Además, para los usuarios finales de un UBR 900 o CVA 120 Series Cable Modem que experimentan los problemas de rendimiento, el mejor comenzando el lugar para localizar averías este problema es los principiantes FAQ para los usuarios finales del uBR900 Series Cable Modem.

Antes de comenzar

Convenciones

Para obtener más información sobre las convenciones del documento, consulte Convenciones de Consejos Técnicos de Cisco.

prerrequisitos

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 Release 12.1(9)EC de Cisco IOS� para el ubr7200 y el uBR7100 CMTS.

  • El Cisco uBR7100, ubr7200, y habitación del uBR7200VXR de los productos CMTS.

  • La información en este documento es relevante para el resto de las versiones actualmente disponibles del Cisco IOS Software del DOCSIS 1.0-based para el equipo CMTS de 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.

Exactamente determinando los niveles de rendimiento que son alcanzados

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.

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

Cuadro 1 (ver este diagrama como animación Flash hacer clic aquí.)

En este diagrama se muestran varios componentes:

  • La red del coaxil de la fibra híbrida entre el usuario final y el CMTS.

  • El segmento de red local CMTS donde el CMTS conecta con la red de proveedor de servicio de cable.

  • La red interna del proveedor de servicio de cable.

  • Los Internetes públicas.

Al realizar una prueba de velocidad entre dos puntas, la velocidad de todos los componentes de la red entre las dos puntas se está midiendo.

Por ejemplo, si la ejecución de una prueba de velocidad entre el CPE y el Server3, que está conectada con Internet a través de una línea ISDN del kbps 128, allí nunca es velocidades de mayor que el kbps 128, incluso si el ancho de banda disponible en el segmento del cable es el mayor entonces kbps 128.

La mayoría de la forma adecuada de medir el funcionamiento del segmento del cable sí mismo es realizar una prueba de velocidad entre el CPE y el server1, que está conectada con el mismo segmento de red que el CMTS. Esto es porque los únicos datos de trayecto necesitan viajar encima son el segmento del cable coaxial. Los datos también deben viajar a través del segmento de red local CMTS, pero se supone que este segmento está de un ancho de banda alto (FastEthernet o mayor) y que no tiene un nivel elevado de congestión.

Si por alguna razón, ningún servidor se puede conectar con el segmento de red local CMTS, después la mayoría de la forma adecuada siguiente de probar el funcionamiento del segmento del cable es realizar una prueba de velocidad entre el CPE y el server2. Esto es una medición precisa mientras haya links adecuadamente de alta velocidad y uncongested dentro de la red interna del proveedor de servicio de cable entre el CMTS y el CPE.

La mayoría de la forma incorrecta de determinar el funcionamiento del segmento del cable es realizar una prueba de velocidad entre el CPE y un servidor en los Internetes públicas. 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 cual carga y están ocurriendo las descargas son cargar o descargar un archivo grande usando el FTP o el HTTP entre un dispositivo CPE conectado con un módem de cable, y un servidor detrás del CMTS. La mayoría del FTP y de los clientes HTTP pueden visualizar la velocidad a la cual una descarga o una carga está ocurriendo o durante la transferencia o la transferencia es una vez completa. La velocidad de la transferencia considerada como resultado del FTP o de la Operación HTTP es el típicamente cerca de 90 por ciento del caudal útil total verdadero logrado. Esto es porque la velocidad de la transferencia visualizada FTP o HTTP no tiene en cuenta el IP adicional y la tara del DOCSIS que necesita viajar entre el dispositivo CPE y el CMTS.

Hay más métodos precisos de medir la producción, por ejemplo usando el equipo de prueba dedicado de tercera persona, tal como un Netcom Smartbits o un generador de paquete IXIA, no obstante estos sistemas no son siempre fácilmente disponibles o conectados fácilmente con una red de cable de la producción. Vale el observar de que si las pruebas de la producción se están realizando en un ambiente de laboratorio, después usando un dispositivo dedicado revelará mucho más información que prueba de la descarga simple FTP o HTTP.

Nota: La prueba basado en HTTP ftp o de la carga y de la descarga es solamente confiable para las velocidades de prueba alrededor del 3 Mbps o menos. A velocidades más altas la potencia de procesamiento del dispositivo CPE, del servidor o del Network Interface Cards (NIC) puede convertirse en factor limitativo en la prueba. Para probar apresura más arriba que sobre el 3 Mbps, el equipo de prueba dedicado del flujo de datos debe ser utilizado.

En el siguiente ejemplo, una prueba simple de la descarga y de la carga FTP se realiza entre un dispositivo CPE conectado con un módem de cable, y un servidor FTP en la red de proveedor de servicio de cable. El módem de cable ha descargado un archivo de configuración de DOCSIS que permite una velocidad de la descarga hasta del kbps 256 y una velocidad de carga de hasta 64 kbps. En esta prueba, un archivo del 3 Mb se ha puesto en el servidor FTP en la dirección IP 172.17.110.132. Dan el usuario del dispositivo CPE un nombre de usuario y contraseña para poder registrar en el servidor FTP así que pueden descargar este archivo del servidor FTP, y después lo cargan de nuevo al servidor FTP. La utilidad FTP de línea de comando se utiliza para realizar la transferencia. Esta utilidad está disponible en virtualmente todas las versiones de Microsoft Windows y de UNIX.

Una prueba similar es conducida teniendo una configuración del servidor Web HTTP en la red de proveedor de servicio y realizando una descarga HTTP.

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

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

El primeros encuentran el número SID del módem que es probado 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 que está progresando la descarga o la carga, borre todos los contadores de paquetes en el CMTS de nuevo a cero usando el comando clear counters. Exactamente cuando se borran los contadores, comience 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 del cronómetro o del tiempo lee exactamente un minuto, publican el comando show interface cable X/Y sid Z counters. Puede ser el mejor teclear el comando primero y entonces golpear ingrese 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 es el período de la prueba, cuanto más exacto el resultado, sin embargo se aseegura que la descarga o la carga no acaba antes de que el temporizador o cronómetro alcance el tiempo especificado, si no la medida es inexacta.

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 la velocidad de la descarga se está probando. La salida del comando show interface cable X/Y sid Z counter indica eso durante un minuto, 1,921,488 bytes es descargada por el módem de cable. Convertir 1,921,488 bytes en los bits revela:

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

Entonces, encontrar la velocidad de descarga en los bits por segundo, divida este número total de bits descargados para el momento en que tome para descargarlos en los segundos.

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

La velocidad de descarga en este ejemplo se muestra para ser aproximadamente el kbps 256, que sucede ser la velocidad de descarga permitida para el módem de cable bajo prueba.

Para mirar la velocidad de carga usando el comando show interface cable X/Y sid Z counters, la columna de Inoctets se debe utilizar para determinar la cantidad de bytes enviada en la dirección ascendente del módem de cable.

Vea la guía de referencia de comandos del cable del ancho de banda de Cisco para 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 necesita ser recopilada al localizar averías el rendimiento de cable módem lento es las limitaciones del rendimiento prescritas de la clase del servicio del módem de cable. Cuando viene un módem de cable en línea, descarga un archivo de configuración de DOCSIS que contenga los límites de funcionamiento para el módem de cable, incluyendo la velocidad máxima de carga y descarga. En circunstancias normales, no se permite que el módem de cable exceda estas velocidades.

Es inicialmente necesario identificar la dirección MAC de un módem de cable que tiene problemas. Tomando un módem con la dirección MAC 0050.7366.2223 que está teniendo problemas con la producción lenta. es necesario descubrir qué clase del servicio está utilizando el perfil este módem de cable ejecutando el comando show cable modem < mac-address > como se ve en el ejemplo abajo.

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í muestra que este módem de cable tiene un perfil del Calidad de Servicio (QoS) de 5. para descubrir qué velocidades en los sentidos descendentes y ascendentes corresponde este perfil de QoS, utiliza el comando del perfil-número del perfil de los qos del cable de la demostración, donde está el perfil el perfil-número de QoS del 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í muestra que el perfil 5 de QoS corresponde a un servicio que proporciona al kbps 256 en el rio abajo y 64 kbps son la conexión en sentido ascendente. Ningún CPE conectado con el Cable módems usando el perfil 5 de QoS no puede exceder estos límites. Las configuraciones del perfil de QoS son determinadas por el contenido de los archivos de configuración de DOCSIS descargados por el Cable módems del servidor TFTP del sistema de abastecimiento, por lo tanto el perfil 5 de QoS en el sistema puede no ser lo mismo que el perfil 5 de QoS en el ejemplo mostrado arriba.

Si la descarga de un usuario final y el funcionamiento de la carga correlacionan con los límites mostrados en su perfil de QoS, después están consiguiendo la clase del servicio y los niveles de caudal para los cuales el módem de cable ha sido aprovisionado y configurado. La única forma de aumentar la producción de la carga y de la descarga es cambiar el archivo de configuración de DOCSIS que es descargado por el módem de cable a una que tenga límites del más alto rendimiento. Vea el documento titulado los archivos de configuración constructivos del DOCSIS 1.0 usando el Cisco DOCSIS Configurator (clientes registrados solamente) para las Instrucciones detalladas en 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 está intentando descargar los datos de Internet a una tarifa mayor que el archivo de configuración de DOCSIS de su módem de cable permite, el CMTS debe límite de velocidad el tráfico que es enviado a ese usuario para asegurarse de que el usuario no consume más que su parte permitida del ancho de banda.

Semejantemente, cuando un usuario final intenta cargar o enviar los datos a Internet a una tarifa mayor que lo que el archivo de configuración de DOCSIS permite, el módem de cable sí mismo debe parar el tráfico en exceso de viajar sobre el segmento del cable al CMTS. Si el módem de cable, por alguna razón, no puede realizar la velocidad ascendente que limita correctamente, después el CMTS prohíbe explícitamente el módem de cable de transmitir más arriba que la tarifa permitida. Este comportamiento en el CMTS es asegurarse de que incluso un módem de cable con las características “cortadas” no puede derribar el proveedor de servicio asignado los límites de la velocidad de carga.

El esquema predeterminado de la limitación de la tarifa usado por el CMTS monitorea el índice de tráfico a o desde cada módem de cable durante cada período de un segundo. Si el módem de cable envía o recibe más que su por segundo cuota en menos que un segundo, después el CMTS no permite que más tráfico fluya a ese módem de cable para el resto del segundo.

Como un ejemplo, tome un módem de cable con un perfil de QoS permitiendo una velocidad de descarga de 512 kbps. Si el módem de cable descarga 512 kilobites (64 kilobytes) dentro de la primera mitad de un segunda, después para la mitad siguiente del segunda, el módem de cable no se permite descargar cualquier cosa. 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 esquema rio abajo de la limitación de la tarifa del mejor a utilizar es el algoritmo de limitación de velocidad de cubeta con ficha con el modelado de tráfico. Este esquema de la limitación de la tarifa se ha optimizado para permitir exploración de la Web una experiencia lisa a una tarifa constante, mientras que al mismo tiempo se asegura de que no se permite a los usuarios finales exceder la velocidad de descarga prescrita como se especifica en el archivo de configuración de DOCSIS.

La manera que este esquema trabaja es medir la tarifa en la cual un módem de cable es que descarga o cargando los datos un paquete se envía cada vez a o desde el módem de cable. Si el envío o la recepción del paquete en la pregunta hace el módem exceder sus velocidades de transferencia permitidas, después el paquete está mitigado u ocultado en la memoria CMTS hasta que el CMTS pueda enviar el paquete sin exceder el límite del ancho de banda descendente.

Nota: Si las relaciones del tráfico rio abajo exceden constantemente la velocidad descendente permitida para el módem de cable, después los paquetes se caen eventual.

Usando este método más liso de tarifa que limita y que forma, la mayoría de las aplicaciones de Internet TCP basadas tales como HTTP exploración de la Web y las transferencias de archivos FTP actúan más suavemente y eficientemente que al usar el esquema predeterminado de la limitación de la tarifa.

El esquema del tarifa-limitar-con-tráfico-shaping de la cubeta con ficha se puede habilitar en el trayecto descendente en una interfaz del cable publicando el comando configuration siguiente de la interfaz del cable:

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

Nota: Se recomienda altamente para habilitar el modelado de token-bucket en el CMTS del usuario. Este comando se soporta a partir de los Cisco IOS Software Releases 12.0(5)T1 y 12.1(1)EC1.

La cubeta con ficha con el esquema del modelado de tráfico también se puede aplicar a los puertos ascendentes, pero puesto que es la responsabilidad del Cable módems realizar la velocidad ascendente que limita, el esquema por aguas arriba de la limitación de la tarifa aplicado al CMTS no tendrá normalmente ningún impacto en el funcionamiento de un sistema.

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

Vea la guía de referencia de comandos del cable del ancho de banda de Cisco para más información sobre el tarifa-límite y los comandos cable upstream rate-limit rio abajo del cable.

Los usuarios pueden ver cómo el CMTS es seriamente tarifa que limita el tráfico a un cable módem determinado usando el comando show interface cable X/Y sid <Z> counters, donde está la interfaz del cable el X/Y del cable con la cual el módem de cable está conectado, y Z es el número SID del módem que es observado. 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, después la información de contador para todo el Cable módems conectó con el X/Y del cable de interfaz se visualiza.

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 de Ratelimit DSPktDrop muestra cuántas veces tiene el CMTS paquetes perdidos destinados para el módem de cable debido al módem que intenta exceder su producción rio abajo permitida.

El campo de Ratelimit BWReqDrop muestra cuántas veces ha rechazado el CMTS dejar un módem de cable enviar un paquete en el trayecto ascendente debido al módem que intentaba exceder su rendimiento de procesamiento ascendente permitido. En la mayoría de los casos este contador debe permanecer siempre en 0. Si sube perceptiblemente sobre cero, puede ser que el módem de cable que es observado no esté realizando la velocidad ascendente que limita correctamente.

Nota: Los valores visualizados por el comando show interface cable X/Y sid Z counters se pueden reajustar a cero publicando el comando clear counters como se ve en el ejemplo abajo.

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 del cable del ancho de banda de Cisco para más información sobre el comando show interface cable sid counters.

Congestión de canal ascendente

El canal ascendente es normalmente la mayoría de los recursos preciosos en un sistema de cable. Actualmente, la mayoría de los proveedores de servicio de cable utilizan un ancho del canal del MHz 1.6 y una modulación de la codificación por desplazamiento de fase en cuadratura (QPSK) en el trayecto 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 convierte sobre utilizado o congestionado, si no todos los usuarios en ese segmento por aguas arriba sufren el rendimiento pobre.

El uso del flujo ascendente para un puerto ascendente determinado puede ser obtenido ejecutando el <Z> por aguas arriba del show interface cable X/Y del comando cmts, donde está el Número de interfaz el X/Y del cable rio abajo y Z es el número del puerto ascendente. Si se omite Z, la información para todas las conexiones en sentido ascendente en el X/Y del cable de interfaz será visualizada. Vea la guía de referencia de comandos del cable del ancho de banda de Cisco para 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 considerado en el ejemplo, el uso del flujo ascendente es actualmente el 18 por ciento y hay 359 módems conectados con esta conexión en sentido ascendente.

Si el uso del canal ascendente está constantemente sobre el 75 por ciento durante el tiempo de uso pico, los usuarios finales comienzan a sufrir los problemas tales como tiempo de espera, tiempos más lentos del “ping”, y una experiencia de Internet generalmente más lenta. Si el uso del canal ascendente está constantemente sobre el 90 por ciento durante el tiempo de uso pico, los usuarios finales experimentan un nivel extremadamente pobre de servicio porque una porción grande de los datos ascendentes del usuario final tendrá que ser retrasada o ser desechada.

El uso del canal ascendente cambia durante el día pues diversos usuarios tienen una oportunidad de utilizar su módem de cable, así que es importante monitorear el uso del flujo ascendente durante los tiempos más ocupados del día bastante que en el tiempo de uso bajo.

Las maneras de aliviar la congestión ascendente incluyen:

  • Reduciendo el número de Cable módems por la conexión en sentido ascendente – si hay demasiado Cable módems conectado con una conexión en sentido ascendente determinada, o si los usuarios en una conexión en sentido ascendente determinada son usuarios habituales del ancho de banda ascendente, la mejor solución es mover a algunos usuarios en el puerto ascendente congestionado a un puerto ascendente usado inferior, o a un puerto ascendente totalmente nuevo. Esto es lograda típicamente moviendo un nodo de fibra a partir de un grupo que combina por aguas arriba a otro, o partiendo a un grupo que combina por aguas arriba en dos grupos que combinan separados. Para más información, refiérase a cuál es la cantidad máxima de usuario por el CMTS.

  • Aumentando el ancho de canal ascendente – Esto implica un análisis riguroso y completo del espectro ascendente para encontrar una de par en par bastante banda con las características adecuadas de la relación señal-ruido (SNR) para soportar el ancho del canal creciente. El ancho de canal ascendente no se debe cambiar sin las hojas de operación (planning) cuidadosas porque este cambio potencialmente puede afectar a los otros servicios en el sistema de cable del usuario. El ancho de canal ascendente se puede cambiar usando el <new-channel-width> por aguas arriba del ancho del canal del cable Z del comando cable interface donde está el número del puerto ascendente Z y el nuevo ancho del canal es uno de 200000, 400000, 800000, 1600000 (el valor por defecto) o 3200000. A continuación, se presenta un ejemplo:

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

    Vea la guía de referencia de comandos del cable del ancho de banda de Cisco para más información sobre el comando show interface cable upstream.

  • Cambiando el esquema por aguas arriba de la modulación digital a la modulación por amplitud 16-Quadrature (QAM) – de nuevo, esto requiere un análisis riguroso y completo del espectro ascendente para verificar si haya una banda de frecuencia en el disponible por aguas arriba que puede soportar la modulación 16-QAM. Si este análisis no se realiza correctamente, hay un riesgo que el funcionamiento está disminuido más a fondo o una interrupción ascendente completa puede ocurrir. 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 del cable del ancho de banda de Cisco para más información sobre el perfil de modulación y los comandos cable upstream modulation-profile del cable. Vea también Configuración de los perfiles de modulación de cable en los Sistemas de terminación del cablemódem de Cisco.

  • Reduciendo el rendimiento de procesamiento ascendente permitido por el módem de cable – Reduciendo la conexión en sentido ascendente máxima transmita la tarifa en los archivos de configuración de DOCSIS apropiados, los usuarios del módem de cable no pueden transmitir en como alto una tarifa en la dirección ascendente y se alivia la congestión ascendente. El aspecto negativo de esta línea de acción es que limitan a los usuarios del módem de cable a una clase del servicio más lenta. Vea los archivos de configuración del DOCSIS 1.0 del edificio usando el Cisco DOCSIS Configurator (clientes registrados solamente).

Nota: Las medidas discutidas en esta sección no aumentan perceptiblemente el funcionamiento ya de un sistema no 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. No obstante, más usuarios comparten típicamente un canal descendente que cualquier solo canal ascendente, así que si el canal descendente se congestiona, a todos los usuarios conectados con el rendimiento reducido rio abajo de la experiencia del segmento.

La tabla siguiente muestra el ancho de banda descendente disponible total asociado a los cuatro esquemas posibles del modulador en sentido 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 de norteamericano del 256-QAM 38 Mbps
64-QAM Euro DOCSIS 38 Mbps
DOCSIS del euro del 256-QAM 54 Mbps

La mayoría de los sistemas del cable DOCSIS despliega actualmente el DOCSIS norteamericano 64-QAM y por lo tanto tiene 27 Mbps disponible por el canal descendente.

El uso del canal descendente puede ser determinado publicando el comando show interface cable X/Y, donde está la interfaz del cable el X/Y del cable que es observada. 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 observar es el ancho de banda de la interfaz indicada por el parámetro de BW. En los Cisco IOS Software Release 12.1(8)EC y Posterior, este valor se ajusta automáticamente según el esquema del modulador en sentido descendente y la versión del DOCSIS que es utilizado. En las revisiones anterior que el Cisco IOS Software Release 12.1(8)EC, este valor se debe configurar manualmente usando el <bandwidth-in-kilo-bits-per-second> del ancho de banda del comando cable interface o sigue habiendo de otra manera en el valor predeterminado de 27000 kbps.

El segundo componente a observar es la carga de la transmisión según lo indicado por el parámetro txload. Este parámetro da un de 255 métrico donde 0/255 significa que ningún tráfico está fluyendo en la dirección descendente a 255/255, que significa que los datos están viajando en el rio abajo a la tarifa posible máxima (en este caso en 27000 kbps). Si este parámetro se está ejecutando constantemente en el mayor que aproximadamente 75 por ciento durante el tiempo de uso pico (por ejemplo, mayor de 191/255), los usuarios finales comienzan a experimentar un acceso a internet y una latencia más alta más lentos.

El tercer componente a observar es la velocidad de salida, que muestra el índice de rendimiento de procesamiento rio abajo de la media en los bits por segundo. Si este número excede constantemente el aproximadamente 75 por ciento del ancho de banda descendente disponible durante el tiempo de uso pico, los usuarios finales comienzan a experimentar un acceso a internet y una latencia más alta más lentos.

Por abandono, estas estadísticas se calculan sobre un promedio fluctuante de cinco minutos. (Refiera a entender la definición de bits por segundo (los dígitos por segundo) del comando show interfaces hecho salir para los detalles de cómo se calcula la media.) El período sobre el cual se calcula esta media se puede reducir a tan poco como 30 segundos publicando el carga-intervalo 30 del comando cable interface. Bajando este período a 30 segundos, un más exacto un valor actualizado se calcula para cada uno de los parámetros discutidos en esta sección.

El uso del canal descendente cambia durante el día pues diversos usuarios tienen una oportunidad de utilizar su módem de cable, así que es importante monitorear el uso descendente durante los tiempos más ocupados del día bastante que en el tiempo de uso bajo.

Las formas de aliviar la congestión ascendente incluyen:

  • Reduciendo el número de Cable módems por rio abajo – si hay demasiado Cable módems conectado con un flujo descendente particular, o si los usuarios en un flujo descendente particular son usuarios habituales del ancho de banda descendente, después la mejor solución es mover a algunos usuarios en el canal descendente congestionado a otro canal descendente. Esto es lograda típicamente partiendo un grupo de nodos de fibra rio abajo asociados al rio abajo en dos grupos separados y asignando cada uno de los nuevos grupos separe los canales descendentes. Refiérase a cuál es la cantidad máxima de usuario por el CMTS.

  • Cambiando el esquema rio abajo de la modulación digital al 256-QAM – esta acción requiere un análisis riguroso y completo del espectro descendente para verificar si el sistema pueda soportar una señal del 256-QAM. Si este análisis no se realiza correctamente, hay un riesgo que el funcionamiento será disminuido más a fondo o una interrupción descendente completa puede ocurrir. El esquema del modulador en sentido descendente puede ser cambiado publicando el comando cable interface según lo considerado abajo.

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

    Vea la guía de referencia de comandos del cable del ancho de banda de Cisco para más información sobre el comando cable downstream modulation.

  • Reduciendo la producción rio abajo permitida por el módem de cable – reduciendo el descendente máximo transmita la tarifa en los archivos de configuración de DOCSIS apropiados, los usuarios del módem de cable no pueden descargar en como alto una tarifa en la dirección descendente y se alivia la congestión descendente. El aspecto negativo de esta línea de acción es que limitan a los usuarios del módem de cable a una clase del servicio más lenta. Refiera a los archivos de configuración del DOCSIS 1.0 del edificio usando el Cisco DOCSIS Configurator (clientes registrados solamente).

    Nota: Las medidas discutidas en esta sección no aumentan perceptiblemente el funcionamiento ya de un sistema no congestionado.

Congestión de Internet o de la red de retroceso

En algunos casos, los problemas de rendimiento pueden no ser un resultado de los problemas en la planta de cable o el CMTS, pero se pueden relacionar con la congestión o los problemas en la red de retroceso que las aplicaciones CMTS de conectar con Internet, o dentro de las partes de Internet sí mismo.

La manera más fácil de determinar si la congestión de red de retroceso es un problema es conectar un puesto de trabajo con el mismo segmento de red que el CMTS e intentar hojear los mismos Web site que los usuarios finales detrás del Cable módems están intentando alcanzar. Si el funcionamiento es todavía lento, hay un problema de rendimiento en la red no relacionada con el CMTS o el segmento del cable. Si el funcionamiento del segmento de red local CMTS es perceptiblemente mejor que para los usuarios conectados con el Cable módems, después esfuerzos del foco detrás en el CMTS y el segmento del cable.

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

Figura 3

En la red antedicha, si el server1, que está conectado con el mismo segmento de red que el CMTS, está consiguiendo el rendimiento lento al hojear Internet, después la fuente del problema no es el CMTS. En lugar, el embotellamiento o el problema de rendimiento en algún otro lugar. Para determinar donde está el problema, las pruebas de rendimiento se realizan entre el server1 y los otros servidores dentro de la red de Proveedor de servicios de Internet (ISP) y los Internetes públicas.

Interferencia y errores en la planta de cable

Si hay una cantidad excesiva de ruido o de ingreso en un sistema de cable, después los paquetes entre el Cable módems y el CMTS pueden ser corrompidos y ser perdidos. Esto puede conducir a una degradación significativa del funcionamiento.

Independientemente de una degradación en el funcionamiento y la producción, algunos de los indicadores primeros del ruido o los problemas del Radiofrecuencia (RF) incluyen:

  • Cable módems que cae esporádico off-liné o que consigue pegado en el init(r1) o init(r2) estados.

  • Un punto bajo estimaba el SNR como se ve en la salida de una conexión en sentido ascendente Z del X/Y del cable del regulador de la demostración, donde está la interfaz del cable el X/Y del cable que es observada y Z es el puerto ascendente que es observado. La especificación de DOCSIS requiere un relación portadora-ruido (CNR) por lo menos de DB 25 para todas las señales por aguas arriba. Esto equivale a un SNR de aproximadamente 29 dB. Cisco CMTS puede detectar coherente las señales por aguas arriba QPSK en niveles mucho peores del SNR, no obstante todos los proveedores de servicio de cable deben esforzarse cumplir los requisitos de DOCSIS CNR en su sistema. Una salida por aguas arriba del X/Y Z del cable del regulador de la demostración de la muestra se muestra abajo.

    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, estimado lectura de SNR es 28.628dB. Esto es adecuado para la operación de flujo ascendente QPSK. Observe que la figura del SNR dada en la salida de este comando es solamente una estimación y no es ningún substituto para una figura del SNR derivada del analizador de espectro o del otro equipo de prueba apropiado. Vea la guía de referencia de comandos del cable del ancho de banda de Cisco para más información sobre el comando show controllers cable upstream spectrum.

  • Un número rápidamente que incrementa de la corrección de errores de reenvío de Corr (FEC) y errores 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. Una salida de muestra del comando show cable hop se muestra abajo.

    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 del paquete debida divulgar. 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 del cable del ancho de banda de Cisco para más información sobre el comando show cable hop.

  • Un número alto de eventos del “flap” en la salida de un comando show cable flap-list. Las estadísticas del flap más en relación con los problemas posibles RF o de ruido son la Columna de omisiones, que indica los pedidos de medición faltados, y el columna P-Adj, que indica los niveles de potencia por aguas arriba rápidamente diversos. Una salida de muestra del comando show cable flap-list se muestra abajo.

    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 
  • ¡El visualizar del Cable módems “* “o “! ---” en la salida de un comando show cable modem o show cable flap-list. “*” indica un módem de cable que esté variando rápidamente sus niveles de potencia por aguas arriba. Esto es indicativo de una mala conexión a la planta de cable, a un amplificador de trayecto inverso defectuoso, o a la atenuación debido rápidamente cambiante de la planta de cable a la temperatura o a otros efectos del entorno. ¡“! ---” indica un módem de cable que ha alcanzado su nivel de potencia por aguas arriba máximo. Esto es indicativo de demasiada atenuación entre el módem de cable y el CMTS, o de una mala conexión entre el módem de cable 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 módem de cable con la dirección MAC 005a.73f6.2213 está transmitiendo en sus energías de salida máxima. Esto da lugar a ese módem que no puede transmitir en el nivel correcto. Por lo tanto, las transmisiones ascendentes de este módem no se oyen 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. Vea la guía de referencia de comandos del cable del ancho de banda de Cisco para más información sobre el módem de cable y los comandos show cable flap-list de la demostración.

Nota: Más detalles sobre la identificación y la resolución de los problemas de ruido RF pueden ser encontrados en determinar el RF o los problemas de configuración en el CMTS y la conexión del Cisco uBR7200 Series Router con la cabecera del cable.

CPU elevada uso en el CMTS

En algunas circunstancias Cisco CMTS puede convertirse en sobrecargado debido a una configuración subóptima, sobre el uso de ciertas funciones de administración, o mismo un número alto de paquetes que son ruteados por el CMTS.

La mejor manera de determinar el USO de la CPU de un Cisco CMTS es ejecutar el comando show process cpu. El USO de la CPU actual se indica en la primera línea de la salida 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 CPU del proceso de la demostración es útil para determinar si una proceso o función determinado es la causa de alto CMTS CPU.

uBR7246-VXR# show process cpu 
CPU utilization for five seconds: 45%/21%; one minute: 45%; five minutes: 31% 
 PID  Runtime(ms)  Invoked  uSecs    5Sec   1Min   5Min TTY Process 
   1          12      9220      1   0.00%  0.00%  0.00%   0 Load Meter 
   2       69816  18276677      3  21.79% 22.10%  9.58%   2 Virtual Exec 
   3       36368      5556   6545   0.00%  0.06%  0.05%   0 Check heaps 
   4           0         1      0   0.00%  0.00%  0.00%   0 Chunk Manager 
   5          96      1436     66   0.00%  0.00%  0.00%   0 Pool Manager 
   6           0         2      0   0.00%  0.00%  0.00%   0 Timers 
   7           0         2      0   0.00%  0.00%  0.00%   0 Serial Backgroun 
   8           0         1      0   0.00%  0.00%  0.00%   0 CMTS ping 
   9       17020    101889    167   0.00%  0.00%  0.00%   0 EnvMon 
  10           0         1      0   0.00%  0.00%  0.00%   0 OIR Handler 
  . . . . . . . 
  <snip> 
  . . . . . . . 
  89        3304     81013     40   0.00%  0.00%  0.00%   0 PIM Process 
  90          12       769     15   0.00%  0.00%  0.00%   0 CEF Scanner 
  92           0       385      0   0.00%  0.00%  0.00%   0 DHCPD Timer 
  93          40     13058      3   0.00%  0.00%  0.00%   0 DHCPD Database

En el ejemplo anterior, la corriente carga de la CPU en el CMTS es el 45 por ciento percent/21. Esto significa que el USO de la CPU total está en el 45 por ciento de la capacidad del sistema. Además el 21 por ciento del CPU se está utilizando para mantener las 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 de cinco minutos es constantemente el más de 80 por ciento durante el tiempo de uso pico en el sistema, después los usuarios finales pueden comenzar a experimentar un funcionamiento y una mayor latencia más lentos. Si el USO de la CPU de cinco minutos es constantemente el más de 95 por ciento durante el tiempo de uso pico, después tome la acción urgente para asegurarse de que el CMTS permanece en un estado estable.

Las estrategias comunes para reducir CPU elevada el uso en el CMTS incluyen:

  • El actualizar al Cisco IOS Software Release 12.1(9)EC o Posterior, activar el cef del comando de configuración global ip, y no aseegurar ninguna interfaz en el CMTS tienen el comando no ip route-cache configurado. Esto lleva típicamente a un 10 por ciento al 15 por ciento de reducción en el USO de la CPU tráfico-relacionado. Asegúrese de que todos estos pasos se realicen de manera conjunta.

  • El aseegurarse ese las estaciones de administración del Simple Network Management Protocol (SNMP) no está siendo demasiado agresivo en sondear el CMTS. Esto lleva CPU elevada a un uso en el proceso IP SNMP.

  • No ejecute el comando show tech varias veces sucesivamente. Esto lleva artificial CPU elevada a un uso en el proceso de EXEC virtual.

  • El aseegurarse ese los comandos no debug se está ejecutando en el CMTS.

Para más información sobre CPU elevada el uso en los routeres Cisco, incluyendo los productos CMTS de Cisco, refiera a localizar averías CPU elevada la utilización en los routeres 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 solamente uno o los pocos usuarios está experimentando la producción lenta, y el resto de la población de usuarios no está experimentando ningún problema, después esto es un indicio sólido que puede haber un problema exclusivo dentro del ese entorno de usuario.

  • Bajo el CPE accionado o sobrecargado — Si el quejarse de los usuarios finales de las dificultades está utilizando el equipo CPE anticuado, o el equipo que puede no ser bastante potente funcionar con su sistema operativo o software elegido del acceso a internet, después este usuario final tendrá dificultades. La única solución, si este es el caso, es que el usuario final actualice el equipamiento CPE.

  • Software del Firewall o de la medición de rendimiento — Si el usuario final está funcionando con el cualquier Firewall, la medición del rendimiento de la red, o el otro software similar, un buen paso de Troubleshooting es tener el usuario apagar este software para considerar si tiene algún efecto sobre el funcionamiento. A menudo, estos tipos de software pueden tener un impacto negativo en el funcionamiento.

  • Configuraciones mal configurado TCP/IP — La mayoría de los proveedores de servicio requieren que los usuarios finales hagan que su equipo CPE adquiera una dirección IP, una máscara de la red, un default gateway, y los servidores DNS por el Protocolo de configuración dinámica de host (DHCP). Asegúrese de que cualquier usuario final que experimenta los problemas haga sus dispositivos CPE configurar para utilizar el DHCP para adquirir todos estos parámetros.

Si un usuario final demanda no tener ningunos de los problemas enumerados arriba, después confirme que el usuario final no está excediendo su velocidad máxima de carga y descarga según las secciones arriba.

Conclusión

Una red de cable DOCSIS es un sistema sofisticado que requiere las hojas de operación (planning) y el mantenimiento apropiados. La mayoría de los problemas de rendimiento en los sistemas del cable DOCSIS son un resultado directo de las hojas de operación (planning) apropiadas y mantenimiento que no es realizado. En el mercado de acceso a Internet de hoy, donde hay una variedad de alternativas del acceso a Internet de banda ancha, es importante que los proveedores de servicio de cable abordan rápidamente cualquier problema del funcionamiento o de la congestión en su sistema antes de que los problemas lleguen a ser bastante significativos para que los usuarios finales sean afectados perceptiblemente, y, por lo tanto, consideran el medio alternativo del acceso por banda ancha.

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Información Relacionada


Document ID: 12551