Contents

Introduction

Medindo retardo, tremulação e perda de pacote de redes de dados ativadas por voz

A importância da medição de atraso, tremulação e perda de pacotes

Definição de retardo, tremulação e perda de pacote

SAA e RTTMON

Implementando retardo e roteadores do agente de tremulação

Onde implementar

Simulando uma chamada de voz

Exemplo de implementação de ponta de prova de retardo e tremulação

Exemplo de coletas de dados

Elegendo as tabelas MIB

Monitoramento proativo de limiares

Comando threshold do SAA

Alarme e evento RMON

Appendix

Cálculos de tremulação nas sondas de tremulação e atraso do Cisco SAA

Configurações de hardware e software do roteador de prova de retardo e de tremulação

Informações Relacionadas

Introduction

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.

Medindo retardo, tremulação e perda de pacote de redes de dados ativadas por voz

A importância da medição de atraso, tremulação e perda de pacotes

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.

Definição de retardo, tremulação e perda de pacote

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.

SAA e RTTMON

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.

Implementando retardo e roteadores do agente de tremulação

Onde implementar

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.

Simulando uma chamada de voz

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 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 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.

- (3.000 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: 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. Esse limite será aumentado em uma versão futura.

Exemplo de implementação de ponta de prova de retardo e tremulação

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

Exemplo de coletas de dados

Elegendo as tabelas MIB

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.

Exemplo de relatório SAA

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.

Exemplos de dados de linha de comando

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

Monitoramento proativo de limiares

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.

Comando threshold do SAA

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

Alarme e evento RMON

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

Appendix

Cálculos de tremulação nas sondas de tremulação e atraso do Cisco SAA

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

Configurações de hardware e software do roteador de prova de retardo e de tremulação

- CISCO1720— roteador modular 10/100BaseT com dois slots de WAN e software Cisco IOS IP

- 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

Informações Relacionadas

- Guia do usuário do SAA

- Suporte Técnico - Cisco Systems