Sommario

Introduzione

Misurazione di ritardo, jitter e perdita di pacchetti per le reti dati abilitate per la voce

L'importanza della misurazione di ritardo, jitter e perdita di pacchetti

Definizione di ritardo, jitter e perdita di pacchetti

SAA e RTTMON

Distribuzione di router con ritardo e jitter Agent

Dove distribuire

Simulazione di una chiamata vocale

Esempio di distribuzione del probe Delay and Jitter

Raccolte di dati di esempio

Polling delle tabelle MIB

Monitoraggio proattivo delle soglie

Comando di soglia ASA

Eventi e allarmi RMON

Appendice

Calcoli di variazione nelle sonde di variazione ritardo SAA Cisco

Configurazioni hardware e software di Delay and Jitter Probe Router

Informazioni correlate

Introduzione

Questo documento descrive i metodi per misurare il ritardo, l'instabilità e la perdita di pacchetti sulla rete dati usando le funzionalità Cisco IOS® Service Assurance Agent (SAA) e Round Trip Time Monitor (RTTMON) e i router Cisco.

Misurazione di ritardo, jitter e perdita di pacchetti per le reti dati abilitate per la voce

L'importanza della misurazione di ritardo, jitter e perdita di pacchetti

Con la comparsa di nuove applicazioni sulle reti di dati, diventa sempre più importante per i clienti prevedere con precisione l'impatto delle nuove implementazioni di applicazioni. Fino a poco tempo fa, era facile allocare la larghezza di banda alle applicazioni e lasciare che le applicazioni si adattassero alla natura esplosiva dei flussi di traffico attraverso le funzioni di timeout e ritrasmissione dei protocolli di livello superiore. Oggi, tuttavia, le applicazioni di nuova generazione, come quelle voce e video, sono più soggette ai cambiamenti delle caratteristiche di trasmissione delle reti di dati. È essenziale comprendere le caratteristiche del traffico della rete prima di installare nuove applicazioni mondiali per garantire implementazioni corrette.

Definizione di ritardo, jitter e perdita di pacchetti

Il VoIP (Voice over IP) è sensibile ai comportamenti di rete, definiti come ritardo e jitter, che possono compromettere l'applicazione vocale al punto di essere inaccettabili per l'utente medio. Il ritardo è il tempo impiegato dal punto a punto in una rete. Il ritardo può essere misurato con un ritardo di andata o di ritorno. I calcoli dei ritardi unidirezionali richiedono apparecchiature di test sofisticate e superano il budget e le competenze della maggior parte dei clienti aziendali. Tuttavia, misurare il ritardo di andata e ritorno è più semplice e richiede apparecchiature meno costose. Per ottenere una misurazione generale del ritardo a una via, misurare il ritardo di andata e ritorno e dividere il risultato per due. In genere, il VoIP tollera ritardi fino a 150 ms prima che la qualità della chiamata sia inaccettabile.

Jitter è la variazione del ritardo nel tempo da punto a punto. Se il ritardo di trasmissione varia eccessivamente in una chiamata VoIP, la qualità della chiamata è notevolmente peggiorata. La quantità di jitter tollerabile sulla rete è influenzata dalla profondità del buffer di jitter sull'apparecchiatura di rete nel percorso vocale. Maggiore è la quantità di buffer di jitter disponibile, maggiore è la capacità della rete di ridurre gli effetti del jitter.

La perdita di pacchetti sta causando la perdita di pacchetti lungo il percorso dei dati, con conseguente grave deterioramento dell'applicazione vocale.

Prima di implementare applicazioni VoIP, è importante valutare il ritardo, l'instabilità e la perdita di pacchetti sulla rete dati per determinare se le applicazioni voce funzionano. Le misurazioni di ritardo, jitter e perdita di pacchetti possono quindi aiutare a progettare e configurare correttamente l'assegnazione di priorità al traffico, nonché i parametri di buffering nelle apparecchiature della rete di dati.

SAA e RTTMON

SAA e RTTMON MIB sono funzionalità software di Cisco IOS disponibili nelle versioni 12.0 (5)T e successive. Queste funzionalità consentono di verificare e raccogliere le statistiche relative al ritardo, allo jitter e alla perdita di pacchetti sulla rete dati. IPM (Internetwork Performance Monitor) è un'applicazione Cisco per la gestione della rete che può configurare le funzionalità e monitorare i dati ASA e RTTMON. Le funzionalità ASA e RTTMON possono essere utilizzate per misurare ritardi, jitter e perdite di pacchetti implementando piccoli router Cisco IOS come agenti per simulare le stazioni terminali dei clienti. I router vengono chiamati sonde di ritardo e di jitter. Inoltre, le sonde di ritardo e di jitter possono essere configurate con l'allarme e i trigger di evento RMON (monitoraggio da remoto) una volta determinati i valori di base. Ciò consente alle sonde di ritardo e jitter di monitorare la rete per un ritardo predeterminato e livelli di servizio jitter e di avvisare le stazioni del sistema di gestione della rete (NMS) quando viene superata una soglia.

Distribuzione di router con ritardo e jitter Agent

Dove distribuire

Il ritardo e l'instabilità possono essere misurati implementando i router Cisco 17xx o versione successiva con codice software Cisco IOS versione 12.05T o successiva e configurando le funzionalità ASA di Cisco IOS. I router devono essere posizionati nelle reti del campus accanto agli host. Vengono fornite le statistiche per le connessioni end-to-end. Poiché non è possibile misurare ogni possibile percorso vocale nella rete, posizionare le sonde in posizioni host tipiche fornendo un campionamento statistico dei percorsi vocali tipici. Alcuni esempi sono:

- percorso da campus a campus locale

- percorso da campus locale a campus remoto tramite un circuito Frame Relay a 384 kbs

- un campus locale da campus a campus remoto tramite un circuito virtuale permanente ATM (PVC)

Nel caso di implementazioni VoIP che utilizzano telefoni tradizionali connessi a router Cisco che utilizzano porte Foreign Exchange Station (FXS), utilizzare il router collegato ai telefoni per servire come sonde di ritardo e di jitter. Una volta distribuita, la sonda raccoglie le statistiche e inserisce le tabelle MIB SNMP (Simple Network Management Protocol) nel router. È quindi possibile accedere ai dati tramite l'applicazione IPM Cisco o tramite gli strumenti di polling SNMP. Inoltre, una volta stabiliti i valori di base, l'appliance ASA può essere configurata per inviare allarmi a una stazione NMS in caso di superamento delle soglie di ritardo, jitter e perdita di pacchetti.

Simulazione di una chiamata vocale

Uno dei punti di forza dell'uso dell'ASA come meccanismo di test è la possibilità di simulare una chiamata vocale. Ad esempio, immaginate di voler simulare una chiamata vocale al G.711. Si sa che utilizza le porte RTP/UDP 14384 e superiori, è di circa 64 kb/s e le dimensioni del pacchetto sono di 200 byte {(160 byte di payload + 40 byte per IP/UDP/RTP (non compresso) }.È possibile simulare questo tipo di traffico impostando la sonda SAA Delay/Jitter come mostrato di seguito.

L'operazione di variazione deve eseguire questa operazione:

- Inviare la richiesta alla porta RTP/UDP numero 14384.

- Invia pacchetti da 172 byte (160 payload + 12 byte di dimensioni intestazione RTP) + 28 byte (IP + UDP).

- Inviare 3000 pacchetti per ogni ciclo di frequenza.

- Inviare ogni pacchetto a 20 millisecondi di distanza l'uno dall'altro per una durata di 60 secondi e sospendere 10 secondi prima di avviare il successivo ciclo di frequenza.

Questi parametri forniscono 64 kb/s per 60 secondi.

- (3000 datagrammi * 160 byte per datagramma)/ 60 secondi) * 8 bit per byte = 64 kb/s

La configurazione sul router è la seguente:

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

Nota: IP+UDP non viene considerato nella dimensione richiesta-dati in quanto il router le aggiunge automaticamente alle dimensioni internamente.

Nota: al momento, Cisco IOS supporta solo 1000 pacchetti per operazione. Questo limite verrà aumentato in una versione futura.

Esempio di distribuzione del probe Delay and Jitter

I router nell'esempio seguente simulano chiamate vocali da 60 secondi ogni 60 secondi e registrano ritardo, jitter e perdita di pacchetti in entrambe le direzioni.

Nota: i calcoli del ritardo sono tempi di andata e ritorno e devono essere divisi per due per ottenere il ritardo unidirezionale.

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

Raccolte di dati di esempio

Polling delle tabelle MIB

Le richieste delay e jitter iniziano a raccogliere i dati che vengono successivamente inseriti nelle tabelle MIB SNMP. La tabella rttMonStats fornisce una media di un'ora di tutte le operazioni di variazione per l'ultima ora. La tabella rttMonLatestJitterOper fornisce i valori dell'ultima operazione completata. Per le statistiche generali sul ritardo e l'instabilità, eseguire il polling della tabella rttMonStats ogni ora. Per statistiche più granulari, eseguire il polling della tabella rttMonLatestJitterOper a un livello di frequenza più alto rispetto all'operazione di jitter. Ad esempio, se il ritardo e la sonda di variazione calcolano la variazione ogni cinque minuti, non eseguire il polling del MIB a intervalli inferiori a cinque minuti.

La schermata seguente mostra i dati della tabella rttMonJitterStatsTable raccolti da un sondaggio MIB di HP OpenView Network Node Manager.

Esempio di report ASA

Il seguente grafico dati SAA è una compilazione di punti dati di ritardo, jitter e perdita di pacchetti in un periodo di otto ore per una coppia di richieste di ritardo e jitter.

Esempi di dati della riga di comando

I dati possono essere visualizzati anche utilizzando il comando Cisco IOS show sulla riga di comando delle sonde di ritardo e di jitter. È possibile utilizzare uno script Perl Expect per raccogliere dati dalla riga di comando ed esportarli in un file di testo per un'analisi successiva. Inoltre, i dati della riga di comando possono essere utilizzati per il monitoraggio in tempo reale e la risoluzione dei problemi di ritardo, jitter e perdita di pacchetti.

Nell'esempio seguente viene mostrato l'output del comando show rtr collection-stats sul router 1.

#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

Monitoraggio proattivo delle soglie

Esistono diversi modi per monitorare i livelli di ritardo, di jitter e di perdita dei pacchetti nella rete una volta stabiliti i valori di base tramite la raccolta iniziale dei dati. Un modo è usare il comando SAA threshold. In alternativa, è possibile usare una funzione nel codice della linea principale di Cisco IOS chiamata RMON Alarm and Event.

Comando di soglia ASA

Il comando set threshold delle funzionalità ASA imposta la soglia crescente (isteresi) che genera un evento di reazione e memorizza le informazioni cronologiche per l'operazione. La seguente configurazione di soglia ASA sul sonda delay e jitter consente il monitoraggio del jitter e crea una trap SNMP sulla violazione di una soglia di 5 ms.

saarouter1#

rtr 100

rtr reaction-configuration 100 threshold-falling 5 threshold-type immediate

Eventi e allarmi RMON

Le sonde delay e jitter monitorano le soglie predeterminate utilizzando le funzionalità ASA di Cisco IOS o l'allarme e il metodo di evento Cisco IOS RMON. In entrambi i casi, il router monitora il ritardo, l'instabilità e la perdita dei pacchetti e avvisa le stazioni NMS delle violazioni di soglia tramite trap SNMP.

La configurazione dell'allarme RMON e della trap di eventi riportata di seguito fa sì che il router 1 generi una trap SNMP se la soglia di aumento supera il tempo di andata e ritorno massimo di 140 ms. Invia inoltre un'altra trap quando il tempo di andata e ritorno massimo scende al di sotto di 100 ms. La trap viene quindi inviata al log sul router e alla stazione 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

Appendice

Calcoli di variazione nelle sonde di variazione ritardo SAA Cisco

L'instabilità è la varianza della latenza unidirezionale e viene calcolata in base ai timestamp di invio e ricezione dei pacchetti consecutivi inviati.

Timestamp

Mittente

Risponditore

T1

inviare pkt1

T2

recv pkt1

T3

invia risposta per pkt1

T4

risposta recv per pkt1

T5

inviare pkt2

T6

recv pkt2

T7

invia risposta per pkt2

T8

risposta recv per pkt2

Per il pacchetto 1 e il pacchetto 2, utilizzare i seguenti calcoli di origine e destinazione.

- Variazione dall'origine alla destinazione (JitterSD) = (T6-T2) - (T5-T1)

- Variazione da destinazione a origine (JitterDS) = (T8-T4) - (T7-T3)

Il jitter viene calcolato utilizzando gli indicatori di ora di due pacchetti consecutivi. Ad esempio:

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

Configurazioni hardware e software di Delay and Jitter Probe Router

- CISCO 1720—Router modulare 10/100BaseT con due slot WAN e software IP Cisco IOS

- MEM1700-16U24D—Cisco 1700 Aggiornamento in fabbrica della DRAM da 16 MB a 24 MB

- MEM1700-4U8MFC—Cisco 1700 Aggiornamento in fabbrica della scheda mini-flash da 4 MB a 8 MB

- CAB-AC: cavo di alimentazione, 110 V

- S17CP-12.1.1T—Cisco 1700 IOS IP PLUS

Informazioni correlate

- Guida per l'utente ASA

- Supporto tecnico – Cisco Systems