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 horodatage des types de sonde RPM suivants : icmp-ping, icmp-ping-timestamp, et udp-ping-timestampudp-ping.
Sur les routeurs M Series et T Series avec MS-PIC, sur les routeurs MX Series avec une carte d’interface 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’équipement client RPM (le routeur ou le commutateur à l’origine des sondes RPM) et sur le serveur de sonde RPM et ne s’applique qu’au trafic IPv4. Il est pris en charge sur les points suivants :
Package de services de couche 2 sur MS-PIC, MS-DPC, MPC MS-MPC et MS-MIC.
Package de services de couche 3 sur MS-PIC, MS-DPC, MS-MPC et MS-MIC.
Package de services de fournisseur d’extension sur les piC de services M Series, MX Series et T Series qui prennent en charge les packages Extension-Provider (Dans les versions Junos OS antérieures à la version 12.3, les packages de fournisseur d’extension étaient divers appelés Junos Services Framework (JSF), MP-SDK et eJunos.)
Les couches 2, les couches 3, les services SDK et l’horodatage PFE RPM interagissent entre eux. Ici, le client RPM peut se trouver sur l’interface de couche 3
sp-et le serveur RPM sur un package de services SDK.
L’horodatage bidirectionnaire est disponible sur sp- et sur les ms- interfaces. Pour configurer l’horodatage dans les deux sens sur les routeurs M Series et T Series, incluez l’énoncé 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 de services ou l’interface multiservices en incluant l’énoncé 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. Il 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 nat et pare-feu à états. Vous ne pouvez pas configurer le service RPM sur unit 0 car 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 des contraintes vous empêche de commettre une configuration RPM là-bas.
Sur les routeurs MX Series, sur les routeurs M320 Series utilisant le MPC enhanced Fileuing et sur les commutateurs EX Series, vous incluez l’énoncé hardware-timestamp au [edit services rpm probe probe-name test test-name] niveau hiérarchique pour spécifier que les sondes doivent être horodatés 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, et sur les commutateurs EX Series, vous pouvez inclure l’énoncé au niveau de la hardware-timestamp [edit services rpm probe probe-name test test-name] hiérarchie pour spécifier que les sondes doivent être horodatés dans le processeur hôte du moteur de transfert de paquets. Sur les routeurs MX Series, l’horodatage matériel est pris en charge sur les cartes d’interface suivantes :
DPC
DPCE
MPC1
MPC2
MPC3
MPC4
MPC5
MPC6
MPC7
hardware-timestamp;
Côté client, ces sondes sont horodatés dans le processeur hôte du moteur de transfert de paquets sur la sortie DPC sur le routeur MX Series ou M320 Series ou le commutateur EX Series à l’origine des sondes RPM (rpm client). Côté répondeur (serveur RPM), les sondes RPM à horodatage sont gérées par le processeur hôte du moteur de transfert de paquets, qui génère la réponse au lieu du processus RPM. Les sondes RPM sont horodatés uniquement sur le routeur qui les a créées (client RPM). En conséquence, seul le temps 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 de taille des données est limitée à 1 400.
La fonctionnalité RPM basée sur le moteur de transfert de paquets ne prend pas en charge les configurations de pare-feu dynamiques. Si vous devez combiner l’horodatage RPM avec un pare-feu dynamique, utilisez le service d’horodatage RPM basé sur l’interface décrit plus tôt dans cette section. Les MS-DPC prennent en charge le traitement de pare-feu à états ainsi que l’horodatage RPM.
Pour configurer l’horodatage à sens unique, 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 le routage local 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 des routes d’interface et créer une stratégie qui accepte le routage local de l’interface de services. Pour exporter des routes d’interface, incluez les
point-to-pointdéclarations etlanau niveau de la[edit routing-options interface-routes family inet export]hiérarchie. Pour configurer une stratégie d’exportation qui accepte le routage local de l’interface de services, incluez leprotocol local,rib inet.0etroute-filter sp-interface-ip-address/32 exactles déclarations au 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, consultez le Guide de l’utilisateur des stratégies de routage, des filtres de pare-feu et du contrôle du trafic.
Le routage des paquets de sonde via la carte multiservices vous permet également de filtrer les paquets de sonde vers des files d’attente particulières. L’exemple suivant illustre la configuration RPM et le filtre qui spécifie la 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, consultez le Guide de l’utilisateur des stratégies de routage, des filtres de pare-feu et du contrôle du trafic ; pour plus d’informations sur la mise en file d’attente, consultez le Guide de l’utilisateur de classe de service (routeurs et commutateurs EX9200).