Configuration de l’horodatage RPM sur les routeurs MX, M, T et PTX Series et les commutateurs EX Series
Pour tenir compte de la latence dans la communication des messages de sonde, vous pouvez activer l’horodatage des paquets de sonde. Vous pouvez horodater les types de palpeurs RPM suivants : icmp-ping, icmp-ping-timestamp, udp-ping, et udp-ping-timestamp.
Sur les routeurs M Series et T Series équipés d’un MS-PIC, sur les routeurs MX Series équipés d’une carte de ligne MS-DPC, MS-MIC ou MS-MPC, sur les routeurs MX10000 Series, sur les routeurs PTX10008 et PTX10016 et sur les commutateurs EX Series, vous pouvez activer l’horodatage matériel des messages de sonde RPM. L’horodatage est appliqué à la fois sur l’appareil client RPM (le routeur ou le commutateur à l’origine des sondes RPM) et sur le serveur de sondes RPM et s’applique uniquement au trafic IPv4. Elle est prise en charge sur les points suivants :
Ensemble de services de couche 2 sur les MS-PIC, MS-DPC, MS-MPC et MS-MIC.
Ensemble de services de couche 3 sur les MS-PIC, MS-DPC, MS-MPC et MS-MIC.
Package de services d’extension sur les services M Series, MX Series et T Series Les PIC qui prennent en charge les packages Extension-Provider (dans les versions de Junos OS antérieures à la version 12.3, les packages de fournisseurs d’extensions étaient diversement appelés Junos Services Framework (JSF), MP-SDK et eJunos.)
Les services de couche 2, de couche 3, SDK et l’horodatage PFE RPM interagissent les uns avec les autres. Ici, le client RPM peut se trouver sur l’interface de couche 3
sp-et le serveur RPM peut se trouver sur un package de services SDK.
L’horodatage bidirectionnel est disponible sur sp- et ms- interfaces. Pour configurer l’horodatage bidirectionnel sur les routeurs M Series et T Series, incluez l’instruction suivante destination-interface au niveau de la [edit services rpm probe probe-owner test test-name] hiérarchie :
destination-interface sp-fpc/pic/port.logical-unit destination-interface ms-fpc/pic/port.logical-unit
Spécifiez le routeur client RPM et le routeur serveur RPM sur l’interface logique des services ou l’interface multiservices en incluant l’instruction rpm au niveau de la [edit interfaces interface-name unit logical-unit-number] hiérarchie :
rpm (client | server);
L’interface logique doit être dédiée à la tâche RPM. Elle nécessite la configuration de l’instruction family inet et d’une /32 adresse, comme illustré dans l’exemple. Cette configuration est également nécessaire pour d’autres services tels que le NAT et le pare-feu dynamique. Vous ne pouvez pas configurer le service RPM car unit 0 RPM nécessite une interface logique dédiée ; la même unité ne peut pas prendre en charge à la fois RPM et d’autres services. Étant donné que la surveillance active des flux nécessite unit 0, mais que RPM peut fonctionner sur n’importe quelle interface logique, une vérification de contrainte vous empêche d’y valider une configuration RPM.
Sur les routeurs MX Series, sur les routeurs M320 Series utilisant le MPC de file d’attente amélioré et sur les commutateurs EX Series, incluez l’instruction hardware-timestamp au niveau de la [edit services rpm probe probe-name test test-name] hiérarchie pour spécifier que les sondes doivent être horodatées dans le processeur hôte du moteur de transfert de paquets :
Sur les routeurs MX Series, sur les routeurs MX10000 Series, sur les routeurs PTX5000, PTX10008 et PTX10016, ainsi que sur les commutateurs EX Series, vous pouvez inclure l’instruction hardware-timestamp au niveau de la [edit services rpm probe probe-name test test-name] hiérarchie pour spécifier que les sondes doivent être horodatées dans le processeur hôte moteur de transfert de paquets. Sur les routeurs MX Series, l’horodatage matériel est pris en charge sur les cartes de ligne suivantes :
DPC
DPCE (en anglais seulement)
MPC1
MPC2
MPC3
MPC4
MPC5
MPC6
MPC7
hardware-timestamp;
Côté client, ces sondes sont horodatées dans le processeur hôte du moteur de transfert de paquets sur le DPC de sortie du routeur MX Series ou M320 Series ou du commutateur EX Series à l’origine des sondes RPM (client RPM). Du côté du répondeur (serveur RPM), les sondes RPM à horodater sont gérées par le processeur hôte du moteur de transfert de paquets, qui génère la réponse à la place du processus RPM. Les sondes RPM sont horodatées uniquement sur le routeur qui les émet (client RPM). Par conséquent, seul le temps d’aller-retour est mesuré pour ces sondes.
Lors de l’utilisation de l’instruction, la data-size valeur de la sonde doit être inférieure d’au moins 100 octets à la MTU par défaut de l’interface de l’interface client RPM (voir Configuration des sondes RPM sur les routeurs M, MX et T Series et les commutateurs EX Series).hardware-timestamp Si l’horodatage matériel des messages de sonde RPM est activé, la taille maximale des données que vous pouvez configurer à l’aide de l’instruction data-size est limitée à 1400.
La fonctionnalité RPM basée sur le moteur de transfert de paquets ne prend en charge aucune configuration de pare-feu dynamique. Si vous avez besoin de combiner l’horodatage RPM avec un pare-feu dynamique, utilisez le service d’horodatage RPM basé sur l’interface décrit plus haut dans cette section. Les MS-DPC prennent en charge le traitement de pare-feu dynamique ainsi que l’horodatage RPM.
Pour configurer l’horodatage unidirectionnel, vous devez également inclure l’instruction one-way-hardware-timestamp au niveau de la [edit services rpm probe probe-owner test test-name] hiérarchie :
one-way-hardware-timestamp;
Si vous configurez des sondes RPM pour une interface de services (sp-), vous devez annoncer les routes locales d’une manière spécifique pour les protocoles de routage suivants :
Pour OSPF, vous pouvez annoncer la route locale en incluant l’interface de services dans la zone OSPF. Pour configurer ce paramètre, incluez l’instruction
interface sp-fpc/pic/portau niveau de la[edit protocols ospf area area-number]hiérarchie.Pour BGP et IS-IS, vous devez exporter les routes d’interface et créer une stratégie qui accepte la route locale de l’interface de services. Pour exporter des routes d’interface, incluez les
point-to-pointinstructions etlanau niveau de la[edit routing-options interface-routes family inet export]hiérarchie. Pour configurer une stratégie d’exportation qui accepte l’itinéraire local de l’interface de services, incluez lesprotocol localinstructions ,rib inet.0, et etroute-filter sp-interface-ip-address/32 exactau niveau de la[edit policy-options policy-statement policy-name term term-name from]hiérarchie et l’actionacceptau niveau de la[edit policy-options policy-statement policy-name term term-name then]hiérarchie. Pour que la stratégie d’exportation prenne effet, appliquez-la à BGP ou IS-IS avec l’instructionexport policy-nameau niveau de la[edit protocols protocol-name]hiérarchie.
Pour plus d’informations sur ces configurations, reportez-vous au Guide de l’utilisateur Stratégies de routage, filtres de pare-feu et mécanismes de contrôle du trafic.
Le routage des paquets de sonde via la carte multiservices vous permet également de filtrer les paquets de sonde dans des files d’attente particulières. L’exemple suivant montre la configuration RPM et le filtre qui spécifie la mise en file d’attente :
services rpm {
probe p1 {
test t1 {
probe-type icmp-ping;
target address 10.8.4.1;
probe-count 10;
probe-interval 10;
test-interval 10;
dscp-code-points af11;
data-size 100;
destination-interface sp-1/2/0.0;
}
}
}
firewall {
filter f1 {
term t1 {
from {
dscp af11;
}
then {
forwarding-class assured-forwarding;
}
}
}
}
interfaces sp-1/2/0 {
unit 2 {
rpm client;
family inet {
address 10.8.4.2/32;
filter {
input f1;
}
}
}
}
interfaces sp-1/2/1 {
unit 2 {
rpm server;
family inet {
address 10.8.3.2/32;
filter {
input f1;
}
}
}
}
Pour plus d’informations sur les filtres de pare-feu, reportez-vous au Guide de l’utilisateur des stratégies de routage, des filtres de pare-feu et des mécanismes de contrôle du trafic ; Pour plus d’informations sur la mise en file d’attente, reportez-vous au Guide de l’utilisateur de la classe de service (routeurs et commutateurs EX9200).