Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

Comprendre le protocole de mesure active bidirectionnel

Découvrez comment utiliser le protocole TWAMP (Two-way Active Measurement Protocol) pour mesurer les performances d’un réseau entre deux appareils quelconques d’un réseau.

Le protocole TWAMP (Two-Way Active Management Protocol), décrit dans la RFC 5357, est une extension du protocole OWAMP (One-Way Active Management Protocol) qui fournit des mesures bidirectionnelles ou aller-retour au lieu de capacités unidirectionnelles. Les mesures bidirectionnelles sont utiles car les retards aller-retour ne nécessitent pas de synchronisation de l’horloge de l’hôte et l’assistance à distance peut être une simple fonction d’écho. Cependant, la requête/réponse d’écho ICMP (Internet Control Message Protocol) (utilisée par ping) à cette fin présente plusieurs lacunes. TWAMP définit un protocole ouvert permettant de mesurer les mesures bidirectionnelles ou aller-retour avec une plus grande précision que les autres méthodes à l’aide d’horodatages (les délais de traitement peuvent également être pris en compte).

Utilisez l’Explorateur de fonctionnalités : protocole de mesure active bidirectionnel pour confirmer la prise en charge de fonctionnalités spécifiques par la plate-forme et la version.

Consultez la section Comportement TWAMP spécifique à la plate-forme pour obtenir des remarques relatives à votre plate-forme.

Avantages de TWAMP

  • La configuration des sondes TWAMP vous permet d’activer, de tester, de surveiller et de dépanner votre réseau de bout en bout sans utiliser d’équipement de test dédié.

  • Les horodatages TWAMP fournissent des mesures bidirectionnelles ou aller-retour avec une plus grande précision que les autres méthodes (les délais de traitement peuvent également être pris en compte).

  • TWAMP est souvent utilisé pour vérifier la conformité aux accords de niveau de service (SLA), et la fonctionnalité TWAMP est souvent utilisée dans ce contexte.

  • Les mesures bidirectionnelles sont meilleures que les mesures unidirectionnelles, car les retards aller-retour ne nécessitent pas de synchronisation de l’horloge hôte. Cela est possible parce que le réflecteur place son propre numéro de séquence dans le paquet.

Note:

Nous vous recommandons de ne pas configurer le client RPM et un serveur TWAMP sur le même périphérique. Cela peut entraîner des problèmes dans les résultats de la sonde RPM.

Comprendre le protocole de mesure active bidirectionnel (TWAMP)

Habituellement, TWAMP fonctionne entre les interfaces de deux appareils jouant des rôles spécifiques. TWAMP est souvent utilisé pour vérifier la conformité aux accords de niveau de service (SLA), et la fonctionnalité TWAMP est souvent présentée dans ce contexte. TWAMP utilise deux protocoles liés, s’exécutant entre plusieurs éléments définis :

  • TWAMP-Control : lance, démarre et met fin aux sessions de test. Le protocole TWAMP-Control s’exécute entre un élément Control-Client et un élément Server.

  • TWAMP-Test : échange des paquets de test entre deux éléments TWAMP. Le protocole TWAMP-Test s’exécute entre un élément Session-Sender et un élément Session-Reflector.

Les quatre éléments sont illustrés à la figure 1 :

Figure 1 : Quatre éléments de TWAMP Four Elements of TWAMP

Bien que quatre périphériques TWAMP différents puissent remplir les quatre rôles logiques de TWAMP Control-Client, Server, Session-Sender et Session-Reflector, différents périphériques peuvent jouer différents rôles. Une implémentation courante combine les rôles de client-contrôle et d’expéditeur de session dans un périphérique (connu sous le nom de contrôleur TWAMP ou client TWAMP) et les rôles de serveur et de réflecteur de session dans l’autre périphérique (connu sous le nom de répondeur TWAMP ou serveur TWAMP). Dans ce cas, chaque périphérique exécute à la fois les protocoles TWAMP-Control (entre Control-Client et Server) et TWAMP-Test (entre Session-Sender et Session-Reflector).

L’architecture client-serveur TWAMP, telle qu’elle est implémentée, ressemble à ceci :

  • Client TWAMP

    • Control-Client configure, démarre et arrête les sessions de test TWAMP.

    • Session-Sender crée des paquets de test TWAMP qui sont envoyés au Session-Reflector sur le serveur TWAMP.

  • Serveur TWAMP

    • Session-Reflector renvoie un paquet de mesure lorsqu’un paquet de test est reçu, mais ne conserve pas d’enregistrement de ces informations.

    • Le serveur gère une ou plusieurs sessions avec le client TWAMP et écoute les messages de contrôle sur un port TCP.

L’empaquetage de ces éléments dans les processus du client TWAMP et du serveur TWAMP est illustré à la figure 2.

Figure 2 : Les éléments de TWAMP implémentés en tant que client (à gauche) et serveur (à droite). The Elements of TWAMP Implemented as Client (Left) and Server (Right).

Prise en charge de la lumière TWAMP

TWAMP Light, tel que défini dans l’Appendice I de la RFC 5357, est une version sans état de TWAMP où les paramètres de test sont prédéfinis au lieu d’être négociés. Tous les paquets de test reçus par le serveur sur un port de test sont immédiatement renvoyés et oubliés. Pour les équipements qui les prennent en charge, vous pouvez également configurer des adresses cibles IPv6, y compris des adresses cibles locales de liaison IPv6.

Utilisez l’Explorateur de fonctionnalités : protocole de mesure active bidirectionnel pour confirmer la prise en charge de fonctionnalités spécifiques par la plate-forme et la version.

Prise en charge simple du protocole de mesure active bidirectionnel (STAMP)

Comme défini dans la RFC 8762, Simple Two-Way Active Measurement Protocol, STAMP normalise et développe le mode de fonctionnement TWAMP Light, qui a été défini dans l’Appendice I de la RFC 5357, Two-Way Active Measurement Protocol (TWAMP). Pour les appareils qui prennent en charge STAMP, un réflecteur compatible STAMP garantit une taille de charge utile symétrique (conformément à la RFC 6038) et fonctionne en mode sans état ou dynamique, selon que le numéro de séquence dans la charge utile réfléchie est copié à partir de la trame client ou généré indépendamment. Un réflecteur dynamique peut détecter dans quelle direction les chutes se sont produites. Dans les versions précédentes, nous prenions en charge les charges utiles symétriques et la réflexion sans état. Nous prenons en charge la réflexion dynamique, la conformité totale à la norme STAMP et les valeurs de chute unidirectionnelles pour les clients. Nous prenons en charge les valeurs de perte unidirectionnelles non seulement pour les clients STAMP, mais également pour les clients en mode géré TWAMP. Pour Junos OS Evolved, STAMP est configuré au niveau de la [edit services monitoring twamp server light] hiérarchie. La réflexion dynamique est configurée avec l’instruction stateful-sequence . Pour les serveurs, la nouvelle valeur par défaut pour offload-type est maintenant pfe-timestamp au lieu de inline-timestamp.

Utilisez l’Explorateur de fonctionnalités : Simple Two-way Active Measurement Protocol (STAMP) pour confirmer la prise en charge de la plate-forme et de la version.

Suivi d’itinéraire statique

À partir de la version 24.4R1 de Junos OS Evolved, nous avons étendu la prise en charge du suivi de route statique à Junos OS Evolved et inclus la prise en charge des tests TWAMP (Two-way Active Measurement Protocol). Les sondes TWAMP permettent de détecter l’état de la liaison et de modifier l’état de la route préférée en fonction des résultats de la sonde. Les routes statiques suivies peuvent être IPv4 ou IPv6, et chaque route statique suivie IPv4 et IPv6 prend en charge jusqu’à 16 sauts suivants. Vous pouvez également configurer les valeurs de métrique, de préférence de route et de balise pour chaque préfixe de destination IPv4 ou IPv6. Toutefois, vous configurez cette fonction différemment sur les équipements Junos OS Evolved ; Vous configurez l’instruction sla-tracking au niveau de la [edit routing-options] hiérarchie. Vous pouvez également utiliser une autre commande, show route sla-tracking, pour afficher des informations sur ces itinéraires.

Prise en charge du Segment Routing pour la configuration des chemins

À partir de la version 24.4R1 de Junos OS Evolved, nous avons ajouté la prise en charge du routage de segments (SR) dans le protocole TWAMP (Two-way Active Measurement Protocol) pour le routage de segments (SR), tel que défini dans la RFC 8402, qui spécifie globalement l’architecture SR. Nous prenons en charge deux types de SR pour les sondes TWAMP :

  • SR-MPLS : Utilise une liste d’étiquettes, chacune représentant un nœud d’extrémité de segment.

  • SRv6 : Utilise un en-tête de routage IPv6 de type 4 introduit dans la RFC 8754, chaque nœud d’extrémité de segment étant représenté par une adresse IPv6 ou un identifiant de segment IPv6 (SID).

Vous pouvez spécifier la liste des segments SR-MPLS ou SRv6 pour qu’une sonde TWAMP atteigne le réflecteur. De plus, vous pouvez spécifier les mêmes informations pour le chemin de retour du réflecteur au client. Ces informations de chemin de retour sont intégrées dans la sonde elle-même à l’aide des extensions proposées dans Simple TWAMP (STAMP) Extensions for Segment Routing Networks, draft-ietf-ippm-stamp-srpm, à savoir le TLV du chemin de retour et ses sous-TLV de liste de segments de retour, selon le cas en fonction du type de routage de segment. Les sondes TWAMP sont horodatées soit dans le moteur de routage, soit dans le moteur de transfert de paquets.

Pour configurer cette fonctionnalité, incluez l’instruction source-routing au niveau de la [edit services monitoring twamp client control-connection name test-session session-name hiérarchie.

Junos OS Evolved : différences dans la prise en charge de TWAMP

La prise en charge de TWAMP par Junos OS Evolved est limitée aux éléments suivants :

  • Trafic IPv4 et IPv6 uniquement pour les sessions de contrôle et les sessions de test. À partir de Junos OS Evolved version 21.4R1, les adresses source et cible IPv6 (à l’exception des adresses lien-local) sont prises en charge pour les listes de clients, les connexions de contrôle et les sessions de test.

  • Statistiques et historique des sondes

  • Contrôler et tester l’état de la session

  • Génération et réception de sondes de session de test, ainsi que réflexion

  • Horodatages définis par le moteur de routage ou le moteur de transfert de paquets pour le trafic IPv4. Pour le trafic IPv6, horodatages définis par le moteur de routage uniquement. Pour le trafic IPv6, à partir de Junos OS Evolved 22.3R1, nous prenons en charge les horodatages du moteur de transfert de paquets. Avant Junos OS Evolved version 22.3R1, pour le trafic IPv6, l’instruction au niveau de la hiérarchie devait être configurée sous la offload-type [edit services monitoring twamp client control-connection name test-session name] forme none. À partir de Junos OS Evolved version 22.4R1 pour les périphériques pris en charge, vous pouvez configurer l’option inline-timestamping de l’instruction offload-type pour activer les horodatages définis en ligne par le matériel.

    À partir de Junos OS Evolved version 23.4R1 pour serveurs, la valeur par défaut de l’instruction offload-type est désormais pfe-timestamp au lieu de inline-timestamp.

  • Rapports d’erreurs uniquement via les messages du journal système et les interruptions SNMP

  • Mode non authentifié uniquement

La prise en charge de TWAMP par Junos OS Evolved inclut également certaines fonctionnalités qui ne sont pas incluses dans Junos OS :

Comportement TWAMP spécifique à la plate-forme

Utilisez l’Explorateur de fonctionnalités : protocole de mesure active bidirectionnel pour confirmer la prise en charge de fonctionnalités spécifiques par la plate-forme et la version.

Utilisez le tableau suivant pour passer en revue les comportements spécifiques à votre plateforme.

Tableau 1 : comportement TWAMP spécifique à la plate-forme
La différence de la plate-forme

ACX Series

  • En Junos OS, les routeurs ACX710 et ACX5448 Series prennent en charge à la fois la réflexion et la génération. D’autres routeurs ACX Series exécutant Junos OS prennent uniquement en charge la réflexion, et non la génération.

  • Dans Junos OS Evolved, TWAMP est pris en charge pour les routeurs ACX, tant pour la réflexion que pour la génération. Reportez-vous à la section Différences entre Junos OS Evolved et la prise en charge de TWAMP pour obtenir des remarques sur les différences entre les systèmes d’exploitation dans la prise en charge de TWAMP.

  • Pour Junos OS, TWAMP est configuré au niveau de la [edit services rpm twamp] hiérarchie. Pour Junos OS Evolved, TWAMP est configuré au niveau de la [edit services monitoring twamp] hiérarchie.

  • Le trafic de connexion de contrôle TWAMP arrive toujours sur les routeurs ACX avec le port d’écoute défini sur 862. Étant donné que ce numéro de port pour les sondes de trafic peut être modifié, les sondes qui arrivent avec un numéro de port différent ne sont pas reconnues et traitées correctement par les routeurs ACX. Par conséquent, le trafic TWAMP et les paquets liés à l’hôte sont abandonnés dans un tel scénario.

  • Pour inline-timestamping le mode, le client et le serveur TWAMP ne peuvent pas être configurés sur le même routeur ACX.

  • En inline-timestamping mode, TWAMP sur VPN de couche 3 n’est pas pris en charge.

  • Avant Junos OS Evolved version 23.4R1, si TWAMP et la gestion des pannes de connectivité (CFM) sont configurés, le client TWAMP abandonne les sondes TWAMP. Supprimez la configuration CFM pour activer TWAMP. À partir de Junos OS Evolved version 23.4R1, vous pouvez configurer CFM sur le même équipement que TWAMP.

EX Series

Le client de contrôle et l’expéditeur de session (le client TWAMP) résident sur le même routeur Juniper Networks. Toutefois, le client TWAMP n’a pas besoin que le serveur et le réflecteur de session se trouvent sur le même système. Par conséquent, le client Juniper TWAMP est capable de fonctionner avec une implémentation serveur tierce.

MX Series

  • Le client de contrôle et l’expéditeur de session (le client TWAMP) résident sur le même routeur Juniper Networks. Toutefois, le client TWAMP n’a pas besoin que le serveur et le réflecteur de session se trouvent sur le même système. Par conséquent, le client Juniper TWAMP est capable de fonctionner avec une implémentation serveur tierce.

  • TWAMP n’est pas pris en charge lorsque vous activez les services nouvelle génération sur un routeur MX Series.

PTX Series

  • L’attribut d’interface si-x/y/z de destination, qui permet d’activer les services en ligne, n’est pas pris en charge sur les routeurs PTX Series pour les configurations client TWAMP.

  • Pour Junos OS, TWAMP est configuré au niveau de la [edit services rpm twamp] hiérarchie. Pour Junos OS Evolved, TWAMP est configuré au niveau de la [edit services monitoring twamp] hiérarchie. Reportez-vous à la section Différences entre Junos OS Evolved et la prise en charge de TWAMP pour obtenir des remarques sur les différences entre les systèmes d’exploitation dans la prise en charge de TWAMP.

Série QFX 10000

Le client de contrôle et l’expéditeur de session (le client TWAMP) résident sur le même routeur Juniper Networks. Toutefois, le client TWAMP n’a pas besoin que le serveur et le réflecteur de session se trouvent sur le même système. Par conséquent, le client Juniper TWAMP est capable de fonctionner avec une implémentation serveur tierce.

Série QFX5000 (Junos OS Evolved)

Pour Junos OS Evolved, TWAMP est configuré au niveau de la [edit services monitoring twamp] hiérarchie. Reportez-vous à la section Différences entre Junos OS Evolved et la prise en charge de TWAMP pour obtenir des remarques sur les différences entre les systèmes d’exploitation dans la prise en charge de TWAMP.

SRX Series (équipements et instances Pare-feu virtuel vSRX SRX300, SRX320, SRX340, SRX345, SRX550M, SRX1500, SRX4100 et SRX4200)

  • TWAMP pour IPv6 n’est pas pris en charge.

  • L’authentification du serveur TWAMP et du client TWAMP n’est pas prise en charge.

  • La lumière TWAMP n’est pas prise en charge.

Pour la MX Series, le tableau ci-dessous montre la relation entre la prise en charge du client et du serveur RPM, la prise en charge du client TWAMP (avec le composant de contrôle) et du serveur TWAMP (avec le composant répondeur), et le matériel qui effectue l’horodatage.

Tableau 2 : prise en charge des fonctionnalités TWAMP et matériel pour Junos OS, MX Series

Prise en charge des fonctionnalités TWAMP

Horodatage du moteur de routage

Horodatage MS-PIC/MS-DPC

Horodatage MS-MIC/MS-MPC

Horodatage du moteur de transfert de paquets (micro-noyau)

Horodatage du moteur de transfert de paquets (LU) (si- interface)

RPM Client

Oui

Oui

Oui

Oui

Non

Serveur RPM

Oui

Oui

Oui

Oui

Non

TWAMP Client

Non

Non

Non

Oui

Oui

Serveur TWAMP

Non

Oui

Non

Oui (aucune configuration de répondeur nécessaire)

Oui
Note:

La prise en charge des interfaces de services (sp-, ms-, et si- interfaces) est légèrement différente.

Le Tableau 3 fournit des informations sur MX Series TWAMP et la prise en charge de l’horodatage associée sur MPC, MS-MIC/MPC et en ligne :

Tableau 3 : prise en charge de TWAMP et de l’horodatage associé, MX Series

Caractéristique

Rôle

IP Version

Soutien (O/N)

Horodatage en ligne

Horodatage sur MPC (hardware-timestamp)

Horodatage sur MPC (si-interface)

Horodatage sur MS-MIC/MPC (delegate-probes)

TWAMP (en anglais seulement)

Client

IPv4 (en anglais)

Y

N

O (μsec)

500 sondes maximum

O (μsec)

500 sondes maximum

N

IPv6 (en anglais)

N

N

N

N

N

Serveur

IPv4 (en anglais)

Y

N

O (μsec)

500 sondes maximum

O (μsec)

500 sondes maximum

N

IPv6 (en anglais)

N

N

N

N

N

Documentation connexe