Usando o Agente de Garantia de Serviço da Cisco e o Monitor de Desempenho Inter-redes para gerenciar a qualidade do software em redes de voz sobre IP

Introduction

Este documento descreve o uso do Cisco Service Assurance Agent (SAA) e do Internetwork Performance Monitor (IPM) para medir a qualidade de serviço (QoS) em redes de Voz sobre IP (VoIP). Essas informações são baseadas em um projeto de telefonia IP real. Este documento concentra-se na aplicação dos produtos, não nos próprios produtos. Você já deve estar familiarizado com o Cisco SAA e o IPM e ter acesso à documentação do produto necessária. Consulte Informações Relacionadas para obter referências a outra documentação.

Observação: a funcionalidade SAA da Cisco no software Cisco IOS® era anteriormente conhecida como Response Time Reporter (RTR).

Ao gerenciar uma rede VoIP em larga escala, você deve ter as ferramentas necessárias para monitorar e relatar objetivamente a qualidade da voz na rede. Não é viável depender apenas do feedback do usuário, pois ele é muitas vezes subjetivo e incompleto. Problemas de qualidade de voz geralmente se originam de problemas de QoS da rede. Assim, quando você identifica problemas de qualidade de voz, precisa de uma segunda ferramenta para gerenciar e monitorar a QoS da rede. O exemplo neste documento usa Cisco SAA e IPM para essa finalidade.

O Cisco Voice Manager (CVM) é usado com Telemate.net para gerenciar a qualidade de voz. Ele relata a qualidade de voz das chamadas através do ICPIF (Imparidade/Fator de Imparidade de Planejamento Calculado) que é calculado por um gateway do Cisco IOS para cada chamada. Isso permite que o gerenciador de rede identifique locais que sofrem com qualidade de voz ruim. Consulte Gerenciamento da qualidade de voz com o Cisco Voice Manager (CVM) e Telemate para obter mais informações.

Prerequisites

Requirements

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

Componentes Utilizados

Este documento não está restrito a versões específicas de software ou hardware, mas os exemplos neste documento usam estas versões de software e hardware:

• Software Cisco IOS versão 12.1(4)

• IPM 2.5 para Windows NT

• Catalyst 4500 Series Switch

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.

Questões de QoS em uma rede VoIP

Vários fatores podem degradar a qualidade da voz em uma rede de voz em pacotes:

• Perda de pacotes

• Atraso excessivo

• Tremulação excessiva

É particularmente importante que você monitore esses números continuamente, se os serviços de comutação de pacotes forem usados na WAN (por exemplo, ATM, Frame Relay ou IP Virtual Private Network). Há vários cenários em que o congestionamento na rede da portadora, a modelagem de tráfego mal configurada nos dispositivos de borda ou a política mal configurada no lado da portadora podem causar perda de pacotes ou buffer excessivo. Quando a portadora está descartando pacotes, não há evidências óbvias nos dispositivos de borda. Portanto, você precisa de uma ferramenta de ponta a ponta, como o Cisco SAA, que possa injetar tráfego na entrada e validar sua chegada bem-sucedida à saída.

Gerenciamento de QoS com Cisco SAA e IPM

Há três componentes Cisco SAA e IPM:

• Prova RTR

• Respondendor RTR

• Console do IPM

A prova de RTR envia um burst de pacotes ao respondedor de RTR. O respondedor RTR os recupera e os envia de volta para a prova. Essa operação simples permite que a sonda meça a perda de pacotes e o retardo de round trip. Para medir o jitter, a sonda envia um pacote de controle ao respondente antes de iniciar o burst de pacote. O pacote de controle informa ao respondedor quantos milissegundos (ms) esperar entre cada pacote na intermitência. O respondedor mede o retardo entre pacotes durante a intermitência e qualquer desvio do intervalo esperado é registrado como atraso de sincronismo.

O console IPM controla o monitoramento de QoS. Ele programa os testadores RTR com as informações relevantes por meio do SNMP (Simple Network Management Protocol). Também coleta os resultados via SNMP. Nenhuma interface de linha de comando é necessária a configuração do Cisco IOS nos testadores RTR.

Emita o comando de configuração global rtr responder para configurar manualmente os respondedores RTR.

Os testadores e respondedores RTR devem executar o Cisco IOS Software Release 12.0(5)T ou posterior. A versão de manutenção mais recente do mainstream 12.1 é recomendada. Os testadores e respondedores RTR nos exemplos neste documento estão executando a versão 12.1(4). A versão do IPM em uso é o IPM 2.5 para Windows NT. Um patch está disponível no Cisco.com para esta versão. Esse patch é importante, pois corrige um problema em que o IPM configura os testadores RTR com uma configuração de precedência de IP incorreta.

Projeto

Antes de implantar uma solução Cisco SAA e IPM, você deve fazer algum trabalho de projeto tendo em mente estas considerações:

• Posicionamento das sondas RTR e dos respondedores

• Tipo de tráfego que é enviado do testador para o respondente

Há várias coisas a serem levadas em consideração quando você decide sobre a colocação de sondas e respondedores. Primeiramente, você quer que a medição de QoS abranja todos as estações, e não somente as estações com problemas. Isso porque os números de atraso e de instabilidade relatados pelo IPM para um determinado site são mais úteis quando comparados a outros sites na mesma rede. Assim, você deseja medir sites com boa QoS e má QoS. Além disso, um site com bom desempenho pode tornar-se um site com mau desempenho amanhã, devido a alterações nos padrões de tráfego ou alterações na rede. Você deve detectar isso antes que afete a qualidade de voz e seja relatado pelos usuários.

Segundo, a utilização da CPU é importante. Um roteador já ocupado pode não ser capaz de atender o componente RTR em tempo hábil, o que pode distorcer os resultados. Além disso, se você colocar muitas instâncias de sonda em um único roteador, você poderá criar problemas de alta utilização da CPU, mesmo que nenhuma tenha existido antes. A abordagem escolhida para o exemplo de rede neste documento (e isso deve funcionar na maioria das redes) é colocar os testadores RTR nos roteadores remotos/de filial. Normalmente, esses roteadores conectam uma única LAN a um serviço de WAN relativamente lento. Então, roteadores filiais costumam ter uma utilização de CPU muito baixa e podem facilmente lidar com RTR. O outro benefício deste projeto é que você distribui a carga pelo maior número possível de roteadores. Lembre-se de que é mais trabalho ser uma sonda do que ser um respondente, já que as sondas levam uma certa quantidade de sondagem SNMP.

Com esse design, os respondedores RTR devem ser colocados no núcleo. Os respondentes estarão mais ocupados que os testadores, pois eles responderão a muitas sondas. Assim, um design robusto implanta roteadores dedicados que atuam apenas como respondedores. A maioria das organizações desativou os roteadores na prateleira que podem executar essa função. Qualquer roteador com uma interface Ethernet é suficiente. Como alternativa, os roteadores de núcleo/distribuição podem dobrar como respondedores. O diagrama de rede nesta seção descreve ambos os cenários.

Espalhe a carga pelo maior número possível de roteadores e monitore o uso da CPU RTR com este comando:

Router# show processes cpu | i Rtt|PID

PID  Runtime(ms)  Invoked  uSecs  5Sec   1Min   5Min    TTY Process
67           0         7      0   0.00%  0.00%  0.00%   0 Rtt Responder

Quando você está combinando sondas com respondedores, é recomendável manter uma topologia consistente entre a prova e o respondente. Por exemplo, todos os testadores e respondedores devem ser separados pelo mesmo número de roteadores, Switches e links WAN. Somente então os resultados do IPM podem ser diretamente comparados entre sites.

Neste exemplo, há 200 locais remotos e quatro locais centrais/de distribuição. Um Catalyst 4500 em cada local de distribuição atua como um respondedor RTR dedicado. Cada um dos 200 roteadores remotos atua como uma prova RTR. Cada sonda visa o respondente localizado no local de distribuição diretamente conectado.

As intermitências do tráfego enviado pelas sondas aos respondedores devem receber da rede os mesmos níveis de QoS atribuídos à voz. Isso pode significar que você precisa ajustar as configurações de prioridade de enfileiramento de baixa latência (LLQ - Low Latency Queueing) ou protocolo de tabela de roteamento (RTP - Routing Table Protocol) no roteador, de modo que o tráfego dos testadores RTR esteja sujeito a enfileiramento de prioridade estrita. Quando você está configurando a sonda para pacotes RTP, somente a porta UDP (User Datagram Protocol) de destino pode ser controlada e não a porta de origem. Uma configuração típica do roteador LLQ neste exemplo de rede tem listas de acesso que classificam especificamente os pacotes RTR na mesma fila que a voz:

class-map VoiceRTP
  match access-group name IP-RTP

policy-map 192Kbps_site
  class VoiceRTP
    priority 110

ip access-list extended IP-RTP
  deny   ip any any fragments
  permit udp 10.0.16.0 0.255.239.255
             range 16384 32768 10.0.16.0 0.255.239.255
             range 16384 32768 precedence critical
  permit udp any any eq 20000 precedence critical
  permit udp any eq 20000 any precedence critical

A lista de acesso IP-RTP tem estas linhas de classificação:

• deny ip any any fragments

  Negue qualquer fragmento IP, pois uma lista de acesso da camada 4 permite isso implicitamente.

• permit udp 10.0.16.0 0.255.239.255 intervalo 16384 32768 10.0.16.0 0.255.239.255 intervalo 16384 3276 8 precedência crítica

  Permitir pacotes RTP de sub-redes de voz com precedência de IP definida como 5.

• permit udp any any eq 20000 prioridade crítica

  Permitir pacotes RTP da prova RTR que vai para o respondente RTR.

• permit udp any eq 20000 any precedence

  Permita que os pacotes RTP do respondente RTR voltem para a prova RTR.

Tenha cuidado para que a adição de tráfego RTR não faça com que as filas LLQ fiquem com excesso de assinaturas e faça com que os pacotes de voz reais sejam descartados. A operação IPM Default60ByteVoice padrão envia rajadas de pacotes RTP com estes parâmetros:

• Solicitar payload: 60 bytes

  Observação: este é o cabeçalho RTP e a voz. Adicione 28 bytes (IP/UDP) para obter o tamanho do datagrama L3.

• Intervalo: 20 ms

• Número de pacotes: 10

Isso significa que, durante uma rajada, o RTR consome 35,2 Kbs de largura de banda de LLQ. Se não houver largura de banda suficiente para o LLQ, crie então uma nova operação IPM e aumente o intervalo do pacote. Com os parâmetros mostrados nesta janela de configuração do IPM, uma intermitência consome apenas 1 Kbps de largura de banda:

Resultados

A tabela nesta seção é um exemplo de um relatório do IPM. Esse relatório contém três instâncias de prova de RTR. Lembre-se de que uma sonda física pode ser configurada com várias instâncias de prova RTR que têm como alvo respondedores diferentes ou usam payloads diferentes.

Estes são os significados de cada uma das colunas:

Média:

O IPM calcula uma média para cada hora de amostragem. Essas médias em horas são então calculadas em um período mais longo para obter-se médias diárias, semanais ou mensais. Em outras palavras, para o relatório diário, o IPM calcula a média para cada hora das últimas 24 horas. Em seguida, calcula a média diária como a média dessas 24 médias.

Média máxima:

Esse valor é a média de todos os máximos horários para cada dia, semana e mês no gráfico. Em outras palavras, para o relatório diário, o IPM toma a maior amostra relatada em cada uma das últimas 24 horas. Em seguida, calcula a média diária máxima como a média dessas 24 amostras.

Mais de %:

Essa é a porcentagem de amostras que estavam acima do limite configurado para o coletor.

Erro %:

Esta é a porcentagem de pacotes que encontraram um erro. Uma sonda de variação de sinal relata vários tipos de erros:

• Perda de pacote SD—Pacotes perdidos entre a origem e o destino

• Perda de pacote DS—Pacotes perdidos entre o destino e a origem

• Negócios—O número de ocasiões em que uma operação de tempo de ida e volta (RTT) não pôde ser iniciada porque uma operação anterior de RTT não foi concluída.

• Sequência—O número de conclusões da operação RTT recebidas com um identificador de sequência inesperado. Estes são alguns dos possíveis motivos pelos quais isso pode ocorrer:

  • Um pacote duplicado foi recebido.

  • Uma resposta foi recebida após o tempo limite.

  • Um pacote corrompido foi recebido e não foi detectado.

• Quedas — O número de ocasiões em que uma destas ocorreu:

  • Não foi possível iniciar uma operação de RTT porque algum recurso interno necessário não estava disponível (por exemplo, memória ou o subsistema de Arquitetura de Rede de Sistemas [SNA])

  • Não foi possível reconhecer a conclusão da operação.

• MIA (Missing in Action) — O número de pacotes perdidos para os quais não é possível determinar nenhuma direção.

• Atrasado—O número de pacotes que chegaram após o tempo limite.

A questão que surge dessas informações é que os valores de retardo, atraso de sincronismo e erro são aceitáveis em uma rede VoIP. Infelizmente, não há uma resposta simples para esta pergunta. Os valores aceitáveis dependem do tipo de codec, da variação de sinal, do tamanho do buffer e de outros fatores. Além disso, existem interdependências entre estas variáveis. Uma perda de pacotes mais alta pode significar uma tolerância menor a variações de sinal.

A melhor forma de obter cenários de retardo trabalháveis e de sincronismo é comparar os sites semelhantes nessa mesma rede. Se todos os sites conectados a 192 Kbps, mas apenas um, relatarem valores de variação de sinal em torno de 50 ms, e o site restante relatar variação de sinal de 100 ms, então há um problema, independentemente dos valores nominais. O IPM pode fornecer medição contínua de retardo e jitter 24 horas por dia, 7 dias por semana para toda a rede e pode fornecer uma linha de base para uso como referência para comparações de retardo e jitter.

No entanto, os erros são diferentes. Em princípio, qualquer porcentagem de erro diferente de zero é um flag vermelho. O mesmo tratamento de QoS é dado para pacotes de RTR como pacotes de voz. Se a rede QoS e o controle de admissão de chamada forem robustos, nenhum nível de congestionamento deverá causar a perda de pacote ou o retardo excessivo de pacotes de voz ou RTR. Portanto, você pode esperar que as contagens de erros do IPM sejam zero. Os únicos erros que poderiam ser considerados "normais" são erros de verificação de redundância cíclica (CRC), mas eles devem ser raros em uma infraestrutura de qualidade. Se forem frequentes, constituem um risco à qualidade da voz.

Informações Relacionadas

• Leitura Recomendada: Troubleshooting da Telefonia IP Cisco
• Suporte Técnico e Documentação - Cisco Systems