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 laisser les applications s’adapter à la nature explosive des flux de trafic via les fonctions de délai d’attente 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 susceptibles de subir les changements des 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 de déployer de nouvelles applications mondiales 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 inacceptable pour l'utilisateur moyen. Le délai est le temps passé d’un point à un autre dans un réseau. Le délai peut être mesuré dans un sens ou dans l'autre. Les calculs de délai unidirectionnel nécessitent des équipements de test sophistiqués coûteux et dépassent le budget et l'expertise de la plupart des entreprises clientes. Toutefois, il est plus facile de mesurer le délai de trajet aller-retour et nécessite un équipement moins coûteux. Pour obtenir une mesure générale du délai aller simple, mesurez le délai aller-retour et divisez le résultat par deux. En règle générale, la VoIP tolère des retards 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 à l'autre. Si le délai de transmission varie trop largement dans un appel VoIP, la qualité de l'appel est considérablement dégradée. La quantité de gigue tolérable sur le réseau est affectée par la profondeur de la mémoire tampon de gigue sur l'équipement réseau dans le chemin vocal. Plus la mémoire tampon disponible est instable, 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 du délai, de la gigue et de la 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 du réseau de données.

SAA et RTTMON

La base MIB SAA et RTTMON sont des fonctionnalités du logiciel Cisco IOS disponibles dans les versions 12.0 (5)T et ultérieures. Ces fonctions 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éseau Cisco qui peut configurer les fonctionnalités et surveiller les données SAA et RTMON. Les fonctions SAA et RTTMON peuvent être utilisées pour mesurer le délai, 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é du client. 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 les déclencheurs d'alarme et d'événement de surveillance à distance (RMON) une fois que les valeurs de base ont été déterminées. Cela permet aux analyseurs de délai et de gigue de surveiller le réseau afin de détecter les niveaux de service de délai et de gigue prédéterminés, ainsi que les stations NMS (Alert Network Management System) lorsqu'un seuil est dépassé.

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

Où déployer

Le délai et la gigue peuvent être mesurés en déployant des routeurs Cisco 17xx ou supérieurs avec le code logiciel Cisco IOS version 12.05T ou ultérieure, et en configurant les fonctionnalités SAA de Cisco IOS. Les routeurs doivent être placés dans les réseaux de campus en regard des hôtes. Ceci fournit des statistiques pour les connexions de bout en bout. Comme il n’est pas pratique de mesurer tous les chemins vocaux possibles sur le réseau, placez les sondes dans les emplacements d’hôtes standard, ce qui permet d’échantillonner les chemins vocaux types de manière statistique. Voici quelques exemples :

• Un chemin de campus à campus local

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

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

Dans le cas de déploiements VoIP utilisant des téléphones traditionnels connectés à des routeurs Cisco à l'aide de 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 ensuite accessibles via l'application Cisco IPM ou via les outils d'interrogation SNMP. En outre, une fois les valeurs de référence é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 voulez simuler un appel vocal G.711. Vous savez qu’il utilise des 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 le SMA Delay/Jitter Probe comme indiqué ci-dessous.

L'opération de gigue doit effectuer ceci :

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

• Envoyez des paquets de 172 octets (charge utile 160 + taille d'en-tête RTP 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 la taille des données de requête car le routeur les ajoute automatiquement à la taille en interne.

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

Exemple de déploiement des sondes de délai et de gigue

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

Note : Les calculs de délai sont des temps aller-retour et doivent être divisés par deux pour obtenir le délai à sens unique.

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 analyseurs de délai et de gigue commencent à collecter des données qui sont ensuite placées dans les tables MIB SNMP. La table rttMonStats fournit une moyenne d'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 à un niveau de fréquence plus élevé que l'opération de gigue. Par exemple, si le délai et la sonde de gigue calculent 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 des analyseurs de délai et de gigue. 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 une 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 ligne de base ont été établies par le biais de la collecte de données initiale. L'une des méthodes consiste à utiliser la commande SAA threshold. Une autre est d'utiliser une fonctionnalité du code de ligne principale 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 les informations d'historique pour l'opération. La configuration de seuil SAA suivante sur la sonde de délai et de gigue permet la surveillance de la gigue et crée un déroutement 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 les 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 interruptions SNMP.

La configuration d'alarme RMON et d'interruption d'événement suivante entraîne la génération d'une interruption SNMP par saarouter1 si le seuil ascendant dépasse 140 ms de temps de retour maximal. Il envoie également un autre déroutement lorsque le temps maximal aller-retour tombe en dessous de 100 ms. Le déroutement 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 SAA de Cisco

La gigue est la variance de la latence à sens unique et est calculée en fonction de l'envoi et de la réception des horodatages des paquets consécutifs envoyés.

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

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

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

• Jitter de la destination à la source (JitterDS) = (T8-T4) - (T7-T3)

La gigue est calculée à l'aide d'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 des routeurs à analyse de délai et de gigue

• CISCO1720 - Routeur modulaire 10/100BaseT avec deux logements WAN et le logiciel IP Cisco IOS

• MEM1700-16U24D—Cisco 1700 16 Mo à 24 Mo de DRAM mise à niveau en usine

• 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 d'utilisation SAA
• Support technique - Cisco Systems

Historique de révision