Collecte de statistiques sur les sessions MPLS
Configuration de MPLS pour collecter des statistiques
Vous pouvez configurer MPLS afin qu’il recueille régulièrement des statistiques de trafic sur toutes les sessions MPLS, y compris les sessions de transit, en configurant l’instruction statistics . Vous devez configurer l’instruction statistics si vous souhaitez collecter des statistiques de trafic MPLS à l’aide de l’interrogation SNMP des bases d’informations de gestion (MIB) MPLS.
Pour activer ou désactiver la collecte de statistiques MPLS, incluez l’énoncé statistics :
statistics { auto-bandwidth (MPLS Statistics); file filename <files number> <size size> <world-readable | no-world-readable>; interval seconds; no-transit-statistics; transit-statistics-polling; }
Vous pouvez configurer ces instructions aux niveaux hiérarchiques suivants :
[edit protocols mpls][edit logical-systems logical-system-name protocols mpls]
L’intervalle par défaut est de 300 secondes.
Si vous configurez l’option file , les statistiques sont placées dans un fichier, avec une entrée par LSP. Pendant l’intervalle spécifié, les informations suivantes sont enregistrées dans ce fichier :
Nombre de paquets, d’octets, de paquets par seconde et d’octets par seconde transmis par chaque LSP. La parité des fonctionnalités pour l’affichage des statistiques de paquets et d’octets pour les sous-LSP d’un LSP point à multipoint sur le chipset Junos Trio est prise en charge dans les versions 11.1R2, 11.2R2 et 11.4 de Junos OS.
Pourcentage de bande passante transmise sur un LSP donné par rapport au pourcentage de bande passante configuré pour ce LSP. Si aucune bande passante n’est configurée pour un LSP, 0 % est enregistré dans la colonne des pourcentages.
À la fin de chaque rapport périodique, un récapitulatif indique le temps en cours, le nombre total de sessions, le nombre de sessions lues, le nombre de sessions ignorées et les erreurs de lecture, le cas échéant. Les sessions ignorées sont généralement celles qui ne sont pas à l’état en hausse ou celles avec un label entrant réservé (de 0 à 15) (généralement le point de sortie d’un LSP). La raison d’une erreur de lecture apparaît sur la même ligne que l’entrée du LSP sur lequel l’erreur s’est produite. La collecte de statistiques est un processus peu fiable; des erreurs de lecture occasionnelles peuvent affecter leur précision. Voici l’exemple de sortie :
lsp6 0 pkt 0 Byte 0 pps 0 Bps 0 lsp5 0 pkt 0 Byte 0 pps 0 Bps 0 lsp6.1 34845 pkt 2926980 Byte 1049 pps 88179 Bps 132 lsp5.1 0 pkt 0 Byte 0 pps 0 Bps 0 lsp4 0 pkt 0 Byte 0 pps 0 Bps 0 Dec 7 17:28:38 Total 6 sessions: 5 success, 0 fail, 1 ignored
Vue d’ensemble de la perte de paquets et des retards de paquets à la demande pour les LSP UHP
Cette rubrique décrit les méthodes de mesure de la perte de paquets, des retards et du débit pour les chemins de commutation d’étiquettes (LSP) UHP (Point-to-point ultimate hop popping) dans les réseaux MPLS afin de surveiller les performances du réseau.
- Importance de mesurer les pertes et les retards de paquets
- Définition des pertes, des retards et du débit des paquets
- Mécanismes de mesure des pertes de paquets et des retards
- Métriques de perte et de retard de paquets
- Concepts de mesure des pertes de paquets et des retards
- Fonctionnalité de mesure des pertes de paquets et des retards
- Fonctionnalités de perte et de retard de paquets
Importance de mesurer les pertes et les retards de paquets
L’essor des applications consommatrices de bande passante, telles que l’IPTV et la vidéo mobile, associée à la pression exercée pour réduire le coût par bit et optimiser la valeur par bit, oblige les opérateurs à migrer leurs réseaux de transport de technologies basées sur circuit vers des technologies basées sur des paquets. MPLS est une technologie de transport de paquets à grande échelle, orientée connexion, parfaitement adaptée aux réseaux de transport de paquets.
Avec l’émergence de nouvelles applications sur les réseaux de données, il devient de plus en plus important pour les fournisseurs de services de prévoir avec précision l’impact des nouveaux déploiements d’applications. La compréhension et la modélisation des performances réseau sont particulièrement pertinentes pour le déploiement d’applications nouvelles afin de garantir le succès des implémentations. Dans les réseaux de paquets, les pertes et les retards de paquets sont deux des mesures les plus fondamentales des performances. Leur rôle est encore plus central en matière de mesures de bout en bout.
Le trafic appartenant à la plupart des applications utilisateur de bout en bout est soit sensible aux pertes (transfert de fichiers), sensible aux retards (applications vocales ou vidéo), ou les deux (applications informatiques interactives). Les accords de niveau de service (SLA) des fournisseurs de services dépendent de la capacité à mesurer et à surveiller ces mesures de performance réseau, car les SLA dépendent directement ou indirectement de la perte et du retard de l’expérience de trafic client sur le réseau du fournisseur de services.
Pour garantir la conformité aux SLA, les fournisseurs de services ont besoin d’outils pour mesurer et surveiller les métriques de performances en matière de perte de paquets, de retard à sens unique et de retard bidirectionnaire, ainsi que des mesures associées, telles que la variation des retards et le débit des canaux. Cette capacité de mesure offre aux fournisseurs de services une meilleure visibilité sur les caractéristiques de performances de leurs réseaux, facilitant ainsi la planification, le dépannage et l’évaluation des performances du réseau.
Définition des pertes, des retards et du débit des paquets
Dans les réseaux de paquets, les pertes et les retards de paquets sont deux des mesures les plus fondamentales des performances.
Loss— La perte de paquets est l’échec d’un ou plusieurs paquets transmis à leur destination. La perte de paquets fait référence aux paquets de données qui sont abandonnés par le réseau pour gérer la congestion.
Les applications de données sont très tolérantes à la perte de paquets, car elles ne sont généralement pas sensibles au temps et peuvent retransmettre les paquets qui ont été abandonnés. Toutefois, dans les environnements de visioconférence et les communications audio pures, comme la VoIP, la perte de paquets peut créer une gigue.
Delay— Le délai de paquet (également appelé latence) est le temps nécessaire pour qu’un paquet de données se rende d’un point désigné à un autre, en fonction de la vitesse du support de transmission, comme le fil de cuivre, la fibre optique ou les ondes radio, et des retards de transmission par les équipements en cours de route, tels que les routeurs et les modems.
Une faible latence indique une efficacité réseau élevée.
Throughput— Le délai de paquet mesure le temps entre le début d’une action et son exécution, tandis que le débit est le nombre total d’actions qui se produisent dans un la temps donné.
Mécanismes de mesure des pertes de paquets et des retards
Les retards et les pertes de paquets sont deux mesures fondamentales des performances du réseau. Junos OS fournit un mécanisme à la demande pour mesurer les pertes de paquets et les retards sur les chemins de commutation d’étiquettes (LSP) bidirectionnels MPLS ultimate hop popping (UHP).
Le mécanisme de mesure des retards et des pertes de paquets à la demande est lancé à l’aide des commandes CLI suivantes :
monitor mpls loss rsvp: effectue une mesure de perte à la demande pour les LSP UHP bidirectionnels associés.monitor mpls delay rsvp: effectue une mesure de retard à la demande pour les LSP UHP bidirectionnels associés.monitor mpls loss-delay rsvp: effectue une mesure combinée à la demande des pertes et des retards pour les LSP UHP bidirectionnels associés.
Pour lancer le mécanisme de mesure des retards et des pertes de paquets, il est nécessaire d’entrer les paramètres souhaités pour la mesure, tels que le type de mesure et le nom du LSP. Une fois les paramètres reçus, un récapitulatif des données de surveillance des performances est affiché et le mécanisme est terminé.
Métriques de perte et de retard de paquets
Les mesures de performance suivantes sont mesurées à l’aide des mécanismes de perte et de retard de paquets à la demande :
Mesure des pertes (paquet et octet)
Mesure du débit (paquets et octets)
Délai de canal bidirectionnaire
Retard aller-retour
Variation de délai entre paquets (IPDV)
La monitor mpls loss rsvp commande effectue les mesures de perte et de débit, et la commande effectue le monitor mpls delay rsvp délai de canal à double sens, le délai aller-retour et les mesures IPDV. La monitor mpls loss-delay rsvp commande effectue une mesure combinée des pertes et des retards et mesure simultanément toutes les mesures de performances mentionnées ci-dessus.
Concepts de mesure des pertes de paquets et des retards
Les concepts suivants aident à mieux comprendre les fonctionnalités de la perte et du retard de paquets :
Querier— Un querier est le routeur de périphérie du fournisseur entrant (PE), qui est à l’origine du message de requête pour mesurer les pertes ou les retards.
Responder— Un répondeur est le routeur PE sortant, qui reçoit et répond aux messages de requête d’un querier.
Associated bidirectional LSP: un LSP bidirectionnel associé se compose de deux LSP unidirectionnels qui sont liés (ou associés les uns aux autres) via une configuration sur les deux terminaux LSP.
La mesure des pertes et des retards à la demande ne peut être effectuée que sur les LSP UHP bidirectionnels associés.
Generic associated channel (G-Ach)— Les messages de surveillance des performances pour le flux de mesure des pertes et des retards à la demande sur le MPLS G-Ach. Ce type de canal prend uniquement en charge les réponses en bande et ne prend pas en charge les modes hors bande ou sans réponse.
Measurement point (MP): mp est l’emplacement où une condition est décrite pour la mesure.
Le MP pour la perte de paquets côté transmission est entre la structure de commutation et l’interface de transmission. La valeur du compteur est tamponné dans le message de mesure de la perte dans le matériel avant qu’il ne soit mis en file d’attente pour la transmission.
Le MP pour la perte de paquets côté réception se trouve entre l’interface de réception et la structure de commutation. Le MP est distribué côté réception. En outre, lorsque l’interface de transmission est une interface agrégée, le MP est également distribué.
Query rate: le débit des requêtes est l’intervalle entre deux requêtes envoyées pour mesurer les pertes et les retards.
Étant donné que les messages de perte et de retard proviennent du moteur de routage, un taux de requête élevé pour plusieurs canaux fait peser une lourde charge sur le moteur de routage. L’intervalle de requête minimum pris en charge est d’une seconde.
Le taux de requête doit être élevé pour les compteurs 32 bits, car les compteurs peuvent s’emballer rapidement lorsque le débit de trafic de données est très élevé. Le taux de requête peut être faible lorsque des compteurs de 64 bits sont utilisés sur les quatre points de mesure impliqués dans la mesure des pertes. Junos OS ne prend en charge que les compteurs 64 bits.
Traffic class— Par défaut, la mesure des pertes est prise en charge pour l’ensemble du canal. Junos OS prend également en charge la mesure de la perte de paquets par classe de trafic, où des compteurs qui maintiennent des statistiques de trafic de données par classe de trafic doivent être créés.
Par défaut, les compteurs de classe par trafic ne sont pas créés. Pour configurer la mesure de perte étendue par classe de trafic, incluez l’instruction
traffic-class-statisticsau niveau de la[edit protocols mpls statistics]hiérarchie.Une fois
traffic-class-statisticsconfigurés, les paquets de contrôle circulant sur le G-Ach ne sont pas comptés dans les compteurs de transmission et de réception.REMARQUE :L’activation et la désactivation des statistiques de classe de trafic entraînent la réinitialisation de tous les compteurs (compteurs agrégés et compteurs par classe) pour les LSP.
Loss measurement mode— Junos OS prend en charge le mode direct de mesure des pertes à la demande et ne prend pas en charge le mode inféré.
Pour mesurer les pertes directes, les statistiques du trafic de données doivent être maintenues à l’entrée et à la sortie de deux LSP unidirectionnels du LSP bidirectionnel associé. Lorsqu’un routeur MX Series n’utilise que des MPC et des MIC, des compteurs pour maintenir les statistiques de trafic de données sont créés par défaut à l’entrée de tous les types de LSP et de sorties de LSP UHP.
Toutefois, le mode direct de mesure de la perte n’est pas entièrement précis pour les raisons suivantes :
Transfert parallèle du matériel.
Présence d’un multichemin à coût égal (ECMP) sur le réseau, par exemple des interfaces Ethernet agrégées, ce qui peut entraîner la réorganisation des paquets de données par rapport aux messages de mesure de perte.
Les paquets de contrôle qui ne circulent pas sur G-Ach ne sont pas comptés à l’entrée LSP, mais sont comptés à la sortie LSP.
Ré-ordre du trafic de données par rapport au message de mesure de perte lorsqu’un Diffserv est implémenté dans le réseau MPLS et que le champ de mesure des pertes est le canal complet et non la classe de trafic.
Pour surmonter cette limitation, effectuez des mesures de perte étendues par classe de trafic lors de l’implémentation d’un Diffserv.
REMARQUE :La mesure des pertes en mode direct est vulnérable aux perturbations lorsque l’interface d’entrée ou de sortie associée au LSP change.
Loss measurement synchronization: les conditions de synchronisation spécifiées à la section 2.9.8 de la RFC 6374 ne sont pas vraies au sens absolu du terme. Toutefois, comme les compteurs de mesure de perte sont tamponnés dans le matériel, les erreurs introduites du fait de ne pas satisfaire les conditions de synchronisation sont relativement faibles. Ces erreurs doivent être quantifiées.
Lorsque l’interface de transmission ou de réception du LSP est une interface agrégée, plus d’erreurs sont introduites que lorsque les interfaces ne sont pas agrégées. Dans tous les cas, les compteurs de mesure des pertes sont tamponnés dans le matériel et l’erreur doit être quantifiée.
Delay measurement accuracy— Lorsque les interfaces de transmission et de réception résident sur différents moteurs de transfert de paquets, l’horloge doit être synchronisée sur ces moteurs de transfert de paquets pour mesurer les retards dans les deux sens. Cette condition est valable pour la plate-forme sur laquelle la fonctionnalité de mesure du retard à la demande est implémentée.
Lorsqu’il existe des interfaces agrégées ou ECMP, le délai n’est mesuré que pour un seul des chemins potentiels.
Lorsqu’un message combiné de perte et de retard est utilisé pour le calcul du retard, la précision du retard est plus faible que lorsque le message de mesure du retard est utilisé dans certains cas, par exemple lorsque l’interface de transmission ou de réception est une interface agrégée.
Les mesures de retard sont toujours effectuées par classe de trafic, et la précision de la mesure doit être quantifiée après les tests.
Timestamp format— Junos OS prend uniquement en charge le format IEEE 1588 Precision Time Protocol (PTP) [IEEE1588] pour l’enregistrement des messages de mesure des retards. Le format de temps réseau (NTP) n’est pas pris en charge.
Operations, administration, and maintenance (OAM)— Pour indiquer que tous les messages OAM pour les LSP MPLS circulent sur le G-Ach MPLS, et que les messages de surveillance des performances MPLS soient transmis sur le G-Ach MPLS, l’instruction
oam mpls-tp-modedoit être incluse au niveau de la[edit protocols mpls label-switched-path lsp-name]hiérarchie.
Fonctionnalité de mesure des pertes de paquets et des retards
Figure 1 illustre les méthodes de base utilisées pour mesurer les pertes et les retards de paquets en bidirectionnelle. Un canal bidirectionnel existe entre les deux routeurs, le routeur A et le routeur B. Les points de référence temporels (T1, T2, T3 et T4) sont associés à une opération de mesure qui a lieu au routeur A. L’opération consiste à envoyer un message de requête au routeur B et au routeur B à renvoyer une réponse. Chaque point de référence indique le moment où la requête ou le message de réponse est transmis ou reçu sur le canal.
Dans Figure 1, le routeur A peut s’organiser pour mesurer la perte de paquets sur le canal dans les directions avant et inverse en envoyant des messages de requête de mesure de perte au routeur B. Chacun des messages d’avant et d’inverse contient le nombre de paquets transmis avant l’heure T1 sur le canal vers le routeur B (A_TxP).
Lorsque le message atteint le routeur B, deux valeurs sont ajoutées au message et le message est répercuté sur le routeur A. Les deux valeurs sont le nombre de paquets reçus avant le temps T2 sur le canal du routeur A (B_RxP) et le nombre de paquets transmis avant le temps T3 sur le canal vers le routeur A (B_TxP).
Lorsque la réponse atteint le routeur A, une quatrième valeur est ajoutée au message : le nombre de paquets reçus avant l’heure T4 sur le canal du routeur B (A_RxP).
Ces quatre contre-valeurs (A_TxP), (B_RxP), (B_TxP) et (A_RxP) permettent au routeur A de calculer les statistiques de perte souhaitées. Étant donné que le nombre de transmissions au routeur A et le nombre de réception au routeur B (et vice versa) peuvent ne pas être synchronisés au moment du premier message, et pour limiter les effets de contre-enveloppement, la perte est calculée sous la forme d’un delta entre les messages.
La perte de transmission (A_TxLoss[n-1,n]) et la perte de réception (A_RxLoss[n-1,n]) dans l’intervalle de mesure marqué par les messages LM[n-1] et LM[n] sont calculées par le routeur A comme suit :
A_TxLoss[n-1,n] = (A_TxP[n] - A_TxP[n-1]) - (B_RxP[n] - B_RxP[n-1])
A_RxLoss[n-1,n] = (B_TxP[n] - B_TxP[n-1]) - (A_RxP[n] - A_RxP[n-1])
L’arithmétique est modulo la taille du compteur.
Pour mesurer au niveau du routeur A le délai sur le canal vers le routeur B, un message de requête de mesure du retard est envoyé du routeur A au routeur B contenant un horodatage qui enregistre l’instant auquel il est transmis. En Figure 1, l’horodatage est enregistré en T1.
Lorsque le message atteint le routeur B, un horodatage est ajouté pour enregistrer l’instant auquel il est reçu (T2). Le message peut désormais être reflété du routeur B au routeur A, le routeur B ajoutant son horodatage de transmission (T3) et le routeur A ajoutant son horodatage de réception (T4).
Ces quatre horodatages (T1, T2, T3 et T4) permettent au routeur A de calculer le délai unidirectionnel dans chaque direction, ainsi que le délai à double sens pour le canal. Les calculs de retard à sens unique nécessitent que les horloges des routeurs A et B soient synchronisées.
À ce stade, le routeur A peut calculer le délai de canal à double sens et le délai d’aller-retour associés au canal comme suit :
Délai de canal bidirectionnaire = (T4 - T1) - (T3 - T2)
Retard aller-retour = T4 - T1
Fonctionnalités de perte et de retard de paquets
Supported Features of Packet Loss and Delay
Junos OS prend en charge les fonctionnalités suivantes avec la mesure des pertes et des retards à la demande :
Surveillance des performances pour les LSP MPLS bidirectionnels MPLS point à point uniquement
Mesure des pertes
Mesure du débit
Mesure du retard dans les deux sens (retard du canal et retard aller-retour)
Variation de délai entre paquets (IPDV)
Mesure des pertes en mode direct
Interfaces Ethernet agrégées et SONET agrégées
Prise en charge multichassis
Compatible 64 bits
Unsupported Features of Packet Loss and Delay
Junos OS ne prend pas en charge les fonctionnalités suivantes de mesure des pertes et des retards à la demande :
Mesure des pertes et des retards pour les pseudowires (section 2.9.1 de la RFC 6374)
Mesure unidirectionnelle (section 2.6 de la RFC 6374)
Mesure dyadique (section 2.7 de la RFC 6374)
Mesure des pertes et des retards en mode bouclage (section 2.8 de la RFC 6374)
Mesure des pertes et des retards sur un nœud intermédiaire à partir d’un point de terminaison LSP (section 2.9.5 de la RFC 6374)
Post-traitement externe (section 2.9.7 de la RFC 6374)
Mesure de la perte en mode inféré (section 2.9.8 de la RFC 6374)
Mode pro-actif
Systèmes logiques
SNMP
Exemple : Configuration de la mesure des pertes et des retards à la demande
Cet exemple montre comment mesurer les pertes et les retards à la demande pour les chemins de commutation d’étiquettes (LSP) UHP (Point-to-Point) dans les réseaux MPLS pour surveiller les performances du réseau.
Conditions préalables
Cet exemple utilise les composants matériels et logiciels suivants :
-
Deux plates-formes de routage universelles 5G MX Series qui contiennent uniquement des MPC/MIC
-
Junos OS Version 14.2 ou ultérieure s’exécutant sur tous les routeurs
Avant de commencer :
-
Configurez les interfaces de l’équipement.
-
Configurez les numéros du système et les iDs de routeur autonomes pour les équipements.
-
Configurez les protocoles suivants :
-
RSVP
-
MPLS
-
OSPF
-
Présentation
À partir de la version 14.2 de Junos OS, un outil à la demande est mis en place pour surveiller et mesurer la perte de paquets, le retard des paquets ou les deux pour les chemins de commutation d’étiquettes (LSP) MPLS (UHP) bidirectionnels associés. L’outil peut être activé à l’aide des commandes CLI suivantes : monitor mpls loss rsvp, et monitor mpls delay rsvpmonitor mpls loss-delay rsvp.
Ces commandes fournissent un récapitulatif à la demande des métriques de performances pour la perte de paquets en mode direct, le délai de paquet à double sens et les mesures associées, telles que la variation des retards entre paquets et la mesure du débit du canal.
Cette fonctionnalité offre une visibilité en temps réel sur les performances du réseau, ce qui facilite la planification, le dépannage et l’évaluation des performances du réseau.
topologie
Figure 2 illustre la mesure des pertes et des retards à la demande à l’aide d’une topologie simple à deux routeurs.
Dans cet exemple, un LSP bidirectionnel associé est configuré entre les routeurs R1 et R2, pour lesquels les métriques de performances sont mesurées.
Configuration
Configuration rapide cli
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez les détails nécessaires pour correspondre à la configuration de votre réseau, copiez et collez les commandes dans la CLI au niveau de la [edit] hiérarchie, puis entrez commit à partir du mode de configuration.
R1
set chassis fpc 0 pic 3 tunnel-services bandwidth 1g set chassis network-services enhanced-ip set interfaces ge-0/0/0 unit 0 family inet address 10.1.1.1/30 set interfaces ge-0/0/0 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.10.0.1/32 set interfaces lo0 unit 0 family mpls set routing-options router-id 10.10.0.1 set protocols rsvp interface ge-0/0/0.0 set protocols rsvp interface lo0.0 set protocols rsvp interface fxp0.0 disable set protocols mpls statistics traffic-class-statistics set protocols mpls label-switched-path R1-R2 to 10.20.0.1 set protocols mpls label-switched-path R1-R2 oam mpls-tp-mode set protocols mpls label-switched-path R1-R2 ultimate-hop-popping set protocols mpls label-switched-path R1-R2 associate-lsp R2-R1 set protocols mpls interface ge-0/0/0.0 set protocols mpls interface lo0.0 set protocols mpls interface fxp0.0 disable set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface fxp0.0 disable
R2
set chassis fpc 0 pic 3 tunnel-services bandwidth 1g set chassis network-services enhanced-ip set interfaces ge-0/0/0 unit 0 family inet address 10.1.1.2/30 set interfaces ge-0/0/0 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.20.0.1/32 set interfaces lo0 unit 0 family mpls set routing-options router-id 10.20.0.1 set protocols rsvp interface ge-0/0/0.0 set protocols rsvp interface lo0.0 set protocols rsvp interface fxp0.0 disable set protocols mpls statistics traffic-class-statistics set protocols mpls label-switched-path R2-R1 to 10.10.0.1 set protocols mpls label-switched-path R2-R1 oam mpls-tp-mode set protocols mpls label-switched-path R2-R1 ultimate-hop-popping set protocols mpls label-switched-path R2-R1 associate-lsp R1-R2 set protocols mpls interface ge-0/0/0.0 set protocols mpls interface lo0.0 set protocols mpls interface fxp0.0 disable set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0.interface fxp0.0 disable
Procédure
Procédure étape par étape
L’exemple suivant exige que vous parcouriez différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation sur l’interface cli, consultez Utilisation de l’éditeur CLI en mode de configuration dans le guide de l’utilisateur CLI.
Pour configurer le routeur R1 :
-
Activez le châssis avec des services de tunnel et une configuration améliorée des services réseau IP.
[edit chassis] user@R1# set fpc 0 pic 3 tunnel-services bandwidth 1g user@R1# set network-services enhanced-ip
-
Configurez les interfaces du routeur R1.
[edit interfaces] user@R1# set ge-0/0/0 unit 0 family inet address 10.1.1.1/30 user@R1# set ge-0/0/0 unit 0 family mpls user@R1# set lo0 unit 0 family inet address 10.10.0.1/32 user@R1# set lo0 unit 0 family mpls
-
Configurez l’ID du routeur pour le routeur R1.
[edit routing-options] user@R1# set router-id 10.10.0.1
-
Activez RSVP sur toutes les interfaces du routeur R1, à l’exception de l’interface de gestion.
[edit protocols] user@R1# set rsvp interface ge-0/0/0.0 user@R1# set rsvp interface lo0.0 user@R1# set rsvp interface fxp0.0 disable
-
Activez MPLS sur toutes les interfaces du routeur R1, à l’exception de l’interface de gestion.
[edit protocols] user@R1# set mpls interface ge-0/0/0.0 user@R1# set mpls interface lo0.0 user@R1# set mpls interface fxp0.0 disable
-
Configurez un LSP bidirectionnel associé au routeur R2.
[edit protocols] user@R1# set mpls label-switched-path R1-R2 to 10.20.0.1 user@R1# set mpls label-switched-path R1-R2 oam mpls-tp-mode user@R1# set mpls label-switched-path R1-R2 ultimate-hop-popping user@R1# set mpls label-switched-path R1-R2 associate-lsp R2-R1
-
Créez des classes de trafic pour gérer les statistiques de trafic de données par classe de trafic.
Cela permet de mesurer les pertes par classe de trafic.
[edit protocols] user@R1# set mpls statistics traffic-class-statistics
-
Configurez OSPF avec des fonctionnalités d’ingénierie du trafic et activez OSPF sur toutes les interfaces du routeur R1, à l’exception de l’interface de gestion.
[edit protocols] user@R1# set ospf traffic-engineering user@R1# set ospf area 0.0.0.0 interface ge-0/0/0.0 user@R1# set ospf area 0.0.0.0 interface lo0.0 user@R1# set ospf interface fxp0.0 disable
Résultats
À partir du mode de configuration, confirmez votre configuration en entrant le show chassis, show interfaces, show routing-optionset les show protocols commandes. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
user@R1# show chassis
fpc 0 {
pic 3 {
tunnel-services {
bandwidth 1g;
}
}
}
network-services enhanced-ip;
user@R1# show interfaces
ge-0/0/0 {
unit 0 {
family inet {
address 1o.1.1.1/30;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.10.0.1/32;
}
family mpls;
}
}
user@R1# show routing-options router-id 10.10.0.1;
user@R1# show protocols
rsvp {
interface ge-0/0/0.0;
interface lo0.0;
interface fxp0.0 {
disable;
}
}
mpls {
statistics {
traffic-class-statistics;
}
label-switched-path R1-R2 {
to 10.20.0.1;
oam mpls-tp-mode;
ultimate-hop-popping;
associate-lsp R2-R1;
}
interface ge-0/0/0.0;
interface lo0.0;
interface fxp0.0 {
disable;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface ge-0/0/0.0;
interface lo0.0;
interface fxp0.0 {
disable;
}
}
}
Vérification
Vérifiez que la configuration fonctionne correctement.
- Vérification du statut LSP
- Vérifier la mesure de la perte de paquets
- Vérifier la mesure des retards de paquets
- Vérifier la mesure des pertes de paquets et des retards
Vérification du statut LSP
But
Vérifiez que le LSP bidirectionnel associé entre les routeurs R1 et R2 est opérationnel.
Action
À partir du mode opérationnel, exécutez la show mpls lsp commande.
user@R1> show mpls lsp Ingress LSP: 1 sessions To From State Rt P ActivePath LSPname 10.20.0.1 10.10.0.1 Up 0 * R1-R2 Assoc-Bidir Total 1 displayed, Up 1, Down 0 Egress LSP: 1 sessions To From State Rt Style Labelin Labelout LSPname 10.10.0.1 10.20.0.1 Up 0 1 FF 299776 - R2-R1 Assoc-Bidir Total 1 displayed, Up 1, Down 0 Transit LSP: 0 sessions Total 0 displayed, Up 0, Down 0
Sens
Le LSP R1-R2 bidirectionnel associé est opérationnel et actif.
Vérifier la mesure de la perte de paquets
But
Vérifiez le résultat de la mesure de perte à la demande.
Action
À partir du mode opérationnel, exécutez la monitor mpls loss rsvp R1-R2 count 2 detail commande.
user@R1> monitor mpls loss rsvp R1-R2 count 2 detail (0) Response code : Success Origin timestamp : 1404129082 secs, 905571890 nsecs Forward transmit count : 83040 Forward receive count : 83040 Reverse transmit count : 83100 Reverse receive count : 83100 (1) Response code : Success Origin timestamp : 1404129083 secs, 905048410 nsecs Forward transmit count : 83841 Forward receive count : 83841 Reverse transmit count : 83904 Reverse receive count : 83904 Current forward transmit count : 801 Current forward receive count : 801 Current forward loss : 0 packets Current forward loss ratio : 0.000000 Current forward throughput : 0.801 kpps Current reverse transmit count : 804 Current reverse receive count : 804 Current reverse loss : 0 packets Current reverse loss ratio : 0.000000 Current reverse throughput : 0.804 kpps (2) Response code : Success Origin timestamp : 1404129084 secs, 904828715 nsecs Forward transmit count : 84423 Forward receive count : 84423 Reverse transmit count : 84487 Reverse receive count : 84487 Current forward transmit count : 582 Current forward receive count : 582 Current forward loss : 0 packets Current forward loss ratio : 0.000000 Current forward throughput : 0.582 kpps Current reverse transmit count : 583 Current reverse receive count : 583 Current reverse loss : 0 packets Current reverse loss ratio : 0.000000 Current reverse throughput : 0.583 kpps Cumulative forward transmit count : 1383 Cumulative forward loss : 0 packets Average forward loss ratio : 0.000000 Average forward throughput : 0.692 kpps Cumulative reverse transmit count : 1387 Cumulative reverse loss : 0 packets Average reverse loss ratio : 0.000000 Average reverse throughput : 0.694 kpps LM queries sent : 3 LM responses received : 3 LM queries timedout : 0 LM responses dropped due to errors : 0
Sens
La mesure de perte de paquets pour deux comptes est affichée.
Vérifier la mesure des retards de paquets
But
Vérifiez le résultat des mesures de retard à la demande.
Action
À partir du mode opérationnel, exécutez la monitor mpls delay rsvp R1-R2 count 2 detail commande.
user@R1> monitor mpls delay rsvp R1-R2 count 2 detail (1) Response code : Success Querier transmit timestamp : 1404129122 secs, 479955401 nsecs Responder receive timestamp : 1404129122 secs, 468519022 nsecs Responder transmit timestamp : 1404129122 secs, 470255123 nsecs Querier receive timestamp : 1404129122 secs, 481736403 nsecs Current two-way channel delay : 44 usecs Current round-trip-time : 1781 usecs (2) Response code : Success Querier transmit timestamp : 1404129123 secs, 480926210 nsecs Responder receive timestamp : 1404129123 secs, 469488696 nsecs Responder transmit timestamp : 1404129123 secs, 471130706 nsecs Querier receive timestamp : 1404129123 secs, 482613911 nsecs Current two-way channel delay : 45 usecs Current round-trip-time : 1687 usecs Best two-way channel delay : 44 usecs Worst two-way channel delay : 45 usecs Average two-way channel delay : 45 usecs Best round-trip-time : 1687 usecs Worst round-trip-time : 1781 usecs Average round-trip-time : 1734 usecs Average forward delay variation : 1 usecs Average reverse delay variation : 1 usecs DM queries sent : 2 DM responses received : 2 DM queries timedout : 0 DM responses dropped due to errors : 0
Sens
La mesure du délai de paquet pour deux comptes est affichée.
Vérifier la mesure des pertes de paquets et des retards
But
Vérifiez le résultat de la mesure des pertes et des retards à la demande.
Action
À partir du mode opérationnel, exécutez la monitor mpls loss-delay rsvp R1-R2 count 2 detail commande.
user@R1> monitor mpls loss-delay rsvp R1-R2 count 2 detail (0) Response code : Success Forward transmit count : 142049 Forward receive count : 142049 Reverse transmit count : 142167 Reverse receive count : 142167 Querier transmit timestamp : 1404129161 secs, 554422723 nsecs Responder receive timestamp : 1404129161 secs, 542877570 nsecs Responder transmit timestamp : 1404129161 secs, 546004545 nsecs Querier receive timestamp : 1404129161 secs, 557599327 nsecs (1) Response code : Success Forward transmit count : 143049 Forward receive count : 143049 Reverse transmit count : 143168 Reverse receive count : 143168 Current forward transmit count : 1000 Current forward receive count : 1000 Current forward loss : 0 packets Current forward loss ratio : 0.000000 Current forward throughput : 1.000 kpps Current reverse transmit count : 1001 Current reverse receive count : 1001 Current reverse loss : 0 packets Current reverse loss ratio : 0.000000 Current reverse throughput : 1.001 kpps Querier transmit timestamp : 1404129162 secs, 554465742 nsecs Responder receive timestamp : 1404129162 secs, 542919166 nsecs Responder transmit timestamp : 1404129162 secs, 545812736 nsecs Querier receive timestamp : 1404129162 secs, 557409175 nsecs Current two-way channel delay : 49 usecs Current round-trip-time : 2943 usecs (2) Response code : Success Forward transmit count : 143677 Forward receive count : 143677 Reverse transmit count : 143799 Reverse receive count : 143799 Current forward transmit count : 628 Current forward receive count : 628 Current forward loss : 0 packets Current forward loss ratio : 0.000000 Current forward throughput : 0.627 kpps Current reverse transmit count : 631 Current reverse receive count : 631 Current reverse loss : 0 packets Current reverse loss ratio : 0.000000 Current reverse throughput : 0.630 kpps Querier transmit timestamp : 1404129163 secs, 556698575 nsecs Responder receive timestamp : 1404129163 secs, 545150128 nsecs Responder transmit timestamp : 1404129163 secs, 546918408 nsecs Querier receive timestamp : 1404129163 secs, 558515047 nsecs Current two-way channel delay : 48 usecs Current round-trip-time : 1816 usecs Cumulative forward transmit count : 1628 Cumulative forward loss : 0 packets Average forward loss ratio : 0.000000 Average forward throughput : 0.813 kpps Cumulative reverse transmit count : 1632 Cumulative reverse loss : 0 packets Average reverse loss ratio : 0.000000 Average reverse throughput : 0.815 kpps Best two-way channel delay : 48 usecs Worst two-way channel delay : 49 usecs Average two-way channel delay : 49 usecs Best round-trip-time : 1816 usecs Worst round-trip-time : 3176 usecs Average round-trip-time : 2645 usecs Average forward delay variation : 1 usecs Average reverse delay variation : 0 usecs LDM queries sent : 3 LDM responses received : 3 LDM queries timedout : 0 LDM responses dropped due to errors : 0
Sens
La perte de paquets et la mesure des retards pour deux comptes est affichée.
Exemple : Configuration des mesures de perte et de retards pro-active pour les LSP MPLS bidirectionnels
Cet exemple montre comment configurer des mesures de perte et de retard pro-active pour les chemins de commutation d’étiquettes (LSP) de saut ultime point à point dans les réseaux MPLS afin de surveiller les performances du réseau.
Conditions préalables
Cet exemple utilise les composants matériels et logiciels suivants :
-
Deux plates-formes de routage universelles 5G MX Series qui contiennent uniquement des MPC/MIC
-
Junos OS Version 15.1 ou ultérieure s’exécutant sur tous les routeurs
Avant de commencer :
-
Configurez les interfaces de l’équipement.
-
Configurez les numéros du système et les iDs de routeur autonomes pour les équipements.
-
Configurez les protocoles suivants :
-
MPLS
-
OSPF
-
RSVP
-
Présentation
À partir de la version 15.1 de Junos OS, un outil pro-actif pour surveiller et mesurer les pertes de paquets, les retards de paquets ou les deux pour les chemins de commutation d’étiquettes (LSP) MPLS bidirectionnels associés.
Cette fonctionnalité fournit les mesures de performances suivantes :
-
Variation de délai entre paquets (IPDV)
-
Mesure des pertes
-
Retard aller-retour (RTT)
-
Mesure du débit
-
Délai de canal bidirectionnaire
Cette fonctionnalité offre une visibilité en temps réel sur les performances du réseau, ce qui facilite la planification, le dépannage et l’évaluation des performances du réseau.
topologie
Figure 3 illustre les mesures de perte et de retard pro-active à l’aide d’une topologie simple à deux routeurs.
Dans cet exemple, un LSP bidirectionnel associé est configuré entre les routeurs R1 et R2, pour lesquels les mesures de performances sont mesurées.
Configuration
Configuration rapide cli
Pour configurer rapidement cet exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez les détails nécessaires pour correspondre à la configuration de votre réseau, copiez et collez les commandes dans la CLI au niveau de la [edit] hiérarchie, puis entrez commit à partir du mode de configuration.
R1
set chassis network-services enhanced-ip set interfaces ge-0/0/0 unit 0 family inet address 10.1.1.1/30 set interfaces ge-0/0/0 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.10.0.1/32 set interfaces lo0 unit 0 family mpls set protocols mpls interface ge-0/0/0.0 set protocols mpls interface lo0.0 set protocols mpls interface fxp0.0 disable set protocols mpls label-switched-path R1-R2 associate-lsp R2-R1 set protocols mpls label-switched-path R1-R2 install 10.20.0.0/24 active set protocols mpls label-switched-path R1-R2 oam mpls-tp-mode set protocols mpls label-switched-path R1-R2 oam performance-monitoring querier delay traffic-class tc-0 query-interval 1000 set protocols mpls label-switched-path R1-R2 oam performance-monitoring querier loss traffic-class none query-interval 1000 set protocols mpls label-switched-path R1-R2 oam performance-monitoring querier loss-delay traffic-class tc-0 query-interval 1000 set protocols mpls label-switched-path R1-R2 oam performance-monitoring responder delay min-query-interval 1000 set protocols mpls label-switched-path R1-R2 oam performance-monitoring responder loss min-query-interval 1000 set protocols mpls label-switched-path R1-R2 to 10.20.0.1 set protocols mpls label-switched-path R1-R2 ultimate-hop-popping set protocols mpls statistics traffic-class-statistics set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols ospf traffic-engineering set protocols rsvp interface ge-0/0/0.0 set protocols rsvp interface lo0.0 set protocols rsvp interface fxp0.0 disable set routing-options router-id 10.10.0.1
R2
set chassis network-services enhanced-ip set interfaces ge-0/0/0 unit 0 family inet address 10.1.1.2/30 set interfaces ge-0/0/0 unit 0 family mpls set interfaces lo0 unit 0 family inet address 10.20.0.1/32 set interfaces lo0 unit 0 family mpls set protocols mpls interface ge-0/0/0.0 set protocols mpls interface lo0.0 set protocols mpls interface fxp0.0 disable set protocols mpls label-switched-path R2-R1 associate-lsp R1-R2 set protocols mpls label-switched-path R2-R1 install 10.10.0.0/24 active set protocols mpls label-switched-path R2-R1 oam mpls-tp-mode set protocols mpls label-switched-path R2-R1 oam performance-monitoring responder delay min-query-interval 1000 set protocols mpls label-switched-path R2-R1 oam performance-monitoring responder loss min-query-interval 1000 set protocols mpls label-switched-path R2-R1 oam performance-monitoring querier delay traffic-class tc-0 query-interval 1000 set protocols mpls label-switched-path R2-R1 oam performance-monitoring querier loss traffic-class none query-interval 1000 set protocols mpls label-switched-path R2-R1 oam performance-monitoring querier loss-delay traffic-class tc-0 query-interval 1000 set protocols mpls label-switched-path R2-R1 to 10.10.0.1 set protocols mpls label-switched-path R2-R1 ultimate-hop-popping set protocols mpls statistics traffic-class-statistics set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 set protocols ospf area 0.0.0.0 interface lo0.0 set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols ospf traffic-engineering set protocols rsvp interface ge-0/0/0.0 set protocols rsvp interface lo0.0 set protocols rsvp interface fxp0.0 disable set routing-options router-id 10.20.0.1
Procédure
Procédure étape par étape
L’exemple suivant exige que vous parcouriez différents niveaux dans la hiérarchie de configuration. Pour plus d’informations sur la navigation sur l’interface cli, consultez Utilisation de l’éditeur CLI en mode de configuration dans le guide de l’utilisateur CLI.
Pour configurer le routeur R1 :
-
Activez la configuration améliorée des services réseau IP.
[edit chassis] user@R1# set network-services enhanced-ip
-
Configurez les interfaces du routeur R1.
[edit interfaces] user@R1# set ge-0/0/0 unit 0 family inet address 10.1.1.1/30 user@R1# set ge-0/0/0 unit 0 family mpls user@R1# set lo0 unit 0 family inet address 10.10.0.1/32 user@R1# set lo0 unit 0 family mpls
-
Configurez l’ID du routeur pour le routeur R1.
[edit routing-options] user@R1# set router-id 10.10.0.1
-
Activez RSVP sur toutes les interfaces du routeur R1, à l’exception de l’interface de gestion.
[edit protocols] user@R1# set rsvp interface ge-0/0/0.0 user@R1# set rsvp interface lo0.0 user@R1# set rsvp interface fxp0.0 disable
-
Activez MPLS sur toutes les interfaces du routeur R1, à l’exception de l’interface de gestion.
[edit protocols] user@R1# set mpls interface ge-0/0/0.0 user@R1# set mpls interface lo0.0 user@R1# set mpls interface fxp0.0 disable
-
Configurez un LSP bidirectionnel associé au routeur R2.
[edit protocols] user@R1# set mpls label-switched-path R1-R2 to 10.20.0.1 user@R1# set mpls label-switched-path R1-R2 install 10.20.0.0/24 active user@R1# set mpls label-switched-path R1-R2 oam mpls-tp-mode user@R1# set mpls label-switched-path R1-R2 ultimate-hop-popping user@R1# set mpls label-switched-path R1-R2 associate-lsp R2-R1
-
Créez des classes de trafic pour gérer les statistiques de trafic de données par classe de trafic.
Cela permet de mesurer les pertes et les retards par classe de trafic.
[edit protocols] user@R1# set mpls statistics traffic-class-statistics
-
Configurez la surveillance des performances côté querier.
[edit protocols] user@R1# set mpls label-switched-path R1-R2 oam performance-monitoring querier delay traffic-class tc-0 query-interval 1000 user@R1# set mpls label-switched-path R1-R2 oam performance-monitoring querier loss traffic-class none query-interval 1000 user@R1# set mpls label-switched-path R1-R2 oam performance-monitoring querier loss-delay traffic-class tc-0 query-interval 1000
-
Configurez la surveillance des performances côté répondeur.
[edit protocols] user@R1# set mpls label-switched-path R1-R2 oam performance-monitoring responder delay min-query-interval 1000 user@R1# set mpls label-switched-path R1-R2 oam performance-monitoring responder loss min-query-interval 1000
-
Configurez OSPF avec des fonctionnalités d’ingénierie du trafic et activez OSPF sur toutes les interfaces du routeur R1, à l’exception de l’interface de gestion.
[edit protocols] user@R1# set ospf traffic-engineering user@R1# set ospf area 0.0.0.0 interface ge-0/0/0.0 user@R1# set ospf area 0.0.0.0 interface lo0.0 user@R1# set ospf interface fxp0.0 disable
Résultats
À partir du mode de configuration, confirmez votre configuration en entrant le show chassis, show interfaces, show routing-optionset les show protocols commandes. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.
user@R1# show chassis network-services enhanced-ip;
user@R1# show interfaces
ge-0/0/0 {
unit 0 {
family inet {
address 10.1.1.1/30;
}
family mpls;
}
}
lo0 {
unit 0 {
family inet {
address 10.10.0.1/32;
}
family mpls;
}
}
user@R1# show routing-options router-id 10.10.0.1;
user@R1# show protocols
rsvp {
interface ge-0/0/0.0;
interface lo0.0;
interface fxp0.0 {
disable;
}
}
mpls {
label-switched-path R1-R2 {
to 10.20.0.1;
install 10.20.0.0/24 active;
oam {
mpls-tp-mode;
performance-monitoring {
querier {
loss {
traffic-class none {
query-interval 1000;
}
}
delay {
traffic-class tc-0 {
query-interval 1000;
}
}
loss-delay {
traffic-class none {
query-interval 1000;
}
}
}
responder {
loss {
min-query-interval 1000;
}
delay {
min-query-interval 1000;
}
}
}
}
ultimate-hop-popping;
associate-lsp R2-R1;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface ge-0/0/0.0;
interface lo0.0;
interface fxp0.0 {
disable;
}
}
}
Vérification
Vérifier la mesure des pertes et des retards
But
Vérifiez la mesure des pertes et des retards.
Action
À partir du mode opérationnel, exécutez la show performance-monitoring mpls lsp commande.
user@R1> show performance-monitoring mpls lsp
Session Total: 3 Up: 3 Down: 0
LSP name:R1-R2, PM State:Up
Loss measurement Data:
Duration: 00:04:43
Traffic-class: None
Queries sent: 282
Responses received: 282
Responses dropped due to errors: 0
Queries timeout: 0
Forward loss measurement:
Average packet loss: 0
Average packet throughput: 554338
Reverse loss measurement:
Average packet loss: 0
Average packet throughput: 1352077
LSP name:R1-R2, PM State:Up
Delay measurement Data:
Duration: 00:04:43
Traffic-class: 0
Queries sent: 282
Responses received: 282
Responses dropped due to errors: 0
Queries timeout: 0
Best 2-way channel delay: 72 usecs
Worst 2-way channel delay: 365 usecs
Best round trip time: 843 usecs
Worst round trip time: 105523 usecs
Avg absolute fw delay variation: 1619 usecs
Avg absolute rv delay variation: 1619 usecs
LSP name:R1-R2, PM State:Up
Loss measurement Data:
Duration: 00:04:43
Traffic-class: None
Queries sent: 282
Responses received: 282
Responses dropped due to errors: 0
Queries timeout: 0
Forward loss measurement:
Average packet loss: 0
Average packet throughput: 553927
Reverse loss measurement:
Average packet loss: 0
Average packet throughput: 1351531
Delay measurement Data:
Best 2-way channel delay: 76 usecs
Worst 2-way channel delay: 368 usecs
Best round trip time: 1082 usecs
Worst round trip time: 126146 usecs
Avg absolute fw delay variation: 1618 usecs
Avg absolute rv delay variation: 1619 usecs
Sens
Les mesures de perte de paquets et de retard pour le LSP sont affichées.
Configuration de la mesure des pertes et des retards à la demande
Vous pouvez configurer une mesure à la demande des pertes et des retards pour les chemins de commutation d’étiquettes (LSP) UHP (Point-to-point ultimate hop popping) dans les réseaux MPLS pour surveiller les performances du réseau. Les monitor mpls loss rsvpcommandes , monitor mpls delay rsvpet monitor mpls loss-delay rsvp CLI fournissent un résumé à la demande des métriques de performances pour la perte de paquets en mode direct, le retard de paquet dans les deux sens et les mesures associées, telles que la variation des retards entre paquets et la mesure du débit du canal.
Cette fonctionnalité offre une visibilité en temps réel sur les performances du réseau, ce qui facilite la planification, le dépannage et l’évaluation des performances du réseau.
Avant de commencer :
Configurez les interfaces de l’équipement.
Configurez l’ID du routeur de l’équipement.
Configurez les protocoles suivants :
RSVP
OSPF
Activez les capacités d’ingénierie du trafic.
MPLS
Pour configurer l’équipement PE :
Configuration des mesures de perte et de retard pro-active
Vous pouvez configurer des mesures de perte et de retard pro-active pour les chemins de commutation d’étiquettes (LSP) de saut ultime point à point dans les réseaux MPLS pour surveiller les performances du réseau. La show performance-monitoring mpls lsp commande CLI fournit un résumé des métriques de performances pour la perte de paquets en mode direct, le retard de paquet à double sens et les mesures associées, telles que la variation des retards entre paquets et la mesure du débit du canal.
Cette fonctionnalité offre une visibilité en temps réel sur les performances du réseau, ce qui facilite la planification, le dépannage et l’évaluation des performances du réseau.
Cette fonctionnalité fournit les mesures de performances suivantes :
Variation de délai entre paquets (IPDV)
Mesure des pertes
Retard aller-retour (RTT)
Mesure du débit
Délai de canal bidirectionnaire
Avant de commencer :
Configurez les interfaces de l’équipement.
Configurez les numéros du système et les iDs de routeur autonomes pour les équipements.
Configurez les protocoles suivants :
MPLS
OSPF
RSVP
Pour configurer des mesures de perte et de retard pro-active sur l’équipement PE :