Este documento descreve métodos para medir o atraso, o jitter e a perda de pacotes na rede de dados usando as características Service Assurance Agent (SAA) e Round Trip Time Monitor (RTTMON) do Cisco IOS® e os roteadores Cisco.
Com o surgimento de novos aplicativos em redes de dados, está se tornando cada vez mais importante para os clientes preverem com precisão o impacto de novas implantações de aplicativos. Não há muito tempo, era fácil alocar largura de banda para aplicativos e permitir que os aplicativos se adaptassem à natureza explosiva dos fluxos de tráfego através das funções de timeout e retransmissão dos protocolos da camada superior. Agora, no entanto, os aplicativos do novo mundo, como voz e vídeo, são mais susceptíveis a mudanças nas características de transmissão das redes de dados. É imperativo entender as características de tráfego da rede antes da implantação de novos aplicativos do mundo para garantir implementações bem-sucedidas.
Voz sobre IP (VoIP) é susceptível a comportamentos de rede, conhecidos como atraso e jitter, que podem degradar o aplicativo de voz a ponto de ser inaceitável para o usuário médio. Atraso é o tempo decorrido de ponto a ponto em uma rede. O atraso pode ser medido em um sentido ou em um round trip delay. Cálculos de atraso unidirecional exigem equipamento de teste sofisticado e caro e estão além do orçamento e da experiência da maioria dos clientes corporativos. No entanto, medir o atraso de ida e volta é mais fácil e exige equipamentos mais baratos. Para obter uma medição geral do atraso unidirecional, meça o atraso de ida e volta e divida o resultado por dois. O VoIP geralmente tolera atrasos de até 150 ms antes que a qualidade da chamada seja inaceitável.
O jitter é a variação no atraso ao longo do tempo de ponto a ponto. Se o atraso das transmissões variar muito em uma chamada VoIP, a qualidade da chamada é muito reduzida. A quantidade de variação de sinal tolerável na rede é afetada pela profundidade do buffer de variação de sinal no equipamento de rede no caminho de voz. Quanto mais buffer de jitter disponível, mais a rede pode reduzir os efeitos do jitter.
A perda de pacotes está perdendo pacotes ao longo do caminho de dados, o que degrada severamente o aplicativo de voz.
Antes de implantar aplicativos de VoIP, é importante avaliar o atraso, o jitter e a perda de pacotes na rede de dados para determinar se os aplicativos de voz funcionam. As medições de atraso, instabilidade e perda de pacotes podem ajudar no projeto e na configuração corretos da priorização de tráfego, bem como nos parâmetros de buffer no equipamento de rede de dados.
O SAA e o RTTMON MIB são recursos do software Cisco IOS disponíveis nas versões 12.0 (5)T e posterior. Esses recursos permitem testar e coletar estatísticas de atraso, instabilidade e perda de pacotes na rede de dados. O Internetwork Performance Monitor (IPM) é um aplicativo de gerenciamento de rede da Cisco que pode configurar os recursos e monitorar os dados SAA e RTTMON. Os recursos SAA e RTTMON podem ser usados para medir atraso, instabilidade e perda de pacotes ao implantar pequenos roteadores Cisco IOS como agentes para simular estações finais do cliente. Os roteadores são chamados de sondas de retardo e jitter. Além disso, os testadores de retardo e jitter podem ser configurados com os disparadores de eventos e alarmes de monitoração remota (RMON) depois que os valores da linha de base são determinados. Isso permite que as sondas de retardo e jitter monitorem a rede para níveis de serviço de retardo e jitter predeterminados e para estações NMS (Network Management System, sistema de gerenciamento de rede) de alerta quando um limiar é excedido.
O retardo e o jitter podem ser medidos com a implantação de roteadores Cisco 17xx ou superiores com o código do software Cisco IOS versão 12.05T ou superior e com a configuração dos recursos ASA do Cisco IOS. Os roteadores devem ser colocados nas redes do campus ao lado dos hosts. Isso fornece estatísticas para conexões fim-a-fim. Como não é prático medir cada caminho de voz possível na rede, coloque os testadores em locais de host típicos, fornecendo uma amostragem estatística de caminhos de voz típicos. Alguns exemplos incluem:
um caminho de campus para campus local
um caminho de campus local para campus remoto através de um circuito Frame Relay de 384 kbs
um campus local para remoto via circuito virtual permanente (PVC - Permanent Virtual Circuit) ATM
No caso de implantações de VoIP usando telefones tradicionais conectados a roteadores Cisco usando portas FXS (Foreign Exchange Station), use o roteador conectado aos telefones para servir como prova de retardo e jitter. Depois de implantada, a sonda coleta estatísticas e preenche as tabelas MIB do Protocolo de Gerenciamento de Rede Simples (SNMP - Simple Network Management Protocol) no roteador. Os dados podem ser acessados por meio do aplicativo Cisco IPM ou por meio de ferramentas de pesquisa SNMP. Além disso, uma vez estabelecidos os valores da linha de base, o SAA pode ser configurado para enviar alertas a uma estação NMS se os limites de atraso, instabilidade e perda de pacotes forem excedidos.
Um dos pontos fortes do uso do SAA como mecanismo de teste é que uma chamada de voz pode ser simulada. Por exemplo, imagine que deseja simular uma chamada de voz G.711. Você sabe que ele usa as portas RTP/UDP 14384 e superiores, ele é aproximadamente 64 kb/s e o tamanho do pacote é 200 bytes {(160 bytes de payload + 40 bytes para IP/UDP/RTP (não compactado) }.Você pode simular esse tipo de tráfego configurando a prova de atraso/jitter SAA como mostrado abaixo.
A operação de instabilidade precisa fazer isso:
Envie a solicitação para a porta RTP/UDP número 14384.
Enviar pacotes de 172 bytes (payload de 160 + tamanho do cabeçalho RTP de 12 bytes) + 28 bytes (IP + UDP).
Envie 3000 pacotes para cada ciclo de frequência.
Envie cada pacote 20 milissegundos separados por uma duração de 60 segundos e durar 10 segundos antes de iniciar o próximo ciclo de frequência.
Esses parâmetros dão 64 kb/s por 60 segundos.
(3.000 datagramas * 160 bytes por datagrama)/ 60 segundos) * 8 bits por byte = 64 kb/s
A configuração no roteador é exibida da seguinte maneira:
rtr 1 type jitter dest-ipaddr 172.18.179.10 dest-port 14384 num-packets 3000+ request-data-size 172* frequency 70 rtr schedule 1 life 2147483647 start-time now
Observação: o IP+UDP não é considerado no tamanho da solicitação de dados, pois o roteador os adiciona automaticamente ao tamanho internamente.
Observação: atualmente, o Cisco IOS suporta apenas 1.000 pacotes por operação. Este limite será aumentado numa versão futura.
Os roteadores no exemplo a seguir simulam chamadas de voz de 60 segundos a cada 60 segundos e registram atraso, instabilidade e perda de pacotes em ambas as direções.
Observação: os cálculos de atraso são tempos de ida e volta e devem ser divididos por dois para obter o atraso unidirecional.
saarouter1# rtr responder rtr 1 type jitter dest-ipaddr 172.18.179.10 dest-port 14384 num-packets 1000 request-data-size 492 frequency 60 rtr schedule 1 life 2147483647 start-time now saarouter2# rtr responder rtr 1 type jitter dest-ipaddr 172.18.178.10 dest-port 14385 num-packets 1000 request-data-size 492 rtr schedule 1 life 2147483647 start-time now saarouter3# rtr responder rtr 1 type jitter dest-ipaddr 172.18.179.100 dest-port 14385 num-packets 1000 request-data-size 492 frequency 60 rtr schedule 1 life 2147483647 start-time now saarouter4# rtr responder rtr 1 type jitter dest-ipaddr 172.18.178.100 dest-port 14385 num-packets 1000 request-data-size 492 frequency 60 rtr schedule 1 life 2147483647 start-time now
As sondas de retardo e jitter começam a coletar dados que são posteriormente colocados em tabelas SNMP MIB. A tabela rttMonStats fornece uma média de uma hora de todas as operações de jitter para a última hora. A tabela rttMonLatestJitterOper fornece os valores da última operação concluída. Para obter estatísticas gerais sobre atraso e instabilidade, consulte a tabela rttMonStats a cada hora. Para obter estatísticas mais granulares, consulte a tabela rttMonLatestJitterOper em um nível de frequência mais alto do que a operação de jitter. Por exemplo, se a prova de retardo e jitter estiver calculando o jitter a cada cinco minutos, não faça poll do MIB em qualquer intervalo menos de cinco minutos.
A captura de tela a seguir mostra os dados da tabela rttMonJitterStatsTable coletados de uma pesquisa MIB do HP OpenView Network Node Manager.
O gráfico de dados SAA a seguir é uma compilação de pontos de dados de atraso, instabilidade e perda de pacotes durante um período de oito horas para um par de sondas de atraso e instabilidade.
Os dados também podem ser vistos usando o comando show do Cisco IOS na linha de comando nos testadores de retardo e jitter. Um script Perl Expect pode ser usado para coletar dados da linha de comando e exportá-los para um arquivo de texto para análise posterior. Além disso, os dados da linha de comando também podem ser usados para monitoramento em tempo real e solução de problemas de atraso, instabilidade e perda de pacotes.
O exemplo a seguir mostra a saída do comando show rtr collection-stats no roteador saarouter1.
#show rtr collection-stats 100 Collected Statistics Entry Number: 100 Target Address: 172.16.71.243, Port Number: 16384 Start Time: 13:06:04.000 09:25:00 Tue Mar 21 2000 RTT Values: NumOfRTT: 600 RTTSum: 873 RTTSum2: 1431 Packet Loss Values: PacketLossSD: 0 PacketLossDS: 0 PacketOutOfSequence: 0 PacketMIA: 0 PacketLateArrival: 0 InternalError: 0 Busies: 0 Jitter Values: MinOfPositivesSD: 1 MaxOfPositivesSD: 1 NumOfPositivesSD: 23 SumOfPositivesSD: 23 Sum2PositivesSD: 23 MinOfNegativesSD: 1 MaxOfNegativesSD: 1 NumOfNegativesSD: 1 SumOfNegativesSD: 1 Sum2NegativesSD: 1 MinOfPositivesDS: 1 MaxOfPositivesDS: 1 NumOfPositivesDS: 7 SumOfPositivesDS: 7 Sum2PositivesDS: 7 MinOfNegativesDS: 1 MaxOfNegativesDS: 1 NumOfNegativesDS: 18 SumOfNegativesDS: 18 Sum2NegativesDS: 18 Entry Number: 100 Target Address: 172.16.71.243, Port Number: 16384 Start Time: 14:06:04.000 09:25:00 Tue Mar 21 2000 RTT Values: NumOfRTT: 590 RTTSum: 869 RTTSum2: 1497 Packet Loss Values: PacketLossSD: 0 PacketLossDS: 0 PacketOutOfSequence: 0 PacketMIA: 0 PacketLateArrival: 0 InternalError: 0 Busies: 0 Jitter Values: MinOfPositivesSD: 1 MaxOfPositivesSD: 1 NumOfPositivesSD: 29 SumOfPositivesSD: 29 Sum2PositivesSD: 29 MinOfNegativesSD: 1 MaxOfNegativesSD: 1 NumOfNegativesSD: 7 SumOfNegativesSD: 7 Sum2NegativesSD: 7 MinOfPositivesDS: 1 MaxOfPositivesDS: 1 NumOfPositivesDS: 47 SumOfPositivesDS: 47 Sum2PositivesDS: 47 MinOfNegativesDS: 1 MaxOfNegativesDS: 1 NumOfNegativesDS: 5 SumOfNegativesDS: 5 Sum2NegativesDS: 5
Há várias maneiras de monitorar os níveis de atraso, instabilidade e perda de pacotes na rede, uma vez que os valores da linha de base foram estabelecidos através da coleta de dados inicial. Uma maneira é usar o comando SAA threshold. Outra é usar um recurso no código de linha principal do Cisco IOS chamado Alarme e Evento RMON.
O comando SAA feature set threshold define o limite de elevação (histerese) que gera um evento de reação e armazena informações de histórico para a operação. A seguinte configuração de limite SAA no atraso e na prova de jitter permite o monitoramento de jitter e cria uma interceptação SNMP na violação de um limite de 5 ms.
saarouter1# rtr 100 rtr reaction-configuration 100 threshold-falling 5 threshold-type immediate
As sondas de retardo e jitter monitoram limiares predeterminados usando os recursos do SAA Cisco IOS ou o método de alarme e evento do Cisco IOS RMON. Em ambos os casos, o roteador monitora o atraso, a instabilidade e a perda de pacotes e alerta as estações NMS sobre violações de limiar através de interceptações SNMP.
A seguinte configuração de alarme de RMON e armadilha de evento faz com que o saarouter1 gere uma interceptação SNMP se o limite de elevação exceder o tempo máximo de ida e volta de 140 ms. Ele também envia outra armadilha quando o tempo máximo de ida e volta cair abaixo de 100 ms. A armadilha é enviada para o log no roteador, bem como para a estação NMS 172.16.71.19.
saarouter1# rmon alarm 10 rttMonJitterStatsRTTMax.100.120518706 1 absolute rising-threshold 140 100 falling-threshold 100 101 owner jharp rmon event 100 log trap private description max_rtt_exceeded owner jharp rmon event 101 log trap private description rtt_max_threshold_reset owner jharp
O jitter é a variação na latência unidirecional e é calculado com base em carimbos de data e hora de envio e recebimento de pacotes consecutivos enviados.
Carimbo de data/hora | Remetente | Respondente |
---|---|---|
T1 | send pkt1 | |
T2 | recv pkt1 | |
T3 | enviar resposta de retorno para pkt1 | |
T4 | resposta recv para pkt1 | |
T5 | send pkt2 | |
T6 | recv pkt2 | |
T7 | enviar resposta de retorno para pkt2 | |
T8 | resposta recv para pkt2 |
Para o pacote 1 e o pacote 2 acima, use os seguintes cálculos de origem e de destino.
Instabilidade da origem para o destino (JitterSD) = (T6-T2) - (T5-T1)
Instabilidade do destino para a origem (JitterDS) = (T8-T4) - (T7-T3)
O jitter é calculado usando carimbos de data e hora de cada dois pacotes consecutivos. Por exemplo:
Router1 send packet1 T1 = 0 Router2 receives packet1 T2 = 20 ms Router2 sends back packet1 T3 = 40 ms Router1 receives packet1 response T4 = 60 ms Router1 sends packet2 T5 = 60 ms Router2 receives packet2 T6 = 82 ms Router2 sends back packet2 T7 = 104 ms Router1 receives packet2 response T8 = 126 ms Jitter from source to destination (JitterSD) = (T6-T2) - (T5-T1) Jitter from source to destination (JitterSD) = (82 ms - 20 ms) - (60 ms - 0 ms) = 2 ms positive jitter SD Jitter from destination to source (JitterDS) = (T8-T4) - (T7-T3) Jitter from destination to source (JitterDS) = (126 ms - 60 ms) - (10 4ms - 40 ms) = 2 ms positive jitter DS
CISCO1720—Roteador modular 10/100BaseT com dois slots WAN e software IP Cisco IOS
MEM1700-16U24D—Atualização de fábrica da DRAM Cisco 1700 de 16 MB a 24 MB
MEM1700-4U8MFC—Atualização de fábrica de placas Mini Flash Cisco 1700 de 4 MB a 8 MB
CAB-AC—Cabo de alimentação, 110V
S17CP-12.1.1T—Cisco 1700 IOS IP PLUS