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 novas aplicações nas redes de dados, torna-se cada vez mais importante para os clientes prever com precisão o impacto de novas implementações de aplicações. Há pouco tempo, era fácil alocar largura de banda para aplicações e permitir que elas se adaptassem à natureza expressiva dos fluxos de tráfego por meio das funções de tempo limite e de retransmissão dos protocolos da camada superior. Agora, no entanto, as novas aplicações do mundo, como voz e vídeo, são mais suscetíveis a alterações nas características de transmissão das redes de dados. É essencial compreender as características de tráfego da rede, antes da implantação de novas aplicações mundiais, para garantir o sucesso das implementações.
O VoIP (Voice over IP) é suscetível aos comportamentos da rede, conhecidos como atraso e instabilidade, que podem prejudicar a aplicação de voz a ponto de ser inaceitável para o usuário médio. Atraso é o tempo gasto de um ponto a outro em uma rede. O atraso pode ser medido em atraso unidirecional ou de ida e volta. Os cálculos de atraso unidirecional exigem equipamentos de teste sofisticados e caros e estão fora do orçamento e do conhecimento da maioria dos clientes corporativos. No entanto, medir o atraso de ida e volta é mais fácil e requer equipamentos mais baratos. Para obter uma medida geral do atraso unidirecional, meça o atraso de ida e volta e divida o resultado por dois. O VoIP normalmente tolera atrasos de até 150 ms com a qualidade da chamada aceitável.
A instabilidade é a variação no atraso ao longo do tempo de um ponto a outro. Se o atraso das transmissões variar muito em uma chamada VoIP, a qualidade da chamada será muito prejudicada. A quantidade de instabilidade tolerável na rede é afetada pela profundidade do buffer de instabilidade no equipamento de rede no caminho de voz. Quanto maior buffer de instabilidade disponível, mais a rede pode reduzir os efeitos da instabilidade.
A perda de pacotes ao longo do caminho de dados prejudica muito a aplicação de voz.
Antes de implantar aplicações VoIP, é importante avaliar o atraso, a instabilidade e a perda de pacotes na rede de dados para determinar se as aplicações de voz funcionam. As medições de atraso, instabilidade e perda de pacotes podem ajudar no design e na configuração correta da priorização de tráfego, bem como nos parâmetros de buffer do 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 superiores. Esses recursos permitem testar e coletar as estatísticas de atraso, instabilidade e perda de pacotes na rede de dados. O Internetwork Performance Monitor (IPM) é uma aplicação de gerenciamento de rede da Cisco que pode configurar os recursos e monitorar os dados de SAA e RTTMON. Os recursos SAA e RTTMON podem ser usados para medir atraso, instabilidade e perda de pacotes, implantando pequenos roteadores Cisco IOS como agentes para simular as estações finais do cliente. Os roteadores são chamados de sondas de atraso e instabilidade. Além disso, as sondas de atraso e instabilidade podem ser configuradas com o alarme de monitoramento remoto (RMON) e os acionadores de evento após a determinação dos valores de linha de base. Isso permite que as sondas de atraso e instabilidade monitorem a rede quanto aos níveis pré-determinados do serviço de atraso e instabilidade e alertem as estações do sistema de gerenciamento de rede (NMS) quando um limite for excedido.
O atraso e a instabilidade podem ser medidos com a implantação dos roteadores Cisco 17xx ou superiores, usando o código do software Cisco IOS versão 12.05T ou superior e configurando os recursos SAA do Cisco IOS. Os roteadores devem ser colocados nas redes de campus ao lado dos hosts. Isso fornece estatísticas para conexões de ponta a ponta. Como não é viável medir todos os caminhos de voz possíveis na rede, coloque as sondas em locais de host típicos, fornecendo uma amostragem estatística dos caminhos de voz típicos. Alguns exemplos incluem:
um caminho local de um campus para outro
um caminho local do campus para o acesso remoto através de um circuito Frame Relay de 384 kbs
um caminho local do campus para o acesso remoto através de um ATM PVC
No caso de implantações de VoIP que usam telefones tradicionais conectados aos roteadores Cisco com portas FXS, utilize o roteador conectado aos telefones para atuar como sondas de atraso e instabilidade. Uma vez implantada, a sonda coleta as estatísticas e preenche as tabelas de MIB do SNMP no roteador. Os dados podem ser acessados por meio da aplicação Cisco IPM ou das ferramentas de pesquisa do SNMP. Além disso, uma vez que os valores de linha de base foram estabelecidos, o SAA pode ser configurado para enviar alertas a uma estação de NMS, se os limites de atraso, instabilidade e perda de pacotes forem excedidos.
Um dos pontos fortes do uso do SAA como o mecanismo de teste é a possibilidade de simular uma chamada de voz. Por exemplo, imagine que você deseja simular uma chamada de voz G.711. Você sabe que ele usa portas RTP/UDP 14384 e superiores, tem aproximadamente 64 kb/s e o tamanho do pacote é 200 bytes {(160 bytes de payload + 40 bytes para IP/UDP/RTP (descompactado) }.Você pode simular esse tipo de tráfego configurando a Prova de atraso/variação de sinal SAA, como mostrado abaixo.
A operação de instabilidade precisa fazer o seguinte:
Envie a solicitação para o número da porta RTP/UDP 14384.
Envie os pacotes de 172 bytes (payload de 160 bytes + tamanho do cabeçalho RTP de 12 bytes) + 28 bytes (IP + UDP).
Envie 3.000 pacotes para cada ciclo de frequência.
Envie cada pacote com 20 milissegundos de diferença para uma duração de 60 segundos e aguarde 10 segundos antes de iniciar o próximo ciclo de frequência.
Esses parâmetros fornecem 64 kb/s para 60 segundos.
((3000 datagramas * 160 bytes por datagrama)/ 60 segundos)) * 8 bits por byte = 64 kb/s
A configuração no roteador é exibida da seguinte forma:
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: IP+UDP não é considerado no tamanho de dados de solicitação, pois o roteador os adiciona automaticamente ao tamanho internamente.
Observação: atualmente, o Cisco IOS suporta apenas 1000 pacotes por operação. Esse limite será aumentado em uma versão futura.
Os roteadores no exemplo a seguir simulam chamadas de voz de 60 segundos a cada 60 segundos e registram o atraso, a instabilidade e a 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 atraso e instabilidade começam a coletar os dados, que posteriormente são colocados nas tabelas de MIB do SNMP. A tabela rttMonStats fornece uma média de uma hora de todas as operações de instabilidade da ú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 detalhadas, pesquise a tabela rttMonLatestJitterOper com mais frequência do que a operação de instabilidade. Por exemplo, se a sonda de atraso e instabilidade estiver calculando a instabilidade a cada cinco minutos, não pesquise no MIB em um intervalo inferior a cinco minutos.
A captura de tela a seguir mostra os dados de rttMonJitterStatsTable coletados em uma pesquisa de MIB do HP OpenView Network Node Manager.
O gráfico de dados SAA a seguir é uma compilação dos pontos de dados de atraso, instabilidade e perda de pacotes em um período de oito horas para um par de sondas de atraso e instabilidade.
Os dados também podem ser visualizados usando o comando show do Cisco IOS na linha de comando das sondas de atraso e instabilidade. 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, depois que os valores de linha de base são estabelecidos por meio da coleta de dados inicial. Uma maneira é usar o comando threshold do SAA. Outra maneira é usar um recurso no código principal do Cisco IOS chamado RMON Alarm and Event.
O comando threshold definido do recurso SAA estabelece o limite crescente (histerese) que gera um evento de reação e armazena informações de histórico da operação. A configuração de threshold do SAA a seguir na sonda de atraso e instabilidade permite o monitoramento da instabilidade e cria uma interceptação SNMP após a violação de um limite de 5 ms.
saarouter1# rtr 100 rtr reaction-configuration 100 threshold-falling 5 threshold-type immediate
As sondas de atraso e instabilidade monitoram limites pré-determinados usando os recursos SAA do Cisco IOS ou o método de alarme e evento RMON do Cisco IOS. Em ambos os casos, o roteador monitora o atraso, a instabilidade e a perda de pacotes e alerta as estações de NMS sobre violações de limite através de interceptações SNMP.
A configuração de interceptação de alarme e evento RMON a seguir faz com que saarouter1 gere uma interceptação SNMP, caso o limite crescente exceda o tempo máximo de ida e volta de 140 ms. Ela também envia outra interceptação quando o tempo máximo de ida e volta fica abaixo de 100 ms. A interceptação é enviada para o registro no roteador, bem como para a estação de 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
A instabilidade é a variação na latência unidirecional e é calculada com base no envio e recebimento de carimbos de data/hora de pacotes consecutivos enviados.
Carimbo de data/hora | Remetente | Respondente |
---|---|---|
T1 | send pkt1 | |
T2 | recv pkt1 | |
T3 | send back reply for pkt1 | |
T4 | recv reply for pkt1 | |
T5 | send pkt2 | |
T6 | recv pkt2 | |
T7 | send back reply for pkt2 | |
T8 | recv reply for pkt2 |
Para os pacotes 1 e 2 acima, use os seguintes cálculos de origem e destino.
Instabilidade da origem para o destino (JitterSD) = (T6-T2) - (T5-T1)
Instabilidade do destino para a origem (JitterDS) = (T8-T4) - (T7-T3)
A instabilidade é calculada usando os carimbos de data/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 de WAN e software Cisco IOS IP
MEM1700-16U24D — Atualização de fábrica da DRAM de 16 MB para 24 MB do Cisco 1700
MEM1700-4U8MFC—Atualização de fábrica da placa miniFlash Cisco 1700 de 4 MB para 8 MB
CAB-AC—Cabo de alimentação, 110V
S17CP-12.1.1T — Cisco 1700 IOS IP PLUS
Revisão | Data de publicação | Comentários |
---|---|---|
1.0 |
02-Dec-2013 |
Versão inicial |