Banda larga a cabo : Modems a cabo

Troubleshooting de Desempenho Lento com Redes de Cable Modem

14 Outubro 2016 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Inglês (22 Agosto 2015) | Feedback


Índice


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.

Este documento olha primeiramente como determinar exatamente que tipos dos níveis de ritmo de transferência um utilizador final está conseguindo e como se certificar de que o desempenho que está sendo medido é aquele da rede de cabo, um pouco do que aquele do Internet mais largo.

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

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

  • Intermitência ou desempenho de download inconstante causada usando uma taxa secundário-ótima que limita o esquema no cable modem termination system (CMTS).

  • Congestão do canal de upstream e downstream.

  • Rede de backhaul ou congestionamento de Internet.

  • Ruído ou erros na planta de cabos.

  • Sob o equipamento de locais de cliente de usuário final posto (CPE).

Cada um dos estes individualmente ou na combinação pode afetar a taxa de transferência e o desempenho em uma rede de cabo.

Este documento não discute pesquisar defeitos uma perda de conectividade completa sobre a rede de cabo ou o Modems a cabo que não vêm em linha. Em lugar de, refira pesquisando defeitos o Online de vinda do Modems a cabo do uBR para estes tipos dos problemas. Além, para os utilizadores finais de um UBR 900 ou de um Series Cable Modem CVA120 que experimentam problemas de desempenho, o melhor começando o lugar para pesquisar defeitos este problema é os novatos FAQ para utilizadores finais do modem a cabo do uBR900 Series.

Antes de Começar

Convenções

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

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 Release 12.1(9)EC do ½ do ¿  de Cisco IOSï para o uBR7200 e o uBR7100 CMTS.

  • O Cisco uBR7100, o uBR7200, e a série do uBR7200VXR dos produtos cmts.

  • A informação neste documento é relevante para todas liberações atualmente disponíveis restantes do Cisco IOS Software DOCSIS 1.0-based para o equipamento 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.

Exatamente determinando os níveis de desempenho que estão sendo conseguidos

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.

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

Figura 1 (para ver este diagrama como uma animação em flash clicar aqui.)

Nesse diagrama há diversos componentes:

  • A rede do co-axial da fibra híbrida entre o utilizador final e o CMTS.

  • O segmento de rede local CMTS onde o CMTS conecta à rede de provedores de serviço de cabo.

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

  • Os Internet públicas.

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 executar um teste de velocidade entre o CPE e Servidor3, que é conectado ao Internet através de uma linha de ISDN dos kbps 128, lá nunca estará a umas velocidades de maior do que os kbps 128, mesmo se a largura de banda disponível no segmento de cabo é os maiores então kbps 128.

A maioria de modo preciso medir o desempenho do segmento de cabo próprio é executar um teste de velocidade entre o CPE e o servidor1, que é conectado ao mesmo segmento de rede que o CMTS. Isto é porque os únicos dados do trajeto precisam de viajar sobre são o segmento do cabo coaxial. Os dados igualmente devem viajar através do segmento de rede local CMTS, mas presume-se que este segmento é de uma largura de banda elevada (FastEthernet ou maior) e não tem um nível alto da congestão.

Se por qualquer motivo, nenhum server pode ser conectado ao segmento de rede local CMTS, a seguir a maioria de modo preciso seguinte testar o desempenho do segmento de cabo é executar um teste de velocidade entre o CPE e o servidor2. Esta é uma medida precisa enquanto há uns links adequadamente de alta velocidade e uncongested dentro da rede interna do provedor de serviços de cabo entre o CMTS e o CPE.

A maioria de maneira menos precisa determinar o desempenho do segmento de cabo é executar um teste de velocidade entre o CPE e um server nos Internet públicas. 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 a mais fácil de determinar a velocidade em que transfere arquivos pela rede e as transferências estão ocorrendo são transferir arquivos pela rede ou transferir um grande arquivo usando o FTP ou o HTTP entre um dispositivo CPE conectado a um modem a cabo, e um server atrás do CMTS. A maioria FTP e de clientes HTTP podem indicar a velocidade em que uma transferência ou uma transferência de arquivo pela rede estão ocorrendo ou durante transferência ou uma vez transferência está completa. A velocidade de transferência considerada em consequência do FTP ou da operação de HTTP é tipicamente aproximadamente 90 por cento de transferência de dados total verdadeira alcançada. Isto é porque a velocidade de transferência indicada FTP ou HTTP não leva em consideração o IP extra e a carga adicional do DOCSIS que precisa de viajar entre o dispositivo CPE e o CMTS.

Há mais métodos precisos de medir a taxa de transferência, por exemplo usando o equipamento de teste dedicado da terceira, tal como um Netcom Smartbits ou um gerador de pacote IXIA, porém estes sistemas não são sempre prontamente - disponível ou conectado facilmente a uma rede de cabo da produção. Vale notando que se os testes da taxa de transferência estão sendo realizados em um ambiente de laboratório, a seguir usar um dispositivo dedicado revelará muito mais informação do que teste da transferência simples FTP ou HTTP.

Nota: O teste HTTP-baseado ftp ou da transferência de arquivo pela rede e de transferência é somente seguro para velocidades de teste em torno do 3 Mbps ou menos. Em umas velocidades mais altas a potência de processamento do dispositivo CPE, do server ou do Network Interface Cards (NIC) pode transformar-se um fator limitante no teste. Para testar apressa-se mais altamente do que sobre o 3 Mbps, o equipamento de teste dedicado do ritmo de transferência de dados deve ser usado.

No exemplo seguinte, um teste simples da transferência e da transferência de arquivo pela rede FTP é executado entre um dispositivo CPE conectado a um modem a cabo, e um servidor FTP na rede de provedores de serviço de cabo. O modem a cabo transferiu um arquivo de configuração DOCSIS que reservasse uma velocidade da transferência até dos kbps 256 e de uma velocidade de upload de até 64 kbps. Neste teste, um arquivo do 3 Mb foi colocado no servidor FTP no endereço IP 172.17.110.132. O usuário do dispositivo CPE é dado um nome de usuário e senha a fim poder registrar no servidor FTP assim que podem transferir este arquivo do servidor FTP, e transferem-no arquivos pela rede então de volta ao servidor FTP. O utilitário de FTP da linha de comando é utilizado para executar a transferência. Esta utilidade está disponível em virtualmente todas as versões de Microsoft Windows e de UNIX.

Um teste similar é conduzido tendo um servidor de Web HTTP estabelecido na rede de provedor de serviços e executando uma transferência HTTP.

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

Figura 2

Note: 
!--- Comments are in blue.

C:\>ftp 172.17.110.132                    


!--- Initiate the FTP session to the server.
 

Connected to 172.17.110.132. 
220 Solaris FTP server (SunOS 5.6) ready. 
User (172.17.110.132:(none)): anonymous    


!--- Enter the FTP server username.
 

331 Guest login ok, send your complete e-mail address as password. 
Password: user@samplenetwork.com.au       


!--- Enter the FTP server password. 


230 User anonymous logged in. 
ftp> dir                                  


!--- View the contents of the current directory.
 

200 PORT command successful. 
150 ASCII data connection for /bin/ls (64.104.207.118,1282) (0 bytes). 
total 74932 
-rw-r--r--   1 root     other    3276800 Oct 10 19:31 cable.txt   


!--- A 3 M file that you can download.


226 ASCII Transfer complete. 
ftp: 105 bytes received in 0.12 Seconds 2.46 Kbytes/sec. 
ftp> bi                                  


!--- Turn on Binary File transfer mode.


200 Type set to I. 
ftp> get cable.txt                       


!--- Retrieve the file cable.txt and wait for it to download.
 
200 PORT command successful. 
150 Binary data connection for cable.txt (192.168.1.13,3154) (3276800 bytes). 
226 Binary Transfer complete. 
ftp: 3276800 bytes received in 111.35 Seconds 29.43 Kbytes/sec. 


!--- Download complete. It seems that the download occurred 
!--- at 29.43 Kbytes/sec, which equals 235 Kbits/sec. This is about 90 percent of 
!--- the allowed 256 Kbps download rate for the modem being tested.
 

ftp> put cable.txt                       


!--- Begin uploading the file. You need to make sure you have                                          
!--- the correct access in order to upload a file to the FTP server or 
!--- you may get an access-denied error.
 

200 PORT command successful. 
150 Binary data connection for cable.txt (192.168.1.13,3157). 
226 Transfer complete. 
ftp: 3276800 bytes sent in 432.49 Seconds 7.58 Kbytes/sec. 


!--- Upload Complete. Here you see the upload 
!--- occurred at 7.58 Kbytes/sec, 
!--- which is equivalent to 60.64 Kbits/sec. This 
!--- is about 90 percent of the allowed 
!--- 64 Kbps upload rate for the modem being tested.
 

ftp> quit                                


!--- Exit the FTP client application.
 
221 Goodbye.

Quando transferência por FTP ocorrer, é possível monitorar o progresso do teste no CMTS usando o comando show interface cable X/Y sid Z counters onde o X/Y do cabo é a interface de cabo que o modem sob o teste é conectado a, e Z é o número de identificador de serviço (SID) do modem sob o 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 é atrás de um modem a cabo com MAC address 0001.9659.4461.

O primeiros encontram o número de 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

Quando a transferência ou a transferência de arquivo pela rede progredirem, cancele todos os contadores de pacote de informação no CMTS de volta a zero usando o comando clear counters. Exatamente quando os contadores são cancelados, comece um cronômetro ou um 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 lê exatamente um minuto, emitem o comando show interface cable X/Y sid Z counters. Pode ser o melhor datilografar primeiramente o comando e para bater então entre exatamente quando o temporizador indica um minuto. O teste pode ser executado durante um período mais longo ou mais curto. Mais longo o período do teste, mais exato o resultado, contudo certifica-se de que a transferência ou a transferência de arquivo pela rede não terminam antes que o temporizador vigilância de parada alcance o tempo especificado, se não a medida é impreciso.

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# 

A velocidade da transferência está sendo testada neste caso. A saída do comando show interface cable X/Y sid Z counter indica aquela durante um minuto, 1,921,488 bytes é transferida pelo modem a cabo. Converter 1,921,488 bytes em bit revela:

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

Então, para encontrar a taxa de download nos bit por segundo, divida este número total de bit transferidos antes que tomar para os transferir nos segundos.

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

A taxa de download neste exemplo é mostrada para ser aproximadamente os kbps 256, que acontece ser a taxa de download reservada para o modem a cabo sob o teste.

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

Veja o guia de referência de comando do cabo da banda larga Cisco para obter mais informações sobre do comando show interface cable sid counters.

Possíveis razões para um desempenho ruim

Desempenho restrito pelo arquivo de configuração DOCSIS

A primeira parte de informação que precisa de ser recolhida ao pesquisar defeitos o desempenho de cable modem lento é as limitações de throughput prescritas da classe de serviço do modem a cabo. Quando um modem a cabo vem em linha, transfere um arquivo de configuração DOCSIS que contenha limites operacionais para o modem a cabo, incluindo a taxa máxima de upload e download. Em circunstâncias normais, o modem a cabo não pode exceder essas taxas.

Inicialmente é necessário identificar o MAC address de um modem a cabo que tem problemas. Tomando um modem com MAC address 0050.7366.2223 que está tendo problemas com taxa de transferência lenta. é necessário encontrar que classe de serviço o perfil este modem a cabo está usando executando o comando show cable modem < mac-address > como 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 mostra que este modem a cabo tem um perfil do Qualidade de Serviço (QoS) de 5. a fim encontrar que taxas downstream e upstream este perfil de QoS corresponde, usa o comando do perfil-número do perfil dos qos do cabo da mostra, onde o perfil-número é o perfil de QoS do 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 5 de QoS corresponde a um serviço que fornece os kbps 256 no a jusante e 64 kbps são os ascendentes. Nenhum CPE conectado ao Modems a cabo que usa o perfil 5 de QoS não pode exceder estes limites. Os ajustes do perfil de QoS são determinados pelos índices dos arquivos de configuração DOCSIS transferidos pelo Modems a cabo do servidor TFTP do sistema de abastecimento, consequentemente o perfil 5 de QoS no sistema não pode ser o mesmo que o perfil 5 de QoS no exemplo mostrado acima.

Se a transferência de um utilizador final e o desempenho da transferência de arquivo pela rede correlacionam com os limites mostrados em seu perfil de QoS, a seguir está obtendo a classe de serviço e os níveis de ritmo de transferência para que o modem a cabo foi fornecida e configurado. A única maneira de aumentar a taxa de transferência da transferência de arquivo pela rede e da transferência é mudar o arquivo de configuração DOCSIS que está sendo transferido pelo modem a cabo a uma que tem limites do throughput elevado. Veja o documento autorizado arquivos de configuração de construção do DOCSIS 1.0 usando o Configurador DOCSIS Cisco (clientes registrados somente) para instruções detalhadas em como criar ou alterar um arquivo de configuração DOCSIS.

Utilizando um método sub-otimizado para taxa limite

Quando um utilizador final está tentando transferir dados do Internet em uma taxa maior do que o arquivo de configuração DOCSIS do seu modem a cabo reserva, o CMTS deve limite de taxa o tráfego que está sendo enviado a esse usuário para assegurar-se de que o usuário não consuma mais do que sua parte permitida da largura de banda.

Similarmente, quando um utilizador final tenta transferir arquivos pela rede ou enviar dados ao Internet em uma taxa maior do que o que o arquivo de configuração DOCSIS permite, o modem a cabo próprio deve parar o tráfego excedente da viagem sobre o segmento de cabo ao CMTS. Se o modem a cabo, por qualquer motivo, não executa a taxa fluxo acima que limita corretamente, a seguir o CMTS proibe explicitamente o modem a cabo de transmitir mais altamente do que a taxa permitida. Este comportamento no CMTS é assegurar-se de que mesmo um modem a cabo com características “cortadas” seja incapaz de subverter o provedor de serviços atribuído limites da taxa de upload.

O esquema da taxa limite do padrão usado pelo CMTS monitora a taxa de tráfego a ou de cada modem a cabo durante cada período de um segundo. Se o modem a cabo envia ou recebe mais do que sua por segundo quota em menos do que um segundo, a seguir o CMTS não permite que any more tráfego flua a esse modem a cabo para o resto do segundo.

Como um exemplo, tome um modem a cabo com um perfil de QoS reservando uma taxa de download de 512 kbps. Se o modem a cabo transfere 512 kilobits (64 quilobytes) dentro da primeira metade de um segunda, a seguir para a metade seguinte do segunda, o modem a cabo não está permitido transferir qualquer coisa. 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 esquema a jusante da taxa limite do melhor a usar-se é o algoritmo de limitação de taxa de bucket de token com modelagem de tráfego. Este esquema da taxa limite foi aperfeiçoado para permitir uma experiência lisa da navegação na web em uma taxa constante, ao ao mesmo tempo assegurar-se de que não estivessem permitidos aos utilizadores finais exceder a taxa de download prescrita como especificado no arquivo de configuração DOCSIS.

A maneira que este esquema trabalha é medir a taxa em que um modem a cabo é de transferência ou transferindo arquivos pela rede dados um pacote é enviado cada vez a ou do modem a cabo. Se enviar ou receber o pacote na pergunta fazem com que o modem exceda suas taxas de transferência reservadas, a seguir o pacote está protegido ou posto em esconderijo na memória CMTS até que o CMTS possa enviar o pacote sem exceder o limite da largura de banda fluxo abaixo.

Nota: Se a taxa de tráfego a jusante excede consistentemente a taxa de downstream reservada para o modem a cabo, a seguir os pacotes estão deixados cair eventualmente.

Usando este método mais liso da taxa que limita e que dá forma, a maioria de aplicativos de Internet com base em TCP tais como a navegação na web HTTP e as transferências de arquivo FTP operam-se mais lisamente e eficientemente do que ao usar o esquema da taxa limite do padrão.

O esquema taxa-limitar-com-tráfego-dando forma do token bucket pode ser permitido no trajeto a jusante em uma interface de cabo emitindo o seguinte comando configuration da interface de cabo:

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

Nota: É altamente recomendado permitir o modelagem de taxa de token bucket no CMTS do usuário. Este comando é apoiado até à data dos Cisco IOS Software Releases 12.0(5)T1 e 12.1(1)EC1.

O token bucket com esquema do modelagem de tráfego igualmente pode ser aplicado às portas upstream, mas desde que é a responsabilidade do Modems a cabo executar a taxa fluxo acima que limita, o esquema ascendente da taxa limite 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

Veja o guia de referência de comando do cabo da banda larga Cisco para obter mais informações sobre do taxa-limite e dos comandos cable upstream rate-limit a jusante do cabo.

Os usuários podem ver como severamente o CMTS é taxa que limita o tráfego a um cable modem particular usando o comando show interface cable X/Y sid <Z> counters, onde o X/Y do cabo é a interface de cabo a que o modem a cabo é conectado, e Z é o número de 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 é especificado para Z, a seguir a informação de contador para todo o Modems a cabo conectou ao X/Y do cabo de interface está indicada.

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 de Ratelimit DSPktDrop mostra quantas vezes o CMTS tem os pacotes descartado destinados para o modem a cabo devido ao modem que tenta exceder sua taxa de transferência a jusante permitida.

O campo de Ratelimit BWReqDrop mostra quantas vezes o CMTS recusou deixar um modem a cabo enviar um pacote no caminho upstream devido ao modem que tenta exceder seu throughput de upstream permitido. Na maioria de circunstâncias este contador sempre deve permanecer em 0. Se aumenta significativamente acima de zero, pode-se ser que o modem a cabo que está sendo observado não esteja executando a taxa fluxo acima que limita corretamente.

Nota: Os valores indicados pelo comando show interface cable X/Y sid Z counters podem ser restaurados a 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

Veja o guia de referência de comando do cabo da banda larga Cisco para obter mais informações sobre do comando show interface cable sid counters.

Congestionamento de canal upstream

O canal upstream é normalmente a maioria de recursos preciosos em um sistema de cabo. Atualmente, a maioria de provedores de serviços de cabo usam uma largura do canal 1.6 megahertz e uma modulação do ajuste de troca de fase de quadratura (QPSK) (QPSK) 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 assegurar-se de que o canal upstream não se torne sobre usado ou congestionado, se não todos os usuários nesse segmento ascendente sofrem o desempenho ruim.

O uso de upstream para uma porta upstream particular pode ser obtido executando o <Z> ascendente do show interface cable X/Y do comando cmts, onde o X/Y do cabo é o número de interface a jusante e Z é o número de porta upstream. Se Z é omitido, a informação para todos os upstreams no X/Y do cabo de interface estará indicada. Veja o guia de referência de comando do cabo da banda larga Cisco para obter mais informações sobre do 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 considerada no exemplo, o uso de upstream é atualmente 18 por cento e há 359 Modems conectados a este rio acima.

Se o uso do canal upstream está consistentemente acima de 75 por cento durante o tempo de pico de uso, os utilizadores finais começam a sofrer edições tais como a latência, uns tempos mais lentos do “sibilo”, e uma experiência em Internet geralmente mais lenta. Se o uso do canal upstream está constantemente acima de 90 por cento durante o tempo de pico de uso, os utilizadores finais experimentam um nível extremamente deficiente do serviço porque uma grande parcela dos dados ascendentes do utilizador final terá que ser atrasada ou rejeitado.

O uso do canal upstream muda durante o dia porque os usuários diferentes têm uma oportunidade de usar seu modem a cabo, assim que é importante monitorar o uso de upstream durante as horas as mais ocupadas do dia um pouco do que no baixo tempo de uso.

As maneiras de aliviar o congestionamento upstream incluem:

  • Reduzindo o número de Modems a cabo por rio acima – se há Modems a cabo demais conectado a um detalhe rio acima, ou se os usuários em um detalhe rio acima são usuários pesados da largura de banda fluxo acima, a melhor solução é mover alguns usuários na porta upstream congestionada para uma porta upstream usada inferior, ou para uma porta upstream completamente nova. Isto é realizado tipicamente movendo um nó de fibra de um grupo de combinação ascendente para outro, ou rachando um grupo de combinação ascendente em dois grupos de combinação separados. Para mais informação, refira o que é o número máximo de usuários pelo CMTS.

  • Aumentando a largura de canal fluxo acima – Isto envolve uma análise rigorosa e completa do espectro de upstream para encontrar largamente bastante faixa com características adequadas da razão sinal-ruído (SNR) para apoiar a largura do canal aumentada. A largura de canal fluxo acima não deve ser mudada sem planeamento cuidadoso porque esta mudança potencialmente pode afetar outros serviços no sistema de cabo do usuário. A largura de canal fluxo acima pode ser mudada usando o <new-channel-width> ascendente da largura do canal do cabo Z do comando cable interface onde Z é o número de porta upstream e a largura do canal nova é um de 200000, de 400000, de 800000, de 1600000 (o padrão) ou de 3200000. Um exemplo a seguir.

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

    Veja o guia de referência de comando do cabo da banda larga Cisco para obter mais informações sobre do comando show interface cable upstream.

  • Mudando o esquema ascendente da modulação digital à modulação de amplitude 16-Quadrature (QAM) – mais uma vez, isto exige uma análise rigorosa e completa do espectro de upstream a fim verificar se há uma banda de frequência no disponível ascendente que pode apoiar a modulação 16-QAM. Se esta análise não é executada corretamente, há um risco que o desempenho está diminuído mais ou uma interrupção upstream completa pode ocorrer. É 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
    
    

    Veja o guia de referência de comando do cabo da banda larga Cisco para obter mais informações sobre do perfil de modulação e dos comandos cable upstream modulation-profile do cabo. 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 de upstream permitido pelo modem a cabo – Reduzindo o máximo rio acima transmita a taxa nos arquivos de configuração DOCSIS apropriados, os usuários do modem a cabo não podem transmitir como na elevação uma taxa na direção de upstream e o congestionamento upstream é aliviado. O aspecto negativo deste curso de ação é que os usuários do modem a cabo estão limitados a uma classe de serviço mais lenta. Veja arquivos de configuração do DOCSIS 1.0 da construção usando o Configurador DOCSIS Cisco (clientes registrados somente).

Nota: As medidas discutidas nesta seção não aumentam significativamente o desempenho já de um sistema 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, mais usuários compartilham tipicamente de canal downstream do que todo o único canal upstream, assim que se o canal downstream se torna congestionado, de todos os usuários conectados ao desempenho reduzido a jusante da experiência do segmento.

A tabela a seguir mostra a largura de banda fluxo abaixo disponível total associada com os quatro esquemas possíveis da modulação downstream disponíveis nos sistemas de DOCSIS.

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

A maioria de sistemas do cabo DOCSIS distribui atualmente 64-QAM DOCSIS norte-americano e tem consequentemente o 27 Mbps disponível pelo canal downstream.

O uso do canal downstream pode ser determinado emitindo o comando show interface cable X/Y, onde o X/Y do cabo é 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 desta saída a notar é a largura de banda da relação indicada pelo parâmetro de BW. Nos Cisco IOS Software Release 12.1(8)EC e Mais Recente, este valor é ajustado automaticamente de acordo com o esquema da modulação downstream e a versão do DOCSIS que está sendo usado. Nas revisões mais cedo do que o Cisco IOS Software Release 12.1(8)EC, este valor deve ser configurado manualmente usando o <bandwidth-in-kilo-bits-per-second> da largura de banda do comando cable interface ou de outra maneira permanece no valor padrão de 27000 kbps.

O segundo componente a notar é a carga da transmissão como indicado pelo parâmetro de carga tx. Este parâmetro dá uma métrica fora de 255 onde 0/255 significam que o sem tráfego está fluindo na direção fluxo abaixo a 255/255, que significa que os dados estão viajando no a jusante na taxa possível máxima (neste caso em 27000 kbps). Se este parâmetro está sendo executado consistentemente em maior do que aproximadamente 75 por cento durante o tempo de pico de uso (por exemplo, maior de 191/255), os utilizadores finais começam experimentar um acesso ao Internet e uma alta latência mais lentos.

O terceiro componente a notar é a taxa de emissor, que mostra a taxa de throughput a jusante da média nos bit por segundo. Se este número excede consistentemente aproximadamente 75 por cento da largura de banda fluxo abaixo disponível durante o tempo de pico de uso, os utilizadores finais começam experimentar um acesso ao Internet e uma alta latência mais lentos.

À revelia, estas estatísticas são calculadas sobre uma média em movimento de cinco minutos. (Refira a compreensão da definição de bits por segundo (bit/segundo) do comando show interfaces Output para detalhes de como a média é calculada.) O período sobre que esta média é calculada pode ser reduzido ao tão pouco quanto 30 segundos emitindo o carga-intervalo 30 do comando cable interface. Abaixando este período a 30 segundos, um mais exato um valor atualizado é calculado para cada um dos parâmetros discutidos nesta seção.

O uso do canal downstream muda durante o dia porque os usuários diferentes têm uma oportunidade de usar seu modem a cabo, assim que é importante monitorar o uso downstream durante as horas as mais ocupadas do dia um pouco do que no baixo tempo de uso.

As Maneiras de diminuir o congestionamento downstream incluem:

  • Reduzindo o número de Modems a cabo por rio abaixo – se há Modems a cabo demais conectado a um downstream particular, ou se os usuários em um downstream particular são usuários pesados da largura de banda fluxo abaixo, a seguir a melhor solução é mover alguns usuários no canal downstream congestionado para um outro canal downstream. Isto é realizado tipicamente rachando um grupo de nós de fibra a jusante associados com o a jusante em dois grupos separados e atribuindo cada um dos grupos novos separe os canais downstream. Refira o que é o número máximo de usuários pelo CMTS.

  • Mudando o esquema a jusante da modulação digital ao 256-QAM – esta ação exige uma análise rigorosa e completa do espectro downstream a fim verificar se o sistema pode apoiar um sinal do 256-QAM. Se esta análise não é executada corretamente, há um risco que o desempenho estará diminuído mais ou uma interrupção downstream completa pode ocorrer. O esquema da modulação downstream pode ser mudado emitindo o comando cable interface como considerado abaixo.

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

    Veja o guia de referência de comando do cabo da banda larga Cisco para obter mais informações sobre do comando cable downstream modulation.

  • Reduzindo a taxa de transferência a jusante permitida pelo modem a cabo – reduzindo o downstream máximo transmita a taxa nos arquivos de configuração DOCSIS apropriados, os usuários do modem a cabo não podem transferir como na elevação uma taxa na direção fluxo abaixo e o congestionamento de downstream é aliviado. O aspecto negativo deste curso de ação é que os usuários do modem a cabo estão limitados a uma classe de serviço mais lenta. Refira arquivos de configuração de construção do DOCSIS 1.0 usando o Configurador DOCSIS Cisco (clientes registrados somente).

    Nota: As medidas discutidas nesta seção não aumentam significativamente o desempenho já de um sistema não congestionado.

Rede backhaul ou congestionamento da Internet

Em alguns casos, os problemas de desempenho não podem ser um resultado das edições na planta de cabos ou no CMTS, mas podem ser relacionados à congestão ou aos problemas na rede de backhaul que os usos CMTS conectar ao Internet, ou dentro das partes do Internet próprias.

A maneira a mais fácil de determinar se a congestão de rede de backhaul é um problema é conectar uma estação de trabalho ao mesmo segmento de rede que o CMTS e tentá-la consultar os mesmos Web site que os utilizadores finais atrás do Modems a cabo estão tentando alcançar. Se o desempenho é ainda lento, há um problema de desempenho na rede não relativa ao CMTS ou ao segmento de cabo. Se o desempenho do segmento de rede local CMTS é significativamente melhor do que para os usuários conectados ao Modems a cabo, a seguir aos esforços do foco para trás no CMTS e no segmento de cabo.

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

Figura 3

Na rede acima, se o servidor1, que é conectado ao mesmo segmento de rede que o CMTS, está obtendo o desempenho lento ao consultar o Internet, a seguir a fonte do problema não é o CMTS. Em lugar de, o gargalo ou o problema de desempenho em outro lugar. A fim determinar onde o problema está, os testes de desempenho são realizados entre o servidor1 e vários server dentro da rede de provedor de serviço do Internet (ISP) e os Internet públicas.

Ruído e erros na planta de cabos

Se há uma quantidade excessiva de ruído ou de ingresso em um sistema de cabo, a seguir os pacotes entre o Modems a cabo e o CMTS podem ser corrompidos e perdido. Isso pode levar a uma redução significativa no desempenho.

Com exceção de uma degradação no desempenho e na taxa de transferência, alguns dos indicadores principais do ruído ou as edições do Radio Frequency (RF) incluem:

  • Modems a cabo que deixa cair esporadicamente off line ou que obtém colado no init(r1) ou no init(r2) estados.

  • Um ponto baixo calculou o SNR como visto na saída de um X/Y Z ascendente do cabo do controlador da mostra, onde o X/Y do cabo fosse a interface de cabo que está sendo observada e Z fosse a porta upstream que está sendo observada. A especificação de DOCSIS exige uma razão portadora-ruído (CNR) pelo menos de DB 25 para todos os sinais ascendentes. Isso é igual a um SNR de aproximadamente 29 dB. Cisco CMTS pode detectar coerentemente o QPSK rio acima sinaliza a níveis SNR muito mais ruins, porém todos os provedores de serviços de cabo devem se esforçar para cumprir os requisitos de DOCSIS CNR em seu sistema. Uma saída ascendente do X/Y Z do cabo do controlador da mostra da amostra é mostrada 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 calculada é 28.628dB. Isto é adequado para a operação upstream de QPSK. Note que a figura SNR dada na saída deste comando não é somente uma avaliação e é nenhum substituto para uma figura SNR derivada de um analisador de espectro ou do outro equipamento de teste apropriado. Veja o guia de referência de comando do cabo da banda larga Cisco para obter mais informações sobre do comando show controllers cable upstream spectrum.

  • Um número rapidamente de incremento da correção de erros de encaminhamento de Corr (FEC) e erros incorrigível de 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       0 

    No exemplo acima, cada porta upstream ativa no cabo 3/0 parece ter experimentado a perda de pacotes devendo propalar. 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. Veja o guia de referência de comando do cabo da banda larga Cisco para obter mais informações sobre do comando show cable hop.

  • Um alto número de eventos do “flap” na saída de um comando show cable flap-list. As estatísticas do flap as mais pertinentes aos problemas possíveis RF ou de ruído são a coluna Falha, que indica requisições de variação faltadas, e a coluna P-Adj, que indica níveis da potência ascendentes rapidamente de variação. 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 
  • Indicação do Modems a cabo “* “ou “! ---” na saída de um comando show cable modem ou show cable flap-list. “*” indica um modem a cabo que esteja variando rapidamente seus níveis da potência ascendentes. Isto é indicativo de uma conexão ruim à planta de cabos, a um amplificador de caminho reverso defeituoso, ou à planta de cabos em rápida mutação atenuação devido à temperatura ou aos outros efeitos ambientais. “! ---” indica um modem a cabo que alcance seu nível da potência ascendente do máximo. Isto é indicativo de demasiada atenuação entre o modem a cabo e o CMTS, ou de 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 MAC address 005a.73f6.2213 está transmitindo em sua potência emissora máxima. Isto conduz a esse modem que não pode transmitir a nível correto. Consequentemente, as transmissões fluxo acima deste modem não são ouvidas tão claramente quanto transmissões do outro 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. Veja o guia de referência de comando do cabo da banda larga Cisco para obter mais informações sobre do modem a cabo e dos comandos show cable flap-list da mostra.

Nota: Mais detalhes sobre a identificação e a resolução de problemas de ruído RF podem ser encontrados em determinar RF ou problemas de configuração no CMTS e em conectar o Cisco uBR7200 Series Router ao fim do cabeçalho do cabo.

Uso da alta utilização da CPU no CMTS

Em algumas circunstâncias Cisco CMTS pode transformar-se sobrecarregado devido a uma configuração subótimo, sobre o uso de determinadas funções de gerenciamento, ou muito um alto número de pacotes que estão sendo distribuídos pelo CMTS.

A melhor maneira de determinar o USO de CPU de Cisco CMTS é executar o comando show process cpu. O USO de CPU atual é 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 processador central do processo da mostra é útil para determinar se uma processo ou função particular são a causa de CMTS alto CPU.

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

No exemplo acima, a carga de CPU atual no CMTS é 45 por cento percent/21. Isto significa que o USO de CPU total está em 45 por cento da capacidade do sistema. Além 21 por cento do CPU estão sendo usados para prestar serviços de manutenção a 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 de CPU de cinco minutos é consistentemente mais de 80 por cento durante o tempo de pico de uso no sistema, a seguir os utilizadores finais podem começar experimentar um desempenho e uma latência aumentada mais lentos. Se o USO de CPU de cinco minutos é constantemente mais de 95 por cento durante o tempo de pico de uso, a seguir tome a ação urgente assegurar-se de que o CMTS permaneça em um estado estável.

As estratégias comuns para reduzir o uso da alta utilização da CPU no CMTS incluem:

  • Promover ao Cisco IOS Software Release 12.1(9)EC ou Mais Recente, ativar o cef do global configuration command ip, e não se certificar de nenhuma relação no CMTS têm o comando no ip route-cache configurado. Isto conduz tipicamente a um por cento 10 a 15 por cento de redução em USO de CPU tráfego-relacionado. Verifique se todos os passos estão sendo realizados em conjunto.

  • Certificando-se de que as estações de gerenciamento do Simple Network Management Protocol (SNMP) não estão sendo demasiado agressivas em votar o CMTS. Isto conduz à alta utilização da CPU um uso no processo IP SNMP.

  • Sem executar o comando show tech sucessivamente. Isto conduz artificialmente à alta utilização da CPU um uso no processo de EXEC virtual.

  • Certificando-se de que os comandos no debug estão sendo executado no CMTS.

Para obter mais informações sobre do uso da alta utilização da CPU nos roteadores Cisco, incluindo produtos cmts de Cisco, refira pesquisando defeitos a utilização elevada 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 somente um ou um número limitado de usuários está experimentando a taxa de transferência lenta, e o resto da população de usuário não está experimentando nenhum problema, a seguir esta é uma indicação forte que pode haver um problema exclusivo dentro desse ambiente de usuário.

  • Sob o CPE posto ou sobrecarregado — Se a queixa dos utilizadores finais das dificuldades está usando o equipamento CPE antiquado, ou o equipamento que não pode ser poderoso bastante executar seu sistema operacional ou software escolhido do acesso ao Internet, a seguir este utilizador final terá dificuldades. A única resolução, se esse for o caso, é que o usuário final atualize seu equipamento CPE.

  • Software do Firewall ou da medida de desempenho — Se o utilizador final está executando qualquer Firewall, medição de desempenho da rede, ou o outro software similar, um bom passo de Troubleshooting é mandar o usuário desligar este software para considerar se tem algum efeito no desempenho. Frequentemente, estes tipos de software podem ter um impacto negativo no desempenho.

  • Ajustes desconfigurados TCP/IP — A maioria de provedores de serviços exigem que os utilizadores finais mandam seu equipamento CPE adquirir um endereço IP de Um ou Mais Servidores Cisco ICM NT, uma máscara de rede, um gateway padrão, e uns servidores DNS pelo protocolo de configuração dinâmica host (DHCP). Assegure-se de que todos os utilizadores finais que experimentam problemas tenham seus dispositivos CPE configurados para usar o DHCP para adquirir todos estes parâmetros.

Se um utilizador final reivindica não ter nenhuns dos problemas alistados acima, a seguir confirme que o utilizador final não está excedendo sua taxa máxima de download ou de upload conforme as seções acima.

Conclusão

Uma rede de cabo DOCSIS é um sistema sofisticado que exige o planeamento e a manutenção apropriados. A maioria de problemas de desempenho em sistemas do cabo DOCSIS são um resultado direto do planeamento apropriado e manutenção que não está sendo executada. No mercado de acesso ao Internet de hoje, onde há uma variedade de alternativas do acesso ao Internet de banda larga, é importante que os provedores de serviços de cabo endereçam rapidamente todas as edições do desempenho ou da congestão em seu sistema antes que os problemas se tornem significativos bastante para que os utilizadores finais sejam afetados visivelmente, e, consequentemente, consideram meios alternativos do acesso à banda larga.


Informações Relacionadas


Document ID: 12551