Troubleshooting de Desempenho Lento com Redes de Cable Modem

Introdução

Há algumas questões que podem afetar o desempenho e a velocidade dos modems a cabo em um sistema DOCSIS (Data-over-Cable Service Interface Specifications). Este documento busca abordar as principais causas de um throughput lento das perspectiva de um provedor de serviços a cabo.

Primeiro, este documento examina como determinar com precisão que tipos de níveis de throughput um usuário final está atingindo e como garantir que o desempenho que está sendo medido seja o da rede a cabo, e não o da Internet mais ampla.

A próxima seção observa as razões potenciais mais comuns para desempenho lento e as resoluções sugeridas. Esses problemas incluem:

• O desempenho está sendo restringido pelos limites no arquivo de configuração DOCSIS.

• Desempenho de download intermitente ou inconstante causado pelo uso de um esquema de limitação de taxa abaixo do ideal no CMTS (sistema de terminação de modem a cabo).

• Congestionamento de canal upstream e downstream.

• Rede backhaul ou congestionamento da Internet.

• Ruído ou erros na planta de cabos.

• Sob o equipamento nas instalações do cliente (CPE - Customer Premises Equipment) do usuário final com alimentação.

Cada um desses itens individualmente ou em combinação pode afetar o throughput e o desempenho em uma rede a cabo.

Este documento não discute a solução de problemas de uma perda completa de conectividade na rede a cabo ou de modems a cabo que não estão on-line. Em vez disso, consulte Troubleshooting uBR Cable Modems Not Coming Online para obter esses tipos de problemas.

Antes de Começar

Pré-requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

As informações neste documento são baseadas nas versões de software e hardware abaixo.

• Software Cisco IOS® versão 12.1(9)EC para CMTS uBR7200 e uBR7100.

• O conjunto de produtos CMTS Cisco uBR7100, uBR7200 e uBR7200VXR.

• As informações neste documento são relevantes para todas as outras versões atualmente disponíveis do software Cisco IOS baseado em DOCSIS 1.0 para equipamentos CMTS da marca Cisco.

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se você estiver trabalhando em uma rede ativa, certifique-se de que entende o impacto potencial de qualquer comando antes de utilizá-lo.

Determinando com precisão os níveis de desempenho que estão sendo atingidos

Medindo as partes corretas do sistema

Existem diversas maneiras de medir a velocidade e o desempenho de um sistema, no entanto é importante entender exatamente quais partes do sistema estão sendo testados. Considere o diagrama a seguir.

Figura 1 (Para ver este diagrama em formato de vídeo, clique aqui.)

Nesse diagrama há diversos componentes:

• A rede Hybrid Fiber Coax entre o usuário final e o CMTS.

• O segmento de rede CMTS local onde o CMTS se conecta à rede do provedor de serviços a cabo.

• A rede interna do provedor de serviços a cabo.

• A Internet pública.

Ao executar um teste de velocidade entre dois pontos, a velocidade de todos os componentes da rede entre os dois pontos está sendo medida.

Por exemplo, se for realizado um teste de velocidade entre o CPE e o Servidor 3, que está conectado à Internet através de uma linha ISDN de 128 Kbps, nunca haverá velocidades superiores a 128 Kbps, mesmo que a largura de banda disponível no segmento de cabo seja superior a 128 Kbps.

A maneira mais precisa de medir o desempenho do próprio segmento de cabo é executar um teste de velocidade entre o CPE e o Servidor 1, que está conectado ao mesmo segmento de rede que o CMTS. Isso ocorre porque o único caminho pelo qual os dados precisam trafegar é o segmento do cabo coaxial. Os dados também devem trafegar pelo segmento de rede CMTS local, mas presume-se que esse segmento tenha uma largura de banda alta (FastEthernet ou maior) e não tenha um alto nível de congestionamento.

Se, por algum motivo, nenhum servidor puder ser conectado ao segmento de rede CMTS local, a próxima maneira mais precisa de testar o desempenho do segmento de cabo será executar um teste de velocidade entre o CPE e o Servidor 2. Essa é uma medida precisa, desde que haja links adequadamente de alta velocidade e sem congestionamento na rede interna do provedor de serviços a cabo entre o CMTS e o CPE.

A maneira mais imprecisa de determinar o desempenho do segmento de cabo é executar um teste de velocidade entre o CPE e um servidor na Internet pública. Isso ocorre porque pode haver links congestionados na Internet pública entre o CPE e o servidor ou porque pode haver links de velocidades muito baixas no caminho entre o CPE e o servidor na Internet.

Determinando a taxa de download e upload

É muito importante poder obter uma medição objetiva e exata dos níveis de throughput de upload e download que estão sendo atingidos antes de tirar quaisquer conclusões sobre a existência de um problema de desempenho em um sistema DOCSIS.

A maneira mais fácil de determinar a velocidade na qual os carregamentos e downloads estão ocorrendo é carregar ou baixar um arquivo grande usando FTP ou HTTP entre um dispositivo CPE conectado a um modem a cabo e um servidor atrás do CMTS. A maioria dos clientes FTP e HTTP é capaz de exibir a velocidade na qual um download ou um upload está ocorrendo durante a transferência ou quando a transferência é concluída. A velocidade de transferência vista como resultado da operação de FTP ou HTTP é geralmente cerca de 90 por cento do throughput total real atingido. Isso ocorre porque a velocidade de transferência de FTP ou HTTP exibida não leva em conta a sobrecarga adicional de IP e DOCSIS que precisa viajar entre o dispositivo CPE e o CMTS.

Existem métodos mais precisos para medir o throughput, por exemplo, usando equipamentos de teste dedicados de terceiros, como um Netcom Smartbits ou um gerador de pacotes IXIA, mas esses sistemas nem sempre estão prontamente disponíveis ou facilmente conectados a uma rede de cabos de produção. É importante observar que, se os testes de throughput estiverem sendo realizados em um ambiente de laboratório, o uso de um dispositivo dedicado revelará muito mais informações do que o simples teste de download por FTP ou HTTP.

Observação: o teste de upload e download baseado em FTP ou HTTP é confiável apenas para velocidades de teste de cerca de 3 Mbps ou menos. Em velocidades mais altas, a potência de processamento do dispositivo CPE, servidor ou placas de interface de rede (NICs) podem se tornar um fator limitante no teste. Para velocidades de teste superiores a 3 Mbps, deve ser usado equipamento dedicado de teste de rendimento de dados.

No exemplo a seguir, um teste simples de download e upload de FTP é realizado entre um dispositivo CPE conectado a um modem a cabo e um servidor FTP na rede do provedor de serviços a cabo. O modem a cabo fez o download de um arquivo de configuração DOCSIS que permite uma velocidade de download de até 256 Kbps e uma velocidade de upload de até 64 Kbps. Neste teste, um arquivo de 3 Mb foi colocado no servidor FTP no endereço IP 172.17.110.132. O usuário do dispositivo CPE recebe um nome de usuário e uma senha para poder fazer login no servidor FTP e poder baixar esse arquivo do servidor FTP e depois carregá-lo de volta no servidor FTP. O utilitário de FTP da linha de comando é utilizado para executar a transferência. Esse utilitário está disponível em praticamente todas as versões do Microsoft Windows e UNIX.

Um teste semelhante é realizado tendo um servidor Web HTTP configurado na rede do provedor de serviços e executando um download 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.

Enquanto a transferência de FTP estiver ocorrendo, é possível monitorar o progresso do teste no CMTS usando o comando show interface cable X/Y sid Z counters, onde cable X/Y é a interface de cabo à qual o modem em teste está conectado, e Z é o número de ID de serviço (SID) do modem em teste. Esse comando mostra quantos bytes estão sendo transferidos de ou para um determinado modem a cabo. Por exemplo, se o CPE que está sendo testado estiver atrás de um modem a cabo com endereço MAC 0001.9659.4461.

Primeiro, localize o número SID do modem que está sendo testado usando o comando show cable modem. Nesse caso o SID do modem a cabo é 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

Enquanto o download ou o carregamento estiver em andamento, limpe todos os contadores de pacotes no CMTS de volta a zero usando o comando clear counters. Exatamente quando os contadores forem zerados, inicie um cronômetro ou 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.

Após o cronômetro ou o tempo ler exatamente um minuto, execute o comando show interface cable X/Y sid Z counters. Talvez seja melhor digitar o comando primeiro e depois pressionar Enter exatamente quando o temporizador indicar um minuto. O ensaio pode ser efetuado durante um período mais longo ou mais curto. Quanto mais longo o período de teste, mais preciso o resultado; entretanto, certifique-se de que o download ou upload não termine antes que o temporizador do cronômetro atinja o tempo especificado, caso contrário, a medição é imprecisa.

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# 

Nesse caso, a velocidade de download está sendo testada. A saída do comando show interface cable X/Y sid Z counter indica que durante um período de um minuto, 1.921.488 bytes é baixado pelo modem a cabo. A conversão de 1.921.488 bytes em bits revela:

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

Em seguida, para encontrar a taxa de download em bits por segundo, divida esse número total de bits baixados pelo tempo que leva para baixá-los em segundos.

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

A taxa de download neste exemplo é mostrada como sendo de aproximadamente 256 Kbps, que é a taxa de download permitida para o modem a cabo em teste.

Para examinar a velocidade de upload usando o comando show interface cable X/Y sid Z counters, a coluna Inoctets deve ser usada para determinar o número de bytes enviados na direção de upstream do modem a cabo.

Consulte o Cisco Broadband Cable Command Reference Guide para obter mais informações sobre o comando show interface cable sid counters.

Possíveis razões para um desempenho ruim

Desempenho restrito pelo arquivo de configuração DOCSIS

A primeira informação que precisa ser coletada durante a solução de problemas de desempenho de modem a cabo lento é a classe prescrita de limitações de throughput de serviço do modem a cabo. Quando um modem a cabo fica on-line, ele baixa um arquivo de configuração DOCSIS que contém limites operacionais para o modem a cabo, incluindo as taxas máximas de upload e download. Em circunstâncias normais, o modem a cabo não pode exceder essas taxas.

Inicialmente, é necessário identificar o endereço MAC de um modem a cabo com problemas. Utilizando um modem com endereço MAC 0050.7366.2223 que esteja tendo problemas com throughput lento,. é necessário descobrir que classe de perfil de serviço esse modem a cabo está usando, executando o comando show cable modem <mac-address> conforme visto no exemplo abaixo.

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

Aqui ele mostra que esse modem a cabo tem um perfil de Qualidade de Serviço (QoS) de 5. Para descobrir a que taxas de downstream e upstream esse perfil de QoS corresponde, use o comando show cable qos profile profile-number , onde profile-number é o perfil de QoS de interesse.

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

Aqui, ele mostra que o perfil de QoS 5 corresponde a um serviço que fornece 256 Kbps no downstream e 64 Kbps é no upstream. Qualquer CPE conectado a modems a cabo usando o perfil de QoS 5 não pode exceder esses limites. As configurações do perfil de QoS são determinadas pelo conteúdo dos arquivos de configuração DOCSIS baixados por modems a cabo do servidor TFTP do sistema de provisionamento, portanto, o perfil de QoS 5 no sistema pode não ser o mesmo que o perfil de QoS 5 no exemplo mostrado acima.

Se o desempenho de download e upload de um usuário final estiver correlacionado com os limites mostrados em seu perfil de QoS, ele estará obtendo a classe de serviço e os níveis de throughput para os quais o modem a cabo foi provisionado e configurado. A única maneira de aumentar o throughput de upload e download é alterar o arquivo de configuração DOCSIS que está sendo baixado pelo modem a cabo para um que tenha limites de throughput mais altos. Consulte o documento Building DOCSIS 1.0 Configuration Files Using Cisco DOCSIS Configurator para obter instruções detalhadas sobre como criar ou modificar um arquivo de configuração DOCSIS.

Utilizando um método sub-otimizado para taxa limite

Quando um usuário final está tentando baixar dados da Internet a uma taxa maior do que a permitida pelo arquivo de configuração DOCSIS do modem a cabo, o CMTS deve limitar a taxa do tráfego que está sendo enviado a esse usuário para garantir que o usuário não consuma mais do que o compartilhamento permitido de largura de banda.

Da mesma forma, quando um usuário final tenta carregar ou enviar dados para a Internet a uma taxa maior do que a permitida pelo arquivo de configuração DOCSIS, o próprio modem a cabo deve impedir que o tráfego em excesso viaje pelo segmento de cabo para o CMTS. Se o modem a cabo, por algum motivo, não conseguir executar corretamente a limitação de taxa de upstream, o CMTS explicitamente proíbe que o modem a cabo transmita uma taxa maior que a permitida. Esse comportamento no CMTS é garantir que até mesmo um modem a cabo com características "hackeadas" não consiga subverter os limites de taxa de upload atribuídos ao provedor de serviços.

O esquema de limitação de taxa padrão usado pelo CMTS monitora a taxa de tráfego de e para cada modem a cabo em cada período de um segundo. Se o modem a cabo enviar ou receber mais de sua cota por segundo em menos de um segundo, o CMTS não permitirá que mais tráfego flua para esse modem a cabo pelo resto do segundo.

Como exemplo, pegue um modem a cabo com um perfil de QoS que permita uma taxa de download de 512 Kbps. Se o modem a cabo fizer download de 512 kilobits (64 kilobytes) no primeiro semestre de um segundo, o modem a cabo não poderá fazer download de nada no próximo semestre. Esse tipo de taxa que limita o comportamento pode ter o efeito de um padrão de download intermitente que parece parar e recomeçar a cada um ou dois segundos.

O melhor esquema de limitação de taxa downstream a ser usado é o algoritmo de limitação de taxa de token bucket com modelagem de tráfego. Esse esquema de limitação de taxa foi otimizado para permitir uma experiência de navegação na Web tranquila a uma taxa constante, ao mesmo tempo em que garante que os usuários finais não possam exceder a taxa de download prescrita, conforme especificado no arquivo de configuração DOCSIS.

A forma como esse esquema funciona é medir a taxa na qual um modem a cabo está baixando ou carregando dados cada vez que um pacote é enviado de ou para o modem a cabo. Se o envio ou o recebimento do pacote em questão fizer com que o modem exceda suas taxas de transferência permitidas, o pacote será colocado em buffer ou em cache na memória CMTS até que o CMTS possa enviar o pacote sem exceder o limite de largura de banda de downstream.

Observação: se a taxa de tráfego de downstream exceder consistentemente a taxa de downstream permitida para o modem a cabo, os pacotes serão eventualmente descartados.

Ao usar esse método mais suave de limitação e modelagem de taxa, a maioria das aplicações da Internet baseadas em TCP, como navegação na Web HTTP e transferências de arquivos FTP, opera de forma mais suave e eficiente do que ao usar o esquema padrão de limitação de taxa.

O esquema token-bucket rate-limit-with-traffic-shaping pode ser ativado no caminho de downstream em uma interface de cabo emitindo o seguinte comando de configuração de interface de cabo:

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

Observação: é altamente recomendável habilitar a modelagem de token bucket no CMTS do usuário. Esse comando é suportado a partir das versões 12.0(5)T1 e 12.1(1)EC1 do software Cisco IOS.

O token bucket com esquema de modelagem de tráfego também pode ser aplicado a portas upstream, mas como é responsabilidade dos modems a cabo executar a limitação de taxa upstream, o esquema de limitação de taxa upstream aplicado ao CMTS normalmente não terá nenhum impacto no desempenho de um sistema.

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

Consulte o Guia de Referência de Comandos de Cabo de Banda Larga da Cisco para obter mais informações sobre os comandos cable downstream rate-limit e cable upstream rate-limit .

Os usuários podem ver o quão severamente o CMTS está limitando a taxa de tráfego para um modem a cabo específico usando o comando show interface cable X/Y sid <Z>counters, onde cable X/Y é a interface de cabo à qual o modem a cabo está conectado, e Z é o número SID do modem sendo observado. Este comando mostra o número de vezes que o CMTS descartou um pacote downstream ou não permitiu um pacote upstream porque o modem excedeu seus limites de throughput permitidos. Se nenhum valor for especificado para Z, as informações de contador para todos os modems a cabo conectados ao cabo de interface X/Y serão exibidas.

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

O campo Ratelimit DSPktDrop mostra quantas vezes o CMTS descartou pacotes destinados ao modem a cabo devido à tentativa do modem de exceder seu throughput de downstream permitido.

O campo Ratelimit BWReqDrop mostra quantas vezes o CMTS se recusou a permitir que um modem a cabo enviasse um pacote no caminho de upstream devido à tentativa do modem de exceder seu throughput de upstream permitido. Na maioria das circunstâncias, esse contador deve sempre permanecer em 0. Se ele aumentar significativamente acima de zero, pode ser que o modem a cabo observado não esteja executando corretamente a limitação de taxa de upstream.

Observação: os valores exibidos pelo comando show interface cable X/Y sid Z counters podem ser redefinidos como zero emitindo o comando clear counters, conforme visto no exemplo abaixo.

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 o Cisco Broadband Cable Command Reference Guide para obter mais informações sobre o comando show interface cable sid counters.

Congestionamento de canal upstream

O canal upstream é normalmente o recurso mais precioso em um sistema de cabo. Atualmente, a maioria dos provedores de serviços a cabo usa uma largura de canal de 1,6 MHz e modulação de Chaveamento de Fase de Quadratura (QPSK - Quadrature Phase Shift Keying) no caminho upstream. Isso equivale a aproximadamente 2.5 Mbps em largura de banda de upstream total disponível para todos os usuários conectados ao canal de upstream em questão. É importante garantir que o canal de upstream não se torne excessivamente usado ou congestionado, caso contrário, todos os usuários nesse segmento de upstream sofrerão desempenho ruim.

O uso de upstream para uma porta de upstream específica pode ser obtido executando o comando CMTS show interface cable X/Y upstream <Z>, onde cable X/Y é o número da interface de downstream e Z é o número da porta de upstream. Se Z for omitido, serão exibidas informações sobre todos os upstream no cabo de interface X/Y. Consulte o Cisco Broadband Cable Command Reference Guide para obter mais informações sobre o 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

Na porta upstream vista no exemplo, o uso de upstream é atualmente de 18 por cento e há 359 modems conectados a este upstream.

Se o uso do canal upstream é consistentemente acima de 75 por cento durante o horário de pico de uso, os usuários finais começam a sofrer problemas como latência, tempos de "ping" mais lentos e uma experiência de Internet geralmente mais lenta. Se o uso do canal de upstream estiver constantemente acima de 90 por cento durante o horário de pico de uso, os usuários finais experimentam um nível de serviço extremamente baixo porque uma grande parte dos dados de upstream do usuário final terá que ser atrasada ou descartada.

O uso do canal upstream muda durante o dia à medida que diferentes usuários têm a oportunidade de usar seu modem a cabo, por isso é importante monitorar o uso upstream durante os horários mais ocupados do dia, em vez de em horários de baixo uso.

As maneiras de aliviar o congestionamento upstream incluem:

• Redução do número de modems a cabo por upstream - Se houver muitos modems a cabo conectados a um upstream específico, ou se os usuários em um upstream específico forem usuários intensos de largura de banda de upstream, a melhor solução é mover alguns usuários na porta de upstream congestionada para uma porta de upstream subutilizada ou para uma porta de upstream completamente nova. Isso é normalmente realizado movendo um nó de fibra de um grupo de combinação upstream para outro, ou dividindo um grupo de combinação upstream em dois grupos de combinação separados. Para obter mais informações, consulte Qual é o número máximo de usuários por CMTS.

• Aumentar a largura de canal upstream - Isso envolve uma análise rigorosa e completa do espectro upstream para encontrar uma banda larga o suficiente com características adequadas de Signal-to-Noise Ratio (SNR) para suportar o aumento da largura de canal. A largura do canal upstream não deve ser alterada sem um planejamento cuidadoso, pois essa alteração pode afetar outros serviços no sistema a cabo do usuário. A largura do canal de upstream pode ser alterada usando o comando de interface de cabo cable upstream Z channel-width <new-channel-width> onde Z é o número da porta de upstream e a nova largura do canal é uma das 200000, 400000, 800000, 1600000 (o padrão) ou 3200000. Um exemplo a seguir.

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

  Consulte o Cisco Broadband Cable Command Reference Guide para obter mais informações sobre o comando show interface cable upstream.

• Alterar o esquema de modulação digital upstream para a Modulação de Amplitude de Quadratura (QAM - 16-Quadrature Amplitude Modulation) - Mais uma vez, isso requer uma análise rigorosa e completa do espectro upstream para verificar se há uma banda de frequência no upstream disponível que possa suportar a modulação 16-QAM. Se essa análise não for executada corretamente, há o risco de o desempenho ser reduzido ainda mais ou de ocorrer uma paralisação completa de upstream. É possível alterar o esquema de modulação upstream criando um perfil de modulação upstream que use a modulação 16-QAM e aplicando-a a uma porta upstream. Um exemplo a seguir.

  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 o Guia de Referência de Comandos de Cabo de Banda Larga da Cisco para obter mais informações sobre os comandos cable modulation-profile e cable upstream modulation-profile . Consulte também Configurando os perfis de modulação do cabo em Sistemas de terminação de modem a cabo da Cisco.

• Redução do throughput de upstream permitido por modem a cabo - Reduzindo a taxa máxima de transmissão de upstream nos arquivos de configuração DOCSIS apropriados, os usuários de modem a cabo não podem transmitir a uma taxa tão alta na direção de upstream e o congestionamento de upstream é aliviado. O aspecto negativo desse curso de ação é que os usuários de modem a cabo estão limitados a uma classe de serviço mais lenta. Consulte Building DOCSIS 1.0 Configuration Files Using Cisco DOCSIS Configurator.

Observação: as medidas discutidas nesta seção não aumentam significativamente o desempenho de um sistema já descongestionado.

Congestionamento de canal downstream

O canal downstream possui uma quantidade significativamente maior de largura de banda para compartilhar do que um canal upstream individual, por isso, o downstream não está tão sujeito a congestionamentos como o upstream. Ainda assim, mais usuários normalmente compartilham um canal downstream do que qualquer canal upstream único, portanto, se o canal downstream ficar congestionado, todos os usuários conectados ao segmento downstream experimentarão um desempenho reduzido.

A tabela a seguir mostra a largura de banda downstream total disponível associada aos quatro esquemas de modulação downstream possíveis disponíveis em sistemas DOCSIS.

Esquema de modulação de downstream	Largura de Banda Downstream Disponível
DOCSIS norte-americano 64-QAM	27 Mbps
DOCSIS norte-americano 256-QAM	38 Mbps
64-QAM Euro DOCSIS	38 Mbps
256-QAM Euro DOCSIS	54 Mbps

A maioria dos sistemas de cabo DOCSIS atualmente implanta o DOCSIS norte-americano 64-QAM e, portanto, tem 27 Mbps disponíveis por canal downstream.

O uso do canal downstream pode ser determinado pela emissão do comando show interface cable X/Y, onde cable X/Y é a interface de cabo sendo observada. A taxa de saída exibida, em bits por segundo, deve ser comparada à largura de banda de downstream disponível, conforme mostrado na tabela acima.

No exemplo a seguir, uma interface que usa DOCSIS norte-americano e modulação digital de 64-QAM é analisada.

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

O primeiro componente dessa saída a ser observado é a largura de banda da interface indicada pelo parâmetro BW. Nos Cisco IOS Software Releases 12.1(8)EC e posteriores, esse valor é ajustado automaticamente de acordo com o esquema de modulação de downstream e a versão do DOCSIS que está sendo usada. Em revisões anteriores ao Cisco IOS Software Release 12.1(8)EC, esse valor deve ser configurado manualmente usando o comando cable interface bandwidth <bandwidth-in-kilo-bits-per-second> ou permanecer no valor padrão de 27000 Kbps.

O segundo componente a ser observado é a carga de transmissão conforme indicado pelo parâmetro txload. Esse parâmetro fornece uma métrica de 255 onde 0/255 significa que nenhum tráfego está fluindo no sentido downstream para 255/255, o que significa que os dados estão viajando no downstream na taxa máxima possível (neste caso a 27000 Kbps). Se esse parâmetro estiver sendo executado consistentemente em mais de aproximadamente 75 por cento durante o horário de pico de uso (por exemplo, maior que 191/255), os usuários finais começarão a experimentar acesso mais lento à Internet e maior latência.

O terceiro componente a ser observado é a taxa de saída, que mostra a taxa média de throughput de downstream em bits por segundo. Se esse número exceder consistentemente aproximadamente 75 por cento da largura de banda downstream disponível durante o horário de pico de uso, os usuários finais começarão a experimentar acesso mais lento à Internet e maior latência.

Por padrão, essas estatísticas são calculadas sobre uma média móvel de cinco minutos. Consulte Entendendo a Definição de bits por segundo (bits/s) da Saída do Comando show interfaces para obter detalhes sobre como a média é calculada. O período sobre o qual essa média é calculada pode ser reduzido para apenas 30 segundos, emitindo o comando cable interface load-interval 30. Ao reduzir esse período para 30 segundos, um valor mais preciso e atualizado é calculado para cada um dos parâmetros discutidos nesta seção.

O uso do canal downstream muda durante o dia à medida que diferentes usuários têm a oportunidade de usar seu modem a cabo, por isso é importante monitorar o uso downstream durante os horários mais ocupados do dia, em vez de em horários de baixo uso.

As formas de aliviar o congestionamento de downstream incluem:

• Redução do número de modems a cabo por downstream - Se houver muitos modems a cabo conectados a um downstream específico, ou se os usuários em um downstream específico forem usuários intensos de largura de banda downstream, a melhor solução será mover alguns usuários no canal downstream congestionado para outro canal downstream. Isso normalmente é feito dividindo-se um grupo de nós de fibra downstream associados ao downstream em dois grupos separados e atribuindo-se cada um dos novos grupos a canais downstream separados. Consulte Qual é o Número Máximo de Usuários por CMTS.

• Alterando o esquema de modulação digital de downstream para 256-QAM - Essa ação requer uma análise rigorosa e completa do espectro de downstream para verificar se o sistema pode suportar um sinal 256-QAM. Se essa análise não for executada corretamente, há o risco de que o desempenho diminua ainda mais ou de que ocorra uma paralisação completa de downstream. O esquema de modulação de downstream pode ser alterado emitindo o comando cable interface, conforme ilustrado abaixo.

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

  Consulte o Guia de Referência de Comandos de Cabo de Banda Larga da Cisco para obter mais informações sobre o comando cable downstream modulation.

• Redução do throughput de downstream permitido por modem a cabo - Reduzindo a taxa máxima de transmissão de downstream nos arquivos de configuração DOCSIS apropriados, os usuários de modem a cabo não podem fazer download a uma taxa tão alta na direção de downstream e o congestionamento de downstream é aliviado. O aspecto negativo desse curso de ação é que os usuários de modem a cabo estão limitados a uma classe de serviço mais lenta. Consulte Building DOCSIS 1.0 Configuration Files Using Cisco DOCSIS Configurator.

  Observação: as medidas discutidas nesta seção não aumentam significativamente o desempenho de um sistema já descongestionado.

Rede backhaul ou congestionamento da Internet

Em alguns casos, os problemas de desempenho podem não ser resultado de problemas na planta de cabos ou no CMTS, mas podem estar relacionados a congestionamento ou problemas na rede de backhaul que o CMTS usa para se conectar à Internet ou dentro de partes da própria Internet.

A maneira mais fácil de determinar se o congestionamento da rede de backhaul é um problema é conectar uma estação de trabalho ao mesmo segmento de rede que o CMTS e tentar navegar nos mesmos sites que os usuários finais atrás dos modems a cabo estão tentando acessar. Se o desempenho ainda estiver lento, há um problema de desempenho na rede não relacionado ao CMTS ou ao segmento de cabo. Se o desempenho do segmento de rede CMTS local for significativamente melhor do que para usuários conectados a modems a cabo, então concentre os esforços de volta no CMTS e no segmento de cabo.

Figure 3

Na rede acima, se o Servidor 1, que está conectado ao mesmo segmento de rede que o CMTS, estiver com desempenho lento ao navegar na Internet, a origem do problema não é o CMTS. Em vez disso, o gargalo ou problema de desempenho ocorre em outro lugar. Para determinar onde o problema está, os testes de desempenho são realizados entre o Servidor 1 e vários outros servidores dentro da rede do Provedor de serviços de Internet (ISP) e da Internet pública.

Ruído e erros na planta de cabos

Se houver uma quantidade excessiva de ruído ou ingresso em um sistema de cabo, os pacotes entre modems a cabo e o CMTS poderão ser corrompidos e perdidos. Isso pode levar a uma redução significativa no desempenho.

Além de uma degradação no desempenho e throughput, alguns dos principais indicadores de problemas de ruído ou radiofrequência (RF) incluem:

• Os modems a cabo ficam esporadicamente off-line ou ficam presos nos estados init(r1) ou init(r2).

• Um SNR estimado baixo como visto na saída de um show controller cable X/Y upstream Z, onde cable X/Y é a interface de cabo sendo observada e Z é a porta upstream sendo observada. A especificação DOCSIS requer uma relação portadora-ruído (CNR - Carrier-to-Noise Ratio) de pelo menos 25 dB para todos os sinais upstream. Isso é igual a um SNR de aproximadamente 29 dB. O Cisco CMTS é capaz de detectar coerentemente sinais de upstream QPSK em níveis de SNR muito piores, no entanto, todos os provedores de serviços a cabo devem se esforçar para atender aos requisitos de CNR DOCSIS em seus sistemas. Um exemplo de saída show controller cable X/Y upstream Z é mostrado abaixo.

  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 

  No exemplo acima, a leitura SNR estimada é 28,628dB. Isso é adequado para a operação de upstream QPSK. Observe que o valor de SNR fornecido na saída desse comando é apenas uma estimativa e não substitui um valor de SNR derivado de um analisador de espectro ou outro equipamento de teste apropriado. Consulte o Guia de Referência de Comandos de Cabo de Banda Larga da Cisco para obter mais informações sobre o comando show controllers cable upstream spectrum.

• Um número de incrementos rápidos de erros de Correção de Erros de Encaminhamento de Correção (FEC - Corr Forward Error Correction) e FEC de Correção de Erros na saída de um comando show cable hop. Os erros Corr FEC indicam dados que foram danificados pelo ruído upstream mas puderam ser recuperados. A mensagem Uncorr FEC errors indica dados corrompidos por ruído upstream e que não puderam ser recuperados, resultando em perda de dados e desempenho mais lento. Um exemplo de saída do comando show cable hop é mostrado abaixo.

  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 

  No exemplo acima, cada porta upstream ativa no cabo 3/0 parece ter experimentado perda de pacotes devido a ruído. A porta upstream 0 parece ser a menos afetada, e a porta upstream 2 parece ser a mais gravemente afetada. O fator importante a observar é a rapidez com que os erros de FEC estão incrementando, em vez de o número total de erros. Consulte o Guia de Referência de Comandos do Cisco Broadband Cable para obter mais informações sobre o comando show cable hop.

• Um número alto de eventos "flap" na saída de um comando show cable flap-list. As estatísticas de flap mais pertinentes a possíveis problemas de RF ou ruído são a coluna Miss, que indica solicitações de variação perdida, e a coluna P-Adj , que indica níveis de potência de upstream com variação rápida. Um exemplo de saída do comando show cable flap-list é mostrado abaixo.

  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 

• Modems a cabo exibindo um "* "ou um "!—" na saída de um comando show cable modem ou show cable flap-list. Um "*" indica um modem a cabo que está variando rapidamente seus níveis de energia de upstream. Isso é indicativo de uma conexão ruim com a planta de cabos, um amplificador de caminho reverso defeituoso ou uma atenuação rápida da planta de cabos devido à temperatura ou outros efeitos ambientais. Um "!—" indica um modem a cabo que atingiu seu nível máximo de energia de upstream. Isso indica muita atenuação entre o modem a cabo e o CMTS, ou uma conexão ruim entre o modem a cabo e a planta de cabos. Um exemplo de saída para o comando show cable modem é exibida a seguir.

  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 

  No exemplo acima, o modem a cabo com endereço MAC 005a.73f6.2213 está transmitindo em sua potência de saída máxima. Isso faz com que o modem não seja capaz de transmitir no nível correto. Consequentemente, as transmissões de upstream desse modem não são ouvidas tão claramente quanto as transmissões de outros modems. O modem a cabo com endereço MAC 009c.96d7.3831 tem uma saída de alimentação que varia rapidamente devido à atenuação variável do sistema de cabos. Consulte o Cisco Broadband Cable Command Reference Guide para obter mais informações sobre os comandos show cable modem e show cable flap-list .

Observação: mais detalhes sobre como identificar e resolver problemas de ruído de RF podem ser encontrados em Determinando problemas de RF ou configuração no CMTS e Conectando o Cisco uBR7200 Series Router ao Headend do cabo.

Alto uso da CPU no CMTS

Em algumas circunstâncias, um Cisco CMTS pode ficar sobrecarregado devido a uma configuração subótima, ao uso excessivo de determinadas funções de gerenciamento ou a um número muito alto de pacotes sendo roteados pelo CMTS.

A melhor maneira de determinar o uso da CPU de um Cisco CMTS é executar o comando show process cpu. O uso atual da CPU é indicado na primeira linha da saída do comando.

Nas linhas da saída mostradas abaixo da primeira linha, cada processo executado no CMTS é mostrado junto com a parte do CPU que está sendo utilizado por esse processo. Esta seção da saída do comando show process cpu é útil para determinar se um processo ou função específica é a causa de uma CPU CMTS alta.

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

No exemplo acima, a carga de CPU atual no CMTS é de 45%/21%. Isso significa que o uso total da CPU está a 45 por cento da capacidade do sistema. Além disso, 21% da CPU está sendo usada para interrupções de serviço. Este segundo número normalmente é igual à porção da CPU que está sendo utilizada para rotear pacotes e comutar o tráfego através do CMTS.

Se o uso da CPU em cinco minutos for consistentemente superior a 80 por cento durante o horário de pico de uso no sistema, os usuários finais podem começar a experimentar um desempenho mais lento e maior latência. Se o uso da CPU durante cinco minutos for constantemente superior a 95 por cento durante o horário de pico de uso, tome medidas urgentes para garantir que o CMTS permaneça em um estado estável.

As estratégias comuns para reduzir o uso elevado da CPU no CMTS incluem:

• Atualizando para o Cisco IOS Software Release 12.1(9)EC ou posterior, ativando o comando de configuração global ip cef e certificando-se de que nenhuma interface no CMTS tenha o comando no ip route-cache configurado. Isso normalmente leva a uma redução de 10 a 15% no uso da CPU relacionado ao tráfego. Verifique se todos os passos estão sendo realizados em conjunto.

• Certificar-se de que as estações de gerenciamento do protocolo de gerenciamento de rede simples (SNMP - Simple Network Management Protocol) não estejam sendo muito agressivas na pesquisa do CMTS. Isso leva a um alto uso da CPU no processo SNMP IP.

• Sem executar o comando show tech sucessivamente. Isso leva a um uso de CPU artificialmente alto no processo Virtual Exec.

• Verificando se nenhum comando debug está sendo executado no CMTS.

Para obter mais informações sobre o alto uso da CPU em roteadores Cisco, incluindo produtos Cisco CMTS, consulte Solução de problemas de alta utilização da CPU em roteadores Cisco.

Equipamento de CPE com alimentação insuficiente ou mal configurado

Em muitos casos, o motivo do acesso lento a uma rede de cabo é um problema no equipamento de CPE de um usuário final. Se apenas um ou alguns usuários estiverem com um throughput lento e o restante da população de usuários não estiver com problemas, isso é uma forte indicação de que pode haver um problema exclusivo no ambiente desse usuário.

• Sob CPE alimentado ou sobrecarregado — Se os usuários finais que estão reclamando de dificuldades estiverem usando equipamentos CPE antiquados ou equipamentos que podem não ser potentes o suficiente para executar seu sistema operacional escolhido ou software de acesso à Internet, então esse usuário final terá dificuldades. A única resolução, se esse for o caso, é que o usuário final atualize seu equipamento CPE.

• Firewall ou software de medição de desempenho — Se o usuário final estiver executando qualquer firewall, medição de desempenho de rede ou outro software semelhante, uma boa etapa de solução de problemas é fazer com que o usuário desligue esse software para ver se ele tem algum efeito no desempenho. Frequentemente, esses tipos de software podem ter um impacto negativo no desempenho.

• Configurações TCP/IP incorretas—A maioria dos provedores de serviços exige que os usuários finais tenham seus equipamentos CPE para adquirir um endereço IP, máscara de rede, gateway padrão e servidores DNS através do Protocolo de Configuração Dinâmica de Host (DHCP - Dynamic Host Configuration Protocol). Certifique-se de que todos os usuários finais com problemas tenham seus dispositivos CPE configurados para usar DHCP para adquirir todos esses parâmetros.

Se um usuário final alegar não ter nenhum dos problemas listados acima, confirme se o usuário final não está excedendo sua taxa máxima de download ou upload de acordo com as seções acima.

Conclusão

Uma rede a cabo DOCSIS é um sistema sofisticado que requer planejamento e manutenção adequados. A maioria dos problemas de desempenho nos sistemas de cabo DOCSIS é um resultado direto da falta de planejamento e manutenção adequados. No atual mercado de acesso à Internet, onde há uma variedade de alternativas de acesso à Internet de banda larga, é importante que os provedores de serviços a cabo resolvam rapidamente quaisquer problemas de desempenho ou congestionamento em seus sistemas antes que os problemas se tornem significativos o suficiente para que os usuários finais sejam afetados de forma perceptível e, consequentemente, considerem um meio alternativo de acesso à banda larga.

Informações Relacionadas

• Troubleshooting de modems a cabo uBR com problemas de conexão
• Determinando problemas de RF ou configuração no CMTS
• Conectando o roteador Cisco uBR7200 Series ao ponto inicial do cabo
• Troubleshooting de Alta Utilização de CPU em Cisco Routers
• Suporte Técnico e Documentação - Cisco Systems