Disponibilité : Haute disponibilité

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

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


Introduction

Ce document décrit des méthodes pour mesurer le retard, le jitter, et la perte de paquets sur le réseau de données utilisant le Logiciel Service Assurance Agent (SAA) de ½ du ¿  de Cisco IOSï et les caractéristiques du moniteur de durée d'aller-retour (RTTMON) et les Routeurs de Cisco.

Retard, jitter, et perte de paquets de mesure pour les réseaux de données à commande vocale

L'importance de mesurer le retard, le jitter, et la perte de paquets

Avec l'émergence de nouvelles applications sur des réseaux de données, il devient de plus en plus important que les clients prévoient exactement l'incidence du déploiement de nouvelles applications. Il y a peu de temps, il était facile d'allouer la bande passante aux applications et permettez les applications de s'adapter à la nature de explosion du trafic traverse des fonctions de délai d'attente et de retransmission des protocoles de couche supérieure. Maintenant, cependant, les nouvelles applications du monde, telles que la Voix et le vidéo, sont plus susceptibles des changements des caractéristiques de transmission des réseaux de données. Il est impératif de comprendre les caractéristiques du trafic du réseau avant le déploiement de nouvelles applications du monde pour assurer des implémentations réussies.

Définir le retard, le jitter, et la perte de paquets

La voix sur ip (VoIP) est susceptible des comportements du réseau, désignés sous le nom du retard et instabilité, qui peut dégrader l'application vocale au point d'être inacceptable pour l'utilisateur moyen. Le retard est le temps pris du Point à point dans un réseau. Le retard peut être mesuré dans l'one-way ou le délai d'aller-retour. Les calculs de délai à sens unique exigent l'équipement sophistiqué cher de test et sont au delà du budget et de l'expertise de la plupart des clients de l'entreprise. Cependant, le délai d'aller-retour de mesure est plus facile et exige moins de matériel cher. Pour obtenir une mesure générale de retard, de délai d'aller-retour à sens unique de mesure et diviser le résultat par deux. Le VoIP tolère typiquement des retards jusqu'à 150 ms avant que la qualité de l'appel soit inacceptable.

Le jitter est la variation du retard au fil du temps du Point à point. Si le retard des transmissions varie trop considérablement dans un appel VoIP, la qualité des communications est considérablement dégradée. La quantité de jitter tolérable sur le réseau est affectée par la profondeur de la mémoire tampon de jitter sur l'équipement réseau dans le chemin voix. Les plus mémoire tampon de jitter disponible, plus le réseau peut réduire les effets du jitter.

La perte de paquets perd des paquets le long du chemin de données, qui dégrade sévèrement l'application vocale.

Avant de déployer des applications VoIP, il est important d'évaluer le retard, le jitter, et la perte de paquets sur le réseau de données afin de déterminer si les Applications voix fonctionnent. Le retard, le jitter, et les mesures de perte de paquets peuvent alors faciliter la conception et la configuration de la hiérarchisation du trafic, aussi bien que les paramètres corrects de mise en mémoire tampon dans le matériel de réseau de données.

SAA et RTTMON

Le MIB SAA et RTTMON sont des Fonctions du logiciel Cisco IOS disponibles dans les versions 12.0 (5)T et ultérieures. Ces caractéristiques te permettent de tester et recueillir le retard, le jitter, et les statistiques de perte de paquets sur le réseau de données. L'Internetwork Performance Monitor (IPM) est une application d'administration réseau de Cisco qui peut configurer les caractéristiques et surveille les données SAA et RTTMON. Les caractéristiques SAA et RTTMON peuvent être utilisées pour mesurer le retard, le jitter, et la perte de paquets en déployant de petits routeurs Cisco IOS comme des agents pour simuler des stations d'extrémité de client. Les Routeurs désigné sous le nom des sondes de retard et instabilité. Supplémentaire, les sondes de retard et instabilité peuvent être configurées avec les déclencheurs d'alarme et d'événement de Surveillance à distance (RMON) une fois que des valeurs de spécification de base ont été déterminées. Ceci permet aux sondes de retard et instabilité pour surveiller le réseau pour les niveaux de service prédéterminés de retard et instabilité et les stations vigilantes du système d'administration de réseaux (NMS) quand un seuil est dépassé.

Déployer des Routeurs d'agent de retard et instabilité

Où se déployer

Le retard et instabilité peut être mesuré en déployant les Routeurs de Cisco 17xx ou plus élevé avec la version 12.05T ou ultérieures de code de logiciel Cisco IOS, et en configurant les caractéristiques du Cisco IOS SAA. Les Routeurs devraient être placés dans les réseaux campus à côté des hôtes. Ceci fournit des statistiques pour des connexions de bout en bout. Puisqu'il n'est pas pratique pour mesurer chaque chemin voix possible dans le réseau, placez les sondes dans des emplacements typiques d'hôte prévoyant un échantillonnage statistique des chemins voix typiques. Quelques exemples incluent :

  • un chemin local de campus-à-campus

  • un chemin local de campus de campus-à-distant par l'intermédiaire d'un circuit en relais de trame de 384 KBS

  • un campus local de campus-à-distant par l'intermédiaire d'un circuit virtuel permanent atmosphère (PVC)

Dans le cas des déploiements VoIP utilisant les téléphones traditionnels connectés aux Routeurs de Cisco utilisant des ports du Foreign Exchange Station (FXS), utilisez le routeur connecté aux téléphones pour servir de sondes de retard et instabilité. Une fois que déployée, la sonde recueille des statistiques et remplit tables MIB de Protocole SNMP (Simple Network Management Protocol) dans le routeur. Les données peuvent alors être accédées à par l'application de Cisco IPM ou par des outils d'interrogation SNMP. Supplémentaire, une fois que des valeurs de spécification de base ont été établies, SAA peut être configuré pour envoyer des alertes à une station NMS si des seuils pour le retard, le jitter, et la perte de paquets sont dépassés.

Simulation d'une communication voix

Une des forces d'utiliser SAA comme mécanisme de test est qu'une communication voix peut être simulée. Par exemple, imaginez-vous pour vouloir simuler G.711 une communication voix. Vous savez qu'il utilise les ports 14384 RTP/UDP et en haut, il est approximativement 64 kb/s, et la longueur de paquet est de 200 octets des octets {(160 de la charge utile + 40 octets pour IP/UDP/RTP (décompressé)}. Vous pouvez simuler que type de trafic en installant la sonde de retard/jitter SAA comme affiché ci-dessous.

L'exécution de jitter doit faire ceci :

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

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

  • Envoyez 3000 paquets pour chaque cycle de fréquence.

  • Envoyez à chaque paquet 20 millisecondes de distant pour une durée de 60 secondes et dormez 10 secondes avant de commencer le prochain cycle de fréquence.

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

  • ((3000 datagrammes * 160 octets par) de datagramme/60 secondes)) * 8 bits par octet = 64 kb/s

La configuration sur le routeur apparaît 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 considéré dans le request-data-size comme le routeur les ajoute automatiquement à la taille intérieurement.

Remarque: Actuellement, le Cisco IOS prend en charge seulement 1000 paquets par exécution. Cette limite sera élevée dans une version future.

Exemple de déploiement de sonde de retard et instabilité

Les Routeurs dans l'exemple suivant simulent les 60-deuxièmes communications voix toutes les 60 secondes et enregistrent le retard, le jitter, et la perte de paquets dans les deux directions.

Remarque: Les calculs de délai sont des durées d'aller-retour et doivent être divisés par deux pour obtenir le retard à sens unique.

/image/gif/paws/24121/saa-1.gif

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

Collectes des informations témoin

Vote des Tableaux MIB

Les sondes de retard et instabilité commencent collectant les données qui sont ultérieurement placées dans des tables MIB SNMP. La table de rttMonStats fournit une moyenne d'une heure de toutes les exécutions de jitter pour la dernière heure. La table de rttMonLatestJitterOper fournit les valeurs de la dernière exécution terminée. Pour des statistiques générales sur le retard et instabilité, votez les rttMonStats ajournent chaque heure. Pour des statistiques plus granulaires, votez la table de rttMonLatestJitterOper à un niveau plus élevé de fréquence que l'exécution de jitter. Par exemple, si la sonde de retard et instabilité calcule le jitter toutes les cinq minutes, ne votez le MIB à aucun intervalle moins de cinq minutes.

La capture d'écran suivante affiche des données du rttMonJitterStatsTable recueilli d'un balayage MIB de gestionnaire de HP OpenView Network Node.

/image/gif/paws/24121/saa-2.gif

Exemple d'état SAA

Le graphique suivant de données SAA est une compilation de retard, de jitter, et de points d'informations de perte de paquets sur une période de huit heures pour une paire de sondes de retard et instabilité.

/image/gif/paws/24121/saa-3.gif

Ligne de commande exemples de données

Les données peuvent également être visualisées utilisant la commande show de Cisco IOS à la ligne de commande sur les sondes de retard et instabilité. Un Perl s'attendent au script peut être utilisé pour recueillir des données de la ligne de commande et pour les exporter à un fichier texte pour l'analyse postérieure. Supplémentaire, la ligne de commande données peut également être utilisée pour le suivi en temps réel et le dépannage du retard, du jitter, et de la perte de paquets.

L'exemple suivant affiche la sortie de commande de la commande de collecte-stats de rtr d'exposition 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 y a plusieurs manières de surveiller le retard, le jitter, et les niveaux de perte de paquets dans le réseau une fois que des valeurs de spécification de base ont été établies par la collecte des informations initiale. Une manière est d'utiliser la commande de seuil SAA. Un autre est d'utiliser une caractéristique dans le Cisco IOS se pique l'alarme et l'événement de RMON appelés par code.

Commande de seuil SAA

La commande de seuil d'ensemble de caractéristiques SAA place le seuil montant (hystérésis) qui génère un événement de réaction et stocke les informations de historique pour l'exécution. La configuration suivante de seuil SAA sur la sonde de retard et instabilité active la surveillance du jitter et crée un déroutement SNMP sur la violation d'un seuil du ms 5.

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

Alarme et événement de RMON

Le retard et instabilité sonde par moniteur les seuils prédéterminés utilisant les caractéristiques de Cisco IOS SAA, ou la méthode d'alarme et d'événement de RMON de Cisco IOS. Dans l'un ou l'autre de cas, le routeur que les moniteurs retardent, se trémoussent, et perte de paquets et alertent des stations NMS des violations de seuil par l'intermédiaire des déroutements SNMP.

Les causes suivantes saarouter1 de configuration de déroutement d'alarme et d'événement de RMON pour générer un déroutement SNMP si le seuil montant dépasse le Round-Trip Time de maximum du ms 140. Il envoie également un autre déroutement quand le Round-Trip Time maximum tombe de retour en-dessous de 100 ms. Le déroutement est alors envoyé au login le routeur, aussi bien qu'à la station 172.16.71.19 NMS.

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 jitter dans des sondes de jitter de retard de Cisco SAA

Le jitter est la variance dans la latence à sens unique et est calculé a basé sur envoyer et recevoir des groupes date/heure des paquets consécutifs envoyés.

Groupe date/heure Expéditeur Responder
T1 envoyez pkt1  
T2   recv pkt1
T3   renvoyez la réponse pour pkt1
T4 réponse de recv pour pkt1  
T5 envoyez pkt2  
T6   recv pkt2
T7   renvoyez la réponse pour pkt2
T8 réponse de recv pour pkt2  

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

  • Trémoussez-vous de la source à la destination (JitterSD) = (T6-T2) - (T5-T1)

  • Trémoussez-vous de la destination à la source (JitterDS) = (T8-T4) - (T7-T3)

Le jitter est calculé utilisant des groupes date/heure de chaque 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 

Matériel et configurations du logiciel de routeur de sonde de retard et instabilité

  • CISCO1720 — routeur 10/100BaseT modulaire avec deux emplacements BLÊMES et logiciel IP de Cisco IOS

  • MEM1700-16U24D — Cisco 1700 16 24 à usine de mémoire vive dynamique de Mo mises à jour de Mo

  • MEM1700-4U8MFC — Cisco 1700 4 Mo à la mise à jour d'usine de carte de Mini-éclair du Mo 8

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

  • S17CP-12.1.1T — IOS IP de Cisco 1700 PLUS


Informations connexes


Document ID: 24121