Comprendre le protocole de mesure active bidirectionnel
Découvrez comment utiliser le protocole TWAMP (Two-Way Active Measurement Protocol) pour mesurer les performances réseau entre deux appareils quelconques au sein d’un réseau.
Le protocole de gestion active bidirectionnelle (TWAMP), décrit dans la RFC 5357, est une extension du protocole de gestion active unidirectionnelle (OWAMP) 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 demande/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 pour mesurer les mesures bidirectionnelles ou aller-retour avec une plus grande précision que les autres méthodes en utilisant des 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 la plate-forme et de la version pour des fonctionnalités spécifiques.
Consultez la section Comportement TWAMP spécifique à la plate-forme pour les notes relatives à votre plate-forme.
Avantages du TWAMP
-
La configuration des sondes TWAMP vous aide à activer, tester, surveiller et 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 car le réflecteur place son propre numéro de séquence dans le paquet.
Nous vous recommandons de ne pas configurer le client RPM et un serveur TWAMP sur le même appareil. 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. Le 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, fonctionnant entre plusieurs éléments définis :
-
TWAMP-Control : lance, démarre et termine les 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 dans la figure 1 :
Bien que quatre périphériques TWAMP différents puissent remplir les quatre rôles logiques de contrôle TWAMP - Client, Serveur, Expéditeur de session et Réflecteur de session, différents périphériques peuvent jouer des rôles différents. Une implémentation commune combine les rôles de client de contrôle et d’expéditeur de session dans un périphérique (appelé contrôleur TWAMP ou client TWAMP) et les rôles de serveur et de réflecteur de session dans l’autre périphérique (appelé répondeur TWAMP ou serveur TWAMP). Dans ce cas, chaque appareil 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 installe, démarre et arrête les sessions de test TWAMP.
-
L’expéditeur de session crée des paquets de test TWAMP qui sont envoyés au réflecteur de session du serveur TWAMP.
-
-
Serveur TWAMP
-
Session-Reflector renvoie un paquet de mesure lorsqu’un paquet de test est reçu, mais ne conserve pas de trace de cette information.
-
Le serveur gère une ou plusieurs sessions avec le client TWAMP et écoute les messages de contrôle sur un port TCP.
-
La figure 2 illustre l’empaquetage de ces éléments dans les processus client et serveur TWAMP.
- Prise en charge de la lumière TWAMP
- Prise en charge simple du protocole STAMP (Two-way Active Measurement Protocol)
- Suivi de route statique
- Prise en charge du Segment Routing pour la configuration des chemins
- Horodatage
Prise en charge de la lumière TWAMP
TWAMP Light, tel que défini dans l’Annexe 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 renvoyés et oubliés immédiatement. Pour les appareils qui les prennent en charge, vous pouvez également configurer des adresses cibles IPv6, y compris des adresses cibles locales IPv6.
Utilisez l’explorateur de fonctionnalités : protocole de mesure active bidirectionnel pour confirmer la prise en charge de la plate-forme et de la version pour des fonctionnalités spécifiques.
Prise en charge simple du protocole STAMP (Two-way Active Measurement Protocol)
Tel que 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’annexe I de la RFC 5357, Two-Way Active Measurement Protocol (TWAMP). Pour les appareils qui prennent en charge STAMP, un réflecteur conforme à STAMP garantit une taille de charge utile symétrique (conformément à la RFC 6038) et fonctionne en mode sans état ou avec état, selon que le numéro de séquence de 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 avec la norme STAMP et les valeurs de chute unidirectionnelles pour les clients. Nous prenons en charge les valeurs de chute 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’instructionstateful-sequence. Pour les serveurs, la nouvelle valeur par défaut est maintenant pfe-timestamp au offload-type lieu de inline-timestamp.
Utilisez l’explorateur de fonctionnalités : protocole STAMP (Simple Two-Way Active Measurement Protocol) pour confirmer la prise en charge de la plate-forme et de la version.
Suivi de route statique
À partir de la version 24.4R1 de Junos OS Evolved, nous avons étendu la prise en charge du suivi de routage statique à Junos OS Evolved et inclus également la prise en charge des tests TWAMP (Two-Way Active Measurement Protocol). Vous utilisez les sondes TWAMP pour détecter l’état des liaisons et modifier l’état du routage préféré sur la base 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 routage et de balise pour chaque préfixe de destination IPv4 ou IPv6. Toutefois, vous configurez cette fonctionnalité différemment sur les équipements Junos OS Evolved ; Vous configurez l’instruction sla-tracking au niveau de la [edit routing-options] hiérarchie. Vous utilisez également une commande différente, 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 Junos OS Evolved version 24.4R1 pour les routeurs PTX qui le prennent en charge et de Junos OS version 25.4R1 pour les routeurs MX qui le prennent en charge, nous avons ajouté la prise en charge du protocole TWAMP (Two-way Active Measurement Protocol) pour le routage de segments (SR) tel que défini dans 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 norme RFC 8754, chaque nœud d’extrémité de segment étant représenté sous la forme d’une adresse IPv6 ou d’un identificateur de segment (SID) IPv6.
Vous pouvez spécifier la liste des segments SR-MPLS ou SRv6 pour qu’une sonde TWAMP atteigne le réflecteur. En outre, 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 chemin de retour TLV et ses sous-TLV de liste de segments de retour, selon le type de routage de segment. Les sondes TWAMP sont horodatées dans le moteur de routage ou le moteur de transfert de paquets.
Pour configurer cette fonctionnalité pour Junos OS Evolved, incluez l’instruction source-routing au niveau de la [edit services monitoring twamp client control-connection name test-session session-name] hiérarchie. Pour configurer cette fonctionnalité pour Junos OS, incluez l’instruction source-routing au niveau de la [edit services rpm twamp client control-connection name test-session session-name] hiérarchie.
Horodatage
Par défaut, pour la plupart des plates-formes, les horodatages sont définis dans le processeur hôte du moteur de transfert de paquets. Pour tenir compte de la latence dans la communication des messages de sonde, vous pouvez décharger l’horodatage des paquets de sonde sur le matériel du moteur de transfert de paquets. Ce type d’horodatage est appelé horodatage en ligne, où l’horodatage est effectué dans le matériel du générateur ou du réflecteur, juste avant que le paquet ne quitte l’appareil. La prise en charge de ce déchargement et de cet horodatage en ligne varie selon la version, la plate-forme et la prise en charge de la carte de ligne :
-
Junos OS : Avant Junos OS version 25.4R1, vous pouviez activer l’horodatage en ligne en configurant une
si-interface ousp-. À partir de la version 25.4R1 de Junos OS, pour les cartes de ligne MX qui le prennent en charge, vous pouvez décharger l’horodatage sur le matériel du moteur de transfert de paquets à l’aide de cetteoffload-type inline-timestampoption. Cette fonctionnalité d’horodatage en ligne prend également en charge Flex Algo et SR-MPLS.Si
si-les interfaces sont configurées sur un routeur MX pour TWAMP, cette option est l’option par défaut pour l’horodatage. Pour déboguer l’implémentation de l’interfacesi-, vous devez configurer l’optionnoneou l’optionpfe-timestamp.Vous configurez l’instruction à l’un
offload-type (inline-timestamp | none | pfe-timestamp)des niveaux hiérarchiques suivants :[edit services rpm twamp client control-connection name test-session name],[edit services rpm twamp server]ou[edit services rpm twamp server light]. -
Junos OS Evolved : Les horodatages sont définis par le moteur de routage ou le moteur de transfert de paquets pour le trafic IPv4. Pour le trafic IPv6, les horodatages sont définis uniquement par le moteur de routage. 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
offload-typeau niveau de la[edit services monitoring twamp client control-connection name test-session name]hiérarchie devait être configurée comme .noneÀ partir de la version 22.4R1 de Junos OS Evolved pour les équipements pris en charge, vous pouvez configurer l’optioninline-timestampingde l’instructionoffload-typepour activer les horodatages définis en ligne par le matériel. À partir de Junos OS Evolved version 23.4R1 pour les serveurs, la valeur par défaut de l’instructionoffload-typeest désormaispfe-timestampau lieu deinline-timestamp. À partir de Junos OS Evolved version 25.4R1, la fonctionnalité d’horodatage en ligne prend également en charge Flex Algo et SR-MPLS.
Différences de Junos OS Evolved 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 de test. À partir de la version 21.4R1 de Junos OS Evolved, les adresses IPv6 source et cible (à l’exception des adresses de liaison locale) 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
-
Signalement des erreurs via les messages du journal système et les interruptions SNMP uniquement
-
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 :
-
À partir de la version 23.4R1 de Junos OS Evolved, nous prenons en charge la norme RFC 8762, Simple Two-Way Active Measurement Protocol (STAMP). La RFC 8762 normalise et développe le mode de fonctionnement TWAMP Light, qui a été défini à l’annexe I de la RFC 5357, Two-Way Active Measurement Protocol (TWAMP). Pour plus d’informations, consultez Prise en charge du protocole STAMP (Simple Two-Way Active Measurement Protocol).
-
À partir de la version 24.4R1 de Junos OS Evolved, nous prenons en charge le suivi de routage statique à l’aide de TWAMP pour les équipements qui prennent en charge cette fonctionnalité. Voir Suivi de routage statique pour plus d’informations.
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 la plate-forme et de la version pour des fonctionnalités spécifiques.
Utilisez le tableau suivant pour passer en revue les comportements spécifiques à votre plateforme.
| Différence de plate-forme | |
|---|---|
| ACX Series |
|
| EX Series |
Le client de contrôle et l’expéditeur de session (le client TWAMP) résident tous deux sur le même routeur Juniper Networks. Cependant, le client TWAMP n’exige pas que le serveur et le réflecteur de session soient sur le même système. Par conséquent, le client TWAMP de Juniper peut fonctionner avec une implémentation serveur tierce. |
| MX Series |
|
| PTX Series |
|
| Série QFX10000 |
Le client de contrôle et l’expéditeur de session (le client TWAMP) résident tous deux sur le même routeur Juniper Networks. Cependant, le client TWAMP n’exige pas que le serveur et le réflecteur de session soient sur le même système. Par conséquent, le client TWAMP de Juniper peut fonctionner avec une implémentation serveur tierce. |
| Série QFX5000 (Junos OS Evolved) |
Pour Junos OS Evolved, TWAMP est configuré au niveau de la |
| SRX Series (appareils SRX300, SRX320, SRX340, SRX345, SRX550M, SRX1500, SRX4100 et SRX4200 et les instances Pare-feu virtuel vSRX) |
|
Pour la MX Series, le tableau ci-dessous indique 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 responder), et le matériel qui effectue l’horodatage.
| 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) ( |
| 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 |
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 la prise en charge de la fonction TWAMP MX Series et de l’horodatage associé sur MPC, MS-MIC/MPC et en ligne :
| Fonctionnalité |
Rôle |
IP Version |
Soutien (O/N) |
Horodatage en ligne |
Horodatage sur MPC (hardware-timestamp) |
Horodatage sur MPC (interface si) |
Horodatage sur MS-MIC/MPC (delegate-sondes) |
|---|---|---|---|---|---|---|---|
| TWAMP |
Client géré |
IPv4 |
Y |
N |
Y (μsec) 1000 sondes maximum |
Y (μsec) 1000 sondes maximum |
N |
| IPv6 |
N |
N |
N |
N |
N |
||
| Serveur géré |
IPv4 |
Y |
N |
Y (μsec) 1000 sondes maximum |
Y (μsec) 1000 sondes maximum |
N |
|
| IPv6 |
N |
N |
N |
N |
N |
| Fonctionnalité |
Rôle |
IP Version |
Soutien (O/N) |
Horodatage en ligne |
Horodatage sur MPC (hardware-timestamp) |
Horodatage sur MPC (interface si) |
Horodatage sur MS-MIC/MPC (delegate-sondes) |
|---|---|---|---|---|---|---|---|
| TWAMP |
Client léger |
IPv4 |
Y |
O (μsec) (à partir de la version 25.4R1) 1000 sondes maximum |
Y (μsec) 1000 sondes maximum |
Y (μsec) 1000 sondes maximum |
N |
| IPv6 |
Y |
O (μsec) (à partir de la version 25.4R1) 1000 sondes maximum |
Y (μsec) 1000 sondes maximum |
Y (μsec) 1000 sondes maximum |
N |
||
| Serveur léger |
IPv4 |
Y |
O (μsec) (à partir de la version 25.4R1) 1000 sondes maximum |
Y (μsec) 1000 sondes maximum |
Y (μsec) 1000 sondes maximum |
N |
|
| IPv6 |
Y |
O (μsec) (à partir de la version 25.4R1) 1000 sondes maximum |
Y (μsec) 1000 sondes maximum |
Y (μsec) 1000 sondes maximum |
N |