Configuration des sondes RPM sur les routeurs M, MX et T Series et les commutateurs EX Series

Le propriétaire de la sonde et le nom de test d’une sonde RPM représentent ensemble une seule instance de configuration RPM. Lorsque vous spécifiez le nom du test, vous pouvez également configurer les paramètres de test.

Pour configurer le propriétaire de la sonde, le nom du test et les paramètres de test, incluez l’instruction probe au niveau de la [edit services rpm] hiérarchie :

Gardez à l’esprit les points suivants lorsque vous configurez des clients RPM et des serveurs RPM :

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

• Vous ne pouvez pas configurer un client RPM basé sur PIC et un serveur RPM basé sur le moteur de transfert de paquets ou le moteur de routage pour recevoir les sondes RPM.

• Vous ne pouvez pas configurer un client RPM basé sur le moteur de transfert de paquets et un serveur RPM qui reçoit les sondes RPM pour qu’ils soient sur le PIC ou le moteur de routage.

• Le client RPM et le serveur RPM doivent être situés sur le même type de module. Par exemple, si le client RPM est basé sur PIC, le serveur RPM doit également être basé sur PIC, et si le serveur RPM est basé sur le moteur de transfert de paquets, le client RPM doit également être basé sur le moteur de transfert de paquets.

• À partir de Junos OS version 17.3R1, les RPM basés sur PIC et basés sur le moteur de routage sont pris en charge pour les tunnels IPsec et les tunnels GRE si vous utilisez des MS-MPC ou MS-MICs. 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.

• À partir de Junos OS version 17.3R1, vous pouvez configurer la génération de sondes IPv4 icmp-ping et icmp-ping-timestamp RPM sur un MS-MPC ou MS-MIC, ce qui augmente le nombre de sondes générées jusqu’à 1 million par seconde sur chaque NPU de service par rapport au nombre de sondes générées sur le moteur de transfert de paquets. À partir de Junos OS version 18.1R1, vous pouvez configurer la génération de icmp6-ping sondes RPM sur un MS-MPC ou MS-MIC. Pour configurer la génération de sondes RPM sur un MS-MPC ou un MS-MIC :

  • Incluez le destination-interface interface-name.logical-unit-number au niveau de la hiérarchie et incluez l’instruction delegate-probes au niveau de la [edit services rpm probe owner test test-name] [edit services rpm probe owner] hiérarchie. Le interface-name.logical-unit-number spécifie une interface logique sur un emplacement MS-MPC ou MS-MIC, un PIC et un port sur lequel une adresse IP valide est définie (par exemple, ms-1/2/1.1). Il ne peut pas s’agir d’une interface multiservices agrégée (ams-).

  • Incluez les instructions et les rpm client-delegate-probes family (inet | inet6) address address au niveau de la [edit interfaces interface-name unit logical-unit-number] hiérarchie. Le interface-name et le doit correspondre à ce interface-name.logical-unit-number que vous avez utilisé pour le logical-unit-number destination-interfacefichier .

  Pour les sondes RPM configurées sur un MS-MPC ou un MS-MIC, vous ne pouvez pas configurer l’instruction routing-instance au niveau de la [edit services rpm probe owner test test-name] hiérarchie et vous ne pouvez pas configurer les sondes IPv4 et IPv6 dans le même test.

  À partir de Junos OS version 18.1R1, vous pouvez utiliser des filtres supplémentaires pour limiter la sortie des commandes show services rpm probe-results et show services rpm history-results pour les sondes RPM générées sur un MS-MPC ou MS-MIC.

• À partir de Junos OS version 17.4R1, vous pouvez optimiser la configuration de l’interface de ligne de commande pour les tests RPM pour IPv4. À partir de Junos OS version 18.2R1, vous pouvez également optimiser la configuration de l’interface de ligne de commande pour les tests RPM pour IPv6. Cette optimisation permet l’utilisation d’instructions de configuration RPM minimales pour générer plusieurs tests (jusqu’à 100 000 tests) avec des noms de test RPM prédéfinis et réservés. Cette optimisation peut être configurée pour les tests avec des sondes générées par le moteur de transfert de paquets ou par un MS-MPC ou MS-MIC. Les tests sont générés pour plusieurs combinaisons d’adresses source et cible, qui sont incrémentées en fonction de votre configuration.

  Le nombre maximal de sondes RPM simultanées prises en charge pour les différentes versions de Junos est le suivant :

  • Version de Junos OS antérieure à 17.3R1—500

  • Junos OS version 17.3R1 et ultérieure : 2000 pour les types de sondes ICMP et ICMP-Timestamp. Pour les sondes d’autres types (UDP et TCP), la limite est de 500.

  • Junos OS version 17.3R1 et ultérieures (avec l’implémentation de delegate-probes) : 1 million par service-NPU.

    Note:

    Un MS-MIC contient un NPU de service et un MS-MPC contient quatre NPU de service.

    Grâce à la mise en œuvre de sondes déléguées, les sondes RPM sont conformes aux normes RFC792 et RFC4443. Par conséquent, ils peuvent être utilisés pour surveiller n’importe quel périphérique IP conforme à l’une ou l’autre RFC et sont capables de répondre aux paquets icmp-timestamp et/ou icmp6-ping.

  Les tests sont d’abord générés pour toutes les adresses source avec l’adresse cible initiale, puis les tests sont générés pour toutes les adresses source avec la prochaine adresse cible disponible, et ainsi de suite. Vous pouvez également configurer un groupe qui contient des valeurs globales pour un propriétaire de sonde particulier et appliquer le groupe au propriétaire de la sonde.

  Pour générer plusieurs tests RPM, configurez les éléments suivants :

  Les options sont les suivantes :

  ipv4-address-base	L’adresse source ou cible IPv4 qui est incrémentée pour générer les adresses utilisées dans les tests RPM.
  ipv6-address-base	L’adresse source ou cible IPv6 qui est incrémentée pour générer les adresses utilisées dans les tests RPM.
  ipv4-step	Quantité d’incrémentation de l’adresse source ou cible IPv4 pour chaque test RPM généré.
  ipv6-step	Quantité d’incrémentation de l’adresse source ou cible IPv6 pour chaque test RPM généré.
  ipv4-count	Nombre maximal d’adresses source ou cible IPv4 à utiliser pour les tests RPM générés.
  ipv6-count	Nombre maximal d’adresses source ou cible IPv6 à utiliser pour les tests RPM générés.
  interface-name.logical-unit-number	L’interface de services qui génère les sondes RPM et le numéro d’unité logique utilisé pour le premier test généré.
  subunit-cnt	Nombre maximal d’unités logiques utilisées par l’interface de services dans les tests générés. Le premier test généré utilise l’unité logique spécifiée dans l’option, et chaque test successif incrémente le numéro d’unité interface-name.logical-unit-number logique d’une unité. Une fois que le nombre maximal d’unités logiques a été utilisé, le test généré suivant revient à l’unité logique qui a été utilisée dans le premier test.
  tests-count	Le nombre maximal de tests RPM à générer. Ce nombre doit être inférieur ou égal au nombre d’adresses source générées multiplié par le nombre d’adresses cibles générées.

  Pour configurer un groupe avec des valeurs globales pour un propriétaire de sonde particulier :

• Pour spécifier un propriétaire de sonde, incluez l’instruction probe au niveau de la [edit services rpm] hiérarchie. L’identificateur du propriétaire de la sonde peut comporter jusqu’à 32 caractères.

• Pour spécifier un nom de test, incluez l’instruction test au niveau de la [edit services rpm probe owner] hiérarchie. L’identificateur de nom de test peut comporter jusqu’à 32 caractères. Un test représente la plage de sondes sur laquelle l’écart-type, la moyenne et la gigue sont calculés.

• Pour spécifier le contenu de la partie données des sondes ICMP (Internet Control Message Protocol), incluez l’instruction data-fill au niveau de la [edit services rpm probe owner] hiérarchie. Il peut s’agir d’une valeur hexadécimale. L’instruction data-fill n’est pas valide avec les http-get types de sonde ou http-metadata-get .

• Pour spécifier la taille de la partie données des sondes ICMP, incluez l’instruction data-size au niveau de la [edit services rpm probe owner] hiérarchie. La taille peut être de A à Z 65400 et la taille par défaut est 0.0 L’instruction data-size n’est pas valide avec les http-get types de sonde ouhttp-metadata-get.

  Note:

  Si vous configurez la fonctionnalité d’horodatage matériel (voir Configuration de l’horodatage RPM sur les routeurs MX, M, T et PTX Series et les commutateurs EX Series) :

  • Il s’agit d’un élément obsolète, la valeur par défaut est de 32 octets et il s’agit d’un élément data-size obsolète, 32 est la valeur minimale pour une configuration explicite. Le type de sonde d’horodatage UDP est une exception ; Il nécessite une taille de données minimale de 44 octets.

  • La data-size valeur doit être inférieure d’au moins 100 octets à la MTU par défaut de l’interface de l’interface client RPM.

• Sur les routeurs M Series et T Series, vous configurez l’instruction pour activer l’horodatage destination-interface matériel des paquets de sonde RPM. Vous spécifiez une interface sp- pour que l’AS ou le PIC multiservices ajoute les horodatages matériels ; Pour plus d’informations, reportez-vous à la section Configuration de l’horodatage RPM sur les routeurs et commutateurs EX Series MX, M, T et PTX Series. Vous pouvez également inclure l’instruction pour activer les one-way-hardware-timestamp mesures de retard unidirectionnel et de gigue.

• Pour spécifier le port UDP (User Datagram Protocol) ou le port TCP (Transmission Control Protocol) vers lequel la sonde est envoyée, incluez l’instruction destination-port au niveau de la [edit services rpm probe owner test test-name] hiérarchie. L’instruction destination-port n’est utilisée que pour les types de sondes UDP et TCP. La valeur peut être 7 ou de à travers 49160 65535.

  Lorsque vous configurez l’horodatage matériel ou probe-type udp-ping-timestamp l’un avec celui-ci, la valeur de l’horodatage probe-type udp-ping destination-port ne peut être que 7. Dans ce cas, une vérification de contrainte vous empêche de configurer une autre valeur pour le port de destination. Cette contrainte ne s’applique pas lorsque vous utilisez l’horodatage matériel unidirectionnel.

• Pour spécifier la valeur du champ Services différenciés (DiffServ) dans l’en-tête IP, incluez l’instruction dscp-code-point au niveau de la [edit services rpm probe owner test test-name] hiérarchie. La valeur des bits du point de code DiffServ (DSCP) peut être définie sur un modèle valide de 6 bits ; Par exemple, 001111. Il peut également être défini à l’aide d’un alias configuré au niveau de la [edit class-of-service code-point-aliases dscp] hiérarchie. La valeur par défaut est 000000.

• Pour spécifier le nombre d’entrées d’historique stockées, incluez l’instruction history-size au niveau de la [edit services rpm probe owner test test-name] hiérarchie. Spécifiez une valeur comprise entre 0 et . 512 La valeur par défaut est 50.

• Pour spécifier un nombre d’échantillons pour effectuer des calculs statistiques, incluez l’instruction moving-average-size au niveau de la [edit services rpm probe owner test test-name] hiérarchie. Spécifiez une valeur comprise entre 0 .255

• Pour spécifier le nombre de sondes dans un test, incluez l’instruction probe-count au niveau de la [edit services rpm probe owner test test-name] hiérarchie. Spécifiez une valeur comprise entre 1 .15

• Pour spécifier le temps d’attente entre l’envoi de paquets, incluez l’instruction probe-interval au niveau de la [edit services rpm probe owner test test-name] hiérarchie. Spécifiez une valeur à partir de 1 toutes les 255 secondes.

• Pour spécifier le contenu du paquet et du protocole 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 requêtes 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.

  Les types de sondes suivants prennent en charge l’horodatage matériel des paquets de sonde : icmp-ping, , , udp-pingicmp-ping-timestampudp-ping-timestamp. À partir de Junos OS version 17.3R3, les sondes déléguées sont réparties uniformément sur l’intervalle de 3 secondes afin d’éviter les pointes de paquets dans le réseau dues à la surveillance des performances en temps réel (RPM). Les syslogs RPM sont traités avec l’augmentation du temps de montée en puissance des tests des délégués RPM à 60 secondes. Lorsque les syslogs RPM sont traités, les chances que plusieurs tests démarrent et se terminent en même temps sont plus faibles, ce qui constitue une restriction potentielle dans event-processing.

  Note:

  Certains types de sondes nécessitent la configuration de paramètres supplémentaires. Par exemple, lorsque vous spécifiez l’option ouudp-ping, vous devez configurer le port de destination à l’aide de l’instruction.tcp-ping destination-port L’option udp-ping-timestamp nécessite une taille de données minimale de 12 ; toute taille de données inférieure entraîne une erreur de validation. La taille minimale des données pour les paquets de sonde TCP est de 1.

  Lorsque vous configurez l’un ou l’autre probe-type udp-ping ou probe-type udp-ping-timestamp avec la commande, la valeur de la one-way-hardware-timestamp destination-port ne peut être que 7. Dans ce cas, une vérification de contrainte vous empêche de configurer une autre valeur pour le port de destination.

• Pour spécifier l’instance de routage utilisée par les sondes ICMP, incluez l’instruction routing-instance au niveau de la [edit services rpm probe owner test test-name] hiérarchie. L’instance de routage par défaut est la table de routage inet.0Internet .

• Pour spécifier l’adresse IP source utilisée pour les sondes ICMP, incluez l’instruction source-address au niveau de la [edit services rpm probe owner test test-name] hiérarchie. Si l’adresse IP source n’est pas l’une des adresses attribuées au routeur, le paquet utilise l’adresse de l’interface sortante comme source.

• À partir de Junos OS version 16.1R1, pour spécifier l’adresse IPv6 source à utiliser pour les sondes RPM envoyées du client RPM (le périphérique à l’origine des paquets RPM) au serveur RPM (le périphérique qui reçoit les sondes RPM), incluez le inet6-options source-address ipv6-address statement au niveau de la [edit services rpm probe owner test test-name] hiérarchie. Si l’adresse IPv6 source n’est pas l’une des adresses attribuées par le routeur ou le commutateur, le paquet utilise l’adresse de l’interface sortante comme source.

• Pour spécifier l’adresse de destination utilisée pour les sondes, incluez l’instruction target au niveau de la [edit services rpm probe owner test test-name] hiérarchie.

  • Pour les types de sonde HTTP, spécifiez une URL entièrement formée qui inclut http:// l’adresse URL.

  • Pour tous les autres types de sondes, spécifiez une adresse IP version 4 (IPv4) ou IP version 6 (IPv6) (la prise en charge d’IPv6 commence dans Junos OS version 16.1R1) pour l’hôte cible.

• Pour spécifier le temps d’attente entre les tests, incluez l’instruction test-interval au niveau de la [edit services rpm probe owner test test-name] hiérarchie. Spécifiez une valeur à partir de 0 toutes les 86400 secondes. Une valeur de 0 seconde entraîne l’arrêt du test RPM après une itération. La valeur par défaut est 1.

• Pour spécifier les seuils utilisés pour les sondes, incluez l’instruction thresholds au niveau de la [edit services rpm probe owner test test-name] hiérarchie. Un message de journal système est généré lorsque le seuil configuré est dépassé. De même, une interruption SNMP (si elle est configurée) est générée lorsqu’un seuil est dépassé. Les options suivantes sont prises en charge :

  • egress-time: mesure le temps maximal source-destination par sonde.

  • ingress-time: mesure le temps maximal entre la destination et la source par sonde.

  • jitter-egress: mesure la gigue maximale de la source à la destination par test.

  • jitter-ingress: mesure la gigue maximale entre la destination et la source par test.

  • jitter-rtt: mesure la gigue maximale par test, de 0 à 60000000 microsecondes.

  • rtt: mesure le temps d’aller-retour maximal par sonde, en microsecondes.

  • std-dev-egress: mesure l’écart-type maximal entre la source et la destination par test.

  • std-dev-ingress: mesure l’écart-type maximal entre la destination et la source par test.

  • std-dev-rtt: mesure l’écart-type maximal par test, en microsecondes.

  • successive-loss: mesure le nombre de pertes successives de la sonde, indiquant la défaillance de la sonde.

  • total-loss: mesure le nombre total de pertes de la sonde indiquant l’échec du test, de 0 à 15. La valeur par défaut de ce seuil est 1.

• Des interruptions sont envoyées si le seuil configuré est atteint ou dépassé. Pour définir le bit de recouvrement afin de générer des interruptions, incluez l’instruction traps au niveau de la [edit services rpm probe owner test test-name] hiérarchie. Les options suivantes sont prises en charge :

  • egress-jitter-exceeded: génère des interruptions lorsque le seuil de gigue dans le temps de sortie est atteint ou dépassé.

  • egress-std-dev-exceeded: génère des interruptions lorsque le seuil d’écart-type temporel de sortie est atteint ou dépassé.

  • egress-time-exceeded: génère des interruptions lorsque le seuil de temps de sortie maximal est atteint ou dépassé.

  • ingress-jitter-exceeded: génère des interruptions lorsque le seuil de temps d’entrée de gigue est atteint ou dépassé.

  • ingress-std-dev-exceeded: génère des interruptions lorsque le seuil d’écart-type temporel d’entrée est atteint ou dépassé.

  • ingress-time-exceeded: génère des interruptions lorsque le seuil de temps d’entrée maximal est atteint ou dépassé.

  • jitter-exceeded: génère des interruptions lorsque le seuil de gigue dans le temps d’aller-retour est atteint ou dépassé.

  • probe-failure: génère des interruptions pour les seuils de perte de sonde successifs franchis.

  • rtt-exceeded: génère des interruptions lorsque le seuil de temps d’aller-retour maximal est atteint ou dépassé.

  • std-dev-exceeded: génère des interruptions lorsque le seuil d’écart-type du temps d’aller-retour est atteint ou dépassé.

  • test-completion: génère des interruptions lorsqu’un test est terminé.

  • test-failure: génère des interruptions lorsque le seuil de perte totale de la sonde est atteint ou dépassé.