As modernas comunicações por modem analógico tornaram-se muito complexas. As tecnologias mais recentes não dependem mais de um simples layout básico, mas esperam que a rede da empresa de telecomunicações (Telco) seja totalmente criada com tecnologia digital. Isso levou a um aumento drástico na largura de banda ao custo de uma complexidade maior. A maior parte da conectividade de chamada de modem agora depende dos componentes mostrados no diagrama a seguir:
Não existem requisitos específicos para este documento.
Este documento não se restringe a versões de software e hardware específicas.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
Os loops locais fornecem uma interface sem erros com a nuvem Telco. Um cliente remoto pode ter um loop analógico ou digital, e os servidores de acesso geralmente são projetados para operar em um loop digital. Se um dos loops falhar, a conectividade adicional entre as extremidades também falhará.
A nuvem Telco transmite os sinais digitais de forma transparente, de ponta a ponta. Caso um link no meio não atenda a esse requisito (por exemplo, conversões analógicas a digitais extras, compactações de canal de voz, perdas esporádicas de dados, etc.), a conectividade do modem provavelmente será afetada, mesmo que nenhuma das extremidades veja nada de errado com seu loop.
Em resumo, baixa taxa de sucesso de chamada (CSR), velocidades de conexão baixas, retragens frequentes e assim por diante não são necessariamente os sintomas de um projeto de modem ruim. Talvez não sejam os modems que precisam ser verificados primeiro.
Esta seção lista problemas comuns relacionados a modems e fornece informações sobre como corrigi-los.
Às vezes, os clientes que fazem chamadas de modem (V.92, V.90, V.34) e digitais (ISDN, Switched 56, V.110 ou V.120) relatam problemas de conectividade.
Conforme discutido na introdução, os protocolos de modem são transmitidos na parte superior da tecnologia digital. Como suas origens estão em comunicações analógicas mais suscetíveis a erros, os protocolos de modem são mais robustos e adaptáveis aos erros de linha. O problema pode não ser muito perceptível, mas ainda está lá. Primeiro, identifique e solucione problemas de chamadas digitais:
Verifique as estatísticas do controlador e da interface para garantir que a linha entre o servidor de acesso e a troca Telco mais próxima esteja livre de erros. Para clientes e servidores de acesso que usam equipamentos Cisco, você pode verificar as estatísticas nos níveis de controlador e interface. Para produtos de terceiros, siga a documentação do fornecedor ou obtenha um analisador de protocolo. As estatísticas precisam também ser verificadas no lado da Telco (caso o problema afete somente os sinais enviados para o intercâmbio Telco mais próximo);
Se os contadores estiverem limpos, mas a linha não for terminada diretamente na troca Telco (há extensores ou trocas de linha intermediários envolvidos), verifique se há erros em todo o caminho para a troca Telco;
Depois de confirmar a limpeza da linha, verifique a sinalização. Para técnicas de Troubleshooting de Sinais Associados de Canal (CAS - Channel Associate Signals), consulte Troubleshooting de Conexões ISDN.
Para obter mais informações, consulte Visão geral do modem geral e da qualidade da linha NAS.
Observação: execute todas essas verificações antes de tentar solucionar problemas do modem
Clientes com determinadas contas ou que ligam de determinados locais não podem se conectar. Algumas marcas de modem tentam se conectar, sem resultados satisfatórios, enquanto os clientes em outros locais não parecem ser afetados.
Esses problemas provavelmente não são provocados pelos próprios modems. As contas (IDs de número chamado, nomes e senhas) são tratadas por protocolos ou aplicativos que residem no topo dos protocolos de modem (PPP, AAA, RPMS, etc.). Talvez não ajude solucionar problemas do modem se os protocolos ou aplicativos precisarem ser removidos ou alterados.
Para continuar, tente solucionar problemas:
Aponte para Point Protocol (PPP). Consulte Tecnologia de discagem: Técnicas para Troubleshooting.
Autenticação, Autorização e Contabilidade (AAA).
Servidor do Resource Pool Manager (RPMS).
A menos que recursos especiais estejam envolvidos (por exemplo, usando a ID do número de chamada ou o número chamado), o problema parece estar em algum lugar na nuvem Telco. Se você realocar o mesmo modem em um local diferente, apenas um fator será alterado: o caminho da chamada. Se a alteração for suficiente para resolver o problema, os endpoints serão configurados corretamente e talvez você não precise solucionar mais o problema. A linha Telco entre o servidor de acesso e o intercâmbio Telco mais próximo está presumivelmente OK, já que somente determinados clientes têm o problema. Uma solução possível é encontrar as configurações do modem, o que permitiria que os modems se conectassem apesar dos problemas da empresa de telecomunicações. Para obter detalhes, consulte Modems de ajuste fino.
Observação: esta solução não é uma solução. Para encontrar uma solução, entre em contato com a sua empresa de telecomunicações de forma a investigar a linha entre o cliente e o intercâmbio de telecomunicações mais próximo e mais além ao longo do caminho de chamadas
Ocasionalmente, os clientes em determinados locais relatam conectividade ruim. Isso inclui velocidades de conexão baixas, frequentemente retratos, altas taxas de erro, etc. Algumas marcas de modem tentam se conectar sem resultados satisfatórios, enquanto outros locais não parecem ser afetados.
A menos que recursos especiais estejam envolvidos (por exemplo, usando a ID do número de chamada ou o número chamado para RPMS), o problema parece estar em algum lugar na nuvem Telco. Quando você usa o mesmo modem em um local diferente, apenas um fator muda: O caminho da chamada (dentro da nuvem da Telco, os caminhos para chamadas de entrada e de saída podem variar). Se a alteração for suficiente para resolver o problema, os endpoints serão configurados corretamente e talvez você não precise solucionar mais o problema. A linha Telco entre o servidor de acesso e a troca Telco mais próxima é presumivelmente aceitável, pois apenas locais específicos têm o problema. O problema ocorre mais provavelmente com o intercâmbio Telco mais próximo do cliente. Verifique se as chamadas em questão chegam ao servidor de acesso, como explicado na Tecnologia de discagem: Técnicas para Troubleshooting.
Se a chamada for concluída, e a linha Telco entre o cliente e a troca Telco mais próxima parecer estar limpa também (por exemplo, se o cliente não vir o problema quando ligar para outros números locais, como o San-Jose Dial-in Lab ou o Laboratório de discagem da Austrália), talvez seja necessário verificar o caminho da chamada inteira para solucionar o problema.
Para verificar o caminho da chamada:
Primeiro, verifique a fiação interna como possível origem do problema.
Conecte dois modems cliente de volta à fiação (para fazer com que um modem faça uma chamada sem esperar pelo tom de discagem, use ATX3D e faça o outro modem responder sem esperar pelo sinal de toque usar ATA). Depois que os modems se formam e entram no modo de dados, geram algum tráfego na linha, depois usam a sequência de escape (normalmente Hayes ++ ou TIES +++AT) para comutar os modems para o modo de comando e verificam os parâmetros da linha (Signal-to-Noise Ratio [SNR], qualidade do sinal, retraições e assim por diante).
Desconecte todo o equipamento conectado na mesma linha do telefone em paralelo com o modem.
Execute um fio de telefone (preferencialmente quad ou Par Trançado Não Blindado [UTP - Unshielded Twisted Pair]) desde a interface de rede até o modem.
Certifique-se de que o modem cliente está executando o firmware mais recente de seu fabricante (consistente com os protocolos suportados pelo modem do servidor). Verifique também se deseja reconfigurar o modem cliente para que ele possa se conectar com mais eficiência. Consulte Ajuste perfeito de modems para obter mais detalhes. Por exemplo, você pode tentar limitar a velocidade DCE do modem do cliente. Se for um cliente Rockwell, tente usar AT+MS=56,1,300,42000 para tentar uma conexão K56Flex a 42 Kbps. Como alternativa, tente +MS=11,1,300,19200 para uma conexão V.34 de 19.2 Kbps.
Ative o registro de modem no cliente para uma análise mais detalhada.
Se você usa o Microsoft Windows, verifique o código de desconexão.
Verifique o diagnóstico de conexão com um modem USR AT i11 ou um modem Lucent AT i11
.
Caso use um Winmodem acionado pela CPU, pergunte ao fornecedor do modem como obter o comando AT existente para solucionar problemas de uma conexão. Alguns fornecedores de modem usam o código de diagnóstico UnIModem da Microsoft (AT#UG).
A investigação do caminho de chamada pode exigir um envolvimento mais próximo da sua empresa de telecomunicações. Para identificar os possíveis problemas, verifique os parâmetros de conexão para as chamadas específicas com o comando show modem operational-status, conforme discutido em Visão geral do modem geral e qualidade da linha NAS. Para obter mais informações, consulte esta Nota de Versão. Uma solução possível é encontrar as configurações do modem, o que permitiria que os modems se conectassem, apesar dos problemas de empresa de telecomunicações. Consulte Modems de ajuste fino.
Embora os clientes em alguns locais possam se conectar, a chamada cai depois de algum tempo. Algumas marcas de modem tentam se conectar sem resultados satisfatórios, enquanto outros locais não parecem ser afetados.
A menos que recursos especiais estejam envolvidos (por exemplo, ID de chamada ou ID do número chamado para RPMS), o problema parece estar em algum lugar da nuvem Telco. Se você usar o mesmo modem em um local diferente, apenas um fator muda: o caminho da chamada (lembre-se também de que, na nuvem da Telco, os caminhos para chamadas de entrada e saída podem ser diferentes). Se a alteração for suficiente para resolver o problema, é provável que o servidor de acesso esteja configurado corretamente e talvez você não precise que você faça Troubleshooting adicional. A linha Telco entre o servidor de acesso e a troca de Telco mais próxima está presumivelmente correta, desde que apenas locais específicos acertem o problema. Para verificar se o cliente dial-up não é a raiz do problema, verifique se:
O cliente não inicia a desconexão do PPP. Consulte Tecnologia de discagem: Técnicas para Troubleshooting.
O cliente não inicia a desconexão do modem. Os motivos para a desconexão do modem no registro de modem estão explicados nestes documentos:
O cliente não inicia a desconexão ISDN. Veja a causa da desconexão de ISDN para obter mais informações. (Ver também Nota 3.)
Se a investigação revelar que as chamadas estão desconectadas devido a erros de conectividade de montagem, tente encontrar configurações de modem que permitam que os modems se conectem apesar dos problemas da Telco. Para obter detalhes, consulte Modems de ajuste fino.
Observação: esta solução não é uma solução. Para encontrar uma solução, entre em contato com a sua empresa de telecomunicações de forma a investigar a linha entre o cliente e o intercâmbio de telecomunicações mais próximo e mais além ao longo do caminho de chamadas.
Às vezes, alguns modelos de modems não conseguem se conectar, enquanto outros modelos no mesmo local podem fazer isso. Algumas vezes, essa pode ser uma questão de compatibilidade de fornecedor. Para identificar por que exatamente a desconexão ocorre, verifique o log do modem para saber os motivos da desconexão. (Ver também Nota 1):
A solução possível é identificar as configurações que habilitariam os modems para evitar o problema de compatibilidade. Para obter detalhes, consulte Modems de ajuste fino. Se nenhuma solução alternativa ajudar (por exemplo, desativar todos os recursos proprietários), entre em contato com o fornecedor do modem cliente para Troubleshooting adicional.
Assegure-se de remover o PPP. O modem cliente deve discar de um programa terminal, como o Windows HyperTerminal, usando comandos AT. Configure o servidor de acesso de modo que ele não inicie o PPP automaticamente para todos os usuários, mas permite um logon exec (por exemplo, via async mode interactive na interface de grupo assíncrono e autoselect PPP nas linhas). Isso permite que o cliente controle e obtenha informações úteis diretamente do modem e, uma vez conectado, possa gerar tráfego exec para estressar a conexão.
No terminal do cliente, inicie o registro da sessão (selecione Transferir > Capturar Texto no HyperTerminal).
Obtenha as seguintes informações do modem do cliente:
ATI, ATI0, ATI1, ATI2.
AT&V0, AT&V1, AT&V2.
Observação: alguns comandos podem retornar ERROR em alguns modems. Você pode ignorar tais erros.
Restaure os padrões de fábrica do modem (ou as configurações desejadas) e verifique se o alto-falante está sempre ligado:
AT&F
ATL2M2
Comece a gravar a chamada em um arquivo .WAV. Para fazer isso no Windows NT, selecione Iniciar > Programas > Acessórios > Multimídia > Gravador de Som.
O botão vermelho inicia a gravação, mas não a pressiona até que você comece a discar. Na janela HyperTerminal, inicia a discagem.
ATDT <number>
Se a chamada não for conectada ou se a modulação necessária não for negociada, pare a gravação depois que NÃO HOUVER CARRIER aparecer na janela do terminal. Se o problema for que a chamada se conecta conforme desejado, mas depois de algum tempo ela é desconectada, continue a gravar o arquivo .WAV. Você precisa pressionar o botão de gravação vermelha novamente a cada minuto se usar o Gravador de som.
Se a chamada se conectar, na modulação desejada ou indesejada, reúna as seguintes informações interessantes enquanto estiver conectada.
no lado do servidor, as informações show modem operational-status (MICA, NextPort) ou modem at-mode / at@e1 (Microcom).
no lado do cliente, saia para o modo AT através de ++ e obtenha ATI6, AT&V1, AT&V2. Você poderá voltar on-line com o ATO.
Quando a chamada estiver concluída, salve o arquivo Gravador de som. Para fazer isso, selecione Arquivo > Salvar como > Formatar alteração.
Formato: PCM
Atributos: 8,000 kHz, 8 Bits, Mono 7 kb/seg
Nome do arquivo: filename.wav
Envie as informações coletadas ao Cisco Technical Assistance Center (TAC) para análise.
Modelos específicos enfrentam conectividade ruim em termos de velocidades de conexão baixas, frequentemente retratos, altas taxas de erro e assim por diante. Outros modelos nos mesmos locais têm boa conectividade.
Algumas vezes, essa pode ser uma questão de compatibilidade de fornecedor. Para identificar por que exatamente a desconexão acontece, verifique o log do modem para saber os motivos da desconexão. (Ver também Nota 1):
A investigação a seguir também pode esclarecer por que certos modems cliente falham:
Primeiro, verifique a fiação interna como possível origem do problema.
Conecte dois modems cliente de volta à fiação (para fazer com que um modem faça uma chamada sem esperar pelo tom de discagem, use ATX3D e para fazer o outro modem responder sem esperar pelo sinal de toque, use ATA). Depois que os modems se formam e entram no modo de dados, geram algum tráfego na linha, depois usam a sequência de escape (normalmente Hayes ++ ou TIES +++AT) para comutar os modems para o modo de comando e verificar os parâmetros da linha (SNR, qualidade do sinal, retrens, etc.).
Desconecte todo o equipamento conectado na mesma linha do telefone em paralelo com o modem.
Instale um fio de telefone (preferivelmente quad ou UTP) da interface da rede diretamente para o modem.
Certifique-se de que o modem cliente está executando o firmware mais recente de seu fabricante (consistente com os protocolos suportados pelo modem do servidor). Também reconfigure o modem do cliente para que ele possa se conectar com mais eficiência. Consulte Modems de ajuste fino para obter detalhes. Por exemplo, você pode tentar limitar a velocidade DCE do modem do cliente. Se for um cliente Rockwell, tente AT+MS=56,1,300,42000 para tentar uma conexão K56Flex a 42 Kbps. Como alternativa, tente +MS=11,1,300,19200 para uma conexão V.34 de 19.2 Kbps.
Ative o registro de modem no cliente para uma análise mais detalhada.
Se você usa o Microsoft Windows, verifique o código de desconexão.
Verifique o diagnóstico de conexão com um modem USR AT i11 ou um modem Lucent AT i11
.
Caso use um Winmodem acionado pela CPU, pergunte ao fornecedor do modem como obter o comando AT existente para solucionar problemas de uma conexão. Alguns fornecedores de modem usam o código de diagnóstico UnIModem da Microsoft (AT#UG).
Uma solução possível é encontrar as configurações, o que permitiria que os modems evitem o problema de compatibilidade. Consulte Ajuste de modems. Se nenhuma solução alternativa ajudar (por exemplo, desabilitar retrens nos modems internos do servidor de acesso), entre em contato com o fornecedor do modem do cliente para solucionar problemas.
Alguns modelos de modems podem se conectar, mas depois a chamada cai. Outros modelos nos mesmos locais permanecem conectados.
Algumas vezes, essa pode ser uma questão de compatibilidade de fornecedor. Para identificar por que a desconexão acontece, verifique o seguinte (consulte também a Nota 1):
Se a terminação PPP foi solicitada. Consulte Tecnologia de discagem: Técnicas para Troubleshooting.
Se a terminação do modem foi solicitada. Razões da desconexão do modem no registro do modem estão explicados em:
Causa de desconexão ISDN. (Ver também Nota 3).
Se a investigação revelar que as chamadas estão desconectadas devido a erros de conectividade de montagem, uma possível solução é obter o firmware ou as configurações mais recentes do modem, que permitem que os modems evitem o problema de compatibilidade. Para obter detalhes e uma matriz de compatibilidade, consulte Modems de ajuste fino. Se a solução alternativa não ajudar (como limitar a velocidade máxima manualmente ou usar capping de modem agressivo), entre em contato com o fornecedor do modem cliente para solucionar problemas.
Falha na conexão de chamadas de vários locais com diferentes modelos de modem para determinados números (DS1 ou servidor de acesso). Os mesmos clientes nos mesmos locais se conectam corretamente a outros números locais (como o San-Jose Dial-in Lab ou o Australia Dial-In Lab).
Verifique se há erros nas estatísticas dos níveis de controlador e interface (consulte a introdução para obter mais informações). Por exemplo, se o servidor de acesso terminar mais de uma linha Telco, certifique-se de que todas as linhas estejam sincronizadas (normalmente significa que as linhas devem ser retiradas do mesmo provedor), como explicado na Sincronização de Relógio. A verificação precisa ser feita nos lados do servidor de acesso e da Telco (se o problema afetar os sinais que vêm do servidor de acesso à troca Telco mais próxima, o servidor de acesso pode não relatar erros). Antes de prosseguir com a solução de problemas de modem, certifique-se de que não haja praticamente erros na camada T1/E1.
Em seguida, certifique-se de que as chamadas cheguem ao servidor de acesso, conforme explicado na Tecnologia de discagem: Técnicas para Troubleshooting. Se as chamadas chegarem, verifique o comando show controller <e1|t1> call-counters. Para alguns problemas de Telco, determinados canais DS0 geralmente relatam tempos de conexão muito baixos e um número muito alto de chamadas.
Para o último teste, a Telco precisa permitir que o servidor de acesso seja chamado por si mesmo através da troca Telco. Verifique também se não há nenhuma conversão analógica para digital irrelevante no caminho entre o servidor de acesso e o Switch. Isto produz um eco de extremidade próxima, os quais os modems digitais podem não ter capacidade de processar, e impede que as conexões de modem PCM funcionem. Ao provisionar um link T1 ou E1 para a Telco, certifique-se de que haja um caminho puramente digital entre o servidor de acesso e o switch Telco. Esse é o caso se houver um link T1 ou E1 direto para o switch. Se os canais forem roteados através de um banco de canais, por exemplo, e assim convertidos de digital para analógico e novamente, a integridade digital dos canais é perdida. Isto significa que:
A modulação de modem Pulse code modulation (PCM) (V.90, K56Flex ou X2) não pode ser usada. Somente V.34 e inferior podem ser usados, e até mesmo o desempenho V.34 pode ser prejudicado.
Não é possível fornecer serviços digitais como dados 56 ou ISDN comutados.
Os modems digitais, como o MICA, não funcionarão bem, devido ao alto nível de eco de extremidade próxima.
Os sintomas típicos em MICA com uma conversão A-D próxima são:
Sem portadora PCM (K56Flex ou V.90).
Portadora V.34 média (19.2 - 26.4) para chamadas locais.
As chamadas de longa distância não podem ser treinadas em V.34, V.32bis ou V.32. No entanto, se o modem cliente estiver limitado a 2400bps V.22bis, ele pode treinar bem.
Nota: V.22bis não requer cancelamento de eco.
Se a Telco não puder fornecer um caminho puramente digital para o servidor de acesso, a MICA (ou outros modems digitais) não são recomendados e é melhor usar modems V.34 analógicos, como Sara (modems analógicos integrados Microcom nos roteadores Cisco 2600 ou 3600).
Para determinar se o caminho para o switch é adequado para modems digitais, faça o seguinte:
Assegure-se de que a linha DS1 seja provisionada para permitir discagem.
Ative debug modem e debug modem csm ou debug csm para identificar qual modem atende à chamada.
Estabeleça uma conexão telnet reversa para um modem e faça a chamada.
Depois que os modems se treinarem, gere algum tráfego (como, por exemplo, terminal length 0 e show tech-support) e verifique show modem operational-status em ambas as extremidades.
Os sintomas mais típicos que indicam problemas com a linha até a troca Telco mais próxima são:
Retransmissões de correção regular de erros (EC).
Aumento contínuo no contador total de retrens.
Valor de SQ (Signal Quality, qualidade do sinal) inferior a três.
Relação sinal/ruído (SNR) abaixo de 30 dB.
Nível de recepção muito abaixo do nível de transmissão.
Deslocamento de frequência diferente de zero, frequência de jitter de fase, nível de jitter de fase ou rolo de fase.
Nível de eco distante inferior a -40 dB.
Intervalos no meio da forma de linha ou alterações consideráveis na(s) extremidade(s).
Eco de extremidade próxima (também conhecido como locutor ou local) é uma parte do sinal de um originador que é refletido de volta ao originador, do escritório central local (CO), sobre o loop local do originador. Eco de extremidade próxima normalmente é visto por modems em linhas analógicas já que é causado pela incompatibilidade de impedância no híbrido, que é o transformador que une o circuito local analógico de 2 fios com a rede de transmissão Telco de 4 fios.
O eco da extremidade oposta é a parte do sinal analógico transmitido que saltou da extremidade próxima analógica do modem remoto.
No diagrama a seguir:
FEC - Eco de extremidade oposta
NEC - Eco de extremidade próxima
Modulações modernas (V.32 e acima) usam canceladores de eco para permitir que sinais transmitidos e recebidos ocupem simultaneamente a mesma banda de freqüência. Eles têm um processador de sinal digital (DSP) para controlar o sinal transmitido e depois subtrair esse sinal do sinal recebido. Os modems de cliente modernos (linha lateral analógica) contêm canceladores de eco de extremidade próxima e de extremidade oposta. Modems MICA contêm canceladores de eco de extremidade oposta e não de extremidade próxima, pois eles não esperam ser conectados a um circuito local analógico. Com uma conexão digital local, não deve haver virtualmente nenhum eco de extremidade próxima.
Aqui estão alguns exemplos de saída show modem operational-status de um T1 (digital para o switch) bom e um T1 ruim (A-D convertido). Além da diferença no eco distante, observe também a diferença de SNR (41 dB vs. 35 dB) que resulta em uma portadora perfeita de 3600 em comparação a uma portadora medíocre de 28800.
Boa conexão
isdn2-9>show modem operation 1/55 Modem(1/55) Operational-Status: Parameter #0 Disconnect Reason Info: (0x0) Type (=0 ): <unknown> Class (=0 ): Other Reason (=0 ): no disconnect has yet occurred Parameter #1 Connect Protocol: LAP-M Parameter #2 Compression: V.42bis both Parameter #3 EC Retransmission Count: 0 Parameter #4 Self Test Error Count: 0 Parameter #5 Call Timer: 44 secs Parameter #6 Total Retrains: 0 Parameter #7 Sq Value: 4 Parameter #8 Connected Standard: V.34+ Parameter #9 TX,RX Bit Rate: 33600, 33600 Parameter #11 TX,RX Symbol Rate: 3429, 3429 Parameter #13 TX,RX Carrier Frequency: 1959, 1959 Parameter #15 TX,RX Trellis Coding: 16, 16 Parameter #16 TX,RX Preemphasis Index: 0, 0 Parameter #17 TX,RX Constellation Shaping: Off, Off Parameter #18 TX,RX Nonlinear Encoding: Off, Off Parameter #19 TX,RX Precoding: Off, Off Parameter #20 TX,RX Xmit Level Reduction: 0, 0 dBm Parameter #21 Signal Noise Ratio: 41 dB Parameter #22 Receive Level: -12 dBm Parameter #23 Frequency Offset: 0 Hz Parameter #24 Phase Jitter Frequency: 0 Hz Parameter #25 Phase Jitter Level: 0 degrees Parameter #26 Far End Echo Level: -73 dBm Parameter #27 Phase Roll: 22 degrees Parameter #28 Round Trip Delay: 3 msecs Parameter #30 Characters transmitted, received: 83, 3194 Parameter #32 Characters received BAD: 0 Parameter #33 PPP/SLIP packets transmitted, received: 0, 0 Parameter #35 PPP/SLIP packets received (BAD/ABORTED): 0 Parameter #36 EC packets transmitted, received OK: 81, 105 Parameter #38 EC packets (Received BAD/ABORTED): 0 Parameter #39 Robbed Bit Signalling (RBS) pattern: 0 Parameter #40 Digital Pad: None, Digital Pad Compensation: None Line Shape: .........* ........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* *
T1 (CAS) defeituoso - conexão de banco de canal com o switch - eco de extremidade oposta é -36dBm
term-server-1#show modem operation 1/38 Modem(1/38) Operational-Status: Parameter #0 Disconnect Reason Info: (0x0) Type (=0 ): <unknown> Class (=0 ): Other Reason (=0 ): no disconnect has yet occurred Parameter #1 Connect Protocol: LAP-M Parameter #2 Compression: V.42bis both Parameter #3 EC Retransmission Count: 2 Parameter #4 Self Test Error Count: 0 Parameter #5 Call Timer: 96 secs Parameter #6 Total Retrains: 1 Parameter #7 Sq Value: 3 Parameter #8 Connected Standard: V.34+ Parameter #9 TX,RX Bit Rate: 28800, 28800 Parameter #11 TX,RX Symbol Rate: 3429, 3429 Parameter #13 TX,RX Carrier Frequency: 1959, 1959 Parameter #15 TX,RX Trellis Coding: 16, 16 Parameter #16 TX,RX Preemphasis Index: 0, 6 Parameter #17 TX,RX Constellation Shaping: Off, Off Parameter #18 TX,RX Nonlinear Encoding: Off, Off Parameter #19 TX,RX Precoding: Off, Off Parameter #20 TX,RX Xmit Level Reduction: 0, 0 dBm Parameter #21 Signal Noise Ratio: 35 dB Parameter #22 Receive Level: -13 dBm Parameter #23 Frequency Offset: 0 Hz Parameter #24 Phase Jitter Frequency: 0 Hz Parameter #25 Phase Jitter Level: 0 degrees Parameter #26 Far End Echo Level: -36 dBm Parameter #27 Phase Roll: 0 degrees Parameter #28 Round Trip Delay: 6 msecs Parameter #30 Characters transmitted, received: 8636, 116 Parameter #32 Characters received BAD: 0 Parameter #33 PPP/SLIP packets transmitted, received: 0, 0 Parameter #35 PPP/SLIP packets received (BAD/ABORTED): 0 Parameter #36 EC packets transmitted, received OK: 124, 63 Parameter #38 EC packets (Received BAD/ABORTED): 4 Parameter #39 Robbed Bit Signalling (RBS) pattern: 0 Parameter #40 Digital Pad: None, Digital Pad Compensation: None Line Shape: .........* ......* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .......* ........* *
Para obter detalhes, consulte Visão geral da qualidade da linha NAS e do modem geral e esta nota de versão.
Se os testes não indicarem nenhum problema com a linha, continue com a Telco ao longo dos caminhos de chamada.
As chamadas de vários locais com vários modelos de modem para determinados números (DS1 ou servidor de acesso) têm conectividade ruim em termos de velocidades de conexão baixas, geralmente retratos, altas taxas de erros, etc. Os mesmos clientes nos mesmos locais têm boa conectividade quando ligam para outros números locais (como o San-Jose Dial-in Lab ou o Austrália Dial-in Lab).
Verifique se há erros nas estatísticas dos níveis de controlador e interface (consulte a introdução para obter mais informações). Por exemplo, se o servidor de acesso terminar mais de uma linha Telco, certifique-se de que todas as linhas estejam sincronizadas (normalmente significa que as linhas devem ser retiradas do mesmo provedor), como explicado na Sincronização de Relógio. A verificação precisa ser feita nos lados do servidor de acesso e da Telco (se o problema afetar os sinais que vêm do servidor de acesso à troca Telco mais próxima, o servidor de acesso pode não relatar erros).
Se você verificou que as coisas estão bem na camada T1 ou E1, mas as coisas não se comportam de forma aceitável na camada de modem, aqui estão algumas coisas a serem verificadas:
Coletar estatísticas representativas (ver também nota 1) em que lado inicia as desconexões e qual é a razão para tal. Para o lado do servidor de acesso, os motivos da desconexão são explicados em:
Verifique se os modems de ajuste fino causam algum impacto nos tempos de conexão ou nos motivos de desconexão.
Certifique-se de usar um bom código de modem (consulte Modems de ajuste fino)
Certifique-se de ajustar os caminhos DS0 através da Telco para um desempenho ideal. Observe que subotimizações podem ser encontradas em qualquer lugar do caminho DS0/3.1 KHz:
No cabeamento das instalações do modem cliente (por exemplo, ramais).
O loop local do cliente (loop longo, bobinas de carga, derivações de bridge).
Na configuração de um Switch existe muito - ou insuficiente – preenchimento digital ou analógico
Troncos problemáticos dentro da Telco (antigos enlaces de micro-ondas, antigos troncos analógicos de quatro fios E&M).
Para poder desconsiderar (em sua maioria) a rede de transmissão e circuitos locais da rede de telecomunicações, é recomendável discar de seu próprio cliente válido conhecido (modem e circuito para o Switch de telecomunicações mais próximo) para o servidor de acesso de destino. Se você obter uma conexão com a qualidade desejada, provará que o servidor de acesso, seus modems e sua linha DS1 estão saudáveis.
Para determinar se o caminho para o switch é adequado para modems digitais, faça o seguinte:
Assegure-se de que a linha DS1 seja provisionada para permitir discagem.
Ative debug modem e debug modem csm ou debug csm para identificar qual modem atende à chamada.
Estabeleça uma conexão telnet reversa para um modem e faça a chamada.
Depois que os modems se treinarem, gere algum tráfego (como, por exemplo, terminal length 0 e show tech-support) e verifique show modem operational-status em ambas as extremidades.
Os sintomas mais típicos que indicam problemas com a linha até a troca Telco mais próxima são:
Retransmissões de correção regular de erros (EC).
Aumento contínuo no contador total de retrens.
Valor de SQ (Signal Quality, qualidade do sinal) inferior a três.
Relação sinal/ruído (SNR) abaixo de 30 dB.
Nível de recepção muito abaixo do nível de transmissão.
Deslocamento de frequência diferente de zero, frequência de jitter de fase, nível de jitter de fase ou rolo de fase.
Nível de eco distante inferior a -40 dB.
Intervalos no meio da forma de linha ou alterações consideráveis na(s) extremidade(s).
O eco de extremidade próxima (também conhecido como talker ou local) é uma parte do sinal de um originador refletida de volta ao originador, do CO local, sobre o circuito local do orginador. Eco de extremidade próxima normalmente é visto por modems em linhas analógicas já que é causado pela incompatibilidade de impedância no híbrido, que é o transformador que une o circuito local analógico de 2 fios com a rede de transmissão Telco de 4 fios.
O eco da extremidade oposta é a parte do sinal analógico transmitido que saltou da extremidade próxima analógica do modem remoto.
No diagrama a seguir:
FEC - Eco de extremidade oposta
NEC - Eco de extremidade próxima
Modulações modernas (V.32 e acima) usam canceladores de eco para permitir que sinais transmitidos e recebidos ocupem simultaneamente a mesma banda de freqüência. Eles têm um DSP para controlar o sinal transmitido e depois subtrair esse sinal do sinal recebido. Os modems de cliente modernos (linha lateral analógica) contêm canceladores de eco de extremidade próxima e de extremidade oposta. Modems MICA contêm canceladores de eco de extremidade oposta e não de extremidade próxima, pois eles não esperam ser conectados a um circuito local analógico. Com uma conexão local digital, não deve haver (virtualmente) nenhum eco de extremidade próxima.
Aqui estão exemplos de show modem operational-status de um T1 bom (digital para o switch) e ruim (A-D convertido). Além da diferença no eco distante, observe também a diferença de SNR (41 dB vs. 35 dB) que resulta em uma portadora perfeita de 3600 em comparação a uma portadora medíocre de 28800.
Boa conexão
isdn2-9>show modem operation 1/55 Modem(1/55) Operational-Status: Parameter #0 Disconnect Reason Info: (0x0) Type (=0 ): <unknown> Class (=0 ): Other Reason (=0 ): no disconnect has yet occurred Parameter #1 Connect Protocol: LAP-M Parameter #2 Compression: V.42bis both Parameter #3 EC Retransmission Count: 0 Parameter #4 Self Test Error Count: 0 Parameter #5 Call Timer: 44 secs Parameter #6 Total Retrains: 0 Parameter #7 Sq Value: 4 Parameter #8 Connected Standard: V.34+ Parameter #9 TX,RX Bit Rate: 33600, 33600 Parameter #11 TX,RX Symbol Rate: 3429, 3429 Parameter #13 TX,RX Carrier Frequency: 1959, 1959 Parameter #15 TX,RX Trellis Coding: 16, 16 Parameter #16 TX,RX Preemphasis Index: 0, 0 Parameter #17 TX,RX Constellation Shaping: Off, Off Parameter #18 TX,RX Nonlinear Encoding: Off, Off Parameter #19 TX,RX Precoding: Off, Off Parameter #20 TX,RX Xmit Level Reduction: 0, 0 dBm Parameter #21 Signal Noise Ratio: 41 dB Parameter #22 Receive Level: -12 dBm Parameter #23 Frequency Offset: 0 Hz Parameter #24 Phase Jitter Frequency: 0 Hz Parameter #25 Phase Jitter Level: 0 degrees Parameter #26 Far End Echo Level: -73 dBm Parameter #27 Phase Roll: 22 degrees Parameter #28 Round Trip Delay: 3 msecs Parameter #30 Characters transmitted, received: 83, 3194 Parameter #32 Characters received BAD: 0 Parameter #33 PPP/SLIP packets transmitted, received: 0, 0 Parameter #35 PPP/SLIP packets received (BAD/ABORTED): 0 Parameter #36 EC packets transmitted, received OK: 81, 105 Parameter #38 EC packets (Received BAD/ABORTED): 0 Parameter #39 Robbed Bit Signalling (RBS) pattern: 0 Parameter #40 Digital Pad: None, Digital Pad Compensation: None Line Shape: .........* ........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* *
T1 (CAS) defeituoso - conexão de banco de canal com o switch - eco de extremidade oposta é -36dBm
term-server-1#show modem operation 1/38 Modem(1/38) Operational-Status: Parameter #0 Disconnect Reason Info: (0x0) Type (=0 ): <unknown> Class (=0 ): Other Reason (=0 ): no disconnect has yet occurred Parameter #1 Connect Protocol: LAP-M Parameter #2 Compression: V.42bis both Parameter #3 EC Retransmission Count: 2 Parameter #4 Self Test Error Count: 0 Parameter #5 Call Timer: 96 secs Parameter #6 Total Retrains: 1 Parameter #7 Sq Value: 3 Parameter #8 Connected Standard: V.34+ Parameter #9 TX,RX Bit Rate: 28800, 28800 Parameter #11 TX,RX Symbol Rate: 3429, 3429 Parameter #13 TX,RX Carrier Frequency: 1959, 1959 Parameter #15 TX,RX Trellis Coding: 16, 16 Parameter #16 TX,RX Preemphasis Index: 0, 6 Parameter #17 TX,RX Constellation Shaping: Off, Off Parameter #18 TX,RX Nonlinear Encoding: Off, Off Parameter #19 TX,RX Precoding: Off, Off Parameter #20 TX,RX Xmit Level Reduction: 0, 0 dBm Parameter #21 Signal Noise Ratio: 35 dB Parameter #22 Receive Level: -13 dBm Parameter #23 Frequency Offset: 0 Hz Parameter #24 Phase Jitter Frequency: 0 Hz Parameter #25 Phase Jitter Level: 0 degrees Parameter #26 Far End Echo Level: -36 dBm Parameter #27 Phase Roll: 0 degrees Parameter #28 Round Trip Delay: 6 msecs Parameter #30 Characters transmitted, received: 8636, 116 Parameter #32 Characters received BAD: 0 Parameter #33 PPP/SLIP packets transmitted, received: 0, 0 Parameter #35 PPP/SLIP packets received (BAD/ABORTED): 0 Parameter #36 EC packets transmitted, received OK: 124, 63 Parameter #38 EC packets (Received BAD/ABORTED): 4 Parameter #39 Robbed Bit Signalling (RBS) pattern: 0 Parameter #40 Digital Pad: None, Digital Pad Compensation: None Line Shape: .........* ......* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .......* ........* *
Para obter detalhes, consulte Visão geral da qualidade da linha NAS e do modem geral e esta nota de versão.
Se os loops nos switches Telco mais próximos (tanto do lado do cliente quanto do lado do servidor de acesso) parecerem limpos e as subotimizações estiverem em algum lugar no caminho Telco, aqui estão algumas coisas que você pode fazer:
Faça uma chamada não-EC em V.22bis a 2400 bps. Se o circuito estiver em bom estado de funcionamento, praticamente não devem ser vistos erros. Se você deixar a conexão ociosa e observar erros recorrentes (especialmente com o código 0x7B, '{' em ASCII), isso indica a presença de lapsos de relógio (controlados) (por exemplo, dentro dos T-spans da Telco, raramente vistos)
Se os níveis de potência de transmissão ou recepção vistos em nossos clientes forem muito altos ou muito baixos, ajuste os níveis de transmissão e adicione ou remova o revestimento de linha ou tronco.
Se você vir uma portadora V.34 saudável, mas receber conexões PCM (Pulse Code Modulation) fracas ou sem pulso (onde o código PCM nos clientes é conhecido por ser compatível com os modems do servidor):
Verifique se os caminhos dos circuitos para os modems clientes podem manter uma conexão PCM. Em outras palavras, certifique-se de que eles não tenham uma conversão analógica a digital extra.
Examine o preenchimento digital no caminho.
Prossiga com a empresa de telecomunicações para investigar mais os caminhos de chamada.
As chamadas de vários locais com vários modelos de modem para conexão com determinado(s) número(s) (DS1 ou servidor de acesso) funcionam corretamente, mas depois a chamada cai. Os mesmos clientes nos mesmos locais têm boa conectividade quando ligam para outros números locais (como o San-Jose Dial-in Lab ou o Austrália Dial-in Lab).
Primeiro, verifique as estatísticas nos níveis de controlador e interface para verificar se há erros (consulte a introdução para obter mais informações). Por exemplo, se o servidor de acesso terminar mais de uma linha Telco, certifique-se de que todas as linhas estejam sincronizadas (normalmente significa que as linhas devem ser retiradas do mesmo provedor), como explicado na Sincronização de Relógio. A verificação precisa ser feita nos lados do servidor de acesso e da Telco (se o problema afetar os sinais que vêm do servidor de acesso à troca Telco mais próxima, o servidor de acesso pode não relatar erros).
Em seguida, certifique-se de que as chamadas cheguem ao servidor de acesso, conforme explicado na Tecnologia de discagem: Técnicas para Troubleshooting. Em seguida, verifique os contadores de chamada do comando show controller <e1|t1>. Para alguns problemas de Telco, determinados canais DS0 geralmente relatam tempos de conexão muito baixos e um número muito alto de chamadas. Coletar estatísticas representativas (ver também Nota 1) em que lado inicia as desconexões e qual é o motivo:
Se a terminação PPP foi solicitada. Consulte Tecnologia de discagem: Técnicas para Troubleshooting.
Se a terminação do modem foi solicitada. Razões da desconexão do modem no registro do modem estão explicados em:
Causa de desconexão ISDN. (Ver também Nota 3).
Se a chamada for desconectada devido a erros de conectividade de montagem, consulte se o ajusto fino dos modems causa algum impacto nos tempos de conexão e/ou nos motivos para desconexão.
Certifique-se de usar um bom código de modem (consulte Modems de ajuste fino)
Certifique-se de ajustar os caminhos DS0 através da Telco para um desempenho ideal. Observe que subotimizações podem ser encontradas em qualquer lugar do caminho DS0/3.1 KHz:
No cabeamento das instalações do modem cliente (por exemplo, ramais).
O loop local do cliente (loop longo, bobinas de carga, derivações de bridge).
Na configuração de um Switch existe muito - ou insuficiente – preenchimento digital ou analógico
Troncos problemáticos dentro da Telco (antigos enlaces de micro-ondas, antigos troncos analógicos de quatro fios E&M).
Para poder desconsiderar (em sua maioria) a rede de transmissão e circuitos locais da rede de telecomunicações, é recomendável discar de seu próprio cliente válido conhecido (modem e circuito para o Switch de telecomunicações mais próximo) para o servidor de acesso de destino. Se você obter uma conexão com a qualidade desejada, provará que o servidor de acesso, seus modems e sua linha DS1 estão saudáveis.
Para determinar se o caminho para o switch é adequado para modems digitais, faça o seguinte:
Assegure-se de que a linha DS1 seja provisionada para permitir discagem.
Ative debug modem e debug modem csm ou debug csm para identificar qual modem atende à chamada.
Estabeleça uma conexão telnet reversa para um modem e faça a chamada.
Depois que os modems se treinarem, gere algum tráfego (por exemplo, terminal length 0 e show tech-support) e verifique show modem operational-status em ambas as extremidades.
Os sintomas mais típicos que indicam problemas com a linha até a troca Telco mais próxima são:
Retransmissões de correção regular de erros (EC).
Aumento contínuo no contador total de retrens.
Valor de SQ (Signal Quality, qualidade do sinal) inferior a três.
Relação sinal/ruído (SNR) abaixo de 30 dB.
Nível de recepção muito abaixo do nível de transmissão.
Deslocamento de frequência diferente de zero, frequência de jitter de fase, nível de jitter de fase ou rolo de fase.
Nível de eco distante inferior a -40 dB.
Intervalos no meio da forma de linha ou alterações consideráveis na(s) extremidade(s).
O eco de extremidade próxima (também conhecido como talker ou local) é uma parte do sinal de um originador refletida de volta ao originador, do CO local, sobre o circuito local do orginador. Eco de extremidade próxima normalmente é visto por modems em linhas analógicas já que é causado pela incompatibilidade de impedância no híbrido, que é o transformador que une o circuito local analógico de 2 fios com a rede de transmissão Telco de 4 fios.
O eco da extremidade oposta é a parte do sinal analógico transmitido que saltou da extremidade próxima analógica do modem remoto.
O eco da extremidade oposta é a parte do sinal analógico transmitido que saltou da extremidade próxima analógica do modem remoto.
No diagrama a seguir:
FEC - Eco de extremidade oposta
NEC - Eco de extremidade próxima
Modulações modernas (V.32 e acima) usam canceladores de eco para permitir que sinais transmitidos e recebidos ocupem simultaneamente a mesma banda de freqüência. Eles têm um DSP para controlar o sinal transmitido e depois subtrair esse sinal do sinal recebido. Os modems de cliente modernos (linha lateral analógica) contêm canceladores de eco de extremidade próxima e de extremidade oposta. Modems MICA contêm canceladores de eco de extremidade oposta e não de extremidade próxima, pois eles não esperam ser conectados a um circuito local analógico. Com uma conexão local digital, não deve haver (virtualmente) nenhum eco de extremidade próxima.
Aqui estão exemplos de show modem operational-status de um T1 bom (digital para o switch) e ruim (A-D convertido). Além da diferença no eco distante, observe também a diferença de SNR (41 dB vs. 35 dB) que resulta em uma portadora perfeita de 3600 em comparação a uma portadora medíocre de 28800.
Boa conexão
isdn2-9>show modem operational 1/55 Modem(1/55) Operational-Status: Parameter #0 Disconnect Reason Info: (0x0) Type (=0 ): <unknown> Class (=0 ): Other Reason (=0 ): no disconnect has yet occurred Parameter #1 Connect Protocol: LAP-M Parameter #2 Compression: V.42bis both Parameter #3 EC Retransmission Count: 0 Parameter #4 Self Test Error Count: 0 Parameter #5 Call Timer: 44 secs Parameter #6 Total Retrains: 0 Parameter #7 Sq Value: 4 Parameter #8 Connected Standard: V.34+ Parameter #9 TX,RX Bit Rate: 33600, 33600 Parameter #11 TX,RX Symbol Rate: 3429, 3429 Parameter #13 TX,RX Carrier Frequency: 1959, 1959 Parameter #15 TX,RX Trellis Coding: 16, 16 Parameter #16 TX,RX Preemphasis Index: 0, 0 Parameter #17 TX,RX Constellation Shaping: Off, Off Parameter #18 TX,RX Nonlinear Encoding: Off, Off Parameter #19 TX,RX Precoding: Off, Off Parameter #20 TX,RX Xmit Level Reduction: 0, 0 dBm Parameter #21 Signal Noise Ratio: 41 dB Parameter #22 Receive Level: -12 dBm Parameter #23 Frequency Offset: 0 Hz Parameter #24 Phase Jitter Frequency: 0 Hz Parameter #25 Phase Jitter Level: 0 degrees Parameter #26 Far End Echo Level: -73 dBm Parameter #27 Phase Roll: 22 degrees Parameter #28 Round Trip Delay: 3 msecs Parameter #30 Characters transmitted, received: 83, 3194 Parameter #32 Characters received BAD: 0 Parameter #33 PPP/SLIP packets transmitted, received: 0, 0 Parameter #35 PPP/SLIP packets received (BAD/ABORTED): 0 Parameter #36 EC packets transmitted, received OK: 81, 105 Parameter #38 EC packets (Received BAD/ABORTED): 0 Parameter #39 Robbed Bit Signalling (RBS) pattern: 0 Parameter #40 Digital Pad: None, Digital Pad Compensation: None Line Shape: .........* ........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* *
T1 (CAS) defeituoso - conexão de banco de canal com o switch - eco de extremidade oposta é -36dBm
term-server-1#show modem operational 1/38 Modem(1/38) Operational-Status: Parameter #0 Disconnect Reason Info: (0x0) Type (=0 ): <unknown> Class (=0 ): Other Reason (=0 ): no disconnect has yet occurred Parameter #1 Connect Protocol: LAP-M Parameter #2 Compression: V.42bis both Parameter #3 EC Retransmission Count: 2 Parameter #4 Self Test Error Count: 0 Parameter #5 Call Timer: 96 secs Parameter #6 Total Retrains: 1 Parameter #7 Sq Value: 3 Parameter #8 Connected Standard: V.34+ Parameter #9 TX,RX Bit Rate: 28800, 28800 Parameter #11 TX,RX Symbol Rate: 3429, 3429 Parameter #13 TX,RX Carrier Frequency: 1959, 1959 Parameter #15 TX,RX Trellis Coding: 16, 16 Parameter #16 TX,RX Preemphasis Index: 0, 6 Parameter #17 TX,RX Constellation Shaping: Off, Off Parameter #18 TX,RX Nonlinear Encoding: Off, Off Parameter #19 TX,RX Precoding: Off, Off Parameter #20 TX,RX Xmit Level Reduction: 0, 0 dBm Parameter #21 Signal Noise Ratio: 35 dB Parameter #22 Receive Level: -13 dBm Parameter #23 Frequency Offset: 0 Hz Parameter #24 Phase Jitter Frequency: 0 Hz Parameter #25 Phase Jitter Level: 0 degrees Parameter #26 Far End Echo Level: -36 dBm Parameter #27 Phase Roll: 0 degrees Parameter #28 Round Trip Delay: 6 msecs Parameter #30 Characters transmitted, received: 8636, 116 Parameter #32 Characters received BAD: 0 Parameter #33 PPP/SLIP packets transmitted, received: 0, 0 Parameter #35 PPP/SLIP packets received (BAD/ABORTED): 0 Parameter #36 EC packets transmitted, received OK: 124, 63 Parameter #38 EC packets (Received BAD/ABORTED): 4 Parameter #39 Robbed Bit Signalling (RBS) pattern: 0 Parameter #40 Digital Pad: None, Digital Pad Compensation: None Line Shape: .........* ......* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .........* .......* ........* *
Para obter detalhes, consulte Visão geral da qualidade da linha NAS e do modem geral e esta nota de versão.
Se os loops nos switches Telco mais próximos (tanto do lado do cliente quanto do lado do servidor de acesso) parecerem limpos e as subotimizações estiverem em algum lugar no caminho Telco, aqui estão algumas coisas que você pode fazer:
Faça uma chamada não-EC em V.22bis a 2400 bps. Se o circuito estiver em bom estado de funcionamento, praticamente não devem ser vistos erros. Se você deixar a conexão ociosa e observar erros recorrentes (especialmente com o código 0x7B, '{' em ASCII), isso indica a presença de lapsos de relógio (controlados) (por exemplo, dentro dos T-spans da Telco, raramente vistos)
Se os níveis de potência de transmissão ou recepção vistos em nossos clientes forem muito altos ou muito baixos, ajuste os níveis de transmissão e adicione ou remova o revestimento de linha ou tronco.
Se você vir uma portadora V.34 saudável, mas receber conexões PCM (Pulse Code Modulation) fracas ou sem pulso (onde o código PCM nos clientes é conhecido por ser compatível com os modems do servidor):
Verifique se os caminhos dos circuitos para os modems clientes podem manter uma conexão PCM. Em outras palavras, certifique-se de que eles não tenham uma conversão analógica a digital extra.
Examine o preenchimento digital no caminho.
Prossiga com a empresa de telecomunicações para investigar mais os caminhos de chamada.
Para solucionar esse problema, faça o seguinte:
Verifique se a chamada chega ao servidor de acesso com a tecnologia de discagem: Técnicas para Troubleshooting.
Verifique se as chamadas ISDN têm o recurso de portador correto e certifique-se de que DoV não esteja configurado.
Verifique se os modems estão configurados para selecionar chamadas de voz.
Verifique se as configurações de tampa de modem, conforme explicado em Operações de Gerenciamento de Modem (consulte também Nota 2), estão corretas (por exemplo, o registro S0 não está definido como 0 ou um valor muito alto):
Se for utilizado RPM ou RPMS, verifique primeiro se o problema persiste depois que o recurso é desativado. Se isto ajudar, prossiga com o RPM configurado localmente e verifique a configuração de modemcap.
Verifique se os canais B não estão ocupados (show isdn active) e se há modems livres (show modem). Se os modems estiverem marcados como defeituosos, isso pode ser um problema de hardware ou software.
A falha de hardware reside normalmente em uma determinada placa portadora ou uma placa de modem. Os modems não precisam necessariamente ser marcados como ruins, mas falham em todas as chamadas desde a inicialização. A solução é a substituição do hardware.
Em caso de falha de software, os modems geralmente funcionam bem após cada reinicialização, mas depois são marcados como inválidos aleatoriamente (podem estar nos clusters de um, dois, três, seis ou 12 na mesma placa de modem) ou todas as outras chamadas simplesmente falham. Se o problema for detectado apenas durante as horas de pico, utilize o comando show modem para verificar as estatísticas do modem. Uma alta taxa de No Answer espalhada uniformemente em todos os modems indica que o servidor de acesso simplesmente não pode lidar com tal volume de chamadas. Se uma taxa alta de No Answer for específica a apenas alguns modems, ainda assim será possível que ela indique uma falha de software. Recarga de firmware é uma solução. A solução é atualizar o software e ter a recuperação automática de modem ativada (para os roteadores Cisco 3600, o módulo de rede [NM] pode precisar de substituição se a saída do comando show diag indicar que o número da peça não é a versão -02: 800-0553x-02). Para obter mais informações, consulte os modems MICA e Nextport.
Às vezes, os modems atendem chamadas, mas não treinam. Para verificar isso, colete estatísticas representativas (ver também a Nota 1) em que lado inicia as desconexões e qual é o motivo. Para o lado do servidor de acesso, os motivos para desconexão são explicados em:
Além disso, o CSR deve estar diminuindo e os modems devem parar em algum lugar no meio das transições de estado do modem.
Primeiramente, verifique se o país de modem está configurado corretamente. Verifique se há erros no controlador ou na interface nos lados do servidor de acesso e da Telco (caso o problema afete os sinais provenientes do servidor de acesso para o intercâmbio Telco mais próximo, o servidor de acesso não poderá relatar nenhum erro). Se for utilizado RPM ou RPMS, verifique se o problema persiste depois que o recurso é desativado. Tente configurar localmente o RPM e verifique se as configurações de tampa de modem, como explicado em Operações de Gerenciamento de Modem (consulte também a Nota 2), estão corretas:
Verifique as estatísticas do modem usando o comando show modem (MICA) ou show spe (NextPort). Se clusters de um, dois, três, seis ou 12 modems dentro da mesma placa de modem tiverem um número invulgarmente alto de chamadas com falha ou estiverem marcados como defeituosos, isso pode ser um problema de hardware ou software.
Em caso de falha de hardware, é típico ficar com uma determinada placa portadora ou uma determinada placa de modem. Os modems não precisam necessariamente ser marcados como ruins, mas falharam em todas as chamadas desde a inicialização. A solução é a substituição do hardware.
Em caso de falha de software, é típico que os modems funcionem bem logo após cada reinicialização, mas posteriormente são marcados como inválidos aleatoriamente (podem estar em clusters de um, dois, três, seis ou 12 dentro da mesma placa de modem) ou simplesmente falham em todas as outras chamadas. Recarga de firmware é uma solução. A solução é atualizar o software e ter a recuperação automática do modem ativada (para os roteadores Cisco 3600, o NM pode precisar de substituição se a saída de show diag mostrar que o número da peça não é a versão -02: 800-0553x-02). Para obter mais informações, consulte os modems MICA e Nextport.
Se o problema não for encontrado específico para a arquitetura do servidor de acesso, veja se os modems de ajuste fino causam algum impacto nos tempos de conexão e nos motivos de desconexão.
Esses problemas podem ser igualmente atribuídos à empresa de telecomunicações, ao(s) modem(s) cliente ou ao servidor de acesso. Se nenhuma estatística prévia para o local estiver disponível, as recomendações para oITU-T V.56 Series podem trabalhar para uma primeira aproximação de taxas de conexão em proporções que você pode esperar. Verifique quanto a erros no controlador e na interface. A verificação precisa ser feita no servidor de acesso e nos lados Telco (se o problema afetar os sinais recebidos do servidor de acesso para a troca Telco mais próxima, o servidor de acesso talvez não reporte nenhum erro). Talvez seja necessário continuar com a empresa de telecomunicações por todo o caminho.
Se for utilizado RPM ou RPMS, verifique primeiro se o problema persiste depois que o recurso é desativado. Se isso ajudar, investigue o RPM e o modemcap configurados localmente, conforme explicado abaixo.
Verifique se as configurações de tampa de modem, conforme explicado em Operações de Gerenciamento de Modem (consulte também Nota 2), estão corretas:
Tente sintonizar os modems e veja se isso traz alguma melhoria. Verifique os parâmetros de conexão para as chamadas específicas com show modem operational-status, conforme discutido em Visão geral do modem geral e da qualidade da linha NAS e nesta Nota de versão para identificar os possíveis problemas.
Para verificar isso, verifique o motivo da desconexão nos registros do modem. Verifique se o CSR não diminui e se os modems passam por todas as transições de estado com êxito. Na verificação de configuração:
Se o PPP no servidor de acesso está configurado no modo interativo ou dedicado. Se o PPP estiver definido para ser selecionado interativamente e o cliente não enviar a sequência de seleção automática do PPP, conforme especificado no RFC 1662, a conectividade do PPP do ponto de vista do servidor de acesso será impossível. Investigue o lado do cliente ou Telco.
Se as linhas de modem e a interface de modem (geralmente a interface de grupo assíncrono) estão configuradas corretamente (para configurações de exemplo, consulte a introdução a esta seção ou Tecnologia de discagem: Técnicas de Troubleshooting).
Se algum modems é deixado órfão fora do intervalo de grupos de interfaces assíncronas. Ninguém deve ficar órfão.
Verifique se os clientes, a Telco ou o servidor de acesso iniciam as desconexões.
Primeiro, verifique se o link PPP foi terminado corretamente (essa desconexão pode ser iniciada pelo cliente ou pelo servidor de acesso) com a tecnologia de discagem: Técnicas para Troubleshooting.
Se o PPP não tiver sido finalizado corretamente, o Telco poderá ser o motivo. Decodifique os motivos da desconexão no registro do modem. (Ver também Nota 1).
Se os modems também relatarem uma desconexão inesperada, a Telco pode estar com falha. É melhor compor os motivos da desconexão em ambas as extremidades da conexão. Consulte a causa da desconexão de ISDN. (Ver também Nota 3).
Se o servidor de acesso tiver interrompido a conexão, verifique se o tráfego interessante está definido corretamente na interface do discador correspondente. O comando debug dialer events deve reportar se o servidor de acesso desconectou chamadas no intervalo.
Se as quedas forem iniciadas pelos clientes, é improvável que a solução de problemas do servidor de acesso ajude. Tente as recomendações da seção de solução de problemas de modem do cliente e continue investigando o lado do cliente primeiro. Mesmo se ocorrerem quedas abruptas para cada cliente testado, esse fato sozinho não é suficiente para identificar o que faz com que eles sejam desconectados do servidor de acesso. Se os resultados da investigação exigirem assistência adicional da Cisco, documente suas descobertas e abra um caso no Cisco TAC.
Para identificar se o CSR é alto ou baixo, você precisa de números de referência típicos da área. O objetivo é alcançar um CSR de 95%. No entanto, em um ambiente de ISP, com uma ampla variedade de modems cliente em um enorme intervalo de condições de loop local, é um objetivo difícil de alcançar. Como o CSR é um problema complexo, é muito difícil citar índices de êxito com relação às chamadas. Isso ocorre devido a várias condições que afetam uma chamada de modem. Por exemplo:
Quais tipos de switch estão em uso?
O site usa COs tandem?
As linhas foram qualificadas (testes BERT, etc.) para garantir que estão limpas?
Qual é a qualidade e integridade da fábrica de cabo de cobre?
A topologia de chamadas inclui nós analógicos?
Os bancos de memória de canal ou placas de SLIC estão sendo usados na rede?
As linhas são E1s ISDN PRI ou canalizadas?
Qual é a distribuição de modems clientes?
Nota: Estes são apenas alguns dos fatores.
As estatísticas devem ser representativas. Deve haver pelo menos dez chamadas por modem para que se possa chegar a conclusões preliminares, mas, em geral, é recomendável esperar até que existam alguns milhares de chamadas (consulte a Nota 1). Cada conexão de modem é única. Duas chamadas do mesmo modem para o mesmo número de destino podem passar por dois caminhos completamente diferentes por meio da rede PSTN e podem terminar em modems host físicos diferentes. O loop local, a conexão de cobre a partir das premissas do cliente até o intercâmbio local, pode sofrer de condições ambientais exclusivas desse cliente, embora a maioria dos provedores locais tente garantir que a característica de loop local se encaixe em uma faixa aceitável. Os modems clientes utilizam grupos de chips diferentes que variam de um fabricante para outro e, com freqüência, dentro de linhas de produtos do mesmo fabricante.
Estes são os parâmetros que você deve monitorar:
CSR: show modem summary
Velocidades da conexão: show modem connect-speed, show modem log (MICA) ou show port modem log (NextPort)
Sinal para razão de ruído (SNR): show modem operational-status (MICA, NextPort), AT@E1 (Microcom), show modem log (MICA) ou show port modem log (NextPort)
Níveis de transmissão e recebimento: show modem operational-status (MICA, NextPort), AT@E1 (Microcom)
Protocolos e modulações de modem: show modem log (MICA) ou show port modem log (NextPort)
Modem desconectados: show modem call-stats
Retrens e retransmissões de blocos CE: show modem log (MICA) ou show port modem log (NextPort), show modem operational-status (MICA, NextPort)
Para obter mais detalhes, consulte Visão geral da qualidade da linha NAS e do modem geral e esta nota de versão.
É aceitável que o CSR relatado pelos servidores de acesso da Cisco seja um pouco menor do que o CSR relatado por servidores de acesso de terceiros devido às diferenças na forma como eles consideram a chamada bem-sucedida. Nos servidores de acesso da Cisco, a chamada é marcada como bem-sucedida somente depois de ter êxito na fase inicial de treinamento e na fase de negociação EC (a menos que a EC seja negociada, os dados do usuário não podem ser passados pelo link). Servidores de acesso de terceiros tendem a considerar a chamada como bem sucedida imediatamente depois que o treinamento inicial passar (ou seja, nenhuma falha EC é levada em consideração).
O problema de CSR baixo pode ser igualmente atribuído ao Telco, aos clientes ou ao servidor de acesso. Tente melhorar o CSR ajustando modems. Para solucionar problemas de modems e da Telco, consulte a seção Troubleshooting de Modems de Cliente. Esses sintomas são típicos para problemas com o servidor de acesso:
show modem relata clusters de um, dois, três, seis ou 12 modems na mesma placa de modem com um número invulgarmente alto de chamadas com falha ou sem resposta.
show modemcall-stats relata clusters de um, dois, três, seis ou 12 modems dentro da mesma placa com mais de 10% de suas desconexões atribuídas a colunas do que dtrDrop ou hostDrop e rmtLink (o lossCarr também pode contar uma boa desconexão, se os modems cliente não terminarem o LAP-M antes de desconectar);
os clusters de um, dois, três, seis ou 12 modems na mesma placa de modem estão marcados como ruins, mas, após o recarregamento do firmware, podem receber chamadas novamente.
Se os sintomas corresponderem, atualize o software e configure a recuperação automática do modem. Para obter mais informações, consulte os modems MICA e Nextport.
Para automatizar a análise de estatísticas de modem, use as ferramentas disponíveis como parte da iniciativa de código aberto (COSI)
centralizada na Cisco.
Para automatizar a análise da tampa de modem, use as ferramentas disponíveis como parte da iniciativa de código aberto (COSI)
centralizada na Cisco.
A análise de sinalização ISDN pode ser automatizada usando as ferramentas disponíveis como parte da iniciativa de código aberto (COSI)
centrada na Cisco.
Revisão | Data de publicação | Comentários |
---|---|---|
1.0 |
03-Sep-2006 |
Versão inicial |