Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Comprendre le protocole de mesure active bidirectionnelle

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

Avantages de TWAMP

  • La configuration TWAMP vous aide à activer, tester, surveiller et dépanner votre réseau de bout en bout sans utiliser d’appareil de test dédié.

  • Les horodatages TWAMP fournissent des métriques 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é des 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 appareil. Cela peut entraîner des problèmes dans les résultats de la sonde RPM.

Comprendre le protocole TWAMP (Two-Way Active Measurement Protocol)

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 délais aller-retour ne nécessitent pas de synchronisation de l’horloge hôte et l’assistance à distance peut être une simple fonction d’écho. Cependant, l’Internet Control Message Protocol (ICMP) Echo Request/Reply (utilisé par ping) à cette fin présente plusieurs lacunes. TWAMP définit un protocole ouvert pour mesurer les métriques 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).

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

  • TWAMP-Control : initie, démarre et termine les sessions de test. Le protocole TWAMP-Control fonctionne 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 fonctionne 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 du 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 des rôles différents. Une implémentation courante combine les rôles de Control-Client et de Session-Sender dans un périphérique (appelé contrôleur TWAMP ou client TWAMP) et les rôles de serveur et de session-réflecteur 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’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 dans 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 client TWAMP et 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).

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

Tableau 1 : prise en charge de TWAMP et de l’horodatage associé

Fonction

Rôle

IP Version

Assistance (O/N)

Horodatage en ligne

Horodatage sur MPC (horodatage matériel)

Horodatage sur MPC (interface si)

Horodatage sur MS-MIC/MPC (sondes déléguées)

TWAMP

Client

IPv4

Y

¡n

Y (μsec)

500 sondes maximum

Y (μsec)

500 sondes maximum

¡n

IPv6

¡n

¡n

¡n

¡n

¡n

Serveur

IPv4

Y

¡n

Y (μsec)

500 sondes maximum

Y (μsec)

500 sondes maximum

¡n

IPv6

¡n

¡n

¡n

¡n

¡n

Prise en charge de TWAMP Light

Le Tableau 2 fournit des informations sur la prise en charge de TWAMP Light, telle que définie dans l’Annexe I de la RFC 5357, qui définit une version allégée du protocole TWAMP, 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.

La prise en charge des adresses cibles IPv6 pour les sessions de test TWAMP Light est introduite dans Junos OS version 21.3R1, comme indiqué dans le tableau ci-dessous.

La prise en charge des adresses cibles locales de liaison IPv6 est introduite dans Junos OS version 21.4R1, pour les routeurs MX Series et PTX1000, PTX3000 et PTX5000 et dans Junos OS Evolved version 22.3R1, pour les routeurs ACX7100, ACX7509, PTX10001-36MR, PTX10003, PTX10004, PTX10008 et PTX10016.

Tableau 2 : prise en charge de TWAMP Light
Appareil pris en charge dans
ACX710 Junos OS version 22.3R1
Série ACX5448 Junos OS version 22.3R1
Série ACX7100 Junos OS Evolved version 21.2R1
ACX7509 Junos OS Evolved version 22.3R1
MX Series, avec LC480, LC2101, LC2103 et MPC jusqu’au MPC9E inclus Junos OS version 21.1R1 (IPv4), Junos OS version 21.3R1 (IPv6)
MX Series avec les cartes de ligne suivantes : LMIC16-BASE, LC9600, MPC10E et MPC11E
  • Client IPv4 : Junos OS version 21.1R1
  • Serveur IPv4 : Junos OS version 22.2R1
  • Client et serveur IPv6 : Junos OS version 22.3R1

PTX Series sous Junos OS, avec MPC jusqu’au MPC9E inclus Junos OS version 21.1R1 (IPv4), Junos OS version 21.3R1 (IPv6)
PTX Series sous Junos OS, avec cartes de ligne MPC10E et MPC11E
  • client : Junos OS version 21.1R1 (IPv4)
  • serveur : Junos OS version 22.2R1 (IPv4)
PTX10001-36MR
  • Junos OS Evolved version 21.1R1 (IPv4)

  • Junos OS Evolved version 21.4R1 (IPv6)

PTX10003
  • Junos OS Evolved version 20.3R1 (IPv4)

  • Junos OS Evolved version 21.4R1 (IPv6)

PTX10004
  • Junos OS Evolved version 21.2R1 (IPv4)

  • Junos OS Evolved version 21.4R1 (IPv6)

PTX10008 et PTX10016 (avec la carte de ligne JNP10008-SF3 et JNP10K-LC1201 ou JNP10K-LC1202-36MR)
  • Junos OS Evolved version 21.1R1 (IPv4)

  • Junos OS Evolved version 21.4R1 (IPv6)

QFX5130-32CD, QFX5220 et QFX5700 Junos OS Evolved 22.4R1 (IPv4 et IPv6)
QFX10002, QFX10008 et QFX10016 Junos OS version 21.3R1 (IPv4)
EX9200 Junos OS version 21.4R1

Prise en charge du protocole STAMP (Simple Two-Way Active Measurement Protocol)

Le Tableau 3 fournit des informations sur la prise en charge de TWAMP Light, telle que définie dans la norme RFC 8762, Simple Two-Way Active Measurement Protocol (STAMP). La norme RFC 8762 standardise et développe le mode de fonctionnement TWAMP Light, défini dans l’Annexe I de la RFC 5357, Two-Way Active Measurement Protocol (TWAMP). Un réflecteur conforme à STAMP garantit une taille de charge utile symétrique (conformément à la norme RFC 6038) et fonctionne en mode sans état ou sans é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 des gouttes 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 désormais en charge la réflexion dynamique, le respect total de la norme STAMP et les valeurs de chute unidirectionnelles pour les clients. Nous prenons en charge les valeurs de drop unidirectionnelles non seulement pour les clients STAMP, mais également pour les clients en mode géré par TWAMP. Pour Junos OS Evolved, STAMP est configuré au niveau de la hiérarchie [edit services monitoring twamp server light]. 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.

Tableau 3 : Prise en charge de STAMP

Appareil

Pris en charge dans

ACX7024, ACX7024X, ACX7100-32C, ACX7100-48L, ACX7509

Junos OS Evolved version 23.4R1

PTX10001-36MR, PTX10003, PTX10004, PTX10008 et PTX10016 (avec la carte de ligne JNP10008-SF3 et JNP10K-LC1201 ou JNP10K-LC1202-36MR)

Junos OS Evolved version 23.4R1

TWAMP sur routeurs MX Series, commutateurs EX9200 Series et QFX10000 Series

Le client de contrôle et l’expéditeur de la session (le client TWAMP) résident sur le même routeur Juniper Networks. Toutefois, 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 est capable de fonctionner avec une implémentation de serveur tiers.

Note:

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

TWAMP sur routeurs PTX Series

Le protocole TWAMP-Control est utilisé pour configurer des sessions de mesure de performance entre un client TWAMP et un serveur TWAMP, et le protocole TWAMP-Test est utilisé pour envoyer et recevoir des sondes de mesure de performance. L’attribut d’interface si-x/y/z de destination, qui est destiné à 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. Le tableau 4 fournit des informations sur la prise en charge de TWAMP.

Tableau 4 : prise en charge TWAMP PTX Series
Appareil pris en charge dans
PTX Series sous Junos OS Junos OS version 19.2R1
PTX10001-36MR
  • Junos OS Evolved version 21.1R1 (IPv4)

  • Junos OS Evolved version 22.4R1 (IPv6)

PTX10003
  • Junos OS Evolved version 20.3R1 (IPv4)

  • Junos OS Evolved version 22.4R1 (IPv6)

PTX10004
  • Junos OS Evolved version 21.2R1 (IPv4)

  • Junos OS Evolved version 22.4R1 (IPv6)

PTX10008 (avec le JNP10008-SF3 et la carte de ligne JNP10K-LC1201 ou JNP10K-LC1202-36MR)
  • Junos OS Evolved version 21.1R1 (IPv4)

  • Junos OS Evolved version 22.4R1 (IPv6)

PTX10016 (avec le JNP10008-SF3 et la carte de ligne JNP10K-LC1201 ou JNP10K-LC1202-36MR)

Junos OS Evolved version 22.4R1 (IPv4 et IPv6)

La prise en charge de TWAMP par Junos OS Evolved se limite 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

  • État des sessions de contrôle et de test

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

  • Horodatage défini par le moteur de routage ou le moteur de transfert de paquets pour le trafic IPv4. Pour le trafic IPv6, horodatage défini 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 Release 22.3R1, pour le trafic IPv6, l’instruction offload-type au niveau de la [edit services monitoring twamp client control-connection name test-session name] hiérarchie devait être configurée comme suit none: . À partir de Junos OS Evolved 23.4R1 pour les serveurs, la valeur par défaut de l’instruction offload-type est désormais pfe-timestamp au lieu de inline-timestamp.

  • À partir de Junos OS Evolved version 23.4R1, nous prenons en charge la norme RFC 8762, Simple Two-Way Active Measurement Protocol (STAMP). La norme RFC 8762 standardise et développe le mode de fonctionnement TWAMP Light, défini dans 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).

  • Rapports d’erreurs via les journaux système et les interruptions SNMP uniquement

  • Mode non authentifié uniquement

TWAMP sur les commutateurs QFX5000 Series

Le protocole TWAMP-Control est utilisé pour configurer des sessions de mesure de performance entre un client TWAMP et un serveur TWAMP, et le protocole TWAMP-Test est utilisé pour envoyer et recevoir des sondes de mesure de performance. Pour Junos OS Evolved, TWAMP est configuré au niveau de la [edit services monitoring twamp] hiérarchie.

Tableau 5 : prise en charge de TWAMP série QFX5000
Appareil pris en charge dans
QFX5130-32CD Junos OS Evolved version 22.4R1
QFX5220 Junos OS Evolved version 22.4R1
QFX5700 Junos OS Evolved version 22.4R1

La prise en charge de TWAMP par Junos OS Evolved se limite aux éléments suivants :

  • Les adresses source et cible IPv4 et IPv6 (y compris les adresses locales de liaison) sont prises en charge pour les listes de clients, les connexions de contrôle et les sessions de test.

  • Statistiques et historique des sondes

  • État des sessions de contrôle et de test

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

  • Horodatage défini par le moteur de routage ou par le moteur de transfert de paquets pour le trafic IPv4 et IPv6.

  • Rapports d’erreurs via les journaux système et les interruptions SNMP uniquement

  • Mode non authentifié uniquement

TWAMP sur les pare-feu SRX Series

Les périphériques SRX300, SRX320, SRX340, SRX345, SRX550M, SRX1500, SRX4100 et SRX4200, ainsi que les instances du pare-feu virtuel vSRX, présentent les limitations suivantes pour la prise en charge de TWAMP :

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

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

  • TWAMP Light n’est pas pris en charge.

TWAMP sur routeurs ACX Series

Dans Junos OS, TWAMP est pris en charge pour les routeurs ACX. Les routeurs ACX710 et ACX5448 Series prennent en charge à la fois la réflexion et la génération. Les autres routeurs ACX Series exécutant Junos OS ne prennent en charge que la réflexion, pas la génération. Pour Junos OS, TWAMP est configuré au niveau de la [edit services rpm twamp] hiérarchie.

Dans Junos OS Evolved, TWAMP est pris en charge pour les routeurs ACX, tant pour la réflexion que pour la génération. À partir de Junos OS Evolved 21.2R1, TWAMP (y compris TWAMP Light) est pris en charge pour les routeurs ACX7100 Series. Pour Junos OS Evolved, TWAMP est configuré au niveau de la [edit services monitoring twamp] hiérarchie. La prise en charge de TWAMP par Junos OS Evolved se limite aux éléments suivants :

  • trafic IPv4 uniquement pour les sessions de contrôle et les sessions de test ; Prise en charge du trafic IPv6 (à l’exception des adresses lien-local) à partir de Junos OS Evolved Release 21.4R1. Prise en charge des adresses lien-local IPv6 pour les sessions de test TWAMP Light uniquement à partir de Junos OS Evolved 22.3R1.

  • Statistiques et historique des sondes

  • État des sessions de contrôle et de test

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

  • Horodatage défini par le moteur de routage ou le moteur de transfert de paquets pour le trafic IPv4. Pour le trafic IPv6, horodatage défini 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 Release 22.3R1, pour le trafic IPv6, l’instruction offload-type au niveau de la [edit services monitoring twamp client control-connection name test-session name] hiérarchie devait être configurée comme suit none: . À partir de Junos OS Evolved 22.4R1 pour routeurs ACX, vous pouvez configurer l’option de l’instruction inline-timestamping offload-type pour activer les horodatages définis en ligne par le matériel.

    À partir de Junos OS Evolved 23.4R1, la valeur par défaut de l’instruction offload-type est désormais pfe-timestamp au lieu de inline-timestamp.
  • À partir de Junos OS Evolved version 23.4R1, nous prenons en charge la norme RFC 8762, Simple Two-Way Active Measurement Protocol (STAMP). La norme RFC 8762 standardise et développe le mode de fonctionnement TWAMP Light, défini dans 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).

  • Rapport d’erreurs via les messages du journal système uniquement

  • Mode non authentifié uniquement