Troubleshooting de Desempenho Lento com Redes de Cable Modem
Contents
Introduction
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.
Este documento primeiro analisa como determinar com precisão que tipos de níveis de throughput um usuário final está alcançando e como garantir que o desempenho 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 é restrito pelos limites do 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 sistema de terminação de modem a cabo (CMTS).
-
Congestionamento de canal upstream e downstream.
-
Rede backhaul ou congestionamento da Internet.
-
Ruído ou erros na planta de cabos.
-
Sob o CPE (equipamento nas instalações do cliente).
Cada um deles individualmente ou em combinação pode afetar o rendimento e o desempenho em uma rede de cabos.
Este documento não discute a solução de problemas de uma perda completa de conectividade na rede a cabo ou nos 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
Prerequisites
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 uBR7200 e uBR7100 CMTS.
-
O conjunto de produtos CMTS Cisco uBR7100, uBR7200 e uBR7200VXR.
-
As informações neste documento são relevantes para todas as outras versões disponíveis atualmente 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. All of the devices used in this document started with a cleared (default) configuration. 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 alcançados
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 coaxial de fibra híbrida 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 de rede entre os dois pontos está sendo medida.
Por exemplo, se estiver realizando 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 é realizar um teste de velocidade entre o CPE e o Servidor 1, que está conectado ao mesmo segmento de rede que o CMTS. Isso porque o único caminho que os dados precisam percorrer é o segmento de cabo coaxial. Os dados também devem trafegar pelo segmento de rede CMTS local, mas presume-se que esse segmento seja de 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 é realizar um teste de velocidade entre o CPE e o Server 2. Essa é uma medida precisa, desde que haja links adequadamente de alta velocidade e não congestionados na rede interna do provedor de serviços de cabo entre o CMTS e o CPE.
A maneira mais imprecisa de determinar o desempenho do segmento de cabo é realizar 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 uploads e downloads estão ocorrendo é fazer upload ou download de 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 pode exibir a velocidade na qual um download ou um upload está ocorrendo durante a transferência ou quando a transferência está concluída. A velocidade de transferência vista como resultado da operação FTP ou HTTP é, normalmente, cerca de 90% do throughput total real alcançado. Isso ocorre porque a velocidade de transferência 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 de medir o throughput, por exemplo, usando equipamentos de teste dedicados de terceiros, como um Smartbits Netcom ou um gerador de pacotes IXIA, no entanto esses sistemas nem sempre estão prontamente disponíveis ou são facilmente conectados a uma rede de cabo de produção. Vale 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 de FTP ou HTTP.
Observação: o teste de upload e download baseado em FTP ou HTTP é confiável apenas para testar velocidades de cerca de 3 Mbps ou menos. Em velocidades mais altas, a potência de processamento do dispositivo CPE, do servidor ou das placas de interface de rede (NIC) pode se tornar um fator limitante no teste. Para testar velocidades superiores a cerca de 3 Mbps, deve ser usado equipamento dedicado de teste de throughput de dados.
No exemplo a seguir, um teste simples de download e upload de FTP é executado 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 baixou 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 para que ele possa fazer download desse arquivo do servidor FTP e, em seguida, carregá-lo de volta para o servidor FTP. O utilitário de FTP da linha de comando é utilizado para executar a transferência. Este utilitário está disponível em praticamente todas as versões do Microsoft Windows e UNIX.
Um teste semelhante é realizado com 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 está ocorrendo, é possível monitorar o progresso do teste no CMTS usando o comando show interface cable X/Y sid Z counters onde o cabo 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 sendo testado estiver atrás de um modem a cabo com endereço MAC 0001.9659.4461.
Primeiro, encontre o número SID do modem 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 upload está progredindo, limpe todos os contadores de pacotes no CMTS de volta para zero usando o comando clear counters. Exatamente quando os contadores forem zerados, inicie um cronômetro ou cronômetro.
uBR7246-VXR# clear counters !--- Reset packet counter to zero. Clear "show interface" counters on all interfaces [confirm] !--- Start the stopwatch when you hit Enter.
Depois que o cronômetro ou o tempo lerem exatamente um minuto, emita 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 realizado durante um período mais longo ou mais curto. Quanto mais longo for o período de teste, mais preciso será o resultado, entretanto, certifique-se de que o download ou o carregamento não terminem antes que o cronômetro de 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 são baixados 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 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 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 ao solucionar problemas de desempenho lento do modem a cabo é a classe prescrita de limitações de rendimento de serviço do modem a cabo. Quando um modem a cabo fica on-line, ele faz o download de 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. Tomando um modem com endereço MAC 0050.7366.2223 que está tendo problemas com a produtividade lenta, é necessário descobrir que classe de perfil de serviço este 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 este 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 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 de 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 se correlacionar com os limites mostrados em seu perfil de QoS, eles estão 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 sendo baixado pelo modem a cabo para um que tenha limites de throughput mais altos. Consulte o documento intitulado Criação de arquivos de configuração DOCSIS 1.0 usando o 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 fazer o download de dados da Internet a uma taxa maior do que o permitido pelo arquivo de configuração DOCSIS do modem a cabo, o CMTS deve limitar a taxa de tráfego enviado a esse usuário para garantir que o usuário não consuma mais do que o compartilhamento de largura de banda permitido.
Da mesma forma, quando um usuário final tenta fazer upload 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 passe pelo segmento de cabo até o CMTS. Se o modem a cabo, por algum motivo, não executar corretamente a limitação de taxa upstream, o CMTS proibirá explicitamente o modem a cabo de transmitir mais que a taxa permitida. Esse comportamento no CMTS é garantir que mesmo um modem a cabo com características "hackeadas" não seja capaz de subverter os limites de taxa de upload atribuídos ao provedor de serviços.
O esquema padrão de limitação de taxa usado pelo CMTS monitora a taxa de tráfego de/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á mais tráfego para esse modem a cabo durante o resto do segundo.
Por 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 baixar 512 kilobits (64 kilobytes) na primeira metade de um segundo, então na próxima metade do segundo, o modem a cabo não tem permissão para baixar nada. 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 em uma taxa constante, ao mesmo tempo em que garante que os usuários finais não tenham permissão para exceder a taxa de download prescrita, conforme especificado no arquivo de configuração DOCSIS.
A forma como este esquema funciona é medir a taxa na qual um modem a cabo está baixando ou carregando dados toda vez que um pacote é enviado para ou do 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á armazenado em buffer ou armazenado 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 downstream exceder consistentemente a taxa de downstream permitida para o modem a cabo, os pacotes serão eventualmente descartados.
Usando esse método mais simples de limitação e modelagem de taxa, a maioria dos aplicativos de Internet baseados em TCP, como navegação na Web HTTP e transferências de arquivos FTP, opera de forma mais suave e eficiente do que quando se usa 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 ativar 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 às 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 Cisco Broadband Cable Command Reference Guide para obter mais informações sobre os comandos cable downstream rate-limit e cable upstream rate-limit.
Os usuários podem ver com que intensidade o CMTS está limitando o tráfego para um modem a cabo específico usando o comando show interface cable X/Y sid <Z> counters, onde o cabo X/Y é a interface a cabo à qual o modem a cabo está conectado, e Z é o número SID do modem que está 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 do 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 ao modem tentando exceder seu throughput de downstream permitido.
O campo Ratelimit BWReqDrop mostra quantas vezes o CMTS se recusou a permitir que um modem a cabo envie um pacote no caminho de upstream devido ao modem tentando exceder seu throughput de upstream permitido. Na maioria das circunstâncias, este contador deve permanecer sempre em 0. Se ele subir significativamente acima de zero, pode ser que o modem a cabo que está sendo observado não esteja executando a limitação da taxa upstream corretamente.
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 como 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 QPSK (Quadrature Phase Shift Keying) no caminho de 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 upstream não se torne mais usado ou congestionado, caso contrário, todos os usuários nesse segmento upstream sofrerão um desempenho ruim.
O uso de upstream para uma porta upstream específica pode ser obtido executando o comando CMTS show interface cable X/Y upstream <Z>, onde o cabo X/Y é o número da interface downstream e Z é o número da porta upstream. Se Z for omitido, serão exibidas informações sobre todos os fluxos ascendentes 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% e há 359 modems conectados a esse upstream.
Se o uso do canal upstream estiver consistentemente acima de 75% durante o tempo 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 upstream estiver constantemente acima de 90% durante o horário de pico de uso, os usuários finais experimentarão um nível de serviço extremamente ruim, pois uma grande parte dos dados upstream do usuário final terá que ser atrasada ou descartada.
O uso do canal upstream muda durante o dia, já que diferentes usuários têm a oportunidade de usar seu modem a cabo, portanto, é importante monitorar o uso upstream durante os horários mais movimentados do dia em vez de em tempos de uso baixos.
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 pesados 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 é feito 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.
-
Aumentando a largura do canal upstream - Isso envolve uma rigorosa e completa análise do espectro upstream para encontrar uma banda larga suficiente com características de Ratio de Sinal para Ruído (SNR - Signal-to-Noise Ratio) adequadas para suportar o aumento da largura do canal. A largura do canal upstream não deve ser alterada sem um planejamento cuidadoso porque essa alteração pode afetar outros serviços no sistema de cabo do usuário. A largura do canal upstream pode ser alterada usando o comando cable interface cable upstream Z channel-width <new-channel-width> onde Z é o número da porta upstream e a nova largura de canal é uma de 200000, 40000, 80000, 160000 (o padrão) 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.
-
Mudar o esquema de modulação digital upstream para 16-Quadrature Amplitude Modulation (QAM) - Mais uma vez, isso requer uma rigorosa e completa análise do espectro upstream para verificar se há uma banda de frequência disponível no upstream que possa suportar modulação 16-QAM. Se essa análise não for realizada corretamente, há o risco de o desempenho ser ainda menor ou de ocorrer uma interrupção de upstream completa. É 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 Cisco Broadband Cable Command Reference Guide 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.
-
Reduzindo o throughput upstream permitido por modem a cabo - reduzindo a taxa máxima de transmissão 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 deste curso de ação é que os usuários de cable modem estão limitados a uma classe de serviço mais lenta. Consulte Criando arquivos de configuração DOCSIS 1.0 usando o Cisco DOCSIS Configurator.
Observação: as medidas discutidas nesta seção não aumentam significativamente o desempenho de um sistema já não congestionado.
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, de modo que se o canal downstream ficar congestionado, todos os usuários conectados ao segmento downstream experimentam um desempenho reduzido.
A tabela a seguir mostra a largura de banda de downstream total disponível associada aos quatro possíveis esquemas de modulação de downstream 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 implementa DOCSIS norte-americano de 64 QAM e, portanto, tem 27 Mbps disponíveis por canal downstream.
O uso do canal downstream pode ser determinado com a emissão do comando show interface cable X/Y, em que cabo X/Y é a interface de cabo que está 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. No 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 sendo usado. 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, caso contrário, permanece 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, em que 0/255 significa que nenhum tráfego está fluindo na direção 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% durante o tempo de pico de uso (por exemplo, maior que 191/255), os usuários finais começam a ter 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 downstream em bits por segundo. Se esse número exceder consistentemente aproximadamente 75% da largura de banda downstream disponível durante o tempo 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 de como a média é calculada.) O período sobre o qual essa média é calculada pode ser reduzido para até 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, já que diferentes usuários têm a oportunidade de usar o modem a cabo, portanto, é importante monitorar o uso de downstream durante os horários mais movimentados do dia em vez de em tempos de uso baixos.
As maneiras 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 pesados de largura de banda downstream, a melhor solução é mover alguns usuários no canal downstream congestionado para outro canal downstream. Isso normalmente é feito dividindo-se um grupo de nós de fibra de downstream associados ao downstream em dois grupos separados e atribuindo cada um dos novos grupos a canais de downstream separados. Consulte Qual é o número máximo de usuários por CMTS.
-
Mudar o esquema de modulação digital a jusante para 256-QAM - Esta ação requer uma rigorosa e completa análise do espectro a jusante para verificar se o sistema pode suportar um sinal 256-QAM. Se essa análise não for realizada corretamente, há o risco de o desempenho ser mais reduzido ou de ocorrer uma interrupção de downstream completa. O esquema de modulação de downstream pode ser alterado com a emissão do comando cable interface como visto abaixo.
uBR7246-VXR(config-if)# cable downstream modulation 256qam
Consulte o Cisco Broadband Cable Command Reference Guide para obter mais informações sobre o comando cable downstream modulation.
-
Reduzindo o throughput de downstream permitido por modem a cabo - reduzindo a taxa de transmissão de downstream máxima nos arquivos de configuração DOCSIS apropriados, os usuários de modem a cabo não podem fazer o download a uma taxa tão alta na direção de downstream e o congestionamento de downstream é aliviado. O aspecto negativo deste curso de ação é que os usuários de cable modem estão limitados a uma classe de serviço mais lenta. Consulte Criação de Arquivos de Configuração DOCSIS 1.0 Usando o Cisco DOCSIS Configurator.
Observação: as medidas discutidas nesta seção não aumentam significativamente o desempenho de um sistema já não congestionado.
Rede backhaul ou congestionamento da Internet
Em alguns casos, problemas de desempenho podem não ser resultado de problemas na instalação 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 é 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 por trá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 do cabo. Se o desempenho do segmento de rede CMTS local for significativamente melhor do que para os usuários conectados a modems a cabo, concentre os esforços 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, está obtendo desempenho lento ao navegar na Internet, a origem do problema não é o CMTS. Em vez disso, o gargalo ou problema de desempenho 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 Internet (ISP) e da Internet pública.
Ruído e erros na planta de cabos
Se houver uma quantidade excessiva de ruído ou entrada em um sistema de cabo, os pacotes entre os modems de cabo e o CMTS podem ser corrompidos e perdidos. Isso pode levar a uma redução significativa no desempenho.
Além da degradação no desempenho e na taxa de transferência, alguns dos principais indicadores de problemas de ruído ou radiofrequência (RF) incluem:
-
Os modems a cabo ficam esporadicamente off-line ou presos nos estados init(r1) ou init(r2).
-
Um SNR estimado em baixa conforme visto na saída de um comando show controller cable X/Y upstream Z, onde cabo X/Y é a interface de cabo que está sendo observada e Z é a porta upstream que está sendo observada. A especificação DOCSIS exige uma taxa de transporte para ruído (CNR) 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 de 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 DOCSIS CNR em seu sistema. Um exemplo de saída de 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 de SNR estimada é 28,628dB. Isso é adequado para a operação de upstream de QPSK. Observe que a figura SNR fornecida na saída desse comando é apenas uma estimativa e não substitui uma figura SNR derivada de um analisador de espectro ou outro equipamento de teste apropriado. Consulte o Cisco Broadband Cable Command Reference Guide para obter mais informações sobre o comando show controllers cable upstream Spectrum.
-
Um número rapidamente crescente de erros FEC (Corr Forward Error Correction) e Uncorr FEC 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 0No exemplo acima, cada porta upstream ativa no cabo 3/0 parece ter sofrido perda de pacotes devido ao 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 Cisco Broadband Cable Command Reference Guide para obter mais informações sobre o comando show cable hop.
-
Um alto número de eventos "flap" na saída de um comando show cable flap-list. As estatísticas de oscilação mais pertinentes a possíveis problemas de RF ou ruído são a coluna Miss, que indica solicitações de intervalo perdidas, e a coluna P-Adj, que indica níveis de potência upstream que variam rapidamente. 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 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 a outros efeitos ambientais. Um "!—" indica um modem a cabo que atingiu seu nível máximo de energia upstream. Isso é indicativo de muita atenuação entre o modem a cabo e o CMTS, ou de uma conexão ruim entre o modem a cabo e a fábrica 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.4457No exemplo acima, o modem a cabo com endereço MAC 005a.73f6.2213 está transmitindo à sua potência máxima de saída. Isso faz com que o modem não possa transmitir no nível correto. Consequentemente, as transmissões upstream deste 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 a identificação e resolução de problemas de ruído de RF podem ser encontrados em Determinando problemas de RF ou de configuração no CMTS e Conectando o Cisco uBR7200 Series Router ao Cabeçalho do Cabo.
Alto uso da CPU no CMTS
Em algumas circunstâncias, um Cisco CMTS pode ficar sobrecarregado devido a uma configuração abaixo do ideal, ao uso de certas 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 show process cpu é útil para determinar se um determinado processo ou função é a causa da alta CPU do CMTS.
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 atual da CPU no CMTS é de 45%/21%. Isso significa que o uso total da CPU está em 45% da capacidade do sistema. Além disso, 21% da CPU está sendo usada para atender interrupções. 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% durante o tempo 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 em cinco minutos estiver constantemente acima de 95% durante o tempo 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 alto uso 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 verificando se nenhuma interface no CMTS tem o comando no ip route-cache configurado. Isso geralmente leva a uma redução de 10% a 15% no uso da CPU relacionada ao tráfego. Verifique se todos os passos estão sendo realizados em conjunto.
-
Verificando se as estações de gerenciamento do Protocolo de Gerenciamento de Rede Simples (SNMP - Simple Network Management Protocol) não estão sendo muito agressivas na pesquisa do CMTS. Isso leva a um alto uso da CPU no processo IP SNMP.
-
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 uso de alta utilização da CPU em roteadores Cisco, incluindo produtos Cisco CMTS, consulte Troubleshooting de Alta Utilização da CPU em Cisco Routers.
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 experimentando um throughput lento e o restante da população de usuários não estiver enfrentando nenhum problema, isso é uma forte indicação de que pode haver um problema único no ambiente desse usuário.
-
Em CPE alimentado ou sobrecarregado — Se os usuários finais reclamarem 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, esse usuário final terá dificuldades. A única resolução, se esse for o caso, é que o usuário final atualize seu equipamento CPE.
-
Software de medição de desempenho ou firewall —Se o usuário final estiver executando qualquer firewall, medida de desempenho da 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 mal configuradas — A maioria dos provedores de serviços exige que os usuários finais tenham seus equipamentos CPE para adquirir um endereço IP, uma máscara de rede, um gateway padrão e servidores DNS por meio do Dynamic Host Configuration Protocol (DHCP). 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 de cabo DOCSIS é um sistema sofisticado que exige planejamento e manutenção adequados. A maioria dos problemas de desempenho em sistemas de cabo DOCSIS é um resultado direto da falta de execução de planejamento e manutenção adequados. No atual mercado de acesso à Internet, onde existem várias alternativas de acesso à Internet de banda larga, é importante que os prestadores de serviços a cabo resolvam rapidamente quaisquer problemas de desempenho ou congestionamento no seu sistema antes que os problemas se tornem suficientemente significativos para que os utilizadores finais sejam significativamente afetados e, consequentemente, considerem um meio alternativo de acesso à banda larga.
Informações Relacionadas
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)