Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

Comprendre l’utilisation de sondes pour la surveillance des performances en temps réel sur les routeurs ACX, MX et PTX Series et les commutateurs EX et QFX

La surveillance des performances en temps réel (RPM) vous permet de configurer des sondes actives pour suivre et surveiller le trafic. Les sondes collectent les paquets par destination et par application, y compris les paquets PING Internet Control Message Protocol (ICMP), les paquets UDP/TCP (User Datagram Protocol et Transmission Control Protocol) avec des ports configurés par l’utilisateur, les paquets de type de service (ToS) DSCP (Differentiated Services Code Point) configurés par l’utilisateur et les paquets HTTP (Hypertext Transfer Protocol). RPM prend en charge la base d’informations de gestion (MIB) avec des extensions pour RFC 2925, Définitions d’objets gérés pour les opérations de ping, de traceroute et de recherche à distance. Pour plus d’informations sur les MIB SNMP prises en charge par Juniper, consultez Explorateur de MIB SNMP.

Vue d’ensemble

Lorsque RPM est configuré sur un appareil, l’appareil calcule les performances du réseau en fonction du temps de réponse des paquets, de la gigue et de la perte de paquets. L’équipement recueille des statistiques RPM en envoyant des sondes à une cible de sonde spécifiée, identifiée par une adresse IP. Lorsque la cible reçoit une sonde, celle-ci génère des réponses qui sont reçues par l’appareil. Un test peut contenir plusieurs sondes. Le type de sonde spécifie le contenu des paquets et des protocoles de la sonde. Vous pouvez utiliser l’historique des 50 sondes les plus récentes pour analyser les tendances de votre réseau et prévoir vos besoins futurs.

Utilisez l’explorateur de fonctionnalités : surveillance des performances en temps réel et explorateur de fonctionnalités : RPM et TWAMP pour confirmer la prise en charge de la plate-forme et des versions.

Grâce aux sondes, vous pouvez surveiller :

  • Temps moyen d’aller-retour

  • Gigue du temps d’aller-retour : différence entre le temps d’aller-retour minimum et le temps d’aller-retour maximal

  • Temps d’aller-retour maximal

  • Temps d’aller-retour minimum

  • Écart type du temps d’aller-retour (Junos OS uniquement)

Les mesures unidirectionnelles des sondes d’horodatage ICMP comprennent :

  • Mesures minimales, maximales, d’écart-type et de gigue pour les temps de sortie et d’entrée

  • Nombre de réponses aux sondes reçues

  • Nombre de sondes envoyées

  • Pourcentage de sondes perdues

Vous pouvez définir des seuils pour déclencher des interruptions SNMP lorsque les valeurs sont dépassées. Vous pouvez configurer les seuils RPM suivants :

  • Délai d’entrée/sortie

  • Gigue

  • Temps d’aller-retour

  • Écart type (Junos OS uniquement)

  • Sondes perdues successives

  • Nombre total de sondes perdues (par test)

Vous pouvez également configurer des classificateurs CoS et la hiérarchisation des paquets RPM par rapport aux paquets de données standard reçus sur une interface d’entrée avec l’instruction dscp-code-points de configuration.

Horodatages matériels

Pour tenir compte de la latence ou de la gigue dans la communication des messages de sonde, vous pouvez activer l’horodatage des paquets de sonde (horodatages matériels). Si les horodatages matériels ne sont pas configurés, vous utilisez des horodatages logiciels. Les horodatages générés au niveau logiciel sont moins précis qu’ils ne l’auraient été avec des horodatages matériels.

Utilisez l’explorateur de fonctionnalités : horodatage matériel des messages de sonde RPM, l’explorateur de fonctionnalités : horodatages matériels RPM avec interfaces VLAN routées, et l’explorateur de fonctionnalités : l’horodatage matériel RPM et TWAMP et la mesure RTT pour confirmer la prise en charge de la plate-forme et de la version pour cette fonctionnalité.

Remarque :

L’horodatage matériel RPM est pris en charge sur Junos OS uniquement, avec certaines restrictions :

  • Routeurs ACX Series : Les routeurs des séries ACX710 et ACX5448 sont les seuls routeurs ACX exécutant Junos OS à prendre en charge la configuration de l’instruction hardware-timestamp . Cette prise en charge a commencé avec Junos OS version 22.3R1.

  • Commutateurs EX Series : Les commutateurs EX Series prennent en charge l’horodatage matériel pour les sondes UDP et ICMP. Les commutateurs EX Series ne prennent pas en charge l’horodatage matériel pour les sondes HTTP ou TCP.

    Sur le commutateur EX4300, l’horodatage RPM est effectué dans le logiciel. Les sondes RPM au niveau des appareils demandeurs et répondeurs sont horodatées dans le moteur de transfert de paquets au lieu du processus Junos OS (rmopd) qui s’exécute sur le moteur de routage. Cette méthode d’horodatage est appelée horodatage pseudo-matériel.

  • Commutateurs QFX Series : Les commutateurs QFX Series ne prennent pas en charge les horodatages matériels.

Vous pouvez horodater les sondes RPM suivantes pour améliorer la mesure de la latence ou de la gigue.

  • Ping ICMP

  • Horodatage ping ICMP

  • Ping UDP

  • Horodatage ping UDP

Remarque :

icmp-ping est le type de sonde par défaut sur les équipements exécutant Junos OS.

Les paquets de la sonde sont horodatés avec les heures auxquelles ils sont envoyés et reçus aux points de terminaison source et de destination.

Vous devez configurer le demandeur (le client RPM) avec des horodatages matériels (voir Figure 1) pour obtenir des résultats plus significatifs que vous n’obtiendriez sans les horodatages. Il n’est pas nécessaire de configurer le répondeur (le serveur RPM) pour prendre en charge les horodatages matériels. Si le répondeur prend en charge les horodatages matériels, il horodate les sondes RPM. Si le répondeur ne prend pas en charge les horodatages matériels, RPM peut uniquement signaler les mesures aller-retour qui incluent le temps de traitement sur le répondeur.

Remarque :

Sur le commutateur EX4300, vous devez configurer le commutateur en tant que demandeur (le client RPM) et répondeur (le serveur RPM) pour horodater le paquet RPM.

La figure 1 montre les horodatages :

Figure 1 : Horodatages RPM Timestamps RPM

  • T1 est l’heure à laquelle le paquet quitte le port du demandeur.

  • T2 est l’heure à laquelle l’intervenant reçoit le paquet.

  • T3 est l’heure à laquelle le répondant envoie la réponse.

  • Le T4 est le moment où le demandeur reçoit la réponse.

Le temps d’aller-retour est de T4 – T1 – (T3 – T2). Si le répondeur ne prend pas en charge les horodatages matériels, le temps d’aller-retour est (T4 – T1) et inclut donc le temps de traitement du répondeur.

Vous pouvez utiliser des sondes RPM pour trouver les mesures de temps suivantes :

  • Temps d’aller-retour minimum

  • Temps d’aller-retour maximal

  • Temps moyen d’aller-retour

  • Écart-type du temps d’aller-retour

  • Gigue du temps d’aller-retour : différence entre le temps d’aller-retour minimum et le temps d’aller-retour maximal

La fonction RPM offre une option de configuration permettant de définir des horodatages matériels unidirectionnels. Utilisez des horodatages unidirectionnels lorsque vous souhaitez obtenir des informations sur le temps unidirectionnel, plutôt que sur les temps d’aller-retour, pour que les paquets traversent le réseau entre le demandeur et le répondeur. Comme le montre la figure 1, les horodatages unidirectionnels représentent l’heure T2 – T1 et l’heure de T4 – T3. Utilisez des horodatages unidirectionnels lorsque vous souhaitez recueillir des informations sur le retard dans chaque direction et trouver les valeurs de gigue de sortie et d’entrée.

Remarque :

Pour une mesure unidirectionnelle correcte, les horloges du demandeur et du répondeur doivent être synchronisées. Si les horloges ne sont pas synchronisées, les mesures et les calculs de la gigue unidirectionnelle peuvent inclure des variations importantes, dans certains cas des ordres de grandeur supérieurs aux temps d’aller-retour.

Lorsque vous activez les horodatages unidirectionnels dans une sonde, les mesures unidirectionnelles suivantes sont signalées :

  • Mesures minimales, maximales, d’écart-type et de gigue pour les temps de sortie et d’entrée

  • Nombre de sondes envoyées

  • Nombre de réponses aux sondes reçues

  • Pourcentage de sondes perdues

Assistance pour Junos OS

Configuration et résultats des sondes

Dans Junos OS, la configuration et les résultats des sondes sont pris en charge à la fois par l’interface de ligne de commande (CLI) et SNMP. Vous définissez les options de sonde dans l’instruction test test-name au niveau de la hiérarchie [edit services rpm probe owner]. Utilisez la show services rpm probe-results commande pour afficher les résultats des sondes RPM les plus récentes.

Remarque :

Limitations des commutateurs EX Series et QFX Series :

  • Les commutateurs ne prennent pas en charge les classificateurs de classe de service (CoS) configurés par l’utilisateur ni la hiérarchisation des paquets RPM par rapport aux paquets de données standard reçus sur une interface d’entrée.

  • Horodatages :

    • Si le répondeur ne prend pas en charge les horodatages matériels, RPM peut uniquement signaler les mesures aller-retour et ne peut pas calculer la gigue aller-retour. (Les commutateurs QFX Series ne prennent pas en charge les horodatages matériels.)

    • Les commutateurs EX Series ne prennent pas en charge les horodatages matériels ou pseudo-matériels pour les sondes HTTP et TCP.

    • Les horodatages s’appliquent uniquement au trafic IPv4.

    • Les mises à niveau Logiciels en service (ISSU) et les mises à niveau Logiciels ininterrompues (NSSU) ne prennent pas en charge les horodatages pseudo-matériels.

Pour spécifier le contenu des paquets et des protocoles de la sonde, incluez l’instruction probe-type au niveau de la [edit services rpm probe owner test test-name] hiérarchie. Les types de sondes suivants sont pris en charge :

  • http-get: envoie une requête get HTTP (Hypertext Transfer Protocol) à une URL cible.

  • http-metadata-get: envoie une requête HTTP get pour les métadonnées à une URL cible.

  • icmp-ping: envoie des demandes d’écho ICMP à une adresse cible.

  • icmp-ping-timestamp: envoie des demandes d’horodatage ICMP à une adresse cible.

  • tcp-ping: envoie des paquets TCP à une cible.

  • udp-ping: envoie des paquets UDP à une cible.

  • udp-ping-timestamp: envoie des demandes d’horodatage UDP à une adresse cible.

Prise en charge des tunnels IPsec et GRE

Vous pouvez appliquer RPM aux tunnels IPsec et aux tunnels GRE pour les clients et serveurs RPM basés sur PIC et basés sur le moteur de routage si vous utilisez des MS-MPC ou des MS-MIC. Le RPM basé sur le moteur de transfert de paquets n’est pas pris en charge pour les tunnels IPsec. La prise en charge de RPM sur les tunnels IPSec permet de surveiller les accords de niveau de service (SLA) pour le trafic transporté dans les tunnels IPSec.

Remarque :

RPM n’est pas pris en charge sur les systèmes logiques.

Utilisez l’explorateur de fonctionnalités : Prise en charge RPM pour les tunnels IPsec et GRE pour confirmer la prise en charge de la plate-forme et de la version pour cette fonctionnalité.

Routes statiques suivies par RPM

Dans Junos OS, vous pouvez également configurer les services RPM pour déterminer automatiquement s’il existe un chemin entre un équipement hôte et ses voisins BGP configurés. Vous pouvez afficher les résultats de la découverte à l’aide d’un client SNMP. Les résultats sont stockés dans pingResultsTable, jnxPingProbeHistoryTablejnxPingResultsTable, et pingProbeHistoryTable.

Utiliser l’explorateur de fonctionnalités : activation ou désactivation des routes statiques sur la base des résultats des tests RPM, Feature Explorer : suivi des routes RPM statiques sur plusieurs sauts suivants, et Feature Explorer : une extension des routes statiques suivies RPM pour confirmer la prise en charge de la plate-forme et de la version pour cette fonctionnalité.

Pour les équipements qui prennent en charge cette fonctionnalité, vous pouvez utiliser des sondes RPM pour détecter l’état des liaisons et modifier l’état du routage préféré en fonction des résultats de la sonde. Les routes suivies par RPM peuvent être IPv4 ou IPv6, et prennent en charge un seul saut suivant IPv4 ou IPv6. Vous configurez cette fonctionnalité avec l’instruction rpm-tracking au niveau de la [edit routing-options] hiérarchie ou [edit routing-instances routing-options] . Par exemple, des sondes RPM peuvent être envoyées à une adresse IP pour déterminer si la liaison est active et, si c’est le cas, le logiciel installe une route statique dans la table de routage. Les routes statiques suivies par RPM sont installées avec la préférence 1 et sont donc préférées à toutes les routes statiques existantes pour le même préfixe. Pour les appareils qui prennent en charge plusieurs sauts suivants, vous pouvez suivre jusqu’à 16 sauts suivants pour chaque route statique IPv4 ou IPv6 suivie par RPM, et vous pouvez configurer les préférences de route et les valeurs de balise pour chaque préfixe de destination IPv4 ou IPv6.

Prise en charge du RPM et de l’horodatage associé sur les MPC, les MS-MIC/MPC et le moteur de routage

Le Tableau 1 fournit des informations sur la prise en charge de RPM et de l’horodatage associé sur MPC, MS-MIC/MPC et le moteur de routage :

Tableau 1 : prise en charge des paquets RPM et de l’horodatage associé pour les sondes ICMP

Fonctionnalité

Rôle

IP Version

Soutien (O/N)

Horodatage sur le moteur de routage

Horodatage sur MPC (hardware-timestamp)

Horodatage sur MPC (interface si)

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

Régime

Maître d’ouvrage

IPv4

Y

Y (μsec)

2000 sondes maximum

Y (μsec)

2000 sondes maximum

N

O (ms)

1 million de sondes maximum

IPv6

Y

Y (μsec)

2000 sondes maximum

N

N

O (ms)

1 million de sondes maximum

Serveur

IPv4

Y

Y (μsec)

2000 sondes maximum

Y (μsec)

2000 sondes maximum

N

O (ms)

1 million de sondes maximum

IPv6

Y

Y (μsec)

2000 sondes maximum

N

N

O (ms)

1 million de sondes maximum

Assistance pour Junos OS Evolved

Configuration et résultats des sondes

À partir de la version 20.1R1 de Junos OS Evolved, vous pouvez configurer des sondes RPM pour les équipements qui prennent en charge cette fonctionnalité. Pour Junos OS Evolved, RPM est configuré au niveau de la [edit services monitoring rpm] hiérarchie. Le champ d’assistance est limité à :

  • Génération et réception de sondes (client) et réflexion (serveur) pour les types de sondes RPM suivants :

    • http-get (ajouté dans Junos OS Evolved 23.4R1)

      Vous devez définir l’instruction offload-type sur none pour configurer ce type de sonde.

    • http-metadata-get (ajouté dans Junos OS Evolved 23.4R1)

      Vous devez définir l’instruction offload-type sur none pour configurer ce type de sonde.

    • icmp-ping

    • horodatage icmp

    • tcp-ping (ajouté dans Junos OS Evolved 23.4R1)

      Vous devez définir l’instruction offload-type sur none pour configurer ce type de sonde.

    • udp-ping

    • horodatage UDP

  • Gestion de l’historique des sondes

  • Rapports via syslog uniquement

À partir de Junos OS Evolved version 21.2R1, la création de rapports via des objets MIB SNMP est prise en charge pour RPM.

Utilisez l’explorateur de fonctionnalités : Services RPM en ligne pour confirmer la prise en charge de la plate-forme et de la version de Junos OS Evolved.

Routes statiques suivies par RPM

À partir de Junos OS Evolved version 24.4R1 pour les équipements prenant en charge cette fonctionnalité, nous avons étendu la prise en charge du suivi de routage statique à Junos OS Evolved et inclus la prise en charge des tests TWAMP (Two-Way Active Measurement Protocol). Vous utilisez des sondes RPM ou TWAMP pour détecter l’état de la liaison et modifier l’état du routage préféré 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 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. Pour Junos OS, vous devez configurer l’instruction rpm-tracking au même niveau hiérarchique et utiliser la commande show route rpm-tracking pour afficher des informations sur ces routes.

Documentation connexe

Tableau de l’historique des modifications

La prise en charge des fonctionnalités est déterminée par la plateforme et la version que vous utilisez. Utilisez l’explorateur de fonctionnalités pour déterminer si une fonctionnalité est prise en charge sur votre plateforme.

Libération
Descriptif
25.4R1
Vous pouvez spécifier un nom de domaine complet (FQDN) comme cible au lieu de l’adresse IPv4 ou IPv6 de la destination. L’équipement résout le nom de domaine complet via le système de noms de domaine (DNS) au début de chaque test, puis envoie des sondes à l’adresse résolue à chaque intervalle. La télémétrie affiche d’abord le nom de domaine complet jusqu’à la résolution, puis affiche l’adresse de destination pour vous aider à suivre les modifications. En cas d’échec de la résolution DNS, les résultats de la sonde conservent le nom de domaine complet comme adresse cible. Si le serveur DNS tarde à répondre, ne répond pas ou n’est pas joignable, le test RPM peut être lent à démarrer ou ne pas démarrer.
24.4R1-EVO
Nous avons étendu la prise en charge du suivi de routage statique à Junos OS Evolved et inclus la prise en charge des tests TWAMP (Two-Way Active Measurement Protocol). Vous utilisez des sondes RPM ou TWAMP pour détecter l’état de la liaison et modifier l’état du routage préféré 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 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. Pour Junos OS, vous devez configurer l’instruction rpm-tracking au même niveau hiérarchique.
23.4R1-EVO
Vous pouvez configurer tcp-ping, http-getet http-metadata-get sondes pour RPM.
23.1R1-EVO
Vous pouvez configurer les adresses source et cible IPv6 pour les sondes RPM. Nous avons également ajouté la prise en charge des adresses IPv6 aux tables de contrôle et de résultats des MIB SNMP RFC2925a. Pour les sondes RPM IPv6, vous pouvez activer les horodatages uniquement dans le moteur de routage.
21.2R1-EVO
Les rapports via des objets MIB SNMP sont pris en charge pour RPM.
20.4R1
Pour les routes statiques suivies par RPM, vous pouvez configurer des préférences de route et des valeurs de balise pour chaque préfixe de destination IPv4 ou IPv6.
20.1R1-EVO
Vous pouvez configurer des sondes RPM. Pour Junos OS Evolved, RPM est configuré au niveau de la hiérarchie [edit services monitoring rpm].
19.3R2
RPM n’est pas pris en charge lorsque vous activez les services nouvelle génération sur un routeur MX Series.
19.1R1
Vous pouvez suivre jusqu’à 16 sauts suivants pour chaque route statique IPv4 ou IPv6 suivie par RPM.
19.1R1
Vous pouvez activer l’horodatage sur les messages de sonde RPM sur le moteur de transfert de paquets.
18.4R1
Vous pouvez utiliser des sondes RPM pour détecter l’état des liaisons et modifier l’état du routage préféré en fonction des résultats de la sonde. Les routes suivies par RPM peuvent être IPv4 ou IPv6, et prennent en charge un seul saut suivant IPv4 ou IPv6. Par exemple, des sondes RPM peuvent être envoyées à une adresse IP pour déterminer si la liaison est active et, si c’est le cas, le logiciel installe une route statique dans la table de routage. Les routes statiques suivies par RPM sont installées avec la préférence 1 et sont donc préférées à toutes les routes statiques existantes pour le même préfixe.
17.3R1
Vous pouvez appliquer RPM aux tunnels IPsec et aux tunnels GRE pour les clients et serveurs RPM basés sur PIC et basés sur le moteur de routage si vous utilisez des MS-MPC ou des MS-MIC.