Dépannage du bit TWAMP S défini de manière incorrecte

Introduction

Ce document décrit le protocole de mesure active et l'utilisation du bit de synchronisation (bit S) pour les mesures de délai. Il décrit la prise en charge du bit S dans la plate-forme IOS-XR.

   

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Protocole OWAMP (One-way Active Measurement Protocol)

• Protocole TWAMP (Two Way Active Measurement Protocol)

• Routeurs à services d'agrégation Cisco ASR 9000 (ASR9000)

Composants utilisés

Les informations contenues dans ce document sont basées sur Périphériques Cisco ASR9000 - version IOS-XR 5.3.4.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Problème : le bit TWAMP S n'est pas défini correctement

Vous pouvez utiliser TWAMP pour mesurer les performances unidirectionnelles et aller-retour entre deux périphériques pris en charge par TWAMP. Lorsque vous testez un accord de niveau de service de protocole Internet (IP SLA) basé sur TWAMP entre une sonde tierce et des périphériques CRS/ASR9000 qui s'exécutent sur IOS-XR 5.3.4, le serveur TWAMP définit le bit S sur False. Par conséquent, le délai unidirectionnel n'est pas calculé par le dispositif de sonde.

TWAMP fondamental

Le protocole OWAMP (One-way Active Measurement Protocol), spécifié dans la norme RFC4656, fournit un protocole commun pour mesurer les métriques unidirectionnelles entre les périphériques réseau. Le protocole OWAMP peut être utilisé de manière bidirectionnelle pour mesurer des mesures unidirectionnelles dans les deux sens entre deux éléments du réseau. Cependant, il ne permet pas les mesures aller-retour ou bidirectionnelles.

Le protocole TWAMP (Two-Way Active Measurement Protocol) décrit dans le document RFC5357 est un processus de surveillance des performances normalisé et très efficace qui s'appuie sur la spécification OWAMP (One-Way Active Measurement Protocol) définie dans le document RFC-4656, avec l'ajout de la mesure des performances des métriques aller-retour et bidirectionnelles pour les réseaux IP. TWAMP est une méthode indépendante du fournisseur permettant de mesurer avec précision les performances unidirectionnelles et aller-retour entre deux terminaux pris en charge par TWAMP.

Selon le RFC4656 (One-Way Active Measurement Protocol), le premier bit S doit être défini si la partie qui génère l'horodatage a une horloge synchronisée avec UTC par une source externe. 

Par exemple, le bit S doit être défini si :

• Le matériel GPS (Global Positioning System) est utilisé pour indiquer qu'il a acquis la position et l'heure actuelles.
• Le protocole NTP (Network Time Protocol) est utilisé pour indiquer qu'il est synchronisé avec une source externe, qui inclut la source de strate 0, etc.).
• Il n'y a pas de notion de synchronisation externe pour la source de temps, le bit S ne doit pas être défini.

The Error Estimate specifies the estimate of the error and
   synchronization.  It has the following format:

         0                   1
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |S|Z|   Scale   |   Multiplier  |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Les entités TWAMP :

Le système TWAMP se compose de 4 entités logiques :
    · serveur : gère une ou plusieurs sessions TWAMP et configure également des ports par session dans les points d'extrémité.
    · session-reflector : reflète un paquet de mesure dès qu'il reçoit un paquet de test TWAMP.
    · control-client - lance le démarrage et l'arrêt des sessions de test TWAMP
    · session-sender : instancie les paquets de test TWAMP envoyés au réflecteur de session

Les protocoles TWAMP :

Le protocole TWAMP comprend trois catégories distinctes d'échange de messages :

• Échange d'établissement de connexion

Les messages établissent une connexion de session entre le client de contrôle et le serveur. Tout d'abord, les identités des homologues communiqués sont établies via un mécanisme de réponse de défi. Le serveur envoie une demande de confirmation générée aléatoirement, à laquelle le client de contrôle envoie ensuite une réponse en chiffrant la demande de confirmation à l’aide d’une clé dérivée du secret partagé. Une fois les identités établies, l'étape suivante négocie un mode de sécurité qui est lié pour les commandes TWAMP-Control suivantes ainsi que les paquets de flux TWAMP-Test.

Remarque : un serveur peut accepter les demandes de connexion de plusieurs clients de contrôle.

• centre de contrôle des signaux PAMT

Le protocole TWAMP-Control s'exécute sur TCP et est utilisé pour instancier et contrôler les sessions de mesure. La séquence des commandes est la suivante, mais contrairement aux échanges de configuration de connexion, les commandes TWAMP-Control peuvent être envoyées plusieurs fois. Cependant, les messages ne peuvent pas être émis hors séquence, bien que plusieurs commandes request-session puissent être envoyées avant une commande session-start.
    ◦ Session de requête
    ◦ Début de session
    ◦ Arrêter la session

• Échange de flux de test TWAMP

TWAMP-Test s'exécute sur UDP et échange des paquets TWAMP-Test entre Session-Sender et Session-Reflector. Ces paquets comprennent des champs d'horodatage qui contiennent l'instant de sortie et d'entrée du paquet. En outre, chaque paquet comprend une estimation d'erreur qui indique le décalage de synchronisation de l'expéditeur (expéditeur de session ou réflecteur de session) avec une source temporelle externe (par exemple GPS ou NTP). Le paquet comprend également un numéro d'ordre.

TWAMP-Control et TWAMP-test stream, disposent de trois modes de sécurité : non authentifié, authentifié et chiffré.

Dépannage

Certaines plates-formes peuvent s'appuyer sur une configuration ou un déploiement spécifique pour fournir un horodatage matériel. En particulier, les routeurs de la gamme Cisco ASR9000 ont besoin de la synchronisation PTP (Precision Time Protocol) comme source d'horloge. Cette solution peut ne pas être disponible dans tous les scénarios utilisateur. Pour permettre l'utilisation d'autres sources d'horodatage (source d'horloge NTP, via un démon exécuté sur RouteProcessor (RP)), une nouvelle configuration de ipsla hw-timestamp disable est introduite pour ignorer les valeurs d'horodatage fournies par d'autres couches dépendantes de la plate-forme et revenir aux horodatages indépendants de la plate-forme.

Si la synchronisation d'horloge NTP est activée et activée, utilisez la commande hw-timestamp disable dans la configuration IP SLA pour désactiver l'horodatage matériel.

   
  

  ipsla
    hw-timestamp disable
    responder
      twamp
       timeout 100
      !
    !
    server twamp
      timer inactivity 100

Notes de version pour les routeurs à services d'agrégation de la gamme Cisco ASR 9000, version 6.0.1 introduit une nouvelle fonctionnalité d'amélioration de la précision TWAMP.

L'amélioration de la précision TWAMP fournit une granularité en microsecondes dans les mesures TWAMP. Cette amélioration permet la collecte des horodatages d'entrée et de sortie aussi près que possible du fil, pour obtenir plus de précision.

Vous pouvez mettre à niveau la version IOS XR vers 6.1.X et les versions ultérieures pour pouvoir utiliser la fonctionnalité d'amélioration de la précision TWAMP et vérifier l'obtention du comportement souhaité.

Vous pouvez effectuer ces étapes pour dépanner le problème ainsi que les captures de paquets

1. Configurez des valeurs plus élevées pour les délais d'attente pour le serveur et le répondeur twamp (par exemple 120s), afin que les informations n'expirent pas trop rapidement avant la collecte.
2. Puisque le débogage doit être activé, assurez-vous de configurer le périphérique pour envoyer des messages de journal de débogage au tampon de journalisation. La taille de la mémoire tampon de journalisation doit être configurée de manière à empêcher le basculement des messages de débogage au cours du test.
3. Assurez-vous que tous les paquets échangés entre le périphérique et la sonde sont capturés (non seulement les paquets de sonde UDP, mais également TCP pour l'établissement de session)
4. Collectez les commandes répertoriées à partir des périphériques ASR9000 ou CRS, selon l'endroit où les tests sont effectués :

Étape 1. Avant de commencer le test à partir de la sonde, collectez :

• longueur de borne 0
• show install active sum
• admin show platform
• admin show hw-module fpd location all
• Commande show run
• normes ipsla twamp
• vshow ipsla twamp status
• show ntp status
• show ntp associations detail

Étape 2. Activez tous les débogages Twamp sur le périphérique, puis effacez le journal.

1. démarrer la capture de paquets
2. démarrer le test à partir de la sonde 

Remarque : cela ne produit pas trop de sorties si c'est le seul test twamp qui s'exécute sur la sonde.

Étape 3.Collectez ces commandes une fois le test terminé

• show log
• show ipsla twamp connection detail
• show ipsla twamp connection requests
• show ipsla twamp session
• show ipsla trace twamp all verbose
• show ipsla trace twamp initialisation verbose    

Solution : bit S jamais implémenté dans IOS-XR

Conformément à la RFC 4656, s’il n’existe aucune notion de synchronisation externe pour la source temporelle, le bit ne doit pas être défini. Par conséquent, le bit S n'est pas implémenté dans la plate-forme IOS-XR.