Mesure des retards, instabilités et pertes de paquets avec Cisco IOS SAA et RTTMON

Introduction

Ce document décrit les méthodes servant à mesurer le retard, le jitter et la perte de paquets sur le réseau de données en utilisant les fonctionnalités Service Assurance Agent (SAA) et Round Trip Time Monitor (RTTMON) de Cisco IOSMD ainsi que les routeurs Cisco.

Mesure du délai, de la gigue et de la perte de paquets pour les réseaux de données vocaux

Importance de la mesure du délai, de la gigue et de la perte de paquets

Avec l'émergence de nouvelles applications sur les réseaux de données, il devient de plus en plus important pour les clients de prévoir avec précision l'impact des nouveaux déploiements d'applications. Il n’y a pas si longtemps, il était facile d’allouer de la bande passante aux applications et de les laisser s’adapter à la nature explosive des flux de trafic grâce aux fonctions de temporisation et de retransmission des protocoles de couche supérieure. Aujourd'hui, cependant, les nouvelles applications, telles que la voix et la vidéo, sont plus sensibles aux changements dans les caractéristiques de transmission des réseaux de données. Il est impératif de comprendre les caractéristiques de trafic du réseau avant le déploiement d'applications nouvelles pour garantir la réussite des mises en oeuvre.

Définition du délai, de la gigue et de la perte de paquets

La voix sur IP (VoIP) est sensible aux comportements réseau, appelés délai et gigue, qui peuvent dégrader l'application vocale au point d'être inacceptables pour l'utilisateur moyen. Le délai est le temps nécessaire d’un point à un autre dans un réseau. Le délai peut être mesuré en temps de propagation aller simple ou aller-retour. Les calculs de délai unidirectionnels nécessitent des équipements de test sophistiqués coûteux et dépassent le budget et l'expertise de la plupart des entreprises clientes. Cependant, la mesure du délai aller-retour est plus facile et nécessite un équipement moins coûteux. Pour obtenir une mesure générale du délai dans un seul sens, mesurez le délai aller-retour et divisez le résultat par deux. La VoIP tolère généralement des délais allant jusqu'à 150 ms avant que la qualité de l'appel ne soit inacceptable.

La gigue est la variation du délai dans le temps d'un point à un autre. Si le délai de transmission varie trop dans un appel VoIP, la qualité de l'appel est fortement dégradée. La quantité de gigue tolérable sur le réseau est affectée par la profondeur du tampon de gigue sur l’équipement réseau dans le chemin vocal. Plus le tampon de gigue est disponible, plus le réseau peut réduire les effets de la gigue.

La perte de paquets entraîne la perte de paquets le long du chemin de données, ce qui dégrade considérablement l'application vocale.

Avant de déployer des applications VoIP, il est important d'évaluer le délai, la gigue et la perte de paquets sur le réseau de données afin de déterminer si les applications vocales fonctionnent. Les mesures de délai, de gigue et de perte de paquets peuvent ensuite aider à concevoir et à configurer correctement la hiérarchisation du trafic, ainsi que les paramètres de mise en mémoire tampon dans l’équipement de réseau de données.

SAA et RTMON

Les MIB SAA et RTTMON sont des fonctionnalités du logiciel Cisco IOS disponibles dans les versions 12.0 (5)T et ultérieures. Ces fonctionnalités vous permettent de tester et de collecter des statistiques de délai, de gigue et de perte de paquets sur le réseau de données. L'IPM (Internetwork Performance Monitor) est une application d'administration de réseaux Cisco qui permet de configurer les fonctionnalités et de surveiller les données SAA et RTMON. Les fonctionnalités SAA et RTMON peuvent être utilisées pour mesurer le retard, la gigue et la perte de paquets en déployant de petits routeurs Cisco IOS en tant qu'agents pour simuler les stations d'extrémité des clients. Les routeurs sont appelés sondes de délai et de gigue. En outre, les sondes de délai et de gigue peuvent être configurées avec l'alarme de surveillance à distance (RMON) et les déclencheurs d'événements une fois que les valeurs de base ont été déterminées. Cela permet aux sondes de retard et de gigue de surveiller le réseau pour des niveaux de service de retard et de gigue prédéterminés et d'alerter les stations du système de gestion de réseau (NMS) lorsqu'un seuil est dépassé.

Déploiement de routeurs d'agent de délai et de gigue

Emplacement de déploiement

Le délai et la gigue peuvent être mesurés en déployant des routeurs Cisco 17xx ou supérieurs avec le code du logiciel Cisco IOS version 12.05T ou supérieure, et en configurant les fonctionnalités Cisco IOS ASA. Les routeurs doivent être placés dans les réseaux de campus à côté des hôtes. Cela fournit des statistiques sur les connexions de bout en bout. Étant donné qu’il n’est pas pratique de mesurer chaque chemin vocal possible dans le réseau, placez les sondes dans des emplacements d’hôtes types pour obtenir un échantillonnage statistique des chemins vocaux types. Voici quelques exemples :

• Un chemin de campus à campus local

• Un chemin de campus local à campus distant via un circuit Frame Relay de 384 kbits/s

• un campus local à un campus distant via un circuit virtuel permanent (PVC) ATM

Dans le cas de déploiements VoIP utilisant des téléphones traditionnels connectés à des routeurs Cisco utilisant des ports FXS (Foreign Exchange Station), utilisez le routeur connecté aux téléphones pour servir de sondes de délai et de gigue. Une fois déployée, la sonde collecte des statistiques et remplit les tables MIB SNMP (Simple Network Management Protocol) du routeur. Les données sont alors accessibles via l'application Cisco IPM ou via les outils d'interrogation SNMP. En outre, une fois les valeurs de base établies, SAA peut être configuré pour envoyer des alertes à une station NMS si les seuils de délai, de gigue et de perte de paquets sont dépassés.

Simulation d'un appel vocal

L'un des avantages de l'utilisation de SAA comme mécanisme de test est qu'un appel vocal peut être simulé. Par exemple, imaginez que vous souhaitez simuler un appel vocal G.711. Vous savez qu'il utilise les ports RTP/UDP 14384 et supérieurs, qu'il est d'environ 64 kbit/s et que la taille du paquet est de 200 octets {(160 octets de données utiles + 40 octets pour IP/UDP/RTP (non compressé) }.Vous pouvez simuler ce type de trafic en configurant la sonde SAA Delay/Jitter comme indiqué ci-dessous.

L'opération de gigue doit effectuer cette opération :

• Envoyez la demande au port RTP/UDP numéro 14384.

• Envoi de paquets de 172 octets (charge utile de 160 octets + taille d’en-tête RTP de 12 octets) + 28 octets (IP + UDP).

• Envoyez 3 000 paquets pour chaque cycle de fréquence.

• Envoyez chaque paquet à 20 millisecondes d'intervalle pendant une durée de 60 secondes et mettez en veille 10 secondes avant de commencer le cycle de fréquence suivant.

Ces paramètres donnent 64 kbit/s pendant 60 secondes.

• ((3 000 datagrammes * 160 octets par datagramme)/ 60 secondes) * 8 bits par octet = 64 kbit/s

La configuration du routeur s’affiche comme suit :

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

Remarque : IP+UDP n'est pas pris en compte dans request-data-size car le routeur les ajoute automatiquement à la taille en interne.

Remarque : Cisco IOS ne prend actuellement en charge que 1 000 paquets par opération. Cette limite sera augmentée dans une prochaine version.

Exemple de déploiement d'une sonde de délai et de gigue

Les routeurs de l'exemple suivant simulent des appels vocaux de 60 secondes toutes les 60 secondes et enregistrent le délai, la gigue et la perte de paquets dans les deux directions.

Remarque : les calculs de délai sont des temps aller-retour et doivent être divisés par deux pour obtenir le délai dans un seul sens.

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

Exemples de collectes de données

Interrogation des tables MIB

Les sondes de délai et de gigue commencent à collecter les données qui sont ensuite placées dans les tables MIB SNMP. La table rttMonStats fournit une moyenne sur une heure de toutes les opérations de gigue de la dernière heure. La table rttMonLatestJitterOper fournit les valeurs de la dernière opération terminée. Pour obtenir des statistiques générales sur le délai et la gigue, interrogez la table rttMonStats toutes les heures. Pour obtenir des statistiques plus précises, interrogez la table rttMonLatestJitterOper à une fréquence supérieure à celle de l'opération de gigue. Par exemple, si la sonde delay and jitter calcule la gigue toutes les cinq minutes, n'interrogez pas la MIB à un intervalle inférieur à cinq minutes.

La capture d'écran suivante montre les données de rttMonJitterStatsTable collectées à partir d'un sondage MIB HP OpenView Network Node Manager.

Exemple de rapport SAA

Le graphique de données SAA suivant est une compilation de points de données de délai, de gigue et de perte de paquets sur une période de huit heures pour une paire de sondes de délai et de gigue.

Exemples de données de ligne de commande

Les données peuvent également être affichées à l'aide de la commande show de Cisco IOS sur la ligne de commande sur les sondes delay et jitter. Un script Perl Expect peut être utilisé pour collecter des données à partir de la ligne de commande et les exporter vers un fichier texte pour analyse ultérieure. En outre, les données de ligne de commande peuvent également être utilisées pour la surveillance et le dépannage en temps réel des retards, de la gigue et de la perte de paquets.

L'exemple suivant montre le résultat de la commande show rtr collection-stats sur le routeur 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

Surveillance proactive des seuils

Il existe plusieurs façons de surveiller les niveaux de délai, de gigue et de perte de paquets dans le réseau une fois que les valeurs de base ont été établies par le biais de la collecte de données initiale. Une méthode consiste à utiliser la commande SAA threshold. Une autre est d'utiliser une fonctionnalité dans le code principal de Cisco IOS appelée RMON Alarm and Event.

Commande SAA threshold

La commande SAA feature set threshold définit le seuil ascendant (hystérésis) qui génère un événement de réaction et stocke des informations d'historique pour l'opération. La configuration de seuil SAA suivante sur la sonde de délai et de gigue active la surveillance de la gigue et crée une interruption SNMP en cas de violation d'un seuil de 5 ms.

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

Alarme et événement RMON

Les sondes de délai et de gigue surveillent des seuils prédéterminés à l'aide des fonctions SAA de Cisco IOS ou de la méthode d'alarme et d'événement RMON de Cisco IOS. Dans les deux cas, le routeur surveille le délai, la gigue et la perte de paquets et avertit les stations NMS des violations de seuil via des déroutements SNMP.

La configuration d’alarme RMON et de déroutement d’événements suivante entraîne la génération d’un déroutement SNMP par le routeur 1 si le seuil ascendant dépasse le temps de propagation aller-retour maximal de 140 ms. Il envoie également un autre déroutement lorsque le temps de parcours aller-retour maximum repasse en dessous de 100 ms. Le trap est ensuite envoyé au journal sur le routeur, ainsi qu’à la station 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

Annexe

Calculs de gigue dans les sondes de gigue de délai Cisco ASA

La gigue est la variance de la latence unidirectionnelle. Elle est calculée en fonction des horodatages d'envoi et de réception des paquets consécutifs envoyés.

Horodatage	Expéditeur	Répondeur
T1	envoyer pkt1
T2		pkt1 recv
T3		réponse de renvoi pour pkt1
T4	réponse recv pour pkt1
T5	send pkt2
T6		pkt2 recv
T7		réponse de renvoi pour pkt2
T8	réponse recv pour pkt2

Pour les paquets 1 et 2 ci-dessus, utilisez les calculs suivants pour la source et la destination.

• Gigue de la source à la destination (JitterSD) = (T6-T2) - (T5-T1)

• Gigue de la destination à la source (GigueDS) = (T8-T4) - (T7-T3)

La gigue est calculée à l'aide des horodatages de deux paquets consécutifs. Exemple :

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 

Configurations matérielles et logicielles du routeur de sonde de délai et de gigue

• CISCO1720 : routeur modulaire 10/100BaseT avec deux logements WAN et logiciel IP Cisco IOS

• MEM1700-16U24D - Mise à niveau industrielle de la mémoire DRAM de 16 à 24 Mo du Cisco 1700

• MEM1700-4U8MFC - Mise à niveau industrielle de la carte Mini-Flash Cisco 1700 de 4 Mo à 8 Mo

• CAB-AC—Cordon d'alimentation, 110 V

• S17CP-12.1.1T - Cisco 1700 IOS IP PLUS

Informations connexes

• Guide de l'utilisateur SAA
• Support technique - Cisco Systems