Configuration des sondes RPM sur les routeurs MX 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 du 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 les clients RPM et les serveurs RPM :

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

• RPM basé sur PIC et basé sur le moteur de routage est pris en charge pour les tunnels IPsec et GRE si vous utilisez des MS-MPC ou 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.

• Vous pouvez configurer la génération de sondes IPv4 icmp-ping et icmp-ping-timestamp RPM sur une MS-MPC ou une 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. Vous pouvez configurer la génération de icmp6-ping sondes RPM sur un MS-MPC ou un MS-MIC. Pour configurer la génération de sondes RPM sur une MS-MPC ou une MS-MIC :

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

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

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

  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 un MS-MIC.

• Vous pouvez optimiser la configuration de la CLI pour les tests RPM pour IPv4. À partir de Junos OS version 18.2R1, vous pouvez également optimiser la configuration CLI pour les tests RPM pour IPv6. Cette optimisation permet d’utiliser des instructions de configuration à régime minimal 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 un MS-MIC. Des 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 :

  • Sans configurer l’instruction : 2000 pour les delegate-probes sondes ICMP et ICMP-timestamp. Pour les autres sondes (UDP et TCP), la limite est de 500.

  • Avec la configuration de l’instruction delegate-probes (1 million par Service-NPU).

    Remarque :

    Une MS-MIC contient une NPU de service et une MS-MPC contient quatre NPU de service.

    Avec la configuration de l’instruction delegate-pondes , les sondes RPM sont conformes aux normes RFC792 et RFC4443. Par conséquent, ils peuvent être utilisés pour surveiller tout 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.

  Des tests sont d’abord générés pour toutes les adresses sources avec l’adresse cible initiale, puis des tests sont générés pour toutes les adresses sources 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	Adresse source ou cible IPv4 incrémentée pour générer les adresses utilisées dans les tests RPM.
  ipv6-address-base	Adresse source ou cible IPv6 incrémentée pour générer les adresses utilisées dans les tests RPM.
  ipv4-step	Montant à incrémenter de l’adresse source ou cible IPv4 pour chaque test RPM généré.
  ipv6-step	Montant à incrémenter de l’adresse source ou cible IPv6 pour chaque test RPM généré.
  ipv4-count	Nombre maximal d’adresses IPv4 source ou cible à utiliser pour les tests RPM générés.
  ipv6-count	Nombre maximal d’adresses IPv6 source ou cible à 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 interface-name.logical-unit-number , et chaque test successif incrémente le numéro d’unité 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 utilisée lors du premier test.
  tests-count	Nombre maximal de tests RPM à générer. Ce nombre doit être inférieur ou égal au nombre d’adresses sources 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 du nom du 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 types de http-get 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 0 through 65400 et la taille par défaut est 0. L’instruction data-size n’est pas valide avec les types de http-get sonde ou http-metadata-get .

  Remarque :

  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) :

  • La data-size valeur par défaut est de 32 octets et 32 est la valeur minimale pour la 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 valeur configurée sur l’instruction data-size 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 MX 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 le PIC AS ou Multiservices ajoute les horodatages matériels ; Pour plus d’informations, consultez Configuration de l’horodatage RPM sur les routeurs MX, M, T et PTX Series et les commutateurs EX Series. Vous pouvez également inclure l’instruction pour activer les one-way-hardware-timestamp mesures unidirectionnelles de retard et de gigue.

• Pour spécifier le port UDP (User Datagram Protocol) ou 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 est utilisée uniquement pour les types de sondes UDP et TCP. La valeur peut être 7 ou de 49160 par .65535

  Lorsque vous configurez l’un ou l’autre probe-type udp-ping ou probe-type udp-ping-timestamp avec l’horodatage matériel, la valeur de le destination-port ne peut être que 7. Une vérification de contrainte vous empêche de configurer une autre valeur pour le port de destination dans ce cas. Cette contrainte ne s’applique pas lorsque vous utilisez un 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 DSCP (DiffServ code point) 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 à 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 dans 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 dans 1 .15

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

• 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.

  Les types de sondes suivants prennent en charge l’horodatage matériel des paquets de sonde : icmp-ping, , icmp-ping-timestampudp-ping, udp-ping-timestamp. Les sondes de délégation sont réparties uniformément sur un intervalle de 3 secondes afin d’éviter les explosions 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 commencent et se terminent en même temps sont plus faibles, d’où une restriction potentielle dans event-processing.

  Remarque :

  Certains types de sondes nécessitent des paramètres supplémentaires pour être configurés. Par exemple, lorsque vous spécifiez l’option tcp-ping ou udp-ping , vous devez configurer le port de destination à l’aide de l’instruction 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 paquets de sonde TCP est de 1.

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

• 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.

• 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 au routeur ou au 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 sondes HTTP, spécifiez une URL complète 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) 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 comprise entre 0 plusieurs 86400 secondes. Une valeur de 0 seconde provoque 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 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 entre la source et la 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 de la destination à 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 d’interruption 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 temps de sortie de la gigue est atteint ou dépassé.

  • egress-std-dev-exceeded: génère des interruptions lorsque le seuil d’écart type du temps 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 la gigue est atteint ou dépassé.

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

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

  • jitter-exceeded: génère des interruptions lorsque le seuil de temps d’aller-retour de la gigue 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 maximal de temps d’aller-retour 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é.